From herbert@gondor.apana.org.au Sun May 1 01:12:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 01:12:13 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j418C77J031945 for ; Sun, 1 May 2005 01:12:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DS9YG-00057c-00; Sun, 01 May 2005 18:11:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DS9YC-0005Nz-00; Sun, 01 May 2005 18:11:40 +1000 Date: Sun, 1 May 2005 18:11:40 +1000 To: Tommy Christensen Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost Message-ID: <20050501081140.GA20647@gondor.apana.org.au> References: <426FDF8B.1030808@tpack.net> <20050427214224.GA25325@gondor.apana.org.au> <42701FFD.5000505@tpack.net> <20050427234359.GB22238@gondor.apana.org.au> <1114768308.4695.1487.camel@tsc-6.cph.tpack.net> <20050429101836.GA2237@gondor.apana.org.au> <1114777355.4695.1598.camel@tsc-6.cph.tpack.net> <20050429234512.GA22699@gondor.apana.org.au> <427380A8.2070006@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427380A8.2070006@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Hi Tommy: I agree with you now that your patch is the best way to go. On Sat, Apr 30, 2005 at 02:57:12PM +0200, Tommy Christensen wrote: > > Regarding the sort of NICs you mention, I came to the conclusion that > we shouldn't try to fix this in the stack. They indicate that they can > take more packets (by NOT calling netif_stop_queue), so we should obey > this and leave it to the drivers to handle things, e.g. by dropping the > packets if needed. Otherwise we deprive the drivers the option of > maintaining their tx_carrier_errors statistics, for instance. And, > theoretically, a driver could even depend on having its hard_start_xmit > invoked in order to kickstart its TX engine. We should document this so that NIC drivers are told about this. Any NICs that can't process their TX rings while the carrier is off needs to stop their queue just before calling netif_carrier_off. > So, I am reluctant to drop this check for netif_queue_stopped. Doing so > would needlessly impact the drivers that work fine already (or at least > should be handling this situation). I don't see how those drivers are worse off without this check. When the carrier is off it doesn't really matter whether we're sending them packets or not. Besides, you didn't put this check in the link_watch code path which would affect them a lot more than this path. > >The other concern I have is that this code can call dev_activate > >or dev_deactivate twice in a row. As far as I can tell this is > >harmless for the moment but it would be nice if we can avoid it. > > Agreed, this isn't ideal. However, if this is the only downside, it > is something that I'd be happy to live with. I don't see any easy > way to avoid it. > > Ideas, anyone? You mean how we can avoid the double call? Here is one way. Move the setting of IF_RUNNING out of dev_get_flags and into dev_activate. This would guarantee that IF_RUNNING is set iff the device has a qdisc. Assuming that you remove the aformentioned netif_queue_stopped check, the device has a qdisc iff the carrier is on. So this preserves the meaning of IF_RUNNING. Now you can avoid the double call by returning early in dev_activate if IF_RUNNING is set, and in dev_deactivate if IF_RUNNING is not set. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From adobriyan@mail.ru Sun May 1 01:29:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 01:29:31 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j418TQ7J000594 for ; Sun, 1 May 2005 01:29:26 -0700 Received: from [217.10.38.130] (port=48616 helo=mail.ru) by mx2.mail.ru with smtp id 1DS9pF-000G3B-00; Sun, 01 May 2005 12:29:17 +0400 Received: by mail.ru (nbSMTP-0.98) for uid 1000 for ; Sun, 1 May 2005 12:32:43 +0000 (GMT) Date: Sun, 1 May 2005 12:32:42 +0000 From: Alexey Dobriyan To: Jesper Juhl Cc: "David S. Miller" , Jouni Malinen , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] resource release cleanup in net/ Message-ID: <20050501123242.GA8407@mipter.zuzino.mipt.ru> Mail-Followup-To: Jesper Juhl , "David S. Miller" , Jouni Malinen , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050501025349.GA9243@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adobriyan@mail.ru Precedence: bulk X-list: netdev On Sun, May 01, 2005 at 01:13:28AM +0200, Jesper Juhl wrote: > On Sun, 1 May 2005, Alexey Dobriyan wrote: > > > On Sat, Apr 30, 2005 at 10:36:00PM +0200, Jesper Juhl wrote: > > > Since Andrew merged the patch that makes calling crypto_free_tfm() with a > > > NULL pointer safe into 2.6.12-rc3-mm1, I made a patch to remove checks for > > > NULL before calling that function > > > drivers/net/wireless/hostap/hostap_crypt_ccmp.c | 5 - > > > drivers/net/wireless/hostap/hostap_crypt_tkip.c | 10 +- > > > drivers/net/wireless/hostap/hostap_crypt_wep.c | 5 - > > > net/ieee80211/ieee80211_crypt_ccmp.c | 5 - > > > net/ieee80211/ieee80211_crypt_tkip.c | 10 +- > > > net/ieee80211/ieee80211_crypt_wep.c | 5 - > > I think I have a better one for these. > > > > --- linux-2.6.12-rc3-mm1/drivers/net/wireless/hostap/hostap_crypt_ccmp.c 2005-05-01 01:53:50.000000000 +0000 > > +++ linux-2.6.12-rc3-mm1-hostap/drivers/net/wireless/hostap/hostap_crypt_ccmp.c 2005-05-01 02:21:10.000000000 +0000 > > @@ -121,8 +118,7 @@ fail: > > static void hostap_ccmp_deinit(void *priv) > > { > > struct hostap_ccmp_data *_priv = priv; > > - if (_priv && _priv->tfm) > > - crypto_free_tfm(_priv->tfm); > > + crypto_free_tfm(_priv->tfm); > > kfree(priv); > > module_put(THIS_MODULE); > > } > > This will Oops if _priv is NULL. That's why my patch did > > if (_priv) > crypto_free_tfm(_priv->tfm); After hostap_ccmp_init() returns successfully: 1. priv is valid pointer line 95 2. priv->tfm is valid pointer line 102 From akpm@osdl.org Sun May 1 03:29:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 03:29:16 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41ATC7J004279 for ; Sun, 1 May 2005 03:29:12 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j41ASYs4012605 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 1 May 2005 03:28:39 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j41ASWQe010017; Sun, 1 May 2005 03:28:32 -0700 Date: Sun, 1 May 2005 03:28:09 -0700 From: Andrew Morton To: netfilter-devel@lists.netfilter.org Cc: netdev@oss.sgi.com Subject: CONFIG_NETFILTER_DEBUG spew Message-Id: <20050501032809.3d0b4cda.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev With the below .config, `telnet localhost' spews stuff like this: [ 179.995229] ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN [ 179.995274] skb: pf=2 (unowned) dev=lo len=54 [ 179.995304] PROTO=6 127.0.0.1:23 127.0.0.1:2737 L=54 S=0x10 I=37030 F=0x4000 T=64 2.6.12-rc3 doesn't do this - it's something to do with changes in Linus's tree post-2.6.12-rc3. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc3 # Sun May 1 03:19:50 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-arakou" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set # CONFIG_SMP is not set # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="/dev/hda2" # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set CONFIG_ACPI_CONTAINER=m # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m # CONFIG_CPU_FREQ_STAT_DETAILS is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # CONFIG_X86_SPEEDSTEP_LIB is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set CONFIG_PCI_MSI=y # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # CONFIG_PCI_DEBUG is not set CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_FW_LOADER is not set # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_GSC is not set CONFIG_PARPORT_1284=y # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_LBD is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_ATA_OVER_ETH is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=m # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_GENERIC is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # # Device Drivers # # CONFIG_IEEE1394_PCILYNX is not set # CONFIG_IEEE1394_OHCI1394 is not set # # Protocol Drivers # CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set # CONFIG_IEEE1394_ETH1394 is not set CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_CMP is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y # CONFIG_IP_ROUTE_MULTIPATH is not set CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_NET_IPGRE_BROADCAST is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=y # CONFIG_IP_TCPDIAG_IPV6 is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m # CONFIG_IPV6_TUNNEL is not set CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_BRIDGE_NETFILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m # CONFIG_IP_NF_CT_ACCT is not set CONFIG_IP_NF_CONNTRACK_MARK=y # CONFIG_IP_NF_CT_PROTO_SCTP is not set CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m # CONFIG_IP_NF_AMANDA is not set CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m # CONFIG_IP_NF_MATCH_ECN is not set # CONFIG_IP_NF_MATCH_DSCP is not set # CONFIG_IP_NF_MATCH_AH_ESP is not set CONFIG_IP_NF_MATCH_LENGTH=m # CONFIG_IP_NF_MATCH_TTL is not set # CONFIG_IP_NF_MATCH_TCPMSS is not set CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m # CONFIG_IP_NF_MATCH_PHYSDEV is not set CONFIG_IP_NF_MATCH_ADDRTYPE=m # CONFIG_IP_NF_MATCH_REALM is not set # CONFIG_IP_NF_MATCH_SCTP is not set CONFIG_IP_NF_MATCH_COMMENT=m CONFIG_IP_NF_MATCH_CONNMARK=m CONFIG_IP_NF_MATCH_HASHLIMIT=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m # CONFIG_IP_NF_TARGET_ULOG is not set # CONFIG_IP_NF_TARGET_TCPMSS is not set CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m # CONFIG_IP_NF_TARGET_DSCP is not set CONFIG_IP_NF_TARGET_MARK=m # CONFIG_IP_NF_TARGET_CLASSIFY is not set CONFIG_IP_NF_TARGET_CONNMARK=m # CONFIG_IP_NF_TARGET_CLUSTERIP is not set # CONFIG_IP_NF_RAW is not set # CONFIG_IP_NF_ARPTABLES is not set # # IPv6: Netfilter Configuration (EXPERIMENTAL) # # CONFIG_IP6_NF_QUEUE is not set # CONFIG_IP6_NF_IPTABLES is not set # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=m # CONFIG_BRIDGE_EBT_BROUTE is not set # CONFIG_BRIDGE_EBT_T_FILTER is not set # CONFIG_BRIDGE_EBT_T_NAT is not set # CONFIG_BRIDGE_EBT_802_3 is not set # CONFIG_BRIDGE_EBT_AMONG is not set # CONFIG_BRIDGE_EBT_ARP is not set # CONFIG_BRIDGE_EBT_IP is not set # CONFIG_BRIDGE_EBT_LIMIT is not set # CONFIG_BRIDGE_EBT_MARK is not set # CONFIG_BRIDGE_EBT_PKTTYPE is not set # CONFIG_BRIDGE_EBT_STP is not set # CONFIG_BRIDGE_EBT_VLAN is not set # CONFIG_BRIDGE_EBT_ARPREPLY is not set # CONFIG_BRIDGE_EBT_DNAT is not set # CONFIG_BRIDGE_EBT_MARK_T is not set # CONFIG_BRIDGE_EBT_REDIRECT is not set # CONFIG_BRIDGE_EBT_SNAT is not set # CONFIG_BRIDGE_EBT_LOG is not set # CONFIG_BRIDGE_EBT_ULOG is not set CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set CONFIG_BRIDGE=m # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set # CONFIG_NET_SCH_CLK_CPU is not set CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # CONFIG_NET_QOS is not set # CONFIG_NET_CLS is not set # CONFIG_NET_CLS_ROUTE is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set CONFIG_E100=y # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set CONFIG_8139TOO=m CONFIG_8139TOO_PIO=y CONFIG_8139TOO_TUNE_TWISTER=y CONFIG_8139TOO_8129=y CONFIG_8139_OLD_RX_RESET=y # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set CONFIG_SK98LIN=m # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # # CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_PRINTER is not set CONFIG_PPDEV=m # CONFIG_TIPAR is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=m CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=y # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set # # TPM devices # # CONFIG_TCG_TPM is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_ELEKTOR=m # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_ISA is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Hardware Sensors Chip support # # CONFIG_I2C_SENSOR is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # # Other I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_RTC8564 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # # CONFIG_VIDEO_BT848 is not set # CONFIG_VIDEO_PMS is not set # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5246A is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_OVCAMCHIP is not set # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_SF16FMR2 is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SOFT_CURSOR=y # CONFIG_FB_MACMODES is not set CONFIG_FB_MODE_HELPERS=y # CONFIG_FB_TILEBLITTING is not set # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON_OLD=m CONFIG_FB_RADEON=m # CONFIG_FB_RADEON_I2C is not set # CONFIG_FB_RADEON_DEBUG is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m # CONFIG_SND_SEQUENCER_OSS is not set # CONFIG_SND_RTCTIMER is not set # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # ISA devices # # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_WAVEFRONT is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # # PCI devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_SONICVIBES is not set CONFIG_SND_VIA82XX=m # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_HDA_INTEL is not set # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m # CONFIG_USB_EHCI_SPLIT_ISO is not set CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Input Devices # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_SN9C102 is not set # CONFIG_USB_STV680 is not set # CONFIG_USB_PWC is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set CONFIG_USB_MON=m # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETKIT is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_TEST is not set # # USB ATM/DSL drivers # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # # CONFIG_MMC is not set # # InfiniBand support # # CONFIG_INFINIBAND is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y # CONFIG_EXT2_FS_SECURITY is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y # CONFIG_REISERFS_FS_SECURITY is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # # XFS support # # CONFIG_XFS_FS is not set CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_TMPFS_XATTR is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_CRAMFS=y # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set CONFIG_NFSD_TCP=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_SUNRPC=y # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp850" CONFIG_CIFS=m # CONFIG_CIFS_STATS is not set # CONFIG_CIFS_XATTR is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set CONFIG_NLS_CODEPAGE_863=m # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_PRINTK_TIME=y CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_FS is not set CONFIG_FRAME_POINTER=y CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_KPROBES is not set # CONFIG_DEBUG_STACK_USAGE is not set # # Page alloc debug is incompatible with Software Suspend on i386 # CONFIG_4KSTACKS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set CONFIG_CRYPTO_WP512=m # CONFIG_CRYPTO_TGR192 is not set CONFIG_CRYPTO_DES=m # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_AES_586 is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_DEFLATE=m # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_TEST is not set # # Hardware crypto devices # # CONFIG_CRYPTO_DEV_PADLOCK is not set # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=y # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y From herbert@gondor.apana.org.au Sun May 1 04:15:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 04:15:47 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41BFe7J006904 for ; Sun, 1 May 2005 04:15:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSCPo-0005tL-00; Sun, 01 May 2005 21:15:12 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSCPj-0000Za-00; Sun, 01 May 2005 21:15:07 +1000 Date: Sun, 1 May 2005 21:15:07 +1000 To: Patrick McHardy Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Andrew Morton Subject: Re: CONFIG_NETFILTER_DEBUG spew Message-ID: <20050501111507.GA2133@gondor.apana.org.au> References: <20050501032809.3d0b4cda.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050501032809.3d0b4cda.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, May 01, 2005 at 10:28:09AM +0000, Andrew Morton wrote: > > With the below .config, `telnet localhost' spews stuff like this: > > [ 179.995229] ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN > [ 179.995274] skb: pf=2 (unowned) dev=lo len=54 > [ 179.995304] PROTO=6 127.0.0.1:23 127.0.0.1:2737 L=54 S=0x10 I=37030 F=0x4000 T=64 > > 2.6.12-rc3 doesn't do this - it's something to do with changes in Linus's > tree post-2.6.12-rc3. Patrick, looks like we need to fix nf_debug_ip_local_deliver to reflect the newly added nf_reset on the ip_output path. BTW, should we do nf_reset in ip_dev_loopback_xmit as well? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bunk@stusta.de Sun May 1 06:56:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 06:56:26 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j41DuJ7J017122 for ; Sun, 1 May 2005 06:56:20 -0700 Received: (qmail 14345 invoked from network); 1 May 2005 13:56:07 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 1 May 2005 13:56:07 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 9AE7CBB5D6; Sun, 1 May 2005 15:56:07 +0200 (CEST) Date: Sun, 1 May 2005 15:56:07 +0200 From: Adrian Bunk To: jkmaline@cc.hut.fi Cc: hostap@shmoo.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [-mm patch] net/ieee80211/: remove pci.h #include's Message-ID: <20050501135607.GD3592@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1593 Lines: 44 I was wondering why editing pci.h triggered the rebuild of three files under net/, and as far as I can see, there's no reason for these three files to #include pci.h . Signed-off-by: Adrian Bunk --- net/ieee80211/ieee80211_module.c | 1 - net/ieee80211/ieee80211_rx.c | 1 - net/ieee80211/ieee80211_tx.c | 1 - 3 files changed, 3 deletions(-) --- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c.old 2005-04-30 23:23:14.000000000 +0200 +++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c 2005-04-30 23:23:18.000000000 +0200 @@ -40,7 +40,6 @@ #include #include #include -#include #include #include #include --- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c.old 2005-04-30 23:23:25.000000000 +0200 +++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c 2005-04-30 23:23:32.000000000 +0200 @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include --- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c.old 2005-04-30 23:23:42.000000000 +0200 +++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c 2005-04-30 23:23:46.000000000 +0200 @@ -23,7 +23,6 @@ #include #include #include -#include #include #include #include From kaber@trash.net Sun May 1 08:17:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 08:17:20 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41FHG7J020898 for ; Sun, 1 May 2005 08:17:17 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DSGBp-0002AQ-HQ; Sun, 01 May 2005 17:17:01 +0200 Message-ID: <4274F2ED.9080404@trash.net> Date: Sun, 01 May 2005 17:17:01 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Andrew Morton , "David S. Miller" Subject: Re: CONFIG_NETFILTER_DEBUG spew References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> In-Reply-To: <20050501111507.GA2133@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------070805040200040001000308" X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2748 Lines: 79 This is a multi-part message in MIME format. --------------070805040200040001000308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > On Sun, May 01, 2005 at 10:28:09AM +0000, Andrew Morton wrote: > >>With the below .config, `telnet localhost' spews stuff like this: >> >>[ 179.995229] ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN >>[ 179.995274] skb: pf=2 (unowned) dev=lo len=54 >>[ 179.995304] PROTO=6 127.0.0.1:23 127.0.0.1:2737 L=54 S=0x10 I=37030 F=0x4000 T=64 >> >>2.6.12-rc3 doesn't do this - it's something to do with changes in Linus's >>tree post-2.6.12-rc3. > > Patrick, looks like we need to fix nf_debug_ip_local_deliver to > reflect the newly added nf_reset on the ip_output path. You're right. I'm tempted to remove the entire nf_debug stuff, as far as I know it has never found a real bug. But for now I've only fixed the warning. > BTW, should we do nf_reset in ip_dev_loopback_xmit as well? I think so. I'll send a patch later, I'm a bit in a hurry right now. Regards Patrick --------------070805040200040001000308 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" [NETFILTER]: Fix nf_debug_ip_local_deliver() Signed-off-by: Patrick McHardy --- commit a91b6fa8bc4b1626d413d58c21cfcfecabbb4a61 tree 9544bb88b28c2e3ca4b0a66fedfa2bb540ec06e2 parent e8108c98dd6d65613fa0ec9d2300f89c48d554bf author Patrick McHardy 1114952978 +0200 committer Patrick McHardy 1114952978 +0200 Index: net/core/netfilter.c =================================================================== --- 3608de2fc88b062070a9d197eda9cac1fb9635d3/net/core/netfilter.c (mode:100644 sha1:e51cfa46950cf8f1f4dea42be94e71d76d8c3c5b) +++ 9544bb88b28c2e3ca4b0a66fedfa2bb540ec06e2/net/core/netfilter.c (mode:100644 sha1:92c51824797dd15018e579eb5753cc372e04fd3d) @@ -217,21 +217,10 @@ * NF_IP_RAW_INPUT and NF_IP_PRE_ROUTING. */ if (!skb->dev) { printk("ip_local_deliver: skb->dev is NULL.\n"); - } - else if (strcmp(skb->dev->name, "lo") == 0) { - if (skb->nf_debug != ((1 << NF_IP_LOCAL_OUT) - | (1 << NF_IP_POST_ROUTING) - | (1 << NF_IP_PRE_ROUTING) - | (1 << NF_IP_LOCAL_IN))) { - printk("ip_local_deliver: bad loopback skb: "); - debug_print_hooks_ip(skb->nf_debug); - nf_dump_skb(PF_INET, skb); - } - } - else { + } else { if (skb->nf_debug != ((1<nf_debug); nf_dump_skb(PF_INET, skb); } --------------070805040200040001000308-- From bunk@stusta.de Sun May 1 08:42:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 08:42:15 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j41FgA7J025577 for ; Sun, 1 May 2005 08:42:11 -0700 Received: (qmail 17005 invoked from network); 1 May 2005 15:42:01 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 1 May 2005 15:42:01 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 3B69EAFC8E; Sun, 1 May 2005 17:42:01 +0200 (CEST) Date: Sun, 1 May 2005 17:42:01 +0200 From: Adrian Bunk To: Andrew Morton Cc: linux@syskonnect.de, Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] remove drivers/net/skfp/lnkstat.c Message-ID: <20050501154201.GH3592@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 5847 Lines: 232 This patch removes a file that seems to be used only on AIX (sic). Signed-off-by: Adrian Bunk --- This patch was already sent on: - 20 Apr 2005 drivers/net/skfp/Makefile | 2 drivers/net/skfp/lnkstat.c | 204 ------------------------------------- 2 files changed, 1 insertion(+), 205 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/Makefile.old 2005-04-20 01:39:14.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/skfp/Makefile 2005-04-20 01:39:33.000000000 +0200 @@ -6,7 +6,7 @@ skfp-objs := skfddi.o hwmtm.o fplustm.o smt.o cfm.o \ ecm.o pcmplc.o pmf.o queue.o rmt.o \ - smtdef.o smtinit.o smttimer.o srf.o lnkstat.o \ + smtdef.o smtinit.o smttimer.o srf.o \ hwt.o drvfbi.o ess.o # NOTE: --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/lnkstat.c 2005-04-20 01:35:22.000000000 +0200 +++ /dev/null 2005-03-19 22:42:59.000000000 +0100 @@ -1,204 +0,0 @@ -/****************************************************************************** - * - * (C)Copyright 1998,1999 SysKonnect, - * a business unit of Schneider & Koch & Co. Datensysteme GmbH. - * - * See the file "skfddi.c" for further information. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * The information in this file is provided "AS IS" without warranty. - * - ******************************************************************************/ - -/* - IBM FDDI read error log function -*/ - -#include "h/types.h" -#include "h/fddi.h" -#include "h/smc.h" -#include "h/lnkstat.h" - -#ifndef lint -static const char ID_sccs[] = "@(#)lnkstat.c 1.8 97/04/11 (C) SK " ; -#endif - -#ifdef sun -#define _far -#endif - -#define EL_IS_OK(x,l) ((((int)&(((struct s_error_log *)0)->x)) + \ - sizeof(er->x)) <= l) - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_get_error_word(smc) - struct s_smc *smc ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT error work for AIX events. - -Return smt_error_word These bits are supported: - - SMT_ERL_ALC == [PS/PA].fddiPORTLerFlag - SMT_ERL_BLC == [PB].fddiPORTLerFlag - SMT_ERL_NCC == fddiMACNotCopiedFlag - SMT_ERL_FEC == fddiMACFrameErrorFlag - - END_MANUAL_ENTRY() - */ -u_long smt_get_error_word(struct s_smc *smc) -{ - u_long st; - - /* - * smt error word low - */ - st = 0 ; - if (smc->s.sas == SMT_SAS) { - if (smc->mib.p[PS].fddiPORTLerFlag) - st |= SMT_ERL_ALC ; - } - else { - if (smc->mib.p[PA].fddiPORTLerFlag) - st |= SMT_ERL_ALC ; - if (smc->mib.p[PB].fddiPORTLerFlag) - st |= SMT_ERL_BLC ; - } - if (smc->mib.m[MAC0].fddiMACNotCopiedFlag) - st |= SMT_ERL_NCC ; /* not copied condition */ - if (smc->mib.m[MAC0].fddiMACFrameErrorFlag) - st |= SMT_ERL_FEC ; /* frame error condition */ - - return st; -} - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_get_event_word(smc) - struct s_smc *smc ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT event work for AIX events. - -Return smt_event_word always 0 - - END_MANUAL_ENTRY() - */ -u_long smt_get_event_word(struct s_smc *smc) -{ - return (u_long) 0; -} - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_get_port_event_word(smc) - struct s_smc *smc ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT port event work for AIX events. - -Return smt_port_event_word always 0 - - END_MANUAL_ENTRY() - */ -u_long smt_get_port_event_word(struct s_smc *smc) -{ - return (u_long) 0; -} - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_read_errorlog(smc,p,len) - struct s_smc *smc ; - char _far *p ; - int len ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT error log field for AIX events. - -Para p pointer to the error log field - len len of the error log field - -Return len used len of the error log field - - END_MANUAL_ENTRY() - */ -int smt_read_errorlog(struct s_smc *smc, char _far *p, int len) -{ - int i ; - int st ; - struct s_error_log _far *er ; - - er = (struct s_error_log _far *) p ; - if (len > sizeof(struct s_error_log)) - len = sizeof(struct s_error_log) ; - for (i = 0 ; i < len ; i++) - *p++ = 0 ; - /* - * set count - */ - if (EL_IS_OK(set_count_high,len)) { - er->set_count_low = (u_short)smc->mib.fddiSMTSetCount.count ; - er->set_count_high = - (u_short)(smc->mib.fddiSMTSetCount.count >> 16L) ; - } - /* - * aci - */ - if (EL_IS_OK(aci_id_code,len)) { - er->aci_id_code = 0 ; - } - /* - * purge counter is missed frames; 16 bits only - */ - if (EL_IS_OK(purge_frame_counter,len)) { - if (smc->mib.m[MAC0].fddiMACCopied_Ct > 0xffff) - er->purge_frame_counter = 0xffff ; - else - er->purge_frame_counter = - (u_short)smc->mib.m[MAC0].fddiMACCopied_Ct ; - } - /* - * CMT and RMT state machines - */ - if (EL_IS_OK(ecm_state,len)) - er->ecm_state = smc->mib.fddiSMTECMState ; - - if (EL_IS_OK(pcm_b_state,len)) { - if (smc->s.sas == SMT_SAS) { - er->pcm_a_state = smc->y[PS].mib->fddiPORTPCMState ; - er->pcm_b_state = 0 ; - } - else { - er->pcm_a_state = smc->y[PA].mib->fddiPORTPCMState ; - er->pcm_b_state = smc->y[PB].mib->fddiPORTPCMState ; - } - } - if (EL_IS_OK(cfm_state,len)) - er->cfm_state = smc->mib.fddiSMTCF_State ; - if (EL_IS_OK(rmt_state,len)) - er->rmt_state = smc->mib.m[MAC0].fddiMACRMTState ; - - /* - * smt error word low (we only need the low order 16 bits.) - */ - - st = smt_get_error_word(smc) & 0xffff ; - - if (EL_IS_OK(smt_error_low,len)) - er->smt_error_low = st ; - - if (EL_IS_OK(ucode_version_level,len)) - er->ucode_version_level = 0x0101 ; - return(len) ; -} - From venza@brownhat.org Sun May 1 09:44:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 09:44:10 -0700 (PDT) Received: from gateway.milesteg.arr (adsl-10-231.38-151.net24.it [151.38.231.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j41Gi27J027527 for ; Sun, 1 May 2005 09:44:06 -0700 Received: (qmail 8822 invoked from network); 1 May 2005 16:43:52 -0000 Received: from unknown (HELO ?192.168.0.205?) (192.168.0.205) by gateway.milesteg.arr with SMTP; 1 May 2005 16:43:52 -0000 In-Reply-To: <20050430115249.GA3654@stusta.de> References: <20050429231653.32d2f091.akpm@osdl.org> <20050430115249.GA3654@stusta.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5c6061e021b4bd91a5b6ee47fbb7f575@brownhat.org> Content-Transfer-Encoding: 7bit Cc: Jeff Garzik , Linux Kernel Mailing List , Adrian Bunk , Netdev From: Daniele Venzano Subject: Re: [-mm patch] SIS900 must select MII Date: Sun, 1 May 2005 18:43:46 +0200 To: Andrew Morton X-Mailer: Apple Mail (2.622) X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: venza@brownhat.org Precedence: bulk X-list: netdev Content-Length: 860 Lines: 31 On 30/apr/05, at 13:52, Adrian Bunk wrote: > This patch fixes the following compile error caused by bk-netdev: > > <-- snip --> > > Signed-off-by: Adrian Bunk Signed-off-by: Daniele Venzano > --- linux-2.6.12-rc3-mm1/drivers/net/Kconfig.old 2005-04-30 > 13:47:25.000000000 +0200 > +++ linux-2.6.12-rc3-mm1/drivers/net/Kconfig 2005-04-30 > 13:47:48.000000000 +0200 > @@ -1543,8 +1543,9 @@ > config SIS900 > tristate "SiS 900/7016 PCI Fast Ethernet Adapter support" > depends on NET_PCI && PCI > select CRC32 > + select MII > ---help--- > This is a driver for the Fast Ethernet PCI network cards based on > the SiS 900 and SiS 7016 chips. The SiS 900 core is also embedded > in > SiS 630 and SiS 540 chipsets. If you have one of those, say Y and > > -- Daniele Venzano http://www.brownhat.org From tgraf@suug.ch Sun May 1 11:47:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 11:47:26 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41IlJ7J032006 for ; Sun, 1 May 2005 11:47:22 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 16AB81C0EB; Sun, 1 May 2005 20:47:32 +0200 (CEST) Date: Sun, 1 May 2005 20:47:31 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 1/2] [XFRM] Prevent off-by-one access to xfrm_dispatch Message-ID: <20050501184731.GJ577@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 520 Lines: 18 Makes the type > XFRM_MSG_MAX check behave correctly to protect access to xfrm_dispatch. Signed-off-by: Thomas Graf --- linux-2.6.12-rc3.orig/include/linux/xfrm.h 2005-04-30 20:22:19.000000000 +0200 +++ linux-2.6.12-rc3/include/linux/xfrm.h 2005-05-01 11:53:30.000000000 +0200 @@ -140,8 +140,9 @@ XFRM_MSG_FLUSHPOLICY, #define XFRM_MSG_FLUSHPOLICY XFRM_MSG_FLUSHPOLICY - XFRM_MSG_MAX + __XFRM_MSG_MAX }; +#define XFRM_MSG_MAX (__XFRM_MSG_MAX - 1) struct xfrm_user_tmpl { struct xfrm_id id; From tgraf@suug.ch Sun May 1 11:55:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 11:55:38 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41ItZ7J032616 for ; Sun, 1 May 2005 11:55:36 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 6DD1B1C0EB; Sun, 1 May 2005 20:55:48 +0200 (CEST) Date: Sun, 1 May 2005 20:55:48 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2/2] [XFRM] Cleanup xfrm_msg_min and xfrm_dispatch Message-ID: <20050501185548.GK577@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4959 Lines: 113 Converts xfrm_msg_min and xfrm_dispatch to use c99 designated initializers to make greping a little bit easier. Also replaces two hardcoded message type with meaningful names. Signed-off-by: Thomas Graf diff -Nru -X dontdiff linux-2.6.12-rc3.orig/include/linux/xfrm.h linux-2.6.12-rc3/include/linux/xfrm.h --- linux-2.6.12-rc3.orig/include/linux/xfrm.h 2005-05-01 13:17:00.000000000 +0200 +++ linux-2.6.12-rc3/include/linux/xfrm.h 2005-05-01 12:21:08.000000000 +0200 @@ -144,6 +144,8 @@ }; #define XFRM_MSG_MAX (__XFRM_MSG_MAX - 1) +#define XFRM_NR_MSGTYPES (XFRM_MSG_MAX + 1 - XFRM_MSG_BASE) + struct xfrm_user_tmpl { struct xfrm_id id; __u16 family; diff -Nru -X dontdiff linux-2.6.12-rc3.orig/net/xfrm/xfrm_user.c linux-2.6.12-rc3/net/xfrm/xfrm_user.c --- linux-2.6.12-rc3.orig/net/xfrm/xfrm_user.c 2005-04-30 20:22:26.000000000 +0200 +++ linux-2.6.12-rc3/net/xfrm/xfrm_user.c 2005-05-01 14:52:48.000000000 +0200 @@ -855,47 +855,44 @@ return 0; } -static const int xfrm_msg_min[(XFRM_MSG_MAX + 1 - XFRM_MSG_BASE)] = { - NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)), /* NEW SA */ - NLMSG_LENGTH(sizeof(struct xfrm_usersa_id)), /* DEL SA */ - NLMSG_LENGTH(sizeof(struct xfrm_usersa_id)), /* GET SA */ - NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)),/* NEW POLICY */ - NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_id)), /* DEL POLICY */ - NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_id)), /* GET POLICY */ - NLMSG_LENGTH(sizeof(struct xfrm_userspi_info)), /* ALLOC SPI */ - NLMSG_LENGTH(sizeof(struct xfrm_user_acquire)), /* ACQUIRE */ - NLMSG_LENGTH(sizeof(struct xfrm_user_expire)), /* EXPIRE */ - NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)),/* UPD POLICY */ - NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)), /* UPD SA */ - NLMSG_LENGTH(sizeof(struct xfrm_user_polexpire)), /* POLEXPIRE */ - NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)), /* FLUSH SA */ - NLMSG_LENGTH(0), /* FLUSH POLICY */ +#define XMSGSIZE(type) NLMSG_LENGTH(sizeof(struct type)) + +static const int xfrm_msg_min[XFRM_NR_MSGTYPES] = { + [XFRM_MSG_NEWSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_info), + [XFRM_MSG_DELSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_id), + [XFRM_MSG_GETSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_id), + [XFRM_MSG_NEWPOLICY - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userpolicy_info), + [XFRM_MSG_DELPOLICY - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userpolicy_id), + [XFRM_MSG_GETPOLICY - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userpolicy_id), + [XFRM_MSG_ALLOCSPI - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userspi_info), + [XFRM_MSG_ACQUIRE - XFRM_MSG_BASE] = XMSGSIZE(xfrm_user_acquire), + [XFRM_MSG_EXPIRE - XFRM_MSG_BASE] = XMSGSIZE(xfrm_user_expire), + [XFRM_MSG_UPDPOLICY - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userpolicy_info), + [XFRM_MSG_UPDSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_info), + [XFRM_MSG_POLEXPIRE - XFRM_MSG_BASE] = XMSGSIZE(xfrm_user_polexpire), + [XFRM_MSG_FLUSHSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_flush), + [XFRM_MSG_FLUSHPOLICY - XFRM_MSG_BASE] = NLMSG_LENGTH(0), }; +#undef XMSGSIZE + static struct xfrm_link { int (*doit)(struct sk_buff *, struct nlmsghdr *, void **); int (*dump)(struct sk_buff *, struct netlink_callback *); -} xfrm_dispatch[] = { - { .doit = xfrm_add_sa, }, - { .doit = xfrm_del_sa, }, - { - .doit = xfrm_get_sa, - .dump = xfrm_dump_sa, - }, - { .doit = xfrm_add_policy }, - { .doit = xfrm_get_policy }, - { - .doit = xfrm_get_policy, - .dump = xfrm_dump_policy, - }, - { .doit = xfrm_alloc_userspi }, - {}, - {}, - { .doit = xfrm_add_policy }, - { .doit = xfrm_add_sa, }, - {}, - { .doit = xfrm_flush_sa }, - { .doit = xfrm_flush_policy }, +} xfrm_dispatch[XFRM_NR_MSGTYPES] = { + [XFRM_MSG_NEWSA - XFRM_MSG_BASE] = { .doit = xfrm_add_sa }, + [XFRM_MSG_DELSA - XFRM_MSG_BASE] = { .doit = xfrm_del_sa }, + [XFRM_MSG_GETSA - XFRM_MSG_BASE] = { .doit = xfrm_get_sa, + .dump = xfrm_dump_sa }, + [XFRM_MSG_NEWPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_add_policy }, + [XFRM_MSG_DELPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_get_policy }, + [XFRM_MSG_GETPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_get_policy, + .dump = xfrm_dump_policy }, + [XFRM_MSG_ALLOCSPI - XFRM_MSG_BASE] = { .doit = xfrm_alloc_userspi }, + [XFRM_MSG_UPDPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_add_policy }, + [XFRM_MSG_UPDSA - XFRM_MSG_BASE] = { .doit = xfrm_add_sa }, + [XFRM_MSG_FLUSHSA - XFRM_MSG_BASE] = { .doit = xfrm_flush_sa }, + [XFRM_MSG_FLUSHPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_flush_policy }, }; static int xfrm_done(struct netlink_callback *cb) @@ -931,7 +928,9 @@ return -1; } - if ((type == 2 || type == 5) && (nlh->nlmsg_flags & NLM_F_DUMP)) { + if ((type == (XFRM_MSG_GETSA - XFRM_MSG_BASE) || + type == (XFRM_MSG_GETPOLICY - XFRM_MSG_BASE)) && + (nlh->nlmsg_flags & NLM_F_DUMP)) { u32 rlen; if (link->dump == NULL) From herbert@gondor.apana.org.au Sun May 1 16:10:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 16:10:51 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41NAU7J011026 for ; Sun, 1 May 2005 16:10:31 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSNYR-000292-00; Mon, 02 May 2005 09:08:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSNYJ-0004Il-00; Mon, 02 May 2005 09:08:43 +1000 Date: Mon, 2 May 2005 09:08:43 +1000 To: Jesper Juhl Cc: "David S. Miller" , Jouni Malinen , James Morris , Pedro Roque , Alexey Kuznetsov , Kunihiro Ishiguro , Mitsuru KANDA , lksctp-developers@lists.sourceforge.net, Andy Adamson , Bruce Fields , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] resource release cleanup in net/ Message-ID: <20050501230843.GA16518@gondor.apana.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 776 Lines: 19 On Sat, Apr 30, 2005 at 10:36:00PM +0200, Jesper Juhl wrote: > > Since Andrew merged the patch that makes calling crypto_free_tfm() with a > NULL pointer safe into 2.6.12-rc3-mm1, I made a patch to remove checks for > NULL before calling that function, and while I was at it I removed similar > redundant checks before calls to kfree() and vfree() in the same files. > There are also a few tiny whitespace cleanups in there. Hi Jesper: Could we wait until the crypto_free_tfm patch gets into the main tree? Most people here track that instead of mm. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From juhl-lkml@dif.dk Sun May 1 16:18:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 16:18:39 -0700 (PDT) Received: from saerimmer.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41NIa7J012046 for ; Sun, 1 May 2005 16:18:37 -0700 Received: from localhost (localhost [127.0.0.1]) by saerimmer.dif.dk (Postfix) with ESMTP id 28AF2FF410 for ; Mon, 2 May 2005 01:30:03 +0200 (CEST) Received: from saerimmer.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09349-05 for ; Mon, 2 May 2005 01:29:57 +0200 (CEST) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by saerimmer.dif.dk (Postfix) with ESMTP id 8063AFFC6E for ; Mon, 2 May 2005 01:29:54 +0200 (CEST) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Mon, 02 May 2005 01:16:52 +0200 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JVV1AQ3J; Mon, 2 May 2005 01:18:14 +0200 Date: Mon, 2 May 2005 01:21:50 +0200 (CEST) From: Jesper Juhl To: Herbert Xu Cc: "David S. Miller" , Jouni Malinen , James Morris , Pedro Roque , Alexey Kuznetsov , Kunihiro Ishiguro , Mitsuru KANDA , lksctp-developers@lists.sourceforge.net, Andy Adamson , Bruce Fields , YOSHIFUJI Hideaki , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] resource release cleanup in net/ In-Reply-To: <20050501230843.GA16518@gondor.apana.org.au> Message-ID: References: <20050501230843.GA16518@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at dif.dk X-Virus-Status: Clean X-archive-position: 516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev Content-Length: 747 Lines: 25 On Mon, 2 May 2005, Herbert Xu wrote: > On Sat, Apr 30, 2005 at 10:36:00PM +0200, Jesper Juhl wrote: > > > > Since Andrew merged the patch that makes calling crypto_free_tfm() with a > > NULL pointer safe into 2.6.12-rc3-mm1, I made a patch to remove checks for > > NULL before calling that function, and while I was at it I removed similar > > redundant checks before calls to kfree() and vfree() in the same files. > > There are also a few tiny whitespace cleanups in there. > > Hi Jesper: > > Could we wait until the crypto_free_tfm patch gets into the main tree? > Most people here track that instead of mm. > Sure. I don't have a problem with that. I'll just hold on to the patches and resend them at a later date. -- Jesper From bunk@stusta.de Sun May 1 18:47:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 18:47:43 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j421la7J020786 for ; Sun, 1 May 2005 18:47:37 -0700 Received: (qmail 31136 invoked from network); 2 May 2005 01:47:27 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 2 May 2005 01:47:27 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 96553BBA1B; Mon, 2 May 2005 03:47:26 +0200 (CEST) Date: Mon, 2 May 2005 03:47:26 +0200 From: Adrian Bunk To: Andrew Morton Cc: Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] drivers/net/arcnet/: possible cleanups Message-ID: <20050502014726.GH3592@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 5052 Lines: 161 This patch contains the following possible cleanups: - make needlessly global code static - arcnet.c: remove the outdated VERSION - arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null) - arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet) Signed-off-by: Adrian Bunk --- This patch was already sent on: - 15 Apr 2005 - 24 Mar 2005 drivers/net/arcnet/arc-rawmode.c | 2 +- drivers/net/arcnet/arcnet.c | 19 ++++++++++--------- drivers/net/arcnet/rfc1051.c | 2 +- drivers/net/arcnet/rfc1201.c | 3 +-- include/linux/arcdevice.h | 9 --------- 5 files changed, 13 insertions(+), 22 deletions(-) --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c.old 2005-02-16 15:16:38.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c 2005-02-16 15:16:51.000000000 +0100 @@ -42,7 +42,7 @@ static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum); -struct ArcProto rawmode_proto = +static struct ArcProto rawmode_proto = { .suffix = 'r', .mtu = XMTU, --- linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h.old 2005-02-16 15:17:26.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h 2005-02-16 15:20:57.000000000 +0100 @@ -206,7 +206,6 @@ extern struct ArcProto *arc_proto_map[256], *arc_proto_default, *arc_bcast_proto, *arc_raw_proto; -extern struct ArcProto arc_proto_null; /* @@ -334,17 +333,9 @@ #define arcnet_dump_skb(dev,skb,desc) ; #endif -#if (ARCNET_DEBUG_MAX & D_RX) || (ARCNET_DEBUG_MAX & D_TX) -void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc, - int take_arcnet_lock); -#else -#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) ; -#endif - void arcnet_unregister_proto(struct ArcProto *proto); irqreturn_t arcnet_interrupt(int irq, void *dev_id, struct pt_regs *regs); struct net_device *alloc_arcdev(char *name); -void arcnet_rx(struct net_device *dev, int bufnum); #endif /* __KERNEL__ */ #endif /* _LINUX_ARCDEVICE_H */ --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c.old 2005-02-16 15:17:47.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c 2005-02-16 15:21:20.000000000 +0100 @@ -41,8 +41,6 @@ * */ -#define VERSION "arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.\n" - #include #include #include @@ -61,6 +59,7 @@ static int null_prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum); +static void arcnet_rx(struct net_device *dev, int bufnum); /* * one ArcProto per possible proto ID. None of the elements of @@ -71,7 +70,7 @@ struct ArcProto *arc_proto_map[256], *arc_proto_default, *arc_bcast_proto, *arc_raw_proto; -struct ArcProto arc_proto_null = +static struct ArcProto arc_proto_null = { .suffix = '?', .mtu = XMTU, @@ -90,7 +89,6 @@ EXPORT_SYMBOL(arc_proto_default); EXPORT_SYMBOL(arc_bcast_proto); EXPORT_SYMBOL(arc_raw_proto); -EXPORT_SYMBOL(arc_proto_null); EXPORT_SYMBOL(arcnet_unregister_proto); EXPORT_SYMBOL(arcnet_debug); EXPORT_SYMBOL(alloc_arcdev); @@ -118,8 +116,8 @@ arcnet_debug = debug; - printk(VERSION); + printk("arcnet loaded.\n"); #ifdef ALPHA_WARNING BUGLVL(D_EXTRA) { printk("arcnet: ***\n" @@ -178,8 +174,8 @@ * Dump the contents of an ARCnet buffer */ #if (ARCNET_DEBUG_MAX & (D_RX | D_TX)) -void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc, - int take_arcnet_lock) +static void arcnet_dump_packet(struct net_device *dev, int bufnum, + char *desc, int take_arcnet_lock) { struct arcnet_local *lp = dev->priv; int i, length; @@ -208,7 +204,10 @@ } -EXPORT_SYMBOL(arcnet_dump_packet); +#else + +#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) do { } while (0) + #endif @@ -987,7 +986,7 @@ * This is a generic packet receiver that calls arcnet??_rx depending on the * protocol ID found. */ -void arcnet_rx(struct net_device *dev, int bufnum) +static void arcnet_rx(struct net_device *dev, int bufnum) { struct arcnet_local *lp = dev->priv; struct archdr pkt; --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c.old 2005-02-16 15:22:16.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c 2005-02-16 15:22:23.000000000 +0100 @@ -43,7 +43,7 @@ int bufnum); -struct ArcProto rfc1051_proto = +static struct ArcProto rfc1051_proto = { .suffix = 's', .mtu = XMTU - RFC1051_HDR_SIZE, --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1201.c.old 2005-02-16 15:22:35.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1201.c 2005-02-16 15:22:46.000000000 +0100 @@ -43,7 +43,7 @@ int bufnum); static int continue_tx(struct net_device *dev, int bufnum); -struct ArcProto rfc1201_proto = +static struct ArcProto rfc1201_proto = { .suffix = 'a', .mtu = 1500, /* could be more, but some receivers can't handle it... */ From nacc@us.ibm.com Sun May 1 23:15:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 23:15:11 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j426F17J032730 for ; Sun, 1 May 2005 23:15:07 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j426EoeE370080 for ; Mon, 2 May 2005 02:14:50 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j426Eoxj307560 for ; Mon, 2 May 2005 00:14:50 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j426EoQX022528 for ; Mon, 2 May 2005 00:14:50 -0600 Received: from joust (sig-9-49-132-50.mts.ibm.com [9.49.132.50]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j426Enoa022521; Mon, 2 May 2005 00:14:49 -0600 Received: by joust (Postfix, from userid 1000) id B83FF4F9FF; Sun, 1 May 2005 23:14:46 -0700 (PDT) Date: Sun, 1 May 2005 23:14:46 -0700 From: Nishanth Aravamudan To: philb@gnu.org Cc: netdev@oss.sgi.com, Kernel-Janitors Subject: [PATCH] net/3c505: replace schedule_timeout() with msleep() Message-ID: <20050502061446.GB10173@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux 2.6.12-rc3-mm2 (i686) User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1028 Lines: 27 Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan --- 2.6.12-rc3/drivers/net/3c505.c 2005-04-29 11:03:04.000000000 -0700 +++ 2.6.12-rc3-dev/drivers/net/3c505.c 2005-05-01 20:52:01.000000000 -0700 @@ -1317,8 +1317,7 @@ static int __init elp_sense(struct net_d if (orig_HSR & DIR) { /* If HCR.DIR is up, we pull it down. HSR.DIR should follow. */ outb(0, dev->base_addr + PORT_CONTROL); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(30*HZ/100); + msleep(300); if (inb_status(addr) & DIR) { if (elp_debug > 0) printk(notfound_msg, 2); @@ -1327,8 +1326,7 @@ static int __init elp_sense(struct net_d } else { /* If HCR.DIR is down, we pull it up. HSR.DIR should follow. */ outb(DIR, dev->base_addr + PORT_CONTROL); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(30*HZ/100); + msleep(300); if (!(inb_status(addr) & DIR)) { if (elp_debug > 0) printk(notfound_msg, 3); From nacc@us.ibm.com Sun May 1 23:35:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 23:35:25 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j426ZC7J001548 for ; Sun, 1 May 2005 23:35:14 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j426Z14I316888 for ; Mon, 2 May 2005 02:35:02 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j426Z1xj302036 for ; Mon, 2 May 2005 00:35:01 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j426Z1OS008521 for ; Mon, 2 May 2005 00:35:01 -0600 Received: from joust (sig-9-49-132-50.mts.ibm.com [9.49.132.50]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j426Z0Ns008432; Mon, 2 May 2005 00:35:00 -0600 Received: by joust (Postfix, from userid 1000) id E10324F9FF; Sun, 1 May 2005 23:34:57 -0700 (PDT) Date: Sun, 1 May 2005 23:34:57 -0700 From: Nishanth Aravamudan To: loz@holmes.demon.co.uk, waltje@uwalt.nl.mugnet.org.sgi.com Cc: netdev@oss.sgi.com, Kernel-Janitors Subject: [PATCH] net/slip: replace schedule_timeout() with msleep_interruptible() Message-ID: <20050502063457.GG10173@us.ibm.com> References: <20050502061446.GB10173@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050502061446.GB10173@us.ibm.com> X-Operating-System: Linux 2.6.12-rc3-mm2 (i686) User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 572 Lines: 18 Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. --- 2.6.12-rc3/drivers/net/slip.c 2005-03-01 23:38:33.000000000 -0800 +++ 2.6.12-rc3-dev/drivers/net/slip.c 2005-05-01 20:53:08.000000000 -0700 @@ -1395,10 +1395,8 @@ static void __exit slip_exit(void) /* First of all: check for active disciplines and hangup them. */ do { - if (busy) { - set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(HZ / 10); - } + if (busy) + msleep_interruptible(100); busy = 0; for (i = 0; i < slip_maxdev; i++) { From hadi@cyberus.ca Mon May 2 05:10:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 05:11:04 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42CAv7J025372 for ; Mon, 2 May 2005 05:10:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DSZl6-0006Ss-JV for netdev@oss.sgi.com; Mon, 02 May 2005 08:10:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DSZl3-0008Oc-7a; Mon, 02 May 2005 08:10:41 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050430235809.GI577@postel.suug.ch> References: <1114879817.8929.117.camel@localhost.localdomain> <4273BB30.1050402@trash.net> <4273BBAA.6060405@trash.net> <1114882045.8929.123.camel@localhost.localdomain> <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Mon, 02 May 2005 08:10:38 -0400 Message-Id: <1115035838.8929.236.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1601 Lines: 38 On Sun, 2005-01-05 at 01:58 +0200, Thomas Graf wrote: > * jamal <1114900485.8929.171.camel@localhost.localdomain> 2005-04-30 18:34 [..] > > Perhaps we can reuse classid by flagging somewhere? > > A good place to do it is tc_verdict. There a few bits still left. > > We could set a bit to say the meaning of classid to be global vs local. > > Sounds good to me, I'm not quite sure if I still have a good enough > picture of your action code. Let's assume we have ematches and an > action setting the classid at ingress. The action sets the above flag > to state the global scope. Which means the classid is not reset by exec(). > The packet passes the stack and the > classid gets copied into the new encapsulated packet. On the egress > device we have something like a nop action assigning the classid > to res->classid. How do we make sure that the classid remains > untouched even if the packet passes a dummy device in between having > actions configured? Can we we still have functional actions on > this dummy device? I would say that if dummy changes it because of a policy, then thats a fair deal. i.e filter blah blah \ action add meta classid global :23 I am beginning to think that perhaps classid should stay as a local scope metadata and what Patrick suggested maybe the way out. Although i have to admit I dont like a generic function to have a parameter that only a very small set of users find useful. If we are going to allow a structure to be passed back and forth, perhaps it should also carry other things (in addition to _result). Need to think a little. cheers, jamal From markb@wetlettuce.com Mon May 2 05:58:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 05:58:39 -0700 (PDT) Received: from piglet.wetlettuce.com (piglet.wetlettuce.com [82.68.149.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Cwa7J028503 for ; Mon, 2 May 2005 05:58:36 -0700 Received: from tigger.wetlettuce.com ([82.68.149.65] helo=tigger ident=Debian-exim) by piglet.wetlettuce.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 1DSaTh-0001tr-00; Mon, 02 May 2005 13:56:49 +0100 Received: from localhost ([127.0.0.1] ident=mark) by tigger with esmtp (Exim 4.50) id 1DSaTf-0003Ap-9E; Mon, 02 May 2005 13:56:47 +0100 Message-ID: <4276238E.4060606@wetlettuce.com> Date: Mon, 02 May 2005 13:56:46 +0100 From: Mark Broadbent User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sergey Vlasov CC: "David S. Miller" , Herbert Xu , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock References: <20050429093521.274adf9a.davem@davemloft.net> <20050429214336.04b40b3f.vsu@altlinux.ru> In-Reply-To: <20050429214336.04b40b3f.vsu@altlinux.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Wetlettuce-MailScanner: Mail is clear of Viree X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: markb@wetlettuce.com Precedence: bulk X-list: netdev Content-Length: 1973 Lines: 56 Sergey Vlasov wrote: > On Fri, 29 Apr 2005 09:35:21 -0700 David S. Miller wrote: > > >>Look at most interrupt handlers in the kernel, they use >>spin_lock_irqsave() rather consistently. If an interrupt >>is registered with SA_SHIRQ, this is a requirement. >>Here is why. >> >>On i386 (or any other platform using the generic IRQ layer), >>for example, unless you specify SA_INTERRUPT at >>request_irq() time, the handler dispatch is: >> >> local_irq_enable(); >> >> for each irq registered { >> x->handler(); >> } >> local_irq_disable(); >> >>(see kernel/irq/handle.c) >> >>At the top level from that handle_IRQ_event() function, the >>IRQ source is ACK'd after those calls. >> >>However, if you have multiple devices on that IRQ line, you >>run into a problem. Let's say TUlip interrupts first and >>we go into the Tulip driver and grab the lock, next the other >>device interrupts and we jump into the Tulip interrupt handler >>again, we will deadlock but what we should have done is use >>IRQ disabling spin locking like Mark's fix does. > > > If what you wrote above is really correct, this means that > Documentation/DocBook/kernel-locking.sgml contains wrong information: See Documentation/spin-locking.txt line 137, this states that spin_[un]lock() should not be used in IRQ handlers. >>>>The irq handler does not to use spin_lock_irq(), because the >>>>softirq cannot run while the irq handler is running: it can use >>>>spin_lock(), which is slightly faster. The only exception would >>>>be if a different hardware irq handler uses the same lock: >>>>spin_lock_irq() will stop that from interrupting us. > > > AFAIK, even if interrupts are enabled, the IRQ line which is currently > handled is disabled in the interrupt controller, therefore the > interrupt handler cannot be reentered (for the same device instance). > Did this really change? As far as I can tell this is the case (disclaimer applies) [see my other reply to Herbert Xu]. Thanks Mark From markb@wetlettuce.com Mon May 2 05:59:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 05:59:09 -0700 (PDT) Received: from piglet.wetlettuce.com (piglet.wetlettuce.com [82.68.149.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Cx67J028655 for ; Mon, 2 May 2005 05:59:07 -0700 Received: from tigger.wetlettuce.com ([82.68.149.65] helo=tigger ident=Debian-exim) by piglet.wetlettuce.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 1DSaUL-0001u0-00; Mon, 02 May 2005 13:57:29 +0100 Received: from localhost ([127.0.0.1] ident=mark) by tigger with esmtp (Exim 4.50) id 1DSaUK-0003BB-TF; Mon, 02 May 2005 13:57:29 +0100 Message-ID: <427623B8.8050107@wetlettuce.com> Date: Mon, 02 May 2005 13:57:28 +0100 From: Mark Broadbent User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> In-Reply-To: <20050429224931.GA18616@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Wetlettuce-MailScanner: Mail is clear of Viree X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: markb@wetlettuce.com Precedence: bulk X-list: netdev Content-Length: 1664 Lines: 48 Herbert Xu wrote: > On Fri, Apr 29, 2005 at 09:35:21AM -0700, David S. Miller wrote: > >>On i386 (or any other platform using the generic IRQ layer), >>for example, unless you specify SA_INTERRUPT at >>request_irq() time, the handler dispatch is: >> >> local_irq_enable(); > > > Yes you're absolutely correct. > > >>However, if you have multiple devices on that IRQ line, you >>run into a problem. Let's say TUlip interrupts first and >>we go into the Tulip driver and grab the lock, next the other >>device interrupts and we jump into the Tulip interrupt handler >>again, we will deadlock but what we should have done is use >>IRQ disabling spin locking like Mark's fix does. > > > However, I don't see how this can happen. __do_IRQ ensures > that the handlers on a single IRQ aren't reentered by desc->lock > and desc->status. Softirqs are also kept out by irq_enter. Am > I missing something? As far as I can see desc->lock is dropped before handle_IRQ_event() is called in __do_IRQ() (kernel/irq/handle.c:170) and desc->status does not prevent the execution of the IRQ handler. Same with softirqs, interrupts are enabled when the handler is called (kernel/softirq.c:89). Thanks Mark >>Therefore I think his patch is perfectly fine and this is an >>excellent area for an audit of the entire tree. I even just >>noticed recently that some of the Sparc drivers/serial/ >>drivers were not taking the interrupt handler lock correctly like >>this (ie. using irqsave). > > > Unless these drivers are registering two different IRQ lines that > can nest within each other, I still think that a plain spin_lock is > safe and desirable. > > Cheers, From jeroens@office.netland.nl Mon May 2 06:22:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 06:22:33 -0700 (PDT) Received: from services-04.netland.nl (mx1.netland.nl [217.170.32.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42DMT7J030384 for ; Mon, 2 May 2005 06:22:29 -0700 Received: from n010095.nbs.netland.nl (fw.office.netland.nl [217.170.32.40]) by services-04.netland.nl (Postfix) with ESMTP id 4A0E45400B for ; Mon, 2 May 2005 15:22:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by n010095.nbs.netland.nl (Postfix) with ESMTP id 0858EA4EC for ; Mon, 2 May 2005 15:22:18 +0200 (CEST) Received: from n010095.nbs.netland.nl ([127.0.0.1]) by localhost (n010095.nbs.netland.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19927-03-4 for ; Mon, 2 May 2005 15:22:17 +0200 (CEST) Received: from jeroens.office.netland.nl (jeroens.office.netland.nl [192.168.170.25]) by n010095.nbs.netland.nl (Postfix) with ESMTP id 1B7F2A4EA for ; Mon, 2 May 2005 15:22:17 +0200 (CEST) Subject: icmp_unreachable uses wrong ip From: "J. Simonetti" To: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-Q2xJWlJ7VlmjEMgXdZYq" Organization: Netland Internet Services Date: Mon, 02 May 2005 15:21:19 +0200 Message-Id: <1115040079.5620.11.camel@jeroens.office.netland.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at n010095.nbs.netland.nl X-Virus-Status: Clean X-archive-position: 534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeroens@office.netland.nl Precedence: bulk X-list: netdev Content-Length: 1252 Lines: 40 --=-Q2xJWlJ7VlmjEMgXdZYq Content-Type: text/plain Content-Transfer-Encoding: 7bit I've recently come to notice that traceroutes through a linux router use the wrong ip (ip of exitting interface) wich should actually be the ip of the incomming interface. I've found a trivial patch (attached) wich resolves this. Perhaps this is something to include (or have a sysctl to toggle this behaviour). I unfortunately have no knowledge of programming, so the sysctl option would have te be done by a volunteer. Regards, Jeroen Simonetti -- Netland Internet Services http://www.netland.nl I despise the pleasure of pleasing people whom I despise. --=-Q2xJWlJ7VlmjEMgXdZYq Content-Disposition: attachment; filename=icmp_traceroute.patch Content-Type: text/x-patch; name=icmp_traceroute.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- net/ipv4/icmp.orig 2005-05-02 04:55:53.512447464 +0200 +++ net/ipv4/icmp.c 2005-05-02 04:56:21.370212440 +0200 @@ -512,7 +512,7 @@ saddr = iph->daddr; if (!(rt->rt_flags & RTCF_LOCAL)) - saddr = 0; + saddr = inet_select_addr(skb_in->dev, 0, RT_SCOPE_LINK); tos = icmp_pointers[type].error ? ((iph->tos & IPTOS_TOS_MASK) | IPTOS_PREC_INTERNETCONTROL) : --=-Q2xJWlJ7VlmjEMgXdZYq-- From hasso@estpak.ee Mon May 2 06:59:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 06:59:23 -0700 (PDT) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42DxK7J032643 for ; Mon, 2 May 2005 06:59:21 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSbRy-0001Ad-FQ; Mon, 02 May 2005 16:59:06 +0300 From: Hasso Tepper To: "J. Simonetti" Subject: Re: icmp_unreachable uses wrong ip Date: Mon, 2 May 2005 16:59:05 +0300 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> In-Reply-To: <1115040079.5620.11.camel@jeroens.office.netland.nl> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_pIjdCRH/C+iyHjz" Message-Id: <200505021659.05674.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 3797 Lines: 102 --Boundary-00=_pIjdCRH/C+iyHjz Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline J. Simonetti wrote: > I've recently come to notice that traceroutes through a linux router use > the wrong ip (ip of exitting interface) wich should actually be the ip > of the incomming interface. There is nothing _wrong_ with this behaviour. Linux just behaves this way. > I've found a trivial patch (attached) wich resolves this. Perhaps this > is something to include (or have a sysctl to toggle this behaviour). I > unfortunately have no knowledge of programming, so the sysctl option > would have te be done by a volunteer. Similar patches have been posted to the list repeatedly AFAIK with no any response from developers. Can someone enlighten us why? Is there something wrong with it? This is the feature people administrating routers would like to have. It makes debugging complicated topologies much easier and all routers I have seen behave this way. I'm attaching patch which was posted to the list some time ago. I'm using it for some time already. I can't find the post from the archive though at the moment. -- Hasso Tepper Elion Enterprises Ltd. WAN administrator --Boundary-00=_pIjdCRH/C+iyHjz Content-Type: text/x-diff; charset="iso-8859-6"; name="linux-2.4.26-icmperrors.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.4.26-icmperrors.patch" diff -ru linux-2.4.26/include/linux/sysctl.h linux-2.4.26-icmperrors/include/linux/sysctl.h --- linux-2.4.26/include/linux/sysctl.h 2004-04-14 14:05:40.000000000 +0100 +++ linux-2.4.26-icmperrors/include/linux/sysctl.h 2004-09-23 22:52:16.000000000 +0100 @@ -314,6 +314,7 @@ NET_IPV4_IPFRAG_SECRET_INTERVAL=94, NET_TCP_WESTWOOD=95, NET_IPV4_IGMP_MAX_MSF=96, + NET_IPV4_ICMP_ERRORS_USE_INBOUND_IFADDR=97, }; enum { diff -ru linux-2.4.26/net/ipv4/icmp.c linux-2.4.26-icmperrors/net/ipv4/icmp.c --- linux-2.4.26/net/ipv4/icmp.c 2004-04-14 14:05:41.000000000 +0100 +++ linux-2.4.26-icmperrors/net/ipv4/icmp.c 2004-09-23 22:52:38.000000000 +0100 @@ -162,6 +162,7 @@ int sysctl_icmp_ratelimit = 1*HZ; int sysctl_icmp_ratemask = 0x1818; +int sysctl_icmp_errors_use_inbound_ifaddr = 0; /* * ICMP control array. This specifies what to do with each ICMP. @@ -452,8 +453,12 @@ #endif saddr = iph->daddr; - if (!(rt->rt_flags & RTCF_LOCAL)) - saddr = 0; + if (!(rt->rt_flags & RTCF_LOCAL)) { + if(sysctl_icmp_errors_use_inbound_ifaddr) + saddr = inet_select_addr(skb_in->dev, 0, RT_SCOPE_LINK); + else + saddr = 0; + } tos = icmp_pointers[type].error ? ((iph->tos & IPTOS_TOS_MASK) | IPTOS_PREC_INTERNETCONTROL) : diff -ru linux-2.4.26/net/ipv4/sysctl_net_ipv4.c linux-2.4.26-icmperrors/net/ipv4/sysctl_net_ipv4.c --- linux-2.4.26/net/ipv4/sysctl_net_ipv4.c 2004-04-14 14:05:41.000000000 +0100 +++ linux-2.4.26-icmperrors/net/ipv4/sysctl_net_ipv4.c 2004-09-23 22:53:07.000000000 +0100 @@ -22,6 +22,7 @@ extern int sysctl_icmp_echo_ignore_all; extern int sysctl_icmp_echo_ignore_broadcasts; extern int sysctl_icmp_ignore_bogus_error_responses; +extern int sysctl_icmp_errors_use_inbound_ifaddr; /* From ip_fragment.c */ extern int sysctl_ipfrag_low_thresh; @@ -181,6 +182,9 @@ {NET_IPV4_ICMP_IGNORE_BOGUS_ERROR_RESPONSES, "icmp_ignore_bogus_error_responses", &sysctl_icmp_ignore_bogus_error_responses, sizeof(int), 0644, NULL, &proc_dointvec}, + {NET_IPV4_ICMP_ERRORS_USE_INBOUND_IFADDR, "icmp_errors_use_inbound_ifaddr", + &sysctl_icmp_errors_use_inbound_ifaddr, sizeof(int), 0644, NULL, + &proc_dointvec}, {NET_IPV4_ROUTE, "route", NULL, 0, 0555, ipv4_route_table}, #ifdef CONFIG_IP_MULTICAST {NET_IPV4_IGMP_MAX_MEMBERSHIPS, "igmp_max_memberships", --Boundary-00=_pIjdCRH/C+iyHjz-- From pmarques@grupopie.com Mon May 2 07:16:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 07:16:44 -0700 (PDT) Received: from bipbip.comserver-pie.com ([195.23.16.24]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42EGV7J001668 for ; Mon, 2 May 2005 07:16:37 -0700 Received: from bipbip.comserver-pie.com (localhost [127.0.0.1]) by VAMS.dummy (Postfix) with SMTP id 8460E26B139; Mon, 2 May 2005 15:12:36 +0100 (WEST) Received: from [192.168.0.198] (195-23-20-139.net.novis.pt [195.23.20.139]) by bipbip.comserver-pie.com (Postfix) with ESMTP id 9521F26B139; Mon, 2 May 2005 15:12:33 +0100 (WEST) Message-ID: <4276362B.1010004@grupopie.com> Date: Mon, 02 May 2005 15:16:11 +0100 From: Paulo Marques Organization: Grupo PIE User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Broadbent Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pmarques@grupopie.com Precedence: bulk X-list: netdev Content-Length: 614 Lines: 17 Mark Broadbent wrote: > The interrupt handling code in the tulip network driver appears to use a non > IRQ safe spinlock in an interrupt context. The following patch should correct > this. Huh? Can a network interrupt handler be interrupted by the same interrupt? AFAIK, the spin_lock_irqsave is to disable interruptions so that an interrupt can not happen in the critical section, so that the interrupt handler can not make modifications to shared data. Am I wrong? -- Paulo Marques - www.grupopie.com All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) From kaber@trash.net Mon May 2 07:52:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 07:52:20 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42EqI7J003659 for ; Mon, 2 May 2005 07:52:18 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DScHG-0000wu-EL; Mon, 02 May 2005 16:52:06 +0200 Message-ID: <42763E96.1070209@trash.net> Date: Mon, 02 May 2005 16:52:06 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Hasso Tepper CC: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505021659.05674.hasso@estpak.ee> In-Reply-To: <200505021659.05674.hasso@estpak.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 452 Lines: 11 Hasso Tepper wrote: > Similar patches have been posted to the list repeatedly AFAIK with no any > response from developers. Can someone enlighten us why? Is there something > wrong with it? This is the feature people administrating routers would like > to have. It makes debugging complicated topologies much easier and all > routers I have seen behave this way. Why can't you simply add the prefered source address to the route? Regards Patrick From tgraf@suug.ch Mon May 2 08:06:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 08:06:27 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42F6L7J004705 for ; Mon, 2 May 2005 08:06:22 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id CE4031C0EB; Mon, 2 May 2005 17:06:32 +0200 (CEST) Date: Mon, 2 May 2005 17:06:32 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050502150632.GM577@postel.suug.ch> References: <4273BBAA.6060405@trash.net> <1114882045.8929.123.camel@localhost.localdomain> <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115035838.8929.236.camel@localhost.localdomain> X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1162 Lines: 23 * jamal <1115035838.8929.236.camel@localhost.localdomain> 2005-05-02 08:10 > I would say that if dummy changes it because of a policy, then thats a > fair deal. i.e > > filter blah blah \ > action add meta classid global :23 Absolutely, given it is requested by the user. My main concern are dependencies on classid invisble to the user. > I am beginning to think that perhaps classid should stay as a local > scope metadata and what Patrick suggested maybe the way out. Although i > have to admit I dont like a generic function to have a parameter that > only a very small set of users find useful. If we are going to allow a > structure to be passed back and forth, perhaps it should also carry > other things (in addition to _result). Need to think a little. What about if we introduce something like struct tcf_pkt_info as we have it for ematches? I'm using it intensly to share information from the classifier to ematches to extend and customize existing classifier. We could declare tc_classid as being global by definition and hide the current use in the API? I'd really like to be able to transfer classification results from one device to another. From kaber@trash.net Mon May 2 09:13:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 09:13:12 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42GD87J011655 for ; Mon, 2 May 2005 09:13:09 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DSdXL-0007Y5-43; Mon, 02 May 2005 18:12:47 +0200 Message-ID: <4276517F.6030606@trash.net> Date: Mon, 02 May 2005 18:12:47 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Andrew Morton , "David S. Miller" Subject: Re: CONFIG_NETFILTER_DEBUG spew References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> In-Reply-To: <20050501111507.GA2133@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------070605040806010003070303" X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1989 Lines: 59 This is a multi-part message in MIME format. --------------070605040806010003070303 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Herbert Xu wrote: > BTW, should we do nf_reset in ip_dev_loopback_xmit as well? I think we should, tc actions could do something unexpected with the packet. Regards Patrick --------------070605040806010003070303 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" [NETFILTER]: Drop conntrack reference in ip_dev_loopback_xmit() Signed-off-by: Patrick McHardy --- commit c4644e58c8b52dca9699e8ee0e975f5f13eb4d2c tree 35d8915a3fd6fa39a46d9b2e8e1fd272e82ea3af parent a91b6fa8bc4b1626d413d58c21cfcfecabbb4a61 author Patrick McHardy 1115049922 +0200 committer Patrick McHardy 1115049922 +0200 Index: net/core/netfilter.c =================================================================== --- 9544bb88b28c2e3ca4b0a66fedfa2bb540ec06e2/net/core/netfilter.c (mode:100644 sha1:92c51824797dd15018e579eb5753cc372e04fd3d) +++ 35d8915a3fd6fa39a46d9b2e8e1fd272e82ea3af/net/core/netfilter.c (mode:100644 sha1:22a8f127c4aad9821e5f3294aa518807165ee8b7) @@ -236,8 +236,6 @@ debug_print_hooks_ip(newskb->nf_debug); nf_dump_skb(PF_INET, newskb); } - /* Clear to avoid confusing input check */ - newskb->nf_debug = 0; } void nf_debug_ip_finish_output2(struct sk_buff *skb) Index: net/ipv4/ip_output.c =================================================================== --- 9544bb88b28c2e3ca4b0a66fedfa2bb540ec06e2/net/ipv4/ip_output.c (mode:100644 sha1:38f69532a029e5ff1ddbdbd665afcff46e94abb5) +++ 35d8915a3fd6fa39a46d9b2e8e1fd272e82ea3af/net/ipv4/ip_output.c (mode:100644 sha1:24fe3e00b42b0bb673be5a6d8ceb15defb192974) @@ -111,6 +111,7 @@ #ifdef CONFIG_NETFILTER_DEBUG nf_debug_ip_loopback_xmit(newskb); #endif + nf_reset(newskb); netif_rx(newskb); return 0; } --------------070605040806010003070303-- From Yair@arx.com Mon May 2 09:17:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 09:18:03 -0700 (PDT) Received: from post.arx.com (post.arx.com [212.25.66.95]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42GHv7J012325 for ; Mon, 2 May 2005 09:17:59 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Re-routing packets via netfilter (ip_rt_bug) Date: Mon, 2 May 2005 19:17:16 +0200 Message-ID: <4151C0F9B9C25C47B3328922A6297A3286CFB8@post.arx.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-routing packets via netfilter (ip_rt_bug) Thread-Index: AcVLKiK78AJdzKpmRxyqorAryLrbSgD3ejng From: "Yair Itzhaki" To: "Patrick McHardy" , "Herbert Xu" Cc: "Jozsef Kadlecsik" , , , X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j42GHv7J012325 X-archive-position: 540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Yair@arx.com Precedence: bulk X-list: netdev Content-Length: 1952 Lines: 53 Can anyone propose a patch that I can start checking? I have come up with the following: --- net/core/netfilter.c.orig 2005-04-18 21:55:30.000000000 +0300 +++ net/core/netfilter.c 2005-05-02 17:35:20.000000000 +0300 @@ -622,9 +622,10 @@ /* some non-standard hacks like ipt_REJECT.c:send_reset() can cause * packets with foreign saddr to appear on the NF_IP_LOCAL_OUT hook. */ - if (inet_addr_type(iph->saddr) == RTN_LOCAL) { + if ((inet_addr_type(iph->saddr) == RTN_LOCAL) || + (inet_addr_type(iph->daddr) == RTN_LOCAL)) { fl.nl_u.ip4_u.daddr = iph->daddr; - fl.nl_u.ip4_u.saddr = iph->saddr; + fl.nl_u.ip4_u.saddr = 0; fl.nl_u.ip4_u.tos = RT_TOS(iph->tos); fl.oif = (*pskb)->sk ? (*pskb)->sk->sk_bound_dev_if : 0; #ifdef CONFIG_IP_ROUTE_FWMARK Please advise, Yair > -----Original Message----- > From: Patrick McHardy [mailto:kaber@trash.net] > Sent: Wednesday, April 27, 2005 14:05 > To: Herbert Xu > Cc: Jozsef Kadlecsik; netdev@oss.sgi.com; > netfilter-devel@lists.netfilter.org; Yair Itzhaki; > linux-kernel@vger.kernel.org > Subject: Re: Re-routing packets via netfilter (ip_rt_bug) > > > Herbert Xu wrote: > > Here is another reason why these packets should go through FORWARD. > > They were generated in response to packets in INPUT/FORWARD/OUTPUT. > > The original packet has not undergone SNAT in any of these cases. > > > > However, if we feed the response packet through LOCAL_OUT it will > > be subject to DNAT. This creates a NAT asymmetry and we may end > > up with the wrong destination address. > > > > By pushing it through FORWARD it will only undergo SNAT which is > > correct since the original packet would have undergone DNAT. > > This is only a problem since the recent NAT changes, but I agree > that we should fix it by moving these packets to FORWARD. > > Regards > Patrick > From hasso@estpak.ee Mon May 2 10:38:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 10:38:39 -0700 (PDT) Received: from arena.estpak.ee (dream.estpak.ee [194.126.115.147]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Hca7J017603 for ; Mon, 2 May 2005 10:38:36 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSesA-0000nG-MB; Mon, 02 May 2005 20:38:22 +0300 From: Hasso Tepper To: Patrick McHardy Subject: Re: icmp_unreachable uses wrong ip Date: Mon, 2 May 2005 20:38:21 +0300 User-Agent: KMail/1.8 Cc: "J. Simonetti" , netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505021659.05674.hasso@estpak.ee> <42763E96.1070209@trash.net> In-Reply-To: <42763E96.1070209@trash.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200505022038.22014.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j42Hca7J017603 X-archive-position: 547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 910 Lines: 20 Patrick McHardy wrote: > Hasso Tepper wrote: > > Similar patches have been posted to the list repeatedly AFAIK with no > > any response from developers. Can someone enlighten us why? Is there > > something wrong with it? This is the feature people administrating > > routers would like to have. It makes debugging complicated topologies > > much easier and all routers I have seen behave this way. > > Why can't you simply add the prefered source address to the route? Because I don't know what it is. Router A knows what's the best path from router A to router B, but he can't know (at least in cases where there are more than 1 path between them) what's the best path from router B to router A. Therefore you canät say which one is incoming interface in router A for traffic from router B. And even if you know it in some moment, topology might change in next moment (dynamic routing) etc. -- Hasso From mkomu@twilight.cs.hut.fi Mon May 2 11:39:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 11:39:38 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42IdX7J023127 for ; Mon, 2 May 2005 11:39:34 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 69F5E2E65; Mon, 2 May 2005 21:39:22 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id B77232DE8 for ; Mon, 2 May 2005 21:39:20 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j42IdKv27517; Mon, 2 May 2005 21:39:20 +0300 (EEST) Date: Mon, 2 May 2005 21:39:20 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: netdev@oss.sgi.com Subject: IPsec performance Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 700 Lines: 21 Hi folks, I compared TCP-over-NULL-ESP vs. plain-TCP throughput with "ttcp" tool and obtained the following results: Plain-TCP: 11 megabytes/s NULL-ESP: 2.5 megabytes/s Am I doing something wrong? I did the measurements by transferring a 100 megabyte file using vanilla 2.6.7 kernel and IPv6. Seems like my results are inconsistent at least with measurements published by Linux Journal: http://www.linuxjournal.com/article/7840 The main differences with the Linux Journal measurements are that I used a significantly larger filesize and IPv6. So, I tried to run the same with IPv4 and got similar results... any ideas? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From mkomu@twilight.cs.hut.fi Mon May 2 12:09:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 12:09:29 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42J9H7J024322 for ; Mon, 2 May 2005 12:09:17 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id EA58A2E68; Mon, 2 May 2005 22:09:03 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 4B3EB2DDA for ; Mon, 2 May 2005 22:09:02 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j42J92929691; Mon, 2 May 2005 22:09:02 +0300 (EEST) Date: Mon, 2 May 2005 22:09:02 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: netdev@oss.sgi.com Subject: Re: IPsec performance In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 910 Lines: 29 On Mon, 2 May 2005, Miika Komu wrote: > Hi folks, > > I compared TCP-over-NULL-ESP vs. plain-TCP throughput with "ttcp" tool and > obtained the following results: > > Plain-TCP: 11 megabytes/s > NULL-ESP: 2.5 megabytes/s > > Am I doing something wrong? I did the measurements by transferring a 100 > megabyte file using vanilla 2.6.7 kernel and IPv6. Seems like my > results are inconsistent at least with measurements published by Linux > Journal: > > http://www.linuxjournal.com/article/7840 > > The main differences with the Linux Journal measurements are that I used a > significantly larger filesize and IPv6. So, I tried to run the same with > IPv4 and got similar results... any ideas? I browsed the archives also and found this one: http://oss.sgi.com/archives/netdev/2004-12/msg00801.html Nothing has been done for this? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From herbert@gondor.apana.org.au Mon May 2 14:29:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:29:16 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42LT77J006499 for ; Mon, 2 May 2005 14:29:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSiSo-0007xm-00; Tue, 03 May 2005 07:28:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSiSh-0004DD-00; Tue, 03 May 2005 07:28:19 +1000 Date: Tue, 3 May 2005 07:28:19 +1000 To: Mark Broadbent Cc: Sergey Vlasov , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050502212819.GA16177@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429214336.04b40b3f.vsu@altlinux.ru> <4276238E.4060606@wetlettuce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4276238E.4060606@wetlettuce.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 615 Lines: 15 On Mon, May 02, 2005 at 01:56:46PM +0100, Mark Broadbent wrote: > > > If what you wrote above is really correct, this means that > > Documentation/DocBook/kernel-locking.sgml contains wrong information: > > See Documentation/spin-locking.txt line 137, this states that > spin_[un]lock() should not be used in IRQ handlers. Line 137 in my spin-locking.txt is a blank line :) Please quote the exact text. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon May 2 14:31:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:31:31 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42LVQ7J006778 for ; Mon, 2 May 2005 14:31:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSiVR-0007yH-00; Tue, 03 May 2005 07:31:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSiVQ-0004Dl-00; Tue, 03 May 2005 07:31:08 +1000 Date: Tue, 3 May 2005 07:31:08 +1000 To: Mark Broadbent Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050502213108.GB16177@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> <427623B8.8050107@wetlettuce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427623B8.8050107@wetlettuce.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1032 Lines: 25 On Mon, May 02, 2005 at 01:57:28PM +0100, Mark Broadbent wrote: > > > However, I don't see how this can happen. __do_IRQ ensures > > that the handlers on a single IRQ aren't reentered by desc->lock > > and desc->status. Softirqs are also kept out by irq_enter. Am > > I missing something? > > As far as I can see desc->lock is dropped before handle_IRQ_event() is > called in __do_IRQ() (kernel/irq/handle.c:170) and desc->status does not > prevent the execution of the IRQ handler. Same with softirqs, desc->status is set to IRQ_INPROGRESS (kernel/irq/handle.c:144) which prevents the same IRQ handlers from being invoked again (kernel/irq/handle.c:141). > interrupts are enabled when the handler is called (kernel/softirq.c:89). Soft IRQs do not run when we're in an IRQ handler (kernel/softirq.c:121). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon May 2 14:32:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:32:42 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42LWc7J007152 for ; Mon, 2 May 2005 14:32:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSiWb-0007yW-00; Tue, 03 May 2005 07:32:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSiWa-0004E7-00; Tue, 03 May 2005 07:32:20 +1000 Date: Tue, 3 May 2005 07:32:20 +1000 To: "David S. Miller" Cc: Mark Broadbent , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050502213220.GC16177@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> <427623B8.8050107@wetlettuce.com> <20050502124358.7186447f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050502124358.7186447f.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 730 Lines: 18 On Mon, May 02, 2005 at 12:43:58PM -0700, David S. Miller wrote: > > Now, a seperate issue. If we wish to disable IRQs at all for another > reason (say to make the critical section not get interrupted by timers > or some other device's handler) than we must use _irqsave/_irqrestore > instead of _irq because there is no guarentee whether IRQs are disabled > upon entry to an IRQ handler or not. The SA_INTERRUPT behavior is not Agreed. However, AFAIK the tulip driver doesn't care about other interrupts. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon May 2 14:36:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:36:56 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Lap7J008314 for ; Mon, 2 May 2005 14:36:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSiaN-00080a-00; Tue, 03 May 2005 07:36:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSiaK-0004En-00; Tue, 03 May 2005 07:36:12 +1000 Date: Tue, 3 May 2005 07:36:12 +1000 To: Patrick McHardy Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Andrew Morton , "David S. Miller" Subject: Re: CONFIG_NETFILTER_DEBUG spew Message-ID: <20050502213612.GD16177@gondor.apana.org.au> References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> <4276517F.6030606@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4276517F.6030606@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 479 Lines: 13 On Mon, May 02, 2005 at 06:12:47PM +0200, Patrick McHardy wrote: > Herbert Xu wrote: > > BTW, should we do nf_reset in ip_dev_loopback_xmit as well? > > I think we should, tc actions could do something unexpected with > the packet. Looks good to me. Thanks Patrick. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Mon May 2 14:43:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:43:58 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Lhu7J009092 for ; Mon, 2 May 2005 14:43:56 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DSiWm-00018L-00; Mon, 02 May 2005 14:32:32 -0700 Date: Mon, 2 May 2005 14:32:32 -0700 From: "David S. Miller" To: Herbert Xu Cc: markb@wetlettuce.com, netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-Id: <20050502143232.1dbec2d6.davem@davemloft.net> In-Reply-To: <20050502213220.GC16177@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> <427623B8.8050107@wetlettuce.com> <20050502124358.7186447f.davem@davemloft.net> <20050502213220.GC16177@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 298 Lines: 9 On Tue, 3 May 2005 07:32:20 +1000 Herbert Xu wrote: > However, AFAIK the tulip driver doesn't care about other interrupts. Even the netdev watchdog? :-) tulip_tx_timeout takes the tp->lock. Therefore it seems that Mark's patch is correct _and_ needed, after all. From herbert@gondor.apana.org.au Mon May 2 14:46:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:46:12 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Lk77J009572 for ; Mon, 2 May 2005 14:46:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSijc-0008GJ-00; Tue, 03 May 2005 07:45:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSijZ-0003VR-00; Tue, 03 May 2005 07:45:45 +1000 Date: Tue, 3 May 2005 07:45:45 +1000 To: "David S. Miller" Cc: markb@wetlettuce.com, netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050502214545.GA13462@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> <427623B8.8050107@wetlettuce.com> <20050502124358.7186447f.davem@davemloft.net> <20050502213220.GC16177@gondor.apana.org.au> <20050502143232.1dbec2d6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050502143232.1dbec2d6.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 563 Lines: 15 On Mon, May 02, 2005 at 02:32:32PM -0700, David S. Miller wrote: > On Tue, 3 May 2005 07:32:20 +1000 > Herbert Xu wrote: > > > However, AFAIK the tulip driver doesn't care about other interrupts. > > Even the netdev watchdog? :-) The watchdog runs in softirq context which is disabled while the IRQ handler is running. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Mon May 2 15:05:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 15:05:04 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42M507J010811 for ; Mon, 2 May 2005 15:05:00 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DSj20-0006fH-70; Tue, 03 May 2005 00:04:48 +0200 Message-ID: <4276A400.2050306@trash.net> Date: Tue, 03 May 2005 00:04:48 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Hasso Tepper CC: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505021659.05674.hasso@estpak.ee> <42763E96.1070209@trash.net> <200505022038.22014.hasso@estpak.ee> In-Reply-To: <200505022038.22014.hasso@estpak.ee> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/863/Mon May 2 09:32:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 860 Lines: 19 Hasso Tepper wrote: > Patrick McHardy wrote: > >>Why can't you simply add the prefered source address to the route? > > Because I don't know what it is. Router A knows what's the best path from > router A to router B, but he can't know (at least in cases where there are > more than 1 path between them) what's the best path from router B to router > A. Therefore you canät say which one is incoming interface in router A for > traffic from router B. And even if you know it in some moment, topology > might change in next moment (dynamic routing) etc. Your patch can't guarantee that the address used is the same that was used as nexthop by the previous hop in the path when multiple addresses are configured on the incoming interface. So I don't think it achieves much of your goal of making debugging complicated topologies easier. Regards Patrick From shemminger@osdl.org Mon May 2 16:24:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 16:24:31 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42NOK7J019388 for ; Mon, 2 May 2005 16:24:20 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j42NO4s4018814 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 May 2005 16:24:04 -0700 Received: from localhost.localdomain (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j42NO45m027059; Mon, 2 May 2005 16:24:04 -0700 Date: Mon, 2 May 2005 16:24:05 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: Mystery packet killing tg3 Message-ID: <20050502162405.65dfb4a9@localhost.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/864/Mon May 2 14:10:35 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 518 Lines: 11 While I was on vacation, OSDL did some networking changes that seems to aggravate some existing bug in the tg3 driver. Could be some VLAN related garbage, not sure. System is 2 CPU AMD64 and the tg3 is on the motherboard. I am seeing messages like: eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:53:08:18 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 Any clues? From kaber@trash.net Mon May 2 17:55:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 17:55:32 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j430tR7J023626 for ; Mon, 2 May 2005 17:55:30 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DSlgy-0006zD-AD; Tue, 03 May 2005 02:55:16 +0200 Date: Tue, 3 May 2005 02:55:16 +0200 (CEST) From: Patrick McHardy X-X-Sender: kaber@kaber.coreworks.de To: Miika Komu cc: netdev@oss.sgi.com Subject: Re: IPsec performance In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 524 Lines: 18 On Mon, 2 May 2005, Miika Komu wrote: >> I compared TCP-over-NULL-ESP vs. plain-TCP throughput with "ttcp" tool and >> obtained the following results: >> >> Plain-TCP: 11 megabytes/s >> NULL-ESP: 2.5 megabytes/s >> > I browsed the archives also and found this one: > > http://oss.sgi.com/archives/netdev/2004-12/msg00801.html null encryption uses a block size of 1, which causes inefficent handling of the data. I'm unsure if some hack for this specific case is worth it since its only meant for testing. Regards Patrick From akepner@sgi.com Mon May 2 18:13:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 18:13:11 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j431D67J024487 for ; Mon, 2 May 2005 18:13:06 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j432tFOG007406 for ; Mon, 2 May 2005 19:55:15 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j431BtbT64893084 for ; Mon, 2 May 2005 18:11:55 -0700 (PDT) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-189.corp.sgi.com [134.15.0.189]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j431As5x20790926; Mon, 2 May 2005 18:10:54 -0700 (PDT) Date: Mon, 2 May 2005 18:09:26 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Leonid Grossman , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com cc: netdev@oss.sgi.com Subject: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() In-Reply-To: <200504051836.j35IanDD005402@guinness.s2io.com> Message-ID: References: <200504051836.j35IanDD005402@guinness.s2io.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 1170 Lines: 32 The neterion 10gige driver uses a readq() to flush some PIO writes in s2io_xmit(). Using mmiowb() can, in some cases, reduce CPU utilization, and/or allow higher throughput. This is particularly true when TSO is off, and small MTUs are in use. For example, in one test measurement I just did with 2.6.12-rc2 on an Altix, MTUs were set to 1500 bytes and TSO turned off. With this patch, transmit throughput improved by ~20%. Throughput was ultimately bound by the CPU with or without the patch. With large MTUs (9600 bytes) or with TSO turned on, there was no significant change to throughput or CPU utilization. Signed-off-by: Arthur Kepner --- linux.orig/drivers/net/s2io.c 2005-05-02 16:40:17.469733509 -0700 +++ linux/drivers/net/s2io.c 2005-05-02 16:40:25.001043632 -0700 @@ -2759,8 +2759,8 @@ static int s2io_xmit(struct sk_buff *skb #endif writeq(val64, &tx_fifo->List_Control); - /* Perform a PCI read to flush previous writes */ - val64 = readq(&bar0->general_int_status); + /* Perform a mmiowb() to order previous writes */ + mmiowb(); put_off++; put_off %= mac_control->tx_curr_put_info[queue].fifo_len + 1; -- Arthur From anton@ozlabs.org Mon May 2 18:44:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 18:44:41 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j431ic7J027026 for ; Mon, 2 May 2005 18:44:39 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 89280679FD; Tue, 3 May 2005 11:44:26 +1000 (EST) Date: Tue, 3 May 2005 11:40:34 +1000 From: Anton Blanchard To: Arthur Kepner Cc: Leonid Grossman , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Message-ID: <20050503014034.GC12682@krispykreme> References: <200504051836.j35IanDD005402@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 1351 Lines: 38 Hi, > The neterion 10gige driver uses a readq() to flush some PIO writes > in s2io_xmit(). Using mmiowb() can, in some cases, reduce CPU > utilization, and/or allow higher throughput. This is particularly > true when TSO is off, and small MTUs are in use. > > For example, in one test measurement I just did with 2.6.12-rc2 > on an Altix, MTUs were set to 1500 bytes and TSO turned off. > With this patch, transmit throughput improved by ~20%. Throughput > was ultimately bound by the CPU with or without the patch. With > large MTUs (9600 bytes) or with TSO turned on, there was no > significant change to throughput or CPU utilization. I didnt know mmiowb is supposed to be a replacement for PCI write posting. Most architectures define mmiowb as nothing and so will be broken with your change. Anton > --- linux.orig/drivers/net/s2io.c 2005-05-02 16:40:17.469733509 -0700 > +++ linux/drivers/net/s2io.c 2005-05-02 16:40:25.001043632 -0700 > @@ -2759,8 +2759,8 @@ static int s2io_xmit(struct sk_buff *skb > #endif > writeq(val64, &tx_fifo->List_Control); > > - /* Perform a PCI read to flush previous writes */ > - val64 = readq(&bar0->general_int_status); > + /* Perform a mmiowb() to order previous writes */ > + mmiowb(); > > put_off++; > put_off %= mac_control->tx_curr_put_info[queue].fifo_len + 1; > > -- > Arthur > From akepner@sgi.com Mon May 2 19:15:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 19:15:37 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j432FX7J028435 for ; Mon, 2 May 2005 19:15:33 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j433vg9G019728 for ; Mon, 2 May 2005 20:57:42 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j432ELbT65806622 for ; Mon, 2 May 2005 19:14:21 -0700 (PDT) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-189.corp.sgi.com [134.15.0.189]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j432DK5x20777765; Mon, 2 May 2005 19:13:21 -0700 (PDT) Date: Mon, 2 May 2005 19:11:53 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Anton Blanchard cc: Leonid Grossman , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() In-Reply-To: <20050503014034.GC12682@krispykreme> Message-ID: References: <200504051836.j35IanDD005402@guinness.s2io.com> <20050503014034.GC12682@krispykreme> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 450 Lines: 16 On Tue, 3 May 2005, Anton Blanchard wrote: > > I didnt know mmiowb is supposed to be a replacement for PCI write > posting. Most architectures define mmiowb as nothing and so will be > broken with your change. > I thought that an arch was supposed to define mmiowb() if it needs it. In this case, the readq() is only being used for the side-effect of ordering the previous writes (the neterion folks can correct me if I'm wrong). -- Arthur From ram.vepa@neterion.com Mon May 2 19:58:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 19:58:58 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j432wu7J029752 for ; Mon, 2 May 2005 19:58:56 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j432whOC000493; Mon, 2 May 2005 22:58:43 -0400 (EDT) Received: from spiderman ([10.16.16.59]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j432wcVG027487; Mon, 2 May 2005 22:58:40 -0400 (EDT) From: "Ramkrishna Vepa" To: "'Arthur Kepner'" , "'Anton Blanchard'" Cc: "'Leonid Grossman'" , , , , "'Ravinandan Arakali'" Subject: RE: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Date: Mon, 2 May 2005 19:58:38 -0700 Message-ID: <03d401c54f8c$03917fd0$5c10100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ram.vepa@neterion.com Precedence: bulk X-list: netdev Content-Length: 527 Lines: 16 > > I didnt know mmiowb is supposed to be a replacement for PCI write > > posting. Most architectures define mmiowb as nothing and so will be > > broken with your change. > > > > I thought that an arch was supposed to define mmiowb() if it needs > it. In this case, the readq() is only being used for the side-effect > of ordering the previous writes (the neterion folks can correct me > if I'm wrong). [Ram] Yes, it is to ensure ordering as well as the flush of the io that is required in some platforms. > > -- > Arthur From anton@ozlabs.org Mon May 2 20:05:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 20:05:52 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4335l7J030517 for ; Mon, 2 May 2005 20:05:48 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 4DF2E679FD; Tue, 3 May 2005 13:05:34 +1000 (EST) Date: Tue, 3 May 2005 13:05:15 +1000 From: Anton Blanchard To: Arthur Kepner Cc: Leonid Grossman , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Message-ID: <20050503030515.GD12682@krispykreme> References: <200504051836.j35IanDD005402@guinness.s2io.com> <20050503014034.GC12682@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 1274 Lines: 29 Hi, > I thought that an arch was supposed to define mmiowb() if it needs > it. In this case, the readq() is only being used for the side-effect > of ordering the previous writes (the neterion folks can correct me > if I'm wrong). The documentation suggests mmiowb does not do write posting: In addition to write posting, on some large multiprocessing systems (e.g. SGI Challenge, Origin and Altix machines) posted writes won't be strongly ordered coming from different CPUs. Thus it's important to properly protect parts of your driver that do memory-mapped writes with locks and use the mmiowb to make sure they arrive in the order intended. Issuing a regular readX will also ensure write ordering, but should only be used when the driver has to be sure that the write has actually arrived at the device (not that it's simply ordered with respect to other writes), since a full readX is a relatively expensive operation. So if we require the write to be posted we will need the read. If however we only need to order wrt subsequent IO writes then I agree mmiowb can be used. Anton From anton@ozlabs.org Mon May 2 20:10:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 20:10:51 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j433Am7J031153 for ; Mon, 2 May 2005 20:10:49 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 4DC8E679FD; Tue, 3 May 2005 13:10:37 +1000 (EST) Date: Tue, 3 May 2005 13:06:20 +1000 From: Anton Blanchard To: Ramkrishna Vepa Cc: "'Arthur Kepner'" , "'Leonid Grossman'" , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com, "'Ravinandan Arakali'" Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Message-ID: <20050503030620.GE12682@krispykreme> References: <03d401c54f8c$03917fd0$5c10100a@pc.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03d401c54f8c$03917fd0$5c10100a@pc.s2io.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 190 Lines: 7 > [Ram] Yes, it is to ensure ordering as well as the flush of the io that is > required in some platforms. If the flush of the IO is required I cant see how we can remove the read. Anton From davem@davemloft.net Mon May 2 20:13:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 20:13:55 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j433Dq7J031739 for ; Mon, 2 May 2005 20:13:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DSngR-0003NL-00; Mon, 02 May 2005 20:02:51 -0700 Date: Mon, 2 May 2005 20:02:51 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050502200251.38271b61.davem@davemloft.net> In-Reply-To: <20050502162405.65dfb4a9@localhost.localdomain> References: <20050502162405.65dfb4a9@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1396 Lines: 34 On Mon, 2 May 2005 16:24:05 -0700 Stephen Hemminger wrote: > While I was on vacation, OSDL did some networking changes that seems to aggravate some > existing bug in the tg3 driver. Could be some VLAN related garbage, not sure. > > System is 2 CPU AMD64 and the tg3 is on the motherboard. > > I am seeing messages like: > eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:53:08:18 > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] > tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 > > Any clues? This usually means that there is some DMA corruption. For example, some bug in the x86_64 IOMMU code or similar causes a bogus DMA address to be fed to the tg3 or even worse a DMA mapping is unmapped before tg3 is actually done with it. Please try to get some more debugging. One thing that might be useful would be a dump of the PCI config and PCI status registers from PCI config space when that tg3_stop_block event triggers. It will tell us if there was a master or slave abort on the PCI bus which would confirm my above theory. Also what PCI controller is in this box? (ie. the north bridge, lspci -v would tell) Since AMD promised me an Opteron system last year, but never made good on that promise, I've never been able to work on fixing this bug myself. :-/ From mkomu@twilight.cs.hut.fi Mon May 2 22:25:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 22:25:33 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j435PT7J007334 for ; Mon, 2 May 2005 22:25:29 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7C6E42F33; Tue, 3 May 2005 08:25:17 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 949C72F2C; Tue, 3 May 2005 08:25:15 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j435PFv25258; Tue, 3 May 2005 08:25:15 +0300 (EEST) Date: Tue, 3 May 2005 08:25:15 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: IPsec performance In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 750 Lines: 23 On Tue, 3 May 2005, Patrick McHardy wrote: > On Mon, 2 May 2005, Miika Komu wrote: > >> I compared TCP-over-NULL-ESP vs. plain-TCP throughput with "ttcp" tool and > >> obtained the following results: > >> > >> Plain-TCP: 11 megabytes/s > >> NULL-ESP: 2.5 megabytes/s > >> > > I browsed the archives also and found this one: > > > > http://oss.sgi.com/archives/netdev/2004-12/msg00801.html > > null encryption uses a block size of 1, which causes inefficent handling > of the data. I'm unsure if some hack for this specific case is worth it > since its only meant for testing. Thanks for your response. However, this does explain why I got only 1.9 megabytes/s with 3DES. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From dave@thedillows.org Mon May 2 22:54:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 22:54:28 -0700 (PDT) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j435sQ7J008260 for ; Mon, 2 May 2005 22:54:26 -0700 Received: (qmail 28565 invoked by uid 0); 3 May 2005 05:54:14 -0000 Received: from user-24-96-111-205.knology.net (HELO ori.thedillows.org) (24.96.111.205) by smtp2.knology.net with SMTP; 3 May 2005 05:54:14 -0000 Received: from ori.thedillows.org (localhost [127.0.0.1]) by ori.thedillows.org (8.13.1/8.13.1) with ESMTP id j435sdZK003765; Tue, 3 May 2005 01:54:39 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.13.1/8.13.1/Submit) id j435sdvC003764; Tue, 3 May 2005 01:54:39 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: IPsec performance From: Dave Dillow To: Miika Komu Cc: Patrick McHardy , Netdev In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 03 May 2005 01:54:38 -0400 Message-Id: <1115099678.2953.3.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev Content-Length: 331 Lines: 10 On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > However, this does explain why I got only 1.9 megabytes/s with 3DES. What was your hardware? Without knowing what you're running on, it's impossible to tell if that is good or bad. Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. I get ~2.1MB/s on a 550MHz Athlon. Dave From mkomu@twilight.cs.hut.fi Mon May 2 23:44:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 23:44:42 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j436ib7J009893 for ; Mon, 2 May 2005 23:44:37 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id AE78C2F57; Tue, 3 May 2005 09:44:25 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 12B232F4F; Tue, 3 May 2005 09:44:25 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j436iO700370; Tue, 3 May 2005 09:44:24 +0300 (EEST) Date: Tue, 3 May 2005 09:44:24 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dave Dillow Cc: Patrick McHardy , Netdev Subject: Re: IPsec performance In-Reply-To: <1115099678.2953.3.camel@ori.thedillows.org> Message-ID: References: <1115099678.2953.3.camel@ori.thedillows.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 482 Lines: 15 On Tue, 3 May 2005, Dave Dillow wrote: > On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > > However, this does explain why I got only 1.9 megabytes/s with 3DES. > > What was your hardware? Without knowing what you're running on, it's > impossible to tell if that is good or bad. > > Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. > I get ~2.1MB/s on a 550MHz Athlon. Intel Pentium III 500 MHz -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From hasso@estpak.ee Mon May 2 23:45:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 23:45:11 -0700 (PDT) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j436j67J009932 for ; Mon, 2 May 2005 23:45:06 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSr9F-0000pm-Qz; Tue, 03 May 2005 09:44:49 +0300 From: Hasso Tepper To: Patrick McHardy Subject: Re: icmp_unreachable uses wrong ip Date: Tue, 3 May 2005 09:44:48 +0300 User-Agent: KMail/1.8 Cc: "J. Simonetti" , netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505022038.22014.hasso@estpak.ee> <4276A400.2050306@trash.net> In-Reply-To: <4276A400.2050306@trash.net> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200505030944.49175.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j436j67J009932 X-archive-position: 585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 1270 Lines: 33 Patrick McHardy wrote: > Hasso Tepper wrote: > > Patrick McHardy wrote: > >>Why can't you simply add the prefered source address to the route? > > > > Because I don't know what it is. Router A knows what's the best path > > from router A to router B, but he can't know (at least in cases where > > there are more than 1 path between them) what's the best path from > > router B to router A. Therefore you canät say which one is incoming > > interface in router A for traffic from router B. And even if you know > > it in some moment, topology might change in next moment (dynamic > > routing) etc. > > Your patch can't guarantee that the address used is the same that was > used as nexthop by the previous hop in the path when multiple addresses > are configured on the incoming interface. So I don't think it achieves > much of your goal of making debugging complicated topologies easier. At first I don't care what was used as nexthop. I want to know which physical link was used. Having multiple addresses in the same link is more corner case in core network anyway. And can you explain what theoretical possibilities router has to obtain info what address was used as nexthop by neighbour? regards, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From herbert@gondor.apana.org.au Tue May 3 02:08:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 02:08:52 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4398j7J019785 for ; Tue, 3 May 2005 02:08:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DStNp-0004Kq-00; Tue, 03 May 2005 19:08:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DStNl-0007gO-00; Tue, 03 May 2005 19:07:57 +1000 Date: Tue, 3 May 2005 19:07:57 +1000 To: Mark Broadbent Cc: vsu@altlinux.ru, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050503090757.GA29509@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429214336.04b40b3f.vsu@altlinux.ru> <4276238E.4060606@wetlettuce.com> <20050502212819.GA16177@gondor.apana.org.au> <57556.192.102.214.6.1115108726.squirrel@webmail.wetlettuce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57556.192.102.214.6.1115108726.squirrel@webmail.wetlettuce.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1112 Lines: 31 On Tue, May 03, 2005 at 09:25:26AM +0100, Mark Broadbent wrote: > > >> See Documentation/spin-locking.txt line 137, this states that > >> spin_[un]lock() should not be used in IRQ handlers. > > "If you have a case where you have to protect a data structure across > several CPU's and you want to use spinlocks you can potentially use > cheaper versions of the spinlocks. IFF you know that the spinlocks are > never used in interrupt handlers, you can use the non-irq versions: > > spin_lock(&lock); > ... > spin_unlock(&lock); > " Yes this isn't very clear. What it's trying to say that if you're in a softirq/user context and the spin lock may be taken in an IRQ context elsewhere then you must use the IRQ-disabling version. However, if you're in the IRQ context yourself, and yours is the only IRQ context that takes that spin lock, then you may use the straight spin_lock version. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From buytenh@wantstofly.org Tue May 3 02:23:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 02:23:04 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j439N07J020539 for ; Tue, 3 May 2005 02:23:01 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 8D6D92B0EC; Tue, 3 May 2005 11:22:44 +0200 (MEST) Date: Tue, 3 May 2005 11:22:44 +0200 From: Lennert Buytenhek To: netdev@oss.sgi.com Cc: "J. Simonetti" Subject: Re: icmp_unreachable uses wrong ip Message-ID: <20050503092244.GA8864@xi.wantstofly.org> References: <1115040079.5620.11.camel@jeroens.office.netland.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115040079.5620.11.camel@jeroens.office.netland.nl> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 814 Lines: 20 On Mon, May 02, 2005 at 03:21:19PM +0200, J. Simonetti wrote: > I've recently come to notice that traceroutes through a linux router use > the wrong ip (ip of exitting interface) wich should actually be the ip > of the incomming interface. > > I've found a trivial patch (attached) wich resolves this. Perhaps this > is something to include (or have a sysctl to toggle this behaviour). I > unfortunately have no knowledge of programming, so the sysctl option > would have te be done by a volunteer. For what it's worth, I would love to see something like this in. In the presence of asymmetric routing, the way linux routers show up on traceroutes has always been slightly confusing to me. (I know, "Every other router vendor out there does it this way." is not a good reason for doing it the same way.) --L From pekkas@netcore.fi Tue May 3 02:42:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 02:42:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j439gJ7J021505 for ; Tue, 3 May 2005 02:42:20 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j439g1x03254; Tue, 3 May 2005 12:42:01 +0300 Date: Tue, 3 May 2005 12:42:01 +0300 (EEST) From: Pekka Savola To: Lennert Buytenhek cc: netdev@oss.sgi.com, "J. Simonetti" Subject: Re: icmp_unreachable uses wrong ip In-Reply-To: <20050503092244.GA8864@xi.wantstofly.org> Message-ID: References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <20050503092244.GA8864@xi.wantstofly.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 680 Lines: 16 On Tue, 3 May 2005, Lennert Buytenhek wrote: > (I know, "Every other router vendor out there does it this way." > is not a good reason for doing it the same way.) There's no specification requiring or recommending either of these approaches, either for v6 or v4 AFAICS so you can't depend on that behaviour.. Do you have specific data to back up "every other router vendor..." ? I doubt it's quite as uniform as that, but if so, it would certainly be a major motivation for a change. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From herbert@gondor.apana.org.au Tue May 3 02:53:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 02:53:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j439rd7J022317 for ; Tue, 3 May 2005 02:53:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSu5e-0004Y4-00; Tue, 03 May 2005 19:53:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSu5Y-0007kn-00; Tue, 03 May 2005 19:53:12 +1000 Date: Tue, 3 May 2005 19:53:12 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim Subject: Re: [patch/RFC]: Asynchronous IPsec processing. Message-ID: <20050503095312.GA29788@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050429144103.A23268@2ka.mipt.ru> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 912 Lines: 21 On Fri, Apr 29, 2005 at 02:41:03PM +0400, Evgeniy Polyakov wrote: > > I've created POC code to perform asynchronous IPsec [ESP] > processing. Please comment about bugs in the following patch. > It of course very dirty - but it is only begining, > I just want to know if approach is right. > Patch was tested with several ssh session and some > traffic like find / and tcpdump over them. IMHO we should ensure that the async code path does not adversely impact synchronous crypto performance. Most users will be using synchronous crypto primitives. Synchronous crypto is also the best way to utilise VIA Padlock which is arguably the best hardware crypto solution that's available today. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue May 3 03:03:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:03:36 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43A3U7J023045 for ; Tue, 3 May 2005 03:03:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSuFA-0004dO-00; Tue, 03 May 2005 20:03:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSuF8-0007li-00; Tue, 03 May 2005 20:03:06 +1000 Date: Tue, 3 May 2005 20:03:06 +1000 To: Tommy Christensen Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-ID: <20050503100306.GB29788@gondor.apana.org.au> References: <4276B13F.2040103@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4276B13F.2040103@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1820 Lines: 56 Hi Tommy: On Tue, May 03, 2005 at 01:01:19AM +0200, Tommy Christensen wrote: > Some network drivers call netif_stop_queue() when detecting loss of > carrier. This leads to packets being queued up at the qdisc level for > an unbound period of time. In order to prevent this effect, the core > networking stack will now seize to queue packets for any device, that > is operationally down (i.e. the queue is flushed and disabled). This looks great. > @@ -552,15 +560,18 @@ > { > struct Qdisc *qdisc; > > - spin_lock_bh(&dev->queue_lock); > - qdisc = dev->qdisc; > - dev->qdisc = &noop_qdisc; > + if (dev->flags & IFF_RUNNING) { > + spin_lock_bh(&dev->queue_lock); > + qdisc = dev->qdisc; > + dev->qdisc = &noop_qdisc; > > - qdisc_reset(qdisc); > + qdisc_reset(qdisc); > > - spin_unlock_bh(&dev->queue_lock); > + spin_unlock_bh(&dev->queue_lock); > > - dev_watchdog_down(dev); > + dev_watchdog_down(dev); > + } > + dev->flags &= ~IFF_RUNNING; > > while (test_bit(__LINK_STATE_SCHED, &dev->state)) > yield(); Doing the wait when IFF_RUNNING is off isn't necessary though. If IFF_RUNNING isn't set, then either the device has never been activated or we've already carried out those waits the last time we were in dev_deactivate. I understand your preference for defensive programming. However, in cases like this it's better to do the obvious thing because: 1) We don't cover up bugs that may come back to bite us elsewhere. 2) We don't give people misconceptions. If they're unfamiliar with the system they may infer things from this code that aren't necessarily the case. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From johnpol@2ka.mipt.ru Tue May 3 03:11:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:11:22 -0700 (PDT) Received: from vocord.com (user-edvans3.msk.internet2.ru [217.25.93.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43ABI7J023727 for ; Tue, 3 May 2005 03:11:19 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j43AAamt022873; Tue, 3 May 2005 14:10:37 +0400 Subject: Re: [patch/RFC]: Asynchronous IPsec processing. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Herbert Xu Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim In-Reply-To: <20050503095312.GA29788@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cJaM2D1YZkDdvae0Sc3H" Organization: MIPT Date: Tue, 03 May 2005 14:18:22 +0400 Message-Id: <1115115502.3414.22.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/852/Mon Apr 25 19:12:46 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 03 May 2005 14:10:40 +0400 (MSD) X-archive-position: 592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1717 Lines: 49 --=-cJaM2D1YZkDdvae0Sc3H Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-05-03 at 19:53 +1000, Herbert Xu wrote: > On Fri, Apr 29, 2005 at 02:41:03PM +0400, Evgeniy Polyakov wrote: > >=20 > > I've created POC code to perform asynchronous IPsec [ESP] > > processing. Please comment about bugs in the following patch. > > It of course very dirty - but it is only begining,=20 > > I just want to know if approach is right. > > Patch was tested with several ssh session and some=20 > > traffic like find / and tcpdump over them. >=20 > IMHO we should ensure that the async code path does not adversely > impact synchronous crypto performance. Most users will be using > synchronous crypto primitives. Synchronous crypto is also the best > way to utilise VIA Padlock which is arguably the best hardware crypto > solution that's available today. It can be compile option - those people who wants asynchronous crypto processing and has appropriate hardware will benefit from that even if theirs general purpose CPU is VIA with PadLock ACE. It looks like several CPUs can not be used for synchronous crypto processing in current IPsec implementation. Using asynchronous mode there might be significant performance win. > Cheers, --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-cJaM2D1YZkDdvae0Sc3H Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCd0/uIKTPhE+8wY0RAh7xAJ4nA4frpuNJdlP59SNY7U9nsxXkRwCcDlFJ BZlFh0eFWlwEIevbQHdhnuQ= =MkCS -----END PGP SIGNATURE----- --=-cJaM2D1YZkDdvae0Sc3H-- From herbert@gondor.apana.org.au Tue May 3 03:15:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:15:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43AFT7J024599 for ; Tue, 3 May 2005 03:15:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSuQV-0004j3-00; Tue, 03 May 2005 20:14:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSuQR-0007nh-00; Tue, 03 May 2005 20:14:47 +1000 Date: Tue, 3 May 2005 20:14:47 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim Subject: Re: [patch/RFC]: Asynchronous IPsec processing. Message-ID: <20050503101447.GA29973@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115115502.3414.22.camel@uganda> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 938 Lines: 24 On Tue, May 03, 2005 at 02:18:22PM +0400, Evgeniy Polyakov wrote: > > It can be compile option - those people who wants asynchronous crypto > processing and has appropriate hardware will benefit from that even > if theirs general purpose CPU is VIA with PadLock ACE. Well if there were no better options then we'll have to do that. However, I believe that with the right crypto API we should be able to have async crypto support without sacrificing synchronous performance. > It looks like several CPUs can not be used for synchronous crypto > processing in current IPsec implementation. Using asynchronous That's just an implementation quirk. I will be addressing that soon as part of the xfrm locking clean-up. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From johnpol@2ka.mipt.ru Tue May 3 03:24:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:24:29 -0700 (PDT) Received: from vocord.com (user-edvans3.msk.internet2.ru [217.25.93.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43AOP7J025249 for ; Tue, 3 May 2005 03:24:26 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j43ANnMl023895; Tue, 3 May 2005 14:23:49 +0400 Subject: Re: [patch/RFC]: Asynchronous IPsec processing. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Herbert Xu Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim In-Reply-To: <20050503101447.GA29973@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-wUR+YD3lwNiIhhyNElti" Organization: MIPT Date: Tue, 03 May 2005 14:31:35 +0400 Message-Id: <1115116295.3414.30.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/852/Mon Apr 25 19:12:46 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 03 May 2005 14:23:50 +0400 (MSD) X-archive-position: 594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1928 Lines: 58 --=-wUR+YD3lwNiIhhyNElti Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-05-03 at 20:14 +1000, Herbert Xu wrote: > On Tue, May 03, 2005 at 02:18:22PM +0400, Evgeniy Polyakov wrote: > >=20 > > It can be compile option - those people who wants asynchronous crypto > > processing and has appropriate hardware will benefit from that even > > if theirs general purpose CPU is VIA with PadLock ACE. >=20 > Well if there were no better options then we'll have to do that. >=20 > However, I believe that with the right crypto API we should be > able to have async crypto support without sacrificing synchronous > performance. Asynchronous processing will not hurt synchronous pathes in any way. But in some places we can use async api easily - like block devices encryption, but for others - like IPsec, there is no ability to split packet processing and thus even use async api. How carefully asynchronous API would be created current IPsec code just can not use it. > > It looks like several CPUs can not be used for synchronous crypto > > processing in current IPsec implementation. Using asynchronous >=20 > That's just an implementation quirk. I will be addressing that > soon as part of the xfrm locking clean-up. That is not enough, as far as I can see, since only one tfm is used for one transformer state. Locking changes will allow parallel processing of AH and ESP for example, but not two packets from the same flow. > Cheers, --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-wUR+YD3lwNiIhhyNElti Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCd1MHIKTPhE+8wY0RAvHyAJ97hDiRUjMPNB7sg2i2sSWKre7O+gCeK99w TahkxWsV6D4GpBuiZbgGn2o= =sN5I -----END PGP SIGNATURE----- --=-wUR+YD3lwNiIhhyNElti-- From herbert@gondor.apana.org.au Tue May 3 03:29:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:29:58 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43ATp7J025856 for ; Tue, 3 May 2005 03:29:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSuek-0004mo-00; Tue, 03 May 2005 20:29:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSuef-0007pr-00; Tue, 03 May 2005 20:29:29 +1000 Date: Tue, 3 May 2005 20:29:29 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim Subject: Re: [patch/RFC]: Asynchronous IPsec processing. Message-ID: <20050503102929.GA30097@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115116295.3414.30.camel@uganda> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 456 Lines: 11 On Tue, May 03, 2005 at 02:31:35PM +0400, Evgeniy Polyakov wrote: > > Asynchronous processing will not hurt synchronous pathes in any way. It will if you force everybody to go through the asynchronous path because you're jacking up the latency. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From buytenh@wantstofly.org Tue May 3 03:38:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:38:27 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43AcP7J027137 for ; Tue, 3 May 2005 03:38:25 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 7D7C02B0EC; Tue, 3 May 2005 12:38:06 +0200 (MEST) Date: Tue, 3 May 2005 12:38:06 +0200 From: Lennert Buytenhek To: Pekka Savola Cc: netdev@oss.sgi.com, "J. Simonetti" Subject: Re: icmp_unreachable uses wrong ip Message-ID: <20050503103806.GB8864@xi.wantstofly.org> References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <20050503092244.GA8864@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 1302 Lines: 34 On Tue, May 03, 2005 at 12:42:01PM +0300, Pekka Savola wrote: > >(I know, "Every other router vendor out there does it this way." > >is not a good reason for doing it the same way.) > > There's no specification requiring or recommending either of these > approaches, either for v6 or v4 AFAICS so you can't depend on that > behaviour.. > > Do you have specific data to back up "every other router vendor..." ? Sorry, I wasn't claiming that every other router vendor out there does it that way, just merely trying to state that that would not be a good argument. The ones I've worked with in the past do, and I just did some simple tests (doing traceroute from a foreign IP in a different network and looking at the ICMP time-exceededs arriving at that foreign IP) to confirm that: - Juniper M5 and M20 both running JUNOS 7.0R2.7 - Cisco 7206VXR and 12k(unsure which model) running unknown IOS versions - Foundry FastIron 3 (the 15-slot chassis) running BIR06636.bin do all behave opposite of the linux way, i.e. sending ICMPs with (one of) the source address(es) of the interface where the original packet (that we're sending an ICMP for) came in. I did also find one router that behaves the linux way: - Foundry TurboIron/8 running 07.800A Any other vendors that we're interested in? --L From johnpol@2ka.mipt.ru Tue May 3 03:48:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:48:36 -0700 (PDT) Received: from vocord.com (user-edvans3.msk.internet2.ru [217.25.93.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43AmQ7J027885 for ; Tue, 3 May 2005 03:48:28 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j43AlgDX025163; Tue, 3 May 2005 14:47:42 +0400 Subject: Re: [patch/RFC]: Asynchronous IPsec processing. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Herbert Xu Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim In-Reply-To: <20050503102929.GA30097@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@gondor.apana.org.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-k9PHOwYCs5KMRHWF2+qk" Organization: MIPT Date: Tue, 03 May 2005 14:55:28 +0400 Message-Id: <1115117728.3414.48.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/852/Mon Apr 25 19:12:46 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 03 May 2005 14:47:43 +0400 (MSD) X-archive-position: 598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2099 Lines: 66 --=-k9PHOwYCs5KMRHWF2+qk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-05-03 at 20:29 +1000, Herbert Xu wrote: > On Tue, May 03, 2005 at 02:31:35PM +0400, Evgeniy Polyakov wrote: > > > > Asynchronous processing will not hurt synchronous pathes in any way. >=20 > It will if you force everybody to go through the asynchronous path > because you're jacking up the latency. But if it will not be selected - IPsec users will not be affected. Using asynchronous crypto processing of course has it's own nitpics, and although it's value was prooven [1] to be unsignificant, it is still=20 there. Current IPsec processing [even if it is UP only] has very strong model which always gets the maximum only from synchronous crypto. If people select asynchronous IPsec processing - they will use=20 _asynchronous_ IPsec processing, and no _synchronous_ pathes will be=20 affected. Using asynchronous IPsec processing is only usefull with asynchronous crypto layers, so no need to turn it on if none could be used with hardware. Btw, current crypto schema by design is SMP unfriendly - there is only low-level TFM entity, which=20 1. must be recreated for several CPUs 2. caller must know about how many CPUs are, which TFM to use and so on. Asynchronous crypto layers allow to hide it using proper API. I doubt there will be any benfit for existing IPsec schema from several CPUs without either some crypto processing rewrite (either by using per-cpu xfrm states or using several tfms per transformer), or without using some asynchronous crypto processing schema... [1] http://www.openbsd.org/papers/ocf.pdf --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-k9PHOwYCs5KMRHWF2+qk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCd1igIKTPhE+8wY0RAreZAJ0UMQ91mhs1Elzjm/pOowLPpTM1KACeMRzi hzOPWkUIC40JQeseFr15c/k= =ArHw -----END PGP SIGNATURE----- --=-k9PHOwYCs5KMRHWF2+qk-- From hasso@estpak.ee Tue May 3 04:01:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 04:01:23 -0700 (PDT) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43B1K7J028785 for ; Tue, 3 May 2005 04:01:21 -0700 Received: from [127.0.0.1] (helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSv9E-0005kS-Uq; Tue, 03 May 2005 14:01:04 +0300 From: Hasso Tepper To: Lennert Buytenhek Subject: Re: icmp_unreachable uses wrong ip Date: Tue, 3 May 2005 14:00:47 +0300 User-Agent: KMail/1.8 Cc: Pekka Savola , netdev@oss.sgi.com, "J. Simonetti" References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <20050503103806.GB8864@xi.wantstofly.org> In-Reply-To: <20050503103806.GB8864@xi.wantstofly.org> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505031400.48287.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 887 Lines: 24 Lennert Buytenhek wrote: > The ones I've worked with in the past do, and I just did some > simple tests (doing traceroute from a foreign IP in a different > network and looking at the ICMP time-exceededs arriving at that > foreign IP) to confirm that: > - Juniper M5 and M20 both running JUNOS 7.0R2.7 > - Cisco 7206VXR and 12k(unsure which model) running unknown IOS versions I haven't seen JUNOS or IOS versions behave differently. > - Foundry FastIron 3 (the 15-slot chassis) running BIR06636.bin I can add to it (probably all) Extreme Networks line. Tested with both software lines - Summit 24e3 and Inferno (Black Diamond 6808). > do all behave opposite of the linux way, i.e. sending ICMPs with (one > of) the source address(es) of the interface where the original packet > (that we're sending an ICMP for) came in. -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From tgraf@suug.ch Tue May 3 04:18:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 04:18:43 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43BId7J030157 for ; Tue, 3 May 2005 04:18:39 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 1C42D1C0EB; Tue, 3 May 2005 13:18:44 +0200 (CEST) Date: Tue, 3 May 2005 13:18:44 +0200 From: Thomas Graf To: Herbert Xu Cc: Tommy Christensen , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-ID: <20050503111844.GP577@postel.suug.ch> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503100306.GB29788@gondor.apana.org.au> X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1736 Lines: 47 * Herbert Xu <20050503100306.GB29788@gondor.apana.org.au> 2005-05-03 20:03 > On Tue, May 03, 2005 at 01:01:19AM +0200, Tommy Christensen wrote: > > Some network drivers call netif_stop_queue() when detecting loss of > > carrier. This leads to packets being queued up at the qdisc level for > > an unbound period of time. In order to prevent this effect, the core > > networking stack will now seize to queue packets for any device, that > > is operationally down (i.e. the queue is flushed and disabled). > > This looks great. > > > @@ -552,15 +560,18 @@ > > { > > struct Qdisc *qdisc; > > > > - spin_lock_bh(&dev->queue_lock); > > - qdisc = dev->qdisc; > > - dev->qdisc = &noop_qdisc; > > + if (dev->flags & IFF_RUNNING) { > > + spin_lock_bh(&dev->queue_lock); > > + qdisc = dev->qdisc; > > + dev->qdisc = &noop_qdisc; > > > > - qdisc_reset(qdisc); > > + qdisc_reset(qdisc); > > > > - spin_unlock_bh(&dev->queue_lock); > > + spin_unlock_bh(&dev->queue_lock); > > > > - dev_watchdog_down(dev); > > + dev_watchdog_down(dev); > > + } > > + dev->flags &= ~IFF_RUNNING; > > > > while (test_bit(__LINK_STATE_SCHED, &dev->state)) > > yield(); > > Doing the wait when IFF_RUNNING is off isn't necessary though. If > IFF_RUNNING isn't set, then either the device has never been activated > or we've already carried out those waits the last time we were in > dev_deactivate. I do like the patch, no question but IFF_RUNNING is still abused by drivers and some subsystems. So I'm not sure how reliable the above code will be without those cases fixed. I submitted a patchset once to fix some of them, not sure about the status. Also, what about those drivers that do not support or do not use netif_carrier_(on|off)? From herbert@gondor.apana.org.au Tue May 3 04:23:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 04:23:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43BNd7J001698 for ; Tue, 3 May 2005 04:23:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSvUf-00054W-00; Tue, 03 May 2005 21:23:13 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSvUc-0007ud-00; Tue, 03 May 2005 21:23:10 +1000 Date: Tue, 3 May 2005 21:23:10 +1000 To: Thomas Graf Cc: Tommy Christensen , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-ID: <20050503112310.GA30356@gondor.apana.org.au> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <20050503111844.GP577@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503111844.GP577@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 982 Lines: 24 On Tue, May 03, 2005 at 01:18:44PM +0200, Thomas Graf wrote: > > I do like the patch, no question but IFF_RUNNING is still abused > by drivers and some subsystems. So I'm not sure how reliable the > above code will be without those cases fixed. I submitted a Ouch, you're right. They either need to be fixed or we'll just have to go back to the simpler version that may call dev_activate/dev_deactivate repeatedly. > patchset once to fix some of them, not sure about the status. Also, > what about those drivers that do not support or do not use > netif_carrier_(on|off)? They simply won't benefit from this patch. This is OK since they're no worse off than where they were before. It might also prove to be an incentive for someone to finally fix them :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hasso@estpak.ee Tue May 3 04:46:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 04:47:00 -0700 (PDT) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Bkv7J002977 for ; Tue, 3 May 2005 04:46:57 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSvrR-0005oX-3z for netdev@oss.sgi.com; Tue, 03 May 2005 14:46:45 +0300 From: Hasso Tepper Subject: Re: icmp_unreachable uses wrong ip Date: Tue, 3 May 2005 14:46:44 +0300 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505021659.05674.hasso@estpak.ee> In-Reply-To: <200505021659.05674.hasso@estpak.ee> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline To: "Undisclosed.Recipients": ; Message-Id: <200505031446.44551.hasso@estpak.ee> X-archive-position: 602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 360 Lines: 13 Hasso Tepper wrote: > I'm attaching patch which was posted to the list some time ago. I'm using > it for some time already. I can't find the post from the archive though > at the moment. Chris Wilson was probably author of this patch. http://marc.theaimsgroup.com/?l=linux-net&m=109595048606145&w=2 -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From johnpol@2ka.mipt.ru Tue May 3 06:31:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 06:31:55 -0700 (PDT) Received: from vocord.com (user-edvans3.msk.internet2.ru [217.25.93.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43DVl7J007227 for ; Tue, 3 May 2005 06:31:49 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j43DUfmW000413; Tue, 3 May 2005 17:30:57 +0400 Subject: [patch/RFC]: Asynchronous IPsec processing benchmark. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Herbert Xu Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim In-Reply-To: <1115117728.3414.48.camel@uganda> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@gondor.apana.org.au> <1115117728.3414.48.camel@uganda> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FFK2WSC8sADObNy6J1+q" Organization: MIPT Date: Tue, 03 May 2005 17:38:27 +0400 Message-Id: <1115127507.3414.58.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 03 May 2005 17:31:02 +0400 (MSD) X-archive-position: 603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 943 Lines: 40 --=-FFK2WSC8sADObNy6J1+q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Here are some numbers: ./netperf -l 60 -H gw -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 TCP STREAM TEST to gw : +/-2.5% @ 99% conf. async-ipsec, 10^6bits/sec: 35.42 sync-ipsec, 10^6bits/sec: 37.11 So even with existing timer deferring it is not noticebly slower [about 4%]. And I think that benefits it provides definitely cost that price and=20 compile time option. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-FFK2WSC8sADObNy6J1+q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCd37TIKTPhE+8wY0RAho5AJ9rMXgXW4qUErGFYBfH1nLZWVDxxwCdH3ZZ n1R13gy6YosPvqaXG4XfhhQ= =dmqb -----END PGP SIGNATURE----- --=-FFK2WSC8sADObNy6J1+q-- From dave@thedillows.org Tue May 3 07:17:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 07:17:10 -0700 (PDT) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j43EH77J009580 for ; Tue, 3 May 2005 07:17:07 -0700 Received: (qmail 21339 invoked by uid 0); 3 May 2005 14:16:54 -0000 Received: from user-24-96-111-205.knology.net (HELO ori.thedillows.org) (24.96.111.205) by smtp7.knology.net with SMTP; 3 May 2005 14:16:54 -0000 Received: from ori.thedillows.org (localhost [127.0.0.1]) by ori.thedillows.org (8.13.1/8.13.1) with ESMTP id j43EHJff004440; Tue, 3 May 2005 10:17:19 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.13.1/8.13.1/Submit) id j43EHJin004439; Tue, 3 May 2005 10:17:19 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: IPsec performance From: Dave Dillow To: Miika Komu Cc: Patrick McHardy , Netdev In-Reply-To: References: <1115099678.2953.3.camel@ori.thedillows.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 03 May 2005 10:17:19 -0400 Message-Id: <1115129839.2953.4.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-archive-position: 605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev Content-Length: 572 Lines: 16 On Tue, 2005-05-03 at 09:44 +0300, Miika Komu wrote: > On Tue, 3 May 2005, Dave Dillow wrote: > > > On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > > > However, this does explain why I got only 1.9 megabytes/s with 3DES. > > > > What was your hardware? Without knowing what you're running on, it's > > impossible to tell if that is good or bad. > > > > Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. > > I get ~2.1MB/s on a 550MHz Athlon. > > Intel Pentium III 500 MHz 3DES is processor intensive. I'd say 1.9MB/s is reasonable for the hardware you are on. From akepner@sgi.com Tue May 3 07:53:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 07:53:53 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Erm7J011109 for ; Tue, 3 May 2005 07:53:48 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j43Ga1RG008145 for ; Tue, 3 May 2005 09:36:01 -0700 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-189.corp.sgi.com [134.15.0.189]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j43ErZ5x20946576; Tue, 3 May 2005 07:53:35 -0700 (PDT) Date: Tue, 3 May 2005 07:52:06 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Anton Blanchard cc: Ramkrishna Vepa , "'Leonid Grossman'" , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com, "'Ravinandan Arakali'" Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() In-Reply-To: <20050503030620.GE12682@krispykreme> Message-ID: References: <03d401c54f8c$03917fd0$5c10100a@pc.s2io.com> <20050503030620.GE12682@krispykreme> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 358 Lines: 14 On Tue, 3 May 2005, Anton Blanchard wrote: > > > [Ram] Yes, it is to ensure ordering as well as the flush of the io that is > > required in some platforms. > > If the flush of the IO is required I cant see how we can remove the read. > Agreed. Can someone from neterion comment? Is a flush required, or is ordering all that's required here? -- Arthur From breed@zuzulu.com Tue May 3 08:28:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 08:28:29 -0700 (PDT) Received: from optimus.nocdirect.com (optimus.nocdirect.com [69.73.171.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43FSM7J019463 for ; Tue, 3 May 2005 08:28:23 -0700 Received: from wbar3.sjo1-4-11-005-121.sjo1.dsl-verizon.net ([4.11.5.121] helo=[192.168.1.102]) by optimus.nocdirect.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50) id 1DSzJl-0006jl-FN; Tue, 03 May 2005 10:28:14 -0500 From: Benjamin Reed To: netdev@oss.sgi.com Subject: [PATCH] dynamic wep keys for airo.c Date: Tue, 3 May 2005 08:26:42 -0700 User-Agent: KMail/1.8 Cc: linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200505030826.42564.breed@zuzulu.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - optimus.nocdirect.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zuzulu.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: breed@zuzulu.com Precedence: bulk X-list: netdev I'm resubmitting a patch for the 2.6.11.8 aironet driver (airo.c) that will enable dynamic wep keying without disabling the MAC. It allows us to use xsupplicant with the driver. Aironet provides the ability to set WEP keys permanently or temporarily. There is a special IW_ENCODE_TEMP flag for selecting which type of key you are setting. However, apart from iwconfig, nobody seems to use this flag. When a permanent WEP key is set, the MAC must be disabled. I have added a module parameter to skip disabling the MAC even if a permanent WEP key is set. Using this flag allows xsupplicant to work without modification. ben Signed-off-by: Benjamin Reed --- drivers/net/wireless/airo.c.orig 2005-05-02 10:15:24.000000000 -0700 +++ drivers/net/wireless/airo.c 2005-05-02 11:16:43.000000000 -0700 @@ -224,6 +224,8 @@ static int maxencrypt /* = 0 */; /* The highest rate that the card can encrypt at. 0 means no limit. For old cards this was 4 */ +static int perm_key_support = 1; /* If set, the MAC will be disabled when + permanent wep keys are set. */ static int auto_wep /* = 0 */; /* If set, it tries to figure out the wep mode */ static int aux_bap /* = 0 */; /* Checks to see if the aux ports are needed to read the bap, needed on some older cards and buses. */ @@ -251,6 +253,13 @@ module_param(basic_rate, int, 0); module_param_array(rates, int, NULL, 0); module_param_array(ssids, charp, NULL, 0); module_param(auto_wep, int, 0); +module_param(perm_key_support, int, 1); +MODULE_PARM_DESC(perm_key_support, "The MAC is supposed to be disabled before \ +a permanent WEP key (the default) is set. Applications that want to set the \ +temporary keys, and thus not disable the MAC, are supposed to use the \ +IW_ENCODE_TEMP flag. Unfortunately, life doesn't always work the way it is \ +supposed to. If the IW_ENCODE_TEMP flag is not used and the MAC should not be \ +disabled, set this flag to 0."); MODULE_PARM_DESC(auto_wep, "If non-zero, the driver will keep looping through \ the authentication options until an association is made. The value of \ auto_wep is number of the wep keys to check. A value of 2 will try using \ @@ -1738,9 +1747,12 @@ static int writeWepKeyRid(struct airo_in rc = PC4500_writerid(ai, RID_WEP_TEMP, &wkr, sizeof(wkr), lock); if (rc!=SUCCESS) printk(KERN_ERR "airo: WEP_TEMP set %x\n", rc); if (perm) { + // We make these messages debug. They really should be error, + // but no one seems to use the TEMP flag and writing a PERM key + // with the MAC disable throws this error rc = PC4500_writerid(ai, RID_WEP_PERM, &wkr, sizeof(wkr), lock); if (rc!=SUCCESS) { - printk(KERN_ERR "airo: WEP_PERM set %x\n", rc); + printk(KERN_DEBUG "airo: WEP_PERM set %x\n", rc); } } return rc; @@ -3813,11 +3825,14 @@ static u16 issuecommand(struct airo_info pRsp->rsp1 = IN4500(ai, RESP1); pRsp->rsp2 = IN4500(ai, RESP2); if ((pRsp->status & 0xff00)!=0 && pCmd->cmd != CMD_SOFTRESET) { - printk (KERN_ERR "airo: cmd= %x\n", pCmd->cmd); - printk (KERN_ERR "airo: status= %x\n", pRsp->status); - printk (KERN_ERR "airo: Rsp0= %x\n", pRsp->rsp0); - printk (KERN_ERR "airo: Rsp1= %x\n", pRsp->rsp1); - printk (KERN_ERR "airo: Rsp2= %x\n", pRsp->rsp2); + /* These really should be error, but supplicants don't seem + * to use the TEMP flag when setting the keys, so this + * error is common */ + printk (KERN_DEBUG "airo: cmd= %x\n", pCmd->cmd); + printk (KERN_DEBUG "airo: status= %x\n", pRsp->status); + printk (KERN_DEBUG "airo: Rsp0= %x\n", pRsp->rsp0); + printk (KERN_DEBUG "airo: Rsp1= %x\n", pRsp->rsp1); + printk (KERN_DEBUG "airo: Rsp2= %x\n", pRsp->rsp2); } // clear stuck command busy if necessary @@ -4046,10 +4061,12 @@ static int PC4500_writerid(struct airo_i Cmd cmd; Resp rsp; +#if 0 /* This check is to catch bugs, not needed for WepRid with temp key */ if (test_bit(FLAG_ENABLED, &ai->flags)) printk(KERN_ERR "%s: MAC should be disabled (rid=%04x)\n", __FUNCTION__, rid); +#endif memset(&cmd, 0, sizeof(cmd)); memset(&rsp, 0, sizeof(rsp)); @@ -5094,7 +5111,7 @@ static int set_wep_key(struct airo_info wkr.len = sizeof(wkr); wkr.kindex = 0xffff; wkr.mac[0] = (char)index; - if (perm) printk(KERN_INFO "Setting transmit key to %d\n", index); + if (perm) printk(KERN_DEBUG "Setting transmit key to %d\n", index); if (perm) ai->defindex = (char)index; } else { // We are actually setting the key @@ -5103,12 +5120,11 @@ static int set_wep_key(struct airo_info wkr.klen = keylen; memcpy( wkr.key, key, keylen ); memcpy( wkr.mac, macaddr, ETH_ALEN ); - printk(KERN_INFO "Setting key %d\n", index); } - disable_MAC(ai, lock); + if (perm_key_support && perm) disable_MAC(ai, lock); writeWepKeyRid(ai, &wkr, perm, lock); - enable_MAC(ai, &rsp, lock); + if (perm_key_support && perm) enable_MAC(ai, &rsp, lock); return 0; } @@ -5562,9 +5578,9 @@ static int __init airo_init_module( void } #ifdef CONFIG_PCI - printk( KERN_INFO "airo: Probing for PCI adapters\n" ); + printk( KERN_DEBUG "airo: Probing for PCI adapters\n" ); pci_register_driver(&airo_driver); - printk( KERN_INFO "airo: Finished probing for PCI adapters\n" ); + printk( KERN_DEBUG "airo: Finished probing for PCI adapters\n" ); #endif /* Always exit with success, as we are a library module @@ -5576,7 +5592,7 @@ static int __init airo_init_module( void static void __exit airo_cleanup_module( void ) { while( airo_devices ) { - printk( KERN_INFO "airo: Unregistering %s\n", airo_devices->dev->name ); + printk( KERN_DEBUG "airo: Unregistering %s\n", airo_devices->dev->name ); stop_airo_card( airo_devices->dev, 1 ); } #ifdef CONFIG_PCI @@ -6166,6 +6182,7 @@ static int airo_set_encode(struct net_de { struct airo_info *local = dev->priv; CapabilityRid cap_rid; /* Card capability info */ + u16 oldAuthType; /* Is WEP supported ? */ readCapabilityRid(local, &cap_rid, 1); @@ -6208,7 +6225,8 @@ static int airo_set_encode(struct net_de /* Copy the key in the driver */ memcpy(key.key, extra, dwrq->length); /* Send the key to the card */ - set_wep_key(local, index, key.key, key.len, 1, 1); + set_wep_key(local, index, key.key, key.len, + !(dwrq->flags&IW_ENCODE_TEMP), 1); } /* WE specify that if a valid key is set, encryption * should be enabled (user may turn it off later) @@ -6222,13 +6240,15 @@ static int airo_set_encode(struct net_de /* Do we want to just set the transmit key index ? */ int index = (dwrq->flags & IW_ENCODE_INDEX) - 1; if ((index >= 0) && (index < ((cap_rid.softCap & 0x80)?4:1))) { - set_wep_key(local, index, NULL, 0, 1, 1); + set_wep_key(local, index, NULL, 0, + !(dwrq->flags&IW_ENCODE_TEMP), 1); } else /* Don't complain if only change the mode */ if(!dwrq->flags & IW_ENCODE_MODE) { return -EINVAL; } } + oldAuthType = local->config.authType; /* Read the flags */ if(dwrq->flags & IW_ENCODE_DISABLED) local->config.authType = AUTH_OPEN; // disable encryption @@ -6237,7 +6257,7 @@ static int airo_set_encode(struct net_de if(dwrq->flags & IW_ENCODE_OPEN) local->config.authType = AUTH_ENCRYPT; // Only Wep /* Commit the changes to flags if needed */ - if(dwrq->flags & IW_ENCODE_MODE) + if(oldAuthType != local->config.authType) set_bit (FLAG_COMMIT, &local->flags); return -EINPROGRESS; /* Call commit handler */ } From mkomu@twilight.cs.hut.fi Tue May 3 09:14:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 09:14:25 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43GEK7J023499 for ; Tue, 3 May 2005 09:14:21 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0DA3B2FDE; Tue, 3 May 2005 19:14:06 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5BED92FC3; Tue, 3 May 2005 19:14:05 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j43GE5X09755; Tue, 3 May 2005 19:14:05 +0300 (EEST) Date: Tue, 3 May 2005 19:14:05 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dave Dillow Cc: Patrick McHardy , Netdev Subject: Re: IPsec performance In-Reply-To: <1115129839.2953.4.camel@ori.thedillows.org> Message-ID: References: <1115099678.2953.3.camel@ori.thedillows.org> <1115129839.2953.4.camel@ori.thedillows.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev On Tue, 3 May 2005, Dave Dillow wrote: > On Tue, 2005-05-03 at 09:44 +0300, Miika Komu wrote: > > On Tue, 3 May 2005, Dave Dillow wrote: > > > > > On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > > > > However, this does explain why I got only 1.9 megabytes/s with 3DES. > > > > > > What was your hardware? Without knowing what you're running on, it's > > > impossible to tell if that is good or bad. > > > > > > Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. > > > I get ~2.1MB/s on a 550MHz Athlon. > > > > Intel Pentium III 500 MHz > > 3DES is processor intensive. I'd say 1.9MB/s is reasonable for the > hardware you are on. Ok. Thanks for your quick responses! -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From ram.vepa@neterion.com Tue May 3 09:23:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 09:23:31 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43GNO7J024249 for ; Tue, 3 May 2005 09:23:24 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j43GNBOC002476; Tue, 3 May 2005 12:23:11 -0400 (EDT) Received: from spiderman ([10.16.16.58]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j43GN8VG007709; Tue, 3 May 2005 12:23:08 -0400 (EDT) From: "Ramkrishna Vepa" To: "'Arthur Kepner'" , "'Anton Blanchard'" Cc: "'Leonid Grossman'" , , , , "'Ravinandan Arakali'" Subject: RE: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Date: Tue, 3 May 2005 09:23:07 -0700 Message-ID: <03d701c54ffc$651958c0$5c10100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: MIMEDefang 2.34 X-archive-position: 610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ram.vepa@neterion.com Precedence: bulk X-list: netdev Ordering is all that is required. We can get rid of the flush. Ram > -----Original Message----- > From: Arthur Kepner [mailto:akepner@sgi.com] > Sent: Tuesday, May 03, 2005 7:52 AM > To: Anton Blanchard > Cc: Ramkrishna Vepa; 'Leonid Grossman'; muhammad.shafiq@neterion.com; > ramkrishna.vepa@neterion.com; netdev@oss.sgi.com; 'Ravinandan Arakali' > Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() > > On Tue, 3 May 2005, Anton Blanchard wrote: > > > > > > [Ram] Yes, it is to ensure ordering as well as the flush of the io > that is > > > required in some platforms. > > > > If the flush of the IO is required I cant see how we can remove the > read. > > > > Agreed. Can someone from neterion comment? Is a flush required, or is > ordering all that's required here? > > -- > Arthur From kaber@trash.net Tue May 3 11:15:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 11:15:24 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43IFL7J032382 for ; Tue, 3 May 2005 11:15:21 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT1vC-00029o-Eu; Tue, 03 May 2005 20:15:03 +0200 Message-ID: <4277BFA6.8090306@trash.net> Date: Tue, 03 May 2005 20:15:02 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Hasso Tepper CC: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505022038.22014.hasso@estpak.ee> <4276A400.2050306@trash.net> <200505030944.49175.hasso@estpak.ee> In-Reply-To: <200505030944.49175.hasso@estpak.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Hasso Tepper wrote: > Patrick McHardy wrote: >> >>Your patch can't guarantee that the address used is the same that was >>used as nexthop by the previous hop in the path when multiple addresses >>are configured on the incoming interface. So I don't think it achieves >>much of your goal of making debugging complicated topologies easier. > > At first I don't care what was used as nexthop. I want to know which > physical link was used. Having multiple addresses in the same link is more > corner case in core network anyway. But when multiple addresses are used the result can be even more confusing. I don't like inconsistent behaviour, and this patch works sometimes and sometimes it doesn't. > And can you explain what theoretical possibilities router has to obtain info > what address was used as nexthop by neighbour? I can think of none. Regards Patrick From dave@thedillows.org Tue May 3 12:28:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 12:28:13 -0700 (PDT) Received: from iasrv1.idleaire.net (ns1.idleaire.net [65.220.16.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43JS87J007219 for ; Tue, 3 May 2005 12:28:08 -0700 Received: by iasrv1.idleaire.net (Postfix, from userid 300) id AF75C236E55; Tue, 3 May 2005 15:27:44 -0400 (EDT) Received: from corp4.idleaire.com (corp4.idleaire.com [10.1.66.36]) by iasrv1.idleaire.net (Postfix) with ESMTP id 1EC90236E4D; Tue, 3 May 2005 15:27:42 -0400 (EDT) Received: from [10.1.66.124] ([10.1.66.124]) by corp4.idleaire.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 May 2005 15:27:44 -0400 Subject: Re: IPsec performance From: Dave Dillow To: Miika Komu Cc: Patrick McHardy , Netdev In-Reply-To: References: <1115099678.2953.3.camel@ori.thedillows.org> <1115129839.2953.4.camel@ori.thedillows.org> Content-Type: text/plain Date: Tue, 03 May 2005 15:27:41 -0400 Message-Id: <1115148461.31573.9.camel@dillow.idleaire.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2005 19:27:44.0358 (UTC) FILETIME=[2E249860:01C55016] X-archive-position: 612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev On Tue, 2005-05-03 at 19:14 +0300, Miika Komu wrote: > On Tue, 3 May 2005, Dave Dillow wrote: > > 3DES is processor intensive. I'd say 1.9MB/s is reasonable for the > > hardware you are on. > > Ok. Thanks for your quick responses! I should note that I mean reasonable given the current implementation -- you're seeing performance in line with numbers on other machines. I think it's been mentioned that our 3DES implementation has not been tuned for x86, so there's probably some performance being left on the floor. I could be wrong, though. -- Dave Dillow From davem@davemloft.net Tue May 3 12:39:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 12:39:15 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43JdC7J008140 for ; Tue, 3 May 2005 12:39:13 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT33Y-0001hc-00; Tue, 03 May 2005 12:27:44 -0700 Date: Tue, 3 May 2005 12:27:44 -0700 From: "David S. Miller" To: Dave Dillow Cc: miika@iki.fi, kaber@trash.net, netdev@oss.sgi.com Subject: Re: IPsec performance Message-Id: <20050503122744.1e5cafcf.davem@davemloft.net> In-Reply-To: <1115148461.31573.9.camel@dillow.idleaire.com> References: <1115099678.2953.3.camel@ori.thedillows.org> <1115129839.2953.4.camel@ori.thedillows.org> <1115148461.31573.9.camel@dillow.idleaire.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 03 May 2005 15:27:41 -0400 Dave Dillow wrote: > I think it's been mentioned that our 3DES implementation has not been > tuned for x86, so there's probably some performance being left on the > floor. That's right. We only have an optimized AES implementation in assembler, and that's for i386 and x86_64 platforms only. From shemminger@osdl.org Tue May 3 14:05:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:05:48 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43L5g7J011397 for ; Tue, 3 May 2005 14:05:42 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43L5Rs4019254 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 14:05:27 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43L5Rfc016016; Tue, 3 May 2005 14:05:27 -0700 Date: Tue, 3 May 2005 14:05:28 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> In-Reply-To: <20050502200251.38271b61.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 2 May 2005 20:02:51 -0700 "David S. Miller" wrote: > On Mon, 2 May 2005 16:24:05 -0700 > Stephen Hemminger wrote: > > > While I was on vacation, OSDL did some networking changes that seems to aggravate some > > existing bug in the tg3 driver. Could be some VLAN related garbage, not sure. > > > > System is 2 CPU AMD64 and the tg3 is on the motherboard. > > > > I am seeing messages like: > > eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:53:08:18 > > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] > > tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 > > > > Any clues? > > This usually means that there is some DMA corruption. > For example, some bug in the x86_64 IOMMU code or similar > causes a bogus DMA address to be fed to the tg3 or even > worse a DMA mapping is unmapped before tg3 is actually > done with it. > > Please try to get some more debugging. One thing that might > be useful would be a dump of the PCI config and PCI status > registers from PCI config space when that tg3_stop_block > event triggers. It will tell us if there was a master or > slave abort on the PCI bus which would confirm my above > theory. Added call to tg_dump_state() tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 DEBUG: PCI status [02b0] TG3PCI state[000010e2] DEBUG: MAC_MODE[00c04c08] MAC_STATUS[00400003] MAC_EVENT[00001000] MAC_LED_CTRL[00000880] DEBUG: MAC_TX_MODE[00000010] MAC_TX_STATUS[00000008] MAC_RX_MODE[00000004] MAC_RX_STATUS[00000000] DEBUG: SNDDATAI_MODE[00000000] SNDDATAI_STATUS[00000000] SNDDATAI_STATSCTRL[00000003] DEBUG: SNDDATAC_MODE[00000000] DEBUG: SNDBDS_MODE[00000004] SNDBDS_STATUS[00000000] DEBUG: SNDBDI_MODE[00000004] SNDBDI_STATUS[00000000] DEBUG: SNDBDC_MODE[00000000] DEBUG: RCVLPC_MODE[00000000] RCVLPC_STATUS[00000000] RCVLPC_STATSCTRL[00000001] DEBUG: RCVDBDI_MODE[00000010] RCVDBDI_STATUS[00000000] DEBUG: RCVDCC_MODE[00000004] DEBUG: RCVBDI_MODE[00000004] RCVBDI_STATUS[00000000] DEBUG: RCVCC_MODE[00000004] RCVCC_STATUS[00000000] DEBUG: RCVLSC_MODE[00000004] RCVLSC_STATUS[00000000] DEBUG: MBFREE_MODE[00000000] MBFREE_STATUS[00000000] DEBUG: HOSTCC_MODE[00000100] HOSTCC_STATUS[00000000] DEBUG: HOSTCC_STATS_BLK_HOST_ADDR[0000000006bb8000] DEBUG: HOSTCC_STATUS_BLK_HOST_ADDR[000000001ce8c000] DEBUG: HOSTCC_STATS_BLK_NIC_ADDR[00000300] DEBUG: HOSTCC_STATUS_BLK_NIC_ADDR[00000b00] DEBUG: MEMARB_MODE[00000002] MEMARB_STATUS[00000000] DEBUG: BUFMGR_MODE[00000004] BUFMGR_STATUS[00000000] DEBUG: BUFMGR_MB_POOL_ADDR[00008000] BUFMGR_MB_POOL_SIZE[00018000] DEBUG: BUFMGR_DMA_DESC_POOL_ADDR[00002000] BUFMGR_DMA_DESC_POOL_SIZE[00002000] DEBUG: RDMAC_MODE[000003fc] RDMAC_STATUS[00000000] DEBUG: WDMAC_MODE[000003fc] WDMAC_STATUS[00000000] DEBUG: DMAC_MODE[00000000] DEBUG: GRC_MODE[04130034] GRC_MISC_CFG[00081082] DEBUG: GRC_LOCAL_CTRL[01000209] DEBUG: RCVDBDI_JUMBO_BD[0000000000000000:00000002:00000000] DEBUG: RCVDBDI_STD_BD[000000002d1c4000:06000000:00006000] DEBUG: RCVDBDI_MINI_BD[0000000000000000:00000002:00000000] > Also what PCI controller is in this box? (ie. the north bridge, > lspci -v would tell) 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=69 I/O behind bridge: 00002000-00002fff Memory behind bridge: c0100000-c01fffff Capabilities: [c0] HyperTransport: Slave or Primary Interface Capabilities: [f0] HyperTransport: Interrupt Discovery and Configuration 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05) Subsystem: IBM: Unknown device 02b7 Flags: bus master, 66Mhz, medium devsel, latency 0 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 64 I/O ports at 1460 [size=16] 00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02) Subsystem: IBM: Unknown device 02b7 Flags: medium devsel, IRQ 11 I/O ports at 1440 [size=32] 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) Subsystem: IBM: Unknown device 02b7 Flags: medium devsel 00:07.5 Multimedia audio controller: Advanced Micro Devices [AMD] AMD-8111 AC97 Audio (rev 03) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 64, IRQ 169 I/O ports at 1000 [size=256] I/O ports at 1400 [size=64] 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: 00003000-00003fff Memory behind bridge: c0200000-c02fffff Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration Capabilities: [c0] HyperTransport: Slave or Primary Interface 00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 0 Memory at c0000000 (64-bit, non-prefetchable) [size=4K] 00:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=03, subordinate=03, sec-latency=64 Memory behind bridge: c0300000-c03fffff Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 0 Memory at c0001000 (64-bit, non-prefetchable) [size=4K] 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface Capabilities: [a0] HyperTransport: Host or Secondary Interface Capabilities: [c0] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface Capabilities: [a0] HyperTransport: Host or Secondary Interface Capabilities: [c0] HyperTransport: Host or Secondary Interface 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 01:02.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) (prog-if 85) Subsystem: IBM: Unknown device 3512 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 169 I/O ports at 2020 [size=8] I/O ports at 2014 [size=4] I/O ports at 2018 [size=8] I/O ports at 2010 [size=4] I/O ports at 2000 [size=16] Memory at c0104000 (32-bit, non-prefetchable) [size=512] Capabilities: [60] Power Management version 2 01:03.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 64, IRQ 193 Memory at c0102000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 01:03.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 64, IRQ 201 Memory at c0103000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 01:03.2 USB Controller: NEC Corporation USB 2.0 (rev 04) (prog-if 20 [EHCI]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 132, IRQ 185 Memory at c0104400 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 02:01.0 Ethernet controller: Syskonnect (Schneider & Koch) SK-98xx Gigabit Ethernet Server Adapter (rev 13) Subsystem: Syskonnect (Schneider & Koch) SK-9821 Gigabit Ethernet Server Adapter (SK-NET GE-T) Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 10 Memory at c0200000 (32-bit, non-prefetchable) [size=16K] I/O ports at 3000 [size=256] Capabilities: [48] Power Management version 1 Capabilities: [50] Vital Product Data 03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02) Subsystem: IBM: Unknown device 026f Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 177 Memory at c0300000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- 08:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-8151 System Controller (rev 13) Subsystem: IBM: Unknown device 02b7 Flags: medium devsel Memory at d0000000 (32-bit, prefetchable) [size=256M] Capabilities: [a0] AGP version 3.0 Capabilities: [c0] HyperTransport: Slave or Primary Interface 08:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8151 AGP Bridge (rev 13) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 99 Bus: primary=08, secondary=09, subordinate=0d, sec-latency=68 I/O behind bridge: 00004000-00004fff Memory behind bridge: c0700000-c07fffff Prefetchable memory behind bridge: e0000000-efffffff 08:03.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=08, secondary=0e, subordinate=12, sec-latency=64 Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration Capabilities: [c0] HyperTransport: Slave or Primary Interface 08:03.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 0 Memory at c0600000 (64-bit, non-prefetchable) [size=4K] 08:04.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=08, secondary=13, subordinate=17, sec-latency=64 Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration 08:04.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 0 Memory at c0601000 (64-bit, non-prefetchable) [size=4K] 09:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 NG [FireGL X1] (rev 80) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0172 Flags: bus master, stepping, 66Mhz, medium devsel, latency 66, IRQ 5 Memory at e0000000 (32-bit, prefetchable) [size=128M] I/O ports at 4000 [size=256] Memory at c0700000 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 09:00.1 Display controller: ATI Technologies Inc Radeon R300 [FireGL X1] (Secondary) (rev 80) Subsystem: ATI Technologies Inc: Unknown device 0173 Flags: bus master, stepping, 66Mhz, medium devsel, latency 66 Memory at e8000000 (32-bit, prefetchable) [size=128M] Memory at c0710000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 -- Stephen Hemminger > Since AMD promised me an Opteron system last year, but never > made good on that promise, I've never been able to work on > fixing this bug myself. :-/ From davem@davemloft.net Tue May 3 14:24:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:24:38 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LOZ7J012441 for ; Tue, 3 May 2005 14:24:35 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4hf-0002RJ-00; Tue, 03 May 2005 14:13:15 -0700 Date: Tue, 3 May 2005 14:13:14 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050503141314.441c9d75.davem@davemloft.net> In-Reply-To: <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 3 May 2005 14:05:28 -0700 Stephen Hemminger wrote: > 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Buggy 8131 APIC, does the drivers/pci/quirks.c:quirk_amd_8131_ioapic() message: PCI: MSI quirk detected. pci_msi_quirk set. trigger? MSI support recently got added to the tg3.c driver, but it should only register MSI interrupt handling if pci_enable_msi() returns zero. See what it ends up doing, or if you even have a MSI capable tg3.c in your kernel. From shemminger@osdl.org Tue May 3 14:30:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:30:17 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LUB7J013100 for ; Tue, 3 May 2005 14:30:12 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43LTqs4021479 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 14:29:53 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43LTqh4017444; Tue, 3 May 2005 14:29:52 -0700 Date: Tue, 3 May 2005 14:29:52 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050503142952.527c33c5@dxpl.pdx.osdl.net> In-Reply-To: <20050503141314.441c9d75.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 3 May 2005 14:13:14 -0700 "David S. Miller" wrote: > On Tue, 3 May 2005 14:05:28 -0700 > Stephen Hemminger wrote: > > > 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) > > Buggy 8131 APIC, does the drivers/pci/quirks.c:quirk_amd_8131_ioapic() > message: > > PCI: MSI quirk detected. pci_msi_quirk set. yes. that is there. > trigger? MSI support recently got added to the tg3.c driver, but it should > only register MSI interrupt handling if pci_enable_msi() returns zero. There is no call to pci_enable_msi in the 2.6.12-rc3 source > See what it ends up doing, or if you even have a MSI capable tg3.c in > your kernel. From davem@davemloft.net Tue May 3 14:35:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:35:46 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LZb7J013713 for ; Tue, 3 May 2005 14:35:37 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4s0-0002TT-00; Tue, 03 May 2005 14:23:56 -0700 Date: Tue, 3 May 2005 14:23:55 -0700 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, dlstevens@us.ibm.com, netdev@oss.sgi.com Subject: Re: [IPV6] Fix raw socket checksums with IPsec Message-Id: <20050503142355.7f2c7ba5.davem@davemloft.net> In-Reply-To: <20050430123301.GA25174@gondor.apana.org.au> References: <20050430123301.GA25174@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 22:33:01 +1000 Herbert Xu wrote: > I made a mistake in my last patch to the raw socket checksum code. > I used the value of inet->cork.length as the length of the payload. > While this works with normal packets, it breaks down when IPsec is > present since the cork length includes the extension header length. > > So here is a patch to fix the length calculations. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From davem@davemloft.net Tue May 3 14:35:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:35:52 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LZn7J013736 for ; Tue, 3 May 2005 14:35:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4sY-0002Tj-00; Tue, 03 May 2005 14:24:30 -0700 Date: Tue, 3 May 2005 14:24:30 -0700 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPV6] Include ipv6.h for ipv6_addr_set Message-Id: <20050503142430.05ea5437.davem@davemloft.net> In-Reply-To: <20050430073845.GA3515@gondor.apana.org.au> References: <20050430073845.GA3515@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 17:38:45 +1000 Herbert Xu wrote: > This patch includes net/ipv6.h from addrconf.h since it needs > ipv6_addr_set. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From shemminger@osdl.org Tue May 3 14:36:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:36:24 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LaI7J013890 for ; Tue, 3 May 2005 14:36:18 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43La3s4021881 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 14:36:04 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43La3SO017789; Tue, 3 May 2005 14:36:03 -0700 Date: Tue, 3 May 2005 14:36:03 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Fw: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 Message-ID: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Wed, 27 Apr 2005 09:05:29 -0700 From: bugme-daemon@osdl.org To: shemminger@osdl.org Subject: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 http://bugme.osdl.org/show_bug.cgi?id=4554 Summary: /proc/net/route missing info for 127.0.0.1/8 Kernel Version: kernel-2.6.9-5.0.3.EL Status: NEW Severity: normal Owner: shemminger@osdl.org Submitter: alex@milivojevic.org Distribution: CentOS 4 (RHEL4) Hardware Environment: i686 Problem Description: cat /proc/net/route is missing information for 127.0.0.1/8 network (lo interface). On 2.4 kernels, this info was present (just checked on an old RH7.3 machine). It seems to be missing on 2.6 kernels. Bug? Feature? Omission? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From davem@davemloft.net Tue May 3 14:36:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:36:38 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LaV7J014092 for ; Tue, 3 May 2005 14:36:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4tH-0002Tz-00; Tue, 03 May 2005 14:25:15 -0700 Date: Tue, 3 May 2005 14:25:15 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/2] [XFRM] Prevent off-by-one access to xfrm_dispatch Message-Id: <20050503142515.1c3c5d8e.davem@davemloft.net> In-Reply-To: <20050501184731.GJ577@postel.suug.ch> References: <20050501184731.GJ577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sun, 1 May 2005 20:47:31 +0200 Thomas Graf wrote: > Makes the type > XFRM_MSG_MAX check behave correctly to > protect access to xfrm_dispatch. > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From davem@davemloft.net Tue May 3 14:37:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:37:14 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lb97J014769 for ; Tue, 3 May 2005 14:37:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4tw-0002UF-00; Tue, 03 May 2005 14:25:56 -0700 Date: Tue, 3 May 2005 14:25:55 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/2] [XFRM] Cleanup xfrm_msg_min and xfrm_dispatch Message-Id: <20050503142555.5b795eeb.davem@davemloft.net> In-Reply-To: <20050501185548.GK577@postel.suug.ch> References: <20050501185548.GK577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sun, 1 May 2005 20:55:48 +0200 Thomas Graf wrote: > Converts xfrm_msg_min and xfrm_dispatch to use c99 designated > initializers to make greping a little bit easier. Also replaces > two hardcoded message type with meaningful names. > > Signed-off-by: Thomas Graf Applied, thanks. From davem@davemloft.net Tue May 3 14:38:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:38:56 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lcr7J016230 for ; Tue, 3 May 2005 14:38:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4vc-0002Uv-00; Tue, 03 May 2005 14:27:40 -0700 Date: Tue, 3 May 2005 14:27:40 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type Message-Id: <20050503142740.345925ea.davem@davemloft.net> In-Reply-To: <20050430195058.GC577@postel.suug.ch> References: <20050430195058.GC577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 21:50:58 +0200 Thomas Graf wrote: > RTM_MAX is currently set to the maximum reserverd message type plus one > thus being the cause of two bugs for new types being assigned a) given the > new family registers only the NEW command in its reserved block the array > size for per family entries is calculated one entry short and b) given the > new family registers all commands RTM_MAX would point to the first entry > of the block following this one and the rtnetlink receive path would accept > a message type for a nonexisting family. > > This patch changes RTM_MAX to point to the maximum valid message type > by aligning it to the start of the next block and subtracting one. > > Signed-off-by: Thomas Graf Excellent observation. The fact that we encode the "modifies state" in the low bits of the RTM_* numbers has always been a source of obscure bugs and hard to track down errors. Patch applied, thanks. From davem@davemloft.net Tue May 3 14:39:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:39:36 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LdY7J016531 for ; Tue, 3 May 2005 14:39:34 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4wG-0002V8-00; Tue, 03 May 2005 14:28:20 -0700 Date: Tue, 3 May 2005 14:28:20 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/3] [RTNETLINK] Fix & cleanup rtm_min/rtm_max Message-Id: <20050503142820.7a436e58.davem@davemloft.net> In-Reply-To: <20050430195202.GD577@postel.suug.ch> References: <20050430195202.GD577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 21:52:02 +0200 Thomas Graf wrote: > Converts rtm_min and rtm_max arrays to use c99 designated > initializers for easier insertion of new message families. > RTM_GETMULTICAST and RTM_GETANYCAST did not have the minimal > message size specified which means that the netlink message > was parsed for routing attributes starting from the header. > Adds the proper minimal message sizes for these messages > (netlink header + common rtnetlink header) to fix this issue. > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From davem@davemloft.net Tue May 3 14:40:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:40:11 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Le87J016865 for ; Tue, 3 May 2005 14:40:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4wp-0002VO-00; Tue, 03 May 2005 14:28:55 -0700 Date: Tue, 3 May 2005 14:28:54 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 3/3] [RTNETLINK] Cleanup rtnetlink_link tables Message-Id: <20050503142854.7097daec.davem@davemloft.net> In-Reply-To: <20050430195243.GE577@postel.suug.ch> References: <20050430195243.GE577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 21:52:43 +0200 Thomas Graf wrote: > Converts remaining rtnetlink_link tables to use c99 designated > initializers to make greping a little bit easier. > > Signed-off-by: Thomas Graf Applied, thanks a lot. From mchan@broadcom.com Tue May 3 14:40:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:40:24 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LeJ7J016968 for ; Tue, 3 May 2005 14:40:19 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 03 May 2005 14:40:12 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 3 May 2005 14:39:45 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWG12822; Tue, 3 May 2005 14:39:45 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA20331; Tue, 3 May 2005 14:39:44 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 May 2005 21:39:44 +0000 Received: from rh4 by nt-irva-0741; 03 May 2005 13:41:47 -0700 Subject: Re: Mystery packet killing tg3 From: "Michael Chan" To: "David S. Miller" cc: "Stephen Hemminger" , jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050503141314.441c9d75.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> Date: Tue, 03 May 2005 13:41:47 -0700 Message-ID: <1115152907.15156.26.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E6930361MW1668191-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev On Tue, 2005-05-03 at 14:13 -0700, David S. Miller wrote: > On Tue, 3 May 2005 14:05:28 -0700 > Stephen Hemminger wrote: > > > 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) > > Buggy 8131 APIC, does the drivers/pci/quirks.c:quirk_amd_8131_ioapic() > message: > > PCI: MSI quirk detected. pci_msi_quirk set. > > trigger? MSI support recently got added to the tg3.c driver, but it should > only register MSI interrupt handling if pci_enable_msi() returns zero. > > See what it ends up doing, or if you even have a MSI capable tg3.c in > your kernel. > > MSI is buggy on 5703 and tg3 will not enable MSI on that chip. MSI only works on the latest PCI Express chips. From davem@davemloft.net Tue May 3 14:42:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:42:05 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lg37J018239 for ; Tue, 3 May 2005 14:42:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4yc-0002Vq-00; Tue, 03 May 2005 14:30:46 -0700 Date: Tue, 3 May 2005 14:30:46 -0700 From: "David S. Miller" To: Andrew Grover Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Add more explanation to tcp_prequeue comment Message-Id: <20050503143046.6f514dc9.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 28 Apr 2005 14:14:13 -0700 Andrew Grover wrote: > Here's a patch to make that prequeue comment a little clearer. Look ok? Looks great, except that it does not apply cleanly. From davem@davemloft.net Tue May 3 14:44:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:44:32 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Li87J018919 for ; Tue, 3 May 2005 14:44:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT50U-0002Wn-00; Tue, 03 May 2005 14:32:42 -0700 Date: Tue, 3 May 2005 14:32:42 -0700 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: juhl-lkml@dif.dk, netdev@oss.sgi.com, reginak@cyclades.com, pc300@cyclades.com, ncorbic@sangoma.com, eis@baty.hanse.de, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cleanups in drivers/net/wan/ - kfree of NULL pointer is valid Message-Id: <20050503143242.3d06f71f.davem@davemloft.net> In-Reply-To: <20050428222330.GI26945@conectiva.com.br> References: <20050428222330.GI26945@conectiva.com.br> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 28 Apr 2005 19:23:30 -0300 Arnaldo Carvalho de Melo wrote: > Em Fri, Apr 29, 2005 at 12:22:22AM +0200, Jesper Juhl escreveu: > > kfree(0) is perfectly valid, checking pointers for NULL before calling > > kfree() on them is redundant. The patch below cleans away a few such > > redundant checks (and while I was around some of those bits I couldn't > > stop myself from making a few tiny whitespace changes as well). > > > Acked-by: Arnaldo Carvalho de MElo Applied, thanks everyone. From davem@davemloft.net Tue May 3 14:47:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:47:38 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LlZ7J019718 for ; Tue, 3 May 2005 14:47:35 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT541-0002ZW-00; Tue, 03 May 2005 14:36:21 -0700 Date: Tue, 3 May 2005 14:36:20 -0700 From: "David S. Miller" To: folkert@vanheusden.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] optimize check in port-allocation code Message-Id: <20050503143620.43cac50f.davem@davemloft.net> In-Reply-To: <20050428212449.GC8774@vanheusden.com> References: <20050420184419.GM20290@vanheusden.com> <20050424190427.11b4863e.davem@davemloft.net> <20050425061210.GB15167@vanheusden.com> <20050428120824.6cc9b345.davem@davemloft.net> <20050428212449.GC8774@vanheusden.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 28 Apr 2005 23:24:53 +0200 folkert@vanheusden.com wrote: > > > I'll resend it as an attachment (see attachment). > > It still has spaces where there should be tabs, even though > > you compressed the patch and used attachment. > > The diff itself must already be corrupt before you attach > > it. > > Please double check that the patch you submit actually apply, > > this will save me a lot of wasted time. > > Ok, I've redone them and tested if they patch cleanly, they now do. > See them attached. Both patches applied, thanks a lot. From davem@davemloft.net Tue May 3 14:48:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:48:46 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lmf7J020088 for ; Tue, 3 May 2005 14:48:42 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT554-0002aJ-00; Tue, 03 May 2005 14:37:26 -0700 Date: Tue, 3 May 2005 14:37:26 -0700 From: "David S. Miller" To: Jesper Juhl Cc: paulus@samba.org, linux-ppp@vger.kernel.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ppp: remove redundant NULL pointer checks before kfree & vfree Message-Id: <20050503143726.63758ce3.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 29 Apr 2005 00:54:44 +0200 (CEST) Jesper Juhl wrote: > kfree() and vfree() can both deal with NULL pointers. This patch removes > redundant NULL pointer checks from the ppp code in drivers/net/ > > Signed-off-by: Jesper Juhl Applied, thanks Jesper. From davem@davemloft.net Tue May 3 14:50:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:50:50 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lol7J020800 for ; Tue, 3 May 2005 14:50:47 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT574-0002bw-00; Tue, 03 May 2005 14:39:30 -0700 Date: Tue, 3 May 2005 14:39:30 -0700 From: "David S. Miller" To: Asim Shankar Cc: netdev@oss.sgi.com Subject: Re: [RESEND] [PATCH 2.6.11.7] sch_htb: Drop packet when direct queue is full Message-Id: <20050503143930.28650cba.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 29 Apr 2005 17:33:12 +0000 (UTC) Asim Shankar wrote: > htb_enqueue(): Free skb and return NET_XMIT_DROP if a packet is > destined for the direct_queue but the direct_queue is full. (Before > this: erroneously returned NET_XMIT_SUCCESS even though the packet was > not enqueued) > > Signed-off-by: Asim Shankar Applied, thanks Asim. From davem@davemloft.net Tue May 3 14:51:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:51:56 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lpq7J021208 for ; Tue, 3 May 2005 14:51:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT584-0002cr-00; Tue, 03 May 2005 14:40:32 -0700 Date: Tue, 3 May 2005 14:40:32 -0700 From: "David S. Miller" To: Patrick McHardy Cc: tgraf@suug.ch, nicolas.dichtel@6wind.com, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Question about QOS Message-Id: <20050503144032.25ea921d.davem@davemloft.net> In-Reply-To: <427225B2.6010705@trash.net> References: <426E06F1.9000105@6wind.com> <20050426125955.GT577@postel.suug.ch> <426E56DC.7000108@6wind.com> <20050426191454.GU577@postel.suug.ch> <426F42F0.9020609@6wind.com> <20050427114216.GV577@postel.suug.ch> <427225B2.6010705@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 29 Apr 2005 14:16:50 +0200 Patrick McHardy wrote: > Thomas Graf wrote: > > * Nicolas DICHTEL <426F42F0.9020609@6wind.com> 2005-04-27 09:44 > > > >>>Yes I agree, it doesn't really matter what value we return and `bound' > >>>is most likely to be correct. I think we should also fix the unlikely > >>>but still possible case when tv1.tv_usec is slightly smaller than > >>>tv2.tv_usec. I know it is very unlikely but do_gettimeofday really > >>>is not that reliable and we have users which rely on a positive > >>>delta. Can you extend your patch to return abs(delta) for case 0 > >>>in PSCHED_TDIFF_SAFE? > > Why abs(delta)? It could be above bound, in fact all cases besides > delta_sec > 2 doesn't take care to stay inside [0..bound] at all. Applied, thanks Patrick. From davem@davemloft.net Tue May 3 14:52:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:52:57 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lqs7J021708 for ; Tue, 3 May 2005 14:52:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT58m-0002cv-00; Tue, 03 May 2005 14:41:16 -0700 Date: Tue, 3 May 2005 14:41:15 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.4 6/6][SCTP] Fix SCTP sendbuffer accouting. Message-Id: <20050503144115.0d03ae87.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Sridhar, I will apply all of these as soon as Marcelo has his GIT tree setup for the 2.4.x kernel. They all look perfectly fine and thanks for remembering to update the default sysctl setting for socket based accounting. From davem@davemloft.net Tue May 3 14:54:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:54:09 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Ls57J022274 for ; Tue, 3 May 2005 14:54:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT5AC-0002eQ-00; Tue, 03 May 2005 14:42:44 -0700 Date: Tue, 3 May 2005 14:42:44 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [NETLINK] cb_lock does not needs ref count on sk Message-Id: <20050503144244.1efdfd0c.davem@davemloft.net> In-Reply-To: <20050401093633.GA32707@gondor.apana.org.au> References: <20050327091524.GA23215@elte.hu> <20050327133811.GA5569@elte.hu> <20050329104906.GA19836@gondor.apana.org.au> <20050329114926.GA14986@elte.hu> <20050330082640.GA8269@gondor.apana.org.au> <20050330170236.2bddf666.davem@davemloft.net> <20050331231922.GA26587@gondor.apana.org.au> <20050331232322.GA26693@gondor.apana.org.au> <20050331203313.57e1c5c3.davem@davemloft.net> <20050401093633.GA32707@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 1 Apr 2005 19:36:33 +1000 Herbert Xu wrote: > Here is a little optimisation for the cb_lock used by netlink_dump. > While fixing that race earlier, I noticed that the reference count > held by cb_lock is completely useless. The reason is that in order > to obtain the protection of the reference count, you have to take > the cb_lock. But the only way to take the cb_lock is through > dereferencing the socket. > > That is, you must already possess a reference count on the socket > before you can take advantage of the reference count held by cb_lock. > As a corollary, we can remve the reference count held by the cb_lock. > > Signed-off-by: Herbert Xu Looks good, applied. From davem@davemloft.net Tue May 3 15:14:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:14:54 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MEo7J023977 for ; Tue, 3 May 2005 15:14:51 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT5UL-0002rN-00; Tue, 03 May 2005 15:03:33 -0700 Date: Tue, 3 May 2005 15:03:33 -0700 From: "David S. Miller" To: "Michael Chan" Cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050503150333.1ac1c159.davem@davemloft.net> In-Reply-To: <1115152907.15156.26.camel@rh4> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 03 May 2005 13:41:47 -0700 "Michael Chan" wrote: > MSI is buggy on 5703 and tg3 will not enable MSI on that chip. MSI only > works on the latest PCI Express chips. Ok, and he has a pre-MSI copy of the tg3 driver anyways. Michael, there were no master/target abort bits set in the PCI status register from his dump. If one of the DMA units locks up on the tg3, will it still be able to update the PCI_STATUS register appropriately when it encounters a DMA transaction error (ie. master or target abort) or would we also need to look at the PCI host bridge PCI config space registers as well? I strongly suspect one of two things in these AMD system cases of tg3 wedging: 1) some DMA problem 2) register write reordering Lack of master/target abort indication in tg3's PCI status register makes me feel that #2 is more likely to be the problem cause. Just for fun, Stephen, can you make tg3_get_invariants() always set the TG3_FLAG_MBOX_WRITE_REORDER bit in tp->tg3_flags and see if that makes the problem go away? Thanks. From tgraf@suug.ch Tue May 3 15:19:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:20:01 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MJu7J024679 for ; Tue, 3 May 2005 15:19:57 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B2CDB1C0EB; Wed, 4 May 2005 00:20:03 +0200 (CEST) Date: Wed, 4 May 2005 00:20:03 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type Message-ID: <20050503222003.GQ577@postel.suug.ch> References: <20050430195058.GC577@postel.suug.ch> <20050503142740.345925ea.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503142740.345925ea.davem@davemloft.net> X-archive-position: 635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * David S. Miller <20050503142740.345925ea.davem@davemloft.net> 2005-05-03 14:27 > Excellent observation. The fact that we encode the "modifies state" > in the low bits of the RTM_* numbers has always been a source of > obscure bugs and hard to track down errors. > > Patch applied, thanks. Do you want 2.4 backports for all patches or just the xfrm off-by-one fix? From mchan@broadcom.com Tue May 3 15:26:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:26:42 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MQd7J025434 for ; Tue, 3 May 2005 15:26:40 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 03 May 2005 15:26:25 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 3 May 2005 15:26:12 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWG24966; Tue, 3 May 2005 15:26:08 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA05094; Tue, 3 May 2005 15:26:08 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 May 2005 22:26:07 +0000 Received: from rh4 by nt-irva-0741; 03 May 2005 14:28:10 -0700 Subject: Re: Mystery packet killing tg3 From: "Michael Chan" To: "David S. Miller" cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050503150333.1ac1c159.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> Date: Tue, 03 May 2005 14:28:10 -0700 Message-ID: <1115155690.15156.32.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E69251B0UW1602596-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev On Tue, 2005-05-03 at 15:03 -0700, David S. Miller wrote: > Michael, there were no master/target abort bits set in the PCI status > register from his dump. If one of the DMA units locks up on the tg3, > will it still be able to update the PCI_STATUS register appropriately > when it encounters a DMA transaction error (ie. master or target abort) I believe so. Also, the DMA read and write status registers showed all zeros, meaning there were no DMA related errors: DEBUG: RDMAC_MODE[000003fc] RDMAC_STATUS[00000000] DEBUG: WDMAC_MODE[000003fc] WDMAC_STATUS[00000000] From tommy.christensen@tpack.net Tue May 3 15:31:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:31:19 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j43MVF7J026089 for ; Tue, 3 May 2005 15:31:16 -0700 Received: (qmail 6494 invoked from network); 3 May 2005 22:31:00 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.6) by 0 with SMTP; 3 May 2005 22:31:00 -0000 Message-ID: <4277FC16.4050307@tpack.net> Date: Wed, 04 May 2005 00:32:54 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> In-Reply-To: <20050503100306.GB29788@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------060107070809070404040805" X-archive-position: 637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------060107070809070404040805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Doing the wait when IFF_RUNNING is off isn't necessary though. If > IFF_RUNNING isn't set, then either the device has never been activated > or we've already carried out those waits the last time we were in > dev_deactivate. Right. But it still depends on what the synchronization is meant to protect us from. It isn't clear to me, whether it's o packets in flight o qdisc references o device references so yes, I tried to play it safe. Anyway, given the comments from Thomas, I've pulled out the IFF_RUNNING stuff. We can add this later, when the other uses have been sorted out. > I understand your preference for defensive programming. However, in > cases like this it's better to do the obvious thing because: > > 1) We don't cover up bugs that may come back to bite us elsewhere. > 2) We don't give people misconceptions. If they're unfamiliar with > the system they may infer things from this code that aren't necessarily > the case. I totally agree with this. -Tommy --------------060107070809070404040805 Content-Type: text/plain; name="carrier-5.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="carrier-5.patch" diff -ru linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-work/net/core/link_watch.c --- linux-2.6.12-rc3/net/core/link_watch.c 2005-03-04 09:55:42.000000000 +0100 +++ linux-2.6.12-work/net/core/link_watch.c 2005-05-02 22:40:59.000000000 +0200 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -74,6 +75,12 @@ clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); if (dev->flags & IFF_UP) { + if (netif_carrier_ok(dev)) { + WARN_ON(dev->qdisc_sleeping == &noop_qdisc); + dev_activate(dev); + } else + dev_deactivate(dev); + netdev_state_change(dev); } diff -ru linux-2.6.12-rc3/net/sched/sch_generic.c linux-2.6.12-work/net/sched/sch_generic.c --- linux-2.6.12-rc3/net/sched/sch_generic.c 2005-03-04 09:55:44.000000000 +0100 +++ linux-2.6.12-work/net/sched/sch_generic.c 2005-05-04 00:24:55.558105856 +0200 @@ -539,6 +539,10 @@ write_unlock_bh(&qdisc_tree_lock); } + if (!netif_carrier_ok(dev)) + /* Delay activation until next carrier-on event */ + return; + spin_lock_bh(&dev->queue_lock); rcu_assign_pointer(dev->qdisc, dev->qdisc_sleeping); if (dev->qdisc != &noqueue_qdisc) { --------------060107070809070404040805-- From davem@davemloft.net Tue May 3 15:38:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:38:27 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43McN7J026725 for ; Tue, 3 May 2005 15:38:24 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT5r6-00036a-00; Tue, 03 May 2005 15:27:04 -0700 Date: Tue, 3 May 2005 15:27:04 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type Message-Id: <20050503152704.4c6744d6.davem@davemloft.net> In-Reply-To: <20050503222003.GQ577@postel.suug.ch> References: <20050430195058.GC577@postel.suug.ch> <20050503142740.345925ea.davem@davemloft.net> <20050503222003.GQ577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 4 May 2005 00:20:03 +0200 Thomas Graf wrote: > * David S. Miller <20050503142740.345925ea.davem@davemloft.net> 2005-05-03 14:27 > > Excellent observation. The fact that we encode the "modifies state" > > in the low bits of the RTM_* numbers has always been a source of > > obscure bugs and hard to track down errors. > > > > Patch applied, thanks. > > Do you want 2.4 backports for all patches or just the xfrm > off-by-one fix? Congratulations if you can find xfrm in the vanilla 2.4.x tree :-) From kaber@trash.net Tue May 3 15:41:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:41:26 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MfM7J027259 for ; Tue, 3 May 2005 15:41:23 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT64b-0005HH-9q; Wed, 04 May 2005 00:41:01 +0200 Message-ID: <4277FDFD.3040501@trash.net> Date: Wed, 04 May 2005 00:41:01 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Fw: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> In-Reply-To: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev > Distribution: CentOS 4 (RHEL4) > Hardware Environment: i686 > Problem Description: > cat /proc/net/route is missing information for 127.0.0.1/8 network (lo > interface). On 2.4 kernels, this info was present (just checked on an old RH7.3 > machine). It seems to be missing on 2.6 kernels. Bug? Feature? Omission? 2.4.30 doesn't show it: # route -n Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 And I'd be surprised if it did, it doesn't include other routes from the local table. Regards Patrick From shemminger@osdl.org Tue May 3 15:45:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:45:20 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MjG7J027930 for ; Tue, 3 May 2005 15:45:16 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43Mj1s4027705 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 15:45:01 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43Mj03M021716; Tue, 3 May 2005 15:45:00 -0700 Date: Tue, 3 May 2005 15:45:00 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: "Michael Chan" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050503154500.0a53160d@dxpl.pdx.osdl.net> In-Reply-To: <20050503150333.1ac1c159.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 3 May 2005 15:03:33 -0700 "David S. Miller" wrote: > On Tue, 03 May 2005 13:41:47 -0700 > "Michael Chan" wrote: > > > MSI is buggy on 5703 and tg3 will not enable MSI on that chip. MSI only > > works on the latest PCI Express chips. > > Ok, and he has a pre-MSI copy of the tg3 driver anyways. > > Michael, there were no master/target abort bits set in the PCI status > register from his dump. If one of the DMA units locks up on the tg3, > will it still be able to update the PCI_STATUS register appropriately > when it encounters a DMA transaction error (ie. master or target abort) > or would we also need to look at the PCI host bridge PCI config space > registers as well? > > I strongly suspect one of two things in these AMD system cases of tg3 > wedging: > > 1) some DMA problem > 2) register write reordering > > Lack of master/target abort indication in tg3's PCI status register > makes me feel that #2 is more likely to be the problem cause. > > Just for fun, Stephen, can you make tg3_get_invariants() always set > the TG3_FLAG_MBOX_WRITE_REORDER bit in tp->tg3_flags and see if that > makes the problem go away? No, I forced it to always be true and still dies (when taking network down). From shemminger@osdl.org Tue May 3 15:47:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:47:29 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MlN7J028643 for ; Tue, 3 May 2005 15:47:25 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43Ml9s4027974 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 15:47:09 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43Ml90C021970; Tue, 3 May 2005 15:47:09 -0700 Date: Tue, 3 May 2005 15:47:09 -0700 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 Message-ID: <20050503154709.218626c6@dxpl.pdx.osdl.net> In-Reply-To: <4277FDFD.3040501@trash.net> References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> <4277FDFD.3040501@trash.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 04 May 2005 00:41:01 +0200 Patrick McHardy wrote: > > Distribution: CentOS 4 (RHEL4) > > Hardware Environment: i686 > > Problem Description: > > cat /proc/net/route is missing information for 127.0.0.1/8 network (lo > > interface). On 2.4 kernels, this info was present (just checked on an old RH7.3 > > machine). It seems to be missing on 2.6 kernels. Bug? Feature? Omission? > > 2.4.30 doesn't show it: > > # route -n > Destination Gateway Genmask Flags Metric Ref Use > Iface > 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 > > And I'd be surprised if it did, it doesn't include other routes > from the local table. > > Regards > Patrick It shows up on our 2.4.18 system, probably it got lost in the fib/seq_printf conversion. $ /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.159.0 172.20.4.11 255.255.255.0 UG 0 0 0 eth2 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth2 From davem@davemloft.net Tue May 3 15:51:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:51:29 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MpD7J029227 for ; Tue, 3 May 2005 15:51:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT63W-0003DL-00; Tue, 03 May 2005 15:39:54 -0700 Date: Tue, 3 May 2005 15:39:54 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: mchan@broadcom.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050503153954.6be62f8a.davem@davemloft.net> In-Reply-To: <20050503154500.0a53160d@dxpl.pdx.osdl.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> <20050503154500.0a53160d@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 3 May 2005 15:45:00 -0700 Stephen Hemminger wrote: > No, I forced it to always be true and still dies (when taking network down). You're reproducing this pretty fast. Does the link jam up, or are you just simply downing the interface and the stop block messages are printed out? If it jams up, what kind of traffic are you using to trigger this problem? From arnaldo.melo@gmail.com Tue May 3 15:55:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:55:34 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MtU7J029832 for ; Tue, 3 May 2005 15:55:30 -0700 Received: by zproxy.gmail.com with SMTP id 8so70799nzo for ; Tue, 03 May 2005 15:55:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EssaBc0T4Oa4KTpnaaDKfe94z3pCBm6L+6fbFu/4k+h4D+j5rSCJX2KjQ/WSADrS7ySTCmsMofWgCqUcu6rQpO+Uc0Z67wgB6agiRKCD9/kntyki3zKJzwjQ29YlFJEJ7DKaKRHzJTk0I9+QhpdzG8Oj6Hi/yEuZG0aMKHvt7R8= Received: by 10.36.61.5 with SMTP id j5mr50102nza; Tue, 03 May 2005 15:55:15 -0700 (PDT) Received: by 10.36.56.15 with HTTP; Tue, 3 May 2005 15:55:15 -0700 (PDT) Message-ID: <39e6f6c70505031555691daf80@mail.gmail.com> Date: Tue, 3 May 2005 19:55:15 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@ghostprotocols.net To: Stephen Hemminger Subject: Re: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 Cc: Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050503154709.218626c6@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> <4277FDFD.3040501@trash.net> <20050503154709.218626c6@dxpl.pdx.osdl.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j43MtU7J029832 X-archive-position: 643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On 5/3/05, Stephen Hemminger wrote: > On Wed, 04 May 2005 00:41:01 +0200 > Patrick McHardy wrote: > > > > Distribution: CentOS 4 (RHEL4) > > > Hardware Environment: i686 > > > Problem Description: > > > cat /proc/net/route is missing information for 127.0.0.1/8 network (lo > > > interface). On 2.4 kernels, this info was present (just checked on an old RH7.3 > > > machine). It seems to be missing on 2.6 kernels. Bug? Feature? Omission? > > > > 2.4.30 doesn't show it: > > > > # route -n > > Destination Gateway Genmask Flags Metric Ref Use > > Iface > > 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 > > > > And I'd be surprised if it did, it doesn't include other routes > > from the local table. > > > > Regards > > Patrick > > It shows up on our 2.4.18 system, probably it got lost in the fib/seq_printf > conversion. > > $ /sbin/route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 192.168.159.0 172.20.4.11 255.255.255.0 UG 0 0 0 eth2 > 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth2 [root@toy acme]# route -n Tabela de Roteamento IP do Kernel Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 eth0 [root@toy acme]# uname -r 2.6.11-77124cl [root@toy acme]# [root@toy acme]# ip r s 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.192 172.20.0.0/16 dev tun0 proto kernel scope link src 172.20.0.1 127.0.0.0/8 dev lo scope link default via 192.168.1.2 dev eth0 [root@toy acme]# [root@toy acme]# cat /proc/net/route Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0 0001A8C0 00000000 0001 0 0 0 00FFFFFF 0 0 0 tun0 000014AC 00000000 0001 0 0 0 0000FFFF 0 0 0 lo 0000007F 00000000 0001 0 0 0 000000FF 0 0 0 eth0 00000000 0201A8C0 0003 0 0 0 00000000 0 0 0 [root@toy acme]# No problems here. - Arnaldo From kaber@trash.net Tue May 3 15:58:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:58:49 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Mwj7J030458 for ; Tue, 3 May 2005 15:58:45 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT6LQ-0005jH-9G; Wed, 04 May 2005 00:58:24 +0200 Message-ID: <42780210.2070607@trash.net> Date: Wed, 04 May 2005 00:58:24 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> <4277FDFD.3040501@trash.net> <20050503154709.218626c6@dxpl.pdx.osdl.net> In-Reply-To: <20050503154709.218626c6@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 644 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Stephen Hemminger wrote: > It shows up on our 2.4.18 system, probably it got lost in the fib/seq_printf > conversion. > > $ /sbin/route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 192.168.159.0 172.20.4.11 255.255.255.0 UG 0 0 0 eth2 > 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth2 2.4.18 looks similar to 2.4.30 in fib_get_procinfo(), fib_magic() and other functions involved. I believe its simply a change of how userspace sets up the routes: # route -n 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 172.16.0.1 0.0.0.0 UG 0 0 0 eth0 # route add -net 127.0.0.0/8 lo # route -n 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 172.16.0.1 0.0.0.0 UG 0 0 0 eth0 "route" seems to add all routes to the main table. My debian system relies on the kernel setting up loopback correctly, so it doesn't add a route itself. Regards Patrick From shemminger@osdl.org Tue May 3 15:59:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:59:32 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MxR7J030564 for ; Tue, 3 May 2005 15:59:27 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43MxBs4028946 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 15:59:12 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43MxBfU022627; Tue, 3 May 2005 15:59:11 -0700 Date: Tue, 3 May 2005 15:59:11 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: mchan@broadcom.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050503155911.766409c3@dxpl.pdx.osdl.net> In-Reply-To: <20050503153954.6be62f8a.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> <20050503154500.0a53160d@dxpl.pdx.osdl.net> <20050503153954.6be62f8a.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 3 May 2005 15:39:54 -0700 "David S. Miller" wrote: > On Tue, 3 May 2005 15:45:00 -0700 > Stephen Hemminger wrote: > > > No, I forced it to always be true and still dies (when taking network down). > > You're reproducing this pretty fast. > > Does the link jam up, or are you just simply downing the interface > and the stop block messages are printed out? Initially, it reproduced everytime link came up, we reconfigured the VLAN to have a mirror port into a laptop to try and capture what was happening, but when we did that the bootup problem went away. It was in the tg3_reset_hw during initial dev_open. Today it only triggers when I force it by doing something does a dev_close (like ifconfig or rmmod). Since the message is the same, I assume it is the same or similar problem. > If it jams up, what kind of traffic are you using to trigger this > problem? No traffic is present when the close occurs. But some DMA could be stuck (forever) in flight at that point. From tgraf@suug.ch Tue May 3 16:02:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:02:13 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43N297J031696 for ; Tue, 3 May 2005 16:02:09 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 186A01C0EB; Wed, 4 May 2005 01:02:18 +0200 (CEST) Date: Wed, 4 May 2005 01:02:17 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type Message-ID: <20050503230217.GR577@postel.suug.ch> References: <20050430195058.GC577@postel.suug.ch> <20050503142740.345925ea.davem@davemloft.net> <20050503222003.GQ577@postel.suug.ch> <20050503152704.4c6744d6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503152704.4c6744d6.davem@davemloft.net> X-archive-position: 646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * David S. Miller <20050503152704.4c6744d6.davem@davemloft.net> 2005-05-03 15:27 > On Wed, 4 May 2005 00:20:03 +0200 > Thomas Graf wrote: > > > * David S. Miller <20050503142740.345925ea.davem@davemloft.net> 2005-05-03 14:27 > > > Excellent observation. The fact that we encode the "modifies state" > > > in the low bits of the RTM_* numbers has always been a source of > > > obscure bugs and hard to track down errors. > > > > > > Patch applied, thanks. > > > > Do you want 2.4 backports for all patches or just the xfrm > > off-by-one fix? > > Congratulations if you can find xfrm in the vanilla > 2.4.x tree :-) Heh, ok ok ;-> I think none of the patches need to be backported then, although the type > RTM_MAX has an off-by-one issue the current RTM_MAX is set to one below the start of the next block so the behaviour matches the 2.6 tree. From davem@davemloft.net Tue May 3 16:05:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:05:19 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43N5F7J032273 for ; Tue, 3 May 2005 16:05:15 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6H6-0003Js-00; Tue, 03 May 2005 15:53:56 -0700 Date: Tue, 3 May 2005 15:53:55 -0700 From: "David S. Miller" To: "Michael Chan" Cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050503155355.6ac3f4a6.davem@davemloft.net> In-Reply-To: <1115155690.15156.32.camel@rh4> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> <1115155690.15156.32.camel@rh4> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 03 May 2005 14:28:10 -0700 "Michael Chan" wrote: > On Tue, 2005-05-03 at 15:03 -0700, David S. Miller wrote: > > > Michael, there were no master/target abort bits set in the PCI status > > register from his dump. If one of the DMA units locks up on the tg3, > > will it still be able to update the PCI_STATUS register appropriately > > when it encounters a DMA transaction error (ie. master or target abort) > > I believe so. Also, the DMA read and write status registers showed all > zeros, meaning there were no DMA related errors: > > DEBUG: RDMAC_MODE[000003fc] RDMAC_STATUS[00000000] > DEBUG: WDMAC_MODE[000003fc] WDMAC_STATUS[00000000] Right, I noticed that too. Stephen says that trying to force enable the mailbox write reordering workaround doesn't solve the problem either. I wonder exactly how it would show up if the x86_64 port unmapped a DMA address in the IOMMU and tg3 (or a bridge in the middle) tried to fetch that address again. I remember some issue not too long ago where PCI bridges could still prefetch a DMA address even after a device was done with it. Because of this, they added code to the x86_64 IOMMU driver that kept a read-only dummy mapping around all the time so that this would not cause faults. I even added similar code to the PCI IOMMU handling on sparc64. Indeed, if you look in arch/x86_64/kernel/pci-gart.c they use a scratch mapping when the unmap DMA translations. I can't think of what else could be wedging the tg3. Michael, any ideas? There are some 5703 specific programming to consider: 1) Setting of PCIX_CAPS_BURST_MASK in PCI_X_CAPS register. Currently tg3 sets it to "PCIX_CAPS_MAX_BURST_CPIOB" which is 2 (shifted up PCIX_CAPS_BURST_SHIFT of course). 2) On Fibre, we force a write of 0x616000 to MAC_SERDES_CFG for 5703 chips. Because the PCS synced indication is on in his dumps, I am assuming he is on a Fibre link, so this is relevant. 3) When the low 5 bits of TG3PCI_CLOCK_CTRL are 0x6 or 0x7 we set DMA_RWCTL_ONE_DMA in the DMA R/W control register. On all 5703 we also set bit 23 to enable some hw bug workaround. 4) On 5703 (and 5704), we always clear the low 4 bits of DMA R/W control. A quick perusal shows that these same exact things get done in the bcm5700 driver too. From tgraf@suug.ch Tue May 3 16:08:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:08:22 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43N8G7J000429 for ; Tue, 3 May 2005 16:08:19 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 46F211C0EB; Wed, 4 May 2005 01:08:24 +0200 (CEST) Date: Wed, 4 May 2005 01:08:24 +0200 From: Thomas Graf To: acme@ghostprotocols.net Cc: Stephen Hemminger , Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 Message-ID: <20050503230824.GS577@postel.suug.ch> References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> <4277FDFD.3040501@trash.net> <20050503154709.218626c6@dxpl.pdx.osdl.net> <39e6f6c70505031555691daf80@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <39e6f6c70505031555691daf80@mail.gmail.com> X-archive-position: 648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Arnaldo Carvalho de Melo <39e6f6c70505031555691daf80@mail.gmail.com> 2005-05-03 19:55 > [root@toy acme]# route -n > Tabela de Roteamento IP do Kernel > Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 eth0 > [root@toy acme]# uname -r > 2.6.11-77124cl > [root@toy acme]# > > [root@toy acme]# ip r s > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.192 > 172.20.0.0/16 dev tun0 proto kernel scope link src 172.20.0.1 > 127.0.0.0/8 dev lo scope link > default via 192.168.1.2 dev eth0 Your distribution, scripts, whatever doesn't use the local table for the loopback route. This gets to be a problem once you add fib rules and rely on the fact that local routes should have top priority. > [root@toy acme]# > > [root@toy acme]# cat /proc/net/route > Iface Destination Gateway Flags RefCnt Use Metric > Mask MTU Window IRTT > eth0 0001A8C0 00000000 0001 0 0 0 > 00FFFFFF 0 0 0 > tun0 000014AC 00000000 0001 0 0 0 > 0000FFFF 0 0 0 > lo 0000007F 00000000 0001 0 0 0 > 000000FF 0 0 0 > eth0 00000000 0201A8C0 0003 0 0 0 > 00000000 0 0 0 > [root@toy acme]# Yes, that's the main routing table. This is a userspace issue. From herbert@gondor.apana.org.au Tue May 3 16:10:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:10:58 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NAn7J000853 for ; Tue, 3 May 2005 16:10:50 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DT6X4-0002ow-00; Wed, 04 May 2005 09:10:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DT6X1-0004lw-00; Wed, 04 May 2005 09:10:23 +1000 Date: Wed, 4 May 2005 09:10:23 +1000 To: Tommy Christensen Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-ID: <20050503231023.GA18323@gondor.apana.org.au> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <4277FC16.4050307@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4277FC16.4050307@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Wed, May 04, 2005 at 12:32:54AM +0200, Tommy Christensen wrote: > > Anyway, given the comments from Thomas, I've pulled out the IFF_RUNNING > stuff. We can add this later, when the other uses have been sorted out. Thanks Tommy. This version looks good to me. BTW, you probably should add a Signed-off-by line. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Tue May 3 16:22:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:22:13 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NMA7J005165 for ; Tue, 3 May 2005 16:22:10 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6XC-0003PT-00; Tue, 03 May 2005 16:10:34 -0700 Date: Tue, 3 May 2005 16:10:34 -0700 From: "David S. Miller" To: Herbert Xu Cc: tommy.christensen@tpack.net, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-Id: <20050503161034.1fc3ec38.davem@davemloft.net> In-Reply-To: <20050503231023.GA18323@gondor.apana.org.au> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <4277FC16.4050307@tpack.net> <20050503231023.GA18323@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 4 May 2005 09:10:23 +1000 Herbert Xu wrote: > On Wed, May 04, 2005 at 12:32:54AM +0200, Tommy Christensen wrote: > > > > Anyway, given the comments from Thomas, I've pulled out the IFF_RUNNING > > stuff. We can add this later, when the other uses have been sorted out. > > Thanks Tommy. This version looks good to me. BTW, you probably > should add a Signed-off-by line. Yes, please provide this and I'll happily apply this patch. Thanks. From tommy.christensen@tpack.net Tue May 3 16:26:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:26:49 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j43NQi7J005769 for ; Tue, 3 May 2005 16:26:44 -0700 Received: (qmail 15375 invoked from network); 3 May 2005 23:26:30 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.6) by 0 with SMTP; 3 May 2005 23:26:30 -0000 Message-ID: <42780918.10001@tpack.net> Date: Wed, 04 May 2005 01:28:24 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <4277FC16.4050307@tpack.net> <20050503231023.GA18323@gondor.apana.org.au> In-Reply-To: <20050503231023.GA18323@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------060507010509040804020203" X-archive-position: 651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------060507010509040804020203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Thanks Tommy. This version looks good to me. BTW, you probably > should add a Signed-off-by line. Sigh. I remembered on all but the final patch ... Thanks for helping out. Signed-off-by: Tommy S. Christensen --------------060507010509040804020203 Content-Type: text/plain; name="carrier-5.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="carrier-5.patch" diff -ru linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-work/net/core/link_watch.c --- linux-2.6.12-rc3/net/core/link_watch.c 2005-03-04 09:55:42.000000000 +0100 +++ linux-2.6.12-work/net/core/link_watch.c 2005-05-02 22:40:59.000000000 +0200 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -74,6 +75,12 @@ clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); if (dev->flags & IFF_UP) { + if (netif_carrier_ok(dev)) { + WARN_ON(dev->qdisc_sleeping == &noop_qdisc); + dev_activate(dev); + } else + dev_deactivate(dev); + netdev_state_change(dev); } diff -ru linux-2.6.12-rc3/net/sched/sch_generic.c linux-2.6.12-work/net/sched/sch_generic.c --- linux-2.6.12-rc3/net/sched/sch_generic.c 2005-03-04 09:55:44.000000000 +0100 +++ linux-2.6.12-work/net/sched/sch_generic.c 2005-05-04 00:24:55.558105856 +0200 @@ -539,6 +539,10 @@ write_unlock_bh(&qdisc_tree_lock); } + if (!netif_carrier_ok(dev)) + /* Delay activation until next carrier-on event */ + return; + spin_lock_bh(&dev->queue_lock); rcu_assign_pointer(dev->qdisc, dev->qdisc_sleeping); if (dev->qdisc != &noqueue_qdisc) { --------------060507010509040804020203-- From shemminger@osdl.org Tue May 3 16:27:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:27:43 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NRd7J006133 for ; Tue, 3 May 2005 16:27:40 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43NRLs4031825 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 16:27:21 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43NRL7d024965; Tue, 3 May 2005 16:27:21 -0700 Date: Tue, 3 May 2005 16:25:50 -0700 From: Stephen Hemminger To: "David S. Miller" , Patrick McHardy Cc: netdev@oss.sgi.com, netem@osdl.org Subject: [PATCH] (3/3) netem: adjust parent qlen when duplicating Message-ID: <20050503162550.30acf31a@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 653 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Fix qlen underrun when doing duplication with netem. If netem is used as leaf discipline, then the parent needs to be tweaked when packets are duplicated. Signed-off-by: Stephen Hemminger Index: netem-2.6.12-rc3/net/sched/sch_api.c =================================================================== --- netem-2.6.12-rc3.orig/net/sched/sch_api.c 2005-05-03 11:19:23.000000000 -0700 +++ netem-2.6.12-rc3/net/sched/sch_api.c 2005-05-03 15:20:59.000000000 -0700 @@ -1289,6 +1289,7 @@ subsys_initcall(pktsched_init); +EXPORT_SYMBOL(qdisc_lookup); EXPORT_SYMBOL(qdisc_get_rtab); EXPORT_SYMBOL(qdisc_put_rtab); EXPORT_SYMBOL(register_qdisc); Index: netem-2.6.12-rc3/net/sched/sch_netem.c =================================================================== --- netem-2.6.12-rc3.orig/net/sched/sch_netem.c 2005-05-03 11:20:05.000000000 -0700 +++ netem-2.6.12-rc3/net/sched/sch_netem.c 2005-05-03 15:41:14.000000000 -0700 @@ -206,7 +206,6 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); - struct sk_buff *skb2; int ret; pr_debug("netem_enqueue skb=%p\n", skb); @@ -220,11 +219,21 @@ } /* Random duplication */ - if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor) - && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { - pr_debug("netem_enqueue: dup %p\n", skb2); + if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor)) { + struct sk_buff *skb2; + + skb2 = skb_clone(skb, GFP_ATOMIC); + if (skb2 && netem_delay(sch, skb2) == NET_XMIT_SUCCESS) { + struct Qdisc *qp; + + /* Since one packet can generate two packets in the + * queue, the parent's qlen accounting gets confused, + * so fix it. + */ + qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); + if (qp) + qp->q.qlen++; - if (netem_delay(sch, skb2)) { sch->q.qlen++; sch->bstats.bytes += skb2->len; sch->bstats.packets++; @@ -253,6 +262,7 @@ } else sch->qstats.drops++; + pr_debug("netem: enqueue ret %d\n", ret); return ret; } From shemminger@osdl.org Tue May 3 16:27:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:27:37 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NRX7J006047 for ; Tue, 3 May 2005 16:27:33 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43NRIs4031817 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 16:27:18 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43NRIds024931; Tue, 3 May 2005 16:27:18 -0700 Date: Tue, 3 May 2005 16:27:18 -0700 From: Stephen Hemminger To: "David S. Miller" , Patrick McHardy Cc: netdev@oss.sgi.com, netem@osdl.org Subject: [PATCH] (1/3) netetm: trap infinite loop hange on qlen underflow Message-ID: <20050503162718.6a670800@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Due to bugs in netem (fixed by later patches), it is possible to get qdisc qlen to go negative. If this happens the CPU ends up spinning forever in qdisc_run(). So add a BUG_ON() to trap it. Signed-off-by: Stephen Hemminger Index: netem-2.6.12-rc3/net/sched/sch_generic.c =================================================================== --- netem-2.6.12-rc3.orig/net/sched/sch_generic.c 2005-05-03 10:55:50.000000000 -0700 +++ netem-2.6.12-rc3/net/sched/sch_generic.c 2005-05-03 10:56:01.000000000 -0700 @@ -179,6 +179,7 @@ netif_schedule(dev); return 1; } + BUG_ON((int) q->q.qlen < 0); return q->q.qlen; } From shemminger@osdl.org Tue May 3 16:27:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:27:46 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NRe7J006139 for ; Tue, 3 May 2005 16:27:40 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43NRLs4031827 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 16:27:21 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43NRLq1024967; Tue, 3 May 2005 16:27:21 -0700 Date: Tue, 3 May 2005 16:27:09 -0700 From: Stephen Hemminger To: "David S. Miller" , Patrick McHardy Cc: netdev@oss.sgi.com, netem@lists.osdl.org Subject: [PATCH] (2/3) netem: make qdisc friendly to outer disciplines Message-ID: <20050503162709.5c0315ec@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Netem currently dumps packets into the queue when timer expires. This patch makes work by self-clocking (more like TBF). It fixes a bug when 0 delay is requested (only doing loss or duplication). Signed-off-by: Stephen Hemminger cb; psched_tdiff_t td; psched_time_t now; PSCHED_GET_TIME(now); td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist); - PSCHED_TADD2(now, td, cb->time_to_send); /* Always queue at tail to keep packets in order */ if (likely(q->delayed.qlen < q->limit)) { + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + + PSCHED_TADD2(now, td, cb->time_to_send); + + pr_debug("netem_delay: skb=%p now=%llu tosend=%llu\n", skb, + now, cb->time_to_send); + __skb_queue_tail(&q->delayed, skb); - if (!timer_pending(&q->timer)) { - q->timer.expires = jiffies + PSCHED_US2JIFFIE(td); - add_timer(&q->timer); - } return NET_XMIT_SUCCESS; } + pr_debug("netem_delay: queue over limit %d\n", q->limit); + sch->qstats.overlimits++; kfree_skb(skb); return NET_XMIT_DROP; } +/* + * Move a packet that is ready to send from the delay holding + * list to the underlying qdisc. + */ +static int netem_run(struct Qdisc *sch) +{ + struct netem_sched_data *q = qdisc_priv(sch); + struct sk_buff *skb; + psched_time_t now; + + PSCHED_GET_TIME(now); + + skb = skb_peek(&q->delayed); + if (skb) { + const struct netem_skb_cb *cb + = (const struct netem_skb_cb *)skb->cb; + long delay + = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_run: skb=%p delay=%ld\n", skb, delay); + + /* if more time remaining? */ + if (delay > 0) { + mod_timer(&q->timer, jiffies + delay); + return 1; + } + + __skb_unlink(skb, &q->delayed); + + if (q->qdisc->enqueue(skb, q->qdisc)) { + sch->q.qlen--; + sch->qstats.drops++; + } + } + + return 0; +} + static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb2; int ret; - pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); + pr_debug("netem_enqueue skb=%p\n", skb); /* Random packet drop 0 => none, ~0 => all */ if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { @@ -184,7 +224,7 @@ && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { pr_debug("netem_enqueue: dup %p\n", skb2); - if (delay_skb(sch, skb2)) { + if (netem_delay(sch, skb2)) { sch->q.qlen++; sch->bstats.bytes += skb2->len; sch->bstats.packets++; @@ -202,7 +242,8 @@ ret = q->qdisc->enqueue(skb, q->qdisc); } else { q->counter = 0; - ret = delay_skb(sch, skb); + ret = netem_delay(sch, skb); + netem_run(sch); } if (likely(ret == NET_XMIT_SUCCESS)) { @@ -241,56 +282,35 @@ return len; } -/* Dequeue packet. - * Move all packets that are ready to send from the delay holding - * list to the underlying qdisc, then just call dequeue - */ static struct sk_buff *netem_dequeue(struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb; + int pending; + + pending = netem_run(sch); skb = q->qdisc->dequeue(q->qdisc); - if (skb) + if (skb) { + pr_debug("netem_dequeue: return skb=%p\n", skb); sch->q.qlen--; + sch->flags &= ~TCQ_F_THROTTLED; + } + else if (pending) { + pr_debug("netem_dequeue: throttling\n"); + sch->flags |= TCQ_F_THROTTLED; + } + return skb; } static void netem_watchdog(unsigned long arg) { struct Qdisc *sch = (struct Qdisc *)arg; - struct netem_sched_data *q = qdisc_priv(sch); - struct net_device *dev = sch->dev; - struct sk_buff *skb; - psched_time_t now; - pr_debug("netem_watchdog: fired @%lu\n", jiffies); - - spin_lock_bh(&dev->queue_lock); - PSCHED_GET_TIME(now); - - while ((skb = skb_peek(&q->delayed)) != NULL) { - const struct netem_skb_cb *cb - = (const struct netem_skb_cb *)skb->cb; - long delay - = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); - pr_debug("netem_watchdog: skb %p@%lu %ld\n", - skb, jiffies, delay); - - /* if more time remaining? */ - if (delay > 0) { - mod_timer(&q->timer, jiffies + delay); - break; - } - __skb_unlink(skb, &q->delayed); - - if (q->qdisc->enqueue(skb, q->qdisc)) { - sch->q.qlen--; - sch->qstats.drops++; - } - } - qdisc_run(dev); - spin_unlock_bh(&dev->queue_lock); + pr_debug("netem_watchdog qlen=%d\n", sch->q.qlen); + sch->flags &= ~TCQ_F_THROTTLED; + netif_schedule(sch->dev); } static void netem_reset(struct Qdisc *sch) @@ -301,6 +321,7 @@ skb_queue_purge(&q->delayed); sch->q.qlen = 0; + sch->flags &= ~TCQ_F_THROTTLED; del_timer_sync(&q->timer); } From davem@davemloft.net Tue May 3 16:29:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:29:34 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NTV7J007517 for ; Tue, 3 May 2005 16:29:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6eW-0003Vc-00; Tue, 03 May 2005 16:18:08 -0700 Date: Tue, 3 May 2005 16:18:08 -0700 From: "David S. Miller" To: Tommy Christensen Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-Id: <20050503161808.5925f241.davem@davemloft.net> In-Reply-To: <42780918.10001@tpack.net> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <4277FC16.4050307@tpack.net> <20050503231023.GA18323@gondor.apana.org.au> <42780918.10001@tpack.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 04 May 2005 01:28:24 +0200 Tommy Christensen wrote: > Herbert Xu wrote: > > Thanks Tommy. This version looks good to me. BTW, you probably > > should add a Signed-off-by line. > > Sigh. I remembered on all but the final patch ... > Thanks for helping out. > > Signed-off-by: Tommy S. Christensen Applied, thanks Tommy. From davem@davemloft.net Tue May 3 16:35:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:35:31 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NZS7J008557 for ; Tue, 3 May 2005 16:35:29 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6kM-0003XK-00; Tue, 03 May 2005 16:24:10 -0700 Date: Tue, 3 May 2005 16:24:10 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: kaber@trash.net, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating Message-Id: <20050503162410.6199eabf.davem@davemloft.net> In-Reply-To: <20050503162550.30acf31a@dxpl.pdx.osdl.net> References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev All 3 patches applied, thanks Stephen. From kaber@trash.net Tue May 3 16:35:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:35:45 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NZg7J008586 for ; Tue, 3 May 2005 16:35:42 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT6vJ-0006VO-BF; Wed, 04 May 2005 01:35:29 +0200 Message-ID: <42780AC1.8040409@trash.net> Date: Wed, 04 May 2005 01:35:29 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> In-Reply-To: <20050503162550.30acf31a@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Stephen Hemminger wrote: > Fix qlen underrun when doing duplication with netem. If netem is used as > leaf discipline, then the parent needs to be tweaked when packets are duplicated. > + /* Since one packet can generate two packets in the > + * queue, the parent's qlen accounting gets confused, > + * so fix it. > + */ > + qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); > + if (qp) > + qp->q.qlen++; This only works in a hierarchy with just one qdisc above netem, there could be up to seven (check_loop_fn prevents more than that). It's also not safe because it violates qdisc locking rules, when this code is executed dev->queue_lock is already taken and qdisc_lookup() grabs qdisc_tree_lock, but they can only be taken in the other order. Regards Patrick From hasso@estpak.ee Tue May 3 16:35:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:35:53 -0700 (PDT) Received: from arena.estpak.ee (dream.estpak.ee [194.126.115.147]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NZo7J008604 for ; Tue, 3 May 2005 16:35:50 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DT6vO-0001NG-JN; Wed, 04 May 2005 02:35:34 +0300 From: Hasso Tepper To: Patrick McHardy Subject: Re: icmp_unreachable uses wrong ip Date: Wed, 4 May 2005 02:35:33 +0300 User-Agent: KMail/1.8 Cc: "J. Simonetti" , netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505030944.49175.hasso@estpak.ee> <4277BFA6.8090306@trash.net> In-Reply-To: <4277BFA6.8090306@trash.net> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505040235.33461.hasso@estpak.ee> X-archive-position: 658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Patrick McHardy wrote: > But when multiple addresses are used the result can be even more > confusing. I don't like inconsistent behaviour, and this patch works > sometimes and sometimes it doesn't. I see no behaviour you can define as "it doesn't work". Purpose of this patch is to provide info about links (not addresses, you can't have this info) used to forward packets and it does the job. > > And can you explain what theoretical possibilities router has to obtain > > info what address was used as nexthop by neighbour? > > I can think of none. Exactly. regards, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From kaber@trash.net Tue May 3 16:37:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:37:57 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Nbr7J009941 for ; Tue, 3 May 2005 16:37:54 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT6xQ-0006Vs-BM; Wed, 04 May 2005 01:37:40 +0200 Message-ID: <42780B44.8040803@trash.net> Date: Wed, 04 May 2005 01:37:40 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Hasso Tepper CC: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505030944.49175.hasso@estpak.ee> <4277BFA6.8090306@trash.net> <200505040235.33461.hasso@estpak.ee> In-Reply-To: <200505040235.33461.hasso@estpak.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Hasso Tepper wrote: > Patrick McHardy wrote: > >>But when multiple addresses are used the result can be even more >>confusing. I don't like inconsistent behaviour, and this patch works >>sometimes and sometimes it doesn't. > > > I see no behaviour you can define as "it doesn't work". Purpose of this > patch is to provide info about links (not addresses, you can't have this > info) used to forward packets and it does the job. Well, arguably it can be called "doesn't work" if addresses not used at all during transmit of the packet show up in traceroute. Regards Patrick From davem@davemloft.net Tue May 3 16:38:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:38:05 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Nc27J010131 for ; Tue, 3 May 2005 16:38:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6gS-0003W8-00; Tue, 03 May 2005 16:20:08 -0700 Date: Tue, 3 May 2005 16:20:07 -0700 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, akpm@osdl.org Subject: Re: CONFIG_NETFILTER_DEBUG spew Message-Id: <20050503162007.70c57f37.davem@davemloft.net> In-Reply-To: <4274F2ED.9080404@trash.net> References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> <4274F2ED.9080404@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Patch applied, thanks. From davem@davemloft.net Tue May 3 16:38:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:38:18 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NcE7J010278 for ; Tue, 3 May 2005 16:38:14 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6gk-0003WC-00; Tue, 03 May 2005 16:20:26 -0700 Date: Tue, 3 May 2005 16:20:26 -0700 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, akpm@osdl.org Subject: Re: CONFIG_NETFILTER_DEBUG spew Message-Id: <20050503162026.11ec4ada.davem@davemloft.net> In-Reply-To: <4276517F.6030606@trash.net> References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> <4276517F.6030606@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 02 May 2005 18:12:47 +0200 Patrick McHardy wrote: > Herbert Xu wrote: > > BTW, should we do nf_reset in ip_dev_loopback_xmit as well? > > I think we should, tc actions could do something unexpected with > the packet. Also applied, thanks a lot. From davem@davemloft.net Tue May 3 16:39:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:39:42 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Ndd7J011563 for ; Tue, 3 May 2005 16:39:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6mb-0003b6-00; Tue, 03 May 2005 16:26:29 -0700 Date: Tue, 3 May 2005 16:26:28 -0700 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries (was: [PATCH][IPv6][IPsec] stop infinite loop) Message-Id: <20050503162628.7541807d.davem@davemloft.net> In-Reply-To: <20050430114349.GA24573@gondor.apana.org.au> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 21:43:49 +1000 Herbert Xu wrote: > The ref counting on loopback_idev wasn't quite right. Here is the > corrected version. Applied, thanks Herbert. From davem@davemloft.net Tue May 3 16:39:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:39:53 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Ndn7J011582 for ; Tue, 3 May 2005 16:39:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6ob-0003by-00; Tue, 03 May 2005 16:28:33 -0700 Date: Tue, 3 May 2005 16:28:33 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: patch: Action repeat Message-Id: <20050503162833.4dc1ae80.davem@davemloft.net> In-Reply-To: <1114879817.8929.117.camel@localhost.localdomain> References: <1114879817.8929.117.camel@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 12:50:17 -0400 jamal wrote: > Long standing bug. > Policy to repeat an action never worked. > > signed-off-by: J Hadi Salim Applied, thanks Jamal. From davem@davemloft.net Tue May 3 16:41:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:41:46 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Nfg7J012845 for ; Tue, 3 May 2005 16:41:42 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6qP-0003e4-00; Tue, 03 May 2005 16:30:25 -0700 Date: Tue, 3 May 2005 16:30:25 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating Message-Id: <20050503163025.38bb9682.davem@davemloft.net> In-Reply-To: <42780AC1.8040409@trash.net> References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 04 May 2005 01:35:29 +0200 Patrick McHardy wrote: > Stephen Hemminger wrote: > > Fix qlen underrun when doing duplication with netem. If netem is used as > > leaf discipline, then the parent needs to be tweaked when packets are duplicated. > > > + /* Since one packet can generate two packets in the > > + * queue, the parent's qlen accounting gets confused, > > + * so fix it. > > + */ > > + qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); > > + if (qp) > > + qp->q.qlen++; > > This only works in a hierarchy with just one qdisc above netem, there > could be up to seven (check_loop_fn prevents more than that). It's also > not safe because it violates qdisc locking rules, when this code is > executed dev->queue_lock is already taken and qdisc_lookup() grabs > qdisc_tree_lock, but they can only be taken in the other order. I see... I'm leaving Stephen's patch in there for now. Perhaps we can create some kind of "propagate up" function that will handle all of the parents in the qdisc hierarchy above netem? From kaber@trash.net Tue May 3 16:48:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:48:19 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NmF7J014038 for ; Tue, 3 May 2005 16:48:16 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT77S-0006Y3-TI; Wed, 04 May 2005 01:48:02 +0200 Message-ID: <42780DB2.2090201@trash.net> Date: Wed, 04 May 2005 01:48:02 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> In-Reply-To: <20050503163025.38bb9682.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev David S. Miller wrote: > On Wed, 04 May 2005 01:35:29 +0200 > Patrick McHardy wrote: > >>This only works in a hierarchy with just one qdisc above netem, there >>could be up to seven (check_loop_fn prevents more than that). It's also >>not safe because it violates qdisc locking rules, when this code is >>executed dev->queue_lock is already taken and qdisc_lookup() grabs >>qdisc_tree_lock, but they can only be taken in the other order. > > I see... I'm leaving Stephen's patch in there for now. > > Perhaps we can create some kind of "propagate up" function > that will handle all of the parents in the qdisc hierarchy > above netem? That's what I already suggested, it should be pretty simple to do so. I'll send a patch once your tree appears on kernel.org. BTW, are you pushing it regulary or just for Linus to merge? Regards Patrick From davem@davemloft.net Tue May 3 17:10:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 17:11:01 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j440Au7J015169 for ; Tue, 3 May 2005 17:10:56 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT7If-0003rU-00; Tue, 03 May 2005 16:59:37 -0700 Date: Tue, 3 May 2005 16:59:37 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating Message-Id: <20050503165937.0c6cac6d.davem@davemloft.net> In-Reply-To: <42780DB2.2090201@trash.net> References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> <42780DB2.2090201@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 04 May 2005 01:48:02 +0200 Patrick McHardy wrote: > That's what I already suggested, it should be pretty simple to do > so. I'll send a patch once your tree appears on kernel.org. Thanks. > BTW, are you pushing it regulary or just for Linus to merge? I tend to process a batch of patches, then push the kernel.org, then to Linus. I just pushed my tree to: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/ and you poke it on the web via: http://www.kernel.org/git/ My net-2.6 tree is in the list there at: http://www.kernel.org/git/gitweb.cgi?p=linux%2Fkernel%2Fgit%2Fdavem%2Fnet-2.6.git;a=log as soon as Marcelo has his GIT tree going for 2.4.x, I'll put Sparc and Net trees up for that as well. From herbert@gondor.apana.org.au Tue May 3 17:46:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 17:46:37 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j440kT7J016706 for ; Tue, 3 May 2005 17:46:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DT81b-0000gX-00; Wed, 04 May 2005 10:46:03 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DT81Y-00055Q-00; Wed, 04 May 2005 10:46:00 +1000 Date: Wed, 4 May 2005 10:46:00 +1000 To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries (was: [PATCH][IPv6][IPsec] stop infinite loop) Message-ID: <20050504004600.GA19502@gondor.apana.org.au> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503162628.7541807d.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Tue, May 03, 2005 at 04:26:28PM -0700, David S. Miller wrote: > > Applied, thanks Herbert. Thanks Dave. BTW, I was reviewing the rt6i_idev usage in IPv6 and it seems to me that they need some protection with locking or RCU. As it is they are simply dereferenced in user/softirq context with no locking. For example, the call chain udpv6_sendmsg -> ip6_dst_lookup -> ipv6_get_saddr occurs in user context and simply dereferences rt6i_idev. The race condition is that another CPU could come in and free rt6i_idev. The reference count held by the dst entry doesn't help since the other CPU will drop the reference count for us through dst_ifdown. Yoshifuji-san, does this look like a real problem to you? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Tue May 3 18:07:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:07:44 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4417d7J017669 for ; Tue, 3 May 2005 18:07:39 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT8Ld-0003XC-V5; Wed, 04 May 2005 03:06:45 +0200 Message-ID: <42782025.3010700@trash.net> Date: Wed, 04 May 2005 03:06:45 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> In-Reply-To: <20050503162628.7541807d.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------010304080206040500020904" X-archive-position: 668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------010304080206040500020904 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David S. Miller wrote: > On Sat, 30 Apr 2005 21:43:49 +1000 > Herbert Xu wrote: > >>The ref counting on loopback_idev wasn't quite right. Here is the >>corrected version. > > > Applied, thanks Herbert. The patch causes a compile error here: CC net/ipv6/xfrm6_policy.o In file included from net/ipv6/xfrm6_policy.c:18: include/net/addrconf.h:40: error: field `prefix' has incomplete type This patch fixes it. Signed-off-by: Patrick McHardy --------------010304080206040500020904 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: net/ipv6/xfrm6_policy.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/ipv6/xfrm6_policy.c (mode:100644 sha1:4429b1a1fe5fe2528318b7417e539279548d9988) +++ uncommitted/net/ipv6/xfrm6_policy.c (mode:100644) @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include --------------010304080206040500020904-- From herbert@gondor.apana.org.au Tue May 3 18:12:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:12:40 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441Ca7J018269 for ; Tue, 3 May 2005 18:12:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DT8Qq-0000pJ-00; Wed, 04 May 2005 11:12:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DT8Qm-00058a-00; Wed, 04 May 2005 11:12:04 +1000 Date: Wed, 4 May 2005 11:12:04 +1000 To: Patrick McHardy Cc: "David S. Miller" , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries Message-ID: <20050504011204.GA19740@gondor.apana.org.au> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42782025.3010700@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Wed, May 04, 2005 at 03:06:45AM +0200, Patrick McHardy wrote: > > The patch causes a compile error here: > > CC net/ipv6/xfrm6_policy.o > In file included from net/ipv6/xfrm6_policy.c:18: > include/net/addrconf.h:40: error: field `prefix' has incomplete type Hmm, I wonder why I didn't see this. Anyway, could you please add the include to addrconf.h instead? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From glen.turner@aarnet.edu.au Tue May 3 18:16:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:16:10 -0700 (PDT) Received: from clix.aarnet.edu.au (clix.aarnet.edu.au [192.94.63.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441G57J018860 for ; Tue, 3 May 2005 18:16:06 -0700 Received: from [202.158.193.5] (andromache.adelaide.aarnet.edu.au [202.158.193.5]) (authenticated bits=0) by clix.aarnet.edu.au (8.12.8/8.12.8) with ESMTP id j441Fjob001649 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 May 2005 11:15:46 +1000 Message-ID: <42782241.6080909@aarnet.edu.au> Date: Wed, 04 May 2005 10:45:45 +0930 From: Glen Turner Organization: Australian Academic and Research Network User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <20050503092244.GA8864@xi.wantstofly.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MDSA: Yes X-Scanned-By: MIMEDefang 2.39 X-archive-position: 670 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: glen.turner@aarnet.edu.au Precedence: bulk X-list: netdev Pekka Savola wrote: > > > There's no specification requiring or recommending either of these > approaches, either for v6 or v4 AFAICS so you can't depend on that > behaviour.. In the lack of a specification, doing what works best for network operators would be nice :-) And that behaviour is that addresses in a traceroute should be ping-able. That is, you're tracing the route and there's loss at one point, so you want to determine how much loss. The outgoing interface's address may not be reached down the same path as used by the traceroute, whereis the incoming address obviously is (or if it isn't, then that itself is interesting diagnostic information). Similarly, using the incoming interface gives more information about asymetric routes. In short, since using the incoming address gives more useful output and the specification is silent as to which address is allowable, using the incoming interface's address would be the most useful choice. Cheers, Glen -- Glen Turner Tel: (08) 8303 3936 or +61 8 8303 3936 Australia's Academic & Research Network www.aarnet.edu.au From herbert@gondor.apana.org.au Tue May 3 18:20:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:20:38 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441KV7J019456 for ; Tue, 3 May 2005 18:20:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DT8YP-0000tD-00; Wed, 04 May 2005 11:19:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DT8YO-0005Nc-00; Wed, 04 May 2005 11:19:56 +1000 Date: Wed, 4 May 2005 11:19:56 +1000 To: Patrick McHardy Cc: "David S. Miller" , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries Message-ID: <20050504011956.GA20670@gondor.apana.org.au> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> <20050504011204.GA19740@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <20050504011204.GA19740@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 04, 2005 at 11:12:04AM +1000, herbert wrote: > On Wed, May 04, 2005 at 03:06:45AM +0200, Patrick McHardy wrote: > > > > The patch causes a compile error here: > > > > CC net/ipv6/xfrm6_policy.o > > In file included from net/ipv6/xfrm6_policy.c:18: > > include/net/addrconf.h:40: error: field `prefix' has incomplete type > > Hmm, I wonder why I didn't see this. Anyway, could you please add > the include to addrconf.h instead? Aha, I can see it if I do something like this. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/asm-i386/checksum.h 1.14 vs edited ===== --- 1.14/include/asm-i386/checksum.h 2005-01-16 22:58:42 +11:00 +++ edited/include/asm-i386/checksum.h 2005-05-04 11:17:09 +10:00 @@ -1,8 +1,6 @@ #ifndef _I386_CHECKSUM_H #define _I386_CHECKSUM_H -#include - /* * computes the checksum of a memory block at buff, length len, * and adds in "sum" (32-bit) @@ -145,6 +143,7 @@ } #define _HAVE_ARCH_IPV6_CSUM +struct in6_addr; static __inline__ unsigned short int csum_ipv6_magic(struct in6_addr *saddr, struct in6_addr *daddr, __u32 len, --mP3DRpeJDSE+ciuQ-- From kaber@trash.net Tue May 3 18:21:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:21:07 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441L17J019497 for ; Tue, 3 May 2005 18:21:02 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT8Yd-0006Hb-Nw; Wed, 04 May 2005 03:20:11 +0200 Message-ID: <4278234B.2080605@trash.net> Date: Wed, 04 May 2005 03:20:11 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> <20050504011204.GA19740@gondor.apana.org.au> In-Reply-To: <20050504011204.GA19740@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------090201060903000203060606" X-archive-position: 672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------090201060903000203060606 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Hmm, I wonder why I didn't see this. Anyway, could you please add > the include to addrconf.h instead? Sure, I missed the includes below and thought users of the file were supposed to include it first. Signed-off-by: Patrick McHardy --------------090201060903000203060606 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: include/net/addrconf.h =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/include/net/addrconf.h (mode:100644 sha1:f1e5af4be98e4a9cde314a5c1ceeaf3a61cf87ad) +++ uncommitted/include/net/addrconf.h (mode:100644) @@ -17,6 +17,8 @@ #define IPV6_MAX_ADDRESSES 16 +#include + struct prefix_info { __u8 type; __u8 length; @@ -43,7 +45,6 @@ #ifdef __KERNEL__ -#include #include #include #include --------------090201060903000203060606-- From kaber@trash.net Tue May 3 18:24:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:24:21 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441OI7J020581 for ; Tue, 3 May 2005 18:24:18 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT8bp-0006I5-CM; Wed, 04 May 2005 03:23:29 +0200 Message-ID: <42782411.2070206@trash.net> Date: Wed, 04 May 2005 03:23:29 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> <20050504011204.GA19740@gondor.apana.org.au> <20050504011956.GA20670@gondor.apana.org.au> In-Reply-To: <20050504011956.GA20670@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Herbert Xu wrote: >>Hmm, I wonder why I didn't see this. Anyway, could you please add >>the include to addrconf.h instead? > > Aha, I can see it if I do something like this. > > > ------------------------------------------------------------------------ > > ===== include/asm-i386/checksum.h 1.14 vs edited ===== > --- 1.14/include/asm-i386/checksum.h 2005-01-16 22:58:42 +11:00 > +++ edited/include/asm-i386/checksum.h 2005-05-04 11:17:09 +10:00 > @@ -1,8 +1,6 @@ > #ifndef _I386_CHECKSUM_H > #define _I386_CHECKSUM_H > > -#include > - > /* > * computes the checksum of a memory block at buff, length len, > * and adds in "sum" (32-bit) > @@ -145,6 +143,7 @@ > } > > #define _HAVE_ARCH_IPV6_CSUM > +struct in6_addr; > static __inline__ unsigned short int csum_ipv6_magic(struct in6_addr *saddr, > struct in6_addr *daddr, > __u32 len, I use x86_64, which explains why I saw the error: struct in6_addr; #define _HAVE_ARCH_IPV6_CSUM 1 csum_ipv6_magic(struct in6_addr *saddr, struct in6_addr *daddr, __u32 len, unsigned short proto, unsigned int sum); Regards Patrick From kaber@trash.net Tue May 3 18:57:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:57:18 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441vE7J022220 for ; Tue, 3 May 2005 18:57:15 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT98I-00046Z-8c; Wed, 04 May 2005 03:57:02 +0200 Message-ID: <42782BEE.2050206@trash.net> Date: Wed, 04 May 2005 03:57:02 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> <42780DB2.2090201@trash.net> <20050503165937.0c6cac6d.davem@davemloft.net> <42782B59.3000500@trash.net> In-Reply-To: <42782B59.3000500@trash.net> Content-Type: multipart/mixed; boundary="------------070808090604040309020309" X-archive-position: 675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------070808090604040309020309 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrick McHardy wrote: > David S. Miller wrote: > >>On Wed, 04 May 2005 01:48:02 +0200 >>Patrick McHardy wrote: >> >> >> >>>That's what I already suggested, it should be pretty simple to do >>>so. I'll send a patch once your tree appears on kernel.org. > > > This one should work. It keeps a pointer to the parent qdisc in struct > Qdisc and adjusts q.qlen of all parent qdiscs in netem. The __parent > pointer also used by CBQ is renamed to parentq and is used for this. To > avoid confusion, the parent classid is also renamed to parentcl. It > should work with all currently included classful qdiscs except HFSC. > Statistics are not correctly updated (and can't be without support from > the qdisc since classes are internal to it), we need to keep this in > mind in case a qdisc like RED which uses qstats.backlog for calculations > is converted to a classful one. Fixing HFSC is very low priority, it > could only use netem in work-conserving mode anyway. > > My favourite solution would be to avoid this hack and let tc actions > handle duplication, as Jamal suggested. My previous point against this > of not necessarily having an identical classification result for the > duplicated packet as the original one is actually a plus since it > provides more flexibility. Steven, what do you think about it? > > Signed-off-by: Patrick McHardy > Oops, I've attached an old patch with a bug. This one is the correct one. --------------070808090604040309020309 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: include/net/sch_generic.h =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/include/net/sch_generic.h (mode:100644 sha1:c57504b3b51819522dc9f868aa9a208d61dd3892) +++ uncommitted/include/net/sch_generic.h (mode:100644) @@ -35,7 +35,7 @@ int padded; struct Qdisc_ops *ops; u32 handle; - u32 parent; + u32 parentcl; atomic_t refcnt; struct sk_buff_head q; struct net_device *dev; @@ -49,10 +49,11 @@ int (*reshape_fail)(struct sk_buff *skb, struct Qdisc *q); - /* This field is deprecated, but it is still used by CBQ + /* This field is deprecated, but it is still used by CBQ and netem * and it will live until better solution will be invented. + * Valid only while qdisc is grafted to its parent. */ - struct Qdisc *__parent; + struct Qdisc *parentq; }; struct Qdisc_class_ops Index: net/sched/sch_api.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_api.c (mode:100644 sha1:07977f8f2679b30cf93808f93fbbcce3c3dbc776) +++ uncommitted/net/sched/sch_api.c (mode:100644) @@ -378,9 +378,11 @@ if (cops) { unsigned long cl = cops->get(parent, classid); if (cl) { + if (new) { + new->parentcl = classid; + new->parentq = parent; + } err = cops->graft(parent, cl, new, old); - if (new) - new->parent = classid; cops->put(parent, cl); } } @@ -855,7 +857,7 @@ q_idx++; continue; } - if (tc_fill_qdisc(skb, q, q->parent, NETLINK_CB(cb->skb).pid, + if (tc_fill_qdisc(skb, q, q->parentcl, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, NLM_F_MULTI, RTM_NEWQDISC) <= 0) { read_unlock_bh(&qdisc_tree_lock); goto done; @@ -1289,7 +1291,6 @@ subsys_initcall(pktsched_init); -EXPORT_SYMBOL(qdisc_lookup); EXPORT_SYMBOL(qdisc_get_rtab); EXPORT_SYMBOL(qdisc_put_rtab); EXPORT_SYMBOL(register_qdisc); Index: net/sched/sch_cbq.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_cbq.c (mode:100644 sha1:d43e3b8cbf6af27a25ab7b9d2aee82a32f8010eb) +++ uncommitted/net/sched/sch_cbq.c (mode:100644) @@ -419,9 +419,6 @@ return ret; } -#ifdef CONFIG_NET_CLS_POLICE - cl->q->__parent = sch; -#endif if ((ret = cl->q->enqueue(skb, cl->q)) == NET_XMIT_SUCCESS) { sch->q.qlen++; sch->bstats.packets++; @@ -456,7 +453,6 @@ #ifdef CONFIG_NET_CLS_POLICE q->rx_class = cl; - cl->q->__parent = sch; #endif if ((ret = cl->q->ops->requeue(skb, cl->q)) == 0) { sch->q.qlen++; @@ -690,7 +686,7 @@ static int cbq_reshape_fail(struct sk_buff *skb, struct Qdisc *child) { int len = skb->len; - struct Qdisc *sch = child->__parent; + struct Qdisc *sch = child->parentq; struct cbq_sched_data *q = qdisc_priv(sch); struct cbq_class *cl = q->rx_class; @@ -701,7 +697,6 @@ cbq_mark_toplevel(q, cl); q->rx_class = cl; - cl->q->__parent = sch; if (cl->q->enqueue(skb, cl->q) == 0) { sch->q.qlen++; Index: net/sched/sch_generic.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_generic.c (mode:100644 sha1:87e48a4e105133ca3d0407b5c2d84f1b0e3a72c4) +++ uncommitted/net/sched/sch_generic.c (mode:100644) @@ -501,7 +501,7 @@ /* unlink inner qdiscs from dev->qdisc_list immediately */ list_for_each_entry(cq, &cql, list) list_for_each_entry_safe(q, n, &qdisc->dev->qdisc_list, list) - if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) { + if (TC_H_MAJ(q->parentcl) == TC_H_MAJ(cq->handle)) { if (q->ops->cl_ops == NULL) list_del_init(&q->list); else Index: net/sched/sch_netem.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_netem.c (mode:100644 sha1:e0c9fbe73b15cee32b44f4469e1ac5eeb9849267) +++ uncommitted/net/sched/sch_netem.c (mode:100644) @@ -230,11 +230,9 @@ * queue, the parent's qlen accounting gets confused, * so fix it. */ - qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); - if (qp) + for (qp = sch; qp; qp = qp->parentq) qp->q.qlen++; - sch->q.qlen++; sch->bstats.bytes += skb2->len; sch->bstats.packets++; } else --------------070808090604040309020309-- From kaber@trash.net Tue May 3 18:54:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:54:52 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441sk7J021935 for ; Tue, 3 May 2005 18:54:49 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT95t-000450-4n; Wed, 04 May 2005 03:54:33 +0200 Message-ID: <42782B59.3000500@trash.net> Date: Wed, 04 May 2005 03:54:33 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> <42780DB2.2090201@trash.net> <20050503165937.0c6cac6d.davem@davemloft.net> In-Reply-To: <20050503165937.0c6cac6d.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------020602040806080405010609" X-archive-position: 674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------020602040806080405010609 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David S. Miller wrote: > On Wed, 04 May 2005 01:48:02 +0200 > Patrick McHardy wrote: > > >>That's what I already suggested, it should be pretty simple to do >>so. I'll send a patch once your tree appears on kernel.org. This one should work. It keeps a pointer to the parent qdisc in struct Qdisc and adjusts q.qlen of all parent qdiscs in netem. The __parent pointer also used by CBQ is renamed to parentq and is used for this. To avoid confusion, the parent classid is also renamed to parentcl. It should work with all currently included classful qdiscs except HFSC. Statistics are not correctly updated (and can't be without support from the qdisc since classes are internal to it), we need to keep this in mind in case a qdisc like RED which uses qstats.backlog for calculations is converted to a classful one. Fixing HFSC is very low priority, it could only use netem in work-conserving mode anyway. My favourite solution would be to avoid this hack and let tc actions handle duplication, as Jamal suggested. My previous point against this of not necessarily having an identical classification result for the duplicated packet as the original one is actually a plus since it provides more flexibility. Steven, what do you think about it? Signed-off-by: Patrick McHardy --------------020602040806080405010609 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: include/net/sch_generic.h =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/include/net/sch_generic.h (mode:100644 sha1:c57504b3b51819522dc9f868aa9a208d61dd3892) +++ uncommitted/include/net/sch_generic.h (mode:100644) @@ -35,7 +35,7 @@ int padded; struct Qdisc_ops *ops; u32 handle; - u32 parent; + u32 parentcl; atomic_t refcnt; struct sk_buff_head q; struct net_device *dev; @@ -49,10 +49,11 @@ int (*reshape_fail)(struct sk_buff *skb, struct Qdisc *q); - /* This field is deprecated, but it is still used by CBQ + /* This field is deprecated, but it is still used by CBQ and netem * and it will live until better solution will be invented. + * Valid only while qdisc is grafted to its parent. */ - struct Qdisc *__parent; + struct Qdisc *parentq; }; struct Qdisc_class_ops Index: net/sched/sch_api.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_api.c (mode:100644 sha1:07977f8f2679b30cf93808f93fbbcce3c3dbc776) +++ uncommitted/net/sched/sch_api.c (mode:100644) @@ -378,9 +378,11 @@ if (cops) { unsigned long cl = cops->get(parent, classid); if (cl) { + if (new) { + new->parentcl = classid; + new->parentq = parent; + } err = cops->graft(parent, cl, new, old); - if (new) - new->parent = classid; cops->put(parent, cl); } } @@ -855,7 +857,7 @@ q_idx++; continue; } - if (tc_fill_qdisc(skb, q, q->parent, NETLINK_CB(cb->skb).pid, + if (tc_fill_qdisc(skb, q, q->parentcl, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, NLM_F_MULTI, RTM_NEWQDISC) <= 0) { read_unlock_bh(&qdisc_tree_lock); goto done; @@ -1289,7 +1291,6 @@ subsys_initcall(pktsched_init); -EXPORT_SYMBOL(qdisc_lookup); EXPORT_SYMBOL(qdisc_get_rtab); EXPORT_SYMBOL(qdisc_put_rtab); EXPORT_SYMBOL(register_qdisc); Index: net/sched/sch_cbq.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_cbq.c (mode:100644 sha1:d43e3b8cbf6af27a25ab7b9d2aee82a32f8010eb) +++ uncommitted/net/sched/sch_cbq.c (mode:100644) @@ -419,9 +419,6 @@ return ret; } -#ifdef CONFIG_NET_CLS_POLICE - cl->q->__parent = sch; -#endif if ((ret = cl->q->enqueue(skb, cl->q)) == NET_XMIT_SUCCESS) { sch->q.qlen++; sch->bstats.packets++; @@ -456,7 +453,6 @@ #ifdef CONFIG_NET_CLS_POLICE q->rx_class = cl; - cl->q->__parent = sch; #endif if ((ret = cl->q->ops->requeue(skb, cl->q)) == 0) { sch->q.qlen++; @@ -690,7 +686,7 @@ static int cbq_reshape_fail(struct sk_buff *skb, struct Qdisc *child) { int len = skb->len; - struct Qdisc *sch = child->__parent; + struct Qdisc *sch = child->parentq; struct cbq_sched_data *q = qdisc_priv(sch); struct cbq_class *cl = q->rx_class; @@ -701,7 +697,6 @@ cbq_mark_toplevel(q, cl); q->rx_class = cl; - cl->q->__parent = sch; if (cl->q->enqueue(skb, cl->q) == 0) { sch->q.qlen++; Index: net/sched/sch_generic.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_generic.c (mode:100644 sha1:87e48a4e105133ca3d0407b5c2d84f1b0e3a72c4) +++ uncommitted/net/sched/sch_generic.c (mode:100644) @@ -501,7 +501,7 @@ /* unlink inner qdiscs from dev->qdisc_list immediately */ list_for_each_entry(cq, &cql, list) list_for_each_entry_safe(q, n, &qdisc->dev->qdisc_list, list) - if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) { + if (TC_H_MAJ(q->parentcl) == TC_H_MAJ(cq->handle)) { if (q->ops->cl_ops == NULL) list_del_init(&q->list); else Index: net/sched/sch_netem.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_netem.c (mode:100644 sha1:e0c9fbe73b15cee32b44f4469e1ac5eeb9849267) +++ uncommitted/net/sched/sch_netem.c (mode:100644) @@ -230,8 +230,7 @@ * queue, the parent's qlen accounting gets confused, * so fix it. */ - qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); - if (qp) + for (qp = sch->parentq; qp; qp = qp->parentq) qp->q.qlen++; sch->q.qlen++; --------------020602040806080405010609-- From akpm@osdl.org Tue May 3 21:56:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 21:56:25 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j444uL7J031028 for ; Tue, 3 May 2005 21:56:22 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j444u7U3022506 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 21:56:07 -0700 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j444u6sS004479; Tue, 3 May 2005 21:56:07 -0700 Message-Id: <200505040456.j444u6sS004479@shell0.pdx.osdl.net> Subject: [patch 1/1] addrconf.h build fix To: davem@davemloft.net Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Tue, 03 May 2005 21:55:40 -0700 X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 676 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev On ppc64: In file included from net/ipv6/xfrm6_policy.c:18: include/net/addrconf.h:40: error: field `prefix' has incomplete type This surely patch isn't right, and might break userspace inclusion of this header file. Signed-off-by: Andrew Morton --- include/net/addrconf.h | 2 ++ 1 files changed, 2 insertions(+) diff -puN include/net/addrconf.h~addrconf-build-fix include/net/addrconf.h --- 25/include/net/addrconf.h~addrconf-build-fix 2005-05-04 04:47:24.000000000 -0600 +++ 25-akpm/include/net/addrconf.h 2005-05-04 04:47:39.000000000 -0600 @@ -1,6 +1,8 @@ #ifndef _ADDRCONF_H #define _ADDRCONF_H +#include + #define RETRANS_TIMER HZ #define MAX_RTR_SOLICITATIONS 3 _ From shemminger@osdl.org Tue May 3 22:02:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 22:02:18 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4452F7J031525 for ; Tue, 3 May 2005 22:02:15 -0700 Received: from [192.168.0.106] (063-170-215-071.dslnorthwest.net [63.170.215.71]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4451wU3023030 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 3 May 2005 22:02:00 -0700 Message-ID: <4278573C.3040503@osdl.org> Date: Tue, 03 May 2005 22:01:48 -0700 From: Stephen Hemminger User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick McHardy CC: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> <42780DB2.2090201@trash.net> <20050503165937.0c6cac6d.davem@davemloft.net> <42782B59.3000500@trash.net> <42782BEE.2050206@trash.net> In-Reply-To: <42782BEE.2050206@trash.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev I like Patrick's solution; and eventually I'll remove duplicate from netem and use mirred action. The problem is that it makes setting up a test environment even more complicated (and error prone). The interface to this is just getting so messy (sorry Jamal), with mirred, filters etc.. Unfortunately, tcng doesn't seem to be getting updated regularly. From davem@davemloft.net Tue May 3 22:03:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 22:03:07 -0700 (PDT) Received: from cheetah.davemloft.net ([216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j445317J031621 for ; Tue, 3 May 2005 22:03:01 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTBr8-00060U-00; Tue, 03 May 2005 21:51:30 -0700 Date: Tue, 3 May 2005 21:51:30 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [patch 1/1] addrconf.h build fix Message-Id: <20050503215130.0526178c.davem@davemloft.net> In-Reply-To: <200505040456.j444u6sS004479@shell0.pdx.osdl.net> References: <200505040456.j444u6sS004479@shell0.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 03 May 2005 21:55:40 -0700 akpm@osdl.org wrote: > On ppc64: > > In file included from net/ipv6/xfrm6_policy.c:18: > include/net/addrconf.h:40: error: field `prefix' has incomplete type > > This surely patch isn't right, and might break userspace inclusion of this > header file. I've got a fix in my queue for this already. In fact, the patch in question was posted to netdev@oss.sgi.com a few hours ago, you may wish to start scanning that list before posting patches :-) From davem@davemloft.net Tue May 3 22:28:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 22:28:33 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j445ST7J000807 for ; Tue, 3 May 2005 22:28:29 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTCFa-0006BV-00; Tue, 03 May 2005 22:16:46 -0700 Date: Tue, 3 May 2005 22:16:46 -0700 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries Message-Id: <20050503221646.4a8de611.davem@davemloft.net> In-Reply-To: <4278234B.2080605@trash.net> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> <20050504011204.GA19740@gondor.apana.org.au> <4278234B.2080605@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 04 May 2005 03:20:11 +0200 Patrick McHardy wrote: > Herbert Xu wrote: > > Hmm, I wonder why I didn't see this. Anyway, could you please add > > the include to addrconf.h instead? > > Sure, I missed the includes below and thought users of the file were > supposed to include it first. > > Signed-off-by: Patrick McHardy Applied, thanks guys. From mchan@broadcom.com Tue May 3 23:09:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 23:09:54 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4469p7J002579 for ; Tue, 3 May 2005 23:09:51 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 03 May 2005 23:09:52 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 3 May 2005 23:09:24 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWH22068; Tue, 3 May 2005 23:09:16 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA06944; Tue, 3 May 2005 23:09:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Mystery packet killing tg3 Date: Tue, 3 May 2005 23:09:15 -0700 Message-ID: Thread-Topic: Mystery packet killing tg3 Thread-Index: AcVQNIybHxh2ztwcRo6XfD92dZE2OQANmgSg From: "Michael Chan" To: "David S. Miller" cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com X-WSS-ID: 6E66B8A51MW1780003-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4469p7J002579 X-archive-position: 680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev David S. Miller wrote: > I can't think of what else could be wedging the tg3. > Michael, any ideas? There are some 5703 specific programming > to consider: > The 5703 related settings in tg3 seem ok to me too. If Stephen says the stop_block error happens during normal ifdown and traffic was otherwise working fine before ifdown, then I think it may not even be a problem at all. Stopping the various state machines can be tricky and I'm not at all surprised that some state machines can fail to stop in some cases. They are all interconnected and even if you follow the stopping sequence in the programmer's reference manual, you may still end up with a situation where one state machine is waiting for another that has been stopped already. This is not a problem as tg3_stop_block() calls are always followed by a global chip reset that will clean up the whole chip. The purpose of tg3_stop_block() is to quiesce the chip and complete all DMA transactions before abruptly resetting the chip. If the DMA blocks would not stop, then it would be a bigger problem. Other tg3_stop_block() errors that I've seen, such as the ones reported by John Linville, were preceded by netdev watchdog timeouts. These netdev watchdog timeouts were real problems that needed to be solved. From mchan@broadcom.com Tue May 3 23:28:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 23:28:14 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j446S97J003803 for ; Tue, 3 May 2005 23:28:11 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 03 May 2005 23:27:41 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 3 May 2005 23:27:38 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWH25736; Tue, 3 May 2005 23:27:38 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA08694; Tue, 3 May 2005 23:27:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Mystery packet killing tg3 Date: Tue, 3 May 2005 23:27:38 -0700 Message-ID: Thread-Topic: Mystery packet killing tg3 Thread-Index: AcVQM89W4DZXZfpCTo+wPELXO7wCDQAPP+9A From: "Michael Chan" To: "Stephen Hemminger" , "David S. Miller" cc: jgarzik@pobox.com, netdev@oss.sgi.com X-WSS-ID: 6E66B4D70UW1703523-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j446S97J003803 X-archive-position: 681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Stephen Hemminger wrote: > Initially, it reproduced everytime link came up, we > reconfigured the VLAN to > have a mirror port into a laptop to try and capture what was > happening, but when > we did that the bootup problem went away. It was in the tg3_reset_hw > during initial dev_open. > During initial dev_open, the TG3_FLAG_INIT_COMPLETE flag is not set so tg3_reset_hw() should not call tg3_abort_hw() where the stop_block calls are made. So there should be no stop_block errors. I think stop_block errors can only happen during dev_close, suspend, netdev watchdog, or ethtool "set" calls. From mroos@tartu.cyber.ee Wed May 4 00:04:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 00:04:08 -0700 (PDT) Received: from tartu.cyber.ee (tartu.cyber.ee [193.40.6.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j447447J006868 for ; Wed, 4 May 2005 00:04:05 -0700 Received: Message by Barricade tartu.cyber.ee with ESMTP id j446eBg29837 for ; Wed, 4 May 2005 09:40:11 +0300 Received: from rhn.tartu-labor (rhn.tartu-labor [192.168.74.17]) by ondatra.tartu-labor (Postfix) with ESMTP id 7BE0A14C48 for ; Wed, 4 May 2005 10:03:45 +0300 (EEST) Received: from mroos by rhn.tartu-labor with local (Exim 4.50) id 1DTDv7-0003vR-DS for netdev@oss.sgi.com; Wed, 04 May 2005 10:03:45 +0300 From: Meelis Roos To: netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip In-Reply-To: <4276A400.2050306@trash.net> User-Agent: tin/1.7.8-20050315 ("Scalpay") (UNIX) (Linux/2.6.12-rc2 (i686)) Message-Id: Date: Wed, 04 May 2005 10:03:45 +0300 X-archive-position: 682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev PM> Your patch can't guarantee that the address used is the same that was PM> used as nexthop by the previous hop in the path when multiple addresses PM> are configured on the incoming interface. So I don't think it achieves PM> much of your goal of making debugging complicated topologies easier. Nevertheless this patch seems to be the most logical thing to do and is _much_ better than current state IMHO. Principle of least surprise. -- Meelis Roos From folkert@vanheusden.com Wed May 4 00:15:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 00:15:41 -0700 (PDT) Received: from keetweej.vanheusden.com (keetweej.xs4all.nl [213.84.46.114]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j447Fa7J007664 for ; Wed, 4 May 2005 00:15:37 -0700 Received: from keetweej.intranet.vanheusden.com (keetweej.intranet.vanheusden.com [192.168.64.99]) by keetweej.vanheusden.com (Postfix) with ESMTP id BC89A1CA366; Wed, 4 May 2005 09:15:22 +0200 (CEST) Date: Wed, 4 May 2005 09:15:20 +0200 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] optimize check in port-allocation code Message-ID: <20050504071516.GA1008@vanheusden.com> References: <20050420184419.GM20290@vanheusden.com> <20050424190427.11b4863e.davem@davemloft.net> <20050425061210.GB15167@vanheusden.com> <20050428120824.6cc9b345.davem@davemloft.net> <20050428212449.GC8774@vanheusden.com> <20050503143620.43cac50f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503143620.43cac50f.davem@davemloft.net> Organization: www.unixexpert.nl X-Chameleon-Return-To: folkert@vanheusden.com X-Xfmail-Return-To: folkert@vanheusden.com X-Phonenumber: +31-6-41278122 X-URL: http://www.vanheusden.com/ X-PGP-KeyID: 1F28D8AE X-GPG-fingerprint: AC89 09CE 41F2 00B4 FCF2 B174 3019 0E8C 1F28 D8AE X-Key: http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0x1F28D8AE Read-Receipt-To: Reply-By: Wed May 4 21:24:53 CEST 2005 X-MSMail-Priority: High User-Agent: Mutt/1.5.9i From: folkert@vanheusden.com X-archive-position: 683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: folkert@vanheusden.com Precedence: bulk X-list: netdev > > > > I'll resend it as an attachment (see attachment). > > > It still has spaces where there should be tabs, even though > > > you compressed the patch and used attachment. > > > The diff itself must already be corrupt before you attach > > > it. > > > Please double check that the patch you submit actually apply, > > > this will save me a lot of wasted time. > > Ok, I've redone them and tested if they patch cleanly, they now do. > > See them attached. > Both patches applied, thanks a lot. What about moving that rover++ to the end of the loop? Was my analysis correct? Folkert van Heusden -- Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.com! From buytenh@wantstofly.org Wed May 4 01:30:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 01:30:13 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j448UA7J014550 for ; Wed, 4 May 2005 01:30:10 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id F24D82B0EC; Wed, 4 May 2005 10:29:51 +0200 (MEST) Date: Wed, 4 May 2005 10:29:51 +0200 From: Lennert Buytenhek To: Patrick McHardy Cc: Hasso Tepper , "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip Message-ID: <20050504082951.GA13761@xi.wantstofly.org> References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505030944.49175.hasso@estpak.ee> <4277BFA6.8090306@trash.net> <200505040235.33461.hasso@estpak.ee> <42780B44.8040803@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42780B44.8040803@trash.net> User-Agent: Mutt/1.4.1i X-archive-position: 684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Wed, May 04, 2005 at 01:37:40AM +0200, Patrick McHardy wrote: > >>But when multiple addresses are used the result can be even more > >>confusing. I don't like inconsistent behaviour, and this patch works > >>sometimes and sometimes it doesn't. > > > > I see no behaviour you can define as "it doesn't work". Purpose of this > > patch is to provide info about links (not addresses, you can't have this > > info) used to forward packets and it does the job. > > Well, arguably it can be called "doesn't work" if addresses not used > at all during transmit of the packet show up in traceroute. That argument doesn't hold, since exactly the same situation occurs if we use the outgoing address as we do now. With asymmetric routing, the incoming interface, interface to the destination, and the interface back to the source might all be different, so we can end up with: path from r3 back to a +-------------------+ | | V | a --- r1 --- r2 --- r3 --- r4 --- r5 --- b The address of the 'upper' interface of r3 is likewise "not used at all during transmit of the packet", but it is the address we currently send the ICMP from. --L From hadi@cyberus.ca Wed May 4 03:40:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 03:40:37 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44AeY7J018230 for ; Wed, 4 May 2005 03:40:34 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DTHIl-00047g-6E for netdev@oss.sgi.com; Wed, 04 May 2005 06:40:23 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTHIe-0006v4-S5; Wed, 04 May 2005 06:40:17 -0400 Subject: Re: [patch/RFC]: Asynchronous IPsec processing benchmark. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: Herbert Xu , netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" In-Reply-To: <1115127507.3414.58.camel@uganda> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@gondor.apana.org.au> <1115117728.3414.48.camel@uganda> <1115127507.3414.58.camel@uganda> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 06:40:14 -0400 Message-Id: <1115203214.7665.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-03-05 at 17:38 +0400, Evgeniy Polyakov wrote: > Here are some numbers: > > ./netperf -l 60 -H gw -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 > -S 57344 > > TCP STREAM TEST to gw : +/-2.5% @ 99% conf. > > async-ipsec, 10^6bits/sec: 35.42 > sync-ipsec, 10^6bits/sec: 37.11 > > So even with existing timer deferring it is not noticebly slower [about > 4%]. > by "sync" i hope you mean the original code without your change? The one thing i see in your POC code that may affect numbers a bit is allocation of struct esp_async every time in the path. Perhaps precreate a pool of those and then just grab/return to/fro pool; BTW, you may need to incr ref counter of x pre-callback and decrement when done in callback. > And I think that benefits it provides definitely cost that price and > compile time option. I think Herberts concerns about latency should go away if you really have some proper crypto hardware. cheers, jamal From hadi@cyberus.ca Wed May 4 04:34:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 04:35:03 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44BYt7J023827 for ; Wed, 4 May 2005 04:34:56 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DTI9J-0007tT-26 for netdev@oss.sgi.com; Wed, 04 May 2005 05:34:41 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTI9I-0007FM-Fe; Wed, 04 May 2005 07:34:40 -0400 Subject: Re: IPsec performance From: jamal Reply-To: hadi@cyberus.ca To: Miika Komu Cc: Dave Dillow , Patrick McHardy , Netdev In-Reply-To: References: <1115099678.2953.3.camel@ori.thedillows.org> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 07:34:37 -0400 Message-Id: <1115206478.7665.100.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-03-05 at 09:44 +0300, Miika Komu wrote: > On Tue, 3 May 2005, Dave Dillow wrote: > > > On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > > > However, this does explain why I got only 1.9 megabytes/s with 3DES. > > > > What was your hardware? Without knowing what you're running on, it's > > impossible to tell if that is good or bad. > > > > Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. > > I get ~2.1MB/s on a 550MHz Athlon. > > Intel Pentium III 500 MHz I tested on 2.4.x based on Davems code backport and contribution from Herbert > a year ago on a really bad Xeon 2.0Ghz(?), 32 bit bus mboard, e1000 NIC. I used a 2.4.x kernel because i was trying to compare against a broadcom SB1250 board which couldnt run 2.6.x - I also had to do a few tricks to get it to run/compile on MIPS and so may have contributed to perfomance degradation. In any case, the numbers between those two were not very different (even though the sb1250 was at i think 600Mhz). Unfortunately i lost the loaner sb1250 shortly after (it was fun to play with). I have my full results somewhere in another machine which i can lookup, but heres some summary data i had in my laptop: used: A) i) two flows ii) 4 flows iii) 8 flows all seem to reproduce the same aggregate throughput. B) static keying Tests and results ----------------- I: Transport mode: 1) Message Authentication: tested with hmac-md5 Should have done sha-1. Next time. a) 64 byte packets Input 100Mbps (148.8Kpps) output 112 Kpps This is about 75% of wire rate (75Mbps). b) 1400 byte packets 8712 (99% of wire rate) == about 17.4Kpps which is almost wire rate at 200Mbps at that packet size. Note we can never get 100% wire rate since the packet header grows because of the AH insertion. 2) Data encryption mode: 3DES/md5 a) 64 byte packets Peak achievement: 43Kpps == 30Mbps. b) 1400 byte packets Peak achievement: 1.8Kpps == 20Mbps. Now this result is very interesting. It clearly shows that 3DES is compute intensive i.e as the packet grows you get slower - quiet counterintuitive. An encryption chip would go along way to help with large packet sizes. Another observation: In other words given the synchronous nature of the crypto path, there is a threshold value where it may be valuable to use a crypto chip. The effects of this were actually demonstrated by Eugene Surovegin ; long thread of discussion on this on netdev. We need to find the threshold packet size where encryption starts overtaking general packet processing i.e where offloading becomes interesting if we stick with sync scheme. Another thing for s/ware based crypto is to improve the 3DES implementation as in assembler coding. Iam back on/off playing with this, so expect more results Real Soon Now. cheers, jamal From hadi@cyberus.ca Wed May 4 04:46:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 04:46:57 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44Bkr7J024796 for ; Wed, 4 May 2005 04:46:53 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DTIKw-0008Ps-IT for netdev@oss.sgi.com; Wed, 04 May 2005 07:46:42 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTIKq-0000O7-N1; Wed, 04 May 2005 07:46:36 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050502150632.GM577@postel.suug.ch> References: <4273BBAA.6060405@trash.net> <1114882045.8929.123.camel@localhost.localdomain> <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 07:46:34 -0400 Message-Id: <1115207194.7665.109.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2005-02-05 at 17:06 +0200, Thomas Graf wrote: > * jamal <1115035838.8929.236.camel@localhost.localdomain> 2005-05-02 08:10 [..] > > I am beginning to think that perhaps classid should stay as a local > > scope metadata and what Patrick suggested maybe the way out. Although i > > have to admit I dont like a generic function to have a parameter that > > only a very small set of users find useful. If we are going to allow a > > structure to be passed back and forth, perhaps it should also carry > > other things (in addition to _result). Need to think a little. > > What about if we introduce something like struct tcf_pkt_info as we > have it for ematches? I'm using it intensly to share information > from the classifier to ematches to extend and customize existing > classifier. Basically, something along those lines (eg struct tca_pkt_info) in which the tcf_result is one of the components should do it. I would be satisfied with this being the structure in the ->act() parameters because then it could also be used to pass action-metadata around (no action written so far needs such coordination, but its been one of those things i have been thinking of for some dynamic creations for example where the return code is insufficient to describe things). Patrick, either you or i could do it. It doesnt matter if at the moment the structure only contains tcf_result or elements of tcf_result because i will add more to it later. Then we could kill access to tc_classid in exec() > We could declare tc_classid as being global by definition > and hide the current use in the API? I'd really like to be able to > transfer classification results from one device to another. since tc_classid suddenly becomes available theres no question about the need for it being global - which is selectable at the meta action. Global I believe means you dont reset it when you clone/copy. skb->tc_verd is only cleared when we free the skb at the moment and transfered when we clone or copy. A bit or two could be reserved in the tc_verd to say "clear tc_classid" and have the meta action decide if it is global(dont clear) or not(clear - current behavior) during clone/copy . Does this sound reasonable? cheers, jamal From kaber@trash.net Wed May 4 05:15:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 05:15:49 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44CFi7J026246 for ; Wed, 4 May 2005 05:15:45 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DTImi-0005wE-Jx; Wed, 04 May 2005 14:15:24 +0200 Message-ID: <4278BCDC.8010208@trash.net> Date: Wed, 04 May 2005 14:15:24 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Thomas Graf , netdev , "David S. Miller" Subject: Re: patch: Action repeat References: <4273BBAA.6060405@trash.net> <1114882045.8929.123.camel@localhost.localdomain> <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> In-Reply-To: <1115207194.7665.109.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev jamal wrote: > Patrick, either you or i could do it. It doesnt matter if at the moment > the structure only contains tcf_result or elements of tcf_result because > i will add more to it later. Then we could kill access to tc_classid in > exec() I'll do it, I have a few patches touching this code lying around anyway Regards Patrick From tgraf@suug.ch Wed May 4 05:32:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 05:32:10 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44CW37J027237 for ; Wed, 4 May 2005 05:32:04 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id D85521C0EB; Wed, 4 May 2005 14:31:57 +0200 (CEST) Date: Wed, 4 May 2005 14:31:57 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504123157.GA18452@postel.suug.ch> References: <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115207194.7665.109.camel@localhost.localdomain> X-archive-position: 689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > Basically, something along those lines (eg struct tca_pkt_info) in which > the tcf_result is one of the components should do it. > > I would be satisfied with this being the structure in the ->act() > parameters because then it could also be used to pass action-metadata > around (no action written so far needs such coordination, but its been > one of those things i have been thinking of for some dynamic creations > for example where the return code is insufficient to describe things). > Patrick, either you or i could do it. It doesnt matter if at the moment > the structure only contains tcf_result or elements of tcf_result because > i will add more to it later. Then we could kill access to tc_classid in > exec() Sounds good. > Global I believe means you dont reset it when you clone/copy. > skb->tc_verd is only cleared when we free the skb at the moment and > transfered when we clone or copy. A bit or two could be reserved in the > tc_verd to say "clear tc_classid" and have the meta action decide if it > is global(dont clear) or not(clear - current behavior) during > clone/copy . Does this sound reasonable? I have no objections but fail to see why we want to clear it anyway? From hadi@cyberus.ca Wed May 4 05:59:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 05:59:32 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44CxQ7J028673 for ; Wed, 4 May 2005 05:59:27 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DTJT6-0004SE-6d for netdev@oss.sgi.com; Wed, 04 May 2005 06:59:12 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTJT5-0006Xe-BV; Wed, 04 May 2005 08:59:11 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050504123157.GA18452@postel.suug.ch> References: <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 08:59:08 -0400 Message-Id: <1115211549.7665.140.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 14:31 +0200, Thomas Graf wrote: > * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > > tc_verd to say "clear tc_classid" and have the meta action decide if it > > is global(dont clear) or not(clear - current behavior) during > > clone/copy . Does this sound reasonable? > > I have no objections but fail to see why we want to clear it anyway? > If its scope is local i.e for one device, then not reseting could confuse the next device that sees it and tries to classify on it. cheers, jamal From matti.aarnio@zmailer.org Wed May 4 05:58:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 05:58:29 -0700 (PDT) Received: from mail.zmailer.org (van-1-67.lab.dnainternet.fi [62.78.96.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44CwK7J028479 for ; Wed, 4 May 2005 05:58:20 -0700 Received: (mea@mea-ext) by mail.zmailer.org id S1611277AbVEDM5w (ORCPT ); Wed, 4 May 2005 15:57:52 +0300 Date: Wed, 4 May 2005 15:57:52 +0300 From: Matti Aarnio To: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: TCP4/6 socket closure causing system crash.. Message-ID: <20050504125752.GA7399@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 690 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matti.aarnio@zmailer.org Precedence: bulk X-list: netdev I have CVS-pserver running under a chroot wrapper. Recently system has become unresponsive the instance somebody refers to the pserver... I have three kernels to choose from: title Fedora Core (2.6.11-1.1282_FC4smp) title Fedora Core (2.6.11-1.1276_FC4smp) title Fedora Core (2.6.11-1.1191_FC4smp) First two crash, third works just fine for this workset. Serial console capture tells following: ----------------- Kernel 2.6.11-1.1282_FC4smp on an i686 mismatch in kmem_cache_free: expected cache f78ee500, got f7972800 f7972800 is TCP. f78ee500 is TCPv6. Badness in cache_free_debugcheck at mm/slab.c:1926 (Not tainted) [] cache_free_debugcheck+0xb3/0x222 [] sk_free+0x7e/0xff [] kmem_cache_free+0x2a/0x69 [] sk_free+0x7e/0xff [] __kfree_skb+0x54/0x146 [] scsi_finish_command+0x7d/0xd1 [scsi_mod] [] net_tx_action+0x4e/0x121 [] scsi_softirq+0x9a/0xbf [scsi_mod] [] __do_softirq+0x72/0xdc [] do_softirq+0x4b/0x4f ======================= [] do_IRQ+0x55/0x86 [] tcp_v4_destroy_sock+0x9/0x16f [] common_interrupt+0x1a/0x20 [] cpuset_zonelist_valid_mems_allowed+0x3/0x3f [] _spin_lock+0x12/0x40 [] __fput+0xbe/0x10e [] _atomic_dec_and_lock+0x27/0x44 [] dput+0xe5/0x1df [] __fput+0xc5/0x10e [] filp_close+0x4f/0x6d [] put_files_struct+0x6e/0xe7 [] do_exit+0xfc/0x36a [] __dequeue_signal+0xe9/0x1aa [] do_group_exit+0x29/0x90 [] get_signal_to_deliver+0x263/0x371 [] do_signal+0x5d/0x111 [] poison_obj+0x20/0x3d [] cache_free_debugcheck+0x138/0x222 [] sys_open+0x4a/0x5b [] do_page_fault+0x0/0x6a7 [] do_notify_resume+0x28/0x39 [] work_notifysig+0x13/0x15 slab error in cache_free_debugcheck(): cache `TCP': double free, or memory outside object was overwritten [] cache_free_debugcheck+0x19e/0x222 [] sk_free+0x7e/0xff [] kmem_cache_free+0x2a/0x69 [] sk_free+0x7e/0xff [] __kfree_skb+0x54/0x146 [] scsi_finish_command+0x7d/0xd1 [scsi_mod] [] net_tx_action+0x4e/0x121 [] scsi_softirq+0x9a/0xbf [scsi_mod] [] __do_softirq+0x72/0xdc [] do_softirq+0x4b/0x4f ======================= [] do_IRQ+0x55/0x86 [] tcp_v4_destroy_sock+0x9/0x16f [] common_interrupt+0x1a/0x20 [] cpuset_zonelist_valid_mems_allowed+0x3/0x3f [] _spin_lock+0x12/0x40 [] __fput+0xbe/0x10e [] _atomic_dec_and_lock+0x27/0x44 [] dput+0xe5/0x1df [] __fput+0xc5/0x10e [] filp_close+0x4f/0x6d [] put_files_struct+0x6e/0xe7 [] do_exit+0xfc/0x36a [] __dequeue_signal+0xe9/0x1aa [] do_group_exit+0x29/0x90 [] get_signal_to_deliver+0x263/0x371 [] do_signal+0x5d/0x111 [] poison_obj+0x20/0x3d [] cache_free_debugcheck+0x138/0x222 [] sys_open+0x4a/0x5b [] do_page_fault+0x0/0x6a7 [] do_notify_resume+0x28/0x39 [] work_notifysig+0x13/0x15 f6456f10: redzone 1: 0x170fc2a5, redzone 2: 0x0. ------------[ cut here ]------------ kernel BUG at mm/slab.c:1946! invalid operand: 0000 [#1] SMP Modules linked in: parport_pc lp parport w83627hf eeprom i2c_sensor i2c_isa ip_conntrack_ftp ipt_conntrack iptable_mangle ipt_state ip_conntrack ipt_REJECT iptable_filter ip_tables ip6table_filter ip6_tables md5 ipv6 dm_mod video button battery ac ohci1394 ieee1394 uhci_hcd ehci_hcd hw_random tpm_nsc tpm i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc e100 mii sk98lin dummy floppy ext3 jbd raid1 qla2300 qla2xxx scsi_transport_fc sata_sil ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010016 (2.6.11-1.1282_FC4smp) EIP is at cache_free_debugcheck+0x215/0x222 eax: f6456dcc ebx: 00012c00 ecx: 00000ca8 edx: 00000144 esi: f7972800 edi: f6456124 ebp: f6456f10 esp: c040bf48 ds: 007b es: 007b ss: 0068 Process cvs (pid: 7668, threadinfo=c040b000 task=d7882020) Stack: c03206d4 f6456f10 170fc2a5 00000000 c0451840 c02a42a7 f6456f14 f7972800 f7d79f18 00000286 c014d20d f6456f14 00000000 c2012480 0000000a c02a42a7 f7ce0fc0 f7ce0ff8 c23b002c f31b8b3c f51dde3c c02a58c1 f7d5b8f4 0000000a Call Trace: [] sk_free+0x7e/0xff [] kmem_cache_free+0x2a/0x69 [] sk_free+0x7e/0xff [] __kfree_skb+0x54/0x146 [] scsi_finish_command+0x7d/0xd1 [scsi_mod] [] net_tx_action+0x4e/0x121 [] scsi_softirq+0x9a/0xbf [scsi_mod] [] __do_softirq+0x72/0xdc [] do_softirq+0x4b/0x4f ======================= [] do_IRQ+0x55/0x86 [] tcp_v4_destroy_sock+0x9/0x16f [] common_interrupt+0x1a/0x20 [] cpuset_zonelist_valid_mems_allowed+0x3/0x3f [] _spin_lock+0x12/0x40 [] __fput+0xbe/0x10e [] _atomic_dec_and_lock+0x27/0x44 [] dput+0xe5/0x1df [] __fput+0xc5/0x10e [] filp_close+0x4f/0x6d [] put_files_struct+0x6e/0xe7 [] do_exit+0xfc/0x36a [] __dequeue_signal+0xe9/0x1aa [] do_group_exit+0x29/0x90 [] get_signal_to_deliver+0x263/0x371 [] do_signal+0x5d/0x111 [] poison_obj+0x20/0x3d [] cache_free_debugcheck+0x138/0x222 [] sys_open+0x4a/0x5b [] do_page_fault+0x0/0x6a7 [] do_notify_resume+0x28/0x39 [] work_notifysig+0x13/0x15 Code: 8b 9e b4 00 00 00 e9 d0 fe ff ff 89 ea 89 f0 e8 fb e3 ff ff 81 38 a5 c2 0f 17 75 87 eb c4 0f 0b 99 07 53 fb 31 c0 e9 d9 fe ff ff <0f> 0b 9a 07 53 fb 31 c0 e9 da fe ff ff 55 57 56 53 83 ec 14 89 <0>Kernel panic - not syncing: Fatal exception in interrupt [] panic+0x45/0x1e8 [] die+0x17b/0x185 [] do_invalid_op+0x0/0xab [] do_invalid_op+0xa2/0xab [] cache_free_debugcheck+0x215/0x222 [] call_console_drivers+0x80/0x14c [] release_console_sem+0x78/0xb5 [] vprintk+0x1f5/0x2a9 [] error_code+0x4f/0x54 [] cache_free_debugcheck+0x215/0x222 [] sk_free+0x7e/0xff [] kmem_cache_free+0x2a/0x69 [] sk_free+0x7e/0xff [] __kfree_skb+0x54/0x146 [] scsi_finish_command+0x7d/0xd1 [scsi_mod] [] net_tx_action+0x4e/0x121 [] scsi_softirq+0x9a/0xbf [scsi_mod] [] __do_softirq+0x72/0xdc [] do_softirq+0x4b/0x4f ======================= [] do_IRQ+0x55/0x86 [] tcp_v4_destroy_sock+0x9/0x16f [] common_interrupt+0x1a/0x20 [] cpuset_zonelist_valid_mems_allowed+0x3/0x3f [] _spin_lock+0x12/0x40 [] __fput+0xbe/0x10e [] _atomic_dec_and_lock+0x27/0x44 [] dput+0xe5/0x1df [] __fput+0xc5/0x10e [] filp_close+0x4f/0x6d [] put_files_struct+0x6e/0xe7 [] do_exit+0xfc/0x36a [] __dequeue_signal+0xe9/0x1aa [] do_group_exit+0x29/0x90 [] get_signal_to_deliver+0x263/0x371 [] do_signal+0x5d/0x111 [] poison_obj+0x20/0x3d [] cache_free_debugcheck+0x138/0x222 [] sys_open+0x4a/0x5b [] do_page_fault+0x0/0x6a7 [] do_notify_resume+0x28/0x39 [] work_notifysig+0x13/0x15 From tgraf@suug.ch Wed May 4 06:28:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:28:22 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44DSG7J030259 for ; Wed, 4 May 2005 06:28:16 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id CCF831C0EB; Wed, 4 May 2005 15:28:22 +0200 (CEST) Date: Wed, 4 May 2005 15:28:22 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504132822.GB18452@postel.suug.ch> References: <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115211549.7665.140.camel@localhost.localdomain> X-archive-position: 692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115211549.7665.140.camel@localhost.localdomain> 2005-05-04 08:59 > On Wed, 2005-04-05 at 14:31 +0200, Thomas Graf wrote: > > * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > > > > tc_verd to say "clear tc_classid" and have the meta action decide if it > > > is global(dont clear) or not(clear - current behavior) during > > > clone/copy . Does this sound reasonable? > > > > I have no objections but fail to see why we want to clear it anyway? > > > > If its scope is local i.e for one device, then not reseting could > confuse the next device that sees it and tries to classify on it. OK, so we're not talking about a reset in action_exec() but rather in tc_classify() or enqueue()? From tgraf@suug.ch Wed May 4 06:32:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:33:06 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44DWw7J031061 for ; Wed, 4 May 2005 06:32:58 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 24D491C0EB; Wed, 4 May 2005 15:33:06 +0200 (CEST) Date: Wed, 4 May 2005 15:33:06 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504133306.GC18452@postel.suug.ch> References: <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504132822.GB18452@postel.suug.ch> X-archive-position: 693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Thomas Graf <20050504132822.GB18452@postel.suug.ch> 2005-05-04 15:28 > * jamal <1115211549.7665.140.camel@localhost.localdomain> 2005-05-04 08:59 > > On Wed, 2005-04-05 at 14:31 +0200, Thomas Graf wrote: > > > * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > > > > > > tc_verd to say "clear tc_classid" and have the meta action decide if it > > > > is global(dont clear) or not(clear - current behavior) during > > > > clone/copy . Does this sound reasonable? > > > > > > I have no objections but fail to see why we want to clear it anyway? > > > > > > > If its scope is local i.e for one device, then not reseting could > > confuse the next device that sees it and tries to classify on it. > > OK, so we're not talking about a reset in action_exec() but rather > in tc_classify() or enqueue()? Sorry, little bit to vague, what I mean is before the first call to tc_classify() or enqueue() on a new device. From hadi@cyberus.ca Wed May 4 06:33:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:33:41 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44DXd7J031132 for ; Wed, 4 May 2005 06:33:39 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DTK0D-0004oY-GJ for netdev@oss.sgi.com; Wed, 04 May 2005 09:33:25 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTK0A-00056n-Vm; Wed, 04 May 2005 09:33:23 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050504132822.GB18452@postel.suug.ch> References: <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 09:33:20 -0400 Message-Id: <1115213600.7665.166.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 15:28 +0200, Thomas Graf wrote: > * jamal <1115211549.7665.140.camel@localhost.localdomain> 2005-05-04 08:59 > > On Wed, 2005-04-05 at 14:31 +0200, Thomas Graf wrote: > > > * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > > > > > > tc_verd to say "clear tc_classid" and have the meta action decide if it > > > > is global(dont clear) or not(clear - current behavior) during > > > > clone/copy . Does this sound reasonable? > > > > > > I have no objections but fail to see why we want to clear it anyway? > > > > > > > If its scope is local i.e for one device, then not reseting could > > confuse the next device that sees it and tries to classify on it. > > OK, so we're not talking about a reset in action_exec() but rather > in tc_classify() or enqueue()? in skb_clone() and friends. Look at CONFIG_NET_CLS_ACT in net/core/skbuff.c cheers, jamal From tgraf@suug.ch Wed May 4 06:48:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:48:12 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44Dm77J000302 for ; Wed, 4 May 2005 06:48:10 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 4BE831C0EB; Wed, 4 May 2005 15:48:15 +0200 (CEST) Date: Wed, 4 May 2005 15:48:15 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504134815.GD18452@postel.suug.ch> References: <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115213600.7665.166.camel@localhost.localdomain> X-archive-position: 695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115213600.7665.166.camel@localhost.localdomain> 2005-05-04 09:33 > On Wed, 2005-04-05 at 15:28 +0200, Thomas Graf wrote: > > * jamal <1115211549.7665.140.camel@localhost.localdomain> 2005-05-04 08:59 > > > If its scope is local i.e for one device, then not reseting could > > > confuse the next device that sees it and tries to classify on it. > > > > OK, so we're not talking about a reset in action_exec() but rather > > in tc_classify() or enqueue()? > > in skb_clone() and friends. > Look at CONFIG_NET_CLS_ACT in net/core/skbuff.c Yes this solves the case for dummy devices etc but how would this cause a reset on the way from ingress to egress? From hadi@cyberus.ca Wed May 4 06:53:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:53:23 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44DrL7J000963 for ; Wed, 4 May 2005 06:53:21 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DTKJI-00048H-E4 for netdev@oss.sgi.com; Wed, 04 May 2005 09:53:08 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTKJF-0000PU-0b; Wed, 04 May 2005 09:53:05 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050504134815.GD18452@postel.suug.ch> References: <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> <20050504134815.GD18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 09:53:02 -0400 Message-Id: <1115214782.7665.184.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 15:48 +0200, Thomas Graf wrote: > * jamal <1115213600.7665.166.camel@localhost.localdomain> 2005-05-04 09:33 > > in skb_clone() and friends. > > Look at CONFIG_NET_CLS_ACT in net/core/skbuff.c > > Yes this solves the case for dummy devices etc but how would > this cause a reset on the way from ingress to egress? If the verdict is not to reset, there should be no clearing of those fields from ingress -> egress until the skb is either freed or someone else along the path resets it. Cloning or copying inherits. Am i missing something? cheers, jamal From tgraf@suug.ch Wed May 4 07:05:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 07:05:39 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44E5X7J001801 for ; Wed, 4 May 2005 07:05:33 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B36A31C0EB; Wed, 4 May 2005 16:05:40 +0200 (CEST) Date: Wed, 4 May 2005 16:05:40 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504140540.GE18452@postel.suug.ch> References: <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> <20050504134815.GD18452@postel.suug.ch> <1115214782.7665.184.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115214782.7665.184.camel@localhost.localdomain> X-archive-position: 697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115214782.7665.184.camel@localhost.localdomain> 2005-05-04 09:53 > On Wed, 2005-04-05 at 15:48 +0200, Thomas Graf wrote: > > * jamal <1115213600.7665.166.camel@localhost.localdomain> 2005-05-04 09:33 > > > > in skb_clone() and friends. > > > Look at CONFIG_NET_CLS_ACT in net/core/skbuff.c > > > > Yes this solves the case for dummy devices etc but how would > > this cause a reset on the way from ingress to egress? > > If the verdict is not to reset, there should be no clearing of those > fields from ingress -> egress until the skb is either freed or someone > else along the path resets it. Cloning or copying inherits. Am i missing > something? I guess not but we might have a different understanding of when to reset. From my point of view the only reason to reset any meta data is to provide a certain scope a set of new fresh and clean sheets to play around. Assuming we define global as everything and local as per device/(ingress|egress) then we definitely need to invoke a reset on the way over to egress. From hadi@cyberus.ca Wed May 4 07:24:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 07:24:18 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44EO57J002959 for ; Wed, 4 May 2005 07:24:07 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DTKn3-0008Jy-B4 for netdev@oss.sgi.com; Wed, 04 May 2005 10:23:53 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTKn1-00067q-By; Wed, 04 May 2005 10:23:51 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050504140540.GE18452@postel.suug.ch> References: <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> <20050504134815.GD18452@postel.suug.ch> <1115214782.7665.184.camel@localhost.localdomain> <20050504140540.GE18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 10:23:49 -0400 Message-Id: <1115216629.7906.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 16:05 +0200, Thomas Graf wrote: > Assuming we define global as everything and local > as per device/(ingress|egress) then we definitely need to invoke > a reset on the way over to egress. Agreed. So shall we stick then to just make it a global-only? cheers, jamal From tgraf@suug.ch Wed May 4 07:53:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 07:53:40 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44ErZ7J004294 for ; Wed, 4 May 2005 07:53:35 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B11E71C0EB; Wed, 4 May 2005 16:53:41 +0200 (CEST) Date: Wed, 4 May 2005 16:53:41 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504145341.GG18452@postel.suug.ch> References: <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> <20050504134815.GD18452@postel.suug.ch> <1115214782.7665.184.camel@localhost.localdomain> <20050504140540.GE18452@postel.suug.ch> <1115216629.7906.4.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115216629.7906.4.camel@localhost.localdomain> X-archive-position: 699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115216629.7906.4.camel@localhost.localdomain> 2005-05-04 10:23 > On Wed, 2005-04-05 at 16:05 +0200, Thomas Graf wrote: > > > > Assuming we define global as everything and local > > as per device/(ingress|egress) then we definitely need to invoke > > a reset on the way over to egress. > > Agreed. So shall we stick then to just make it a global-only? As long as we can't find a way to have a well defined local scope which is both easy to implement and easy to understand for the user a global-only scope with the ability for the user to reset the value via the meta action is most reasonable to me. We need to define this well because it will get to be the backend for any advanced classyfing over multiple devices. I will give it some more thinking in the background, in the meantime I suggest to implement it global-only for now. The global classid issue is the next item on my list and I should be able to come up with something this week after posting rtnetlink neighbour tables patches and the new generic textsearch API + skb search bits + textsearch ematch which will provide optimized textsearching facitilies including a simple regular expression for both linear and non-linear skbs. From johnpol@2ka.mipt.ru Wed May 4 09:12:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 09:12:45 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44GCd7J011409 for ; Wed, 4 May 2005 09:12:40 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with ESMTP id j44GBg1l020484; Wed, 4 May 2005 20:11:42 +0400 Date: Wed, 4 May 2005 20:11:43 +0400 From: Evgeniy Polyakov To: hadi@cyberus.ca Cc: Herbert Xu , netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" Subject: Re: [patch/RFC]: Asynchronous IPsec processing benchmark. Message-ID: <20050504201143.7f6bdcce@zanzibar.2ka.mipt.ru> In-Reply-To: <1115203214.7665.58.camel@localhost.localdomain> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@gondor.apana.org.au> <1115117728.3414.48.camel@uganda> <1115127507.3414.58.camel@uganda> <1115203214.7665.58.camel@localhost.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Wed, 04 May 2005 20:11:43 +0400 (MSD) X-archive-position: 701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev On Wed, 04 May 2005 06:40:14 -0400 jamal wrote: > On Tue, 2005-03-05 at 17:38 +0400, Evgeniy Polyakov wrote: > > Here are some numbers: > > > > ./netperf -l 60 -H gw -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 > > -S 57344 > > > > TCP STREAM TEST to gw : +/-2.5% @ 99% conf. > > > > async-ipsec, 10^6bits/sec: 35.42 > > sync-ipsec, 10^6bits/sec: 37.11 > > > > So even with existing timer deferring it is not noticebly slower [about > > 4%]. > > > > by "sync" i hope you mean the original code without your change? Yes, it is vanilla 2.6.12-rc2 kernel with native IPsec. > The one thing i see in your POC code that may affect numbers a bit is > allocation of struct esp_async every time in the path. Perhaps precreate > a pool of those and then just grab/return to/fro pool; That could be skb too - since both skb/kmalloc atomic allocations end up in kmem_cache_alloc(). > BTW, you may need to incr ref counter of x pre-callback and decrement > when done in callback. It looks like dst entry holding is enough since direct dst->output(), i.e. xfrm_state->output(), call itself is not protected by reference counter, but dst entry is being held during that call. > > And I think that benefits it provides definitely cost that price and > > compile time option. > > I think Herberts concerns about latency should go away if you really > have some proper crypto hardware. Unfortunately I do not have hardware crypto accelerator setup currently [board freezes before even monitor and keyboard blink with my HIFN card, it looks like bus arbitrage problem], so I can not provide real numbers with it, but I will set acrypto with several software crypto providers with that patch on SMP [scheiße, I burned second HT Xeon] (1+1HT) up, and will rerun the test soon. > cheers, > jamal > Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From Robert.Olsson@data.slu.se Wed May 4 09:10:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 09:10:47 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44GAb7J011040 for ; Wed, 4 May 2005 09:10:37 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j44GAKfd019974; Wed, 4 May 2005 18:10:20 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 15B51EE1E9; Wed, 4 May 2005 18:10:20 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17016.62444.34282.625407@robur.slu.se> Date: Wed, 4 May 2005 18:10:20 +0200 To: netdev@oss.sgi.com Cc: Robert Olsson , Jens.Laas@data.slu.se Subject: (diet-)FIB alternative fib_hlist.c X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-archive-position: 700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Hello! fib_hlist is the smallest and simpliest routing algo we could think of it's just a sorted (h)list. routing (FIB lookup) performance. dst hash is not used. fib_hlist fib_hash test routing table size ----------------------------------------------------- 444 kpps 433 kpps Single flow. local=19/main=5 entries 433 kpps 431 kpps rDoS. local=19/main=5 0.2 kpps 198 kpps rDoS local=19/main=123946 As seen fib_hlist is catastrophe for large routing tables as expected but performs surprisingly well for ordinary routing tables so it should be fine for most hosts and servers. The patch has config option to select FIB. Probably we soon want to specify differnt lookup schemes for different tables say for local table fib_hash or fib_hlist. While for large main table fib_hash2/fib_trie would be better option. Cheers. --ro --- net/ipv4/Makefile.orig 2005-04-15 13:42:12.000000000 +0200 +++ net/ipv4/Makefile 2005-05-04 16:24:27.000000000 +0200 @@ -7,8 +7,10 @@ ip_output.o ip_sockglue.o \ tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o tcp_minisocks.o \ datagram.o raw.o udp.o arp.o icmp.o devinet.o af_inet.o igmp.o \ - sysctl_net_ipv4.o fib_frontend.o fib_semantics.o fib_hash.o + sysctl_net_ipv4.o fib_frontend.o fib_semantics.o +obj-$(CONFIG_IP_FIB_HASH) += fib_hash.o +obj-$(CONFIG_IP_FIB_HLIST) += fib_hlist.o obj-$(CONFIG_PROC_FS) += proc.o obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o obj-$(CONFIG_IP_MROUTE) += ipmr.o --- net/ipv4/Kconfig.orig 2005-04-15 13:41:52.000000000 +0200 +++ net/ipv4/Kconfig 2005-05-04 16:23:58.000000000 +0200 @@ -1,6 +1,27 @@ # # IP configuration # +choice + prompt "Choose IP: FIB lookup"" + depends on INET + default IP_FIB_HASH + +config IP_FIB_HASH + bool "FIB_HASH" + ---help--- + Current FIB is very proven and good enough for most users. + +config IP_FIB_HLIST + bool "FIB_HLIST" + depends on INET && EXPERIMENTAL + ---help--- + + Use new very simple and minimalistic lookup algorithm. It should + only be used for small routing tables. Performance is equal to + FIB_HASH with small tables but with less memory use. + +endchoice + config IP_MULTICAST bool "IP: multicasting" depends on INET --- /dev/null 2005-04-14 15:05:36.930846264 +0200 +++ net/ipv4/fib_hlist.c 2005-05-03 20:07:24.000000000 +0200 @@ -0,0 +1,719 @@ +/* + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Robert Olsson Uppsala Universitet + * & Swedish University of Agricultural Sciences. + * + * Jens Laas Swedish University of + * Agricultural Sciences. + * + * Hans Liss Uppsala Universitet + * + * Code from fib_hash has been reused which includes the following header: + * + * Authors: Alexey Kuznetsov, + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/* + * An alternative FIB for applications with small routing table + * The simplest and smallest routing algo eveer all routes is keept + * in a single (h)list sorted by prefix length. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "fib_lookup.h" + +#define VERSION "0.04" + +typedef unsigned int t_key; + +struct fib_hlist_info { + struct hlist_node hlist; + u32 plen; + u32 pfx; + struct list_head falh; +}; + +struct fib_hlist_table { + struct hlist_head list; + rwlock_t lock; +}; + +extern void rtmsg_fib(int event, u32 key, struct fib_alias *fa, int z, int tb_id, + struct nlmsghdr *n, struct netlink_skb_parms *req); + +extern struct fib_alias *fib_find_alias(struct list_head *fah, u8 tos, u32 prio); +extern int fib_detect_death(struct fib_info *fi, int order, + struct fib_info **last_resort, int *last_idx, int *dflt); + +static int debug = 0; +static kmem_cache_t *fn_alias_kmem; +static kmem_cache_t *fn_hlist_kmem; + +static inline void fn_free_node(struct fib_hlist_info * f) +{ + kmem_cache_free(fn_hlist_kmem, f); +} + +/* Candiate for fib_semantics */ + +static void fn_free_alias(struct fib_alias *fa) +{ + fib_release_info(fa->fa_info); + kmem_cache_free(fn_alias_kmem, fa); +} + +static struct fib_hlist_info *fib_find_node(struct hlist_head *head, u32 key, int plen) +{ + struct hlist_node *node; + struct fib_hlist_info *fhi; + + hlist_for_each_entry(fhi, node, head, hlist) { + + if ( fhi->plen == plen && fhi->pfx == key ) + return fhi; + } + return NULL; +} + +static void fib_insert_node(struct hlist_head *head, struct fib_hlist_info *new) +{ + struct fib_hlist_info *fhi=NULL, *last=NULL; + struct hlist_node *node, *tmp; + + if(hlist_empty(head)) + hlist_add_head(&new->hlist, head); + else { + hlist_for_each_entry_safe(fhi, node, tmp, head, hlist) { + + if (new->plen > fhi->plen) + break; + + last = fhi; + } + if(last) + hlist_add_after(&last->hlist, &new->hlist); + else + hlist_add_before(&new->hlist, &fhi->hlist); + } +} + +static int +fn_hlist_insert(struct fib_table *tb, struct rtmsg *r, struct kern_rta *rta, + struct nlmsghdr *nlhdr, struct netlink_skb_parms *req) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + int plen = r->rtm_dst_len; + int type = r->rtm_type; + u8 tos = r->rtm_tos; + u32 key, mask; + int err = 0; + struct fib_alias *fa=NULL, *new_fa; + struct list_head *fa_head=NULL; + struct fib_info *fi; + struct fib_hlist_info *fhi=NULL, *new_fhi; + + if (plen > 32) + return -EINVAL; + + key = 0; + if (rta->rta_dst) + memcpy(&key, rta->rta_dst, 4); + + key = ntohl(key); + mask = ntohl( inet_make_mask(plen) ); + + if(key & ~mask) + return -EINVAL; + + key = key & mask; + + if(debug) + printk("fn_hlist_insert id=%d %08x/%d\n", tb->tb_id, key, plen); + + if ((fi = fib_create_info(r, rta, nlhdr, &err)) == NULL) + return err; + + fhi = fib_find_node(&t->list, key, plen); + + if (!fhi) + fa = NULL; + else { + fa_head = &fhi->falh; + fa = fib_find_alias(fa_head, tos, fi->fib_priority); + } + + /* Now fa, if non-NULL, points to the first fib alias + * with the same keys [prefix,tos,priority], if such key already + * exists or to the node before which we will insert new one. + * + * If fa is NULL, we will need to allocate a new one and + * insert to the head of f. + * + * If f is NULL, no fib node matched the destination key + * and we need to allocate a new one of those as well. + */ + + if (fa && + fa->fa_info->fib_priority == fi->fib_priority) { + struct fib_alias *fa_orig; + + err = -EEXIST; + if (nlhdr->nlmsg_flags & NLM_F_EXCL) + goto out; + + if (nlhdr->nlmsg_flags & NLM_F_REPLACE) { + struct fib_info *fi_drop; + u8 state; + + write_lock_bh(&t->lock); + fi_drop = fa->fa_info; + fa->fa_info = fi; + fa->fa_type = type; + fa->fa_scope = r->rtm_scope; + state = fa->fa_state; + fa->fa_state &= ~FA_S_ACCESSED; + write_unlock_bh(&t->lock); + + fib_release_info(fi_drop); + if (state & FA_S_ACCESSED) + rt_cache_flush(-1); + return 0; + } + + /* Error if we find a perfect match which + * uses the same scope, type, and nexthop + * information. + */ + fa_orig = fa; + list_for_each_entry(fa, fa_orig->fa_list.prev, fa_list) { + if (fa->fa_tos != tos) + break; + if (fa->fa_info->fib_priority != fi->fib_priority) + break; + if (fa->fa_type == type && + fa->fa_scope == r->rtm_scope && + fa->fa_info == fi) + goto out; + } + if (!(nlhdr->nlmsg_flags & NLM_F_APPEND)) + fa = fa_orig; + } + + err = -ENOENT; + if (!(nlhdr->nlmsg_flags&NLM_F_CREATE)) + goto out; + + err = -ENOBUFS; + new_fa = kmem_cache_alloc(fn_alias_kmem, SLAB_KERNEL); + if (new_fa == NULL) + goto out; + + new_fa->fa_info = fi; + new_fa->fa_tos = tos; + new_fa->fa_type = type; + new_fa->fa_scope = r->rtm_scope; + new_fa->fa_state = 0; + + new_fhi = NULL; + if (!fhi) { + new_fhi = kmem_cache_alloc(fn_hlist_kmem, SLAB_KERNEL); + if(!new_fhi) + goto out_free_new_fa; + + new_fhi->plen = plen; + new_fhi->pfx = key; + + INIT_LIST_HEAD(&new_fhi->falh); + fa_head = &new_fhi->falh; + } + + /* + * Insert new entry to the list. + */ + + write_lock_bh(&t->lock); + if(new_fhi) + fib_insert_node(&t->list, new_fhi); + + list_add_tail(&new_fa->fa_list, + (fa ? &fa->fa_list : fa_head)); + write_unlock_bh(&t->lock); + + rt_cache_flush(-1); + rtmsg_fib(RTM_NEWROUTE, key, new_fa, plen, tb->tb_id, nlhdr, req); + return 0; + +out_free_new_fa: + kmem_cache_free(fn_alias_kmem, new_fa); +out: + fib_release_info(fi); + return err; +} + +static int +fn_hlist_lookup(struct fib_table *tb, const struct flowi *flp, struct fib_result *res) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + t_key key; + u32 mask; + int ret; + struct fib_hlist_info *fhi = NULL; + struct hlist_node *node; + + key = ntohl( flp->fl4_dst ); + + read_lock(&t->lock); + hlist_for_each_entry(fhi, node, &t->list, hlist) { + + mask = ntohl( inet_make_mask(fhi->plen) ); + + if (fhi->pfx == (key & mask)) { + ret = fib_semantic_match(&fhi->falh, flp, res, fhi->plen); + + if(ret <= 0) + goto found; + } + } + ret = 1; +found: + read_unlock(&t->lock); + return ret; +} + +static int +fn_hlist_delete(struct fib_table *tb, struct rtmsg *r, struct kern_rta *rta, + struct nlmsghdr *nlhdr, struct netlink_skb_parms *req) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + u32 key, mask; + int plen = r->rtm_dst_len; + u8 tos = r->rtm_tos; + int err = 0; + int kill_fn = 0; + struct fib_alias *fa, *fa_to_delete; + struct list_head *fa_head; + struct hlist_node *node; + struct fib_hlist_info *fhi = NULL; + + if (plen > 32) + return -EINVAL; + + key = 0; + if (rta->rta_dst) + memcpy(&key, rta->rta_dst, 4); + + key = ntohl(key); + mask = ntohl( inet_make_mask(plen) ); + + if(key & ~mask) + return -EINVAL; + + key = key & mask; + + if(debug) + printk("fn_hlist_delete id=%d %08x/%d\n", tb->tb_id, key, plen); + + hlist_for_each_entry(fhi, node, &t->list, hlist) { + if (fhi->plen == plen && fhi->pfx == key ) { + fa = fib_find_alias(&fhi->falh, tos, 0); + if(fa) + goto got_alias; + } + } + return -ESRCH; + +got_alias: + fa_to_delete = NULL; + fa_head = fa->fa_list.prev; + list_for_each_entry(fa, fa_head, fa_list) { + struct fib_info *fi = fa->fa_info; + + if (fa->fa_tos != tos) + break; + + if ((!r->rtm_type || + fa->fa_type == r->rtm_type) && + (r->rtm_scope == RT_SCOPE_NOWHERE || + fa->fa_scope == r->rtm_scope) && + (!r->rtm_protocol || + fi->fib_protocol == r->rtm_protocol) && + fib_nh_match(r, nlhdr, rta, fi) == 0) { + fa_to_delete = fa; + break; + } + } + + if (! fa_to_delete) + return -ESRCH; + + kill_fn = 0; + fa = fa_to_delete; + + rtmsg_fib(RTM_DELROUTE, key, fa, plen, tb->tb_id, nlhdr, req); + + write_lock_bh(&t->lock); + list_del(&fa->fa_list); + + /* Remove fib_hlist_info in case */ + + if(list_empty(fa_head)) { + hlist_del(&fhi->hlist); + kill_fn = 1; + } + write_unlock_bh(&t->lock); + + if (fa->fa_state & FA_S_ACCESSED) + rt_cache_flush(-1); + + fn_free_alias(fa); + + if (kill_fn) + fn_free_node(fhi); + + return err; +} + +static int hlist_flush_list(struct fib_hlist_table *t, struct list_head *fah) +{ + struct list_head *head = fah; + struct fib_alias *fa, *fa_node; + int found = 0; + + list_for_each_entry_safe(fa, fa_node, head, fa_list) { + struct fib_info *fi = fa->fa_info; + + if (fi && (fi->fib_flags&RTNH_F_DEAD)) { + + write_lock_bh(&t->lock); + list_del(&fa->fa_list); + write_unlock_bh(&t->lock); + + fn_free_alias(fa); + found++; + } + } + return found; +} + +static int fn_hlist_flush(struct fib_table *tb) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + int found = 0; + struct hlist_head *bh; + struct hlist_node *node; + struct hlist_node *tmp; + struct fib_hlist_info *fhi; + int kill_f; + + if(debug) + printk("fn_hlist_flush table=%d\n", tb->tb_id); + + bh = &t->list; + + hlist_for_each_entry_safe(fhi, node, tmp, bh, hlist) { + if(list_empty(&fhi->falh)) + continue; + + found += hlist_flush_list(t, &fhi->falh); + + kill_f = 0; + write_lock_bh(&t->lock); + if(list_empty(&fhi->falh)) { + hlist_del(&fhi->hlist); + kill_f = 1; + } + write_unlock_bh(&t->lock); + + if(kill_f) + fn_free_node(fhi); + } + + if(debug) + printk("fn_hlist_flush flushed=%d\n", found); + + return found; +} + +static int hlist_last_dflt=-1; + +static void +fn_hlist_select_default(struct fib_table *tb, const struct flowi *flp, struct fib_result *res) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + int order, last_idx; + struct fib_info *fi = NULL; + struct fib_info *last_resort; + struct fib_alias *fa = NULL; + struct fib_hlist_info *fhi; + + if(debug) + printk("fn_hlist_select_default\n"); + + fhi = fib_find_node(&t->list, 0, 0); + + if(!fhi) + return; + + if (list_empty(&fhi->falh)) + return; + + last_idx = -1; + last_resort = NULL; + order = -1; + + list_for_each_entry(fa, &fhi->falh, fa_list) { + struct fib_info *next_fi = fa->fa_info; + + if (fa->fa_scope != res->scope || + fa->fa_type != RTN_UNICAST) + continue; + + if (next_fi->fib_priority > res->fi->fib_priority) + break; + if (!next_fi->fib_nh[0].nh_gw || + next_fi->fib_nh[0].nh_scope != RT_SCOPE_LINK) + continue; + fa->fa_state |= FA_S_ACCESSED; + + if (fi == NULL) { + if (next_fi != res->fi) + break; + } else if (!fib_detect_death(fi, order, &last_resort, + &last_idx, &hlist_last_dflt)) { + if (res->fi) + fib_info_put(res->fi); + res->fi = fi; + atomic_inc(&fi->fib_clntref); + hlist_last_dflt = order; + goto out; + } + fi = next_fi; + order++; + } + + if (order <= 0 || fi == NULL) { + hlist_last_dflt = -1; + goto out; + } + + if (!fib_detect_death(fi, order, &last_resort, &last_idx, &hlist_last_dflt)) { + if (res->fi) + fib_info_put(res->fi); + res->fi = fi; + atomic_inc(&fi->fib_clntref); + hlist_last_dflt = order; + goto out; + } + + if (last_idx >= 0) { + if (res->fi) + fib_info_put(res->fi); + res->fi = last_resort; + if (last_resort) + atomic_inc(&last_resort->fib_clntref); + } + hlist_last_dflt = last_idx; + out:; +} + +static inline int fn_hlist_dump_fa(t_key key, int plen, struct list_head *fah, struct fib_table *tb, + struct sk_buff *skb, struct netlink_callback *cb) +{ + int i, s_i; + struct fib_alias *fa; + u32 xkey=htonl(key); + s_i=cb->args[3]; + i = 0; + + list_for_each_entry(fa, fah, fa_list) { + + if (i < s_i) + goto next; + + if (fa->fa_info->fib_nh == NULL) + goto next; + + if (fa->fa_info == NULL) + goto next; + + if (fib_dump_info(skb, NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, + RTM_NEWROUTE, + tb->tb_id, + fa->fa_type, + fa->fa_scope, + &xkey, + plen, + fa->fa_tos, + fa->fa_info) < 0) { + cb->args[3] = i; + return -1; + } + next: + i++; + } + cb->args[3]=i; + return skb->len; +} + +static inline int fn_hlist_dump_plen(int plen, struct fib_table *tb, + struct sk_buff *skb, struct netlink_callback *cb) +{ + int s_i = cb->args[2]; + int i = 0; + struct hlist_node *node; + struct fib_hlist_info *fhi; + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + struct hlist_head *head; + + head = &t->list; + + hlist_for_each_entry(fhi, node, head, hlist) { + + if (i < s_i) + goto next; + + if (i > s_i) + memset(&cb->args[3], 0, + sizeof(cb->args) - 3*sizeof(cb->args[0])); + + if (fhi->plen == plen) { + + if (fn_hlist_dump_fa(fhi->pfx, fhi->plen, &fhi->falh, tb, skb, cb)<0) { + cb->args[2]=i; + return -1; + } + } + next: + i++; + } + cb->args[2]=i; + return skb->len; +} + +static int fn_hlist_dump(struct fib_table *tb, struct sk_buff *skb, struct netlink_callback *cb) +{ + int m, s_m; + s_m= cb->args[1]; + + for (m=s_m; m<=32; m++) { + + if (m < s_m) continue; + if (m > s_m) + memset(&cb->args[2], 0, + sizeof(cb->args) - 2*sizeof(cb->args[0])); + + if (fn_hlist_dump_plen(32-m, tb, skb, cb)<0) { + cb->args[1] = m; + return -1; + } + } + cb->args[1] = m; + return skb->len; +} + +void create(struct fib_table *tb) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + + INIT_HLIST_HEAD(&t->list); + + printk(KERN_INFO "IP: FIB_hlist vers %s routing table id=%d\n", + VERSION, tb->tb_id); +} + +#ifdef CONFIG_IP_MULTIPLE_TABLES +struct fib_table * fib_hash_init(int id) +#else +struct fib_table * __init fib_hash_init(int id) +#endif +{ + struct fib_table *tb; + struct fib_hlist_table *t; + + if (fn_alias_kmem == NULL) + fn_alias_kmem = kmem_cache_create("ip_fib_alias", + sizeof(struct fib_alias), + 0, SLAB_HWCACHE_ALIGN, + NULL, NULL); + + if (fn_hlist_kmem == NULL) + fn_hlist_kmem = kmem_cache_create("ip_hlist_info", + sizeof(struct fib_hlist_info), + 0, SLAB_HWCACHE_ALIGN, + NULL, NULL); + + tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fib_hlist_table), + GFP_KERNEL); + + if (tb == NULL) + return NULL; + + tb->tb_id = id; + tb->tb_lookup = fn_hlist_lookup; + tb->tb_insert = fn_hlist_insert; + tb->tb_delete = fn_hlist_delete; + tb->tb_flush = fn_hlist_flush; + tb->tb_select_default = fn_hlist_select_default; + tb->tb_dump = fn_hlist_dump; + memset(tb->tb_data, 0, sizeof(struct fib_hlist_table)); + + t = (struct fib_hlist_table *) tb->tb_data; + + t->lock = RW_LOCK_UNLOCKED; + + create(tb); + return tb; +} + +#ifdef CONFIG_PROC_FS + +int __init fib_proc_init(void) +{ + return 0; +} + +void __init fib_proc_exit(void) +{ + proc_net_remove("route"); +} +#endif /* CONFIG_PROC_FS */ + From arnaldo.melo@gmail.com Wed May 4 09:16:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 09:16:49 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44GGV7J012118 for ; Wed, 4 May 2005 09:16:34 -0700 Received: by zproxy.gmail.com with SMTP id 8so265066nzo for ; Wed, 04 May 2005 09:16:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V9AeM40jQNUinWDtmgPwrH3tm3pvqZumf1APxvwGUO2FvUhy5zy62xVf1+wWnw70SzszEptH41E6KvJHCVvpf5uf6eNVUlTMRMyD9T/kYjlzrSI4cgnSR6lZ6+TCGNpEZ+npRAod8vzNX0MA7Pd/6X4/b0q7FEUZUzNIe24GqUs= Received: by 10.36.8.20 with SMTP id 20mr164344nzh; Wed, 04 May 2005 09:16:17 -0700 (PDT) Received: by 10.36.56.15 with HTTP; Wed, 4 May 2005 09:16:17 -0700 (PDT) Message-ID: <39e6f6c705050409161b90858b@mail.gmail.com> Date: Wed, 4 May 2005 13:16:17 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@ghostprotocols.net To: Matti Aarnio Subject: Re: TCP4/6 socket closure causing system crash.. Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <20050504125752.GA7399@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050504125752.GA7399@mea-ext.zmailer.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j44GGV7J012118 X-archive-position: 702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On 5/4/05, Matti Aarnio wrote: > I have CVS-pserver running under a chroot wrapper. > Recently system has become unresponsive the instance somebody > refers to the pserver... > > I have three kernels to choose from: > > title Fedora Core (2.6.11-1.1282_FC4smp) > title Fedora Core (2.6.11-1.1276_FC4smp) > title Fedora Core (2.6.11-1.1191_FC4smp) > > First two crash, third works just fine for this workset. > > Serial console capture tells following: > > ----------------- > > Kernel 2.6.11-1.1282_FC4smp on an i686 > > mismatch in kmem_cache_free: expected cache f78ee500, got f7972800 Look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155389 Try with the sk_prot_creator patch. - Arnaldo From shemminger@osdl.org Wed May 4 10:10:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 10:10:24 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44HAB7J014749 for ; Wed, 4 May 2005 10:10:12 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j44H9rU3013104 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 4 May 2005 10:09:54 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j44H9rRC001301; Wed, 4 May 2005 10:09:53 -0700 Date: Wed, 4 May 2005 10:09:53 -0700 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: [RFC] alternate way of handling netem duplication Message-ID: <20050504100953.615e28b8@dxpl.pdx.osdl.net> In-Reply-To: <42782B59.3000500@trash.net> References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> <42780DB2.2090201@trash.net> <20050503165937.0c6cac6d.davem@davemloft.net> <42782B59.3000500@trash.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Here is an alternate way of handling duplication. What it does is mark the packets on enqueue with a repcount. Then on dequeue it cheats and bypasses direct to the device avoiding the other qdisc. When duplication takes place in the dequeue there is a harmless race. Since qdisc_xmit (formerly part of qdisc_restart) drops queue_lock, and reacquires. Therefore netem dequeue will return NULL causing qdisc_restart to return qlen > 0 and qdisc_run will recall qdisc_restart, which will pick up the same packet again. It is untested, and reordering needs fixing. Index: netem-2.6.12-rc3/net/sched/sch_netem.c =================================================================== --- netem-2.6.12-rc3.orig/net/sched/sch_netem.c +++ netem-2.6.12-rc3/net/sched/sch_netem.c @@ -59,7 +59,6 @@ struct netem_sched_data { u32 latency; u32 loss; u32 limit; - u32 counter; u32 gap; u32 jitter; u32 duplicate; @@ -78,6 +77,7 @@ struct netem_sched_data { /* Time stamp put into socket buffer control block */ struct netem_skb_cb { psched_time_t time_to_send; + int repcount; }; /* init_crandom - initialize correlated random number generator @@ -137,35 +137,6 @@ static long tabledist(unsigned long mu, return x / NETEM_DIST_SCALE + (sigma / NETEM_DIST_SCALE) * t + mu; } -/* Put skb in the private delayed queue. */ -static int netem_delay(struct Qdisc *sch, struct sk_buff *skb) -{ - struct netem_sched_data *q = qdisc_priv(sch); - psched_tdiff_t td; - psched_time_t now; - - PSCHED_GET_TIME(now); - td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist); - - /* Always queue at tail to keep packets in order */ - if (likely(q->delayed.qlen < q->limit)) { - struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; - - PSCHED_TADD2(now, td, cb->time_to_send); - - pr_debug("netem_delay: skb=%p now=%llu tosend=%llu\n", skb, - now, cb->time_to_send); - - __skb_queue_tail(&q->delayed, skb); - return NET_XMIT_SUCCESS; - } - - pr_debug("netem_delay: queue over limit %d\n", q->limit); - sch->qstats.overlimits++; - kfree_skb(skb); - return NET_XMIT_DROP; -} - /* * Move a packet that is ready to send from the delay holding * list to the underlying qdisc. @@ -206,64 +177,45 @@ static int netem_run(struct Qdisc *sch) static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); - int ret; + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + psched_tdiff_t td; + psched_time_t now; pr_debug("netem_enqueue skb=%p\n", skb); + cb->repcount = 1; + PSCHED_GET_TIME(now); + td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist); + PSCHED_TADD2(now, td, cb->time_to_send); + + pr_debug("netem_enqueue: skb=%p now=%llu tosend=%llu\n", skb, + now, cb->time_to_send); + /* Random packet drop 0 => none, ~0 => all */ - if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { - pr_debug("netem_enqueue: random loss\n"); - sch->qstats.drops++; - kfree_skb(skb); - return 0; /* lie about loss so TCP doesn't know */ - } + if (q->loss && q->loss >= get_crandom(&q->loss_cor)) + --cb->repcount; /* Random duplication */ - if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor)) { - struct sk_buff *skb2; + if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor)) + ++cb->repcount; - skb2 = skb_clone(skb, GFP_ATOMIC); - if (skb2 && netem_delay(sch, skb2) == NET_XMIT_SUCCESS) { - struct Qdisc *qp; - - /* Since one packet can generate two packets in the - * queue, the parent's qlen accounting gets confused, - * so fix it. - */ - qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); - if (qp) - qp->q.qlen++; - - sch->q.qlen++; - sch->bstats.bytes += skb2->len; - sch->bstats.packets++; - } else - sch->qstats.drops++; - } - - /* If doing simple delay then gap == 0 so all packets - * go into the delayed holding queue - * otherwise if doing out of order only "1 out of gap" - * packets will be delayed. - */ - if (q->counter < q->gap) { - ++q->counter; - ret = q->qdisc->enqueue(skb, q->qdisc); - } else { - q->counter = 0; - ret = netem_delay(sch, skb); - netem_run(sch); + if (cb->repcount == 0) { + kfree_skb(skb); + return 0; } - if (likely(ret == NET_XMIT_SUCCESS)) { - sch->q.qlen++; - sch->bstats.bytes += skb->len; - sch->bstats.packets++; - } else + if (q->delayed.qlen < q->limit) { sch->qstats.drops++; - - pr_debug("netem: enqueue ret %d\n", ret); - return ret; + kfree_skb(skb); + return NET_XMIT_DROP; + } + + __skb_queue_tail(&q->delayed, skb); + sch->q.qlen++; + sch->bstats.bytes += skb->len; + sch->bstats.packets++; + + return NET_XMIT_SUCCESS; } /* Requeue packets but don't change time stamp */ @@ -302,7 +254,23 @@ static struct sk_buff *netem_dequeue(str skb = q->qdisc->dequeue(q->qdisc); if (skb) { - pr_debug("netem_dequeue: return skb=%p\n", skb); + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + + printk("netem_dequeue: skb=%p count=%d\n", skb, cb->repcount); + if (cb->repcount > 1) { + struct sk_buff *skb2; + + /* Go direct to device to avoid problems + with parent qlen */ + skb2 = skb_clone(skb, GFP_ATOMIC); + if (skb2 && qdisc_xmit(sch->dev, skb2) != NETDEV_TX_OK) { + kfree_skb(skb2); + q->qdisc->ops->requeue(skb, q->qdisc); + } + --cb->repcount; + return NULL; + } + sch->q.qlen--; sch->flags &= ~TCQ_F_THROTTLED; } @@ -459,7 +427,6 @@ static int netem_init(struct Qdisc *sch, init_timer(&q->timer); q->timer.function = netem_watchdog; q->timer.data = (unsigned long) sch; - q->counter = 0; q->qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); if (!q->qdisc) { Index: netem-2.6.12-rc3/include/net/pkt_sched.h =================================================================== --- netem-2.6.12-rc3.orig/include/net/pkt_sched.h +++ netem-2.6.12-rc3/include/net/pkt_sched.h @@ -234,6 +234,8 @@ static inline void qdisc_run(struct net_ /* NOTHING */; } +extern int qdisc_xmit(struct net_device *dev, struct sk_buff *skb); + extern int tc_classify(struct sk_buff *skb, struct tcf_proto *tp, struct tcf_result *res); Index: netem-2.6.12-rc3/net/sched/sch_api.c =================================================================== --- netem-2.6.12-rc3.orig/net/sched/sch_api.c +++ netem-2.6.12-rc3/net/sched/sch_api.c @@ -1289,7 +1289,6 @@ static int __init pktsched_init(void) subsys_initcall(pktsched_init); -EXPORT_SYMBOL(qdisc_lookup); EXPORT_SYMBOL(qdisc_get_rtab); EXPORT_SYMBOL(qdisc_put_rtab); EXPORT_SYMBOL(register_qdisc); Index: netem-2.6.12-rc3/net/sched/sch_generic.c =================================================================== --- netem-2.6.12-rc3.orig/net/sched/sch_generic.c +++ netem-2.6.12-rc3/net/sched/sch_generic.c @@ -77,7 +77,78 @@ void qdisc_unlock_tree(struct net_device dev->queue_lock and dev->xmit_lock are mutually exclusive, if one is grabbed, another must be free. */ +int qdisc_xmit(struct net_device *dev, struct sk_buff *skb) +{ + unsigned need_lock = !(dev->features & NETIF_F_LLTX); + + /* + * When the driver has LLTX set it does its own locking + * in start_xmit. No need to add additional overhead by + * locking again. These checks are worth it because + * even uncongested locks can be quite expensive. + * The driver can do trylock like here too, in case + * of lock congestion it should return -1 and the packet + * will be requeued. + */ + if (need_lock) { + if (!spin_trylock(&dev->xmit_lock)) + goto collision; + /* Remember that the driver is grabbed by us. */ + dev->xmit_lock_owner = smp_processor_id(); + } + + /* And release queue */ + spin_unlock(&dev->queue_lock); + + if (likely(!netif_queue_stopped(dev))) { + int ret; + if (netdev_nit) + dev_queue_xmit_nit(skb, dev); + + ret = dev->hard_start_xmit(skb, dev); + if (likely(ret == NETDEV_TX_OK)) { + if (need_lock) { + dev->xmit_lock_owner = -1; + spin_unlock(&dev->xmit_lock); + } + spin_lock(&dev->queue_lock); + return NETDEV_TX_OK; + } + if (ret == NETDEV_TX_LOCKED && !need_lock) { + spin_lock(&dev->queue_lock); + goto collision; + } + + } + + /* NETDEV_TX_BUSY - we need to requeue */ + /* Release the driver */ + if (need_lock) { + dev->xmit_lock_owner = -1; + spin_unlock(&dev->xmit_lock); + } + spin_lock(&dev->queue_lock); + return NETDEV_TX_BUSY; + + collision: + /* So, someone grabbed the driver. */ + + /* It may be transient configuration error, + when hard_start_xmit() recurses. We detect + it by checking xmit owner and drop the + packet when deadloop is detected. + */ + if (dev->xmit_lock_owner == smp_processor_id()) { + kfree_skb(skb); + if (net_ratelimit()) + printk(KERN_DEBUG "Dead loop on netdevice %s, fix it urgently!\n", dev->name); + return NETDEV_TX_OK; + } + + __get_cpu_var(netdev_rx_stat).cpu_collision++; + return NETDEV_TX_BUSY; +} /* Kick device. Note, that this procedure can be called by a watchdog timer, so that @@ -96,91 +167,19 @@ int qdisc_restart(struct net_device *dev struct sk_buff *skb; /* Dequeue packet */ - if ((skb = q->dequeue(q)) != NULL) { - unsigned nolock = (dev->features & NETIF_F_LLTX); - /* - * When the driver has LLTX set it does its own locking - * in start_xmit. No need to add additional overhead by - * locking again. These checks are worth it because - * even uncongested locks can be quite expensive. - * The driver can do trylock like here too, in case - * of lock congestion it should return -1 and the packet - * will be requeued. - */ - if (!nolock) { - if (!spin_trylock(&dev->xmit_lock)) { - collision: - /* So, someone grabbed the driver. */ - - /* It may be transient configuration error, - when hard_start_xmit() recurses. We detect - it by checking xmit owner and drop the - packet when deadloop is detected. - */ - if (dev->xmit_lock_owner == smp_processor_id()) { - kfree_skb(skb); - if (net_ratelimit()) - printk(KERN_DEBUG "Dead loop on netdevice %s, fix it urgently!\n", dev->name); - return -1; - } - __get_cpu_var(netdev_rx_stat).cpu_collision++; - goto requeue; - } - /* Remember that the driver is grabbed by us. */ - dev->xmit_lock_owner = smp_processor_id(); - } - - { - /* And release queue */ - spin_unlock(&dev->queue_lock); - - if (!netif_queue_stopped(dev)) { - int ret; - if (netdev_nit) - dev_queue_xmit_nit(skb, dev); - - ret = dev->hard_start_xmit(skb, dev); - if (ret == NETDEV_TX_OK) { - if (!nolock) { - dev->xmit_lock_owner = -1; - spin_unlock(&dev->xmit_lock); - } - spin_lock(&dev->queue_lock); - return -1; - } - if (ret == NETDEV_TX_LOCKED && nolock) { - spin_lock(&dev->queue_lock); - goto collision; - } - } - - /* NETDEV_TX_BUSY - we need to requeue */ - /* Release the driver */ - if (!nolock) { - dev->xmit_lock_owner = -1; - spin_unlock(&dev->xmit_lock); - } - spin_lock(&dev->queue_lock); - q = dev->qdisc; - } - - /* Device kicked us out :( - This is possible in three cases: - - 0. driver is locked - 1. fastroute is enabled - 2. device cannot determine busy state - before start of transmission (f.e. dialout) - 3. device is buggy (ppp) - */ + skb = q->dequeue(q); + if (likely(skb)) { + if (likely(qdisc_xmit(dev, skb) == NETDEV_TX_OK)) + return -1; -requeue: + q = dev->qdisc; q->ops->requeue(skb, q); netif_schedule(dev); return 1; + } else { + BUG_ON((int) q->q.qlen < 0); + return q->q.qlen; } - BUG_ON((int) q->q.qlen < 0); - return q->q.qlen; } static void dev_watchdog(unsigned long arg) @@ -604,6 +603,7 @@ EXPORT_SYMBOL(noop_qdisc); EXPORT_SYMBOL(noop_qdisc_ops); EXPORT_SYMBOL(qdisc_create_dflt); EXPORT_SYMBOL(qdisc_destroy); +EXPORT_SYMBOL(qdisc_xmit); EXPORT_SYMBOL(qdisc_reset); EXPORT_SYMBOL(qdisc_restart); EXPORT_SYMBOL(qdisc_lock_tree); From greearb@candelatech.com Wed May 4 10:10:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 10:10:22 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44HA97J014741 for ; Wed, 4 May 2005 10:10:09 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j44HdkGf030571 for ; Wed, 4 May 2005 10:39:46 -0700 Message-ID: <427901E0.6010502@candelatech.com> Date: Wed, 04 May 2005 10:09:52 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: IPv6 messes up VLAN device references. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev I am seeing lots of reports of being unable to remove vlan interfaces, and so far the problem is always resolved when IPv6 is disabled completely. You can find the bug report here in my vlan bug tracker if you want the details. http://grok.yi.org/~greear/bugzilla/show_bug.cgi?id=190 Is there a better place than netdev to submit bugs to the IPv6 people? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From davem@davemloft.net Wed May 4 11:08:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 11:08:58 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44I8s7J017261 for ; Wed, 4 May 2005 11:08:55 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTO7d-00036d-00; Wed, 04 May 2005 10:57:21 -0700 Date: Wed, 4 May 2005 10:57:21 -0700 From: "David S. Miller" To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: IPv6 messes up VLAN device references. Message-Id: <20050504105721.2b5a9301.davem@davemloft.net> In-Reply-To: <427901E0.6010502@candelatech.com> References: <427901E0.6010502@candelatech.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 04 May 2005 10:09:52 -0700 Ben Greear wrote: > Is there a better place than netdev to submit bugs to the IPv6 > people? netdev is the best place for all networking bug reports. From ak@muc.de Wed May 4 11:30:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 11:30:24 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44IUK7J019564 for ; Wed, 4 May 2005 11:30:21 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 2F044D033E; Wed, 4 May 2005 20:30:00 +0200 (CEST) To: "David S. Miller" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> From: Andi Kleen Date: Wed, 04 May 2005 20:30:00 +0200 In-Reply-To: <20050502200251.38271b61.davem@davemloft.net> (David S. Miller's message of "Mon, 2 May 2005 20:02:51 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 917 Lines: 23 "David S. Miller" writes: > > This usually means that there is some DMA corruption. > For example, some bug in the x86_64 IOMMU code or similar > causes a bogus DMA address to be fed to the tg3 or even > worse a DMA mapping is unmapped before tg3 is actually > done with it. IOMMU code on x86-64 should be never active unless Stephen used IOMMU_DEBUG or iommu=force. THat is because the tg3 is a 64bit capable device and should always use bypass. > Since AMD promised me an Opteron system last year, but never > made good on that promise, I've never been able to work on > fixing this bug myself. :-/ You could just buy one ,-) Lowend A64s boards+cpus are *really* cheap these days. And it will likely be much quieter than a noisy original AMD box. And the IOMMU works on that too if you force it (normally it is never active because they dont have enough memory to need remapping) -Andi From ak@muc.de Wed May 4 11:39:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 11:39:33 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44IdQ7J020300 for ; Wed, 4 May 2005 11:39:27 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 68176D033E; Wed, 4 May 2005 20:39:10 +0200 (CEST) To: Robert Olsson Cc: Jens.Laas@data.slu.se, netdev@oss.sgi.com Subject: Re: (diet-)FIB alternative fib_hlist.c References: <17016.62444.34282.625407@robur.slu.se> From: Andi Kleen Date: Wed, 04 May 2005 20:39:10 +0200 In-Reply-To: <17016.62444.34282.625407@robur.slu.se> (Robert Olsson's message of "Wed, 4 May 2005 18:10:20 +0200") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 2093 Lines: 50 Robert Olsson writes: > Hello! > > fib_hlist is the smallest and simpliest routing algo we could think of > it's just a sorted (h)list. > > routing (FIB lookup) performance. dst hash is not used. > > fib_hlist fib_hash test routing table size > ----------------------------------------------------- > 444 kpps 433 kpps Single flow. local=19/main=5 entries > 433 kpps 431 kpps rDoS. local=19/main=5 > 0.2 kpps 198 kpps rDoS local=19/main=123946 > > As seen fib_hlist is catastrophe for large routing tables as expected but > performs surprisingly well for ordinary routing tables so it should be > fine for most hosts and servers. The patch has config option to select FIB. > > Probably we soon want to specify differnt lookup schemes for different > tables say for local table fib_hash or fib_hlist. While for large main table > fib_hash2/fib_trie would be better option. Great patch! I wanted to do something like this for a long time :/ It is a good solution for 99.999% of all users who never have more than a few routes. Random comments while reading the code: I would perhaps add a printk that warns the user if there are more than 10 routes or so to use a different FIB. Also I would try to replace the write locks with normal spinlocks. read/write locks should not be needed for the use case of a normal client who basically never changes the routing table, and normal spinlocks are more friendly to modern cache coherency protocols. With only a few routes it is overkill to have two kmem caches, which both need at least a page each. With 10-20 routes you waste half the memory because of that. Better use a single slab cache for both object types or just kmalloc. Now we only need support for loadable fibs, then distributions could use this too. Loadable ones should be pretty easy, as long as you dont try to make them unloadable. The later would need a lot of reference counting in fast paths, which would be probably a bad idea. And losing that capability is not a big issue. -Andi From peter@pantasys.com Wed May 4 11:45:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 11:45:10 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44Ij77J020990 for ; Wed, 4 May 2005 11:45:07 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 May 2005 11:44:07 -0700 Message-ID: <42791825.2080204@pantasys.com> Date: Wed, 04 May 2005 11:44:53 -0700 From: Peter Buckingham User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2005 18:44:07.0484 (UTC) FILETIME=[40C70FC0:01C550D9] X-archive-position: 709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Content-Length: 669 Lines: 19 Andi Kleen wrote: > "David S. Miller" writes: > >>This usually means that there is some DMA corruption. >>For example, some bug in the x86_64 IOMMU code or similar >>causes a bogus DMA address to be fed to the tg3 or even >>worse a DMA mapping is unmapped before tg3 is actually >>done with it. > > > IOMMU code on x86-64 should be never active unless Stephen > used IOMMU_DEBUG or iommu=force. THat is because the tg3 > is a 64bit capable device and should always use bypass. how is this detected? we have a board that is using a 32bit e1000 and we have to use iommu=force otherwise it doesn't do the right thing with > 4GB of RAM. peter From hch@lst.de Wed May 4 12:28:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 12:28:12 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44JS77J026624 for ; Wed, 4 May 2005 12:28:08 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j44JRf6t021427 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 4 May 2005 21:27:41 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j44JRehW021425; Wed, 4 May 2005 21:27:40 +0200 Date: Wed, 4 May 2005 21:27:40 +0200 From: Christoph Hellwig To: acme@conectiva.com.br Cc: netdev@oss.sgi.com Subject: [PATCH] add alloc_ltalkdev Message-ID: <20050504192740.GA21409@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 3164 Lines: 91 this matches the API used by other link layer like ethernet or token ring. Signed-off-by: Christoph Hellwig Index: drivers/net/appletalk/cops.c =================================================================== --- 2aa9e4732d7014dcda4c0e80d2e377f52e2262e9/drivers/net/appletalk/cops.c (mode:100644 sha1:2161c2d585f0869e57ebfe101a49686f5ea36b4b) +++ uncommitted/drivers/net/appletalk/cops.c (mode:100644) @@ -65,7 +65,7 @@ #include #include #include -#include /* For ltalk_setup() */ +#include #include /* For udelay() */ #include #include @@ -223,7 +223,7 @@ int base_addr; int err = 0; - dev = alloc_netdev(sizeof(struct cops_local), "lt%d", ltalk_setup); + dev = alloc_ltalkdev(sizeof(struct cops_local)); if (!dev) return ERR_PTR(-ENOMEM); Index: drivers/net/appletalk/ltpc.c =================================================================== --- 2aa9e4732d7014dcda4c0e80d2e377f52e2262e9/drivers/net/appletalk/ltpc.c (mode:100644 sha1:ad8e943231a1c3a93cb769fb3d1fad23baa40ac6) +++ uncommitted/drivers/net/appletalk/ltpc.c (mode:100644) @@ -1039,7 +1039,7 @@ unsigned long f; unsigned long timeout; - dev = alloc_netdev(sizeof(struct ltpc_private), "lt%d", ltalk_setup); + dev = alloc_ltalkdev(sizeof(struct ltpc_private)); if (!dev) goto out; Index: include/linux/if_ltalk.h =================================================================== --- 2aa9e4732d7014dcda4c0e80d2e377f52e2262e9/include/linux/if_ltalk.h (mode:100644 sha1:e75e832b7ff0dd56d79bb07029a89a16c067afa2) +++ uncommitted/include/linux/if_ltalk.h (mode:100644) @@ -6,7 +6,7 @@ #define LTALK_ALEN 1 #ifdef __KERNEL__ -extern void ltalk_setup(struct net_device *); +extern struct net_device *alloc_ltalkdev(int sizeof_priv); #endif #endif Index: net/appletalk/dev.c =================================================================== --- 2aa9e4732d7014dcda4c0e80d2e377f52e2262e9/net/appletalk/dev.c (mode:100644 sha1:76598445d84b1591279ea3467b68ebe119bb3684) +++ uncommitted/net/appletalk/dev.c (mode:100644) @@ -19,7 +19,7 @@ return -EINVAL; } -void ltalk_setup(struct net_device *dev) +static void ltalk_setup(struct net_device *dev) { /* Fill in the fields of the device structure with localtalk-generic values. */ @@ -40,4 +40,22 @@ dev->flags = IFF_BROADCAST|IFF_MULTICAST|IFF_NOARP; } -EXPORT_SYMBOL(ltalk_setup); + +/** + * alloc_ltalkdev - Allocates and sets up an localtalk device + * @sizeof_priv: Size of additional driver-private structure to be allocated + * for this localtalk device + * + * Fill in the fields of the device structure with localtalk-generic + * values. Basically does everything except registering the device. + * + * Constructs a new net device, complete with a private data area of + * size @sizeof_priv. A 32-byte (not bit) alignment is enforced for + * this private data area. + */ + +struct net_device *alloc_ltalkdev(int sizeof_priv) +{ + return alloc_netdev(sizeof_priv, "lt%d", ltalk_setup); +} +EXPORT_SYMBOL(alloc_ltalkdev); From shemminger@osdl.org Wed May 4 12:42:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 12:42:22 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44JgF7J027662 for ; Wed, 4 May 2005 12:42:16 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j44JfbU3026753 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 4 May 2005 12:41:37 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j44JfaTn010748; Wed, 4 May 2005 12:41:36 -0700 Date: Wed, 4 May 2005 12:41:36 -0700 From: Stephen Hemminger To: Andi Kleen Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050504124136.7f93e4fb@dxpl.pdx.osdl.net> In-Reply-To: References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 04 May 2005 20:30:00 +0200 Andi Kleen wrote: > "David S. Miller" writes: > > > > This usually means that there is some DMA corruption. > > For example, some bug in the x86_64 IOMMU code or similar > > causes a bogus DMA address to be fed to the tg3 or even > > worse a DMA mapping is unmapped before tg3 is actually > > done with it. > > IOMMU code on x86-64 should be never active unless Stephen > used IOMMU_DEBUG or iommu=force. THat is because the tg3 > is a 64bit capable device and should always use bypass. > > > Since AMD promised me an Opteron system last year, but never > > made good on that promise, I've never been able to work on > > fixing this bug myself. :-/ > > You could just buy one ,-) Lowend A64s boards+cpus are *really* cheap > these days. And it will likely be much quieter than a noisy > original AMD box. And the IOMMU works on that too if you force > it (normally it is never active because they dont have enough > memory to need remapping) > > -Andi FYI the config of the system: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc3 # Mon May 2 13:31:20 2005 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-netem" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_PREEMPT is not set # CONFIG_SCHED_SMT is not set # CONFIG_K8_NUMA is not set # CONFIG_NUMA_EMU is not set # CONFIG_NUMA is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_NR_CPUS=8 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GART_IOMMU=y CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_SECCOMP=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_ACPI_CONTAINER is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_UNORDERED_IO is not set CONFIG_PCIEPORTBUS=y CONFIG_PCI_MSI=y # CONFIG_PCI_LEGACY_PROC is not set # CONFIG_PCI_NAMES is not set # CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_UID16=y # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=128000 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_LBD is not set # CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_ATA_OVER_ETH is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=y CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPNP=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_OFFBOARD=y CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_IDEDMA_ONLYDISK=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI Transport Attributes # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m # CONFIG_SCSI_ISCSI_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=5000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y # CONFIG_SCSI_AIC7XXX_OLD is not set CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_ENABLE_RD_STRM is not set # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 CONFIG_AIC79XX_REG_PRETTY_PRINT=y # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_AHCI is not set # CONFIG_SCSI_SATA_SVW is not set # CONFIG_SCSI_ATA_PIIX is not set # CONFIG_SCSI_SATA_NV is not set # CONFIG_SCSI_SATA_PROMISE is not set # CONFIG_SCSI_SATA_QSTOR is not set # CONFIG_SCSI_SATA_SX4 is not set CONFIG_SCSI_SATA_SIL=y # CONFIG_SCSI_SATA_SIS is not set # CONFIG_SCSI_SATA_ULI is not set # CONFIG_SCSI_SATA_VIA is not set # CONFIG_SCSI_SATA_VITESSE is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set CONFIG_SCSI_EATA=m CONFIG_SCSI_EATA_TAGGED_QUEUE=y CONFIG_SCSI_EATA_LINKED_COMMANDS=y CONFIG_SCSI_EATA_MAX_TAGS=16 # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_DEBUG is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y # CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=y # CONFIG_IP_TCPDIAG_IPV6 is not set CONFIG_IPV6=m # CONFIG_IPV6_PRIVACY is not set CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m # CONFIG_IPV6_TUNNEL is not set # CONFIG_NETFILTER is not set CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y # CONFIG_NET_SCH_CLK_JIFFIES is not set # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set CONFIG_NET_SCH_CLK_CPU=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_NET_CLS_IND=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_PEDIT=m # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_NETDEVICES=y CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=y # CONFIG_NET_SB1000 is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set CONFIG_B44=m # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_R8169=m CONFIG_R8169_NAPI=y # CONFIG_R8169_VLAN is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set CONFIG_TIGON3=m # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y # CONFIG_SERIAL_8250_MULTIPORT is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=m CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=m # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set # # TPM devices # # CONFIG_TCG_TPM is not set # # I2C support # CONFIG_I2C=m # CONFIG_I2C_CHARDEV is not set # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # CONFIG_I2C_ALI1535=m # CONFIG_I2C_ALI1563 is not set CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m # CONFIG_I2C_AMD756_S4882 is not set CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m CONFIG_I2C_I810=m # CONFIG_I2C_PIIX4 is not set CONFIG_I2C_ISA=m CONFIG_I2C_NFORCE2=m CONFIG_I2C_PARPORT_LIGHT=m CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m CONFIG_SCx200_ACB=m CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m # CONFIG_I2C_STUB is not set CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m CONFIG_I2C_VOODOO3=m # CONFIG_I2C_PCA_ISA is not set # # Hardware Sensors Chip support # # CONFIG_I2C_SENSOR is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # # Other I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_RTC8564 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # # CONFIG_VIDEO_BT848 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5246A is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_OVCAMCHIP is not set # # Radio Adapters # # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SOFT_CURSOR=y # CONFIG_FB_MACMODES is not set CONFIG_FB_MODE_HELPERS=y # CONFIG_FB_TILEBLITTING is not set # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON_OLD is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # # CONFIG_LOGO is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # PCI devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_HDA_INTEL is not set # # USB devices # CONFIG_SND_USB_AUDIO=m # CONFIG_SND_USB_USX2Y is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Input Devices # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y CONFIG_HID_FF=y CONFIG_HID_PID=y CONFIG_LOGITECH_FF=y CONFIG_THRUSTMASTER_FF=y CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_SN9C102 is not set # CONFIG_USB_STV680 is not set # CONFIG_USB_PWC is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set CONFIG_USB_MON=m # # USB port drivers # # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_CP2101 is not set # CONFIG_USB_SERIAL_CYPRESS_M8 is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_GARMIN is not set # CONFIG_USB_SERIAL_IPW is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_TI is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETKIT is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_TEST is not set # # USB ATM/DSL drivers # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # # CONFIG_MMC is not set # # InfiniBand support # # CONFIG_INFINIBAND is not set # # Firmware Drivers # # CONFIG_EDD is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=y CONFIG_JBD_DEBUG=y CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # # XFS support # # CONFIG_XFS_FS is not set # CONFIG_MINIX_FS is not set CONFIG_ROMFS_FS=m # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y # CONFIG_TMPFS_XATTR is not set CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y # CONFIG_ROOT_NFS is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=y # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=m # # Kernel hacking # # CONFIG_PRINTK_TIME is not set CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_SCHEDSTATS=y # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_INFO=y CONFIG_DEBUG_FS=y # CONFIG_INIT_DEBUG is not set # CONFIG_IOMMU_DEBUG is not set CONFIG_KPROBES=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m # CONFIG_CRYPTO_WP512 is not set # CONFIG_CRYPTO_TGR192 is not set CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_ARC4=m # CONFIG_CRYPTO_KHAZAD is not set CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m # CONFIG_CRYPTO_CRC32C is not set CONFIG_CRYPTO_TEST=m # # Hardware crypto devices # # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=y # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m From Robert.Olsson@data.slu.se Wed May 4 13:10:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 13:10:53 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44KAn7J002332 for ; Wed, 4 May 2005 13:10:49 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j44KAVJw026755; Wed, 4 May 2005 22:10:32 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id DA7EAEE1E9; Wed, 4 May 2005 22:10:31 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17017.11319.855946.521718@robur.slu.se> Date: Wed, 4 May 2005 22:10:31 +0200 To: Andi Kleen Cc: Robert Olsson , Jens.Laas@data.slu.se, netdev@oss.sgi.com Subject: Re: (diet-)FIB alternative fib_hlist.c In-Reply-To: References: <17016.62444.34282.625407@robur.slu.se> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-archive-position: 712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Andi Kleen writes: > Great patch! I wanted to do something like this for a long time :/ > It is a good solution for 99.999% of all users who never have more > than a few routes. > > Random comments while reading the code: > > I would perhaps add a printk that warns the user if there are > more than 10 routes or so to use a different FIB. When we find the break-even point we can a print warning at insertions above this point. A minor problem. > Also I would try to replace the write locks with normal spinlocks. > read/write locks should not be needed for the use case of a normal > client who basically never changes the routing table, and normal > spinlocks are more friendly to modern cache coherency protocols. Interesting. I'll guess this goes for all FIB variants. Needs some experimentation. > With only a few routes it is overkill to have two kmem caches, > which both need at least a page each. With 10-20 routes you > waste half the memory because of that. Better use a single > slab cache for both object types or just kmalloc. Doable. slab objects are nice & easy to monitor during development. > Now we only need support for loadable fibs, then > distributions could use this too. Loadable ones should > be pretty easy, as long as you dont try to make them unloadable. First step yes. Also we need hi-pref system to have multiple FIB variants. Just attack it if got some ideas. > The later would need a lot of reference counting in fast paths, > which would be probably a bad idea. And losing that capability > is not a big issue. Yes leave that out for now. Cheers. --ro From arnaldo.melo@gmail.com Wed May 4 13:49:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 13:49:21 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44KnH7J004956 for ; Wed, 4 May 2005 13:49:18 -0700 Received: by zproxy.gmail.com with SMTP id 8so339322nzo for ; Wed, 04 May 2005 13:49:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bdL/kHmXmVcfX7g7HRqHX8prPr92NFyJITKNX8TfpfF87oPBTIr5HznyZB4ekF6+Z2lm0NBeJY2DsHGaa5sTrdmo0FVrIFvuE5MMYa8YNAMNRnrQJCZPKiOSSZPDoyu1Nc4bf2lfzn0rMECEg8aP/iZv2qC/qOplXtNoecbjKeg= Received: by 10.36.80.18 with SMTP id d18mr204907nzb; Wed, 04 May 2005 13:49:03 -0700 (PDT) Received: by 10.36.56.15 with HTTP; Wed, 4 May 2005 13:49:03 -0700 (PDT) Message-ID: <39e6f6c70505041349f98590f@mail.gmail.com> Date: Wed, 4 May 2005 17:49:03 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@ghostprotocols.net To: Christoph Hellwig Subject: Re: [PATCH] add alloc_ltalkdev Cc: acme@conectiva.com.br, netdev@oss.sgi.com In-Reply-To: <20050504192740.GA21409@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050504192740.GA21409@lst.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j44KnH7J004956 X-archive-position: 713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On 5/4/05, Christoph Hellwig wrote: > this matches the API used by other link layer like ethernet or token > ring. > > Signed-off-by: Christoph Hellwig > > Index: drivers/net/appletalk/cops.c Acked-by: Arnaldo Carvalho de Melo From alexn@dsv.su.se Wed May 4 14:35:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 14:35:59 -0700 (PDT) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44LZj7J006832 for ; Wed, 4 May 2005 14:35:53 -0700 X-T2-Posting-ID: jLUmkBjoqvly7NM6d2gdCg== Received: from c213-100-52-74.swipnet.se ([213.100.52.74] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 4.3c5) with ESMTP id 160067507; Wed, 04 May 2005 23:35:30 +0200 Subject: Re: strange 3c59x behaviour under 2.6.11.7 From: Alexander Nyberg To: Jim Faulkner Cc: vortex@scyld.com, Bogdan.Costescu@iwr.uni-heidelberg.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Date: Wed, 04 May 2005 23:35:11 +0200 Message-Id: <1115242511.2562.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-archive-position: 714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alexn@dsv.su.se Precedence: bulk X-list: netdev > Some background for the linux-kernel folks: > > http://www.scyld.com/pipermail/vortex/2005-May/002483.html > > http://www.scyld.com/pipermail/vortex/2005-May/002484.html > > On Tue, 3 May 2005, Bogdan Costescu wrote: > > > > Any ideas on what is causing this problem, and how to fix it? > > > > Try booting with acpi=off. > > Try updating BIOS and/or modify power related options in BIOS. > > I've tried disabling ACPI in the kernel, turning on APM support in the > BIOS, and the combination of the two, and unfortunately the problem > persisted. > > However, I found this patch (the one at the very bottom of the page): > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg78894.html > > And after adapting it to the 2.6.11.7 kernel, everything works again! > I've rebooted the machine several times, and the 3com cards initialized > successfully every time. > > I'm CC'ing linux-kernel in the hopes that this fix can make it into the > mainstream kernel sometime soon. I'm sure my mother would appreciate it > greatly. :) > > Please CC my e-mail address in any replies as I am not subscribed to this > list. [netdev needs to be up on the CC on this too] Yeah I get the same behaviour reliably when doing kexec on a box with the 3c59x, lspci shows: 0000:00:0f.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74) Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- ; Wed, 4 May 2005 15:33:28 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j44MXCU3008614 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 4 May 2005 15:33:12 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j44MXBrx020479; Wed, 4 May 2005 15:33:12 -0700 Date: Wed, 4 May 2005 15:33:11 -0700 From: Stephen Hemminger To: Stefaan De Roeck , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] tlan: restore deleted module parameters. Message-ID: <20050504153311.7d1a0fe9@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The module parameter values got lost in the conversion to the new module_param interface. This should fix it. Signed-off-by: Stephen Hemminger Index: tlan/drivers/net/tlan.c =================================================================== --- tlan.orig/drivers/net/tlan.c +++ tlan/drivers/net/tlan.c @@ -193,6 +193,12 @@ static int aui[MAX_TLAN_BOARDS]; static int duplex[MAX_TLAN_BOARDS]; static int speed[MAX_TLAN_BOARDS]; static int boards_found; +module_param_array(aui, int, NULL, 0); +module_param_array(duplex, int, NULL, 0); +module_param_array(speed, int, NULL, 0); +MODULE_PARM_DESC(aui, "ThunderLAN use AUI port(s) (0-1)"); +MODULE_PARM_DESC(duplex, "ThunderLAN duplex setting(s) (0-default, 1-half, 2-full)"); +MODULE_PARM_DESC(speed, "ThunderLAN port speen setting(s) (0,10,100)"); MODULE_AUTHOR("Maintainer: Samuel Chessman "); MODULE_DESCRIPTION("Driver for TI ThunderLAN based ethernet PCI adapters"); @@ -204,8 +210,13 @@ MODULE_LICENSE("GPL"); /* Turn on debugging. See Documentation/networking/tlan.txt for details */ static int debug; +module_param(debug, int, 0); +MODULE_PARM_DESC(debug, "ThunderLAN debug mask"); static int bbuf; +module_param(bbuf, int, 0); +MODULE_PARM_DESC(bbuf, "ThunderLAN use big buffer (0-1)"); + static u8 *TLanPadBuffer; static dma_addr_t TLanPadBufferDMA; static char TLanSignature[] = "TLAN"; From shemminger@osdl.org Wed May 4 15:52:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 15:52:12 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44Mq47J012530 for ; Wed, 4 May 2005 15:52:04 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j44MpiU3009990 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 4 May 2005 15:51:45 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j44MphJc021331; Wed, 4 May 2005 15:51:43 -0700 Date: Wed, 4 May 2005 15:51:43 -0700 From: Stephen Hemminger To: "Michael Chan" Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050504155143.1a78cb7a@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 3 May 2005 23:27:38 -0700 "Michael Chan" wrote: > Stephen Hemminger wrote: > > > Initially, it reproduced everytime link came up, we > > reconfigured the VLAN to > > have a mirror port into a laptop to try and capture what was > > happening, but when > > we did that the bootup problem went away. It was in the tg3_reset_hw > > during initial dev_open. > > > > During initial dev_open, the TG3_FLAG_INIT_COMPLETE flag is not set so > tg3_reset_hw() should not call tg3_abort_hw() where the stop_block calls are > made. So there should be no stop_block errors. > > I think stop_block errors can only happen during dev_close, suspend, netdev > watchdog, or ethtool "set" calls. It seems that dhclient was failing on bootup then taking the device down. When the device down happened it got the tg3_stop_block from Call Trace:{:tg3:tg3_stop_block+185} {:tg3:tg3_abort_hw+605} {:tg3:tg3_halt+40} {:tg3:tg3_close+71} {dev_close+100} {dev_change_flags+104} {devinet_ioctl+773} {inet_ioctl+92} {sock_ioctl+556} {do_ioctl+58} {vfs_ioctl+715} {sys_ioctl+77} {system_call+126} From mchan@broadcom.com Wed May 4 16:28:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 16:29:02 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44NSw7J017713 for ; Wed, 4 May 2005 16:28:58 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Wed, 04 May 2005 16:28:33 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 4 May 2005 16:28:24 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWL10635; Wed, 4 May 2005 16:28:20 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id QAA22478; Wed, 4 May 2005 16:28:19 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 May 2005 23:28:19 +0000 Received: from rh4 by nt-irva-0741; 04 May 2005 15:30:22 -0700 Subject: Re: Mystery packet killing tg3 From: "Michael Chan" To: "Stephen Hemminger" cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050504155143.1a78cb7a@dxpl.pdx.osdl.net> References: <20050504155143.1a78cb7a@dxpl.pdx.osdl.net> Date: Wed, 04 May 2005 15:30:22 -0700 Message-ID: <1115245822.15156.78.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E67852B21S2002357-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev On Wed, 2005-05-04 at 15:51 -0700, Stephen Hemminger wrote: > On Tue, 3 May 2005 23:27:38 -0700 > "Michael Chan" wrote: > > > I think stop_block errors can only happen during dev_close, suspend, netdev > > watchdog, or ethtool "set" calls. > > It seems that dhclient was failing on bootup then taking the device down. > When the device down happened it got the tg3_stop_block from > Call Trace:{:tg3:tg3_stop_block+185} {:tg3:tg3_abort_hw+605} > {:tg3:tg3_halt+40} {:tg3:tg3_close+71} > {dev_close+100} {dev_change_flags+104} > {devinet_ioctl+773} {inet_ioctl+92} > {sock_ioctl+556} {do_ioctl+58} > {vfs_ioctl+715} {sys_ioctl+77} > {system_call+126} > This makes sense. Before the dhclient closes the device, was the device functioning properly? If not, was it not sending or not receiving? If the device was functioning properly prior to the close, meaning that the dhclient was closing because there was no response from the dhcp server, then the stop_block error was inconsequential. From tgraf@suug.ch Wed May 4 16:40:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 16:40:35 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44NeT7J018667 for ; Wed, 4 May 2005 16:40:30 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id A8F3B1C0EB; Thu, 5 May 2005 01:40:36 +0200 (CEST) Date: Thu, 5 May 2005 01:40:36 +0200 From: Thomas Graf To: netdev@oss.sgi.com Cc: Pablo Neira Subject: [RFC] textsearch infrastructure + skb_find_text() Message-ID: <20050504234036.GH18452@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev The patch below is a report on the current state of the textsearch infrastructure and its first user skb_find_text(). The textsearch is kept as simple as possible but advanced enough to handle non-linear data such as skb fragments. Unlike in many other approaches the text input is not seen as a single pointer but rather as a continuously called callback get_text() until 0 is returned allowing to search on any kind of data and to implement customized from-to limits. The patch is separated into 3 parts, the first one being the textsearch infrastructure itself followed by a simple Knuth-Morris-Pratt implementation for reference. I'm also working on what could be called the smallest regular expression implementation ever but I left that out for now since it still has issues. Last but not least the function skb_find_text() written in a hurry and probably not yet correct but you should get the idea. From a userspace perspective the first user will be an ematch but writing it will be peanuts so I left it out for now. Basically what it looks like right now is: int pos; struct ts_state; struct ts_config *conf = textsearch_prepare("kmp", "hanky", 5, GFP_KERNEL, 1); /* search for "hanky" at offset 20 until end of packet */ for (pos = skb_find_text(skb, 20, INT_MAX, conf, &state; pos >= 0; pos = textsearch_next(conf, &state)) { printk("Need a hanky? I found one at offset %d.\n", pos); } textsearch_put(conf); kfree(conf); You might wonder about the 1 given to _prepare(), it indicates whether to autoload modules because the ematches will need it to be able to drop rtnl sem. The code is not tested and cerainly not bug free yet but should compile. Thoughts? diff -X dontdiff -Nru linux-2.6.12-rc3.orig/include/linux/textsearch.h linux-2.6.12-rc3/include/linux/textsearch.h --- linux-2.6.12-rc3.orig/include/linux/textsearch.h 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.12-rc3/include/linux/textsearch.h 2005-05-05 00:35:07.000000000 +0200 @@ -0,0 +1,169 @@ +#ifndef __LINUX_TEXTSEARCH_H +#define __LINUX_TEXTSEARCH_H + +#ifdef __KERNEL__ + +#include +#include +#include +#include +#include + +struct ts_config; + +/** + * struct ts_state - textsearch state + * @offset: current offset for next match + * @args: for persistant variables of get_text() + */ +struct ts_state +{ + int offset; + long args[6]; +}; + +/** + * struct ts_ops - textsearch operations + * @name: name of search algorithm + * @init: called upon initialization to prepare a search + * @find: does the actual matching on a prepared configuration + * @owner: reference to algorithm module if existent + * @list: operations list we are on + */ +struct ts_ops +{ + const char *name; + struct ts_config * (*init)(const unsigned char *, size_t, int); + int (*find)(struct ts_config *, + struct ts_state *); + struct module *owner; + struct list_head list; +}; + +/** + * struct ts_config - textsearch configuration + * @ops: textsearch operations + * @get_text: callback to fetch text to search in + * @len: length of pattern + */ +struct ts_config +{ + struct ts_ops *ops; + + /** + * get_text - return next chunk of text + * @offset: Number of bytes consumed by the matcher + * @dst: destination buffer + * @conf: search configuration + * @state: search state + * + * Gets called repeatedly until 0 is returned.Must assign a pointer + * to the start of the next chunk of text to *dst and return the + * length of the chunk or 0 if at the end. offset==0 indicates + * a new search. May store/read persistant values in state->args[]. + */ + int (*get_text)(int offset, unsigned char **dst, + struct ts_config *conf, + struct ts_state *state); + + /** + * finish - called when the matching has been completed successful + * or not. + * @conf: search configuration + * @state: search state + */ + void (*finish)(struct ts_config *conf, + struct ts_state *state); + int pattern_len; +}; + +/* Do no use this function directly */ +static inline int __textsearch_find(struct ts_config *conf, + struct ts_state *state) +{ + int ret = conf->ops->find(conf, state); + + if (conf->finish) + conf->finish(conf, state); + + return ret; +} + +/** + * textsearch_find - search for a pattern in a text + * @conf: search configuration + * @state: search state + * + * Peforms the actual search on the prepared configuration. + * + * Returns the position of first occurrence of the pattern or a + * negative number if no match was found. + */ +static inline int textsearch_find(struct ts_config *conf, + struct ts_state *state) +{ + state->offset = 0; + return __textsearch_find(conf, state); +} + +/** + * textsearch_next - continue search for a pattern in a text + * @conf: search configuration + * @state: search state + * + * Continues a search looking for more occurrences of the pattern. + * You must call textsearch_find() to search the first occurrence + * in order to reset the state. + * + * Returns the position of next occurance of the pattern or a + * negative number if no match was found. + */ +static inline int textsearch_next(struct ts_config *conf, + struct ts_state *state) +{ + state->offset += conf->pattern_len; + return __textsearch_find(conf, state); +} + +/** + * textsearch_put - give back a textsearch configuration + * @conf: search configuration + * + * Releases all references of the configuration. Must be + * called prior to freeing the object. + */ +static inline void textsearch_put(struct ts_config *conf) +{ + if (conf->ops) + module_put(conf->ops->owner); +} + +/** + * alloc_ts_config - allocate a textsearch configuration + * @payload: size of additional module specific data required + * @gfp_mask: allocation mask + * + * Returns a new, empty textsearch configuration or a ERR_PTR(). + */ +static inline struct ts_config *alloc_ts_config(size_t payload, int gfp_mask) +{ + struct ts_config *conf; + + conf = kmalloc(sizeof(*conf) + payload, gfp_mask); + if (conf == NULL) + return ERR_PTR(-ENOMEM); + + memset(conf, 0, sizeof(*conf) + payload); + return conf; +} + +extern int textsearch_register(struct ts_ops *); +extern int textsearch_unregister(struct ts_ops *); +extern struct ts_config *textsearch_prepare(const char *, const unsigned char *, + size_t, int, int); +extern int textsearch_find_continuous(struct ts_config *, struct ts_state *, + const unsigned char *, size_t); + +#endif /* __KERNEL__ */ + +#endif diff -X dontdiff -Nru linux-2.6.12-rc3.orig/lib/textsearch.c linux-2.6.12-rc3/lib/textsearch.c --- linux-2.6.12-rc3.orig/lib/textsearch.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.12-rc3/lib/textsearch.c 2005-05-04 23:01:42.000000000 +0200 @@ -0,0 +1,241 @@ +/* + * lib/textsearch.c Generic text search interface + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + * + * ========================================================================== + * + * The textsearch infrastructure provides text searching facitilies for both + * linear and non-linear data. Unlike many other + * + * Before a textsearch can be performed, a configuration must be created + * by calling textsearch_prepare() specyfing the searching algorithm and + * the pattern to match. The returned configuration may then be used for + * an arbitary amount of times and even in parallel as long as you + * provide a separate struct ts_state variable for every instance. + * + * The actual search is performed by either calling textsearch_find_text() + * for linear text or by providing an own get_text() implementation and + * calling textsearch_find(). Both functions will returns the position + * of the first matching occurrence of the patern. Subsequent matches + * may be retrived via textsearch_next() irrespective of the linearity + * of the text. + * + * Once you're done using a configuration you must give back the + * allocted resources by calling textsearch_put(). + * + * Example: + * int pos; + * struct ts_config *conf; + * struct ts_state state; + * conar char *pattern = "chicken"; + * const char *example = "We dance the funky chicken"; + * + * conf = textsearch_prepare("kmp", pattern, strlen(pattern), GFP_KERNEL, 1); + * if (IS_ERR(conf)) { + * err = PTR_ERR(conf); + * goto errout; + * } + * + * pos = textsearch_find_text(conf, &state, example, strlen(example)); + * if (pos >= 0) + * panic("Oh my god, dancing chickens at %d\n", pos); + * + * textsearch_put(conf); + * kfree(conf); + * + * ========================================================================== + */ + +#include +#include +#include +#include +#include +#include + +static LIST_HEAD(ts_ops); +static DEFINE_RWLOCK(ts_mod_lock); + +static inline struct ts_ops *lookup_ts_algo(const char *name) +{ + struct ts_ops *o; + + read_lock(&ts_mod_lock); + list_for_each_entry(o, &ts_ops, list) { + if (!strcmp(name, o->name)) { + if (!try_module_get(o->owner)) + o = NULL; + read_unlock(&ts_mod_lock); + return o; + } + } + read_unlock(&ts_mod_lock); + + return NULL; +} + +/** + * textsearch_register - register a textsearch module + * @ops: operations lookup table + * + * This function must be called by textsearch modules to announce + * their presence. The given @ops must have %name set to a unique + * identifier and the callbacks find() and init() must be implemented. + * + * Returns -EEXISTS if another module has already registered with + * same name. + */ +int textsearch_register(struct ts_ops *ops) +{ + int err = -EEXIST; + struct ts_ops *o; + + if (ops->name == NULL || ops->find == NULL || ops->init == NULL) + return -EINVAL; + + write_lock(&ts_mod_lock); + list_for_each_entry(o, &ts_ops, list) + if (!strcmp(ops->name, o->name)) + goto errout; + + list_add_tail(&ops->list, &ts_ops); + err = 0; +errout: + write_unlock(&ts_mod_lock); + return err; +} + +/** + * textsearch_unregister - unregister a textsearch module + * @ops: operations lookup table + * + * This function must be called by textsearch modules to announce + * their disappearance for examples when the module gets unloaded. + * The @ops parameter must be the same as the one during the + * registration. + * + * Returns -ENOENT if no matching textsearch registration was found. + */ +int textsearch_unregister(struct ts_ops *ops) +{ + int err = 0; + struct ts_ops *o; + + write_lock(&ts_mod_lock); + list_for_each_entry(o, &ts_ops, list) { + if (o == ops) { + list_del(&o->list); + goto out; + } + } + + err = -ENOENT; +out: + write_unlock(&ts_mod_lock); + return err; +} + +static inline int get_linear_text(int offset, unsigned char **text, + struct ts_config *conf, + struct ts_state *state) +{ + unsigned char *string = (unsigned char *) state->args[0]; + size_t len = state->args[1]; + + if (offset < len) { + *text = string + offset; + return len - offset; + } else + return 0; +} + +/** + * textsearch_find_continuous - search a pattern in continuous/linear text + * @conf: search configuration + * @state: search state + * @text: text to search in + * @len: length of text + * + * A simplified version of textsearch_find() for continuous/linear text. + * Call textsearch_next() to retrieve subsequent matches. + * + * Returns the position of first occurrence of the pattern or a + * negative number if no match was found. + */ +int textsearch_find_continuous(struct ts_config *conf, struct ts_state *state, + const unsigned char *text, size_t len) +{ + conf->get_text = get_linear_text; + state->args[0] = (long) text; + state->args[1] = len; + + return textsearch_find(conf, state); +} + +/** + * textsearch_prepare - Prepare a text search + * @algo: name of search algorithm + * @pattern: pattern data + * @len: length of pattern + * @gfp_mask: allocation mask + * @autoload: bool indicating whether to autoload modules + * + * Looks up the search algorithm module and creates a new textsearch + * configuration for the specified pattern. Upon completion all + * necessary refcnts are held and the configuration must be put back + * using textsearch_put() after usage. + * + * Note: The format of the pattern may not be compatible between + * the various search algorithms. + * + * Returns a new textsearch configuration according to the specified + * parameters or a ERR_PTR(). + */ +struct ts_config *textsearch_prepare(const char *algo, + const unsigned char *pattern, size_t len, + int gfp_mask, int autoload) +{ + int err = -ENOENT; + struct ts_config *conf; + struct ts_ops *ops; + + ops = lookup_ts_algo(algo); +#ifdef CONFIG_KMOD + /* Why not always autoload you may ask. Some users may be + * in a situation where requesting a module may deadlock, + * especially when the module is located on a NFS mount. */ + if (ops == NULL && autoload) { + request_module("ts_%s", algo); + ops = lookup_ts_algo(algo); + } +#endif + + if (ops == NULL) + goto errout; + + conf = ops->init(pattern, len, gfp_mask); + if (IS_ERR(conf)) { + err = PTR_ERR(conf); + goto errout; + } + + conf->ops = ops; + return conf; + +errout: + if (ops) + module_put(ops->owner); + + return ERR_PTR(err); +} + +EXPORT_SYMBOL(textsearch_register); +EXPORT_SYMBOL(textsearch_unregister); +EXPORT_SYMBOL(textsearch_prepare); +EXPORT_SYMBOL(textsearch_find_continuous); diff -X dontdiff -Nru linux-2.6.12-rc3.orig/lib/ts_kmp.c linux-2.6.12-rc3/lib/ts_kmp.c --- linux-2.6.12-rc3.orig/lib/ts_kmp.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.12-rc3/lib/ts_kmp.c 2005-05-05 00:32:28.000000000 +0200 @@ -0,0 +1,108 @@ +/* + * lib/ts_kmp.c Knuth-Morris-Pratt text search implementation + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include + +#define TS_KMP_PREFIX_TBL(conf) \ + ((unsigned int *) ((unsigned char *) (conf) \ + + sizeof(struct ts_config))) + +#define TS_KMP_PATTERN(conf) \ + ((unsigned char *) TS_KMP_PREFIX_TBL(conf) \ + + (conf->pattern_len * sizeof(unsigned int))) + +static int kmp_find(struct ts_config *conf, struct ts_state *state) +{ + int i, q = 0, consumed = state->offset; + unsigned char *text, *pattern = TS_KMP_PATTERN(conf); + unsigned int *prefix_tbl = TS_KMP_PREFIX_TBL(conf); + size_t text_len, pattern_len = conf->pattern_len; + + for (;;) { + text_len = conf->get_text(consumed, &text, conf, state); + + if (text_len == 0) + break; + + for (i = 0; i < text_len; i++) { + while (q > 0 && pattern[q] != text[i]) + q = prefix_tbl[q - 1]; + if (pattern[q] == text[i]) + q++; + if (q == pattern_len) { + state->offset = consumed + i - pattern_len + 1; + return state->offset; + } + } + + consumed += text_len; + } + + return -1; + +} + +static inline void compute_prefix_tbl(const unsigned char *pattern, size_t len, + unsigned int *prefix_tbl) +{ + unsigned int k, q; + + for (k = 0, q = 1; q < len; q++) { + while (k > 0 && pattern[k] != pattern[q]) + k = prefix_tbl[k-1]; + if (pattern[k] == pattern[q]) + k++; + prefix_tbl[q] = k; + } +} + +static struct ts_config *kmp_init(const unsigned char *pattern, size_t len, + int gfp_mask) +{ + struct ts_config *conf; + + conf = alloc_ts_config(len + (len * sizeof(int)), gfp_mask); + if (IS_ERR(conf)) + return conf; + + conf->pattern_len = len; + memcpy(TS_KMP_PATTERN(conf), pattern, len); + compute_prefix_tbl(pattern, len, TS_KMP_PREFIX_TBL(conf)); + + return conf; +} + +static struct ts_ops kmp_ops = { + .name = "kmp", + .find = kmp_find, + .init = kmp_init, + .owner = THIS_MODULE, + .list = LIST_HEAD_INIT(kmp_ops.list) +}; + +static int __init init_kmp(void) +{ + return textsearch_register(&kmp_ops); +} + +static void __exit exit_kmp(void) +{ + textsearch_unregister(&kmp_ops); +} + +MODULE_LICENSE("GPL"); + +module_init(init_kmp); +module_exit(exit_kmp); diff -X dontdiff -Nru linux-2.6.12-rc3.orig/net/core/skbuff.c linux-2.6.12-rc3/net/core/skbuff.c --- linux-2.6.12-rc3.orig/net/core/skbuff.c 2005-04-30 20:22:24.000000000 +0200 +++ linux-2.6.12-rc3/net/core/skbuff.c 2005-05-05 00:35:50.000000000 +0200 @@ -1502,6 +1502,80 @@ skb_split_no_header(skb, skb1, len, pos); } +static int get_skb_text(int offset, unsigned char **text, + struct ts_config *conf, struct ts_state *state) +{ + /* args[0]: lower limit + * args[1]: upper limit + * args[2]: skb + * args[3]: fragment index + * args[4]: current fragment data buffer + * args[5]: octets consumed up to previous fragment */ + int from = state->args[0], to = state->args[1]; + struct sk_buff *skb = (struct sk_buff *) state->args[2]; + int limit = min_t(int, skb_headlen(skb), to); + int real_offset = offset + from; + skb_frag_t *f; + + if (!skb_is_nonlinear(skb)) { + if (real_offset < limit) { +linear: + *text = skb->data + real_offset; + return limit - real_offset; + } + + return 0; + } + + if (real_offset < limit) + goto linear; + +next_fragment: + f = &skb_shinfo(skb)->frags[state->args[3]]; + limit = min_t(int, f->size + state->args[5], to); + + if (!state->args[4]) + state->args[4] = (long) kmap_skb_frag(f); + + if (real_offset < limit) { + *text = (unsigned char *) state->args[4] + f->page_offset + + (real_offset - (int) state->args[5]); + return limit - real_offset; + } + + kunmap_skb_frag((void *) state->args[4]); + state->args[3]++; + state->args[4] = (long) NULL; + state->args[5] += f->size; + + if (state->args[3] >= skb_shinfo(skb)->nr_frags) + return 0; + + goto next_fragment; +} + +static void get_skb_text_finish(struct ts_config *conf, struct ts_state *state) +{ + if (state->args[4]) + kunmap_skb_frag((void *) state->args[4]); +} + +int skb_find_text(struct sk_buff *skb, int from, int to, + struct ts_config *config, struct ts_state *state) +{ + config->get_text = get_skb_text; + config->finish = get_skb_text_finish; + state->args[0] = from; + state->args[1] = to; + state->args[2] = (long) skb; + state->args[3] = 0; + state->args[4] = 0; + state->args[5] = skb_headlen(skb); + + return textsearch_find(config, state); +} + + void __init skb_init(void) { skbuff_head_cache = kmem_cache_create("skbuff_head_cache", @@ -1540,3 +1614,4 @@ EXPORT_SYMBOL(skb_unlink); EXPORT_SYMBOL(skb_append); EXPORT_SYMBOL(skb_split); +EXPORT_SYMBOL(skb_find_text); diff -X dontdiff -Nru linux-2.6.12-rc3.orig/include/linux/skbuff.h linux-2.6.12-rc3/include/linux/skbuff.h --- linux-2.6.12-rc3.orig/include/linux/skbuff.h 2005-04-30 20:22:19.000000000 +0200 +++ linux-2.6.12-rc3/include/linux/skbuff.h 2005-05-05 00:12:46.000000000 +0200 @@ -28,6 +28,7 @@ #include #include #include +#include #define HAVE_ALLOC_SKB /* For the drivers to know */ #define HAVE_ALIGNABLE_SKB /* Ditto 8) */ @@ -1186,6 +1187,9 @@ extern void skb_split(struct sk_buff *skb, struct sk_buff *skb1, const u32 len); +extern int skb_find_text(struct sk_buff *skb, int from, int to, + struct ts_config *config, struct ts_state *state); + static inline void *skb_header_pointer(const struct sk_buff *skb, int offset, int len, void *buffer) { From greearb@candelatech.com Wed May 4 17:00:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 17:00:28 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4500O7J019913 for ; Wed, 4 May 2005 17:00:24 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j450U5Gf003537 for ; Wed, 4 May 2005 17:30:05 -0700 Message-ID: <42796209.7050305@candelatech.com> Date: Wed, 04 May 2005 17:00:09 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: via-rhine & rx-buffer size Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Hello! I've been doing some testing with the routerboard-44 4-port Via-Rhine NIC. When running about 10Mbps (~1kpps) of traffic in both directions on all 4 ports, I see about 1% packet drop. I tried adjusting the buffer sizes like this: #define TX_RING_SIZE 32 #define TX_QUEUE_LEN 30 /* Limit ring entries actually used. */ #define RX_RING_SIZE 64 I get slightly fewer drops (maybe, .3% or so), but I was hoping for better still. So, first: Any reason not to increase the buffers as show above? (Yes, I know the part about tx buffers & QoS, so if one wants to leave that at 16, tis fine by me). Any ideas for other tweakings that might give me better performance? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bunk@stusta.de Wed May 4 17:23:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 17:23:43 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j450NX7J021381 for ; Wed, 4 May 2005 17:23:39 -0700 Received: (qmail 14171 invoked from network); 5 May 2005 00:23:12 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 5 May 2005 00:23:12 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 7F2EDAF98F; Thu, 5 May 2005 02:23:11 +0200 (CEST) Date: Thu, 5 May 2005 02:23:10 +0200 From: Adrian Bunk To: marcel@holtmann.or.sgi.com, maxk@qualcomm.com Cc: bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/bluetooth/: possible cleanups Message-ID: <20050505002310.GF3593@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev This patch contains the following possible cleanups: - #ifdef HCI_DATA_DUMP the following function: lib.c: bt_dump - #if 0 the following unused global functions: - hci_core.c: hci_suspend_dev - hci_core.c: hci_resume_dev - remove the following unneeded EXPORT_SYMBOL's: - hci_core.c: hci_dev_get - hci_core.c: hci_send_cmd - hci_event.c: hci_si_event Please review which of these changes do make sense and which conflict with pending patches. Signed-off-by: Adrian Bunk --- include/net/bluetooth/hci_core.h | 2 -- net/bluetooth/hci_core.c | 6 ++++-- net/bluetooth/hci_event.c | 1 - net/bluetooth/lib.c | 2 ++ 4 files changed, 6 insertions(+), 5 deletions(-) --- linux-2.6.12-rc3-mm2-full/include/net/bluetooth/hci_core.h.old 2005-05-03 10:38:41.000000000 +0200 +++ linux-2.6.12-rc3-mm2-full/include/net/bluetooth/hci_core.h 2005-05-03 10:38:49.000000000 +0200 @@ -375,8 +375,6 @@ void hci_free_dev(struct hci_dev *hdev); int hci_register_dev(struct hci_dev *hdev); int hci_unregister_dev(struct hci_dev *hdev); -int hci_suspend_dev(struct hci_dev *hdev); -int hci_resume_dev(struct hci_dev *hdev); int hci_dev_open(__u16 dev); int hci_dev_close(__u16 dev); int hci_dev_reset(__u16 dev); --- linux-2.6.12-rc3-mm2-full/net/bluetooth/hci_core.c.old 2005-05-03 10:38:58.000000000 +0200 +++ linux-2.6.12-rc3-mm2-full/net/bluetooth/hci_core.c 2005-05-03 10:47:49.000000000 +0200 @@ -299,7 +299,6 @@ read_unlock(&hci_dev_list_lock); return hdev; } -EXPORT_SYMBOL(hci_dev_get); /* ---- Inquiry support ---- */ static void inquiry_cache_flush(struct hci_dev *hdev) @@ -899,6 +898,8 @@ } EXPORT_SYMBOL(hci_unregister_dev); +#if 0 + /* Suspend HCI device */ int hci_suspend_dev(struct hci_dev *hdev) { @@ -915,6 +916,8 @@ } EXPORT_SYMBOL(hci_resume_dev); +#endif /* 0 */ + /* ---- Interface to upper protocols ---- */ /* Register/Unregister protocols. @@ -1042,7 +1045,6 @@ return 0; } -EXPORT_SYMBOL(hci_send_cmd); /* Get data from the previously sent command */ void *hci_sent_cmd_data(struct hci_dev *hdev, __u16 ogf, __u16 ocf) --- linux-2.6.12-rc3-mm2-full/net/bluetooth/lib.c.old 2005-05-03 10:39:29.000000000 +0200 +++ linux-2.6.12-rc3-mm2-full/net/bluetooth/lib.c 2005-05-03 10:39:49.000000000 +0200 @@ -34,6 +34,7 @@ #include +#ifdef HCI_DATA_DUMP void bt_dump(char *pref, __u8 *buf, int count) { char *ptr; @@ -58,6 +59,7 @@ printk(KERN_INFO "%s:%s\n", pref, line); } EXPORT_SYMBOL(bt_dump); +#endif /* HCI_DATA_DUMP */ void baswap(bdaddr_t *dst, bdaddr_t *src) { --- linux-2.6.12-rc3-mm2-full/net/bluetooth/hci_event.c.old 2005-05-03 10:48:13.000000000 +0200 +++ linux-2.6.12-rc3-mm2-full/net/bluetooth/hci_event.c 2005-05-03 10:48:21.000000000 +0200 @@ -1040,4 +1040,3 @@ hci_send_to_sock(hdev, skb); kfree_skb(skb); } -EXPORT_SYMBOL(hci_si_event); From dgibson@ozlabs.org Wed May 4 17:28:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 17:28:30 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j450SN7J021943 for ; Wed, 4 May 2005 17:28:24 -0700 Received: by ozlabs.org (Postfix, from userid 1007) id 5910A67A05; Thu, 5 May 2005 10:28:08 +1000 (EST) Date: Thu, 5 May 2005 10:27:59 +1000 From: David Gibson To: Andrew Morton Cc: Pavel Roskin , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [proski@gnu.org: [PATCH] Mailing lists, homepage for orinoco driver] Message-ID: <20050505002759.GB18270@localhost.localdomain> Mail-Followup-To: David Gibson , Andrew Morton , Pavel Roskin , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-archive-position: 721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev I think this can go straight to Andrew and Linus, without having to go via netdev. Andrew, please apply. Acked-by: David Gibson ----- Forwarded message from Pavel Roskin ----- Subject: [PATCH] Mailing lists, homepage for orinoco driver From: Pavel Roskin To: David Gibson , netdev@oss.sgi.com Date: Thu, 21 Apr 2005 22:23:23 -0400 Hello! Please add mailing list addresses for Orinoco and update its homepage. Signed-off-by: Pavel Roskin MAINTAINERS: 4333b69e56bdefdbc30858e0d4ccaf887d9b2ae0 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1699,7 +1699,9 @@ P: Pavel Roskin M: proski@gnu.org P: David Gibson M: hermes@gibson.dropbear.id.au -W: http://www.ozlabs.org/people/dgibson/dldwd +L: orinoco-users@lists.sourceforge.net +L: orinoco-devel@lists.sourceforge.net +W: http://www.nongnu.org/orinoco/ S: Maintained PARALLEL PORT SUPPORT -- Regards, Pavel Roskin ----- End forwarded message ----- -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/people/dgibson From michaelc@cs.wisc.edu Wed May 4 19:53:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 19:53:51 -0700 (PDT) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j452rm7J028909 for ; Wed, 4 May 2005 19:53:48 -0700 Received: from [192.168.0.2] ([199.108.226.254]) (authenticated bits=0) by sabe.cs.wisc.edu (8.13.1/8.13.1) with ESMTP id j452rVaw029801 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 May 2005 21:53:33 -0500 Message-ID: <42798AA6.4090109@cs.wisc.edu> Date: Wed, 04 May 2005 19:53:26 -0700 From: Mike Christie User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev , linux-scsi , netdev Subject: [PATCH 1/3] add open iscsi netlink interface to iscsi transport class Content-Type: multipart/mixed; boundary="------------000905020208010703030007" X-archive-position: 723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michaelc@cs.wisc.edu Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------000905020208010703030007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit attached add-iscsi-netlink-def.patch - include/linux/netlink.h changes (added new protocol NETLINK_ISCSI) Thanks, Linux-iscsi Team Signed-off-by: Alex Aizman Signed-off-by: Dmitry Yusupov Signed-off-by: Mike Christie --------------000905020208010703030007 Content-Type: text/x-patch; name="add-iscsi-netlink-def.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="add-iscsi-netlink-def.patch" --- linux-2.6.12-rc3.orig/include/linux/netlink.h 2005-04-20 17:03:16.000000000 -0700 +++ linux-2.6.12-rc3/include/linux/netlink.h 2005-05-04 18:06:44.000000000 -0700 @@ -14,6 +14,7 @@ #define NETLINK_SELINUX 7 /* SELinux event notifications */ #define NETLINK_ARPD 8 #define NETLINK_AUDIT 9 /* auditing */ +#define NETLINK_ISCSI 10 /* iSCSI Open Interface */ #define NETLINK_ROUTE6 11 /* af_inet6 route comm channel */ #define NETLINK_IP6_FW 13 #define NETLINK_DNRTMSG 14 /* DECnet routing messages */ --------------000905020208010703030007-- From michaelc@cs.wisc.edu Wed May 4 19:54:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 19:54:19 -0700 (PDT) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j452sF7J028965 for ; Wed, 4 May 2005 19:54:15 -0700 Received: from [192.168.0.2] ([199.108.226.254]) (authenticated bits=0) by sabe.cs.wisc.edu (8.13.1/8.13.1) with ESMTP id j452rxht029804 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 May 2005 21:53:59 -0500 Message-ID: <42798AC1.2010308@cs.wisc.edu> Date: Wed, 04 May 2005 19:53:53 -0700 From: Mike Christie User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-scsi , netdev , linux-kernel@vger.kernel.org Subject: [PATCH 2/3] add open iscsi netlink interface to iscsi transport class Content-Type: multipart/mixed; boundary="------------060103050002050101020701" X-archive-position: 724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michaelc@cs.wisc.edu Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------060103050002050101020701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit attached common-iscsi-headers.patch - Common header files: - iscsi_if.h (user/kernel #defines); - iscsi_proto.h (RFC3720 #defines and types); - iscsi_ifev.h (user/kernel events). Thanks, Linux-iscsi Team Signed-off-by: Alex Aizman Signed-off-by: Dmitry Yusupov Signed-off-by: Mike Christie --------------060103050002050101020701 Content-Type: text/x-patch; name="common-iscsi-headers.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="common-iscsi-headers.patch" diff -Naurp linux-2.6.12-rc3.orig/include/scsi/iscsi_ifev.h linux-2.6.12-rc3/include/scsi/iscsi_ifev.h --- linux-2.6.12-rc3.orig/include/scsi/iscsi_ifev.h 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.12-rc3/include/scsi/iscsi_ifev.h 2005-05-04 18:21:43.000000000 -0700 @@ -0,0 +1,121 @@ +/* + * iSCSI Kernel/User Interface Events + * + * Copyright (C) 2005 Dmitry Yusupov, Alex Aizman + * maintained by open-iscsi@googlegroups.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published + * by the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * See the file COPYING included with this distribution for more details. + */ + +#ifndef ISCSI_IFEV_H +#define ISCSI_IFEV_H + +enum iscsi_uevent_e { + ISCSI_UEVENT_UNKNOWN = 0, + + /* down events */ + ISCSI_UEVENT_CREATE_SESSION = UEVENT_BASE + 1, + ISCSI_UEVENT_DESTROY_SESSION = UEVENT_BASE + 2, + ISCSI_UEVENT_CREATE_CNX = UEVENT_BASE + 3, + ISCSI_UEVENT_DESTROY_CNX = UEVENT_BASE + 4, + ISCSI_UEVENT_BIND_CNX = UEVENT_BASE + 5, + ISCSI_UEVENT_SET_PARAM = UEVENT_BASE + 6, + ISCSI_UEVENT_START_CNX = UEVENT_BASE + 7, + ISCSI_UEVENT_STOP_CNX = UEVENT_BASE + 8, + ISCSI_UEVENT_SEND_PDU = UEVENT_BASE + 9, + ISCSI_UEVENT_TRANS_LIST = UEVENT_BASE + 10, + ISCSI_UEVENT_GET_STATS = UEVENT_BASE + 11, + ISCSI_UEVENT_GET_PARAM = UEVENT_BASE + 12, + + /* up events */ + ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1, + ISCSI_KEVENT_CNX_ERROR = KEVENT_BASE + 2, + ISCSI_KEVENT_IF_ERROR = KEVENT_BASE + 3, +}; + +struct iscsi_uevent { + uint32_t type; /* k/u events type */ + uint32_t iferror; /* carries interface or resource errors */ + uint64_t transport_handle; + + union { + /* messages u -> k */ + struct msg_create_session { + uint32_t initial_cmdsn; + } c_session; + struct msg_destroy_session { + uint64_t session_handle; + uint32_t sid; + } d_session; + struct msg_create_cnx { + uint64_t session_handle; + uint32_t cid; + uint32_t sid; + } c_cnx; + struct msg_bind_cnx { + uint64_t session_handle; + uint64_t cnx_handle; + uint32_t transport_fd; + uint32_t is_leading; + } b_cnx; + struct msg_destroy_cnx { + uint64_t cnx_handle; + uint32_t cid; + } d_cnx; + struct msg_send_pdu { + uint32_t hdr_size; + uint32_t data_size; + uint64_t cnx_handle; + } send_pdu; + struct msg_set_param { + uint64_t cnx_handle; + uint32_t param; /* enum iscsi_param */ + uint32_t value; + } set_param; + struct msg_start_cnx { + uint64_t cnx_handle; + } start_cnx; + struct msg_stop_cnx { + uint64_t cnx_handle; + uint32_t flag; + } stop_cnx; + struct msg_get_stats { + uint64_t cnx_handle; + } get_stats; + } u; + union { + /* messages k -> u */ + uint64_t handle; + int retcode; + struct msg_create_session_ret { + uint64_t session_handle; + uint32_t sid; + } c_session_ret; + struct msg_recv_req { + uint64_t recv_handle; + uint64_t cnx_handle; + } recv_req; + struct msg_cnx_error { + uint64_t cnx_handle; + uint32_t error; /* enum iscsi_err */ + } cnxerror; + struct msg_trans_list { + struct { + uint64_t trans_handle; + char name[ISCSI_TRANSPORT_NAME_MAXLEN]; + } elements[ISCSI_TRANSPORT_MAX]; + } t_list; + } r; +} __attribute__ ((aligned (sizeof(unsigned long)))); + +#endif /* ISCSI_IFEV_H */ diff -Naurp linux-2.6.12-rc3.orig/include/scsi/iscsi_if.h linux-2.6.12-rc3/include/scsi/iscsi_if.h --- linux-2.6.12-rc3.orig/include/scsi/iscsi_if.h 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.12-rc3/include/scsi/iscsi_if.h 2005-05-04 18:22:05.000000000 -0700 @@ -0,0 +1,155 @@ +/* + * iSCSI User/Kernel Shares (Defines, Constants, Protocol definitions, etc) + * + * Copyright (C) 2005 Dmitry Yusupov, Alex Aizman + * maintained by open-iscsi@googlegroups.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published + * by the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * See the file COPYING included with this distribution for more details. + */ + +#ifndef ISCSI_IF_H +#define ISCSI_IF_H + +#include + +#define ISCSI_TRANSPORT_NAME_MAXLEN 16 +#define ISCSI_TRANSPORT_MAX 1 +#define UEVENT_BASE 10 +#define KEVENT_BASE 100 +#define ISCSI_ERR_BASE 1000 + +/* + * Common error codes + */ +enum iscsi_err { + ISCSI_OK = 0, + + ISCSI_ERR_DATASN = ISCSI_ERR_BASE + 1, + ISCSI_ERR_DATA_OFFSET = ISCSI_ERR_BASE + 2, + ISCSI_ERR_MAX_CMDSN = ISCSI_ERR_BASE + 3, + ISCSI_ERR_EXP_CMDSN = ISCSI_ERR_BASE + 4, + ISCSI_ERR_BAD_OPCODE = ISCSI_ERR_BASE + 5, + ISCSI_ERR_DATALEN = ISCSI_ERR_BASE + 6, + ISCSI_ERR_AHSLEN = ISCSI_ERR_BASE + 7, + ISCSI_ERR_PROTO = ISCSI_ERR_BASE + 8, + ISCSI_ERR_LUN = ISCSI_ERR_BASE + 9, + ISCSI_ERR_BAD_ITT = ISCSI_ERR_BASE + 10, + ISCSI_ERR_CNX_FAILED = ISCSI_ERR_BASE + 11, + ISCSI_ERR_R2TSN = ISCSI_ERR_BASE + 12, + ISCSI_ERR_SNX_FAILED = ISCSI_ERR_BASE + 13, + ISCSI_ERR_HDR_DGST = ISCSI_ERR_BASE + 14, + ISCSI_ERR_DATA_DGST = ISCSI_ERR_BASE + 15, + ISCSI_ERR_PDU_GATHER_FAILED = ISCSI_ERR_BASE + 16, + ISCSI_ERR_PARAM_NOT_FOUND = ISCSI_ERR_BASE + 17 +}; + +/* + * iSCSI Parameters (RFC3720) + */ +enum iscsi_param { + ISCSI_PARAM_MAX_RECV_DLENGTH = 0, + ISCSI_PARAM_MAX_XMIT_DLENGTH = 1, + ISCSI_PARAM_HDRDGST_EN = 2, + ISCSI_PARAM_DATADGST_EN = 3, + ISCSI_PARAM_INITIAL_R2T_EN = 4, + ISCSI_PARAM_MAX_R2T = 5, + ISCSI_PARAM_IMM_DATA_EN = 6, + ISCSI_PARAM_FIRST_BURST = 7, + ISCSI_PARAM_MAX_BURST = 8, + ISCSI_PARAM_PDU_INORDER_EN = 9, + ISCSI_PARAM_DATASEQ_INORDER_EN = 10, + ISCSI_PARAM_ERL = 11, + ISCSI_PARAM_IFMARKER_EN = 12, + ISCSI_PARAM_OFMARKER_EN = 13, +}; +#define ISCSI_PARAM_MAX 14 + +typedef uint64_t iscsi_snx_t; /* iSCSI Data-Path session handle */ +typedef uint64_t iscsi_cnx_t; /* iSCSI Data-Path connection handle */ + +#define iscsi_ptr(_handle) ((void*)(unsigned long)_handle) +#define iscsi_handle(_ptr) ((uint64_t)(unsigned long)_ptr) +#define iscsi_hostdata(_hostdata) ((void*)_hostdata + sizeof(unsigned long)) + +/* + * These flags presents iSCSI Data-Path capabilities. + */ +#define CAP_RECOVERY_L0 0x1 +#define CAP_RECOVERY_L1 0x2 +#define CAP_RECOVERY_L2 0x4 +#define CAP_MULTI_R2T 0x8 +#define CAP_HDRDGST 0x10 +#define CAP_DATADGST 0x20 +#define CAP_MULTI_CNX 0x40 +#define CAP_TEXT_NEGO 0x80 + +/* + * These flags describes reason of stop_cnx() call + */ +#define STOP_CNX_TERM 0x1 +#define STOP_CNX_SUSPEND 0x2 +#define STOP_CNX_RECOVER 0x3 + +#define ISCSI_STATS_CUSTOM_MAX 32 +#define ISCSI_STATS_CUSTOM_DESC_MAX 64 +struct iscsi_stats_custom { + char desc[ISCSI_STATS_CUSTOM_DESC_MAX]; + uint64_t value; +}; + +/* + * struct iscsi_stats - iSCSI Statistics (iSCSI MIB) + * + * Note: this structure contains counters collected on per-connection basis. + */ +struct iscsi_stats { + /* octets */ + uint64_t txdata_octets; + uint64_t rxdata_octets; + + /* xmit pdus */ + uint32_t noptx_pdus; + uint32_t scsicmd_pdus; + uint32_t tmfcmd_pdus; + uint32_t login_pdus; + uint32_t text_pdus; + uint32_t dataout_pdus; + uint32_t logout_pdus; + uint32_t snack_pdus; + + /* recv pdus */ + uint32_t noprx_pdus; + uint32_t scsirsp_pdus; + uint32_t tmfrsp_pdus; + uint32_t textrsp_pdus; + uint32_t datain_pdus; + uint32_t logoutrsp_pdus; + uint32_t r2t_pdus; + uint32_t async_pdus; + uint32_t rjt_pdus; + + /* errors */ + uint32_t digest_err; + uint32_t timeout_err; + + /* + * iSCSI Custom Statistics support, i.e. Transport could + * extend existing MIB statistics with its own specific statistics + * up to ISCSI_STATS_CUSTOM_MAX + */ + uint32_t custom_length; + struct iscsi_stats_custom custom[0] + __attribute__ ((aligned (sizeof(unsigned long)))); +}; + +#endif diff -Naurp linux-2.6.12-rc3.orig/include/scsi/iscsi_proto.h linux-2.6.12-rc3/include/scsi/iscsi_proto.h --- linux-2.6.12-rc3.orig/include/scsi/iscsi_proto.h 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.12-rc3/include/scsi/iscsi_proto.h 2005-05-04 18:21:43.000000000 -0700 @@ -0,0 +1,565 @@ +/* + * RFC 3720 (iSCSI) protocol data types + * + * Copyright (C) 2005 Dmitry Yusupov, Alex Aizman + * maintained by open-iscsi@googlegroups.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published + * by the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * See the file COPYING included with this distribution for more details. + */ + +#ifndef ISCSI_PROTO_H +#define ISCSI_PROTO_H + +#define ISCSI_VERSION_STR "0.3" +#define ISCSI_DATE_STR "22-Apr-2005" +#define ISCSI_DRAFT20_VERSION 0x00 + +/* default iSCSI listen port for incoming connections */ +#define ISCSI_LISTEN_PORT 3260 + +/* Padding word length */ +#define PAD_WORD_LEN 4 + +/* + * useful common(control and data pathes) macro + */ +#define ntoh24(p) (((p)[0] << 16) | ((p)[1] << 8) | ((p)[2])) +#define hton24(p, v) { \ + p[0] = (((v) >> 16) & 0xFF); \ + p[1] = (((v) >> 8) & 0xFF); \ + p[2] = ((v) & 0xFF); \ +} +#define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;} + +/* + * iSCSI Template Message Header + */ +struct iscsi_hdr { + uint8_t opcode; + uint8_t flags; /* Final bit */ + uint8_t rsvd2[2]; + uint8_t hlength; /* AHSs total length */ + uint8_t dlength[3]; /* Data length */ + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 ttt; /* Target Task Tag */ + __be32 statsn; + __be32 exp_statsn; + uint8_t other[16]; +}; + +/************************* RFC 3720 Begin *****************************/ + +#define ISCSI_RESERVED_TAG 0xffffffff + +/* Opcode encoding bits */ +#define ISCSI_OP_RETRY 0x80 +#define ISCSI_OP_IMMEDIATE 0x40 +#define ISCSI_OPCODE_MASK 0x3F + +/* Initiator Opcode values */ +#define ISCSI_OP_NOOP_OUT 0x00 +#define ISCSI_OP_SCSI_CMD 0x01 +#define ISCSI_OP_SCSI_TMFUNC 0x02 +#define ISCSI_OP_LOGIN 0x03 +#define ISCSI_OP_TEXT 0x04 +#define ISCSI_OP_SCSI_DATA_OUT 0x05 +#define ISCSI_OP_LOGOUT 0x06 +#define ISCSI_OP_SNACK 0x10 + +/* Target Opcode values */ +#define ISCSI_OP_NOOP_IN 0x20 +#define ISCSI_OP_SCSI_CMD_RSP 0x21 +#define ISCSI_OP_SCSI_TMFUNC_RSP 0x22 +#define ISCSI_OP_LOGIN_RSP 0x23 +#define ISCSI_OP_TEXT_RSP 0x24 +#define ISCSI_OP_SCSI_DATA_IN 0x25 +#define ISCSI_OP_LOGOUT_RSP 0x26 +#define ISCSI_OP_R2T 0x31 +#define ISCSI_OP_ASYNC_EVENT 0x32 +#define ISCSI_OP_REJECT 0x3f + +/* SCSI Command Header */ +struct iscsi_cmd { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2; + uint8_t cmdrn; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 data_length; + __be32 cmdsn; + __be32 exp_statsn; + uint8_t cdb[16]; /* SCSI Command Block */ + /* Additional Data (Command Dependent) */ +}; + +/* Command PDU flags */ +#define ISCSI_FLAG_CMD_FINAL 0x80 +#define ISCSI_FLAG_CMD_READ 0x40 +#define ISCSI_FLAG_CMD_WRITE 0x20 +#define ISCSI_FLAG_CMD_ATTR_MASK 0x07 /* 3 bits */ + +/* SCSI Command Attribute values */ +#define ISCSI_ATTR_UNTAGGED 0 +#define ISCSI_ATTR_SIMPLE 1 +#define ISCSI_ATTR_ORDERED 2 +#define ISCSI_ATTR_HEAD_OF_QUEUE 3 +#define ISCSI_ATTR_ACA 4 + +/* SCSI Response Header */ +struct iscsi_cmd_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t response; + uint8_t cmd_status; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 rsvd1; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 exp_datasn; + __be32 bi_residual_count; + __be32 residual_count; + /* Response or Sense Data (optional) */ +}; + +/* Command Response PDU flags */ +#define ISCSI_FLAG_CMD_BIDI_OVERFLOW 0x10 +#define ISCSI_FLAG_CMD_BIDI_UNDERFLOW 0x08 +#define ISCSI_FLAG_CMD_OVERFLOW 0x04 +#define ISCSI_FLAG_CMD_UNDERFLOW 0x02 + +/* iSCSI Status values. Valid if Rsp Selector bit is not set */ +#define ISCSI_STATUS_CMD_COMPLETED 0 +#define ISCSI_STATUS_TARGET_FAILURE 1 +#define ISCSI_STATUS_SUBSYS_FAILURE 2 + +/* Asynchronous Event Header */ +struct iscsi_async { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t lun[8]; + uint8_t rsvd4[8]; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t async_event; + uint8_t async_vcode; + __be16 param1; + __be16 param2; + __be16 param3; + uint8_t rsvd5[4]; +}; + +/* iSCSI Event Codes */ +#define ISCSI_ASYNC_MSG_SCSI_EVENT 0 +#define ISCSI_ASYNC_MSG_REQUEST_LOGOUT 1 +#define ISCSI_ASYNC_MSG_DROPPING_CONNECTION 2 +#define ISCSI_ASYNC_MSG_DROPPING_ALL_CONNECTIONS 3 +#define ISCSI_ASYNC_MSG_PARAM_NEGOTIATION 4 +#define ISCSI_ASYNC_MSG_VENDOR_SPECIFIC 255 + +/* NOP-Out Message */ +struct iscsi_nopout { + uint8_t opcode; + uint8_t flags; + __be16 rsvd2; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 ttt; /* Target Transfer Tag */ + __be32 cmdsn; + __be32 exp_statsn; + uint8_t rsvd4[16]; +}; + +/* NOP-In Message */ +struct iscsi_nopin { + uint8_t opcode; + uint8_t flags; + __be16 rsvd2; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 ttt; /* Target Transfer Tag */ + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t rsvd4[12]; +}; + +/* SCSI Task Management Message Header */ +struct iscsi_tm { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd1[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 rtt; /* Reference Task Tag */ + __be32 cmdsn; + __be32 exp_statsn; + __be32 refcmdsn; + __be32 exp_datasn; + uint8_t rsvd2[8]; +}; + +#define ISCSI_FLAG_TASK_MGMT_FUNCTION_MASK 0x7F + +/* Function values */ +#define ISCSI_TM_FUNC_ABORT_TASK 1 +#define ISCSI_TM_FUNC_ABORT_TASK_SET 2 +#define ISCSI_TM_FUNC_CLEAR_ACA 3 +#define ISCSI_TM_FUNC_CLEAR_TASK_SET 4 +#define ISCSI_TM_FUNC_LOGICAL_UNIT_RESET 5 +#define ISCSI_TM_FUNC_TARGET_WARM_RESET 6 +#define ISCSI_TM_FUNC_TARGET_COLD_RESET 7 +#define ISCSI_TM_FUNC_TASK_REASSIGN 8 + +/* SCSI Task Management Response Header */ +struct iscsi_tm_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t response; /* see Response values below */ + uint8_t qualifier; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd2[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 rtt; /* Reference Task Tag */ + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t rsvd3[12]; +}; + +/* Response values */ +#define SCSI_TCP_TM_RESP_COMPLETE 0x00 +#define SCSI_TCP_TM_RESP_NO_TASK 0x01 +#define SCSI_TCP_TM_RESP_NO_LUN 0x02 +#define SCSI_TCP_TM_RESP_TASK_ALLEGIANT 0x03 +#define SCSI_TCP_TM_RESP_NO_FAILOVER 0x04 +#define SCSI_TCP_TM_RESP_NOT_SUPPORTED 0x05 +#define SCSI_TCP_TM_RESP_AUTH_FAILED 0x06 +#define SCSI_TCP_TM_RESP_REJECTED 0xff + +/* Ready To Transfer Header */ +struct iscsi_r2t_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 ttt; /* Target Transfer Tag */ + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 r2tsn; + __be32 data_offset; + __be32 data_length; +}; + +/* SCSI Data Hdr */ +struct iscsi_data { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; + __be32 ttt; + __be32 rsvd4; + __be32 exp_statsn; + __be32 rsvd5; + __be32 datasn; + __be32 offset; + __be32 rsvd6; + /* Payload */ +}; + +/* SCSI Data Response Hdr */ +struct iscsi_data_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2; + uint8_t cmd_status; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; + __be32 ttt; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 datasn; + __be32 offset; + __be32 residual_count; +}; + +/* Data Response PDU flags */ +#define ISCSI_FLAG_DATA_ACK 0x40 +#define ISCSI_FLAG_DATA_OVERFLOW 0x04 +#define ISCSI_FLAG_DATA_UNDERFLOW 0x02 +#define ISCSI_FLAG_DATA_STATUS 0x01 + +/* Text Header */ +struct iscsi_text { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd4[8]; + __be32 itt; + __be32 ttt; + __be32 cmdsn; + __be32 exp_statsn; + uint8_t rsvd5[16]; + /* Text - key=value pairs */ +}; + +#define ISCSI_FLAG_TEXT_CONTINUE 0x40 + +/* Text Response Header */ +struct iscsi_text_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd4[8]; + __be32 itt; + __be32 ttt; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t rsvd5[12]; + /* Text Response - key:value pairs */ +}; + +/* Login Header */ +struct iscsi_login { + uint8_t opcode; + uint8_t flags; + uint8_t max_version; /* Max. version supported */ + uint8_t min_version; /* Min. version supported */ + uint8_t hlength; + uint8_t dlength[3]; + uint8_t isid[6]; /* Initiator Session ID */ + __be16 tsih; /* Target Session Handle */ + __be32 itt; /* Initiator Task Tag */ + __be16 cid; + __be16 rsvd3; + __be32 cmdsn; + __be32 exp_statsn; + uint8_t rsvd5[16]; +}; + +/* Login PDU flags */ +#define ISCSI_FLAG_LOGIN_TRANSIT 0x80 +#define ISCSI_FLAG_LOGIN_CONTINUE 0x40 +#define ISCSI_FLAG_LOGIN_CURRENT_STAGE_MASK 0x0C /* 2 bits */ +#define ISCSI_FLAG_LOGIN_NEXT_STAGE_MASK 0x03 /* 2 bits */ + +#define ISCSI_LOGIN_CURRENT_STAGE(flags) \ + ((flags & ISCSI_FLAG_LOGIN_CURRENT_STAGE_MASK) >> 2) +#define ISCSI_LOGIN_NEXT_STAGE(flags) \ + (flags & ISCSI_FLAG_LOGIN_NEXT_STAGE_MASK) + +/* Login Response Header */ +struct iscsi_login_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t max_version; /* Max. version supported */ + uint8_t active_version; /* Active version */ + uint8_t hlength; + uint8_t dlength[3]; + uint8_t isid[6]; /* Initiator Session ID */ + __be16 tsih; /* Target Session Handle */ + __be32 itt; /* Initiator Task Tag */ + __be32 rsvd3; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t status_class; /* see Login RSP ststus classes below */ + uint8_t status_detail; /* see Login RSP Status details below */ + uint8_t rsvd4[10]; +}; + +/* Login stage (phase) codes for CSG, NSG */ +#define ISCSI_INITIAL_LOGIN_STAGE -1 +#define ISCSI_SECURITY_NEGOTIATION_STAGE 0 +#define ISCSI_OP_PARMS_NEGOTIATION_STAGE 1 +#define ISCSI_FULL_FEATURE_PHASE 3 + +/* Login Status response classes */ +#define ISCSI_STATUS_CLS_SUCCESS 0x00 +#define ISCSI_STATUS_CLS_REDIRECT 0x01 +#define ISCSI_STATUS_CLS_INITIATOR_ERR 0x02 +#define ISCSI_STATUS_CLS_TARGET_ERR 0x03 + +/* Login Status response detail codes */ +/* Class-0 (Success) */ +#define ISCSI_LOGIN_STATUS_ACCEPT 0x00 + +/* Class-1 (Redirection) */ +#define ISCSI_LOGIN_STATUS_TGT_MOVED_TEMP 0x01 +#define ISCSI_LOGIN_STATUS_TGT_MOVED_PERM 0x02 + +/* Class-2 (Initiator Error) */ +#define ISCSI_LOGIN_STATUS_INIT_ERR 0x00 +#define ISCSI_LOGIN_STATUS_AUTH_FAILED 0x01 +#define ISCSI_LOGIN_STATUS_TGT_FORBIDDEN 0x02 +#define ISCSI_LOGIN_STATUS_TGT_NOT_FOUND 0x03 +#define ISCSI_LOGIN_STATUS_TGT_REMOVED 0x04 +#define ISCSI_LOGIN_STATUS_NO_VERSION 0x05 +#define ISCSI_LOGIN_STATUS_ISID_ERROR 0x06 +#define ISCSI_LOGIN_STATUS_MISSING_FIELDS 0x07 +#define ISCSI_LOGIN_STATUS_CONN_ADD_FAILED 0x08 +#define ISCSI_LOGIN_STATUS_NO_SESSION_TYPE 0x09 +#define ISCSI_LOGIN_STATUS_NO_SESSION 0x0a +#define ISCSI_LOGIN_STATUS_INVALID_REQUEST 0x0b + +/* Class-3 (Target Error) */ +#define ISCSI_LOGIN_STATUS_TARGET_ERROR 0x00 +#define ISCSI_LOGIN_STATUS_SVC_UNAVAILABLE 0x01 +#define ISCSI_LOGIN_STATUS_NO_RESOURCES 0x02 + +/* Logout Header */ +struct iscsi_logout { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd1[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd2[8]; + __be32 itt; /* Initiator Task Tag */ + __be16 cid; + uint8_t rsvd3[2]; + __be32 cmdsn; + __be32 exp_statsn; + uint8_t rsvd4[16]; +}; + +/* Logout PDU flags */ +#define ISCSI_FLAG_LOGOUT_REASON_MASK 0x7F + +/* logout reason_code values */ + +#define ISCSI_LOGOUT_REASON_CLOSE_SESSION 0 +#define ISCSI_LOGOUT_REASON_CLOSE_CONNECTION 1 +#define ISCSI_LOGOUT_REASON_RECOVERY 2 +#define ISCSI_LOGOUT_REASON_AEN_REQUEST 3 + +/* Logout Response Header */ +struct iscsi_logout_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t response; /* see Logout response values below */ + uint8_t rsvd2; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd3[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 rsvd4; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 rsvd5; + __be16 t2wait; + __be16 t2retain; + __be32 rsvd6; +}; + +/* logout response status values */ + +#define ISCSI_LOGOUT_SUCCESS 0 +#define ISCSI_LOGOUT_CID_NOT_FOUND 1 +#define ISCSI_LOGOUT_RECOVERY_UNSUPPORTED 2 +#define ISCSI_LOGOUT_CLEANUP_FAILED 3 + +/* SNACK Header */ +struct iscsi_snack { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[14]; + __be32 itt; + __be32 begrun; + __be32 runlength; + __be32 exp_statsn; + __be32 rsvd3; + __be32 exp_datasn; + uint8_t rsvd6[8]; +}; + +/* SNACK PDU flags */ +#define ISCSI_FLAG_SNACK_TYPE_MASK 0x0F /* 4 bits */ + +/* Reject Message Header */ +struct iscsi_reject { + uint8_t opcode; + uint8_t flags; + uint8_t reason; + uint8_t rsvd2; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t rsvd4[16]; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 datasn; + uint8_t rsvd5[8]; + /* Text - Rejected hdr */ +}; + +/* Reason for Reject */ +#define CMD_BEFORE_LOGIN 1 +#define DATA_DIGEST_ERROR 2 +#define DATA_SNACK_REJECT 3 +#define ISCSI_PROTOCOL_ERROR 4 +#define CMD_NOT_SUPPORTED 5 +#define IMM_CMD_REJECT 6 +#define TASK_IN_PROGRESS 7 +#define INVALID_SNACK 8 +#define BOOKMARK_REJECTED 9 +#define BOOKMARK_NO_RESOURCES 10 +#define NEGOTIATION_RESET 11 + +/* Max. number of Key=Value pairs in a text message */ +#define MAX_KEY_VALUE_PAIRS 8192 + +/* maximum length for text keys/values */ +#define KEY_MAXLEN 64 +#define VALUE_MAXLEN 255 +#define TARGET_NAME_MAXLEN VALUE_MAXLEN + +#define DEFAULT_MAX_RECV_DATA_SEGMENT_LENGTH 8192 + +/************************* RFC 3720 End *****************************/ + +#endif /* ISCSI_PROTO_H */ --------------060103050002050101020701-- From michaelc@cs.wisc.edu Wed May 4 19:53:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 19:53:35 -0700 (PDT) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j452rV7J028885 for ; Wed, 4 May 2005 19:53:32 -0700 Received: from [192.168.0.2] ([199.108.226.254]) (authenticated bits=0) by sabe.cs.wisc.edu (8.13.1/8.13.1) with ESMTP id j452rFN6029797 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 May 2005 21:53:16 -0500 Message-ID: <42798A95.6070909@cs.wisc.edu> Date: Wed, 04 May 2005 19:53:09 -0700 From: Mike Christie User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-scsi , netdev , linux-kernel@vger.kernel.org Subject: [PATCH 0/3] add open iscsi netlink interface to iscsi transport class Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michaelc@cs.wisc.edu Precedence: bulk X-list: netdev The following patches add the linux-iscsi-5.X/open-iscsi project's netlink interface to the iscsi transport class since the groups doing iSCSI over TCP (this module is completed now and will be submitted in a seperate mail), iSCSI over SCTP and iSER are using it for a common interface and to share code. The answers to why netlink and why push so much to userspace can be found here http://open-iscsi.org/. Patches 1. add-iscsi-netlink-def.patch - include/linux/netlink.h changes (added new protocol NETLINK_ISCSI) 2. common-iscsi-headers.patch - Common header files: - iscsi_if.h (user/kernel #defines); - iscsi_proto.h (RFC3720 #defines and types); - iscsi_ifev.h (user/kernel events). 3. integrate-iscsi-netlink.patch - incorporate the open-iscsi/linux-iscsi netlink interface into the iscsi transport class. Thanks, Linux-iscsi Team From itn780@yahoo.com Wed May 4 21:31:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 21:32:02 -0700 (PDT) Received: from smtp109.mail.sc5.yahoo.com (smtp109.mail.sc5.yahoo.com [66.163.170.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j454Vt7J006731 for ; Wed, 4 May 2005 21:31:55 -0700 Received: from unknown (HELO ?192.168.0.144?) (itn780@24.7.113.184 with plain) by smtp109.mail.sc5.yahoo.com with SMTP; 5 May 2005 04:31:40 -0000 Message-ID: <4279A1A5.60405@yahoo.com> Date: Wed, 04 May 2005 21:31:33 -0700 From: Alex Aizman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: linux-scsi@vger.kernel.org CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, linux-iscsi-devel@lists.sourceforge.net, open-iscsi@googlegroups.com, James Bottomley , Christoph Hellwig Subject: [ANNOUNCE] Linux-iSCSI High-Performance Initiator Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: itn780@yahoo.com Precedence: bulk X-list: netdev 1. Linux iSCSI Initiator ================= This is to announce a new release of the iSCSI Initiator for Linux: v5.0.0.3rc2 for 2.6.12 kernel. The previous (2nd) submission (posted 04/12/05) can be located at: http://marc.theaimsgroup.com/?l=linux-kernel&m=111328256211837&w=2 The very first submission is here: http://marc.theaimsgroup.com/?l=linux-kernel&m=111017939025775&w=2 Current release is result of the ongoing effort by the combined linux-iscsi team. In-depth information on the project, including the latest download, performance results, etc. documentation can be found at: http://linux-iscsi.sourceforge.net and/or http://www.open-iscsi.org 2. SCSI transport ============= This Initiator will work with the new iSCSI transport class from the (very) recent submission by Mike Christie. The related (and required) submission can be located at: http://marc.theaimsgroup.com/?l=linux-kernel&m=111526182523809&w=2 3. The patch ========= A single consolidated (94KB) patch against 2.6.12 can be downloaded at: http://www.open-iscsi.org/src/iscsi_tcp.patch This contains: - SCSI LLDD: iscsi_tcp.[ch] (iSCSI transport over TCP/IP). - drivers/scsi/Kconfig changes - drivers/scsi/Makefile changes Signed-off-by: Alex Aizman Signed-off-by: Dmitry Yusupov 4. User space ========== The assoicated userspace tools can be downloaded from http://www.open-iscsi.org/index.html#download 5. Changelog since v5.0.0.2 (Open-iSCSI v 0.2) =================================== * support non-immediate control plane commands * flush queue in cnx_stop() * fix queue add/remove * Christoph Hellwig: - remove sys_iopl and (no need since oom_adj serves the purpose) - patch to use __be16/__be16 types for static typechecking with sparse -Wbitwise - make needlessly global symbols static - switch to proper goto-based error unwinding - kill zone_init cpp abuse - lots of 0 vs. NULL and one missing void in a prototype: cleanup - make two needlessly global symbols in iscsi_tcp.c static - use uintptr_t (the C99 type) to store a pointer instead of the locally defined ulong_t * Mike Christie: - scsi_host_lookup: release scsi host handle right away - patch to move the scsi scanning to userspace. - request_bufflen: rely on the scsi_ml to set the correct value (INQUIRY, REQUEST_SENSE and REPORT_LUNS etc.) * data_xmit(): cleanup, optimization * MRDSL fix (discovered by Mike Christie) * use GFP_ATOMIC in case of recovery and GFP_KERNEL in case of initial login * race fix: max_r2t data_xmit() vs. r2t_rsp() * release socket cleanup: done _after_ stopping data_xmit() * padding: scsi_cmnd total length * r2t sglist assertion fixes * deprecate and remove control plane cnx/snx handles * ERL=0 recovery fix for HeaderDigest=CRC32C * iSCSI MIB and extended statistics: initial support, get_stats() API * get_stats(): calculate actual size of statistics buffer * integrate with scsi_transport_iscsi.[ch] Regards, Linux-iscsi Team From chrisw@osdl.org Wed May 4 22:38:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 22:39:45 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j455cg7J010452 for ; Wed, 4 May 2005 22:38:42 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j455cOU3005607 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 4 May 2005 22:38:25 -0700 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j455cO2H002874; Wed, 4 May 2005 22:38:24 -0700 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j455cOlj002873; Wed, 4 May 2005 22:38:24 -0700 Date: Wed, 4 May 2005 22:38:24 -0700 From: Chris Wright To: Mike Christie Cc: linux-kernel@vger.kernel.org, linux-scsi , netdev Subject: Re: [PATCH 3/3] add open iscsi netlink interface to iscsi transport class Message-ID: <20050505053824.GV23013@shell0.pdx.osdl.net> References: <42798ADD.5070803@cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42798ADD.5070803@cs.wisc.edu> User-Agent: Mutt/1.5.6i X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev * Mike Christie (michaelc@cs.wisc.edu) wrote: > +static int > +iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh) > +{ > + int err = 0; > + struct iscsi_uevent *ev = NLMSG_DATA(nlh); > + struct iscsi_transport *transport = iscsi_ptr(ev->transport_handle); > + > + if (nlh->nlmsg_type != ISCSI_UEVENT_TRANS_LIST && > + iscsi_if_transport_lookup(transport) < 0) > + return -EEXIST; > + > + daemon_pid = NETLINK_CREDS(skb)->pid; > + Are any of these message types privileged operations? I didn't notice any real credential check. > + switch (nlh->nlmsg_type) { > + case ISCSI_UEVENT_TRANS_LIST: { > + int i; > + > + for (i = 0; i < ISCSI_TRANSPORT_MAX; i++) { > + if (transport_table[i]) { > + ev->r.t_list.elements[i].trans_handle = > + iscsi_handle(transport_table[i]); > + strncpy(ev->r.t_list.elements[i].name, > + transport_table[i]->name, > + ISCSI_TRANSPORT_NAME_MAXLEN); > + } else > + ev->r.t_list.elements[i].trans_handle = > + iscsi_handle(NULL); > + } > + } break; > + case ISCSI_UEVENT_CREATE_SESSION: > + err = iscsi_if_create_snx(transport, ev); > + break; > + case ISCSI_UEVENT_DESTROY_SESSION: > + err = iscsi_if_destroy_snx(transport, ev); > + break; > + case ISCSI_UEVENT_CREATE_CNX: > + err = iscsi_if_create_cnx(transport, ev); > + break; > + case ISCSI_UEVENT_DESTROY_CNX: > + err = iscsi_if_destroy_cnx(transport, ev); > + break; > + case ISCSI_UEVENT_BIND_CNX: > + if (!iscsi_if_find_cnx(ev->u.b_cnx.cnx_handle, H_TYPE_TRANS)) > + return -EEXIST; > + ev->r.retcode = transport->bind_cnx( > + ev->u.b_cnx.session_handle, > + ev->u.b_cnx.cnx_handle, > + ev->u.b_cnx.transport_fd, > + ev->u.b_cnx.is_leading); > + break; > + case ISCSI_UEVENT_SET_PARAM: > + if (!iscsi_if_find_cnx(ev->u.set_param.cnx_handle, > + H_TYPE_TRANS)) > + return -EEXIST; > + ev->r.retcode = transport->set_param( > + ev->u.set_param.cnx_handle, > + ev->u.set_param.param, ev->u.set_param.value); > + break; > + case ISCSI_UEVENT_START_CNX: > + if (!iscsi_if_find_cnx(ev->u.start_cnx.cnx_handle, > + H_TYPE_TRANS)) > + return -EEXIST; > + ev->r.retcode = transport->start_cnx( > + ev->u.start_cnx.cnx_handle); > + break; > + case ISCSI_UEVENT_STOP_CNX: > + if (!iscsi_if_find_cnx(ev->u.stop_cnx.cnx_handle, H_TYPE_TRANS)) > + return -EEXIST; > + transport->stop_cnx(ev->u.stop_cnx.cnx_handle, > + ev->u.stop_cnx.flag); > + break; > + case ISCSI_UEVENT_SEND_PDU: > + if (!iscsi_if_find_cnx(ev->u.send_pdu.cnx_handle, > + H_TYPE_TRANS)) > + return -EEXIST; > + ev->r.retcode = transport->send_pdu( > + ev->u.send_pdu.cnx_handle, > + (struct iscsi_hdr*)((char*)ev + sizeof(*ev)), > + (char*)ev + sizeof(*ev) + ev->u.send_pdu.hdr_size, > + ev->u.send_pdu.data_size); > + break; > + case ISCSI_UEVENT_GET_STATS: { > + struct iscsi_stats *stats; > + struct sk_buff *skbstat; > + struct iscsi_if_cnx *cnx; > + struct nlmsghdr *nlhstat; > + struct iscsi_uevent *evstat; > + int len = NLMSG_SPACE(sizeof(*ev) + > + sizeof(struct iscsi_stats) + > + sizeof(struct iscsi_stats_custom) * > + ISCSI_STATS_CUSTOM_MAX); > + int err; > + > + cnx = iscsi_if_find_cnx(ev->u.get_stats.cnx_handle, > + H_TYPE_TRANS); > + if (!cnx) > + return -EEXIST; > + > + do { > + int actual_size; > + > + skbstat = mempool_zone_get_skb(&cnx->z_pdu); > + if (!skbstat) { > + printk("iscsi%d: can not deliver stats: OOM\n", > + cnx->host->host_no); > + return -ENOMEM; > + } > + > + nlhstat = __nlmsg_put(skbstat, daemon_pid, 0, 0, > + (len - sizeof(*nlhstat))); > + evstat = NLMSG_DATA(nlhstat); > + memset(evstat, 0, sizeof(*evstat)); > + evstat->transport_handle = iscsi_handle(cnx->transport); > + evstat->type = nlh->nlmsg_type; > + if (cnx->z_pdu.allocated >= cnx->z_pdu.hiwat) > + evstat->iferror = -ENOMEM; > + evstat->u.get_stats.cnx_handle = > + ev->u.get_stats.cnx_handle; > + stats = (struct iscsi_stats *) > + ((char*)evstat + sizeof(*evstat)); > + memset(stats, 0, sizeof(*stats)); > + > + transport->get_stats(ev->u.get_stats.cnx_handle, stats); > + actual_size = NLMSG_SPACE(sizeof(struct iscsi_uevent) + > + sizeof(struct iscsi_stats) + > + sizeof(struct iscsi_stats_custom) * > + stats->custom_length); > + actual_size -= sizeof(*nlhstat); > + actual_size = NLMSG_LENGTH(actual_size); > + skb_trim(skb, NLMSG_ALIGN(actual_size)); > + nlhstat->nlmsg_len = actual_size; > + > + err = iscsi_unicast_skb(&cnx->z_pdu, skbstat); > + } while (err < 0 && err != -ECONNREFUSED); > + } break; > + default: > + err = -EINVAL; > + break; > + } > + > + return err; > +} From davem@davemloft.net Wed May 4 23:19:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 23:19:23 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j456JI7J013153 for ; Wed, 4 May 2005 23:19:18 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTZWG-0000ln-00 for ; Wed, 04 May 2005 23:07:32 -0700 Date: Wed, 4 May 2005 23:07:31 -0700 From: "David S. Miller" To: netdev@oss.sgi.com Subject: [PATCH] TSO Reloaded Message-Id: <20050504230731.12be1bc3.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Ok, here it is, first draft of the new TSO handling I promised so long ago :-) I was lazy and waited until today to implement the entire thing. It works with basic testing over tg3. I'll discuss the changes in more detail tomorrow, but the only potentially sore spot right now is the tcp_push_one() avoidance done in tcp_sendmsg() and tcp_sendpages(). It may need to be changed to do so mething like "if not TSO then tcp_push_one(), else wait for N packets to accumulate" where N is configurable or dynamically measured in some way. It would be nice to know that this thing works with e1000 and other TSO capable cards, also I did not do much sendfile() testing at all. Thanks. --- ./include/linux/tcp.h.~1~ 2005-04-20 10:18:11.000000000 -0700 +++ ./include/linux/tcp.h 2005-05-04 15:21:50.000000000 -0700 @@ -280,8 +280,7 @@ struct tcp_sock { __u32 snd_wnd; /* The window we expect to receive */ __u32 max_window; /* Maximal window ever seen from peer */ __u32 pmtu_cookie; /* Last pmtu seen by socket */ - __u32 mss_cache; /* Cached effective mss, not including SACKS */ - __u16 mss_cache_std; /* Like mss_cache, but without TSO */ + __u16 mss_cache; /* Cached effective mss, not including SACKS */ __u16 ext_header_len; /* Network protocol overhead (IP/IPv6 options) */ __u8 ca_state; /* State of fast-retransmit machine */ __u8 retransmits; /* Number of unrecovered RTO timeouts. */ --- ./include/net/tcp.h.~1~ 2005-05-03 14:32:02.000000000 -0700 +++ ./include/net/tcp.h 2005-05-04 22:42:49.000000000 -0700 @@ -943,7 +943,6 @@ extern int tcp_write_xmit(struct sock *, extern int tcp_retransmit_skb(struct sock *, struct sk_buff *); extern void tcp_xmit_retransmit_queue(struct sock *); extern void tcp_simple_retransmit(struct sock *); -extern int tcp_trim_head(struct sock *, struct sk_buff *, u32); extern void tcp_send_probe0(struct sock *); extern void tcp_send_partial(struct sock *); @@ -962,7 +961,7 @@ extern void tcp_clear_xmit_timers(struct extern void tcp_delete_keepalive_timer(struct sock *); extern void tcp_reset_keepalive_timer(struct sock *, unsigned long); extern unsigned int tcp_sync_mss(struct sock *sk, u32 pmtu); -extern unsigned int tcp_current_mss(struct sock *sk, int large); +extern unsigned int tcp_current_mss(struct sock *sk); #ifdef TCP_DEBUG extern const char tcp_timer_bug_msg[]; @@ -1054,7 +1053,7 @@ static inline void tcp_reset_xmit_timer( static inline void tcp_initialize_rcv_mss(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); - unsigned int hint = min(tp->advmss, tp->mss_cache_std); + unsigned int hint = min(tp->advmss, tp->mss_cache); hint = min(hint, tp->rcv_wnd/2); hint = min(hint, TCP_MIN_RCVMSS); @@ -1163,45 +1162,16 @@ struct tcp_skb_cb { #include -/* Due to TSO, an SKB can be composed of multiple actual - * packets. To keep these tracked properly, we use this. - */ -static inline int tcp_skb_pcount(const struct sk_buff *skb) -{ - return skb_shinfo(skb)->tso_segs; -} - -/* This is valid iff tcp_skb_pcount() > 1. */ -static inline int tcp_skb_mss(const struct sk_buff *skb) -{ - return skb_shinfo(skb)->tso_size; -} - -static inline void tcp_dec_pcount_approx(__u32 *count, - const struct sk_buff *skb) -{ - if (*count) { - *count -= tcp_skb_pcount(skb); - if ((int)*count < 0) - *count = 0; - } -} - static inline void tcp_packets_out_inc(struct sock *sk, - struct tcp_sock *tp, - const struct sk_buff *skb) + struct tcp_sock *tp) { - int orig = tp->packets_out; - - tp->packets_out += tcp_skb_pcount(skb); - if (!orig) + if (!tp->packets_out++) tcp_reset_xmit_timer(sk, TCP_TIME_RETRANS, tp->rto); } -static inline void tcp_packets_out_dec(struct tcp_sock *tp, - const struct sk_buff *skb) +static inline void tcp_packets_out_dec(struct tcp_sock *tp) { - tp->packets_out -= tcp_skb_pcount(skb); + tp->packets_out--; } /* This determines how many packets are "in the network" to the best @@ -1397,57 +1367,39 @@ static __inline__ void tcp_minshall_upda tp->snd_sml = TCP_SKB_CB(skb)->end_seq; } -/* Return 0, if packet can be sent now without violation Nagle's rules: - 1. It is full sized. - 2. Or it contains FIN. - 3. Or TCP_NODELAY was set. - 4. Or TCP_CORK is not set, and all sent packets are ACKed. - With Minshall's modification: all sent small packets are ACKed. - */ - -static __inline__ int -tcp_nagle_check(const struct tcp_sock *tp, const struct sk_buff *skb, - unsigned mss_now, int nonagle) -{ - return (skb->len < mss_now && - !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && - ((nonagle&TCP_NAGLE_CORK) || - (!nonagle && - tp->packets_out && - tcp_minshall_check(tp)))); -} - -extern void tcp_set_skb_tso_segs(struct sock *, struct sk_buff *); - -/* This checks if the data bearing packet SKB (usually sk->sk_send_head) - * should be put on the wire right now. +/* This determines how many packets, starting with skb, + * should be put on the wire right now. It is guarenteed + * that this many valid packets are in the socket write + * queue, and all of which are in-window. */ -static __inline__ int tcp_snd_test(struct sock *sk, - struct sk_buff *skb, - unsigned cur_mss, int nonagle) +static __inline__ unsigned int tcp_snd_test(struct sock *sk, + struct sk_buff *skb, + unsigned cur_mss, int nonagle) { struct tcp_sock *tp = tcp_sk(sk); - int pkts = tcp_skb_pcount(skb); - - if (!pkts) { - tcp_set_skb_tso_segs(sk, skb); - pkts = tcp_skb_pcount(skb); - } + unsigned int in_flight, cwnd; + int nagle_check, nagle_allows; /* RFC 1122 - section 4.2.3.4 * - * We must queue if - * - * a) The right edge of this frame exceeds the window - * b) There are packets in flight and we have a small segment - * [SWS avoidance and Nagle algorithm] - * (part of SWS is done on packetization) - * Minshall version sounds: there are no _small_ - * segments in flight. (tcp_nagle_check) - * c) We have too many packets 'in flight' + * We must queue if the right edge of this frame exceeds + * the window. + */ + if (after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd)) + return 0; + + /* If we're looking at the final FIN frame, just sent it + * out now. + */ + if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) + return 1; + + /* We must queue if there are packets in flight and we have + * a small segment (SWS avoidance and Nagle algorithm, part + * of SWS is done on packetization). Minshall version sounds: + * there are no _small_ segments in flight. * - * Don't use the nagle rule for urgent data (or - * for the final FIN -DaveM). + * Don't use the nagle rule for urgent data. * * Also, Nagle rule does not apply to frames, which * sit in the middle of queue (they have no chances @@ -1455,14 +1407,36 @@ static __inline__ int tcp_snd_test(struc * not enough to save something seriously (<32 for now). */ - /* Don't be strict about the congestion window for the - * final FIN frame. -DaveM - */ - return (((nonagle&TCP_NAGLE_PUSH) || tp->urg_mode - || !tcp_nagle_check(tp, skb, cur_mss, nonagle)) && - (((tcp_packets_in_flight(tp) + (pkts-1)) < tp->snd_cwnd) || - (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) && - !after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd)); + nagle_check = (skb->len < cur_mss && + ((nonagle&TCP_NAGLE_CORK) || + (!nonagle && + tp->packets_out && + tcp_minshall_check(tp)))); + nagle_allows = ((nonagle & TCP_NAGLE_PUSH) || + tp->urg_mode || + !nagle_check); + if (!nagle_allows) + return 0; + + /* We must queue if we have too many packets 'in flight'. */ + in_flight = tcp_packets_in_flight(tp); + cwnd = tp->snd_cwnd; + if (in_flight < cwnd) { + unsigned int ret = 0; + + cwnd -= in_flight; + while (cwnd--) { + ret++; + skb = skb->next; + if (skb == (struct sk_buff *)&sk->sk_write_queue || + after(TCP_SKB_CB(skb)->end_seq, + tp->snd_una+tp->snd_wnd)) + break; + } + return ret; + } + + return 0; } static __inline__ void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp) @@ -1501,7 +1475,7 @@ static __inline__ void __tcp_push_pendin static __inline__ void tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp) { - __tcp_push_pending_frames(sk, tp, tcp_current_mss(sk, 1), tp->nonagle); + __tcp_push_pending_frames(sk, tp, tcp_current_mss(sk), tp->nonagle); } static __inline__ int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp) @@ -1509,7 +1483,7 @@ static __inline__ int tcp_may_send_now(s struct sk_buff *skb = sk->sk_send_head; return (skb && - tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), + tcp_snd_test(sk, skb, tcp_current_mss(sk), tcp_skb_is_last(sk, skb) ? TCP_NAGLE_PUSH : tp->nonagle)); } @@ -1986,7 +1960,7 @@ static inline void tcp_westwood_update_r static inline __u32 __tcp_westwood_bw_rttmin(const struct tcp_sock *tp) { return max((tp->westwood.bw_est) * (tp->westwood.rtt_min) / - (__u32) (tp->mss_cache_std), + (__u32) (tp->mss_cache), 2U); } --- ./include/net/sock.h.~1~ 2005-05-03 11:34:28.000000000 -0700 +++ ./include/net/sock.h 2005-05-04 16:35:59.000000000 -0700 @@ -1128,13 +1128,16 @@ static inline void sk_stream_moderate_sn static inline struct sk_buff *sk_stream_alloc_pskb(struct sock *sk, int size, int mem, int gfp) { - struct sk_buff *skb = alloc_skb(size + sk->sk_prot->max_header, gfp); + struct sk_buff *skb; + int hdr_len; + hdr_len = SKB_DATA_ALIGN(sk->sk_prot->max_header); + skb = alloc_skb(size + hdr_len, gfp); if (skb) { skb->truesize += mem; if (sk->sk_forward_alloc >= (int)skb->truesize || sk_stream_mem_schedule(sk, skb->truesize, 0)) { - skb_reserve(skb, sk->sk_prot->max_header); + skb_reserve(skb, hdr_len); return skb; } __kfree_skb(skb); --- ./net/ipv4/tcp_output.c.~1~ 2005-04-24 19:06:29.000000000 -0700 +++ ./net/ipv4/tcp_output.c 2005-05-04 22:55:15.000000000 -0700 @@ -41,6 +41,7 @@ #include #include #include +#include /* People can turn this off for buggy TCP's found in printers etc. */ int sysctl_tcp_retrans_collapse = 1; @@ -58,7 +59,7 @@ static inline void update_send_head(stru if (sk->sk_send_head == (struct sk_buff *)&sk->sk_write_queue) sk->sk_send_head = NULL; tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; - tcp_packets_out_inc(sk, tp, skb); + tcp_packets_out_inc(sk, tp); } /* SND.NXT, if window was not shrunk. @@ -274,12 +275,13 @@ static int tcp_transmit_skb(struct sock int sysctl_flags; int err; - BUG_ON(!tcp_skb_pcount(skb)); - #define SYSCTL_FLAG_TSTAMPS 0x1 #define SYSCTL_FLAG_WSCALE 0x2 #define SYSCTL_FLAG_SACK 0x4 + /* Callers must make sure this is set to 1 or greater. */ + BUG_ON(!skb_shinfo(skb)->tso_segs); + sysctl_flags = 0; if (tcb->flags & TCPCB_FLAG_SYN) { tcp_header_size = sizeof(struct tcphdr) + TCPOLEN_MSS; @@ -409,58 +411,32 @@ static void tcp_queue_skb(struct sock *s sk->sk_send_head = skb; } -static inline void tcp_tso_set_push(struct sk_buff *skb) -{ - /* Force push to be on for any TSO frames to workaround - * problems with busted implementations like Mac OS-X that - * hold off socket receive wakeups until push is seen. - */ - if (tcp_skb_pcount(skb) > 1) - TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; -} - /* Send _single_ skb sitting at the send head. This function requires - * true push pending frames to setup probe timer etc. + * true push pending frames to setup probe timer etc. Since we are + * sending only one frame, at most, there is no reason to try to + * cons up a TSO frame here. */ void tcp_push_one(struct sock *sk, unsigned cur_mss) { struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *skb = sk->sk_send_head; - if (tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH)) { + if (tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH) != 0) { /* Send it out now. */ +#if 0 + printk("TCP: tcp_push_one() PACKETS_OUT(%d) CWND(%d) WRITE_QLEN(%d)\n", + tp->packets_out, tp->snd_cwnd, skb_queue_len(&sk->sk_write_queue)); +#endif TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { sk->sk_send_head = NULL; tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; - tcp_packets_out_inc(sk, tp, skb); + tcp_packets_out_inc(sk, tp); return; } } } -void tcp_set_skb_tso_segs(struct sock *sk, struct sk_buff *skb) -{ - struct tcp_sock *tp = tcp_sk(sk); - - if (skb->len <= tp->mss_cache_std || - !(sk->sk_route_caps & NETIF_F_TSO)) { - /* Avoid the costly divide in the normal - * non-TSO case. - */ - skb_shinfo(skb)->tso_segs = 1; - skb_shinfo(skb)->tso_size = 0; - } else { - unsigned int factor; - - factor = skb->len + (tp->mss_cache_std - 1); - factor /= tp->mss_cache_std; - skb_shinfo(skb)->tso_segs = factor; - skb_shinfo(skb)->tso_size = tp->mss_cache_std; - } -} - /* Function to create two new TCP segments. Shrinks the given segment * to the specified size and appends a new segment with the rest of the * packet to the list. This won't be called frequently, I hope. @@ -468,7 +444,6 @@ void tcp_set_skb_tso_segs(struct sock *s */ static int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len) { - struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *buff; int nsize; u16 flags; @@ -488,6 +463,10 @@ static int tcp_fragment(struct sock *sk, return -ENOMEM; /* We'll just try again later. */ sk_charge_skb(sk, buff); + /* Init TSO state. */ + skb_shinfo(buff)->tso_segs = 1; + skb_shinfo(buff)->tso_size = 0; + /* Correct the sequence numbers. */ TCP_SKB_CB(buff)->seq = TCP_SKB_CB(skb)->seq + len; TCP_SKB_CB(buff)->end_seq = TCP_SKB_CB(skb)->end_seq; @@ -522,93 +501,12 @@ static int tcp_fragment(struct sock *sk, */ TCP_SKB_CB(buff)->when = TCP_SKB_CB(skb)->when; - if (TCP_SKB_CB(skb)->sacked & TCPCB_LOST) { - tp->lost_out -= tcp_skb_pcount(skb); - tp->left_out -= tcp_skb_pcount(skb); - } - - /* Fix up tso_factor for both original and new SKB. */ - tcp_set_skb_tso_segs(sk, skb); - tcp_set_skb_tso_segs(sk, buff); - - if (TCP_SKB_CB(skb)->sacked & TCPCB_LOST) { - tp->lost_out += tcp_skb_pcount(skb); - tp->left_out += tcp_skb_pcount(skb); - } - - if (TCP_SKB_CB(buff)->sacked&TCPCB_LOST) { - tp->lost_out += tcp_skb_pcount(buff); - tp->left_out += tcp_skb_pcount(buff); - } - /* Link BUFF into the send queue. */ __skb_append(skb, buff); return 0; } -/* This is similar to __pskb_pull_head() (it will go to core/skbuff.c - * eventually). The difference is that pulled data not copied, but - * immediately discarded. - */ -static unsigned char *__pskb_trim_head(struct sk_buff *skb, int len) -{ - int i, k, eat; - - eat = len; - k = 0; - for (i=0; inr_frags; i++) { - if (skb_shinfo(skb)->frags[i].size <= eat) { - put_page(skb_shinfo(skb)->frags[i].page); - eat -= skb_shinfo(skb)->frags[i].size; - } else { - skb_shinfo(skb)->frags[k] = skb_shinfo(skb)->frags[i]; - if (eat) { - skb_shinfo(skb)->frags[k].page_offset += eat; - skb_shinfo(skb)->frags[k].size -= eat; - eat = 0; - } - k++; - } - } - skb_shinfo(skb)->nr_frags = k; - - skb->tail = skb->data; - skb->data_len -= len; - skb->len = skb->data_len; - return skb->tail; -} - -int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len) -{ - if (skb_cloned(skb) && - pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) - return -ENOMEM; - - if (len <= skb_headlen(skb)) { - __skb_pull(skb, len); - } else { - if (__pskb_trim_head(skb, len-skb_headlen(skb)) == NULL) - return -ENOMEM; - } - - TCP_SKB_CB(skb)->seq += len; - skb->ip_summed = CHECKSUM_HW; - - skb->truesize -= len; - sk->sk_wmem_queued -= len; - sk->sk_forward_alloc += len; - sock_set_flag(sk, SOCK_QUEUE_SHRUNK); - - /* Any change of skb->len requires recalculation of tso - * factor and mss. - */ - if (tcp_skb_pcount(skb) > 1) - tcp_set_skb_tso_segs(sk, skb); - - return 0; -} - /* This function synchronize snd mss to current pmtu/exthdr set. tp->rx_opt.user_mss is mss set by user by TCP_MAXSEG. It does NOT counts @@ -662,7 +560,7 @@ unsigned int tcp_sync_mss(struct sock *s /* And store cached results */ tp->pmtu_cookie = pmtu; - tp->mss_cache = tp->mss_cache_std = mss_now; + tp->mss_cache = mss_now; return mss_now; } @@ -675,56 +573,306 @@ unsigned int tcp_sync_mss(struct sock *s * is not a big flaw. */ -unsigned int tcp_current_mss(struct sock *sk, int large) +unsigned int tcp_current_mss(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); struct dst_entry *dst = __sk_dst_get(sk); - unsigned int do_large, mss_now; + unsigned int mss_now; - mss_now = tp->mss_cache_std; + mss_now = tp->mss_cache; if (dst) { u32 mtu = dst_mtu(dst); if (mtu != tp->pmtu_cookie) mss_now = tcp_sync_mss(sk, mtu); } - do_large = (large && - (sk->sk_route_caps & NETIF_F_TSO) && - !tp->urg_mode); - - if (do_large) { - unsigned int large_mss, factor, limit; - - large_mss = 65535 - tp->af_specific->net_header_len - - tp->ext_header_len - tp->tcp_header_len; - - if (tp->max_window && large_mss > (tp->max_window>>1)) - large_mss = max((tp->max_window>>1), - 68U - tp->tcp_header_len); - - factor = large_mss / mss_now; - - /* Always keep large mss multiple of real mss, but - * do not exceed 1/tso_win_divisor of the congestion window - * so we can keep the ACK clock ticking and minimize - * bursting. + if (tp->rx_opt.eff_sacks) + mss_now -= (TCPOLEN_SACK_BASE_ALIGNED + + (tp->rx_opt.eff_sacks * TCPOLEN_SACK_PERBLOCK)); + return mss_now; +} + +static inline int tcp_skb_data_all_paged(struct sk_buff *skb) +{ + return (skb->len == skb->data_len); +} + +/* If possible, append paged data of SRC_SKB onto the + * tail of DST_SKB. + * + * The only truly complicated part about this is cleanly + * unwinding the state when we hit MAX_SKB_FRAGS. We defer + * updating nr_frags and data_len until all frags are appended + * successfully. + */ +static int skb_append_pages(struct sk_buff *dst_skb, struct sk_buff *src_skb) +{ + int i, dst_nr_frags, dst_new_data_len, err; + int first_new_frag = -1; + int orig_tail_frag_size = -1; + + if (!tcp_skb_data_all_paged(src_skb)) { +#if 0 + printk("skb_append_data: SRC skb not all paged, len(%d) data_len(%d)\n", + src_skb->len, src_skb->data_len); +#endif + return -EINVAL; + } + + dst_nr_frags = skb_shinfo(dst_skb)->nr_frags; + dst_new_data_len = 0; + if (dst_nr_frags != 0) { + skb_frag_t *frag = &skb_shinfo(dst_skb)->frags[dst_nr_frags-1]; + + orig_tail_frag_size = frag->size; + } + for (i = 0; i < skb_shinfo(src_skb)->nr_frags; i++) { + skb_frag_t *src_frag = &skb_shinfo(src_skb)->frags[i]; + skb_frag_t *dst_frag; + int dst_frag_idx; + + dst_frag_idx = dst_nr_frags; + + if (skb_can_coalesce(dst_skb, dst_frag_idx, + src_frag->page, src_frag->page_offset)) { + dst_frag = &skb_shinfo(dst_skb)->frags[dst_frag_idx-1]; + dst_frag->size += src_frag->size; + } else { + err = -EMSGSIZE; + if (dst_frag_idx >= MAX_SKB_FRAGS) { +#if 0 + printk("skb_append_data: Hit MAX_SKB_FRAGS, unwinding.\n"); +#endif + goto unwind_state; + } + + if (first_new_frag == -1) + first_new_frag = dst_frag_idx; + dst_frag = &skb_shinfo(dst_skb)->frags[dst_frag_idx]; + dst_nr_frags = dst_frag_idx + 1; + + dst_frag->page = src_frag->page; + get_page(src_frag->page); + + dst_frag->page_offset = src_frag->page_offset; + dst_frag->size = src_frag->size; + } + dst_new_data_len += src_frag->size; + } + skb_shinfo(dst_skb)->nr_frags = dst_nr_frags; + dst_skb->len += dst_new_data_len; + dst_skb->data_len += dst_new_data_len; + dst_skb->truesize += dst_new_data_len; + TCP_SKB_CB(dst_skb)->end_seq += dst_new_data_len; + TCP_SKB_CB(dst_skb)->flags |= + (TCP_SKB_CB(src_skb)->flags & (TCPCB_FLAG_FIN|TCPCB_FLAG_PSH)); + + return 0; + +unwind_state: + /* Release any coalesced data. */ + if (orig_tail_frag_size != -1) { + int nr_frags = skb_shinfo(dst_skb)->nr_frags; + skb_frag_t *frag = &skb_shinfo(dst_skb)->frags[nr_frags-1]; + + frag->size = orig_tail_frag_size; + } + + /* Release any pages we added. */ + if (first_new_frag != -1) { + for (i = first_new_frag; i < dst_nr_frags; i++) { + skb_frag_t *frag = &skb_shinfo(dst_skb)->frags[i]; + + BUG_ON(!frag->page); + put_page(frag->page); + frag->page = NULL; + } + } + + return err; +} + +static inline struct sk_buff *alloc_tso_skb(struct sock *sk, + struct tcp_sock *tp, + struct sk_buff *cur, + struct sk_buff *head) +{ + int hdr_len = SKB_DATA_ALIGN(sk->sk_prot->max_header); + + if (cur) + return cur; + + if (!(sk->sk_route_caps & NETIF_F_TSO) || + tp->urg_mode) + return NULL; + + cur = alloc_skb(hdr_len, GFP_ATOMIC); + if (cur) { + skb_reserve(cur, hdr_len); + skb_shinfo(cur)->tso_segs = 1; + skb_shinfo(cur)->tso_size = 0; + TCP_SKB_CB(cur)->seq = TCP_SKB_CB(head)->seq; + TCP_SKB_CB(cur)->end_seq = TCP_SKB_CB(head)->seq; + TCP_SKB_CB(cur)->flags = TCPCB_FLAG_ACK; + TCP_SKB_CB(cur)->sacked = 0; + cur->ip_summed = head->ip_summed; + } + return cur; +} + +static inline int tcp_transmit_tso_skb(struct sock *sk, unsigned int mss_now, unsigned int tso_count, struct sk_buff *tso_skb, struct sk_buff *last) +{ + int err; + + BUG_ON(!last); + if (tso_skb->len > mss_now) { + unsigned int len = tso_skb->len; + + len += (mss_now - 1); + skb_shinfo(tso_skb)->tso_segs = len / mss_now; + skb_shinfo(tso_skb)->tso_size = mss_now; + } + + err = tcp_transmit_skb(sk, tso_skb); + if (!err) { + struct tcp_sock *tp = tcp_sk(sk); + int orig; + + sk->sk_send_head = last->next; + if (sk->sk_send_head == (struct sk_buff *)&sk->sk_write_queue) + sk->sk_send_head = NULL; + tp->snd_nxt = TCP_SKB_CB(tso_skb)->end_seq; + + orig = tp->packets_out; + tp->packets_out += tso_count; + if (!orig) + tcp_reset_xmit_timer(sk, TCP_TIME_RETRANS, tp->rto); + + tcp_minshall_update(tp, mss_now, tso_skb); + } + + return err; +} + +/* Transmit N packets starting at SKB. If possible, coalesce packets + * into TSO frames, else just send them one-by-one. Return the number + * of frames actually sent. + */ +static unsigned int segment_and_xmit(struct sock *sk, struct sk_buff *skb, unsigned int mss_now, unsigned int n) +{ + struct tcp_sock *tp = tcp_sk(sk); + struct sk_buff *tso_skb, *last; + unsigned int sent = 0, tso_count; + +#if 0 + printk("TCP: segment_and_xmit() N(%d) PACKETS_OUT(%d) CWND(%d) WRITE_QLEN(%d) ", + n, tp->packets_out, tp->snd_cwnd, skb_queue_len(&sk->sk_write_queue)); + print_symbol("from(%s)\n", (unsigned long)__builtin_return_address(0)); +#endif + tso_skb = alloc_tso_skb(sk, tp, NULL, skb); + last = NULL; + tso_count = 0; + while (n--) { + struct sk_buff *next; + + /* tcp_snd_test() guarentees this for us. */ + BUG_ON(skb == (struct sk_buff *)&sk->sk_write_queue || + after(TCP_SKB_CB(skb)->end_seq, + tp->snd_una+tp->snd_wnd)); + + if (skb->len > mss_now && + tcp_fragment(sk, skb, mss_now)) + break; + + /* This must be after the tcp_fragment() call. */ + next = skb->next; + + /* Always update transmit stamp, even when doing TSO + * gathering. */ - limit = tp->snd_cwnd; - if (sysctl_tcp_tso_win_divisor) - limit /= sysctl_tcp_tso_win_divisor; - limit = max(1U, limit); - if (factor > limit) - factor = limit; + TCP_SKB_CB(skb)->when = tcp_time_stamp; + + if (tso_skb) { + int err; + + do_append: + err = skb_append_pages(tso_skb, skb); + if (!err) { + last = skb; + tso_count++; + goto next_packet; + } + + /* Either we hit the MAX_SKB_FRAGS limit, or + * we hit a packet that has non-paged data. + * Regardless, we first send off the existing + * TSO frame we've been building if it contains + * any data. + */ + if (tso_skb->len) { + TCP_SKB_CB(tso_skb)->when = tcp_time_stamp; + if (tcp_transmit_tso_skb(sk, mss_now, tso_count, + tso_skb, last)) + break; + tso_skb = NULL; + } + tso_skb = alloc_tso_skb(sk, tp, tso_skb, skb); + last = NULL; + tso_count = 0; + if (tso_skb && err == -EMSGSIZE) + goto do_append; - tp->mss_cache = mss_now * factor; + /* Fallthrough to send the non-paged SKB. */ + } + if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) + break; + + update_send_head(sk, tp, skb); - mss_now = tp->mss_cache; + tcp_minshall_update(tp, mss_now, skb); + + next_packet: + sent++; + + skb = next; + } + if (tso_skb) { + if (tso_skb->len) { + TCP_SKB_CB(tso_skb)->when = tcp_time_stamp; + tcp_transmit_tso_skb(sk, mss_now, tso_count, + tso_skb, last); + } else + kfree_skb(tso_skb); } - if (tp->rx_opt.eff_sacks) - mss_now -= (TCPOLEN_SACK_BASE_ALIGNED + - (tp->rx_opt.eff_sacks * TCPOLEN_SACK_PERBLOCK)); - return mss_now; + return sent; +} + +/* Send as much of the send queue as possible, possibly coalescing + * single frames into TSO frames. Return whether any packets were + * sent successfully. + */ +static inline unsigned int emit_send_queue(struct sock *sk, int nonagle) +{ + struct sk_buff *skb = sk->sk_send_head; + unsigned int mss_now = tcp_current_mss(sk); + unsigned int packets_allowed; + unsigned int sent_pkts = 0; + + if (!skb) + goto out; + + packets_allowed = tcp_snd_test(sk, skb, mss_now, + tcp_skb_is_last(sk, skb) ? + nonagle : + TCP_NAGLE_PUSH); + if (!packets_allowed) + goto out; + + sent_pkts = segment_and_xmit(sk, skb, mss_now, packets_allowed); + +out: + return sent_pkts; } /* This routine writes packets to the network. It advances the @@ -736,48 +884,14 @@ unsigned int tcp_current_mss(struct sock */ int tcp_write_xmit(struct sock *sk, int nonagle) { - struct tcp_sock *tp = tcp_sk(sk); - unsigned int mss_now; - /* If we are closed, the bytes will have to remain here. * In time closedown will finish, we empty the write queue and all * will be happy. */ if (sk->sk_state != TCP_CLOSE) { - struct sk_buff *skb; - int sent_pkts = 0; - - /* Account for SACKS, we may need to fragment due to this. - * It is just like the real MSS changing on us midstream. - * We also handle things correctly when the user adds some - * IP options mid-stream. Silly to do, but cover it. - */ - mss_now = tcp_current_mss(sk, 1); - - while ((skb = sk->sk_send_head) && - tcp_snd_test(sk, skb, mss_now, - tcp_skb_is_last(sk, skb) ? nonagle : - TCP_NAGLE_PUSH)) { - if (skb->len > mss_now) { - if (tcp_fragment(sk, skb, mss_now)) - break; - } - - TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); - if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) - break; - - /* Advance the send_head. This one is sent out. - * This call will increment packets_out. - */ - update_send_head(sk, tp, skb); - - tcp_minshall_update(tp, mss_now, skb); - sent_pkts = 1; - } + struct tcp_sock *tp = tcp_sk(sk); - if (sent_pkts) { + if (emit_send_queue(sk, nonagle)) { tcp_cwnd_validate(sk, tp); return 0; } @@ -928,9 +1042,6 @@ static void tcp_retrans_try_collapse(str ((skb_size + next_skb_size) > mss_now)) return; - BUG_ON(tcp_skb_pcount(skb) != 1 || - tcp_skb_pcount(next_skb) != 1); - /* Ok. We will be able to collapse the packet. */ __skb_unlink(next_skb, next_skb->list); @@ -954,22 +1065,23 @@ static void tcp_retrans_try_collapse(str */ TCP_SKB_CB(skb)->sacked |= TCP_SKB_CB(next_skb)->sacked&(TCPCB_EVER_RETRANS|TCPCB_AT_TAIL); if (TCP_SKB_CB(next_skb)->sacked&TCPCB_SACKED_RETRANS) - tp->retrans_out -= tcp_skb_pcount(next_skb); + tp->retrans_out--; if (TCP_SKB_CB(next_skb)->sacked&TCPCB_LOST) { - tp->lost_out -= tcp_skb_pcount(next_skb); - tp->left_out -= tcp_skb_pcount(next_skb); + tp->lost_out--; + tp->left_out--; } /* Reno case is special. Sigh... */ if (!tp->rx_opt.sack_ok && tp->sacked_out) { - tcp_dec_pcount_approx(&tp->sacked_out, next_skb); - tp->left_out -= tcp_skb_pcount(next_skb); + tp->sacked_out--; + tp->left_out--; } /* Not quite right: it can be > snd.fack, but * it is better to underestimate fackets. */ - tcp_dec_pcount_approx(&tp->fackets_out, next_skb); - tcp_packets_out_dec(tp, next_skb); + if (tp->fackets_out) + tp->fackets_out--; + tcp_packets_out_dec(tp); sk_stream_free_skb(sk, next_skb); } } @@ -982,7 +1094,7 @@ void tcp_simple_retransmit(struct sock * { struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *skb; - unsigned int mss = tcp_current_mss(sk, 0); + unsigned int mss = tcp_current_mss(sk); int lost = 0; sk_stream_for_retrans_queue(skb, sk) { @@ -990,11 +1102,11 @@ void tcp_simple_retransmit(struct sock * !(TCP_SKB_CB(skb)->sacked&TCPCB_SACKED_ACKED)) { if (TCP_SKB_CB(skb)->sacked&TCPCB_SACKED_RETRANS) { TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS; - tp->retrans_out -= tcp_skb_pcount(skb); + tp->retrans_out--; } if (!(TCP_SKB_CB(skb)->sacked&TCPCB_LOST)) { TCP_SKB_CB(skb)->sacked |= TCPCB_LOST; - tp->lost_out += tcp_skb_pcount(skb); + tp->lost_out++; lost = 1; } } @@ -1027,7 +1139,7 @@ void tcp_simple_retransmit(struct sock * int tcp_retransmit_skb(struct sock *sk, struct sk_buff *skb) { struct tcp_sock *tp = tcp_sk(sk); - unsigned int cur_mss = tcp_current_mss(sk, 0); + unsigned int cur_mss = tcp_current_mss(sk); int err; /* Do not sent more than we queued. 1/4 is reserved for possible @@ -1037,20 +1149,6 @@ int tcp_retransmit_skb(struct sock *sk, min(sk->sk_wmem_queued + (sk->sk_wmem_queued >> 2), sk->sk_sndbuf)) return -EAGAIN; - if (before(TCP_SKB_CB(skb)->seq, tp->snd_una)) { - if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una)) - BUG(); - - if (sk->sk_route_caps & NETIF_F_TSO) { - sk->sk_route_caps &= ~NETIF_F_TSO; - sock_set_flag(sk, SOCK_NO_LARGESEND); - tp->mss_cache = tp->mss_cache_std; - } - - if (tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)) - return -ENOMEM; - } - /* If receiver has shrunk his window, and skb is out of * new window, do not retransmit it. The exception is the * case, when window is shrunk to zero. In this case @@ -1061,16 +1159,11 @@ int tcp_retransmit_skb(struct sock *sk, return -EAGAIN; if (skb->len > cur_mss) { - int old_factor = tcp_skb_pcount(skb); - int new_factor; - if (tcp_fragment(sk, skb, cur_mss)) return -ENOMEM; /* We'll try again later. */ /* New SKB created, account for it. */ - new_factor = tcp_skb_pcount(skb); - tp->packets_out -= old_factor - new_factor; - tp->packets_out += tcp_skb_pcount(skb->next); + tp->packets_out++; } /* Collapse two adjacent packets if worthwhile and we can. */ @@ -1079,7 +1172,6 @@ int tcp_retransmit_skb(struct sock *sk, (skb->next != sk->sk_send_head) && (skb->next != (struct sk_buff *)&sk->sk_write_queue) && (skb_shinfo(skb)->nr_frags == 0 && skb_shinfo(skb->next)->nr_frags == 0) && - (tcp_skb_pcount(skb) == 1 && tcp_skb_pcount(skb->next) == 1) && (sysctl_tcp_retrans_collapse != 0)) tcp_retrans_try_collapse(sk, skb, cur_mss); @@ -1095,8 +1187,6 @@ int tcp_retransmit_skb(struct sock *sk, tp->snd_una == (TCP_SKB_CB(skb)->end_seq - 1)) { if (!pskb_trim(skb, 0)) { TCP_SKB_CB(skb)->seq = TCP_SKB_CB(skb)->end_seq - 1; - skb_shinfo(skb)->tso_segs = 1; - skb_shinfo(skb)->tso_size = 0; skb->ip_summed = CHECKSUM_NONE; skb->csum = 0; } @@ -1106,7 +1196,6 @@ int tcp_retransmit_skb(struct sock *sk, * is still in somebody's hands, else make a clone. */ TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); err = tcp_transmit_skb(sk, (skb_cloned(skb) ? pskb_copy(skb, GFP_ATOMIC): @@ -1125,7 +1214,7 @@ int tcp_retransmit_skb(struct sock *sk, } #endif TCP_SKB_CB(skb)->sacked |= TCPCB_RETRANS; - tp->retrans_out += tcp_skb_pcount(skb); + tp->retrans_out++; /* Save stamp of the first retransmit. */ if (!tp->retrans_stamp) @@ -1184,8 +1273,7 @@ void tcp_xmit_retransmit_queue(struct so tcp_reset_xmit_timer(sk, TCP_TIME_RETRANS, tp->rto); } - packet_cnt -= tcp_skb_pcount(skb); - if (packet_cnt <= 0) + if (--packet_cnt <= 0) break; } } @@ -1254,7 +1342,7 @@ void tcp_send_fin(struct sock *sk) * unsent frames. But be careful about outgoing SACKS * and IP options. */ - mss_now = tcp_current_mss(sk, 1); + mss_now = tcp_current_mss(sk); if (sk->sk_send_head != NULL) { TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_FIN; @@ -1510,7 +1598,7 @@ int tcp_connect(struct sock *sk) skb_header_release(buff); __skb_queue_tail(&sk->sk_write_queue, buff); sk_charge_skb(sk, buff); - tp->packets_out += tcp_skb_pcount(buff); + tp->packets_out++; tcp_transmit_skb(sk, skb_clone(buff, GFP_KERNEL)); TCP_INC_STATS(TCP_MIB_ACTIVEOPENS); @@ -1655,7 +1743,7 @@ int tcp_write_wakeup(struct sock *sk) if ((skb = sk->sk_send_head) != NULL && before(TCP_SKB_CB(skb)->seq, tp->snd_una+tp->snd_wnd)) { int err; - unsigned int mss = tcp_current_mss(sk, 0); + unsigned int mss = tcp_current_mss(sk); unsigned int seg_size = tp->snd_una+tp->snd_wnd-TCP_SKB_CB(skb)->seq; if (before(tp->pushed_seq, TCP_SKB_CB(skb)->end_seq)) @@ -1671,19 +1759,10 @@ int tcp_write_wakeup(struct sock *sk) TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; if (tcp_fragment(sk, skb, seg_size)) return -1; - /* SWS override triggered forced fragmentation. - * Disable TSO, the connection is too sick. */ - if (sk->sk_route_caps & NETIF_F_TSO) { - sock_set_flag(sk, SOCK_NO_LARGESEND); - sk->sk_route_caps &= ~NETIF_F_TSO; - tp->mss_cache = tp->mss_cache_std; - } - } else if (!tcp_skb_pcount(skb)) - tcp_set_skb_tso_segs(sk, skb); + } TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); err = tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC)); if (!err) { update_send_head(sk, tp, skb); --- ./net/ipv4/tcp_input.c.~1~ 2005-04-25 21:39:24.000000000 -0700 +++ ./net/ipv4/tcp_input.c 2005-05-04 22:42:23.000000000 -0700 @@ -805,10 +805,10 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp, __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0); if (!cwnd) { - if (tp->mss_cache_std > 1460) + if (tp->mss_cache > 1460) cwnd = 2; else - cwnd = (tp->mss_cache_std > 1095) ? 3 : 4; + cwnd = (tp->mss_cache > 1095) ? 3 : 4; } return min_t(__u32, cwnd, tp->snd_cwnd_clamp); } @@ -974,14 +974,6 @@ tcp_sacktag_write_queue(struct sock *sk, int flag = 0; int i; - /* So, SACKs for already sent large segments will be lost. - * Not good, but alternative is to resegment the queue. */ - if (sk->sk_route_caps & NETIF_F_TSO) { - sk->sk_route_caps &= ~NETIF_F_TSO; - sock_set_flag(sk, SOCK_NO_LARGESEND); - tp->mss_cache = tp->mss_cache_std; - } - if (!tp->sacked_out) tp->fackets_out = 0; prior_fackets = tp->fackets_out; @@ -1038,7 +1030,7 @@ tcp_sacktag_write_queue(struct sock *sk, if(!before(TCP_SKB_CB(skb)->seq, end_seq)) break; - fack_count += tcp_skb_pcount(skb); + fack_count++; in_sack = !after(start_seq, TCP_SKB_CB(skb)->seq) && !before(end_seq, TCP_SKB_CB(skb)->end_seq); @@ -1082,8 +1074,8 @@ tcp_sacktag_write_queue(struct sock *sk, */ if (sacked & TCPCB_LOST) { TCP_SKB_CB(skb)->sacked &= ~(TCPCB_LOST|TCPCB_SACKED_RETRANS); - tp->lost_out -= tcp_skb_pcount(skb); - tp->retrans_out -= tcp_skb_pcount(skb); + tp->lost_out--; + tp->retrans_out--; } } else { /* New sack for not retransmitted frame, @@ -1095,13 +1087,13 @@ tcp_sacktag_write_queue(struct sock *sk, if (sacked & TCPCB_LOST) { TCP_SKB_CB(skb)->sacked &= ~TCPCB_LOST; - tp->lost_out -= tcp_skb_pcount(skb); + tp->lost_out--; } } TCP_SKB_CB(skb)->sacked |= TCPCB_SACKED_ACKED; flag |= FLAG_DATA_SACKED; - tp->sacked_out += tcp_skb_pcount(skb); + tp->sacked_out++; if (fack_count > tp->fackets_out) tp->fackets_out = fack_count; @@ -1118,7 +1110,7 @@ tcp_sacktag_write_queue(struct sock *sk, if (dup_sack && (TCP_SKB_CB(skb)->sacked&TCPCB_SACKED_RETRANS)) { TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS; - tp->retrans_out -= tcp_skb_pcount(skb); + tp->retrans_out--; } } } @@ -1142,12 +1134,12 @@ tcp_sacktag_write_queue(struct sock *sk, (IsFack(tp) || !before(lost_retrans, TCP_SKB_CB(skb)->ack_seq + tp->reordering * - tp->mss_cache_std))) { + tp->mss_cache))) { TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS; - tp->retrans_out -= tcp_skb_pcount(skb); + tp->retrans_out--; if (!(TCP_SKB_CB(skb)->sacked&(TCPCB_LOST|TCPCB_SACKED_ACKED))) { - tp->lost_out += tcp_skb_pcount(skb); + tp->lost_out++; TCP_SKB_CB(skb)->sacked |= TCPCB_LOST; flag |= FLAG_DATA_SACKED; NET_INC_STATS_BH(LINUX_MIB_TCPLOSTRETRANSMIT); @@ -1222,7 +1214,7 @@ static void tcp_enter_frto_loss(struct s tp->fackets_out = 0; sk_stream_for_retrans_queue(skb, sk) { - cnt += tcp_skb_pcount(skb); + cnt++; TCP_SKB_CB(skb)->sacked &= ~TCPCB_LOST; if (!(TCP_SKB_CB(skb)->sacked&TCPCB_SACKED_ACKED)) { @@ -1232,10 +1224,10 @@ static void tcp_enter_frto_loss(struct s if (!after(TCP_SKB_CB(skb)->end_seq, tp->frto_highmark)) { TCP_SKB_CB(skb)->sacked |= TCPCB_LOST; - tp->lost_out += tcp_skb_pcount(skb); + tp->lost_out++; } } else { - tp->sacked_out += tcp_skb_pcount(skb); + tp->sacked_out++; tp->fackets_out = cnt; } } @@ -1297,16 +1289,16 @@ void tcp_enter_loss(struct sock *sk, int tp->undo_marker = tp->snd_una; sk_stream_for_retrans_queue(skb, sk) { - cnt += tcp_skb_pcount(skb); + cnt++; if (TCP_SKB_CB(skb)->sacked&TCPCB_RETRANS) tp->undo_marker = 0; TCP_SKB_CB(skb)->sacked &= (~TCPCB_TAGBITS)|TCPCB_SACKED_ACKED; if (!(TCP_SKB_CB(skb)->sacked&TCPCB_SACKED_ACKED) || how) { TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_ACKED; TCP_SKB_CB(skb)->sacked |= TCPCB_LOST; - tp->lost_out += tcp_skb_pcount(skb); + tp->lost_out++; } else { - tp->sacked_out += tcp_skb_pcount(skb); + tp->sacked_out++; tp->fackets_out = cnt; } } @@ -1542,12 +1534,12 @@ static void tcp_mark_head_lost(struct so BUG_TRAP(cnt <= tp->packets_out); sk_stream_for_retrans_queue(skb, sk) { - cnt -= tcp_skb_pcount(skb); + cnt--; if (cnt < 0 || after(TCP_SKB_CB(skb)->end_seq, high_seq)) break; if (!(TCP_SKB_CB(skb)->sacked&TCPCB_TAGBITS)) { TCP_SKB_CB(skb)->sacked |= TCPCB_LOST; - tp->lost_out += tcp_skb_pcount(skb); + tp->lost_out++; } } tcp_sync_left_out(tp); @@ -1578,7 +1570,7 @@ static void tcp_update_scoreboard(struct if (tcp_skb_timedout(tp, skb) && !(TCP_SKB_CB(skb)->sacked&TCPCB_TAGBITS)) { TCP_SKB_CB(skb)->sacked |= TCPCB_LOST; - tp->lost_out += tcp_skb_pcount(skb); + tp->lost_out++; } } tcp_sync_left_out(tp); @@ -2170,7 +2162,7 @@ static void vegas_cong_avoid(struct tcp_ * is the cwnd during the previous RTT. */ old_wnd = (tp->vegas.beg_snd_nxt - tp->vegas.beg_snd_una) / - tp->mss_cache_std; + tp->mss_cache; old_snd_cwnd = tp->vegas.beg_snd_cwnd; /* Save the extent of the current window so we can use this @@ -2348,72 +2340,6 @@ static inline void tcp_ack_packets_out(s } } -/* There is one downside to this scheme. Although we keep the - * ACK clock ticking, adjusting packet counters and advancing - * congestion window, we do not liberate socket send buffer - * space. - * - * Mucking with skb->truesize and sk->sk_wmem_alloc et al. - * then making a write space wakeup callback is a possible - * future enhancement. WARNING: it is not trivial to make. - */ -static int tcp_tso_acked(struct sock *sk, struct sk_buff *skb, - __u32 now, __s32 *seq_rtt) -{ - struct tcp_sock *tp = tcp_sk(sk); - struct tcp_skb_cb *scb = TCP_SKB_CB(skb); - __u32 seq = tp->snd_una; - __u32 packets_acked; - int acked = 0; - - /* If we get here, the whole TSO packet has not been - * acked. - */ - BUG_ON(!after(scb->end_seq, seq)); - - packets_acked = tcp_skb_pcount(skb); - if (tcp_trim_head(sk, skb, seq - scb->seq)) - return 0; - packets_acked -= tcp_skb_pcount(skb); - - if (packets_acked) { - __u8 sacked = scb->sacked; - - acked |= FLAG_DATA_ACKED; - if (sacked) { - if (sacked & TCPCB_RETRANS) { - if (sacked & TCPCB_SACKED_RETRANS) - tp->retrans_out -= packets_acked; - acked |= FLAG_RETRANS_DATA_ACKED; - *seq_rtt = -1; - } else if (*seq_rtt < 0) - *seq_rtt = now - scb->when; - if (sacked & TCPCB_SACKED_ACKED) - tp->sacked_out -= packets_acked; - if (sacked & TCPCB_LOST) - tp->lost_out -= packets_acked; - if (sacked & TCPCB_URG) { - if (tp->urg_mode && - !before(seq, tp->snd_up)) - tp->urg_mode = 0; - } - } else if (*seq_rtt < 0) - *seq_rtt = now - scb->when; - - if (tp->fackets_out) { - __u32 dval = min(tp->fackets_out, packets_acked); - tp->fackets_out -= dval; - } - tp->packets_out -= packets_acked; - - BUG_ON(tcp_skb_pcount(skb) == 0); - BUG_ON(!before(scb->seq, scb->end_seq)); - } - - return acked; -} - - /* Remove acknowledged frames from the retransmission queue. */ static int tcp_clean_rtx_queue(struct sock *sk, __s32 *seq_rtt_p) { @@ -2432,12 +2358,8 @@ static int tcp_clean_rtx_queue(struct so * discard it as it's confirmed to have arrived at * the other end. */ - if (after(scb->end_seq, tp->snd_una)) { - if (tcp_skb_pcount(skb) > 1) - acked |= tcp_tso_acked(sk, skb, - now, &seq_rtt); + if (after(scb->end_seq, tp->snd_una)) break; - } /* Initial outgoing SYN's get put onto the write_queue * just like anything else we transmit. It is not @@ -2456,15 +2378,15 @@ static int tcp_clean_rtx_queue(struct so if (sacked) { if (sacked & TCPCB_RETRANS) { if(sacked & TCPCB_SACKED_RETRANS) - tp->retrans_out -= tcp_skb_pcount(skb); + tp->retrans_out--; acked |= FLAG_RETRANS_DATA_ACKED; seq_rtt = -1; } else if (seq_rtt < 0) seq_rtt = now - scb->when; if (sacked & TCPCB_SACKED_ACKED) - tp->sacked_out -= tcp_skb_pcount(skb); + tp->sacked_out--; if (sacked & TCPCB_LOST) - tp->lost_out -= tcp_skb_pcount(skb); + tp->lost_out--; if (sacked & TCPCB_URG) { if (tp->urg_mode && !before(scb->end_seq, tp->snd_up)) @@ -2472,8 +2394,9 @@ static int tcp_clean_rtx_queue(struct so } } else if (seq_rtt < 0) seq_rtt = now - scb->when; - tcp_dec_pcount_approx(&tp->fackets_out, skb); - tcp_packets_out_dec(tp, skb); + if (tp->fackets_out) + tp->fackets_out--; + tcp_packets_out_dec(tp); __skb_unlink(skb, skb->list); sk_stream_free_skb(sk, skb); } @@ -2799,19 +2722,19 @@ static void westwood_dupack_update(struc { struct tcp_sock *tp = tcp_sk(sk); - tp->westwood.accounted += tp->mss_cache_std; - tp->westwood.cumul_ack = tp->mss_cache_std; + tp->westwood.accounted += tp->mss_cache; + tp->westwood.cumul_ack = tp->mss_cache; } static inline int westwood_may_change_cumul(struct tcp_sock *tp) { - return (tp->westwood.cumul_ack > tp->mss_cache_std); + return (tp->westwood.cumul_ack > tp->mss_cache); } static inline void westwood_partial_update(struct tcp_sock *tp) { tp->westwood.accounted -= tp->westwood.cumul_ack; - tp->westwood.cumul_ack = tp->mss_cache_std; + tp->westwood.cumul_ack = tp->mss_cache; } static inline void westwood_complete_update(struct tcp_sock *tp) @@ -3952,7 +3875,7 @@ static void tcp_new_space(struct sock *s !(sk->sk_userlocks & SOCK_SNDBUF_LOCK) && !tcp_memory_pressure && atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0]) { - int sndmem = max_t(u32, tp->rx_opt.mss_clamp, tp->mss_cache_std) + + int sndmem = max_t(u32, tp->rx_opt.mss_clamp, tp->mss_cache) + MAX_TCP_HEADER + 16 + sizeof(struct sk_buff), demanded = max_t(unsigned int, tp->snd_cwnd, tp->reordering + 1); --- ./net/ipv4/tcp.c.~1~ 2005-04-20 10:18:18.000000000 -0700 +++ ./net/ipv4/tcp.c 2005-05-04 22:23:45.000000000 -0700 @@ -646,7 +646,7 @@ static ssize_t do_tcp_sendpages(struct s clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); - mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + mss_now = tcp_current_mss(sk); copied = 0; err = -EPIPE; @@ -702,7 +702,8 @@ new_segment: skb->ip_summed = CHECKSUM_HW; tp->write_seq += copy; TCP_SKB_CB(skb)->end_seq += copy; - skb_shinfo(skb)->tso_segs = 0; + skb_shinfo(skb)->tso_segs = 1; + skb_shinfo(skb)->tso_size = 0; if (!copied) TCP_SKB_CB(skb)->flags &= ~TCPCB_FLAG_PSH; @@ -718,8 +719,15 @@ new_segment: if (forced_push(tp)) { tcp_mark_push(tp, skb); __tcp_push_pending_frames(sk, tp, mss_now, TCP_NAGLE_PUSH); - } else if (skb == sk->sk_send_head) - tcp_push_one(sk, mss_now); + } else if (skb == sk->sk_send_head) { + /* If we can potentially do TSO, it is better to queue + * things up and accumulate then to push the frame right + * now. + */ + if (!(sk->sk_route_caps & NETIF_F_TSO) || + tp->urg_mode) + tcp_push_one(sk, mss_now); + } continue; wait_for_sndbuf: @@ -731,7 +739,7 @@ wait_for_memory: if ((err = sk_stream_wait_memory(sk, &timeo)) != 0) goto do_error; - mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + mss_now = tcp_current_mss(sk); } out: @@ -773,15 +781,11 @@ ssize_t tcp_sendpage(struct socket *sock static inline int select_size(struct sock *sk, struct tcp_sock *tp) { - int tmp = tp->mss_cache_std; + int tmp = tp->mss_cache; - if (sk->sk_route_caps & NETIF_F_SG) { - int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER); + if (sk->sk_route_caps & NETIF_F_SG) + tmp = 0; - if (tmp >= pgbreak && - tmp <= pgbreak + (MAX_SKB_FRAGS - 1) * PAGE_SIZE) - tmp = pgbreak; - } return tmp; } @@ -810,7 +814,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru /* This should be in poll */ clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); - mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + mss_now = tcp_current_mss(sk); /* Ok commence sending. */ iovlen = msg->msg_iovlen; @@ -949,7 +953,8 @@ new_segment: tp->write_seq += copy; TCP_SKB_CB(skb)->end_seq += copy; - skb_shinfo(skb)->tso_segs = 0; + skb_shinfo(skb)->tso_segs = 1; + skb_shinfo(skb)->tso_size = 0; from += copy; copied += copy; @@ -962,8 +967,15 @@ new_segment: if (forced_push(tp)) { tcp_mark_push(tp, skb); __tcp_push_pending_frames(sk, tp, mss_now, TCP_NAGLE_PUSH); - } else if (skb == sk->sk_send_head) - tcp_push_one(sk, mss_now); + } else if (skb == sk->sk_send_head) { + /* If we can potentially do TSO, it is better to queue + * things up and accumulate then to push the frame right + * now. + */ + if (!(sk->sk_route_caps & NETIF_F_TSO) || + tp->urg_mode) + tcp_push_one(sk, mss_now); + } continue; wait_for_sndbuf: @@ -975,7 +987,7 @@ wait_for_memory: if ((err = sk_stream_wait_memory(sk, &timeo)) != 0) goto do_error; - mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + mss_now = tcp_current_mss(sk); } } @@ -2135,7 +2147,7 @@ void tcp_get_info(struct sock *sk, struc info->tcpi_rto = jiffies_to_usecs(tp->rto); info->tcpi_ato = jiffies_to_usecs(tp->ack.ato); - info->tcpi_snd_mss = tp->mss_cache_std; + info->tcpi_snd_mss = tp->mss_cache; info->tcpi_rcv_mss = tp->ack.rcv_mss; info->tcpi_unacked = tp->packets_out; @@ -2185,7 +2197,7 @@ int tcp_getsockopt(struct sock *sk, int switch (optname) { case TCP_MAXSEG: - val = tp->mss_cache_std; + val = tp->mss_cache; if (!val && ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN))) val = tp->rx_opt.user_mss; break; --- ./net/ipv4/tcp_ipv4.c.~1~ 2005-05-03 14:36:08.000000000 -0700 +++ ./net/ipv4/tcp_ipv4.c 2005-05-04 15:17:16.000000000 -0700 @@ -2060,7 +2060,7 @@ static int tcp_v4_init_sock(struct sock */ tp->snd_ssthresh = 0x7fffffff; /* Infinity */ tp->snd_cwnd_clamp = ~0; - tp->mss_cache_std = tp->mss_cache = 536; + tp->mss_cache = 536; tp->reordering = sysctl_tcp_reordering; --- ./net/ipv6/tcp_ipv6.c.~1~ 2005-05-03 14:36:44.000000000 -0700 +++ ./net/ipv6/tcp_ipv6.c 2005-05-04 15:17:09.000000000 -0700 @@ -2021,7 +2021,7 @@ static int tcp_v6_init_sock(struct sock */ tp->snd_ssthresh = 0x7fffffff; tp->snd_cwnd_clamp = ~0; - tp->mss_cache_std = tp->mss_cache = 536; + tp->mss_cache = 536; tp->reordering = sysctl_tcp_reordering; From yoshfuji@linux-ipv6.org Thu May 5 02:52:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 02:52:56 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j459qp7J001285 for ; Thu, 5 May 2005 02:52:51 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 2473533CC2; Thu, 5 May 2005 18:55:04 +0900 (JST) Date: Thu, 05 May 2005 18:55:03 +0900 (JST) Message-Id: <20050505.185503.78606493.yoshfuji@linux-ipv6.org> To: michaelc@cs.wisc.edu Cc: linux-scsi@vger.kernel.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2/3] add open iscsi netlink interface to iscsi transport class From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <42798AC1.2010308@cs.wisc.edu> References: <42798AC1.2010308@cs.wisc.edu> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <42798AC1.2010308@cs.wisc.edu> (at Wed, 04 May 2005 19:53:53 -0700), Mike Christie says: > +struct iscsi_uevent { : > +} __attribute__ ((aligned (sizeof(unsigned long)))); I think it'd be better to use sizeof(uint64_t) or something. Please check other spots, too. e.g.: > + struct iscsi_stats_custom custom[0] > + __attribute__ ((aligned (sizeof(unsigned long)))); --yoshfuji From anton@ozlabs.org Thu May 5 03:18:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 03:18:48 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45AIj7J003399 for ; Thu, 5 May 2005 03:18:46 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 3A5C567A04; Thu, 5 May 2005 20:18:30 +1000 (EST) Date: Thu, 5 May 2005 20:15:42 +1000 From: Anton Blanchard To: netdev@oss.sgi.com Subject: oops in ip_rcv Message-ID: <20050505101542.GB7916@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Hi, Im booting a recent 2.6.12-rc3++ git tree on ppc64. Just got an oops very early in boot, right after: TCP established hash table entries: 131072 (order: 9, 2097kernel: It looks like we tried to load from address -1. c0000000003c515c ip_rcv+0x4c/0x6e0 c0000000003a6750 netif_receive_skb+0x290/0x3b0 c0000000003a6954 process_backlog+0xe4/0x250 c0000000003a4204 net_rx_action+0x114/0x2d0 c00000000005e06c __do_softirq+0xec/0x1d0 c000000000014568 call_do_softirq+0x14/0x24 c00000000000fdcc do_softirq+0x9c/0xb0 c00000000005dad4 irq_exit+0x64/0x80 c00000000000fcbc do_IRQ+0x7c/0xf0 I do have some local patches, I'll try to reproduce without them. Anton From laforge@netfilter.org Thu May 5 04:15:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 04:15:44 -0700 (PDT) Received: from ganesha.gnumonks.org (ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45BFO7J009096 for ; Thu, 5 May 2005 04:15:25 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DTeJp-0001IO-UH; Thu, 05 May 2005 13:15:02 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DTeJl-0003yv-UZ; Thu, 05 May 2005 13:14:57 +0200 Date: Thu, 5 May 2005 13:14:57 +0200 From: Harald Welte To: Patrick McHardy Cc: Herbert Xu , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, "David S. Miller" Subject: Re: CONFIG_NETFILTER_DEBUG spew Message-ID: <20050505111457.GS30482@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , Patrick McHardy , Herbert Xu , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, "David S. Miller" References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> <4274F2ED.9080404@trash.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HM+R7/Jd0Fa6H3F" Content-Disposition: inline In-Reply-To: <4274F2ED.9080404@trash.net> User-Agent: mutt-ng 1.5.8-r168i (Debian) X-archive-position: 732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --+HM+R7/Jd0Fa6H3F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 01, 2005 at 05:17:01PM +0200, Patrick McHardy wrote: > You're right. I'm tempted to remove the entire nf_debug stuff, > as far as I know it has never found a real bug. But for now > I've only fixed the warning. yes, I second that change. At the same time, we should get rid of all the lockhelp.h stuff that makes the netfilter code use non-standard lock primitives. --=20 - Harald Welte http://netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --+HM+R7/Jd0Fa6H3F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCegAxXaXGVTD0i/8RAjw/AJ9gnJdmZW9GWXkPX+som+Fv9qDzxwCgqt1s EaDWEpEUHlSFNzkq0nAsxy8= =k6gh -----END PGP SIGNATURE----- --+HM+R7/Jd0Fa6H3F-- From laforge@netfilter.org Thu May 5 04:22:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 04:22:54 -0700 (PDT) Received: from ganesha.gnumonks.org (ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45BMp7J013820 for ; Thu, 5 May 2005 04:22:51 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DTeR9-0001Vw-Ep; Thu, 05 May 2005 13:22:35 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DTeR7-0003zX-AN; Thu, 05 May 2005 13:22:33 +0200 Date: Thu, 5 May 2005 13:22:33 +0200 From: Harald Welte To: cranium2003 Cc: net dev Subject: Re: Help getting Neighbour table overflow a lot messages Message-ID: <20050505112233.GT30482@sunbeam.de.gnumonks.org> References: <20050422103749.43324.qmail@web41403.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7+7T3ZdO12I8zLgo" Content-Disposition: inline In-Reply-To: <20050422103749.43324.qmail@web41403.mail.yahoo.com> User-Agent: mutt-ng 1.5.8-r168i (Debian) X-archive-position: 733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --7+7T3ZdO12I8zLgo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2005 at 03:37:48AM -0700, cranium2003 wrote: > inet addr:10.1.1.30 Bcast:10.255.255.255=20 so you have a /8 on your network interface? looks like a broken network setup to me. do you really have up to 16 million machine in one segment? Anyway, with this network setup you need to make sure that your linux box has got enough memory for accomodating up to 16 million neighbour table entries, and set the respective limits high enough so it can use all that memory... --=20 - Harald Welte http://netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --7+7T3ZdO12I8zLgo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCegH5XaXGVTD0i/8RAut/AJ4tELmFou72ZY6Vv4jA2xVL6pwkCwCggmth h9S5izQGR0DlN6Wm+eFEnk4= =EdSx -----END PGP SIGNATURE----- --7+7T3ZdO12I8zLgo-- From SRS0+953ed2a1813f9a823f68+620+infradead.org+hch@pentafluge.srs.infradead.org Thu May 5 04:37:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 04:37:54 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Bbo7J015213 for ; Thu, 5 May 2005 04:37:51 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DTefe-0002N0-HG; Thu, 05 May 2005 12:37:34 +0100 Date: Thu, 5 May 2005 12:37:34 +0100 From: Christoph Hellwig To: Mike Christie Cc: linux-kernel@vger.kernel.org, linux-scsi , netdev Subject: Re: [PATCH 3/3] add open iscsi netlink interface to iscsi transport class Message-ID: <20050505113734.GA8985@infradead.org> Mail-Followup-To: Christoph Hellwig , Mike Christie , linux-kernel@vger.kernel.org, linux-scsi , netdev References: <42798ADD.5070803@cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42798ADD.5070803@cs.wisc.edu> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev [Mike, can you please insert the patches inline? I hate needing to save attachment first to be able to comment on the patch] - * Copyright (C) Mike Christie, 2004 + * Copyright (C) Mike Christie, Dmitry Yusupov, Alex Aizman, 2004 - 2005 should probably be separate Copyright lines for everyone involved. +static struct iscsi_transport *transport_table[ISCSI_TRANSPORT_MAX]; please avoid static limits for the number of transports, e.g. use the lib/idr.c helpers. +static DECLARE_MUTEX(callsema); horrible name for a lock, even a static one. + +struct mempool_zone { + mempool_t *pool; + volatile int allocated; don't use volatile, either atomic_t or if it's properly locked just int + +#define Z_SIZE_REPLY NLMSG_SPACE(sizeof(struct iscsi_uevent)) +#define Z_MAX_REPLY 8 +#define Z_HIWAT_REPLY 6 + +#define Z_SIZE_PDU NLMSG_SPACE(sizeof(struct iscsi_uevent) + \ + sizeof(struct iscsi_hdr) + \ + DEFAULT_MAX_RECV_DATA_SEGMENT_LENGTH) +#define Z_MAX_PDU 8 +#define Z_HIWAT_PDU 6 + +#define Z_SIZE_ERROR NLMSG_SPACE(sizeof(struct iscsi_uevent)) +#define Z_MAX_ERROR 16 +#define Z_HIWAT_ERROR 12 At least the *_Z_SIZE defines are unneeded, just pass them to the functions directly. And please add some explanations for the MAX and HIWAT defines. +struct iscsi_if_cnx { + struct list_head item; /* item in cnxlist */ + struct list_head snxitem; /* item in snx->connections */ please rename cnx to conn and snx to session everywhere, keeps the code a lot more readable. + iscsi_cnx_t cnxh; + volatile int active; volatile usage again +#define H_TYPE_TRANS 1 +#define H_TYPE_HOST 2 +static struct iscsi_if_cnx* +iscsi_if_find_cnx(uint64_t key, int type) +{ + unsigned long flags; + struct iscsi_if_cnx *cnx; + + spin_lock_irqsave(&cnxlock, flags); + list_for_each_entry(cnx, &cnxlist, item) { + if ((type == H_TYPE_TRANS && cnx->cnxh == key) || + (type == H_TYPE_HOST && cnx->host == iscsi_ptr(key))) { + spin_unlock_irqrestore(&cnxlock, flags); + return cnx; + } + } + spin_unlock_irqrestore(&cnxlock, flags); + return NULL; } please use two separate helpers for transport/host instead of the H_TYPE thing. + list_del((void*)&skb->cb); please add some inline helpers for using skb->cb as list instead of spreading the casts all over. +static int zone_init(struct mempool_zone *zp, unsigned max, + unsigned size, unsigned hiwat) should probably become mempool_zone_init to match the other functions operating on struct mempool_zone. +static int +iscsi_if_destroy_snx(struct iscsi_transport *transport, struct iscsi_uevent *ev) +{ + struct Scsi_Host *shost; + struct iscsi_if_snx *snx; + unsigned long flags; + struct iscsi_if_cnx *cnx; + + shost = scsi_host_lookup(ev->u.d_session.sid); + if (shost == ERR_PTR(-ENXIO)) + return -EEXIST; + scsi_host_put(shost); you must keep the reference until you're done. + spin_unlock_irqrestore(&cnxlock, flags); + + scsi_remove_host(shost); + transport->destroy_session(ev->u.d_session.session_handle); can we please move the scsi_remove_host into the individual ->destroy_session methods? dito for the scsi_host_add +static int +iscsi_if_create_cnx(struct iscsi_transport *transport, struct iscsi_uevent *ev) +{ + struct iscsi_if_snx *snx; + struct Scsi_Host *shost; + struct iscsi_if_cnx *cnx; + unsigned long flags; + int error; + + shost = scsi_host_lookup(ev->u.c_cnx.sid); + if (shost == ERR_PTR(-ENXIO)) + return -EEXIST; + scsi_host_put(shost); again, please keep the reference until you're done. From herbert@gondor.apana.org.au Thu May 5 04:40:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 04:40:25 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45BeI7J015852 for ; Thu, 5 May 2005 04:40:19 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTehq-00056M-00; Thu, 05 May 2005 21:39:50 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTehn-0005gJ-00; Thu, 05 May 2005 21:39:47 +1000 From: Herbert Xu To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / ????) Subject: Re: [PATCH 2/3] add open iscsi netlink interface to iscsi transport class Cc: michaelc@cs.wisc.edu, linux-scsi@vger.kernel.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org Organization: Core In-Reply-To: <20050505.185503.78606493.yoshfuji@linux-ipv6.org> X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.netdev,apana.lists.os.linux.scsi User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 05 May 2005 21:39:47 +1000 X-archive-position: 735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev YOSHIFUJI Hideaki / ???? wrote: > In article <42798AC1.2010308@cs.wisc.edu> (at Wed, 04 May 2005 19:53:53 -0700), Mike Christie says: > >> +struct iscsi_uevent { > : >> +} __attribute__ ((aligned (sizeof(unsigned long)))); > > I think it'd be better to use sizeof(uint64_t) or something. Is there a benefit in aligning on 64-bit boundaries for 32-bit platforms? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu May 5 04:41:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 04:41:29 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45BfL7J016308 for ; Thu, 5 May 2005 04:41:22 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTeiz-00058C-00; Thu, 05 May 2005 21:41:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTeis-0005gu-00; Thu, 05 May 2005 21:40:54 +1000 From: Herbert Xu To: anton@samba.org (Anton Blanchard) Subject: Re: oops in ip_rcv Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <20050505101542.GB7916@krispykreme> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 05 May 2005 21:40:54 +1000 X-archive-position: 736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Anton Blanchard wrote: > > Im booting a recent 2.6.12-rc3++ git tree on ppc64. Just got an oops > very early in boot, right after: > > TCP established hash table entries: 131072 (order: 9, 2097kernel: > > It looks like we tried to load from address -1. > > c0000000003c515c ip_rcv+0x4c/0x6e0 Any idea why you'd be receiving packets this early? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ak@muc.de Thu May 5 04:43:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 04:43:48 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Bhj7J017122 for ; Thu, 5 May 2005 04:43:46 -0700 Received: (qmail 80255 invoked by uid 3709); 5 May 2005 11:43:27 -0000 Date: 5 May 2005 13:43:27 +0200 Date: Thu, 5 May 2005 13:43:27 +0200 From: Andi Kleen To: Peter Buckingham Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050505114327.GA51761@muc.de> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42791825.2080204@pantasys.com> User-Agent: Mutt/1.4.1i X-archive-position: 737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev > >IOMMU code on x86-64 should be never active unless Stephen > >used IOMMU_DEBUG or iommu=force. THat is because the tg3 > >is a 64bit capable device and should always use bypass. > > how is this detected? we have a board that is using a 32bit e1000 and we > have to use iommu=force otherwise it doesn't do the right thing with > > 4GB of RAM. "32bit e1000"? How did you get such a beast? AFAIK all e1000s are 64bit address capable. Please supply a full boot log without iommu=force and describe what happens exactly. -Andi From yoshfuji@linux-ipv6.org Thu May 5 04:53:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 04:53:09 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Br67J018256 for ; Thu, 5 May 2005 04:53:07 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8C1A633CC2; Thu, 5 May 2005 20:55:31 +0900 (JST) Date: Thu, 05 May 2005 20:55:30 +0900 (JST) Message-Id: <20050505.205530.107537707.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: michaelc@cs.wisc.edu, linux-scsi@vger.kernel.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2/3] add open iscsi netlink interface to iscsi transport class From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20050505.185503.78606493.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 738 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article (at Thu, 05 May 2005 21:39:47 +1000), Herbert Xu says: > YOSHIFUJI Hideaki / ???? wrote: > > In article <42798AC1.2010308@cs.wisc.edu> (at Wed, 04 May 2005 19:53:53 -0700), Mike Christie says: > > > >> +struct iscsi_uevent { > > : > >> +} __attribute__ ((aligned (sizeof(unsigned long)))); > > > > I think it'd be better to use sizeof(uint64_t) or something. > > Is there a benefit in aligning on 64-bit boundaries for 32-bit platforms? Well, this if for avoiding inconsistency between kernel and userspace. If you use unsigned long, sizeof(unsigned long) may be inconssitent between kernel and userland like this: kernel: sizeof(unsigned long) == 8 userspace: sizeof(unsigned long) == 4 --yoshfuji From webmaster@rapidforum.com Thu May 5 05:17:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 05:17:35 -0700 (PDT) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j45CHT7J020613 for ; Thu, 5 May 2005 05:17:30 -0700 Received: (qmail 10876 invoked by uid 1004); 5 May 2005 12:17:11 -0000 Received: from p549f136b.dip0.t-ipconnect.de (HELO ?84.159.19.107?) (Dragony@84.159.19.107) by www.rapidforum.com with SMTP; 5 May 2005 12:17:11 -0000 Message-ID: <427A0EAF.2050402@rapidforum.com> Date: Thu, 05 May 2005 14:16:47 +0200 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: MultiPath Routing Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 739 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Hello. Since this seems to be an undocumented feature.... How is this equal-cost multipath supposed to work? I just want to send outgoing traffic over two gateways. I tried this: ip route replace default scope global nexthop via 192.168.0.1 dev eth1 weight 100 nexthop via 192.168.0.100 dev eth1 weight 100 It it doesnt work. It always uses the last for all download-users (around a few hundreds) Or is this the wrong way? (2.6.12rc3) Best regards, Chris From willy@www.linux.org.uk Thu May 5 05:21:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 05:21:58 -0700 (PDT) Received: from parcelfarce.linux.theplanet.co.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45CLo7J021269 for ; Thu, 5 May 2005 05:21:53 -0700 Received: from willy by parcelfarce.linux.theplanet.co.uk with local (Exim 4.43) id 1DTfMj-0002YX-5B; Thu, 05 May 2005 13:22:05 +0100 Date: Thu, 5 May 2005 13:22:04 +0100 From: Matthew Wilcox To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: michaelc@cs.wisc.edu, linux-scsi@vger.kernel.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] add open iscsi netlink interface to iscsi transport class Message-ID: <20050505122204.GL19678@parcelfarce.linux.theplanet.co.uk> References: <42798AC1.2010308@cs.wisc.edu> <20050505.185503.78606493.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505.185503.78606493.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.4.1i X-archive-position: 740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: netdev On Thu, May 05, 2005 at 06:55:03PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > In article <42798AC1.2010308@cs.wisc.edu> (at Wed, 04 May 2005 19:53:53 -0700), Mike Christie says: > > > +struct iscsi_uevent { > : > > +} __attribute__ ((aligned (sizeof(unsigned long)))); > > I think it'd be better to use sizeof(uint64_t) or something. Actually, it's completely unnecessary. iscsi_uevent contains a uint64_t element, and the GCC docs (in the 'Type attribute' section, documenting aligned) say: Note that the alignment of any given `struct' or `union' type is required by the ISO C standard to be at least a perfect multiple of the lowest common multiple of the alignments of all of the members of the `struct' or `union' in question. This means that you _can_ So best to just delete it. It has no effect. > Please check other spots, too. e.g.: > > > + struct iscsi_stats_custom custom[0] > > + __attribute__ ((aligned (sizeof(unsigned long)))); This one's probably useless too, but it's hard to tell since the patches weren't sent inline thus making them difficult to cross-reference. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain From herbert@gondor.apana.org.au Thu May 5 05:37:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 05:37:30 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45CbM7J022936 for ; Thu, 5 May 2005 05:37:23 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTfbA-0005XF-00; Thu, 05 May 2005 22:37:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTfb8-0005lI-00; Thu, 05 May 2005 22:36:58 +1000 From: Herbert Xu To: webmaster@rapidforum.com (Christian Schmid) Subject: Re: MultiPath Routing Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <427A0EAF.2050402@rapidforum.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 05 May 2005 22:36:58 +1000 X-archive-position: 741 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Christian Schmid wrote: > > Since this seems to be an undocumented feature.... How is this equal-cost multipath supposed to > work? I just want to send outgoing traffic over two gateways. I tried this: > > ip route replace default scope global nexthop via 192.168.0.1 dev eth1 weight 100 nexthop via > 192.168.0.100 dev eth1 weight 100 > > It it doesnt work. It always uses the last for all download-users (around a few hundreds) Did you enable IP_ROUTE_MULTIPATH_CACHED? If so please disable it since it breaks multipath routing for forwarded traffic. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Thu May 5 05:42:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 05:42:39 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Cga7J023835 for ; Thu, 5 May 2005 05:42:36 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DTfgM-0007Ut-CQ for netdev@oss.sgi.com; Thu, 05 May 2005 08:42:22 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTfgK-00017M-2y; Thu, 05 May 2005 08:42:20 -0400 Subject: Re: [RFC] textsearch infrastructure + skb_find_text() From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com, Pablo Neira In-Reply-To: <20050504234036.GH18452@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Thu, 05 May 2005 08:42:17 -0400 Message-Id: <1115296937.7680.52.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 742 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Thu, 2005-05-05 at 01:40 +0200, Thomas Graf wrote: > The patch below is a report on the current state of the textsearch > infrastructure and its first user skb_find_text(). The textsearch > is kept as simple as possible but advanced enough to handle non-linear > data such as skb fragments. Unlike in many other approaches the text > input is not seen as a single pointer but rather as a continuously > called callback get_text() until 0 is returned allowing to search > on any kind of data and to implement customized from-to limits. > How is this different from libqsearch? IIRC, it also kept pointers and callbacks. BTW, I hope theres sync with libqsearch - at least some canibalization of ideas. Also hopefully, pluggin of ne algorithms is trivial (e.g boyer-moore could be included in addition to kmp etc) > The patch is separated into 3 parts, the first one being the textsearch > infrastructure itself followed by a simple Knuth-Morris-Pratt > implementation for reference. I'm also working on what could be called > the smallest regular expression implementation ever but I left that > out for now since it still has issues. Last but not least the > function skb_find_text() written in a hurry and probably not yet > correct but you should get the idea. From a userspace perspective > the first user will be an ematch but writing it will be peanuts > so I left it out for now. > nice > Basically what it looks like right now is: > > int pos; > struct ts_state; > struct ts_config *conf = textsearch_prepare("kmp", "hanky", 5, GFP_KERNEL, 1); > > /* search for "hanky" at offset 20 until end of packet */ > for (pos = skb_find_text(skb, 20, INT_MAX, conf, &state; > pos >= 0; > pos = textsearch_next(conf, &state)) { > printk("Need a hanky? I found one at offset %d.\n", pos); > } > I have a lot of questions: - does a string have to be terminated by \0? - do you keep state of the string from the begining? ex: how do you know that preceeding "hanky" was "Need a"? - all sorts of limits: how long is the string? etc - what happens if a string spans multiple skbs or even multiple fragments? > textsearch_put(conf); > kfree(conf); > > You might wonder about the 1 given to _prepare(), it indicates whether > to autoload modules because the ematches will need it to be able to drop > rtnl sem. > do you really wanna leave that decision upto the user? > The code is not tested and cerainly not bug free yet but should compile. > > Thoughts? I dont have time to look at the patch to sufficiently critique it, but it looks like a good start - maybe this weekend. It would be nice to have other utilities which could be loaded eg; case compare, regualr expressions, strchr after you match, etc Of course all this to be followed by actions such as strok etc. Probably all this is a layer above this - but essentially when you are doing this keep the desire to do this in mind. cheers, jamal From hadi@cyberus.ca Thu May 5 05:49:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 05:49:56 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Cnm7J024803 for ; Thu, 5 May 2005 05:49:51 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DTfnL-0004Bv-Up for netdev@oss.sgi.com; Thu, 05 May 2005 08:49:35 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTfnI-0002EK-56; Thu, 05 May 2005 08:49:32 -0400 Subject: Re: (diet-)FIB alternative fib_hlist.c From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: Robert Olsson , Jens.Laas@data.slu.se, netdev@oss.sgi.com In-Reply-To: References: <17016.62444.34282.625407@robur.slu.se> Content-Type: text/plain Organization: unknown Date: Thu, 05 May 2005 08:49:29 -0400 Message-Id: <1115297370.7680.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 20:39 +0200, Andi Kleen wrote: > Robert Olsson writes: > > > Hello! > > > > fib_hlist is the smallest and simpliest routing algo we could think of > > it's just a sorted (h)list. > > > > routing (FIB lookup) performance. dst hash is not used. > > > > fib_hlist fib_hash test routing table size > > ----------------------------------------------------- > > 444 kpps 433 kpps Single flow. local=19/main=5 entries > > 433 kpps 431 kpps rDoS. local=19/main=5 > > 0.2 kpps 198 kpps rDoS local=19/main=123946 > > > Great patch! I wanted to do something like this for a long time :/ > It is a good solution for 99.999% of all users who never have more > than a few routes. > Great patch it is - but why do you say "99.999% of all users" feel they would love this? Clearly perfomance at the low routes area is not something that is a huge difference against standard fib. And you suffer miserably at latge route size. Is it memory consumption you are thinking of? cheers, jamal From hadi@cyberus.ca Thu May 5 06:06:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 06:06:59 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45D6u7J026762 for ; Thu, 5 May 2005 06:06:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DTg3w-0006Hx-5k for netdev@oss.sgi.com; Thu, 05 May 2005 09:06:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTg3t-00056m-Ce; Thu, 05 May 2005 09:06:41 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050504145341.GG18452@postel.suug.ch> References: <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> <20050504134815.GD18452@postel.suug.ch> <1115214782.7665.184.camel@localhost.localdomain> <20050504140540.GE18452@postel.suug.ch> <1115216629.7906.4.camel@localhost.localdomain> <20050504145341.GG18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Thu, 05 May 2005 09:06:39 -0400 Message-Id: <1115298399.7680.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 16:53 +0200, Thomas Graf wrote: > * jamal <1115216629.7906.4.camel@localhost.localdomain> 2005-05-04 10:23 > > Agreed. So shall we stick then to just make it a global-only? > > As long as we can't find a way to have a well defined local > scope which is both easy to implement and easy to understand > for the user a global-only scope with the ability for the user > to reset the value via the meta action is most reasonable to me. ok - i will wait to see the patches from Patrick out first then do this. Its actually a simple change. cheers, jamal From hadi@cyberus.ca Thu May 5 06:04:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 06:05:03 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45D4u7J026352 for ; Thu, 5 May 2005 06:04:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DTg1s-0007w1-Cx for netdev@oss.sgi.com; Thu, 05 May 2005 07:04:36 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTg1o-0004jS-JN; Thu, 05 May 2005 09:04:32 -0400 Subject: Re: [patch/RFC]: Asynchronous IPsec processing benchmark. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: Herbert Xu , netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" In-Reply-To: <20050504201143.7f6bdcce@zanzibar.2ka.mipt.ru> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@gondor.apana.org.au> <1115117728.3414.48.camel@uganda> <1115127507.3414.58.camel@uganda> <1115203214.7665.58.camel@localhost.localdomain> <20050504201143.7f6bdcce@zanzibar.2ka.mipt.ru> Content-Type: text/plain Organization: unknown Date: Thu, 05 May 2005 09:04:29 -0400 Message-Id: <1115298270.7680.65.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 20:11 +0400, Evgeniy Polyakov wrote: > On Wed, 04 May 2005 06:40:14 -0400 > jamal wrote: > > > On Tue, 2005-03-05 at 17:38 +0400, Evgeniy Polyakov wrote: > > > Here are some numbers: > > > > > > ./netperf -l 60 -H gw -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 > > > -S 57344 > > > > > > TCP STREAM TEST to gw : +/-2.5% @ 99% conf. > > > > > > async-ipsec, 10^6bits/sec: 35.42 > > > sync-ipsec, 10^6bits/sec: 37.11 > > > > > > So even with existing timer deferring it is not noticebly slower [about > > > 4%]. > > > > > > > by "sync" i hope you mean the original code without your change? > > Yes, it is vanilla 2.6.12-rc2 kernel with native IPsec. > Very nice numbers then - considering the async was at least delaying things by at least a jiffie. > > The one thing i see in your POC code that may affect numbers a bit is > > allocation of struct esp_async every time in the path. Perhaps precreate > > a pool of those and then just grab/return to/fro pool; > > That could be skb too - since both skb/kmalloc > atomic allocations end up in kmem_cache_alloc(). The skb is a little tricky in particular if you allocate in one CPU and free on another. If this could happen with the esp_async struct as well then it is not worth it. > > > BTW, you may need to incr ref counter of x pre-callback and decrement > > when done in callback. > > It looks like dst entry holding is enough since > direct dst->output(), i.e. xfrm_state->output(), > call itself is not protected by reference counter, > but dst entry is being held during that call. > makes sense. cheers, jamal From anton@ozlabs.org Thu May 5 06:14:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 06:14:33 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45DEU7J027764 for ; Thu, 5 May 2005 06:14:31 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id EEB9367A6B; Thu, 5 May 2005 23:14:14 +1000 (EST) Date: Thu, 5 May 2005 23:09:04 +1000 From: Anton Blanchard To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: oops in ip_rcv Message-ID: <20050505130904.GA16593@krispykreme> References: <20050505101542.GB7916@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-archive-position: 746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev > Any idea why you'd be receiving packets this early? Not sure, although PCI has already been probed and tcp_init is called with interrupts on. Any reason we cant take a packet at this point? Im guessing its calling this: IP_INC_STATS_BH(IPSTATS_MIB_INRECEIVES); Which we dont initialise until later on in init_ipv4_mibs. Anton From hadi@cyberus.ca Thu May 5 06:14:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 06:15:01 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45DEv7J027928 for ; Thu, 5 May 2005 06:14:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DTgBf-00009k-5l for netdev@oss.sgi.com; Thu, 05 May 2005 09:14:43 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTgBb-0006NO-4N; Thu, 05 May 2005 09:14:39 -0400 Subject: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" , Herbert Xu Cc: netdev Content-Type: multipart/mixed; boundary="=-TNOxsxazJoDnCipOTrB4" Organization: unknown Date: Thu, 05 May 2005 09:14:36 -0400 Message-Id: <1115298877.7680.75.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev --=-TNOxsxazJoDnCipOTrB4 Content-Type: text/plain Content-Transfer-Encoding: 7bit I dont think we reached any agreement last time, Herbert - so here is a resend. A rule is unique by both selector(which it was already and this patch doesnt change) and index which could be user specified(new) . I spent at least 30 minutes testing it and infact captured some of my testcases at the last minutes - also attached. cheers, jamal --=-TNOxsxazJoDnCipOTrB4 Content-Disposition: attachment; filename=polid_p5 Content-Type: text/plain; name=polid_p5; charset=UTF-8 Content-Transfer-Encoding: 7bit --- a/include/net/xfrm.h 2005/04/28 14:05:00 1.1 +++ b/include/net/xfrm.h 2005/04/28 14:05:48 @@ -302,6 +302,7 @@ struct dst_entry *bundles; __u16 family; __u8 action; + __u8 dir; __u8 flags; __u8 dead; __u8 xfrm_nr; --- a/net/xfrm/xfrm_user.c 2005/04/28 13:59:27 1.1 +++ b/net/xfrm/xfrm_user.c 2005/04/28 14:01:58 @@ -653,6 +653,7 @@ memcpy(&xp->selector, &p->sel, sizeof(xp->selector)); memcpy(&xp->lft, &p->lft, sizeof(xp->lft)); xp->action = p->action; + xp->dir = p->dir; xp->flags = p->flags; xp->family = p->sel.family; /* XXX xp->share = p->share; */ --- a/net/xfrm/xfrm_policy.c 2005/04/27 11:32:13 1.1 +++ b/net/xfrm/xfrm_policy.c 2005/04/29 23:07:38 @@ -163,7 +163,7 @@ if (xp->dead) goto out; - dir = xp->index & 7; + dir = xp->dir; if (xp->lft.hard_add_expires_seconds) { long tmo = xp->lft.hard_add_expires_seconds + @@ -341,17 +341,35 @@ { struct xfrm_policy *pol, **p; struct xfrm_policy *delpol = NULL; + struct xfrm_policy *delpol2 = NULL; + struct xfrm_policy *delp = NULL; struct xfrm_policy **newpos = NULL; + int ret = -EINVAL; + + if (policy->index) + delpol = xfrm_policy_byid(dir, policy->index, 0); + delpol2 = xfrm_policy_bysel(dir, &policy->selector, 0); + + /* must be unique in both index and selector */ + if (delpol && delpol2) + if (delpol != delpol2) + goto pol_err; + if (delpol) + delp = delpol; + else + delp = delpol2; + + if (delp && excl) { + ret = -EEXIST; + goto pol_err; + } + + /* insert, sorted by prio*/ write_lock_bh(&xfrm_policy_lock); for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL;) { - if (!delpol && memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0) { - if (excl) { - write_unlock_bh(&xfrm_policy_lock); - return -EEXIST; - } + if (pol == delp) { *p = pol->next; - delpol = pol; if (policy->priority > pol->priority) continue; } else if (policy->priority >= pol->priority) { @@ -360,27 +378,36 @@ } if (!newpos) newpos = p; - if (delpol) - break; p = &pol->next; } + if (newpos) p = newpos; + xfrm_pol_hold(policy); policy->next = *p; *p = policy; atomic_inc(&flow_cache_genid); - policy->index = delpol ? delpol->index : xfrm_gen_index(dir); + if (!policy->index) + policy->index = delp ? delp->index : xfrm_gen_index(dir); + policy->curlft.add_time = (unsigned long)xtime.tv_sec; policy->curlft.use_time = 0; if (!mod_timer(&policy->timer, jiffies + HZ)) xfrm_pol_hold(policy); write_unlock_bh(&xfrm_policy_lock); - if (delpol) { - xfrm_policy_kill(delpol); + if (delp) { + xfrm_policy_kill(delp); } - return 0; + ret = 0; + +pol_err: + if (delpol) + xfrm_pol_put(delpol); + if (delpol2) + xfrm_pol_put(delpol2); + return ret; } EXPORT_SYMBOL(xfrm_policy_insert); @@ -413,7 +440,7 @@ struct xfrm_policy *pol, **p; write_lock_bh(&xfrm_policy_lock); - for (p = &xfrm_policy_list[id & 7]; (pol=*p)!=NULL; p = &pol->next) { + for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL; p = &pol->next) { if (pol->index == id) { xfrm_pol_hold(pol); if (delete) --=-TNOxsxazJoDnCipOTrB4 Content-Disposition: attachment; filename=ipsec-spd-priotst Content-Type: text/plain; name=ipsec-spd-priotst; charset=UTF-8 Content-Transfer-Encoding: 7bit IP=./root/iproute-mod/ip/ip root@jzny2: $IP x p flush root@jzny2: $IP -s x p ls root@jzny2: $IP x policy add dir in index 1 priority 10 src 12.0.0.10/24 dst 12.0.0.2/24 root@jzny2: $IP x policy add dir in index 2 priority 100 src 11.0.0.10/24 dst 12.0.0.2/24 root@jzny2: $IP x policy add dir in index 4 priority 200 src 11.0.0.10/24 dst 11.0.0.2/24 root@jzny2: $IP x policy add dir in index 5 priority 400 src 13.0.0.10/24 dst 11.0.0.2/24 root@jzny2: $IP -s x p ls src 12.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 1 priority 10 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 5 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - root@jzny2: $IP x policy update dir in priority 120 src 12.0.0.10/24 dst 12.0.0.2/24 root@jzny2: $IP -s x p ls src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 12.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 1 priority 120 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 5 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - root@jzny2: $IP x policy update dir in priority 220 src 12.0.0.10/24 dst 12.0.0.2/24 root@jzny2: $IP -s x p ls src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 12.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 1 priority 220 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:55 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 5 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - root@jzny2: $IP x policy update dir in priority 420 src 12.0.0.10/24 dst 12.0.0.2/24 root@jzny2: $IP -s x p ls src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 5 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 12.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 1 priority 420 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:55 use - root@jzny2: $IP x policy update dir in priority 20 src 12.0.0.10/24 dst 12.0.0.2/24 root@jzny2: $IP -s x p ls src 12.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 1 priority 20 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:55 use - src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 5 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - root@jzny2: $IP x policy add dir in priority 30 src 13.0.0.10/24 dst 11.0.0.2/24 RTNETLINK answers: File exists root@jzny2: $IP -s x p ls src 12.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 1 priority 20 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:55 use - src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 5 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - root@jzny2: $IP x policy update dir in priority 700 src 12.0.0.10/24 dst 12.0.0.2/24 root@jzny2: $IP -s x p ls src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 5 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:54 use - src 12.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 1 priority 700 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:56 use - root@jzny2: $IP x p flush root@jzny2: $IP -s x p ls root@jzny2: $IP x policy add dir in index 1 priority 10 src 12.0.0.10/24 dst 12.0.0.2/24 root@jzny2: $IP x policy add dir in index 2 priority 100 src 11.0.0.10/24 dst 12.0.0.2/24 root@jzny2: $IP x policy add dir in index 3 priority 200 src 11.0.0.10/24 dst 11.0.0.2/24 root@jzny2: $IP x policy add dir in index 4 priority 400 src 13.0.0.10/24 dst 11.0.0.2/24 root@jzny2: $IP -s x p ls src 12.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 1 priority 10 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 3 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - root@jzny2: $IP x policy update dir in priority 120 index 1 root@jzny2: $IP -s x p ls src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 0.0.0.0/0 dst 0.0.0.0/0 uid 0 dir in action allow index 1 priority 120 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use 2005-04-29 22:16:59 src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 3 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - root@jzny2: $IP x policy update dir in priority 220 index 1 root@jzny2: $IP -s x p ls src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 3 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 0.0.0.0/0 dst 0.0.0.0/0 uid 0 dir in action allow index 1 priority 220 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:17:00 use 2005-04-29 22:17:00 src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - root@jzny2: $IP x policy update dir in priority 420 index 1 root@jzny2: $IP -s x p ls src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 3 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 0.0.0.0/0 dst 0.0.0.0/0 uid 0 dir in action allow index 1 priority 420 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:17:00 use 2005-04-29 22:17:00 root@jzny2: $IP x policy update dir in priority 20 index 1 root@jzny2: $IP -s x p ls src 0.0.0.0/0 dst 0.0.0.0/0 uid 0 dir in action allow index 1 priority 20 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:17:01 use 2005-04-29 22:17:01 src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 3 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - root@jzny2: $IP x policy add dir in priority 30 index 4 RTNETLINK answers: Invalid argument root@jzny2: $IP -s x p ls src 0.0.0.0/0 dst 0.0.0.0/0 uid 0 dir in action allow index 1 priority 20 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:17:01 use 2005-04-29 22:17:01 src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 3 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - root@jzny2: $IP x policy update dir in priority 700 index 1 root@jzny2: $IP -s x p ls src 11.0.0.10/24 dst 12.0.0.2/24 uid 0 dir in action allow index 2 priority 100 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 11.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 3 priority 200 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 13.0.0.10/24 dst 11.0.0.2/24 uid 0 dir in action allow index 4 priority 400 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:16:59 use - src 0.0.0.0/0 dst 0.0.0.0/0 uid 0 dir in action allow index 1 priority 700 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-29 22:17:02 use 2005-04-29 22:17:02 --=-TNOxsxazJoDnCipOTrB4-- From marcel@holtmann.org Thu May 5 06:28:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 06:28:39 -0700 (PDT) Received: from mail.holtmann.net (coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45DSX7J029175 for ; Thu, 5 May 2005 06:28:34 -0700 Received: from pegasus (p5487E5D5.dip.t-dialin.net [84.135.229.213]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j45DTNWX003812 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 15:29:23 +0200 Subject: Re: [2.6 patch] net/bluetooth/: possible cleanups From: Marcel Holtmann To: Adrian Bunk Cc: marcel@holtmann.or.sgi.com, maxk@qualcomm.com, bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20050505002310.GF3593@stusta.de> References: <20050505002310.GF3593@stusta.de> Content-Type: text/plain Date: Thu, 05 May 2005 15:28:30 +0200 Message-Id: <1115299710.8496.168.camel@pegasus> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 Content-Transfer-Encoding: 7bit X-archive-position: 748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Hi Adrian, > This patch contains the following possible cleanups: > - #ifdef HCI_DATA_DUMP the following function: > lib.c: bt_dump > - #if 0 the following unused global functions: > - hci_core.c: hci_suspend_dev > - hci_core.c: hci_resume_dev > - remove the following unneeded EXPORT_SYMBOL's: > - hci_core.c: hci_dev_get > - hci_core.c: hci_send_cmd > - hci_event.c: hci_si_event > > Please review which of these changes do make sense and which conflict > with pending patches. I like to let hci_suspend_dev() and hci_resume_dev() stay for now. No driver uses it, but actually nobody really looked deep enough to really understand the needs for suspend of Bluetooth devices. The hci_dev_get(), hci_send_cmd() and hci_si_event() doesn't need to be exported. And I think that the bt_dump() and and BT_DMP() stuff can be removed completely. Please redo the patch and actually it is enough to copy the bluez-devel mailing list. I will take care of getting it back into mainline. Regards Marcel From tgraf@suug.ch Thu May 5 07:12:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 07:12:37 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45ECO7J032589 for ; Thu, 5 May 2005 07:12:24 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 148001C0EB; Thu, 5 May 2005 16:12:23 +0200 (CEST) Date: Thu, 5 May 2005 16:12:22 +0200 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, Pablo Neira Subject: Re: [RFC] textsearch infrastructure + skb_find_text() Message-ID: <20050505141222.GA25977@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> <1115296937.7680.52.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115296937.7680.52.camel@localhost.localdomain> X-archive-position: 749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115296937.7680.52.camel@localhost.localdomain> 2005-05-05 08:42 > How is this different from libqsearch? IIRC, it also kept pointers and > callbacks. The main difference is that my infrastructure is much simpler. > BTW, I hope theres sync with libqsearch - at least some canibalization > of ideas. I read the libqsearch code but fixing up all the issues required for my use would have taken up more time than writing up something new. > Also hopefully, pluggin of ne algorithms is trivial (e.g boyer-moore > could be included in addition to kmp etc) Very simple, ts_kmp.c is 108 lines whereas simple.c in libqsearch is over 500. > I have a lot of questions: > - does a string have to be terminated by \0? All strings are length terminated. > - do you keep state of the string from the begining? ex: how do you know > that preceeding "hanky" was "Need a"? I store the shift of a match in struct ts_state, add the length of the pattern in the call to textsearch_next() and provide this shift as offset to the get_text() callback. > - all sorts of limits: how long is the string? etc Both the length of a pattern and the length of a text block is limited by INT_MAX. However, since there can be an arbitary number of blocks there is no limit in the text length. Depending on the search algorithm there might be more limits, for example kmp uses unsigned int for each prefix table entry so this limits the length of the pattern as well (theoretically). > - what happens if a string spans multiple skbs or even multiple > fragments? This was the single most important requirement. Actually you can compose the text out of anything. I already wrote some code to handle paged skbs and multiple skbs can be implemented the same way. You could for example store a ts_state per conntrack and call textsearch_next continuously until you find a match. Would require some magic in the get_text() but shouldn't be too hard. > > > You might wonder about the 1 given to _prepare(), it indicates whether > > to autoload modules because the ematches will need it to be able to drop > > rtnl sem. > > > > do you really wanna leave that decision upto the user? We have to, otherwise we can't use it in ematches without the risk of deadlocks. There is no way around than have the caller drop its locks and call prepare again with no locks held, at least I'm not aware of one. > It would be nice to have other utilities which could be loaded eg; case > compare, regualr expressions, strchr after you match, etc Indeed, I'm working on the regular expression thing but it has some issues with textsearch_next() for patterns like .+abc.+ which I want to resolve first. From shemminger@osdl.org Thu May 5 09:20:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 09:21:01 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45GKu7J010897 for ; Thu, 5 May 2005 09:20:57 -0700 Received: from [192.168.0.101] (063-170-215-071.dslnorthwest.net [63.170.215.71]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j45GKWU3029315 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 09:20:33 -0700 Message-ID: <427A47C9.6040302@osdl.org> Date: Thu, 05 May 2005 09:20:25 -0700 From: Stephen Hemminger User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Peter Buckingham , "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> In-Reply-To: <20050505114327.GA51761@muc.de> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Andi Kleen wrote: >>>IOMMU code on x86-64 should be never active unless Stephen >>>used IOMMU_DEBUG or iommu=force. THat is because the tg3 >>>is a 64bit capable device and should always use bypass. >>> >>> >>how is this detected? we have a board that is using a 32bit e1000 and we >>have to use iommu=force otherwise it doesn't do the right thing with > >>4GB of RAM. >> >> > >"32bit e1000"? How did you get such a beast? AFAIK all e1000s are 64bit >address capable. Please supply a full boot log without iommu=force >and describe what happens exactly. > > One of the osdl e1000's in the lab is an IBM rebranded card that although it uses a 64bit slot, is really only 32bit From m.iatrou@freemail.gr Thu May 5 09:31:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 09:32:01 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j45GVr7J011796 for ; Thu, 5 May 2005 09:31:53 -0700 Received: (qmail 28170 invoked by uid 111); 5 May 2005 16:31:33 -0000 Received: from 150.140.129.29 by nic.upatras.gr (envelope-from , uid 103) with qmail-scanner-1.25 (clamdscan: 0.83/706. Clear:RC:1(150.140.129.29):. Processed in 0.117151 secs); 05 May 2005 16:31:33 -0000 Received: from patreas.upatras.gr (150.140.129.29) by nic.upatras.gr with SMTP; 5 May 2005 16:31:33 -0000 Received: (qmail 17049 invoked from network); 5 May 2005 16:31:32 -0000 Received: from upnet-dialupb-129.upnet.gr ([150.140.131.129]) (envelope-sender ) by patreas.upatras.gr (qmail-ldap-1.03) with SMTP for ; 5 May 2005 16:31:32 -0000 From: Michael Iatrou To: netdev@oss.sgi.com Subject: e1000 (?) jumbo frames performance issue Date: Thu, 5 May 2005 19:28:32 +0300 User-Agent: KMail/1.8 MIME-Version: 1.0 Message-Id: <200505051928.32496.m.iatrou@freemail.gr> Content-Type: Multipart/Mixed; boundary="Boundary-00=_wmkeCiRh5V4XVuz" X-archive-position: 751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: m.iatrou@freemail.gr Precedence: bulk X-list: netdev --Boundary-00=_wmkeCiRh5V4XVuz Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I did several benchmarks using Intel e1000 NIC and it seems there is a network throughput problem for MTU > 12000 (e1000 supports up to 16110 MTU). Configuration: Two identical PCs, connected back to back, Intel Xeon 2.8GHz (SMP/SMT disabled), 512MB RAM, e1000 (82546EB) Linux 2.6.11.7 netperf 2.3pl1 http://members.hellug.gr/iatrou/plain_ip_mtu.png http://members.hellug.gr/iatrou/plain_ip_mtu.dat -- Michael Iatrou Electrical and Computer Engineering Dept. University of Patras, Greece --Boundary-00=_wmkeCiRh5V4XVuz Content-Type: text/plain; charset="iso-8859-7"; name="plain_ip_mtu.dat" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="plain_ip_mtu.dat" 1500 936.14 1550 938.45 1600 927.26 1650 943.06 1700 942.91 1750 943.94 1800 947.95 1850 945.14 1900 952.91 1950 948.15 2000 948.55 2050 949.63 2100 953.98 2150 958.59 2200 959.39 2250 959.48 2300 960.57 2350 960.78 2400 953.26 2450 956.50 2500 964.36 2550 961.98 2600 964.61 2650 963.79 2700 966.36 2750 967.56 2800 968.12 2850 963.65 2900 969.22 2950 968.97 3000 967.69 3050 968.75 3100 970.95 3150 967.95 3200 972.19 3250 972.61 3300 973.01 3350 973.41 3400 973.78 3450 974.15 3500 974.52 3550 974.88 3600 975.23 3650 975.56 3700 975.89 3750 976.20 3800 976.52 3850 976.82 3900 977.11 3950 977.39 4000 977.68 4050 977.95 4100 978.23 4150 978.48 4200 978.74 4250 978.97 4300 979.21 4350 979.46 4400 979.68 4450 979.91 4500 980.13 4550 980.36 4600 980.58 4650 980.77 4700 980.97 4750 981.17 4800 981.37 4850 981.56 4900 981.75 4950 981.92 5000 982.10 5050 982.28 5100 982.47 5150 982.61 5200 982.78 5250 982.96 5300 983.11 5350 983.27 5400 983.43 5450 983.58 5500 983.71 5550 983.87 5600 984.01 5650 984.15 5700 984.27 5750 984.42 5800 984.55 5850 984.67 5900 984.83 5950 984.94 6000 985.06 6050 985.21 6100 985.29 6150 985.43 6200 985.54 6250 985.66 6300 985.79 6350 985.91 6400 986.03 6450 986.13 6500 986.23 6550 986.34 6600 986.44 6650 986.55 6700 986.65 6750 986.75 6800 986.83 6850 986.95 6900 987.04 6950 987.13 7000 987.22 7050 987.31 7100 987.40 7150 987.48 7200 987.57 7250 987.66 7300 987.74 7350 987.81 7400 987.89 7450 987.98 7500 987.74 7550 987.81 7600 987.20 7650 987.58 7700 986.59 7750 985.17 7800 985.46 7850 983.50 7900 983.88 7950 982.86 8000 953.35 8050 952.76 8100 947.34 8150 947.85 8200 942.18 8250 989.13 8300 989.21 8350 989.27 8400 989.33 8450 989.40 8500 989.47 8550 989.52 8600 989.58 8650 989.64 8700 989.71 8750 989.76 8800 989.82 8850 989.88 8900 989.93 8950 989.99 9000 990.04 9050 990.10 9100 990.16 9150 990.21 9200 990.26 9250 990.31 9300 990.37 9350 990.41 9400 990.47 9450 990.51 9500 990.57 9550 990.61 9600 990.66 9650 990.70 9700 990.76 9750 990.81 9800 990.86 9850 990.89 9900 990.94 9950 990.98 10000 991.04 10050 991.08 10100 991.12 10150 991.17 10200 991.21 10250 991.23 10300 991.30 10350 991.34 10400 991.38 10450 991.43 10500 991.46 10550 991.50 10600 991.55 10650 991.58 10700 991.63 10750 991.67 10800 991.70 10850 991.74 10900 991.78 10950 991.81 11000 991.86 11050 991.89 11100 991.92 11150 991.97 11200 992.00 11250 992.03 11300 992.07 11350 992.11 11400 992.13 11450 992.17 11500 992.21 11550 992.23 11600 992.16 11650 992.12 11700 991.89 11750 991.62 11800 991.79 11850 991.50 11900 991.77 11950 990.46 12000 990.52 12050 989.66 12100 968.77 12150 967.79 12200 970.55 12250 955.71 12300 952.36 12350 947.52 12400 945.08 12450 946.48 12500 944.09 12550 945.16 12600 942.07 12650 940.04 12700 938.17 12750 936.29 12800 933.29 12850 930.13 12900 927.75 12950 925.10 13000 924.25 13050 922.31 13100 917.67 13150 915.92 13200 913.99 13250 912.00 13300 908.68 13350 905.72 13400 904.99 13450 903.24 13500 900.91 13550 898.57 13600 897.07 13650 895.17 13700 892.79 13750 890.03 13800 888.41 13850 887.29 13900 886.30 13950 884.43 14000 882.25 14050 880.46 14100 878.22 14150 876.24 14200 875.41 14250 872.58 14300 873.01 14350 870.16 14400 868.45 14450 866.98 14500 864.76 14550 863.05 14600 862.22 14650 860.05 14700 858.71 14750 857.23 14800 856.31 14850 854.37 14900 851.15 14950 849.92 15000 849.54 15050 848.40 15100 847.32 15150 845.17 15200 844.45 15250 842.98 15300 841.14 15350 839.62 15400 838.34 15450 837.14 15500 836.43 15550 834.64 15600 833.64 15650 832.08 15700 830.72 15750 829.29 15800 828.07 15850 826.93 15900 825.75 15950 825.10 16000 823.32 16050 822.36 16100 819.77 --Boundary-00=_wmkeCiRh5V4XVuz-- From pablo@eurodev.net Thu May 5 10:02:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 10:02:10 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45H257J014264 for ; Thu, 5 May 2005 10:02:06 -0700 Received: from [85.136.116.114] by smtp06.retemail.es (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050505170148.LBPL26907.smtp06.retemail.es@[85.136.116.114]>; Thu, 5 May 2005 19:01:48 +0200 Message-ID: <427A51A2.8090600@eurodev.net> Date: Thu, 05 May 2005 19:02:26 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: netdev@oss.sgi.com, jamal Subject: Re: [RFC] textsearch infrastructure + skb_find_text() References: <20050504234036.GH18452@postel.suug.ch> In-Reply-To: <20050504234036.GH18452@postel.suug.ch> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Hi Thomas, Thomas Graf wrote: > The patch is separated into 3 parts, the first one being the textsearch > infrastructure itself followed by a simple Knuth-Morris-Pratt > implementation for reference. I'm also working on what could be called > the smallest regular expression implementation ever but I left that > out for now since it still has issues. Last but not least the > function skb_find_text() written in a hurry and probably not yet > correct but you should get the idea. From a userspace perspective > the first user will be an ematch but writing it will be peanuts > so I left it out for now. > > Basically what it looks like right now is: > > int pos; > struct ts_state; > struct ts_config *conf = textsearch_prepare("kmp", "hanky", 5, GFP_KERNEL, 1); > > /* search for "hanky" at offset 20 until end of packet */ > for (pos = skb_find_text(skb, 20, INT_MAX, conf, &state; > pos >= 0; > pos = textsearch_next(conf, &state)) { > printk("Need a hanky? I found one at offset %d.\n", pos); > } > > textsearch_put(conf); > kfree(conf); I haven't got too much time to review this stuff in deep though. Impressive work, but I still miss something, some comments: - A custom destroy function in ts_ops. - I don't see a way to look for matches in fragments. I mean, say we've got "dancing " in a fragment and "chicken" in the next one. Currently we don't get a match. - I particularly like Rusty's skb iterator, well you've refactored that code anyway. I've been reworking the framework for string matching that I sent you two/three months ago, you've definitely worked on a good base. Since then I've introduced a lot of changes and actually I've been testing it (ick, that means that we've clashed!). I think that I can merge both works and then roll on. I still need more time to study more in deep your proposition. -- Pablo From peter@pantasys.com Thu May 5 10:10:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 10:10:13 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45HA97J015712 for ; Thu, 5 May 2005 10:10:09 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 May 2005 10:09:05 -0700 Message-ID: <427A5363.2080703@pantasys.com> Date: Thu, 05 May 2005 10:09:55 -0700 From: Peter Buckingham User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> In-Reply-To: <20050505114327.GA51761@muc.de> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2005 17:09:05.0250 (UTC) FILETIME=[2464F420:01C55195] X-archive-position: 753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Andi Kleen wrote: > "32bit e1000"? How did you get such a beast? AFAIK all e1000s are 64bit > address capable. Please supply a full boot log without iommu=force > and describe what happens exactly. that was my initial impression too :-( basically what happens is when there is more that 4GB of RAM in this system packets will start disappearing. ie ping will drop packets. Initially our bios was not configuring the IOMMU correctly, that has changed now. I can make it work without the iommu=force by forcing the DMA to be 32bit in the initialisation, but this seems to be a bit of a hack.. I've attached a dmesg output from a while ago (you may remember it from when i was tracking down a serial console problem ;-) peter --- Linux version 2.6.8-24.11-smp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #2 SMP Wed Mar 16 09:22:34 PST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000b6ff0000 (usable) BIOS-e820: 00000000b6ff0000 - 00000000b6ffe000 (ACPI data) BIOS-e820: 00000000b6ffe000 - 00000000b7000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000200000000 (usable) Scanning NUMA topology in Northbridge 24 Number of nodes 4 (30030) Node 0 MemBase 0000000000000000 Limit 000000007fffffff Node 1 MemBase 0000000080000000 Limit 00000000ffffffff Node 2 MemBase 0000000100000000 Limit 000000017fffffff Node 3 MemBase 0000000180000000 Limit 00000001ffffffff node 1 shift 24 addr ff000000 conflict 0 node 3 shift 25 addr 1fe000000 conflict 0 Using node hash shift of 26 Bootmem setup node 0 0000000000000000-000000007fffffff Bootmem setup node 1 0000000080000000-00000000ffffffff Bootmem setup node 2 0000000100000000-000000017fffffff Bootmem setup node 3 0000000180000000-00000001ffffffff No mptable found. NVidia chipset found. Disabling timer override ACPI: RSDP (v000 ACPIAM ) @ 0x00000000000f8510 ACPI: RSDT (v001 A M I OEMRSDT 0x03000509 MSFT 0x00000097) @ 0x00000000b6ff0000 ACPI: FADT (v002 A M I OEMFACP 0x03000509 MSFT 0x00000097) @ 0x00000000b6ff0200 ACPI: MADT (v001 A M I OEMAPIC 0x03000509 MSFT 0x00000097) @ 0x00000000b6ff0390 ACPI: OEMB (v001 A M I AMI_OEM 0x03000509 MSFT 0x00000097) @ 0x00000000b6ffe040 ACPI: MCFG (v001 A M I OEMMCFG 0x03000509 MSFT 0x00000097) @ 0x00000000b6ff65e0 ACPI: DSDT (v001 0ABGS 0ABGS020 0x00000020 INTL 0x02002026) @ 0x0000000000000000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) Processor #2 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) Processor #3 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Using ACPI (MADT) for SMP configuration information Checking aperture... CPU 0: aperture @ 16e0000000 size 64 MB Aperture from northbridge cpu 0 beyond 4GB. Ignoring. No AGP bridge found Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup This costs you 64 MB of RAM Mapping aperture over 65536 KB of RAM @ 4000000 Built 4 zonelists Kernel command line: ip=dhcp nfsroot=10.2.128.1:/discovery iommu=force console=tty0 console=ttyS1,115200 BOOT_IMAGE=vmlinuz ip=10.2.135.253:10.2.128.1:0.0.0.0:255.255.128.0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 2000.015 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) Memory: 6978140k/8388608k available (3860k kernel code, 0k reserved, 2106k data, 240k init) Mount-cache hash table entries: 256 (order: 0, 4096 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) Using local APIC NMI watchdog using perfctr0 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU0: AMD Opteron(tm) Processor 846 HE stepping 0a per-CPU timeslice cutoff: 1023.93 usecs. task migration cache decay timeout: 2 msecs. Booting processor 1/1 rip 6000 rsp 10101c3ff58 Initializing CPU#1 3940.35 BogoMIPS (lpj=1970176) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Booting processor 2/2 rip 6000 rsp 1017ffa5f58 Initializing CPU#2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Booting processor 3/3 rip 6000 rsp 101fffb1f58 Initializing CPU#3 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Total of 4 processors activated (15785.98 BogoMIPS). Using local APIC timer interrupts. Detected 12.500 MHz APIC timer. checking TSC synchronization across 4 CPUs: passed. time.c: Using PIT/TSC based timekeeping. Brought up 4 CPUs NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040715 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - 0000:00:09.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 16 17 18 19) *10 ACPI: PCI Interrupt Link [LNKB] (IRQs 16 17 18 19) *9 ACPI: PCI Interrupt Link [LNKC] (IRQs 16 17 18 19) *11 ACPI: PCI Interrupt Link [LNKD] (IRQs 16 17 18 19) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 16 17 18 19) *0, disabled. ACPI: PCI Interrupt Link [LUS0] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LUS1] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LUS2] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LKLN] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LAUI] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LKMO] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LKSM] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LTID] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LTIE] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LATA] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LN2A] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN2B] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN2C] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN2D] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LK2N] (IRQs 44 45 46 47) *0, disabled. ACPI: PCI Interrupt Link [LT5D] (IRQs 44 45 46 47) *0, disabled. ACPI: PCI Interrupt Link [LT2E] (IRQs 44 45 46 47) *0, disabled. ACPI: PCI Interrupt Link [LN3A] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN3B] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN3C] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN3D] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN4A] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN4B] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN4C] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN4D] (IRQs 40 41 42 43) *0, disabled. SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LKSM] enabled at IRQ 22 ACPI: PCI interrupt 0000:00:01.1[A] -> GSI 22 (level, low) -> IRQ 177 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 19 ACPI: PCI interrupt 0000:05:06.0[A] -> GSI 19 (level, low) -> IRQ 185 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 18 ACPI: PCI interrupt 0000:05:07.0[A] -> GSI 18 (level, low) -> IRQ 193 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 17 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 17 (level, low) -> IRQ 201 PCI-DMA: Disabling AGP. PCI-DMA: aperture base @ 4000000 size 65536 KB Kernel panic - not syncing: Cannot allocate iommu bitmap From rick.jones2@hp.com Thu May 5 10:32:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 10:32:38 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45HWZ7J018420 for ; Thu, 5 May 2005 10:32:36 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id C7A611C085AA; Thu, 5 May 2005 10:32:17 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id KAA07988; Thu, 5 May 2005 10:32:17 -0700 (PDT) Message-ID: <427A58A0.3080309@hp.com> Date: Thu, 05 May 2005 10:32:16 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Buckingham , netdev@oss.sgi.com Cc: jgarzik@pobox.com Subject: Re: Mystery packet killing tg3 References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A5363.2080703@pantasys.com> In-Reply-To: <427A5363.2080703@pantasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Peter Buckingham wrote: > Andi Kleen wrote: > >> "32bit e1000"? How did you get such a beast? AFAIK all e1000s are 64bit >> address capable. Please supply a full boot log without iommu=force and >> describe what happens exactly. > > > that was my initial impression too :-( IIRC the HP Itanium2 workstations (zx2000, zx6000) have a 32-bit Intel (e1000) GbE on them. I have an idea what the name of the chip was, but will defer to any and all Intel types on the list :) rick jones From peter@pantasys.com Thu May 5 10:38:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 10:38:43 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Hcf7J019320 for ; Thu, 5 May 2005 10:38:41 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 May 2005 10:37:37 -0700 Message-ID: <427A5A13.1080402@pantasys.com> Date: Thu, 05 May 2005 10:38:27 -0700 From: Peter Buckingham User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rick Jones CC: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: Mystery packet killing tg3 References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A5363.2080703@pantasys.com> <427A58A0.3080309@hp.com> In-Reply-To: <427A58A0.3080309@hp.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2005 17:37:37.0484 (UTC) FILETIME=[20F720C0:01C55199] X-archive-position: 755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Rick Jones wrote: > IIRC the HP Itanium2 workstations (zx2000, zx6000) have a 32-bit Intel > (e1000) GbE on them. I have an idea what the name of the chip was, but > will defer to any and all Intel types on the list :) this is the one we're using. in the next generation of our system we'll definitely be using a 64bit part... peter 0000:05:07.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller (rev 05) Subsystem: Giga-byte Technology: Unknown device 3000 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- ; Thu, 5 May 2005 10:42:21 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 1F0281C0EB; Thu, 5 May 2005 19:42:24 +0200 (CEST) Date: Thu, 5 May 2005 19:42:24 +0200 From: Thomas Graf To: Pablo Neira Cc: netdev@oss.sgi.com, jamal Subject: Re: [RFC] textsearch infrastructure + skb_find_text() Message-ID: <20050505174224.GB25977@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> <427A51A2.8090600@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427A51A2.8090600@eurodev.net> X-archive-position: 756 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Pablo Neira <427A51A2.8090600@eurodev.net> 2005-05-05 19:02 > - A custom destroy function in ts_ops. Sure, can be added once we need it. Currently none of my algorithms allocate anything on their own. Might be worth to change the API and replace textsearch_put with textesearch_destroy also freeing the configuration though. > - I don't see a way to look for matches in fragments. I mean, say we've > got "dancing " in a fragment and "chicken" in the next one. Currently we > don't get a match. This is implemented in skb_find_text(), I just looked through rusty's code and it's very simliar so we could make the args in ts_state a union of long args[6] and char cb[XXX] so we can store skb_iter in there. > I've been reworking the framework for string matching that I sent you > two/three months ago, you've definitely worked on a good base. Since > then I've introduced a lot of changes and actually I've been testing it > (ick, that means that we've clashed!). I don't think so, my approach is quite different and allows for optimized text searches over fragments, multiple skbs, etc without any hacks around the fragment borders. It's a lot more generic allowing it to be in lib/ so it can be used from other subsystem as well. > I think that I can merge both works and then roll on. I still need more > time to study more in deep your proposition. Sure go ahead but please don't merge it into netfilter, a) the core really is supposed to be in lib, and b) I don't want any netfilter dependencies in my ematches. From jheffner@psc.edu Thu May 5 10:45:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 10:45:41 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Hjd7J020739 for ; Thu, 5 May 2005 10:45:39 -0700 Received: from homer.psc.edu (homer.psc.edu [128.182.61.117]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j45HjLuZ025245 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 13:45:22 -0400 (EDT) From: John Heffner Organization: PSC To: Rick Jones Subject: Re: Mystery packet killing tg3 Date: Thu, 5 May 2005 13:45:35 -0400 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <20050502162405.65dfb4a9@localhost.localdomain> <427A5363.2080703@pantasys.com> <427A58A0.3080309@hp.com> In-Reply-To: <427A58A0.3080309@hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200505051345.35455.jheffner@psc.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j45Hjd7J020739 X-archive-position: 757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev On Thursday 05 May 2005 01:32 pm, Rick Jones wrote: > Peter Buckingham wrote: > > Andi Kleen wrote: > >> "32bit e1000"? How did you get such a beast? AFAIK all e1000s are 64bit > >> address capable. Please supply a full boot log without iommu=force and > >> describe what happens exactly. > > > > that was my initial impression too :-( > > IIRC the HP Itanium2 workstations (zx2000, zx6000) have a 32-bit Intel > (e1000) GbE on them. I have an idea what the name of the chip was, but > will defer to any and all Intel types on the list :) > > rick jones From a zx2000: 0000:a0:03.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02) Subsystem: Hewlett-Packard Company: Unknown device 1274 Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 56 Memory at 00000000d0000000 (32-bit, non-prefetchable) [size=128K] I/O ports at a080 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device. Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- -John From ak@muc.de Thu May 5 11:01:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:01:26 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45I1N7J022177 for ; Thu, 5 May 2005 11:01:23 -0700 Received: (qmail 24964 invoked by uid 3709); 5 May 2005 18:01:06 -0000 Date: 5 May 2005 20:01:06 +0200 Date: Thu, 5 May 2005 20:01:06 +0200 From: Andi Kleen To: Stephen Hemminger Cc: Peter Buckingham , "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050505180106.GA24386@muc.de> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A47C9.6040302@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427A47C9.6040302@osdl.org> User-Agent: Mutt/1.4.1i X-archive-position: 758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev On Thu, May 05, 2005 at 09:20:25AM -0700, Stephen Hemminger wrote: > Andi Kleen wrote: > > >>>IOMMU code on x86-64 should be never active unless Stephen > >>>used IOMMU_DEBUG or iommu=force. THat is because the tg3 > >>>is a 64bit capable device and should always use bypass. > >>> > >>> > >>how is this detected? we have a board that is using a 32bit e1000 and we > >>have to use iommu=force otherwise it doesn't do the right thing with > > >>4GB of RAM. > >> > >> > > > >"32bit e1000"? How did you get such a beast? AFAIK all e1000s are 64bit > >address capable. Please supply a full boot log without iommu=force > >and describe what happens exactly. > > > > > One of the osdl e1000's in the lab is an IBM rebranded card that although > it uses a 64bit slot, is really only 32bit Ok, but it still supports DAC. The PCI bus width is a different thing from the size of the address registers. What we are talking about here is just if the card can directly address physical memory above 4GB. What width the bus is is a hardware internal thing that we do not really care about in the IOMMU code. -Andi From ak@muc.de Thu May 5 11:06:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:06:28 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45I6P7J022928 for ; Thu, 5 May 2005 11:06:26 -0700 Received: (qmail 26658 invoked by uid 3709); 5 May 2005 18:06:09 -0000 Date: 5 May 2005 20:06:09 +0200 Date: Thu, 5 May 2005 20:06:09 +0200 From: Andi Kleen To: Peter Buckingham Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050505180609.GB24386@muc.de> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A5363.2080703@pantasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427A5363.2080703@pantasys.com> User-Agent: Mutt/1.4.1i X-archive-position: 759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev On Thu, May 05, 2005 at 10:09:55AM -0700, Peter Buckingham wrote: > Andi Kleen wrote: > >"32bit e1000"? How did you get such a beast? AFAIK all e1000s are 64bit > >address capable. Please supply a full boot log without iommu=force > >and describe what happens exactly. > > that was my initial impression too :-( > > basically what happens is when there is more that 4GB of RAM in this > system packets will start disappearing. ie ping will drop packets. > Initially our bios was not configuring the IOMMU correctly, that has > changed now. The kernel should detect incorrect IOMMU setups and work around it. So even if your BIOS screws it up completely it should work (at the cost of some lost memory). That is the theory at least, but perhaps you discovered some new way to screw it up that is not handled yet ,-) > > I can make it work without the iommu=force by forcing the DMA to be > 32bit in the initialisation, but this seems to be a bit of a hack.. In what initialization exactly? YOu mean changing the pci_set_dma_mask() in the e1000 driver? > Checking aperture... > CPU 0: aperture @ 16e0000000 size 64 MB > Aperture from northbridge cpu 0 beyond 4GB. Ignoring. > No AGP bridge found > Your BIOS doesn't leave a aperture memory hole > Please enable the IOMMU option in the BIOS setup > This costs you 64 MB of RAM > Mapping aperture over 65536 KB of RAM @ 4000000 We try to fix up the IOMMU. Normally it should work now. > PCI-DMA: Disabling AGP. > PCI-DMA: aperture base @ 4000000 size 65536 KB > > Kernel panic - not syncing: Cannot allocate iommu bitmap Hmm, that must be a different problem in the IOMMU code not related to the e1000. Probably it got confused somehow. Why did you get the idea the ethernet driver has anything to do with it? -Andi From ak@muc.de Thu May 5 11:08:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:08:02 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45I7x7J023603 for ; Thu, 5 May 2005 11:07:59 -0700 Received: (qmail 27116 invoked by uid 3709); 5 May 2005 18:07:43 -0000 Date: 5 May 2005 20:07:43 +0200 Date: Thu, 5 May 2005 20:07:43 +0200 From: Andi Kleen To: jamal Cc: Robert Olsson , Jens.Laas@data.slu.se, netdev@oss.sgi.com Subject: Re: (diet-)FIB alternative fib_hlist.c Message-ID: <20050505180743.GC24386@muc.de> References: <17016.62444.34282.625407@robur.slu.se> <1115297370.7680.58.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115297370.7680.58.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-archive-position: 760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev > Great patch it is - but why do you say "99.999% of all users" feel they > would love this? Clearly perfomance at the low routes area is not What I wanted to say is that 99.999% of all users dont need the cisco grade BGP4 capable standard FIB, it is a just wasted complexity and memory for them. > something that is a huge difference against standard fib. And you suffer > miserably at latge route size. > Is it memory consumption you are thinking of? Yes, and complexity. -Andi From peter@pantasys.com Thu May 5 11:21:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:21:43 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45ILe7J025182 for ; Thu, 5 May 2005 11:21:40 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 May 2005 11:20:36 -0700 Message-ID: <427A6426.40104@pantasys.com> Date: Thu, 05 May 2005 11:21:26 -0700 From: Peter Buckingham User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A5363.2080703@pantasys.com> <20050505180609.GB24386@muc.de> In-Reply-To: <20050505180609.GB24386@muc.de> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2005 18:20:36.0109 (UTC) FILETIME=[21F213D0:01C5519F] X-archive-position: 761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Andi Kleen wrote: > In what initialization exactly? YOu mean changing the pci_set_dma_mask() > in the e1000 driver? exactly. >>Kernel panic - not syncing: Cannot allocate iommu bitmap > > > Hmm, that must be a different problem in the IOMMU code > not related to the e1000. Probably it got confused somehow. > Why did you get the idea the ethernet driver has anything to do with > it? i don't think it has anything to do with the e1000 actually. we only see this when the serial console redirection is enabled. It was the only dmesg I had lying around that had the IOMMU not forced. We run our systems diskless so it's not easy to get the boot log when the ethernet device is not working correctly. I can try to get a system with a hard drive and give you the dmesg from that instead (probably more useful ;-) peter From ak@muc.de Thu May 5 11:32:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:32:04 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45IW17J026170 for ; Thu, 5 May 2005 11:32:01 -0700 Received: (qmail 33962 invoked by uid 3709); 5 May 2005 18:31:44 -0000 Date: 5 May 2005 20:31:44 +0200 Date: Thu, 5 May 2005 20:31:44 +0200 From: Andi Kleen To: Peter Buckingham Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050505183144.GD24386@muc.de> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A5363.2080703@pantasys.com> <20050505180609.GB24386@muc.de> <427A6426.40104@pantasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427A6426.40104@pantasys.com> User-Agent: Mutt/1.4.1i X-archive-position: 763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1473 Lines: 39 On Thu, May 05, 2005 at 11:21:26AM -0700, Peter Buckingham wrote: > Andi Kleen wrote: > >In what initialization exactly? YOu mean changing the pci_set_dma_mask() > >in the e1000 driver? > > exactly. That should be impossible. Or it sounds like a serious hardware problem. DAC should normally always work with all e1000 AFAIK. Most likely you have some hardware problem and it is somehow magically worked around by IOMMU remapping. One difference is that the remapping makes all IO slower, perhaps the changed timing works around some bug. Or there is a posting problem somewhere that is worked around by the additional config accesses in IOMMU. Have you contacted the e1000 maintainters? > >>Kernel panic - not syncing: Cannot allocate iommu bitmap > > > > > >Hmm, that must be a different problem in the IOMMU code > >not related to the e1000. Probably it got confused somehow. > >Why did you get the idea the ethernet driver has anything to do with > >it? > > i don't think it has anything to do with the e1000 actually. we only see > this when the serial console redirection is enabled. It was the only > dmesg I had lying around that had the IOMMU not forced. We run our > systems diskless so it's not easy to get the boot log when the ethernet > device is not working correctly. I can try to get a system with a hard > drive and give you the dmesg from that instead (probably more useful ;-) It sounds like something is wrong with your hardware. -Andi From shemminger@osdl.org Thu May 5 11:36:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:36:20 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45IaG7J027058 for ; Thu, 5 May 2005 11:36:16 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j45IZvU3008376 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 5 May 2005 11:35:58 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j45IZvwZ032251; Thu, 5 May 2005 11:35:57 -0700 Date: Thu, 5 May 2005 11:35:57 -0700 From: Stephen Hemminger To: Jamal Hadi Salim , netdev@oss.sgi.com Subject: Re: ip route del bug? Message-ID: <20050505113557.7d21baf2@dxpl.pdx.osdl.net> In-Reply-To: <427A3370.3090001@skywaywest.com> References: <427A3370.3090001@skywaywest.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 702 Lines: 21 On Thu, 05 May 2005 07:53:36 -0700 Greg Varga wrote: > Hey there, > > I was working on one of our Linux routers yesterday, and when I issued a > "ip route del" command (no arg's) by mistake, it deleted the default route. > > I was just wondering if this is indeed the way it was intended, or if > its a bug and in fact should have displayed an error message? I > personally would have preferred that it error'd with some sort of message. > > I'm running Fedora Core 2 with iproute-2.4.7-14 rpm installed. > > Thanks, > --Greg It looks like an accidental behaviour (of the kernel) in response to an ip route delete netlink message with no additional data. Comments? From davem@davemloft.net Thu May 5 11:38:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:38:36 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45IcV7J027561 for ; Thu, 5 May 2005 11:38:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTl3I-00067v-00; Thu, 05 May 2005 11:26:24 -0700 Date: Thu, 5 May 2005 11:26:24 -0700 From: "David S. Miller" To: Anton Blanchard Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: oops in ip_rcv Message-Id: <20050505112624.3ffd7f3d.davem@davemloft.net> In-Reply-To: <20050505130904.GA16593@krispykreme> References: <20050505101542.GB7916@krispykreme> <20050505130904.GA16593@krispykreme> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 765 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 770 Lines: 29 On Thu, 5 May 2005 23:09:04 +1000 Anton Blanchard wrote: > > > Any idea why you'd be receiving packets this early? > > Not sure, although PCI has already been probed and tcp_init is called > with interrupts on. Any reason we cant take a packet at this point? > > Im guessing its calling this: > > IP_INC_STATS_BH(IPSTATS_MIB_INRECEIVES); > > Which we dont initialise until later on in init_ipv4_mibs. Can you test out putting the init_ipv4_mibs() call right before the comment: /* * Add all the base protocols. */ If it fixes things for you I'll put that upstream. Thanks. I still would really like to know how you are getting packets at all that early. Even if PCI is initialized, no interfaces should be marked up at _all_. From peter@pantasys.com Thu May 5 11:40:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:40:44 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Iec7J028325 for ; Thu, 5 May 2005 11:40:38 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 May 2005 11:39:33 -0700 Message-ID: <427A6898.4070804@pantasys.com> Date: Thu, 05 May 2005 11:40:24 -0700 From: Peter Buckingham User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A5363.2080703@pantasys.com> <20050505180609.GB24386@muc.de> <427A6426.40104@pantasys.com> <20050505183144.GD24386@muc.de> In-Reply-To: <20050505183144.GD24386@muc.de> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------050001030104020109040704" X-OriginalArrivalTime: 05 May 2005 18:39:33.0828 (UTC) FILETIME=[C8143840:01C551A1] X-archive-position: 766 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Content-Length: 17882 Lines: 386 This is a multi-part message in MIME format. --------------050001030104020109040704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andi Kleen wrote: > That should be impossible. Or it sounds like a serious > hardware problem. DAC should normally always work with all e1000 AFAIK. okay. I basically just force it to take a 32bit dma mask. I admit i'm a little clueless as to what this truely means. I had assumed that it would result in only dma'ing to an area below 4GB, but I hadn't really validated that assumption :-( > Most likely you have some hardware problem and it is somehow magically > worked around by IOMMU remapping. One difference is that > the remapping makes all IO slower, perhaps the changed timing > works around some bug. this is always a possibility, can you suggest some ways of isolating this problem? > Have you contacted the e1000 maintainters? not as yet, if you think that it is valuable i will. i've attached a fresh dmesg from a system running off a hard drive. this may or may not give you more clues about this. thanks for your help, peter --------------050001030104020109040704 Content-Type: text/plain; name="iommu_dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="iommu_dmesg.txt" Bootdata ok (command line is vga=normal root=/dev/hda3 console=tty0) Linux version 2.6.8-24.11-smp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Tue Mar 1 18:17:49 PST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000097ff0000 (usable) BIOS-e820: 0000000097ff0000 - 0000000097ffe000 (ACPI data) BIOS-e820: 0000000097ffe000 - 0000000098000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000240000000 (usable) Scanning NUMA topology in Northbridge 24 Number of nodes 8 (70070) Node 0 MemBase 0000000000000000 Limit 000000007fffffff Node 1 MemBase 0000000080000000 Limit 00000000ffffffff Node 2 MemBase 0000000100000000 Limit 000000017fffffff Node 3 MemBase 0000000180000000 Limit 00000001ffffffff Skipping disabled node 4 Skipping disabled node 5 Node 6 MemBase 0000000200000000 Limit 000000023fffffff Skipping disabled node 7 node 1 shift 24 addr ff000000 conflict 0 node 3 shift 25 addr 1fe000000 conflict 0 Using node hash shift of 26 Bootmem setup node 0 0000000000000000-000000007fffffff Bootmem setup node 1 0000000080000000-00000000ffffffff Bootmem setup node 2 0000000100000000-000000017fffffff Bootmem setup node 3 0000000180000000-00000001ffffffff Bootmem setup node 6 0000000200000000-000000023fffffff No mptable found. On node 0 totalpages: 524287 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 520191 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 On node 1 totalpages: 524287 DMA zone: 0 pages, LIFO batch:1 Normal zone: 524287 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 On node 2 totalpages: 524287 DMA zone: 0 pages, LIFO batch:1 Normal zone: 524287 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 On node 3 totalpages: 524287 DMA zone: 0 pages, LIFO batch:1 Normal zone: 524287 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 On node 6 totalpages: 262143 DMA zone: 0 pages, LIFO batch:1 Normal zone: 262143 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 NVidia chipset found. Disabling timer override ACPI: RSDP (v000 ACPIAM ) @ 0x00000000000f8700 ACPI: RSDT (v001 A M I OEMRSDT 0x03000518 MSFT 0x00000097) @ 0x0000000097ff0000 ACPI: FADT (v002 A M I OEMFACP 0x03000518 MSFT 0x00000097) @ 0x0000000097ff0200 ACPI: MADT (v001 A M I OEMAPIC 0x03000518 MSFT 0x00000097) @ 0x0000000097ff0390 ACPI: OEMB (v001 A M I AMI_OEM 0x03000518 MSFT 0x00000097) @ 0x0000000097ffe040 ACPI: MCFG (v001 A M I OEMMCFG 0x03000518 MSFT 0x00000097) @ 0x0000000097ff65e0 ACPI: DSDT (v001 0ABGS 0ABGS023 0x00000023 INTL 0x02002026) @ 0x0000000000000000 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) Processor #2 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) Processor #3 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) Processor #4 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) Processor #5 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled) Processor #6 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) Processor #7 15:5 APIC version 16 ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 8, version 17, address 0xfec00000, GSI 0-23 ACPI: IOAPIC (id[0x09] address[0xbeeff000] gsi_base[24]) IOAPIC[1]: apic_id 9, version 17, address 0xbeeff000, GSI 24-47 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information Checking aperture... CPU 0: aperture @ 98000000 size 32 MB Aperture from northbridge cpu 0 too small (32 MB) No AGP bridge found Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup This costs you 64 MB of RAM Mapping aperture over 65536 KB of RAM @ 4000000 Built 8 zonelists Kernel command line: vga=normal root=/dev/hda3 console=tty0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 2000.032 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) Memory: 7505340k/9437184k available (3226k kernel code, 0k reserved, 1578k data, 228k init) Calibrating delay loop... 3964.92 BogoMIPS (lpj=1982464) Mount-cache hash table entries: 256 (order: 0, 4096 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) Using local APIC NMI watchdog using perfctr0 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU0: AMD Opteron(tm) Processor 846 HE stepping 0a per-CPU timeslice cutoff: 1023.93 usecs. task migration cache decay timeout: 2 msecs. Booting processor 1/1 rip 6000 rsp 10202647f58 Initializing CPU#1 Calibrating delay loop... <7>spurious 8259A interrupt: IRQ7. 3940.35 BogoMIPS (lpj=1970176) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Booting processor 2/2 rip 6000 rsp 101fff93f58 Initializing CPU#2 Calibrating delay loop... 3940.35 BogoMIPS (lpj=1970176) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Booting processor 3/3 rip 6000 rsp 1023ff85f58 Initializing CPU#3 Calibrating delay loop... 3940.35 BogoMIPS (lpj=1970176) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Booting processor 4/4 rip 6000 rsp 10097fbbf58 Initializing CPU#4 Calibrating delay loop... 3940.35 BogoMIPS (lpj=1970176) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Booting processor 5/5 rip 6000 rsp 10181c49f58 Initializing CPU#5 Calibrating delay loop... 3940.35 BogoMIPS (lpj=1970176) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Booting processor 6/6 rip 6000 rsp 10008069f58 Initializing CPU#6 Calibrating delay loop... 3940.35 BogoMIPS (lpj=1970176) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Booting processor 7/7 rip 6000 rsp 10081c7df58 Initializing CPU#7 Calibrating delay loop... 3940.35 BogoMIPS (lpj=1970176) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 846 HE stepping 0a Total of 8 processors activated (31547.39 BogoMIPS). Using local APIC timer interrupts. Detected 12.500 MHz APIC timer. checking TSC synchronization across 8 CPUs: passed. time.c: Using PIT/TSC based timekeeping. Brought up 8 CPUs NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040715 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - 0000:00:09.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] ACPI: PCI Root Bridge [PCIC] (00:40) PCI: Probing PCI hardware (bus 40) ACPI: PCI Interrupt Routing Table [\_SB_.PCIC._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 16 17 18 19) *10 ACPI: PCI Interrupt Link [LNKB] (IRQs 16 17 18 19) *9 ACPI: PCI Interrupt Link [LNKC] (IRQs 16 17 18 19) *11 ACPI: PCI Interrupt Link [LNKD] (IRQs 16 17 18 19) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 16 17 18 19) *0, disabled. ACPI: PCI Interrupt Link [LUS0] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LUS1] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LUS2] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LKLN] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LAUI] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LKMO] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LKSM] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LTID] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LTIE] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [LATA] (IRQs 20 21 22) *14 ACPI: PCI Interrupt Link [LN2A] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN2B] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN2C] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN2D] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LK2N] (IRQs 44 45 46 47) *0, disabled. ACPI: PCI Interrupt Link [LT5D] (IRQs 44 45 46 47) *0, disabled. ACPI: PCI Interrupt Link [LT2E] (IRQs 44 45 46 47) *0, disabled. ACPI: PCI Interrupt Link [LN3A] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN3B] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN3C] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN3D] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN4A] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN4B] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN4C] (IRQs 40 41 42 43) *0, disabled. ACPI: PCI Interrupt Link [LN4D] (IRQs 40 41 42 43) *0, disabled. SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LKSM] enabled at IRQ 22 ACPI: PCI interrupt 0000:00:01.1[A] -> GSI 22 (level, low) -> IRQ 22 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 19 ACPI: PCI interrupt 0000:05:06.0[A] -> GSI 19 (level, low) -> IRQ 19 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 18 ACPI: PCI interrupt 0000:05:07.0[A] -> GSI 18 (level, low) -> IRQ 18 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 17 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 17 (level, low) -> IRQ 17 ACPI: PCI Interrupt Link [LN3C] enabled at IRQ 43 ACPI: PCI interrupt 0000:41:00.0[A] -> GSI 43 (level, low) -> IRQ 43 PCI-DMA: Disabling AGP. PCI-DMA: aperture base @ 4000000 size 65536 KB PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture IA32 emulation $Id: sys_ia32.c 72 2005-03-02 01:01:07Z peter $ Total HugeTLB memory allocated, 0 NTFS driver 2.1.17 [Flags: R/O]. subfs 0.9 Initializing Cryptographic API pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp: PCI Express Hot Plug Controller Driver version: 0.4 vesafb: probe of vesafb0 failed with error -6 ACPI: Power Button (FF) [PWRF] ACPI: Processor [CPU1] (supports C1) ACPI: Processor [CPU2] (supports C1) ACPI: Processor [CPU3] (supports C1) ACPI: Processor [CPU4] (supports C1) ACPI: Processor [CPU5] (supports C1) ACPI: Processor [CPU6] (supports C1) ACPI: Processor [CPU7] (supports C1) ACPI: Processor [CPU8] (supports C1) Real Time Clock Driver v1.12 Non-volatile memory driver v1.2 Linux agpgart interface v0.100 (c) Dave Jones ipmi message handler version v33 ipmi device interface version v33 IPMI System Interface driver version v33, KCS version v33, SMIC version v33, BT version v33 ipmi_si: Found SMBIOS-specified state machine at I/O address 0x62 Could not set up I/O space Trying to free nonexistent resource <00000062-00000063> ipmi_si: Unable to find any System Interface(s) Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot version v33. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 Serial: 8250/16550 driver $Revision: 1.1 $ 8 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize loop: loaded (max 8 devices) nbd: Couldn't get a blowfish cipher context. Intel(R) PRO/1000 Network Driver - version 5.3.19-k2 Copyright (c) 1999-2004 Intel Corporation. ACPI: PCI interrupt 0000:05:07.0[A] -> GSI 18 (level, low) -> IRQ 18 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection eth0: TCP Segmentation Offload (TSO) disabled by default pcnet32.c:v1.30i 06.28.2004 tsbogend@alpha.franken.de e100: Intel(R) PRO/100 Network Driver, 3.0.27-k2-NAPI e100: Copyright(c) 1999-2004 Intel Corporation Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0 NFORCE-CK804: chipset revision 162 NFORCE-CK804: not 100% native mode: will probe irqs later NFORCE-CK804: 0000:00:06.0 (rev a2) UDMA133 controller ide0: BM-DMA at 0x6000-0x6007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x6008-0x600f, BIOS settings: hdc:DMA, hdd:DMA Probing IDE interface ide0... hda: FUJITSU MHT2040AS, ATA DISK drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... Probing IDE interface ide1... Probing IDE interface ide2... ide2: Wait for ready failed before probe ! Probing IDE interface ide3... ide3: Wait for ready failed before probe ! Probing IDE interface ide4... ide4: Wait for ready failed before probe ! Probing IDE interface ide5... ide5: Wait for ready failed before probe ! hda: max request size: 128KiB hda: 78140160 sectors (40007 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(33) hda: cache flushes supported hda: hda1 hda2 hda3 ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) USB Universal Host Controller Interface driver v2.2 Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. usbcore: registered new driver hiddev usbcore: registered new driver usbhid /panta-build/kernel-sources/SuSE-2.6.8/drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 NET: Registered protocol family 2 IP: routing cache hash table of 65536 buckets, 1024Kbytes TCP: Hash tables configured (established 262144 bind 65536) ip_conntrack version 2.1 (8192 buckets, 65536 max) - 520 bytes per conntrack ip_tables: (C) 2000-2002 Netfilter core team ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ ClusterIP Version 0.5 loaded successfully arp_tables: (C) 2002 David S. Miller NET: Registered protocol family 1 NET: Registered protocol family 17 ACPI: (supports S0 S1 S5) ACPI wakeup devices: PS2K USB0 USB1 P0P1 P0P2 P0P3 P0P4 P0P5 BR84 BR83 BR82 BR81 PWRB kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 228k freed EXT3 FS on hda3, internal journal FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Adding 1052248k swap on /dev/hda2. Priority:42 extents:1 --------------------- ioctl INIT: pci_find_slot(1, 0) --------------------- ioctl INIT: pci_find_slot(1, 0) --------------------- ioctl INIT: pci_find_slot(1, 0) --------------------- ioctl INIT: pci_find_slot(65, 0) --------------------- ioctl INIT: pci_find_slot(65, 0) --------------------- ioctl INIT: pci_find_slot(65, 0) e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex PCI: Setting latency timer of device 0000:01:00.0 to 64 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 17 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:41:00.0 to 64 ACPI: PCI interrupt 0000:41:00.0[A] -> GSI 43 (level, low) -> IRQ 43 Mellanox Tavor Device Driver is creating device "InfiniHost0" (bus=01, devfn=00) Mellanox Tavor Device Driver is creating device "InfiniHost1" (bus=41, devfn=00) THH kernel module initialized successfully [KERNEL_IB][ib_mad_static_compute_base][/var/tmp/IBGD/lib/modules/2.6.8-24.11-smp/source/drivers/infiniband/core/mad_static.c:93]Couldn't find a suitable network device; setting lid_base to 1 NET: Registered protocol family 26 --------------050001030104020109040704-- From kaber@trash.net Thu May 5 11:53:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:53:06 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Ir3Ov030001 for ; Thu, 5 May 2005 11:53:03 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DTlSh-0002Z7-9U; Thu, 05 May 2005 20:52:39 +0200 Message-ID: <427A6B77.1030200@trash.net> Date: Thu, 05 May 2005 20:52:39 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: Jamal Hadi Salim , netdev@oss.sgi.com Subject: Re: ip route del bug? References: <427A3370.3090001@skywaywest.com> <20050505113557.7d21baf2@dxpl.pdx.osdl.net> In-Reply-To: <20050505113557.7d21baf2@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Stephen Hemminger wrote: > It looks like an accidental behaviour (of the kernel) in response to > an ip route delete netlink message with no additional data. I don't believe it is accidental, it seems correct to me to delete the default route when no more specific selector is given. To avoid this, iproute could print an error when dst.bytelen == 0. Regards Patrick From ak@muc.de Thu May 5 11:56:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 11:56:54 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45IupOv030824 for ; Thu, 5 May 2005 11:56:52 -0700 Received: (qmail 41967 invoked by uid 3709); 5 May 2005 18:56:35 -0000 Date: 5 May 2005 20:56:35 +0200 Date: Thu, 5 May 2005 20:56:35 +0200 From: Andi Kleen To: Peter Buckingham Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050505185635.GE24386@muc.de> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A5363.2080703@pantasys.com> <20050505180609.GB24386@muc.de> <427A6426.40104@pantasys.com> <20050505183144.GD24386@muc.de> <427A6898.4070804@pantasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427A6898.4070804@pantasys.com> User-Agent: Mutt/1.4.1i X-archive-position: 769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev On Thu, May 05, 2005 at 11:40:24AM -0700, Peter Buckingham wrote: > Andi Kleen wrote: > >That should be impossible. Or it sounds like a serious > >hardware problem. DAC should normally always work with all e1000 AFAIK. > > okay. > > I basically just force it to take a 32bit dma mask. I admit i'm a little > clueless as to what this truely means. I had assumed that it would > result in only dma'ing to an area below 4GB, but I hadn't really > validated that assumption :-( If you dont use iommu=force it will only cause IOMMU remapping when the memory buffer is beyond 4GB. It is basically random if that happens or not, depending on how fully your memory is. With iommu=force or CONFIG_IOMMU_DEBUG all IO is foced through the IOMMU. > > >Most likely you have some hardware problem and it is somehow magically > >worked around by IOMMU remapping. One difference is that > >the remapping makes all IO slower, perhaps the changed timing > >works around some bug. > > this is always a possibility, can you suggest some ways of isolating > this problem? Hmm - if you want to hack the kernel you could add udelay()s to the no IOMMU paths in arch/x86_64/kernel/pci-gart.c and see if that cures the problem too. If yes then the timing theory would be proved. Actually the IOMMU code does more than just delaying, it also does config space accesses which might flush or synchronize things in the PCI bridges. Perhaps adding some dummy access for that would be good too. The dmesg looks similar to the previous one from the IOMMU code perspective. -Andi From peter@pantasys.com Thu May 5 12:02:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 12:02:39 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45J2XOv031778 for ; Thu, 5 May 2005 12:02:33 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 May 2005 12:01:27 -0700 Message-ID: <427A6DB7.10404@pantasys.com> Date: Thu, 05 May 2005 12:02:15 -0700 From: Peter Buckingham User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A5363.2080703@pantasys.com> <20050505180609.GB24386@muc.de> <427A6426.40104@pantasys.com> <20050505183144.GD24386@muc.de> <427A6898.4070804@pantasys.com> <20050505185635.GE24386@muc.de> In-Reply-To: <20050505185635.GE24386@muc.de> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2005 19:01:27.0656 (UTC) FILETIME=[D72E7680:01C551A4] X-archive-position: 770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Andi Kleen wrote: > With iommu=force or CONFIG_IOMMU_DEBUG all IO is foced > through the IOMMU. okay, that's definitely bad... > Hmm - if you want to hack the kernel you could add udelay()s > to the no IOMMU paths in arch/x86_64/kernel/pci-gart.c > and see if that cures the problem too. If yes then the timing > theory would be proved. > Actually the IOMMU code does more than just delaying, it also > does config space accesses which might flush or synchronize > things in the PCI bridges. Perhaps adding some dummy access > for that would be good too. okay, i'll start to take a look at this, but it'll probably be a little while before i can really get to it. i'll let you know what i find out. > The dmesg looks similar to the previous one from the IOMMU > code perspective. it actually looks like it's configure correctly now (at least from agp-gart messages), before we were getting errors. i guess the bios guys finally got it right ;-) thanks, peter From hadi@znyx.com Thu May 5 12:15:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 12:15:47 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45JFhOv000832 for ; Thu, 5 May 2005 12:15:43 -0700 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050512160069:40886 ; Thu, 5 May 2005 12:16:00 -0700 Subject: Re: ip route del bug? From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Patrick McHardy Cc: Stephen Hemminger , netdev@oss.sgi.com In-Reply-To: <427A6B77.1030200@trash.net> References: <427A3370.3090001@skywaywest.com> <20050505113557.7d21baf2@dxpl.pdx.osdl.net> <427A6B77.1030200@trash.net> Organization: ZNYX Networks Date: Thu, 05 May 2005 15:15:24 -0400 Message-Id: <1115320524.8006.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 12:16:00 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 12:16:03 PM, Serialize complete at 05/05/2005 12:16:03 PM Content-Type: multipart/mixed; boundary="=-wgwMQDo2D6A5JlW9zFg0" X-archive-position: 771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev --=-wgwMQDo2D6A5JlW9zFg0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Thu, 2005-05-05 at 20:52 +0200, Patrick McHardy wrote: > Stephen Hemminger wrote: > > It looks like an accidental behaviour (of the kernel) in response to > > an ip route delete netlink message with no additional data. > > I don't believe it is accidental, it seems correct to me to delete > the default route when no more specific selector is given. To avoid > this, iproute could print an error when dst.bytelen == 0. Agreed - basically the kernel does what its told. I think the check should be on missing dst (default will always give you bytelen of 0 for example and is legit). Patchlet attached. cheers, jamal --=-wgwMQDo2D6A5JlW9zFg0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=iprdl_p Content-Type: text/plain; name=iprdl_p; charset=utf-8 --- a/ip/iproute.c 2005/05/05 18:56:30 1.1 +++ b/ip/iproute.c 2005/05/05 19:10:49 @@ -857,6 +857,11 @@ argc--; argv++; } + if (!dst_ok) { + fprintf(stderr,"route must specify destination address \n"); + return -1; + } + if (rtnl_open(&rth, 0) < 0) exit(1); --=-wgwMQDo2D6A5JlW9zFg0-- From webmaster@rapidforum.com Thu May 5 12:16:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 12:16:43 -0700 (PDT) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j45JGdOv000972 for ; Thu, 5 May 2005 12:16:40 -0700 Received: (qmail 23489 invoked by uid 1004); 5 May 2005 19:16:20 -0000 Received: from p549f136b.dip0.t-ipconnect.de (HELO ?84.159.19.107?) (Dragony@84.159.19.107) by www.rapidforum.com with SMTP; 5 May 2005 19:16:20 -0000 Message-ID: <427A70ED.3010305@rapidforum.com> Date: Thu, 05 May 2005 21:15:57 +0200 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: de, en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: MultiPath Routing References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev > Did you enable IP_ROUTE_MULTIPATH_CACHED? If so please disable it > since it breaks multipath routing for forwarded traffic. Yes I enabled it. But it shouldnt do anything because its no forwarded traffic here. I just used example-IPs. Or does the bug also break non-forwarded traffic? From ak@muc.de Thu May 5 12:24:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 12:24:28 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45JOLOv005815 for ; Thu, 5 May 2005 12:24:22 -0700 Received: (qmail 50997 invoked by uid 3709); 5 May 2005 19:24:05 -0000 Date: 5 May 2005 21:24:05 +0200 Date: Thu, 5 May 2005 21:24:05 +0200 From: Andi Kleen To: Peter Buckingham Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050505192405.GF24386@muc.de> References: <42791825.2080204@pantasys.com> <20050505114327.GA51761@muc.de> <427A5363.2080703@pantasys.com> <20050505180609.GB24386@muc.de> <427A6426.40104@pantasys.com> <20050505183144.GD24386@muc.de> <427A6898.4070804@pantasys.com> <20050505185635.GE24386@muc.de> <427A6DB7.10404@pantasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427A6DB7.10404@pantasys.com> User-Agent: Mutt/1.4.1i X-archive-position: 773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev > >The dmesg looks similar to the previous one from the IOMMU > >code perspective. > > it actually looks like it's configure correctly now (at least from > agp-gart messages), before we were getting errors. i guess the bios guys > finally got it right ;-) No, it is still broken, the kernel fixed it up. Look at the early messages. It was too small (32MB) -Andi From kaber@trash.net Thu May 5 12:54:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 12:54:11 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Js6Ov007796 for ; Thu, 5 May 2005 12:54:09 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DTmPh-0001Yn-0X; Thu, 05 May 2005 21:53:37 +0200 Message-ID: <427A79C0.4020103@trash.net> Date: Thu, 05 May 2005 21:53:36 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Yasuyuki Kozakai CC: pb@bieringer.de, usagi-users@linux-ipv6.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, laforge@gnumonks.org Subject: Re: netfilter6: ICMPv6 type 143 doesn't match References: <6050E336B1A0D7D8E70C66F3@t1mobil.muc.aerasec.de> <200412270417.iBR4HZRG021429@toshiba.co.jp> In-Reply-To: <200412270417.iBR4HZRG021429@toshiba.co.jp> Content-Type: multipart/mixed; boundary="------------070703010208060508000301" X-archive-position: 774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------070703010208060508000301 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yasuyuki Kozakai wrote: > Well, the Multicast Listener Report seems that skb->data != skb->nh.ipv6h > when interface is up. But IPv6 netfilter modules assumes that > skb->data == skb->nh.ipv6h like IPv4 netfilter modules. > > folks, is this wrong or bad asumption ? If so, I'll fix this problem in > many modules as follows. Sorry for getting back to this so late, I must have missed it at the time. Anyway, I think it would be safer to restore netfilters assumption by doing something like this patch. If everyone is fine with it I'm going to add it to my pending netfilter patches for 2.6.13. Regards Patrick --------------070703010208060508000301 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: net/ipv6/mcast.c =================================================================== --- 2cfdb1827d9c176f4df42619c693e7b990a61963/net/ipv6/mcast.c (mode:100644 sha1:393b6e6f50a9626e2894c9a5abd8dafd903e5eba) +++ uncommitted/net/ipv6/mcast.c (mode:100644) @@ -1280,15 +1280,6 @@ return NULL; skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - - ndisc_mc_map(&mld2_all_mcr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6,ha,NULL,size) < 0) { - kfree_skb(skb); - return NULL; - } - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* : @@ -1312,6 +1303,24 @@ return skb; } +static inline int igmp6_dev_queue_xmit(struct sk_buff *skb) +{ + struct net_device *dev = skb->dev; + + if (dev->hard_header) { + unsigned char ha[MAX_ADDR_LEN]; + int err; + + ndisc_mc_map(&skb->nh.ipv6h->daddr, ha, dev, 1); + err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); + if (err < 0) { + kfree_skb(skb); + return err; + } + } + return dev_queue_xmit(skb); +} + static void mld_sendpack(struct sk_buff *skb) { struct ipv6hdr *pip6 = skb->nh.ipv6h; @@ -1329,7 +1338,7 @@ pmr->csum = csum_ipv6_magic(&pip6->saddr, &pip6->daddr, mldlen, IPPROTO_ICMPV6, csum_partial(skb->h.raw, mldlen, 0)); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + igmp6_dev_queue_xmit); if (!err) { ICMP6_INC_STATS(idev,ICMP6_MIB_OUTMSGS); IP6_INC_STATS(IPSTATS_MIB_OUTMCASTPKTS); @@ -1635,12 +1644,6 @@ } skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - ndisc_mc_map(snd_addr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, full_len) < 0) - goto out; - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* : @@ -1668,7 +1671,7 @@ idev = in6_dev_get(skb->dev); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + igmp6_dev_queue_xmit); if (!err) { if (type == ICMPV6_MGM_REDUCTION) ICMP6_INC_STATS(idev, ICMP6_MIB_OUTGROUPMEMBREDUCTIONS); @@ -1683,7 +1686,6 @@ in6_dev_put(idev); return; -out: IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); kfree_skb(skb); } --------------070703010208060508000301-- From andre@tomt.net Thu May 5 12:55:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 12:55:10 -0700 (PDT) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Jt6Ov007922 for ; Thu, 5 May 2005 12:55:07 -0700 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 225BE8867A; Thu, 5 May 2005 21:54:50 +0200 (CEST) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id CBE008864D; Thu, 5 May 2005 21:54:49 +0200 (CEST) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id AD9B222A92; Thu, 5 May 2005 21:54:48 +0200 (CEST) Message-ID: <427A7A09.4060900@tomt.net> Date: Thu, 05 May 2005 21:54:49 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson Cc: netdev@oss.sgi.com, Jens.Laas@data.slu.se Subject: Re: (diet-)FIB alternative fib_hlist.c References: <17016.62444.34282.625407@robur.slu.se> In-Reply-To: <17016.62444.34282.625407@robur.slu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Robert Olsson wrote: > Hello! > > fib_hlist is the smallest and simpliest routing algo we could think of > it's just a sorted (h)list. > > routing (FIB lookup) performance. dst hash is not used. > > fib_hlist fib_hash test routing table size > ----------------------------------------------------- > 444 kpps 433 kpps Single flow. local=19/main=5 entries > 433 kpps 431 kpps rDoS. local=19/main=5 > 0.2 kpps 198 kpps rDoS local=19/main=123946 > > As seen fib_hlist is catastrophe for large routing tables as expected but > performs surprisingly well for ordinary routing tables so it should be > fine for most hosts and servers. The patch has config option to select FIB. > > Probably we soon want to specify differnt lookup schemes for different > tables say for local table fib_hash or fib_hlist. While for large main table > fib_hash2/fib_trie would be better option. From a distribution[1] point of view, a boot time option would be much better than choosing at compile time. Boot time plus a kconfig multiple selection list would be even better. Another perhaps even more user friendly option would be setting it runtime using f.ex. iproute, but I guess that could end up messy.. 1. goes for both "a GNU/Linux distribution" and kernel image distribution in a production network From rick.jones2@hp.com Thu May 5 13:17:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 13:17:54 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45KHmOv011494 for ; Thu, 5 May 2005 13:17:48 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 48A7C18C4; Thu, 5 May 2005 13:17:32 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id NAA09493; Thu, 5 May 2005 13:17:31 -0700 (PDT) Message-ID: <427A7F5B.8050704@hp.com> Date: Thu, 05 May 2005 13:17:31 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Iatrou Cc: netdev@oss.sgi.com Subject: Re: e1000 (?) jumbo frames performance issue References: <200505051928.32496.m.iatrou@freemail.gr> In-Reply-To: <200505051928.32496.m.iatrou@freemail.gr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1196 Lines: 31 Michael Iatrou wrote: > Hi, > I did several benchmarks using Intel e1000 NIC and it seems there is a > network throughput problem for MTU > 12000 (e1000 supports up to 16110 > MTU). > > Configuration: > Two identical PCs, connected back to back, Intel Xeon 2.8GHz (SMP/SMT > disabled), 512MB RAM, e1000 (82546EB) > > Linux 2.6.11.7 > netperf 2.3pl1 What settings, if any, did you use for -s, -S and in particular -m in netperf? I seem to recall that some of the stack defaults for SO_SNDBUF (IIRC) would result in netperf sending 16KB at a time into the connection - once you sent the MTU above 16K you may have started running into issues with Nagle and delayed ACK? You could try some tests adding a test-specific -D to disable Nagle, or -C to set TCP_CORK, or use -m to set the send size to say, 32KB. It might be good to add CPU utilization figures - for 2.3pl1 that means editing the makefile to add a -DUSE_PROC_STAT and recompiling. Or you can grab netperf 2.4.0-rc3 from: ftp://ftp.cup.hp.com/dist/networking/benchmarks/netperf/experimental/ if you cannot find it elsewhere, and that will (try to) compile-in the right CPU utilization mechanism automagically. rick jones From kaber@trash.net Thu May 5 13:20:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 13:20:30 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45KKROv012391 for ; Thu, 5 May 2005 13:20:27 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DTmpK-0001uw-6V; Thu, 05 May 2005 22:20:06 +0200 Message-ID: <427A7FF5.4030900@trash.net> Date: Thu, 05 May 2005 22:20:05 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Yasuyuki Kozakai CC: usagi-users@linux-ipv6.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, laforge@gnumonks.org, pb@bieringer.de Subject: Re: netfilter6: ICMPv6 type 143 doesn't match References: <6050E336B1A0D7D8E70C66F3@t1mobil.muc.aerasec.de> <200412270417.iBR4HZRG021429@toshiba.co.jp> <427A79C0.4020103@trash.net> In-Reply-To: <427A79C0.4020103@trash.net> Content-Type: multipart/mixed; boundary="------------010408040000090202080001" X-archive-position: 778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 3469 Lines: 121 This is a multi-part message in MIME format. --------------010408040000090202080001 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrick McHardy wrote: > Yasuyuki Kozakai wrote: > >>Well, the Multicast Listener Report seems that skb->data != skb->nh.ipv6h >>when interface is up. But IPv6 netfilter modules assumes that >>skb->data == skb->nh.ipv6h like IPv4 netfilter modules. >> >>folks, is this wrong or bad asumption ? If so, I'll fix this problem in >>many modules as follows. > > > Sorry for getting back to this so late, I must have missed it at the > time. Anyway, I think it would be safer to restore netfilters assumption > by doing something like this patch. If everyone is fine with it I'm > going to add it to my pending netfilter patches for 2.6.13. The last patch left some unreachable code. --------------010408040000090202080001 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: net/ipv6/mcast.c =================================================================== --- 2cfdb1827d9c176f4df42619c693e7b990a61963/net/ipv6/mcast.c (mode:100644 sha1:393b6e6f50a9626e2894c9a5abd8dafd903e5eba) +++ uncommitted/net/ipv6/mcast.c (mode:100644) @@ -1280,15 +1280,6 @@ return NULL; skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - - ndisc_mc_map(&mld2_all_mcr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6,ha,NULL,size) < 0) { - kfree_skb(skb); - return NULL; - } - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* : @@ -1312,6 +1303,25 @@ return skb; } +static inline int igmp6_dev_queue_xmit(struct sk_buff *skb) +{ + struct net_device *dev = skb->dev; + + if (dev->hard_header) { + unsigned char ha[MAX_ADDR_LEN]; + int err; + + ndisc_mc_map(&skb->nh.ipv6h->daddr, ha, dev, 1); + err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); + if (err < 0) { + IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); + kfree_skb(skb); + return err; + } + } + return dev_queue_xmit(skb); +} + static void mld_sendpack(struct sk_buff *skb) { struct ipv6hdr *pip6 = skb->nh.ipv6h; @@ -1329,7 +1339,7 @@ pmr->csum = csum_ipv6_magic(&pip6->saddr, &pip6->daddr, mldlen, IPPROTO_ICMPV6, csum_partial(skb->h.raw, mldlen, 0)); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + igmp6_dev_queue_xmit); if (!err) { ICMP6_INC_STATS(idev,ICMP6_MIB_OUTMSGS); IP6_INC_STATS(IPSTATS_MIB_OUTMCASTPKTS); @@ -1635,12 +1645,6 @@ } skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - ndisc_mc_map(snd_addr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, full_len) < 0) - goto out; - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* : @@ -1668,7 +1672,7 @@ idev = in6_dev_get(skb->dev); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + igmp6_dev_queue_xmit); if (!err) { if (type == ICMPV6_MGM_REDUCTION) ICMP6_INC_STATS(idev, ICMP6_MIB_OUTGROUPMEMBREDUCTIONS); @@ -1682,10 +1686,6 @@ if (likely(idev != NULL)) in6_dev_put(idev); return; - -out: - IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); - kfree_skb(skb); } static int ip6_mc_del1_src(struct ifmcaddr6 *pmc, int sfmode, --------------010408040000090202080001-- From kaber@trash.net Thu May 5 13:31:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 13:31:28 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45KVPOv013902 for ; Thu, 5 May 2005 13:31:25 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DTmzy-00022f-98; Thu, 05 May 2005 22:31:06 +0200 Message-ID: <427A828A.3080309@trash.net> Date: Thu, 05 May 2005 22:31:06 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev Subject: [IPV4]: multipath_wrandom.c GPF fixes Content-Type: multipart/mixed; boundary="------------000100020409060809050509" X-archive-position: 779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1930 Lines: 59 This is a multi-part message in MIME format. --------------000100020409060809050509 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit multipath_wrandom needs to use GFP_ATOMIC. --------------000100020409060809050509 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" [IPV4]: multipath_wrandom.c GPF fixes Signed-off-by: Patrick McHardy --- commit cdb5c875d48676b20ecd95fef080891a68c32e9c tree 46b576def0e0b0e4600193306cb830e66b5a57da parent 3a614a8969f79ac4116f496beff879736dca83e2 author Patrick McHardy 1115277458 +0200 committer Patrick McHardy 1115277458 +0200 Index: net/ipv4/multipath_wrandom.c =================================================================== --- a744d6c4cd2587f82796c0f6cb4d7f94744ef9f2/net/ipv4/multipath_wrandom.c (mode:100644 sha1:10b23e1bece663bd8a9317f980b30ec0df7f0a11) +++ 46b576def0e0b0e4600193306cb830e66b5a57da/net/ipv4/multipath_wrandom.c (mode:100644 sha1:c3d2ca1a6781513bc7b2524aad96f61e7a4053a6) @@ -172,7 +172,7 @@ multipath_comparekeys(&rt->fl, flp)) { struct multipath_candidate* mpc = (struct multipath_candidate*) - kmalloc(size_mpc, GFP_KERNEL); + kmalloc(size_mpc, GFP_ATOMIC); if (!mpc) return; @@ -244,7 +244,7 @@ if (!target_route) { const size_t size_rt = sizeof(struct multipath_route); target_route = (struct multipath_route *) - kmalloc(size_rt, GFP_KERNEL); + kmalloc(size_rt, GFP_ATOMIC); target_route->gw = nh->nh_gw; target_route->oif = nh->nh_oif; @@ -265,7 +265,7 @@ if (!target_dest) { const size_t size_dst = sizeof(struct multipath_dest); target_dest = (struct multipath_dest*) - kmalloc(size_dst, GFP_KERNEL); + kmalloc(size_dst, GFP_ATOMIC); target_dest->nh_info = nh; target_dest->network = network; --------------000100020409060809050509-- From mchan@broadcom.com Thu May 5 13:55:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 13:55:18 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45KtEOv016040 for ; Thu, 5 May 2005 13:55:14 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 05 May 2005 13:54:37 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 5 May 2005 13:54:40 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWQ00324; Thu, 5 May 2005 13:54:32 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA01124; Thu, 5 May 2005 13:54:32 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 May 2005 20:54:32 +0000 Received: from rh4 by nt-irva-0741; 05 May 2005 12:56:34 -0700 Subject: Re: Mystery packet killing tg3 From: "Michael Chan" To: "David S. Miller" cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050505113356.0f1b4c00.davem@davemloft.net> References: <20050504155143.1a78cb7a@dxpl.pdx.osdl.net> <1115245822.15156.78.camel@rh4> <20050505113356.0f1b4c00.davem@davemloft.net> Date: Thu, 05 May 2005 12:56:34 -0700 Message-ID: <1115322994.15156.98.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E64578721S2298103-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 2227 Lines: 77 On Thu, 2005-05-05 at 11:33 -0700, David S. Miller wrote: > I'm very tempted to add a silencer to these messages in these > cases. Something like the patch below. Michael, what do you > think? > > [TG3]: Elide tg3_stop_block messages when such events are normal. > > Signed-off-by: David S. Miller > Looks good. I'm adding this patch to further ignore the tg3_stop_block errors. [TG3]: Ignore tg3_stop_block() errors. tg3_stop_block() errors can be safely ignored since tg3_chip_reset() always follows tg3_stop_block() calls. Signed-off-by: Michael Chan diff -Nru f/drivers/net/tg3.c g/drivers/net/tg3.c --- f/drivers/net/tg3.c 2005-05-05 12:29:41.000000000 -0700 +++ g/drivers/net/tg3.c 2005-05-05 12:37:14.000000000 -0700 @@ -3725,8 +3725,6 @@ err |= tg3_stop_block(tp, SNDDATAC_MODE, SNDDATAC_MODE_ENABLE, silent); err |= tg3_stop_block(tp, DMAC_MODE, DMAC_MODE_ENABLE, silent); err |= tg3_stop_block(tp, SNDBDC_MODE, SNDBDC_MODE_ENABLE, silent); - if (err) - goto out; tp->mac_mode &= ~MAC_MODE_TDE_ENABLE; tw32_f(MAC_MODE, tp->mac_mode); @@ -3744,10 +3742,10 @@ printk(KERN_ERR PFX "tg3_abort_hw timed out for %s, " "TX_MODE_ENABLE will not clear MAC_TX_MODE=%08x\n", tp->dev->name, tr32(MAC_TX_MODE)); - return -ENODEV; + err |= -ENODEV; } - err = tg3_stop_block(tp, HOSTCC_MODE, HOSTCC_MODE_ENABLE, silent); + err |= tg3_stop_block(tp, HOSTCC_MODE, HOSTCC_MODE_ENABLE, silent); err |= tg3_stop_block(tp, WDMAC_MODE, WDMAC_MODE_ENABLE, silent); err |= tg3_stop_block(tp, MBFREE_MODE, MBFREE_MODE_ENABLE, silent); @@ -3756,15 +3754,12 @@ err |= tg3_stop_block(tp, BUFMGR_MODE, BUFMGR_MODE_ENABLE, silent); err |= tg3_stop_block(tp, MEMARB_MODE, MEMARB_MODE_ENABLE, silent); - if (err) - goto out; if (tp->hw_status) memset(tp->hw_status, 0, TG3_HW_STATUS_SIZE); if (tp->hw_stats) memset(tp->hw_stats, 0, sizeof(struct tg3_hw_stats)); -out: return err; } @@ -5063,9 +5058,7 @@ tg3_write_sig_pre_reset(tp, RESET_KIND_INIT); if (tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) { - err = tg3_abort_hw(tp, 1); - if (err) - return err; + tg3_abort_hw(tp, 1); } err = tg3_chip_reset(tp); From herbert@gondor.apana.org.au Thu May 5 14:33:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 14:33:14 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45LX9Ov019185 for ; Thu, 5 May 2005 14:33:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTnxc-0001Wk-00; Fri, 06 May 2005 07:32:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTnxX-0007ga-00; Fri, 06 May 2005 07:32:39 +1000 Date: Fri, 6 May 2005 07:32:39 +1000 To: jamal Cc: "David S. Miller" , netdev Subject: Re: resend patch: xfrm policybyid Message-ID: <20050505213239.GA29526@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115298877.7680.75.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 850 Lines: 33 On Thu, May 05, 2005 at 09:14:36AM -0400, jamal wrote: > > + if (policy->index) > + delpol = xfrm_policy_byid(dir, policy->index, 0); > + delpol2 = xfrm_policy_bysel(dir, &policy->selector, 0); > + > + /* must be unique in both index and selector */ > + if (delpol && delpol2) > + if (delpol != delpol2) > + goto pol_err; > > + if (delpol) > + delp = delpol; > + else > + delp = delpol2; > + > + if (delp && excl) { > + ret = -EEXIST; > + goto pol_err; > + } > + > + /* insert, sorted by prio*/ > write_lock_bh(&xfrm_policy_lock); This is still racy since delp can be killed by timers before you get the lock. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Thu May 5 14:37:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 14:37:10 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Lb2Ov019864 for ; Thu, 5 May 2005 14:37:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTnpo-0007OO-00; Thu, 05 May 2005 14:24:40 -0700 Date: Thu, 5 May 2005 14:24:40 -0700 From: "David S. Miller" To: acme@ghostprotocols.net Cc: arnaldo.melo@gmail.com, hch@lst.de, acme@conectiva.com.br, netdev@oss.sgi.com Subject: Re: [PATCH] add alloc_ltalkdev Message-Id: <20050505142440.106334bf.davem@davemloft.net> In-Reply-To: <39e6f6c70505041349f98590f@mail.gmail.com> References: <20050504192740.GA21409@lst.de> <39e6f6c70505041349f98590f@mail.gmail.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 410 Lines: 14 On Wed, 4 May 2005 17:49:03 -0300 Arnaldo Carvalho de Melo wrote: > On 5/4/05, Christoph Hellwig wrote: > > this matches the API used by other link layer like ethernet or token > > ring. > > > > Signed-off-by: Christoph Hellwig > > > > Index: drivers/net/appletalk/cops.c > > Acked-by: Arnaldo Carvalho de Melo Applied, thanks. From herbert@gondor.apana.org.au Thu May 5 14:38:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 14:38:12 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Lc8Ov020223 for ; Thu, 5 May 2005 14:38:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTo2T-0001ZQ-00; Fri, 06 May 2005 07:37:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTo2O-0007hc-00; Fri, 06 May 2005 07:37:40 +1000 Date: Fri, 6 May 2005 07:37:40 +1000 To: "David S. Miller" Cc: Anton Blanchard , netdev@oss.sgi.com Subject: Re: oops in ip_rcv Message-ID: <20050505213740.GB29526@gondor.apana.org.au> References: <20050505101542.GB7916@krispykreme> <20050505130904.GA16593@krispykreme> <20050505112624.3ffd7f3d.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505112624.3ffd7f3d.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 527 Lines: 15 On Thu, May 05, 2005 at 11:26:24AM -0700, David S. Miller wrote: > > Can you test out putting the init_ipv4_mibs() call right before > the comment: Could we delay the call of dev_add_pack(&ip_packet_type) until the very end of inet_init? That way we're guaranteed to not receive anything until it's ready. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Thu May 5 14:40:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 14:40:10 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Le3Ov021033 for ; Thu, 5 May 2005 14:40:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTnt2-0007P8-00; Thu, 05 May 2005 14:28:00 -0700 Date: Thu, 5 May 2005 14:28:00 -0700 From: "David S. Miller" To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: [IPV4]: multipath_wrandom.c GPF fixes Message-Id: <20050505142800.0b66405a.davem@davemloft.net> In-Reply-To: <427A828A.3080309@trash.net> References: <427A828A.3080309@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 388 Lines: 12 On Thu, 05 May 2005 22:31:06 +0200 Patrick McHardy wrote: > multipath_wrandom needs to use GFP_ATOMIC. I didn't fix this, because none of these allocations even check the return value so it's kind of pointless. There is zero error handling in the multipath modules. But I suppose it's best to get some of this fixed rather than none of it, so patch applied, thanks. From herbert@gondor.apana.org.au Thu May 5 14:45:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 14:45:25 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45LjIOv021864 for ; Thu, 5 May 2005 14:45:19 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTo9P-0001eT-00; Fri, 06 May 2005 07:44:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTo9N-0007lj-00; Fri, 06 May 2005 07:44:53 +1000 Date: Fri, 6 May 2005 07:44:53 +1000 To: "David S. Miller" Cc: Anton Blanchard , netdev@oss.sgi.com Subject: Re: oops in ip_rcv Message-ID: <20050505214453.GA29853@gondor.apana.org.au> References: <20050505101542.GB7916@krispykreme> <20050505130904.GA16593@krispykreme> <20050505112624.3ffd7f3d.davem@davemloft.net> <20050505213740.GB29526@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <20050505213740.GB29526@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1891 Lines: 83 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 06, 2005 at 07:37:40AM +1000, herbert wrote: > > Could we delay the call of dev_add_pack(&ip_packet_type) until > the very end of inet_init? That way we're guaranteed to not > receive anything until it's ready. This patch should do the trick. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/af_inet.c 1.86 vs edited ===== --- 1.86/net/ipv4/af_inet.c 2005-03-27 09:04:35 +10:00 +++ edited/net/ipv4/af_inet.c 2005-05-06 07:41:44 +10:00 @@ -1010,6 +1010,15 @@ static int ipv4_proc_init(void); extern void ipfrag_init(void); +/* + * IP protocol layer initialiser + */ + +static struct packet_type ip_packet_type = { + .type = __constant_htons(ETH_P_IP), + .func = ip_rcv, +}; + static int __init inet_init(void) { struct sk_buff *dummy_skb; @@ -1102,6 +1111,8 @@ ipv4_proc_init(); ipfrag_init(); + + dev_add_pack(&ip_packet_type); rc = 0; out: ===== net/ipv4/ip_output.c 1.82 vs edited ===== --- 1.82/net/ipv4/ip_output.c 2005-03-24 07:17:35 +11:00 +++ edited/net/ipv4/ip_output.c 2005-05-06 07:41:29 +10:00 @@ -1323,23 +1323,8 @@ ip_rt_put(rt); } -/* - * IP protocol layer initialiser - */ - -static struct packet_type ip_packet_type = { - .type = __constant_htons(ETH_P_IP), - .func = ip_rcv, -}; - -/* - * IP registers the packet type and then calls the subprotocol initialisers - */ - void __init ip_init(void) { - dev_add_pack(&ip_packet_type); - ip_rt_init(); inet_initpeers(); --C7zPtVaVf+AK4Oqc-- From davem@davemloft.net Thu May 5 14:45:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 14:45:30 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45LjQOv021883 for ; Thu, 5 May 2005 14:45:26 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTnyA-0007Pc-00; Thu, 05 May 2005 14:33:18 -0700 Date: Thu, 5 May 2005 14:33:18 -0700 From: "David S. Miller" To: Rick Jones Cc: m.iatrou@freemail.gr, netdev@oss.sgi.com Subject: Re: e1000 (?) jumbo frames performance issue Message-Id: <20050505143318.004566a9.davem@davemloft.net> In-Reply-To: <427A7F5B.8050704@hp.com> References: <200505051928.32496.m.iatrou@freemail.gr> <427A7F5B.8050704@hp.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1002 Lines: 19 On Thu, 05 May 2005 13:17:31 -0700 Rick Jones wrote: > I seem to recall that some of the stack defaults for SO_SNDBUF (IIRC) would > result in netperf sending 16KB at a time into the connection - once you sent the > MTU above 16K you may have started running into issues with Nagle and delayed > ACK? You could try some tests adding a test-specific -D to disable Nagle, or -C > to set TCP_CORK, or use -m to set the send size to say, 32KB. Yes, for one don't expect reasonable behavior if the MTU is near to or less than the send buffer size in use. Also, many of Nagle's notions start to fall apart at such high MTU settings. For example, all of Nagle (even with Minshall's modifications) basically define "small packet" as anything smaller than 1 MSS. So something to look into (besides increasing your send buffer size with jacking up the MTU so large) is changing Nagle to use some constant. Perhaps something like 512 bytes or smaller, or even 128 bytes or smaller. From davem@davemloft.net Thu May 5 14:47:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 14:47:08 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Ll4Ov022641 for ; Thu, 5 May 2005 14:47:04 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTnz2-0007Pq-00; Thu, 05 May 2005 14:34:12 -0700 Date: Thu, 5 May 2005 14:34:12 -0700 From: "David S. Miller" To: Patrick McHardy Cc: yasuyuki.kozakai@toshiba.co.jp, usagi-users@linux-ipv6.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, laforge@gnumonks.org, pb@bieringer.de Subject: Re: netfilter6: ICMPv6 type 143 doesn't match Message-Id: <20050505143412.0fe9ebca.davem@davemloft.net> In-Reply-To: <427A7FF5.4030900@trash.net> References: <6050E336B1A0D7D8E70C66F3@t1mobil.muc.aerasec.de> <200412270417.iBR4HZRG021429@toshiba.co.jp> <427A79C0.4020103@trash.net> <427A7FF5.4030900@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 865 Lines: 22 On Thu, 05 May 2005 22:20:05 +0200 Patrick McHardy wrote: > Patrick McHardy wrote: > > Yasuyuki Kozakai wrote: > > > >>Well, the Multicast Listener Report seems that skb->data != skb->nh.ipv6h > >>when interface is up. But IPv6 netfilter modules assumes that > >>skb->data == skb->nh.ipv6h like IPv4 netfilter modules. > >> > >>folks, is this wrong or bad asumption ? If so, I'll fix this problem in > >>many modules as follows. > > > > > > Sorry for getting back to this so late, I must have missed it at the > > time. Anyway, I think it would be safer to restore netfilters assumption > > by doing something like this patch. If everyone is fine with it I'm > > going to add it to my pending netfilter patches for 2.6.13. > > The last patch left some unreachable code. This looks OK with me, I hope it doesn't inadvertantly break anything. From davem@davemloft.net Thu May 5 14:54:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 14:54:10 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Ls6Ov023873 for ; Thu, 5 May 2005 14:54:06 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTo6b-0007W3-00; Thu, 05 May 2005 14:42:01 -0700 Date: Thu, 5 May 2005 14:42:01 -0700 From: "David S. Miller" To: "Michael Chan" Cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050505144201.389edfd4.davem@davemloft.net> In-Reply-To: <1115322994.15156.98.camel@rh4> References: <20050504155143.1a78cb7a@dxpl.pdx.osdl.net> <1115245822.15156.78.camel@rh4> <20050505113356.0f1b4c00.davem@davemloft.net> <1115322994.15156.98.camel@rh4> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 884 Lines: 29 On Thu, 05 May 2005 12:56:34 -0700 "Michael Chan" wrote: > On Thu, 2005-05-05 at 11:33 -0700, David S. Miller wrote: > > > I'm very tempted to add a silencer to these messages in these > > cases. Something like the patch below. Michael, what do you > > think? > > > > [TG3]: Elide tg3_stop_block messages when such events are normal. > > > > Signed-off-by: David S. Miller > > > > Looks good. I'm adding this patch to further ignore the tg3_stop_block > errors. > > [TG3]: Ignore tg3_stop_block() errors. > > tg3_stop_block() errors can be safely ignored since tg3_chip_reset() > always follows tg3_stop_block() calls. Your email client wrapped the lines in the patch Michael, please use attachments if you can't avoid this. Anyways, I applied both my patch and your's (by hand) to my tree and will push upstream. Thanks again. From rick.jones2@hp.com Thu May 5 14:55:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 14:55:05 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Lt0Ov024260 for ; Thu, 5 May 2005 14:55:02 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 2C63C2370; Thu, 5 May 2005 14:54:44 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id OAA10145; Thu, 5 May 2005 14:54:43 -0700 (PDT) Message-ID: <427A9623.5060402@hp.com> Date: Thu, 05 May 2005 14:54:43 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: m.iatrou@freemail.gr Subject: Re: e1000 (?) jumbo frames performance issue References: <200505051928.32496.m.iatrou@freemail.gr> <427A7F5B.8050704@hp.com> <20050505143318.004566a9.davem@davemloft.net> In-Reply-To: <20050505143318.004566a9.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1622 Lines: 33 David S. Miller wrote: > On Thu, 05 May 2005 13:17:31 -0700 > Rick Jones wrote: > > >>I seem to recall that some of the stack defaults for SO_SNDBUF (IIRC) would >>result in netperf sending 16KB at a time into the connection - once you sent the >>MTU above 16K you may have started running into issues with Nagle and delayed >>ACK? You could try some tests adding a test-specific -D to disable Nagle, or -C >>to set TCP_CORK, or use -m to set the send size to say, 32KB. > > > Yes, for one don't expect reasonable behavior if the MTU is near to or less > than the send buffer size in use. > > Also, many of Nagle's notions start to fall apart at such high MTU settings. > For example, all of Nagle (even with Minshall's modifications) basically define > "small packet" as anything smaller than 1 MSS. > > So something to look into (besides increasing your send buffer size with jacking > up the MTU so large) is changing Nagle to use some constant. Perhaps something like > 512 bytes or smaller, or even 128 bytes or smaller. IMO 128 is too small - 54 bytes of header to only 128 bytes of data seems "worthy" of encountering Nagle by default. If not 1460, then 536 feels nice - I would guess it likely was a common MSS "back in the day" when Nagle first proposed the algorithm/heuristic - assuming of course that the intent of the algorithm was to try to get the average header/header+data ratio to something around 0.9 (although IIRC, none of a 537 byte send would be delayed by Nagle since it was the size of the user's send being >= the MSS, so make that ~0.45 ?) rick jones From herbert@gondor.apana.org.au Thu May 5 15:03:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:03:08 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45M32Ov025483 for ; Thu, 5 May 2005 15:03:03 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DToQY-0001kg-00; Fri, 06 May 2005 08:02:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DToQW-0007pa-00; Fri, 06 May 2005 08:02:36 +1000 Date: Fri, 6 May 2005 08:02:36 +1000 To: "David S. Miller" Cc: Anton Blanchard , netdev@oss.sgi.com Subject: Re: oops in ip_rcv Message-ID: <20050505220236.GA30068@gondor.apana.org.au> References: <20050505101542.GB7916@krispykreme> <20050505130904.GA16593@krispykreme> <20050505112624.3ffd7f3d.davem@davemloft.net> <20050505213740.GB29526@gondor.apana.org.au> <20050505214453.GA29853@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <20050505214453.GA29853@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1495 Lines: 59 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 06, 2005 at 07:44:53AM +1000, herbert wrote: > On Fri, May 06, 2005 at 07:37:40AM +1000, herbert wrote: > > > > Could we delay the call of dev_add_pack(&ip_packet_type) until > > the very end of inet_init? That way we're guaranteed to not > > receive anything until it's ready. > > This patch should do the trick. Here is the version of IPv6. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/af_inet6.c 1.92 vs edited ===== --- 1.92/net/ipv6/af_inet6.c 2005-03-27 09:04:35 +10:00 +++ edited/net/ipv6/af_inet6.c 2005-05-06 08:01:36 +10:00 @@ -774,7 +774,6 @@ if (if6_proc_init()) goto proc_if6_fail; #endif - ipv6_packet_init(); ip6_route_init(); ip6_flowlabel_init(); err = addrconf_init(); @@ -791,6 +790,8 @@ /* Init v6 transport protocols. */ udpv6_init(); tcpv6_init(); + + ipv6_packet_init(); err = 0; out: return err; @@ -798,7 +799,6 @@ addrconf_fail: ip6_flowlabel_cleanup(); ip6_route_cleanup(); - ipv6_packet_cleanup(); #ifdef CONFIG_PROC_FS if6_proc_exit(); proc_if6_fail: --SLDf9lqlvOQaIe6s-- From hadi@cyberus.ca Thu May 5 15:17:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:17:41 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MHZOv026630 for ; Thu, 5 May 2005 15:17:36 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DToep-0005Br-Dq for netdev@oss.sgi.com; Thu, 05 May 2005 18:17:23 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DToel-0007cU-FJ; Thu, 05 May 2005 18:17:19 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev In-Reply-To: <20050505213239.GA29526@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Thu, 05 May 2005 18:17:15 -0400 Message-Id: <1115331436.8006.112.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 562 Lines: 22 On Fri, 2005-06-05 at 07:32 +1000, Herbert Xu wrote: > > + if (delp && excl) { > > + ret = -EEXIST; > > + goto pol_err; > > + } > > + > > + /* insert, sorted by prio*/ > > write_lock_bh(&xfrm_policy_lock); > > This is still racy since delp can be killed by timers before you get > the lock. Ok, Herbert - this is fixable: I take it moving the lock one up is sufficient; i dont mind if you fix it and add it to your list. BTW, are the event patches in Davems queue somewhere? I have a few ipsec ones (cosmetic) that i will send later. cheers, jamal From davem@davemloft.net Thu May 5 15:21:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:21:55 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MLqOv027271 for ; Thu, 5 May 2005 15:21:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DToXP-0007kF-00; Thu, 05 May 2005 15:09:43 -0700 Date: Thu, 5 May 2005 15:09:43 -0700 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, netdev@oss.sgi.com Subject: Re: oops in ip_rcv Message-Id: <20050505150943.566280f0.davem@davemloft.net> In-Reply-To: <20050505214453.GA29853@gondor.apana.org.au> References: <20050505101542.GB7916@krispykreme> <20050505130904.GA16593@krispykreme> <20050505112624.3ffd7f3d.davem@davemloft.net> <20050505213740.GB29526@gondor.apana.org.au> <20050505214453.GA29853@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 661 Lines: 19 On Fri, 6 May 2005 07:44:53 +1000 Herbert Xu wrote: > On Fri, May 06, 2005 at 07:37:40AM +1000, herbert wrote: > > > > Could we delay the call of dev_add_pack(&ip_packet_type) until > > the very end of inet_init? That way we're guaranteed to not > > receive anything until it's ready. > > This patch should do the trick. > > Signed-off-by: Herbert Xu Of course... But I don't want to apply this until Anton tells us how in the world he is receiving packets so early in the boot. If I put this patch in now, he may get lazy just like me and never try and figure out where they are coming from :) From dlstevens@us.ibm.com Thu May 5 15:26:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:26:52 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MQmOv027915; Thu, 5 May 2005 15:26:48 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j45MQV0c789126; Thu, 5 May 2005 18:26:31 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j45MQUna232756; Thu, 5 May 2005 16:26:30 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j45MQTQW004506; Thu, 5 May 2005 16:26:30 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j45MQTeO004501; Thu, 5 May 2005 16:26:29 -0600 In-Reply-To: <427A79C0.4020103@trash.net> To: Patrick McHardy Cc: laforge@gnumonks.org, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, netfilter-devel@lists.netfilter.org, pb@bieringer.de, usagi-users@linux-ipv6.org, Yasuyuki Kozakai MIME-Version: 1.0 Subject: Re: netfilter6: ICMPv6 type 143 doesn't match X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 5 May 2005 15:26:27 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 05/05/2005 16:26:29, Serialize complete at 05/05/2005 16:26:29 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 365 Lines: 9 I'll look at it in more detail and let you know if I see any problems, but I wouldn't call it "igmpv6", which doesn't exist. "MLD" is the equivalent in IPv6. There certainly are existing references to "igmp6" in the Linux code-- that just isn't the name of the protocol. :-) suggest: change to mld_dev_queue_xmit(). +-DLS From davem@davemloft.net Thu May 5 15:29:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:29:29 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MTOOv028510 for ; Thu, 5 May 2005 15:29:24 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DToem-0007lQ-00; Thu, 05 May 2005 15:17:20 -0700 Date: Thu, 5 May 2005 15:17:20 -0700 From: "David S. Miller" To: Rick Jones Cc: netdev@oss.sgi.com, m.iatrou@freemail.gr Subject: Re: e1000 (?) jumbo frames performance issue Message-Id: <20050505151720.075e4a91.davem@davemloft.net> In-Reply-To: <427A9623.5060402@hp.com> References: <200505051928.32496.m.iatrou@freemail.gr> <427A7F5B.8050704@hp.com> <20050505143318.004566a9.davem@davemloft.net> <427A9623.5060402@hp.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 634 Lines: 14 On Thu, 05 May 2005 14:54:43 -0700 Rick Jones wrote: > assuming of course that the intent of the algorithm was to try to get the average header/header+data ratio to something > around 0.9 (although IIRC, none of a 537 byte send would be delayed by Nagle > since it was the size of the user's send being >= the MSS, so make that ~0.45 ?) It tries to hold smaller packets back in hopes to get some more sendmsg() calls which will bunch up some more data before all outstanding data is ACK'd. It's meant for terminal protocols and other chatty sequences. It was not designed with 16K MSS frame sizes in mind. From davem@davemloft.net Thu May 5 15:30:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:30:38 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MUVOv028918 for ; Thu, 5 May 2005 15:30:32 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTofl-0007m1-00; Thu, 05 May 2005 15:18:21 -0700 Date: Thu, 5 May 2005 15:18:20 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: resend patch: xfrm policybyid Message-Id: <20050505151820.672b89fa.davem@davemloft.net> In-Reply-To: <1115331436.8006.112.camel@localhost.localdomain> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 268 Lines: 8 On Thu, 05 May 2005 18:17:15 -0400 jamal wrote: > BTW, are the event patches in Davems queue somewhere? > I have a few ipsec ones (cosmetic) that i will send later. I'm not queueing 2.6.13 material yet. 2.6.12 bug fixes are a full time job yet :-) From kaber@trash.net Thu May 5 15:32:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:32:54 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MWoOv029659 for ; Thu, 5 May 2005 15:32:51 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DTotT-0008A9-Iy; Fri, 06 May 2005 00:32:31 +0200 Message-ID: <427A9EFF.5030907@trash.net> Date: Fri, 06 May 2005 00:32:31 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: David Stevens CC: laforge@gnumonks.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, pb@bieringer.de, usagi-users@linux-ipv6.org, Yasuyuki Kozakai Subject: Re: netfilter6: ICMPv6 type 143 doesn't match References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 453 Lines: 16 David Stevens wrote: > I'll look at it in more detail and let you know if I see any problems, Thanks. Is there a reason why these packets never hit the POST_ROUTING hook? > but I wouldn't call it "igmpv6", which doesn't exist. "MLD" is the > equivalent in IPv6. There certainly are existing references to > "igmp6" in the Linux code-- that just isn't the name of the protocol. :-) > > suggest: change to mld_dev_queue_xmit(). Done. Regards Patrick From kaber@trash.net Thu May 5 15:33:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:33:36 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MXWOv029767 for ; Thu, 5 May 2005 15:33:33 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DTouC-0008Ah-1o; Fri, 06 May 2005 00:33:16 +0200 Message-ID: <427A9F2B.2060804@trash.net> Date: Fri, 06 May 2005 00:33:15 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [IPV4]: multipath_wrandom.c GPF fixes References: <427A828A.3080309@trash.net> <20050505142800.0b66405a.davem@davemloft.net> In-Reply-To: <20050505142800.0b66405a.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 381 Lines: 13 David S. Miller wrote: > I didn't fix this, because none of these allocations even > check the return value so it's kind of pointless. > > There is zero error handling in the multipath modules. > > But I suppose it's best to get some of this fixed rather > than none of it, so patch applied, thanks. The first one is already checked, I'll look into the others. Regards Patrick From kaber@trash.net Thu May 5 15:36:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:37:01 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MawOv030855 for ; Thu, 5 May 2005 15:36:58 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DToxQ-0008BH-0B; Fri, 06 May 2005 00:36:36 +0200 Message-ID: <427A9FF3.7060408@trash.net> Date: Fri, 06 May 2005 00:36:35 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Harald Welte CC: Herbert Xu , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, "David S. Miller" Subject: Re: CONFIG_NETFILTER_DEBUG spew References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> <4274F2ED.9080404@trash.net> <20050505111457.GS30482@sunbeam.de.gnumonks.org> In-Reply-To: <20050505111457.GS30482@sunbeam.de.gnumonks.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 623 Lines: 18 Harald Welte wrote: > On Sun, May 01, 2005 at 05:17:01PM +0200, Patrick McHardy wrote: > >>You're right. I'm tempted to remove the entire nf_debug stuff, >>as far as I know it has never found a real bug. But for now >>I've only fixed the warning. > > > yes, I second that change. At the same time, we should get rid of all > the lockhelp.h stuff that makes the netfilter code use non-standard lock > primitives. I've removed nf_debug. As for lockhelp.h, I'm still undecided whether I should try to make rwlock debugging a feature of standard rwlocks or else what to do with all the rwlock assertions. Regards Patrick From davem@davemloft.net Thu May 5 15:43:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:43:35 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MhVOv031569 for ; Thu, 5 May 2005 15:43:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTosI-0007sQ-00; Thu, 05 May 2005 15:31:18 -0700 Date: Thu, 5 May 2005 15:31:18 -0700 From: "David S. Miller" To: Patrick McHardy Cc: dlstevens@us.ibm.com, laforge@gnumonks.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, pb@bieringer.de, usagi-users@linux-ipv6.org, yasuyuki.kozakai@toshiba.co.jp Subject: Re: netfilter6: ICMPv6 type 143 doesn't match Message-Id: <20050505153118.0d26297c.davem@davemloft.net> In-Reply-To: <427A9EFF.5030907@trash.net> References: <427A9EFF.5030907@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 710 Lines: 20 On Fri, 06 May 2005 00:32:31 +0200 Patrick McHardy wrote: > David Stevens wrote: > > I'll look at it in more detail and let you know if I see any problems, > > Thanks. Is there a reason why these packets never hit the POST_ROUTING > hook? I think it is an oversight rather than intentional. The NDISC lookup stuff wrt. routing went back and forth implementation wise. We used to use a seperate routing table for NDISC entries, but that caused all kinds of problems wrt. IPSEC (which the seperate routing table was ironically meant to fix) so that got undone and now NDISC routes and normal routes exist in one table. So I think this oversight is just fallout from all of those changes. From davem@davemloft.net Thu May 5 15:47:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:47:43 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MlcOv032194 for ; Thu, 5 May 2005 15:47:40 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTowQ-0007t1-00 for ; Thu, 05 May 2005 15:35:34 -0700 Date: Thu, 5 May 2005 15:35:32 -0700 From: "David S. Miller" To: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-Id: <20050505153532.30159bd5.davem@davemloft.net> In-Reply-To: <20050504230731.12be1bc3.davem@davemloft.net> References: <20050504230731.12be1bc3.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 219 Lines: 6 Is anyone testing this or is everyone too scared? :-) A lot of people wanted this TSO stuff fixed, so I spent time implementing the fix. Yet nobody seems interested enough to even say "it works" or "it's busted" :-/ From kaber@trash.net Thu May 5 15:50:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:50:38 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MoZOv032737 for ; Thu, 5 May 2005 15:50:36 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DTpAP-0008Ru-Hv; Fri, 06 May 2005 00:50:01 +0200 Message-ID: <427AA319.1040906@trash.net> Date: Fri, 06 May 2005 00:50:01 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: dlstevens@us.ibm.com, laforge@gnumonks.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, pb@bieringer.de, usagi-users@linux-ipv6.org, yasuyuki.kozakai@toshiba.co.jp Subject: Re: netfilter6: ICMPv6 type 143 doesn't match References: <427A9EFF.5030907@trash.net> <20050505153118.0d26297c.davem@davemloft.net> In-Reply-To: <20050505153118.0d26297c.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------000109000507000500000406" X-archive-position: 801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 3682 Lines: 129 This is a multi-part message in MIME format. --------------000109000507000500000406 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David S. Miller wrote: > On Fri, 06 May 2005 00:32:31 +0200 > Patrick McHardy wrote: > >>Is there a reason why these packets never hit the POST_ROUTING hook? > > I think it is an oversight rather than intentional. > > The NDISC lookup stuff wrt. routing went back and forth > implementation wise. We used to use a seperate routing > table for NDISC entries, but that caused all kinds of > problems wrt. IPSEC (which the seperate routing table > was ironically meant to fix) so that got undone and now > NDISC routes and normal routes exist in one table. > > So I think this oversight is just fallout from all of > those changes. Thanks, I've added a call to NF_HOOK(NF_IP6_POST_ROUTING) to the patch. --------------000109000507000500000406 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: net/ipv6/mcast.c =================================================================== --- 2cfdb1827d9c176f4df42619c693e7b990a61963/net/ipv6/mcast.c (mode:100644 sha1:393b6e6f50a9626e2894c9a5abd8dafd903e5eba) +++ uncommitted/net/ipv6/mcast.c (mode:100644) @@ -1280,15 +1280,6 @@ return NULL; skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - - ndisc_mc_map(&mld2_all_mcr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6,ha,NULL,size) < 0) { - kfree_skb(skb); - return NULL; - } - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* : @@ -1312,6 +1303,31 @@ return skb; } +static inline int mld_dev_queue_xmit2(struct sk_buff *skb) +{ + struct net_device *dev = skb->dev; + + if (dev->hard_header) { + unsigned char ha[MAX_ADDR_LEN]; + int err; + + ndisc_mc_map(&skb->nh.ipv6h->daddr, ha, dev, 1); + err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); + if (err < 0) { + IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); + kfree_skb(skb); + return err; + } + } + return dev_queue_xmit(skb); +} + +static inline int mld_dev_queue_xmit(struct sk_buff *skb) +{ + return NF_HOOK(PF_INET6, NF_IP6_POST_ROUTING, skb, NULL, skb->dev, + mld_dev_queue_xmit2); +} + static void mld_sendpack(struct sk_buff *skb) { struct ipv6hdr *pip6 = skb->nh.ipv6h; @@ -1329,7 +1345,7 @@ pmr->csum = csum_ipv6_magic(&pip6->saddr, &pip6->daddr, mldlen, IPPROTO_ICMPV6, csum_partial(skb->h.raw, mldlen, 0)); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + mld_dev_queue_xmit); if (!err) { ICMP6_INC_STATS(idev,ICMP6_MIB_OUTMSGS); IP6_INC_STATS(IPSTATS_MIB_OUTMCASTPKTS); @@ -1635,12 +1651,6 @@ } skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - ndisc_mc_map(snd_addr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, full_len) < 0) - goto out; - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* : @@ -1668,7 +1678,7 @@ idev = in6_dev_get(skb->dev); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + mld_dev_queue_xmit); if (!err) { if (type == ICMPV6_MGM_REDUCTION) ICMP6_INC_STATS(idev, ICMP6_MIB_OUTGROUPMEMBREDUCTIONS); @@ -1682,10 +1692,6 @@ if (likely(idev != NULL)) in6_dev_put(idev); return; - -out: - IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); - kfree_skb(skb); } static int ip6_mc_del1_src(struct ifmcaddr6 *pmc, int sfmode, --------------000109000507000500000406-- From jdmason@us.ibm.com Thu May 5 15:56:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:56:56 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45MurOv000927 for ; Thu, 5 May 2005 15:56:53 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j45Mua4I444702 for ; Thu, 5 May 2005 18:56:36 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j45Muana256344 for ; Thu, 5 May 2005 16:56:36 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j45MuZnJ018309 for ; Thu, 5 May 2005 16:56:36 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j45MuZIx018173; Thu, 5 May 2005 16:56:35 -0600 From: Jon Mason Organization: IBM To: "David S. Miller" Subject: Re: [PATCH] TSO Reloaded Date: Thu, 5 May 2005 17:56:25 -0500 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <20050504230731.12be1bc3.davem@davemloft.net> <20050505153532.30159bd5.davem@davemloft.net> In-Reply-To: <20050505153532.30159bd5.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505051756.25186.jdmason@us.ibm.com> X-archive-position: 802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 445 Lines: 17 On Thursday 05 May 2005 05:35 pm, David S. Miller wrote: > > Is anyone testing this or is everyone too scared? :-) > > A lot of people wanted this TSO stuff fixed, so I spent > time implementing the fix. Yet nobody seems interested > enough to even say "it works" or "it's busted" :-/ I can give it a quick sniff on e1000 and r8169 (on amd64), though only to verify that its works (ie, no real perf). Is that acceptable? Thanks, Jon From romieu@fr.zoreil.com Thu May 5 15:58:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 15:58:09 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45Mw3Ov001241 for ; Thu, 5 May 2005 15:58:04 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j45Mv2BN018391; Fri, 6 May 2005 00:57:02 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j45MuuId018390; Fri, 6 May 2005 00:56:56 +0200 Date: Fri, 6 May 2005 00:56:56 +0200 From: Francois Romieu To: Andrew Morton Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: [patch linux-2.6.12-rc3-mm3 1/7] r8169: de-obfuscate supported PCI ID Message-ID: <20050505225656.GA11200@electric-eye.fr.zoreil.com> References: <20050504221057.1e02a402.akpm@osdl.org> <20050505115502.GA4414@electric-eye.fr.zoreil.com> <20050505110052.62c1c2cb.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505110052.62c1c2cb.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 697 Lines: 22 De-obfuscate supported PCI ID Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-440 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-440 2005-05-06 00:37:16.695925125 +0200 +++ b/drivers/net/r8169.c 2005-05-06 00:38:40.051448306 +0200 @@ -174,9 +174,9 @@ const static struct { #undef _R static struct pci_device_id rtl8169_pci_tbl[] = { - {0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x1186, 0x4300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0x16ec, 0x0116, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), }, + { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), }, + { PCI_DEVICE(0x16ec, 0x0116), }, {0,}, }; _ From romieu@fr.zoreil.com Thu May 5 16:10:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:10:09 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NA2Ov003499 for ; Thu, 5 May 2005 16:10:03 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j45N6cjG018843; Fri, 6 May 2005 01:06:39 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j45N6XHT018830; Fri, 6 May 2005 01:06:33 +0200 Date: Fri, 6 May 2005 01:06:31 +0200 From: Francois Romieu To: Andrew Morton Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: [patch linux-2.6.12-rc3-mm3 7/7] r8169: cleanup (function args) Message-ID: <20050505230631.GF18393@electric-eye.fr.zoreil.com> References: <20050504221057.1e02a402.akpm@osdl.org> <20050505115502.GA4414@electric-eye.fr.zoreil.com> <20050505110052.62c1c2cb.akpm@osdl.org> <20050505225656.GA11200@electric-eye.fr.zoreil.com> <20050505225905.GA18393@electric-eye.fr.zoreil.com> <20050505230016.GB18393@electric-eye.fr.zoreil.com> <20050505230154.GC18393@electric-eye.fr.zoreil.com> <20050505230313.GD18393@electric-eye.fr.zoreil.com> <20050505230418.GE18393@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505230418.GE18393@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 810 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2220 Lines: 65 minor cleanup - more consistent function arguments; - rtl8169_rx_interrupt() o the error condition should be rare; o goto removal. Signed-off-by: Richard Dawe Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-580 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-580 2005-05-06 00:40:32.031341377 +0200 +++ b/drivers/net/r8169.c 2005-05-06 00:40:32.059336850 +0200 @@ -457,10 +457,10 @@ static void rtl8169_hw_start(struct net_ static int rtl8169_close(struct net_device *dev); static void rtl8169_set_rx_mode(struct net_device *dev); static void rtl8169_tx_timeout(struct net_device *dev); -static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); +static struct net_device_stats *rtl8169_get_stats(struct net_device *dev); static int rtl8169_rx_interrupt(struct net_device *, struct rtl8169_private *, void __iomem *); -static int rtl8169_change_mtu(struct net_device *netdev, int new_mtu); +static int rtl8169_change_mtu(struct net_device *dev, int new_mtu); static void rtl8169_down(struct net_device *dev); #ifdef CONFIG_R8169_NAPI @@ -2360,7 +2360,7 @@ rtl8169_rx_interrupt(struct net_device * rx_left = NUM_RX_DESC + tp->dirty_rx - cur_rx; rx_left = rtl8169_rx_quota(rx_left, (u32) dev->quota); - while (rx_left > 0) { + for (; rx_left > 0; rx_left--, cur_rx++) { unsigned int entry = cur_rx % NUM_RX_DESC; struct RxDesc *desc = tp->RxDescArray + entry; u32 status; @@ -2370,7 +2370,7 @@ rtl8169_rx_interrupt(struct net_device * if (status & DescOwn) break; - if (status & RxRES) { + if (unlikely(status & RxRES)) { if (netif_msg_rx_err(tp)) { printk(KERN_INFO "%s: Rx ERROR. status = %08x\n", @@ -2397,7 +2397,7 @@ rtl8169_rx_interrupt(struct net_device * tp->stats.rx_dropped++; tp->stats.rx_length_errors++; rtl8169_mark_to_asic(desc, tp->rx_buf_sz); - goto move_on; + continue; } rtl8169_rx_csum(skb, desc); @@ -2426,9 +2426,6 @@ rtl8169_rx_interrupt(struct net_device * tp->stats.rx_bytes += pkt_size; tp->stats.rx_packets++; } -move_on: - cur_rx++; - rx_left--; } count = cur_rx - tp->cur_rx; _ From herbert@gondor.apana.org.au Thu May 5 16:12:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:12:50 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NCdOv004009 for ; Thu, 5 May 2005 16:12:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTpVu-0002M5-00; Fri, 06 May 2005 09:12:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTpVq-0007yD-00; Fri, 06 May 2005 09:12:10 +1000 Date: Fri, 6 May 2005 09:12:10 +1000 To: jamal Cc: "David S. Miller" , netdev Subject: Re: resend patch: xfrm policybyid Message-ID: <20050505231210.GA30574@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115331436.8006.112.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1009 Lines: 26 On Thu, May 05, 2005 at 06:17:15PM -0400, jamal wrote: > > > This is still racy since delp can be killed by timers before you get > > the lock. > > Ok, Herbert - this is fixable: I take it moving the lock one up is > sufficient; i dont mind if you fix it and add it to your list. I know it's fixable, but the problem is that the fix is likely to make this function even uglier :) What I still don't get is who would be using this feature. No I don't mean an example of how the ip command can do this :) I mean a real-world scenario why someone or some KM would want do this and why it can't be done easily with what we've already got. BTW I very much like part where you added the dir to the policy structure. So if that can be split off I'd have no objections in seeing it included. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From anton@ozlabs.org Thu May 5 16:14:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:14:03 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NDwOv004536 for ; Thu, 5 May 2005 16:14:00 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id EC4F267B2F; Fri, 6 May 2005 09:13:41 +1000 (EST) Date: Fri, 6 May 2005 09:11:41 +1000 From: Anton Blanchard To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-ID: <20050505231141.GB16593@krispykreme> References: <20050504230731.12be1bc3.davem@davemloft.net> <20050505153532.30159bd5.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505153532.30159bd5.davem@davemloft.net> User-Agent: Mutt/1.5.9i X-archive-position: 812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 322 Lines: 11 > Is anyone testing this or is everyone too scared? :-) > > A lot of people wanted this TSO stuff fixed, so I spent > time implementing the fix. Yet nobody seems interested > enough to even say "it works" or "it's busted" :-/ When I can get my machines booting to userspace Im definitely going to try it out :) Anton From davem@davemloft.net Thu May 5 16:17:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:17:33 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NHSOv005369 for ; Thu, 5 May 2005 16:17:29 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTpPI-00086m-00; Thu, 05 May 2005 16:05:24 -0700 Date: Thu, 5 May 2005 16:05:24 -0700 From: "David S. Miller" To: "Michael Chan" Cc: akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc2 3/3] tg3: Fix tg3_restart_ints() Message-Id: <20050505160524.4946082a.davem@davemloft.net> In-Reply-To: <1114470490.4917.85.camel@rh4> References: <1114463061.4917.34.camel@rh4> <1114463351.4917.39.camel@rh4> <1114464194.4917.52.camel@rh4> <20050425151816.1910b2ba.davem@davemloft.net> <1114466185.4917.61.camel@rh4> <20050425162416.2b4edd43.davem@davemloft.net> <1114470490.4917.85.camel@rh4> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1972 Lines: 47 On Mon, 25 Apr 2005 16:08:10 -0700 "Michael Chan" wrote: > I think removing the read back of intr. mailbox in tg3_interrupt() will > have the following impact: > > On machines where PIOs are posted by the chipset for a long time, the > write to the intr. mailbox will not reach the 57xx chip for a long time. > As a result, the interrupt signal INTA will remain asserted until the > mailbox write is flushed to the 57xx chip. So this can cause > tg3_interrupt() to be called multiple times until the INTA signal is de- > asserted. I think at most it will be called 2 times since on the second > time, the status block updated bit will not be set and we will read the > PCI state register, causing the mailbox write to be flushed. > > As you described, the netif_rx_schedule() will be called again the > second time in tg3_interrupt() but it will do nothing. > > So I think reading the intr. mailbox will help performance by > eliminating multiple calls to tg3_interrupt() in the scenario I > described, but is a rather high price to pay on other systems where PIOs > are not posted for very long. I think the second interrupt will not happen, here is why. The platform specific code invokes the interrupt handler roughly like so: local_irq_enable(); ret = action->handler(irq, dev_id, regs); interrupt_controller->ack_irq(irq); That ACK of the IRQ in the interrupt controller register set will be STRONGLY ordered wrt. the tg3 mailbox register write. Therefore, the mailbox write would reach the tg3 chip, then the IRQ would be ACK'd in the interrupt controller, in that exact order. There may be a tiny window, in the case where the interrupt controller is processor-near and the PCI bus is far away, where the IRQ unmask could occur before the tg3 register write reaches the PCI bus. But that would be 1) rare and 2) handled properly if it did occur (as you described). I therefore see no reason not to remove this register readback. From niv@us.ibm.com Thu May 5 16:18:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:18:51 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NIlOv005811 for ; Thu, 5 May 2005 16:18:48 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j45NIVua237070 for ; Thu, 5 May 2005 19:18:31 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j45NIVUA371470 for ; Thu, 5 May 2005 17:18:31 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j45NIUUa004651 for ; Thu, 5 May 2005 17:18:30 -0600 Received: from [9.47.22.127] (dyn9047022127.beaverton.ibm.com [9.47.22.127]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j45NIUOr004636; Thu, 5 May 2005 17:18:30 -0600 Message-ID: <427AA9C5.8080605@us.ibm.com> Date: Thu, 05 May 2005 16:18:29 -0700 From: Nivedita Singhvi User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded References: <20050504230731.12be1bc3.davem@davemloft.net> <20050505153532.30159bd5.davem@davemloft.net> In-Reply-To: <20050505153532.30159bd5.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 341 Lines: 15 David S. Miller wrote: > Is anyone testing this or is everyone too scared? :-) > > A lot of people wanted this TSO stuff fixed, so I spent > time implementing the fix. Yet nobody seems interested > enough to even say "it works" or "it's busted" :-/ > It's in the queue, Dave :). Let you know if there are problems... thanks, Nivedita From davem@davemloft.net Thu May 5 16:26:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:26:44 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NQdOv011147 for ; Thu, 5 May 2005 16:26:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTpYF-0008Cx-00; Thu, 05 May 2005 16:14:39 -0700 Date: Thu, 5 May 2005 16:14:39 -0700 From: "David S. Miller" To: Anton Blanchard Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-Id: <20050505161439.2755fcb6.davem@davemloft.net> In-Reply-To: <20050505231141.GB16593@krispykreme> References: <20050504230731.12be1bc3.davem@davemloft.net> <20050505153532.30159bd5.davem@davemloft.net> <20050505231141.GB16593@krispykreme> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 475 Lines: 15 On Fri, 6 May 2005 09:11:41 +1000 Anton Blanchard wrote: > > > Is anyone testing this or is everyone too scared? :-) > > > > A lot of people wanted this TSO stuff fixed, so I spent > > time implementing the fix. Yet nobody seems interested > > enough to even say "it works" or "it's busted" :-/ > > When I can get my machines booting to userspace Im definitely going to > try it out :) Do you need anything besides that early-packet fix from Herbert? From davem@davemloft.net Thu May 5 16:28:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:28:14 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NSBOv011713 for ; Thu, 5 May 2005 16:28:11 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTpZj-0008DB-00; Thu, 05 May 2005 16:16:11 -0700 Date: Thu, 5 May 2005 16:16:10 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-Id: <20050505161610.16e3ccdc.davem@davemloft.net> In-Reply-To: <20050505162448.3278aa8f@dxpl.pdx.osdl.net> References: <20050504230731.12be1bc3.davem@davemloft.net> <20050505153532.30159bd5.davem@davemloft.net> <20050505162448.3278aa8f@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 633 Lines: 19 On Thu, 5 May 2005 16:24:48 -0700 Stephen Hemminger wrote: > On Thu, 5 May 2005 15:35:32 -0700 > "David S. Miller" wrote: > > > > > Is anyone testing this or is everyone too scared? :-) > > > > A lot of people wanted this TSO stuff fixed, so I spent > > time implementing the fix. Yet nobody seems interested > > enough to even say "it works" or "it's busted" :-/ > > It works on tg3 that is too stupid to do TSO at least. More tests coming It's off by default, "ethtool -K eth0 tso on" is necessary. I'll change that soon. Or do you have a chip revision that really can't do TSO? From brazilnut@us.ibm.com Thu May 5 16:42:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:42:14 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NgAOv012955 for ; Thu, 5 May 2005 16:42:10 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j45NfqLT016066 for ; Thu, 5 May 2005 19:41:52 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j45Nfp8Y112746 for ; Thu, 5 May 2005 19:41:51 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j45Nfp1J016525 for ; Thu, 5 May 2005 19:41:51 -0400 Received: from DYN319661.beaverton.ibm.com (dyn9047022144.beaverton.ibm.com [9.47.22.144]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j45Nfp5D016209 for ; Thu, 5 May 2005 19:41:51 -0400 Received: by DYN319661.beaverton.ibm.com (Postfix, from userid 1000) id A59E922A168; Thu, 5 May 2005 16:41:28 -0700 (PDT) Date: Thu, 5 May 2005 16:41:28 -0700 From: Don Fry To: netdev@oss.sgi.com Subject: RFC ethtool usage Message-ID: <20050505234128.GA21736@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 906 Lines: 30 One of the pieces of information that is useful for me when debugging problems with the pcnet32 driver, is which chip version the problem occurs with (79C973, 79C976, etc). Since the chip has no firmware, how badly would I be flamed, if I modified the driver to return the string (which is currently printed on boot), as the 'firmware-version'? --- orig.pcnet32.c Mon May 2 15:12:02 2005 +++ pcnet32.c Mon May 2 15:13:38 2005 @@ -559,6 +559,7 @@ static void pcnet32_get_drvinfo(struct n strcpy (info->driver, DRV_NAME); strcpy (info->version, DRV_VERSION); + strncpy(info->fw_version, lp->name, sizeof(info->fw_version) - 1); if (lp->pci_dev) strcpy (info->bus_info, pci_name(lp->pci_dev)); else So the output looked like: $ ethtool -i eth0 driver: pcnet32 version: 1.30j firmware-version: PCnet/PRO 79C976 bus-info: 0000:00:01.0 $ -- Don Fry brazilnut@us.ibm.com From mchan@broadcom.com Thu May 5 16:49:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:49:44 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NnfOv013734 for ; Thu, 5 May 2005 16:49:41 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 05 May 2005 16:49:21 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 5 May 2005 16:49:15 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWR16633; Thu, 5 May 2005 16:49:11 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id QAA29876; Thu, 5 May 2005 16:49:11 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 May 2005 23:49:11 +0000 Received: from rh4 by nt-irva-0741; 05 May 2005 15:51:14 -0700 Subject: Re: [PATCH 2.6.12-rc2 3/3] tg3: Fix tg3_restart_ints() From: "Michael Chan" To: "David S. Miller" cc: akepner@sgi.com, netdev@oss.sgi.com In-Reply-To: <20050505160524.4946082a.davem@davemloft.net> References: <1114463061.4917.34.camel@rh4> <1114463351.4917.39.camel@rh4> <1114464194.4917.52.camel@rh4> <20050425151816.1910b2ba.davem@davemloft.net> <1114466185.4917.61.camel@rh4> <20050425162416.2b4edd43.davem@davemloft.net> <1114470490.4917.85.camel@rh4> <20050505160524.4946082a.davem@davemloft.net> Date: Thu, 05 May 2005 15:51:14 -0700 Message-ID: <1115333474.15156.119.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E646E8B0UW2264728-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1870 Lines: 51 On Thu, 2005-05-05 at 16:05 -0700, David S. Miller wrote: > > I think the second interrupt will not happen, here is why. > > The platform specific code invokes the interrupt handler roughly > like so: > > local_irq_enable(); > ret = action->handler(irq, dev_id, regs); > interrupt_controller->ack_irq(irq); > > That ACK of the IRQ in the interrupt controller register > set will be STRONGLY ordered wrt. the tg3 mailbox register > write. > But no PCI cycles will necessarily be generated during the ack_irq() call. The apic_write() call or the I/O cycles to the 8259 PIC or other cycles to ack the interrupt controller are not PCI cycles and therefore may not necessarily flush the tg3 mailbox write PCI cycle. There is no spec that I'm aware of that requires posted cycles to be flushed when INTx is asserted or the IRQ is acknowledged. I am not arguing that the read-back should not be removed. I think most systems will benefit from its removal. But there may be some systems with long posted cycles that will be adversely (performance-wise) affected by its removal. BTW, when we use MSI, all these problems will disappear. The interrupt will arrive in order and since MSI is equivalent to an edge interrupt, it will not remain asserted like INTx and there is no need to flush the interrupt mailbox. > Therefore, the mailbox write would reach the tg3 chip, then > the IRQ would be ACK'd in the interrupt controller, in that > exact order. > > There may be a tiny window, in the case where the interrupt > controller is processor-near and the PCI bus is far away, where > the IRQ unmask could occur before the tg3 register write reaches > the PCI bus. But that would be 1) rare and 2) handled properly if > it did occur (as you described). Agreed. It will be handled properly. > > I therefore see no reason not to remove this register readback. > From herbert@gondor.apana.org.au Thu May 5 16:50:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:50:06 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j45NnwOv013759 for ; Thu, 5 May 2005 16:49:59 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTq5w-0002Zl-00; Fri, 06 May 2005 09:49:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTq5f-00083u-00; Fri, 06 May 2005 09:49:11 +1000 Date: Fri, 6 May 2005 09:49:11 +1000 To: "David S. Miller" Cc: anton@samba.org, netdev@oss.sgi.com Subject: Re: oops in ip_rcv Message-ID: <20050505234911.GA30980@gondor.apana.org.au> References: <20050505101542.GB7916@krispykreme> <20050505130904.GA16593@krispykreme> <20050505112624.3ffd7f3d.davem@davemloft.net> <20050505213740.GB29526@gondor.apana.org.au> <20050505214453.GA29853@gondor.apana.org.au> <20050505150943.566280f0.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505150943.566280f0.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 478 Lines: 12 On Thu, May 05, 2005 at 03:09:43PM -0700, David S. Miller wrote: > > Of course... But I don't want to apply this until Anton > tells us how in the world he is receiving packets so > early in the boot. Alright, that's simply a matter of dropping a BUG into netif_rx. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From arjan@infradead.org Thu May 5 16:53:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 16:53:47 -0700 (PDT) Received: from s-utl01-nypop.stsn.com (s-utl01-nypop.stsn.com [199.106.90.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j45NrfOw015148 for ; Thu, 5 May 2005 16:53:41 -0700 Received: from s-utl01-nypop.stsn.com ([127.0.0.1]) by s-utl01-nypop.stsn.com (SMSSMTP 4.0.0.59) with SMTP id M2005050519522619807 ; Thu, 05 May 2005 19:52:26 -0400 Received: from [10.57.123.92] ([10.57.123.92]) by s-utl01-nypop.stsn.com; Thu, 5 May 2005 19:52:24 -0400 Subject: Re: [PATCH 2/3] add open iscsi netlink interface to iscsi transport class From: Arjan van de Ven To: Herbert Xu Cc: YOSHIFUJI Hideaki / ???? , michaelc@cs.wisc.edu, linux-scsi@vger.kernel.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 05 May 2005 07:45:47 -0400 Message-Id: <1115293547.6052.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-archive-position: 822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arjan@infradead.org Precedence: bulk X-list: netdev Content-Length: 564 Lines: 17 On Thu, 2005-05-05 at 21:39 +1000, Herbert Xu wrote: > YOSHIFUJI Hideaki / ???? wrote: > > In article <42798AC1.2010308@cs.wisc.edu> (at Wed, 04 May 2005 19:53:53 -0700), Mike Christie says: > > > >> +struct iscsi_uevent { > > : > >> +} __attribute__ ((aligned (sizeof(unsigned long)))); > > > > I think it'd be better to use sizeof(uint64_t) or something. > > Is there a benefit in aligning on 64-bit boundaries for 32-bit platforms? why align at all as opposed to just letting the compiler figure it out. From anton@ozlabs.org Thu May 5 18:07:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 18:07:13 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46174Ov019321 for ; Thu, 5 May 2005 18:07:07 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id AF8F167B3D; Fri, 6 May 2005 11:06:47 +1000 (EST) Date: Fri, 6 May 2005 11:03:17 +1000 From: Anton Blanchard To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-ID: <20050506010317.GB8255@krispykreme> References: <20050504230731.12be1bc3.davem@davemloft.net> <20050505153532.30159bd5.davem@davemloft.net> <20050505231141.GB16593@krispykreme> <20050505161439.2755fcb6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505161439.2755fcb6.davem@davemloft.net> User-Agent: Mutt/1.5.9i X-archive-position: 823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 129 Lines: 7 > Do you need anything besides that early-packet fix from > Herbert? Nope. I'll spin the patch up now and report back. Anton From anton@ozlabs.org Thu May 5 18:07:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 18:07:15 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46174Ov019322 for ; Thu, 5 May 2005 18:07:07 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id B502E67B44; Fri, 6 May 2005 11:06:47 +1000 (EST) Date: Fri, 6 May 2005 11:02:46 +1000 From: Anton Blanchard To: "David S. Miller" Cc: Herbert Xu , netdev@oss.sgi.com Subject: Re: oops in ip_rcv Message-ID: <20050506010246.GA8255@krispykreme> References: <20050505101542.GB7916@krispykreme> <20050505130904.GA16593@krispykreme> <20050505112624.3ffd7f3d.davem@davemloft.net> <20050505213740.GB29526@gondor.apana.org.au> <20050505214453.GA29853@gondor.apana.org.au> <20050505150943.566280f0.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505150943.566280f0.davem@davemloft.net> User-Agent: Mutt/1.5.9i X-archive-position: 824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 1925 Lines: 49 Hi, > Of course... But I don't want to apply this until Anton > tells us how in the world he is receiving packets so > early in the boot. > > If I put this patch in now, he may get lazy just like me > and never try and figure out where they are coming from :) You know me too well :) I start getting acenic irqs straight after the card is initialised: acenic.c: v0.92 08/05/2002 Jes Sorensen, linux-acenic@SunSITE.dk http://home.cern.ch/~jes/gige/acenic.html 0001:40:0c.0: Alteon AceNIC Gigabit Ethernet at 0xd7fcc000, irq 45 Tigon II (Rev. 6), Firmware: 12.4.11, MAC: 00:02:55:9a:0c:bd PCI bus width: 64 bits, speed: 66MHz, latency: 72 clks 0001:40:0c.0: Firmware up and running drivers/net/ibmveth.c: ibmveth: IBM i/pSeries Virtual Ethernet Driver 1.03 eth1: Optical link UP (Full Duplex, Flow Control: ) netconsole: not configured, aborting Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx sym0: <875> rev cpu 0x0: Vector: 700 (Program Check) at [c00000000fffxbb10] pc: c00000000043a6fc: .netif_rx+0x1c/0x4 00 lr: c0000000002aae20: .ace_interrupt+0x1c0/t0xac0 sp: c00000000fffbd90 msr: a000000000029032 current = 0xc0000000005ca500 paca = 0xc000000000585400 pid = 0, comm = swapper kernel BUG in netif_rx at 0net/core/dev.c:1443! 0:mon> t c0000000002aae20 .ace_interrupt+0x1c0/0xac0 c000000000084ca4 .handle_IRQ_event+0x84/0x100 c00000000001457c .call_handle_IRQ_event+0x14/0x24 c00000000000fa74 .ppc_irq_dispatch_handler+0x224/0x3f0 c00000000000fcb8 .do_IRQ+0x78/0xf0 c00000000000ae34 hardware_interrupt_entry+0x8/0x54 --- Exception: 501 (Hardware Interrupt) at c000000000010270 .default_idle+0xa0/0x130 c000000000010074 .cpu_idle+0x34/0x50 c00000000000c03c .rest_init+0x3c/0x60 c0000000004d3904 .start_kernel+0x2a4/0x320 c00000000000bfb4 .__setup_cpu_power3+0x0/0x4 From hadi@cyberus.ca Thu May 5 18:15:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 18:15:50 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j461FlOv020855 for ; Thu, 5 May 2005 18:15:48 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DTrRF-0004wP-80 for netdev@oss.sgi.com; Thu, 05 May 2005 21:15:33 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTrR8-0007aW-7a; Thu, 05 May 2005 21:15:26 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev In-Reply-To: <20050505231210.GA30574@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Thu, 05 May 2005 21:15:22 -0400 Message-Id: <1115342122.7660.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1525 Lines: 45 On Fri, 2005-06-05 at 09:12 +1000, Herbert Xu wrote: > On Thu, May 05, 2005 at 06:17:15PM -0400, jamal wrote: > > > > > This is still racy since delp can be killed by timers before you get > > > the lock. > > > > Ok, Herbert - this is fixable: I take it moving the lock one up is > > sufficient; i dont mind if you fix it and add it to your list. > > I know it's fixable, but the problem is that the fix is likely to > make this function even uglier :) > I am giving you the opportunity now to fix it your way;-> Rewrite if you want. I promise not to hassle you ;-> > What I still don't get is who would be using this feature. > No I > don't mean an example of how the ip command can do this :) Oh, wait, ip doesnt count as an app?;-> Now, lets say it doesnt. The incosistency i see is not something i have seen in any table logic in the kernel or anywhere else. a) I am allowed to set the id to say a 1 only to be overruled by the kernel which sets it to 8? b) The table is searchable by id - except i just cant set the search key. So for the sake of correctness, at least, this needs to be fixed. > I mean > a real-world scenario why someone or some KM would want do this and > why it can't be done easily with what we've already got. > Thats a moot point really Herbert. I can think of a few apps that can use this, but it shouldnt matter: The main point is correctness. You know what else you can do is get rid of the index totaly - that would be fine with me. What do you say to that? cheers, jamal From herbert@gondor.apana.org.au Thu May 5 18:31:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 18:32:02 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j461VtOv021981 for ; Thu, 5 May 2005 18:31:56 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTrgg-00036e-00; Fri, 06 May 2005 11:31:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTrgc-0008HL-00; Fri, 06 May 2005 11:31:26 +1000 Date: Fri, 6 May 2005 11:31:25 +1000 To: jamal Cc: "David S. Miller" , netdev Subject: Re: resend patch: xfrm policybyid Message-ID: <20050506013125.GA31780@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115342122.7660.25.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1246 Lines: 34 On Thu, May 05, 2005 at 09:15:22PM -0400, jamal wrote: > > Thats a moot point really Herbert. I can think of a few apps that can > use this, but it shouldnt matter: The main point is correctness. Ah, that's why we're talking past each other :) You're looking at it as a bug where we aren't setting the index when it is provided by the user. The way I'm seeing it is that the index is simply a read-only value that's only provided by the kernel to the user as an aid in locating policies. In this respect it's just like xfrm_policy->curlft, it can be read by the user by it's only ever written by the kernel. So whatever value the user provides us when adding/updating a policy is simply ignored. Another way to look at it is that it's a handle that we're returning to the user so that they can talk about policies in an unambiguous way. Does this make sense? > You know what else you can do is get rid of the index totaly - that > would be fine with me. What do you say to that? That would break user API/ABI so no :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From pablo@eurodev.net Thu May 5 18:33:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 18:33:18 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j461XBOv022244 for ; Thu, 5 May 2005 18:33:12 -0700 Received: from [85.136.100.66] by smtp06.retemail.es (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050506013254.PWUX26907.smtp06.retemail.es@[85.136.100.66]>; Fri, 6 May 2005 03:32:54 +0200 Message-ID: <427AC96E.2020208@eurodev.net> Date: Fri, 06 May 2005 03:33:34 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: netdev@oss.sgi.com, jamal Subject: Re: [RFC] textsearch infrastructure + skb_find_text() References: <20050504234036.GH18452@postel.suug.ch> <427A51A2.8090600@eurodev.net> <20050505174224.GB25977@postel.suug.ch> In-Reply-To: <20050505174224.GB25977@postel.suug.ch> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 2446 Lines: 65 Thomas Graf wrote: > * Pablo Neira <427A51A2.8090600@eurodev.net> 2005-05-05 19:02 > >>- A custom destroy function in ts_ops. > > > Sure, can be added once we need it. Currently none of my > algorithms allocate anything on their own. Might be worth > to change the API and replace textsearch_put with textesearch_destroy > also freeing the configuration though. that's fine >>- I don't see a way to look for matches in fragments. I mean, say we've >>got "dancing " in a fragment and "chicken" in the next one. Currently we >>don't get a match. > > > This is implemented in skb_find_text(), I just looked through rusty's > code and it's very simliar so we could make the args in ts_state a > union of long args[6] and char cb[XXX] so we can store skb_iter > in there. Yes, we could just use one of those args in ts_state to store if we found a partial match or not. >>I've been reworking the framework for string matching that I sent you >>two/three months ago, you've definitely worked on a good base. Since >>then I've introduced a lot of changes and actually I've been testing it >>(ick, that means that we've clashed!). > > > I don't think so, my approach is quite different and allows for > optimized text searches over fragments, multiple skbs, etc without > any hacks around the fragment borders. Boyer-Moore requires such hack to look for matches around the fragment borders. But no problem, such hack will go inside the bm_find function. > It's a lot more generic > allowing it to be in lib/ so it can be used from other subsystem > as well. Sure, your approach is definitely more generic because I just thought about using such string matching framework for net apps, it's different from that point of view, but I still see things that reminds me to my proposed framework, say that ts_state thing ;). >>I think that I can merge both works and then roll on. I still need more >>time to study more in deep your proposition. > > > Sure go ahead but please don't merge it into netfilter, a) the core > really is supposed to be in lib, and b) I don't want any netfilter > dependencies in my ematches. No problem mate. Just curious about something, since this stuff will live under lib, what kind of applications in kernel space could use this string matching framework ? I bet that non-net kernel guys will surely ask about it ;-> I'll be back working on this stuff next week, expect some feedback. -- Pablo From hadi@cyberus.ca Thu May 5 19:10:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 19:10:32 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j462ASOv024511 for ; Thu, 5 May 2005 19:10:28 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DTsIA-0000ua-Fw for netdev@oss.sgi.com; Thu, 05 May 2005 22:10:14 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTsI3-0000vL-Lj; Thu, 05 May 2005 22:10:07 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev In-Reply-To: <20050506013125.GA31780@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Thu, 05 May 2005 22:10:03 -0400 Message-Id: <1115345403.7660.49.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 828 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2232 Lines: 65 On Fri, 2005-06-05 at 11:31 +1000, Herbert Xu wrote: > On Thu, May 05, 2005 at 09:15:22PM -0400, jamal wrote: > > > > Thats a moot point really Herbert. I can think of a few apps that can > > use this, but it shouldnt matter: The main point is correctness. > > Ah, that's why we're talking past each other :) You're looking at > it as a bug where we aren't setting the index when it is provided > by the user. It is a bug based on what common usage of what indices are used for in tables. They are search keys. > The way I'm seeing it is that the index is simply a read-only value > that's only provided by the kernel to the user as an aid in locating > policies. > IOW, they are search keys. Search keys are unique and read-write. You cant just invent you rules Herbert ;-> The typical rules are simple for indices: a) you specify the index - if it doesnt conflict, it is accepted. You can then use that key to search in the future b) you dont specifiy the index, the kernel specifies one for you which doesnt conflict. We do b) only and override a). Look at these as array subscripts if you want an analogy. You can reference an empty array slot but not one thats being used. If you dont specify the array index then the kernel will provide one for you. > In this respect it's just like xfrm_policy->curlft, it can be read > by the user by it's only ever written by the kernel. So whatever > value the user provides us when adding/updating a policy is simply > ignored. > Theres a difference;-> you cant search by curlft i.e its not a key. > Another way to look at it is that it's a handle that we're returning > to the user so that they can talk about policies in an unambiguous way. > > Does this make sense? > You are emphasizing the uniqueuness feature of a search key ;-> > > You know what else you can do is get rid of the index totaly - that > > would be fine with me. What do you say to that? > > That would break user API/ABI so no :) Understood. There are a lot of things i think need fixing in both the SPD and SAD that i am not touching - this is certainly one that i dont want to leave alone. The other issues i will leave to another discussion without distracting this one;-> cheers, jamal From hadi@cyberus.ca Thu May 5 19:20:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 19:20:40 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j462KbOv025674 for ; Thu, 5 May 2005 19:20:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DTsRs-00032w-M1 for netdev@oss.sgi.com; Thu, 05 May 2005 20:20:16 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTsRw-0002dM-G6; Thu, 05 May 2005 22:20:20 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev In-Reply-To: <1115345403.7660.49.camel@localhost.localdomain> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> Content-Type: text/plain Organization: unknown Date: Thu, 05 May 2005 22:20:16 -0400 Message-Id: <1115346016.7660.55.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 337 Lines: 12 On Thu, 2005-05-05 at 22:10 -0400, jamal wrote: > > Look at these as array subscripts if you want an analogy. You can > reference an empty array slot but not one thats being used. If you dont > specify the array index then the kernel will provide one for you. It wasnt clear - but the above description is for adding. cheers, jamal From jgarzik@pobox.com Thu May 5 19:33:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 19:33:17 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j462X6Ov027189 for ; Thu, 5 May 2005 19:33:08 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.50 #1 (Red Hat Linux)) id 1DTsdy-00026v-GC; Fri, 06 May 2005 02:32:47 +0000 Message-ID: <427AD74B.10904@pobox.com> Date: Thu, 05 May 2005 22:32:43 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: netdev@oss.sgi.com Subject: Re: RFC ethtool usage References: <20050505234128.GA21736@us.ibm.com> In-Reply-To: <20050505234128.GA21736@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1073 Lines: 35 Don Fry wrote: > One of the pieces of information that is useful for me when debugging > problems with the pcnet32 driver, is which chip version the problem > occurs with (79C973, 79C976, etc). > > Since the chip has no firmware, how badly would I be flamed, if I > modified the driver to return the string (which is currently printed > on boot), as the 'firmware-version'? > > --- orig.pcnet32.c Mon May 2 15:12:02 2005 > +++ pcnet32.c Mon May 2 15:13:38 2005 > @@ -559,6 +559,7 @@ static void pcnet32_get_drvinfo(struct n > > strcpy (info->driver, DRV_NAME); > strcpy (info->version, DRV_VERSION); > + strncpy(info->fw_version, lp->name, sizeof(info->fw_version) - 1); > if (lp->pci_dev) > strcpy (info->bus_info, pci_name(lp->pci_dev)); > else > > So the output looked like: > $ ethtool -i eth0 > driver: pcnet32 > version: 1.30j > firmware-version: PCnet/PRO 79C976 > bus-info: 0000:00:01.0 Convenient in the short term, but misleading in the long run, IMO. Surely you can get this info from an ethtool register dump? Jeff From davem@davemloft.net Thu May 5 20:13:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 20:13:44 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j463DXOv029321 for ; Thu, 5 May 2005 20:13:34 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTt5Q-0001FB-00; Thu, 05 May 2005 20:01:08 -0700 Date: Thu, 5 May 2005 20:01:08 -0700 From: "David S. Miller" To: Jeff Garzik Cc: brazilnut@us.ibm.com, netdev@oss.sgi.com Subject: Re: RFC ethtool usage Message-Id: <20050505200108.1e45f860.davem@davemloft.net> In-Reply-To: <427AD74B.10904@pobox.com> References: <20050505234128.GA21736@us.ibm.com> <427AD74B.10904@pobox.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 318 Lines: 10 On Thu, 05 May 2005 22:32:43 -0400 Jeff Garzik wrote: > Convenient in the short term, but misleading in the long run, IMO. > > Surely you can get this info from an ethtool register dump? I agree. It might not be a bad idea to formalize this in some generic "ethtool_chip_info" block, however. From davem@davemloft.net Thu May 5 20:17:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 20:17:14 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j463H8Ov029902 for ; Thu, 5 May 2005 20:17:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTt2u-0001F0-00; Thu, 05 May 2005 19:58:32 -0700 Date: Thu, 5 May 2005 19:58:31 -0700 From: "David S. Miller" To: Anton Blanchard Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: oops in ip_rcv Message-Id: <20050505195831.6c747c32.davem@davemloft.net> In-Reply-To: <20050506010246.GA8255@krispykreme> References: <20050505101542.GB7916@krispykreme> <20050505130904.GA16593@krispykreme> <20050505112624.3ffd7f3d.davem@davemloft.net> <20050505213740.GB29526@gondor.apana.org.au> <20050505214453.GA29853@gondor.apana.org.au> <20050505150943.566280f0.davem@davemloft.net> <20050506010246.GA8255@krispykreme> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 419 Lines: 12 On Fri, 6 May 2005 11:02:46 +1000 Anton Blanchard wrote: > I start getting acenic irqs straight after the card is initialised: Thanks, this needs to be fixed. I bet some people would be very unpleased to know that an inteface that hasn't been brought up at least once will sit and receive broadcast frames :-/ Anyways, for now I'll put Herbert's ipv4 and ipv6 patches in. Thanks a lot Anton :-) From leonid.grossman@neterion.com Thu May 5 20:21:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 20:21:54 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j463LpOv001707 for ; Thu, 5 May 2005 20:21:51 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j463KxOC013096; Thu, 5 May 2005 23:20:59 -0400 (EDT) Received: from lgt40 ([10.16.16.165]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j463KvVG013576; Thu, 5 May 2005 23:20:57 -0400 (EDT) Message-Id: <200505060320.j463KvVG013576@guinness.s2io.com> From: "Leonid Grossman" To: "'David S. Miller'" , Subject: RE: [PATCH] TSO Reloaded Date: Thu, 5 May 2005 20:20:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050505153532.30159bd5.davem@davemloft.net> Thread-Index: AcVRxHd8lVA89Cp9SaCF6KPt6kjE5QAJYyOQ X-Scanned-By: MIMEDefang 2.34 X-archive-position: 833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 579 Lines: 19 We will be testing on 10GbE NICs in the next couple weeks; will let you know. BTW - any plans for IPv6 support? > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > Behalf Of David S. Miller > Sent: Thursday, May 05, 2005 3:36 PM > To: netdev@oss.sgi.com > Subject: Re: [PATCH] TSO Reloaded > > > Is anyone testing this or is everyone too scared? :-) > > A lot of people wanted this TSO stuff fixed, so I spent > time implementing the fix. Yet nobody seems interested > enough to even say "it works" or "it's busted" :-/ From davem@davemloft.net Thu May 5 20:42:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 20:43:01 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j463gvOv003169 for ; Thu, 5 May 2005 20:42:57 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTtYC-0001Rk-00; Thu, 05 May 2005 20:30:52 -0700 Date: Thu, 5 May 2005 20:30:52 -0700 From: "David S. Miller" To: "Leonid Grossman" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-Id: <20050505203052.059125eb.davem@davemloft.net> In-Reply-To: <200505060320.j463KvVG013576@guinness.s2io.com> References: <20050505153532.30159bd5.davem@davemloft.net> <200505060320.j463KvVG013576@guinness.s2io.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 932 Lines: 22 On Thu, 5 May 2005 20:20:56 -0700 "Leonid Grossman" wrote: > We will be testing on 10GbE NICs in the next couple weeks; will let you > know. > BTW - any plans for IPv6 support? What exactly does your NIC expect? Do you use the NETIF_F_HW_CSUM flag to indicate generic checksumming support? Otherwise, there is no other way to support ipv6 checksum offload at the moment, and that is a requirement for ipv6 TSO. For TSO, the ipv6 header handling seems very non-trivial. What is supposed to happen in cases where certain optional extension headers should be present in some of the frames but not the others? A specification of how your NIC support ipv6 TSO is necessary in order for support to be written, see? Seems like you are the most qualified person to write the support, therefore :-) Really, it isn't that hard and you have something on which to test whatever you write, whereas I don't. From jdmason@us.ibm.com Thu May 5 20:54:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 20:54:13 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j463s4Ov004039 for ; Thu, 5 May 2005 20:54:11 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j463rm0c228864 for ; Thu, 5 May 2005 23:53:48 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j463rlna256636 for ; Thu, 5 May 2005 21:53:47 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j463rlvT021907 for ; Thu, 5 May 2005 21:53:47 -0600 Received: from sig-9-49-134-45.mts.ibm.com (sig-9-49-134-45.mts.ibm.com [9.49.134.45]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j463rkr2021904; Thu, 5 May 2005 21:53:47 -0600 From: Jon Mason Reply-To: jdmason@us.ibm.com Organization: IBM To: "David S. Miller" Subject: Re: [PATCH] TSO Reloaded Date: Thu, 5 May 2005 22:53:09 -0500 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <20050504230731.12be1bc3.davem@davemloft.net> <200505051756.25186.jdmason@us.ibm.com> <20050505154955.0dcb4b38.davem@davemloft.net> In-Reply-To: <20050505154955.0dcb4b38.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505052253.10301.jdmason@us.ibm.com> X-archive-position: 835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 374 Lines: 11 On Thursday 05 May 2005 05:49 pm, David S. Miller wrote: > On Thu, 5 May 2005 17:56:25 -0500 > > Jon Mason wrote: > > I can give it a quick sniff on e1000 and r8169 (on amd64), though only to > > verify that its works (ie, no real perf). Is that acceptable? > > Yes. It worked fine for both r8169 and e1000 on my amd64 box (running 2.6.12-rc3-mm2). From davem@davemloft.net Thu May 5 21:29:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 21:29:49 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j464TeOv005815 for ; Thu, 5 May 2005 21:29:44 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTuHP-0001kQ-00; Thu, 05 May 2005 21:17:35 -0700 Date: Thu, 5 May 2005 21:17:35 -0700 From: "David S. Miller" To: mchan@broadcom.com Cc: netdev@oss.sgi.com Subject: [TG3]: Add tagged status support Message-Id: <20050505211735.3829cff2.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 10377 Lines: 306 I've been meaning to do this for a long time. This adds tagged status support. With this, we don't need to poke the chip 10 times per second via the timer to keep from losing interrupts. Michael, I didn't know what needs to be done wrt. MSI here. So I didn't touch the MSI code until I understand things better, which likely means that this patch breaks MSI (actually, I think it will cause the MSI case to generate interrupts endlessly). My best hunch is that all MSI supporting chips support tagged status, therefore I should just make the tg3_msi() interrupt handler do the tp->last_tag stuff. We should also integrate the coalescing tweaks we did last week after we smoothe this patch out. I noticed that we were doing the 5705 status block fetch 10 times per second instead of once per second. That's fixed here too. I also removed the MAILBOX readback in the normal interrupt handling paths. Network processing overhead minded folks, particular the SGI NUMA people (hint hint) should really really check out this patch :-) It is against current 2.6.x sources. Signed-off-by: David S. Miller --- 1/drivers/net/tg3.c.~1~ 2005-05-05 17:15:59.000000000 -0700 +++ 2/drivers/net/tg3.c 2005-05-05 21:11:41.000000000 -0700 @@ -420,7 +420,8 @@ static void tg3_enable_ints(struct tg3 * { tw32(TG3PCI_MISC_HOST_CTRL, (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); - tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000); + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + (tp->last_tag << 24)); tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); tg3_cond_int(tp); @@ -455,7 +456,8 @@ static void tg3_restart_ints(struct tg3 { tw32(TG3PCI_MISC_HOST_CTRL, (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); - tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000); + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + tp->last_tag << 24); mmiowb(); if (tg3_has_work(tp)) @@ -2977,11 +2979,56 @@ static irqreturn_t tg3_interrupt(int irq */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); + sblk->status &= ~SD_STATUS_UPDATED; + + if (likely(tg3_has_work(tp))) + netif_rx_schedule(dev); /* schedule NAPI poll */ + else { + /* no work, shared interrupt perhaps? re-enable + * interrupts, and flush that PCI write + */ + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + 0x00000000); + tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + } + } else { /* shared interrupt */ + handled = 0; + } + + spin_unlock_irqrestore(&tp->lock, flags); + + return IRQ_RETVAL(handled); +} + +static irqreturn_t tg3_interrupt_tagged(int irq, void *dev_id, struct pt_regs *regs) +{ + struct net_device *dev = dev_id; + struct tg3 *tp = netdev_priv(dev); + struct tg3_hw_status *sblk = tp->hw_status; + unsigned long flags; + unsigned int handled = 1; + + spin_lock_irqsave(&tp->lock, flags); + + /* In INTx mode, it is possible for the interrupt to arrive at + * the CPU before the status block posted prior to the interrupt. + * Reading the PCI State register will confirm whether the + * interrupt is ours and will flush the status block. + */ + if ((sblk->status & SD_STATUS_UPDATED) || + !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) { /* - * Flush PCI write. This also guarantees that our - * status block has been flushed to host memory. + * writing any value to intr-mbox-0 clears PCI INTA# and + * chip-internal interrupt pending events. + * writing non-zero to intr-mbox-0 additional tells the + * NIC to stop sending us irqs, engaging "in-intr-handler" + * event coalescing. */ - tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + 0x00000001); + + tp->last_tag = sblk->status_tag; + sblk->status &= ~SD_STATUS_UPDATED; if (likely(tg3_has_work(tp))) @@ -2991,7 +3038,7 @@ static irqreturn_t tg3_interrupt(int irq * interrupts, and flush that PCI write */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, - 0x00000000); + tp->last_tag << 24); tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); } } else { /* shared interrupt */ @@ -5446,6 +5493,7 @@ static int tg3_reset_hw(struct tg3 *tp) tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0); tr32(MAILBOX_INTERRUPT_0); + tp->last_tag = 0; if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { tw32_f(DMAC_MODE, DMAC_MODE_ENABLE); @@ -5723,31 +5771,33 @@ static void tg3_timer(unsigned long __op spin_lock_irqsave(&tp->lock, flags); spin_lock(&tp->tx_lock); - /* All of this garbage is because when using non-tagged - * IRQ status the mailbox/status_block protocol the chip - * uses with the cpu is race prone. - */ - if (tp->hw_status->status & SD_STATUS_UPDATED) { - tw32(GRC_LOCAL_CTRL, - tp->grc_local_ctrl | GRC_LCLCTRL_SETINT); - } else { - tw32(HOSTCC_MODE, tp->coalesce_mode | - (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW)); - } + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) { + /* All of this garbage is because when using non-tagged + * IRQ status the mailbox/status_block protocol the chip + * uses with the cpu is race prone. + */ + if (tp->hw_status->status & SD_STATUS_UPDATED) { + tw32(GRC_LOCAL_CTRL, + tp->grc_local_ctrl | GRC_LCLCTRL_SETINT); + } else { + tw32(HOSTCC_MODE, tp->coalesce_mode | + (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW)); + } - if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) { - tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER; - spin_unlock(&tp->tx_lock); - spin_unlock_irqrestore(&tp->lock, flags); - schedule_work(&tp->reset_task); - return; + if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) { + tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER; + spin_unlock(&tp->tx_lock); + spin_unlock_irqrestore(&tp->lock, flags); + schedule_work(&tp->reset_task); + return; + } } - if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) - tg3_periodic_fetch_stats(tp); - /* This part only runs once per second. */ if (!--tp->timer_counter) { + if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) + tg3_periodic_fetch_stats(tp); + if (tp->tg3_flags & TG3_FLAG_USE_LINKCHG_REG) { u32 mac_stat; int phy_event; @@ -5846,9 +5896,13 @@ static int tg3_test_interrupt(struct tg3 if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) err = request_irq(tp->pdev->irq, tg3_msi, SA_SAMPLE_RANDOM, dev->name, dev); - else - err = request_irq(tp->pdev->irq, tg3_interrupt, + else { + irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + fn = tg3_interrupt_tagged; + err = request_irq(tp->pdev->irq, fn, SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + } if (err) return err; @@ -5900,9 +5954,14 @@ static int tg3_test_msi(struct tg3 *tp) tp->tg3_flags2 &= ~TG3_FLG2_USING_MSI; - err = request_irq(tp->pdev->irq, tg3_interrupt, - SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + { + irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + fn = tg3_interrupt_tagged; + err = request_irq(tp->pdev->irq, fn, + SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + } if (err) return err; @@ -5959,9 +6018,14 @@ static int tg3_open(struct net_device *d if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) err = request_irq(tp->pdev->irq, tg3_msi, SA_SAMPLE_RANDOM, dev->name, dev); - else - err = request_irq(tp->pdev->irq, tg3_interrupt, + else { + irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + fn = tg3_interrupt_tagged; + + err = request_irq(tp->pdev->irq, fn, SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + } if (err) { if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) { @@ -5980,9 +6044,16 @@ static int tg3_open(struct net_device *d tg3_halt(tp, 1); tg3_free_rings(tp); } else { - tp->timer_offset = HZ / 10; - tp->timer_counter = tp->timer_multiplier = 10; - tp->asf_counter = tp->asf_multiplier = (10 * 120); + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + tp->timer_offset = HZ; + else + tp->timer_offset = HZ / 10; + + BUG_ON(tp->timer_offset > HZ); + tp->timer_counter = tp->timer_multiplier = + (HZ / tp->timer_offset); + tp->asf_counter = tp->asf_multiplier = + ((HZ / tp->timer_offset) * 120); init_timer(&tp->timer); tp->timer.expires = jiffies + tp->timer_offset; @@ -8422,15 +8493,7 @@ static int __devinit tg3_get_invariants( if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG; - /* Only 5701 and later support tagged irq status mode. - * Also, 5788 chips cannot use tagged irq status. - * - * However, since we are using NAPI avoid tagged irq status - * because the interrupt condition is more difficult to - * fully clear in that mode. - */ tp->coalesce_mode = 0; - if (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_AX && GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_BX) tp->coalesce_mode |= HOSTCC_MODE_32BYTE; @@ -8494,6 +8557,18 @@ static int __devinit tg3_get_invariants( grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788M)) tp->tg3_flags2 |= TG3_FLG2_IS_5788; + if (!(tp->tg3_flags2 & TG3_FLG2_IS_5788) && + (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700)) + tp->tg3_flags |= TG3_FLAG_TAGGED_STATUS; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) { + tp->coalesce_mode |= (HOSTCC_MODE_CLRTICK_RXBD | + HOSTCC_MODE_CLRTICK_TXBD); + + tp->misc_host_ctrl |= MISC_HOST_CTRL_TAGGED_STATUS; + pci_write_config_dword(tp->pdev, TG3PCI_MISC_HOST_CTRL, + tp->misc_host_ctrl); + } + /* these are limited to 10/100 only */ if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 && (grc_misc_cfg == 0x8000 || grc_misc_cfg == 0x4000)) || --- 1/drivers/net/tg3.h.~1~ 2005-05-05 17:15:59.000000000 -0700 +++ 2/drivers/net/tg3.h 2005-05-05 20:58:56.000000000 -0700 @@ -2023,6 +2023,7 @@ struct tg3 { struct tg3_hw_status *hw_status; dma_addr_t status_mapping; + u32 last_tag; u32 msg_enable; @@ -2068,6 +2069,7 @@ struct tg3 { u32 rx_offset; u32 tg3_flags; +#define TG3_FLAG_TAGGED_STATUS 0x00000001 #define TG3_FLAG_TXD_MBOX_HWBUG 0x00000002 #define TG3_FLAG_RX_CHECKSUMS 0x00000004 #define TG3_FLAG_USE_LINKCHG_REG 0x00000008 From anton@ozlabs.org Thu May 5 21:38:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 21:38:37 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j464cXOv006602 for ; Thu, 5 May 2005 21:38:34 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id C4C3A67B40; Fri, 6 May 2005 14:38:16 +1000 (EST) Date: Fri, 6 May 2005 14:36:53 +1000 From: Anton Blanchard To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-ID: <20050506043653.GD8255@krispykreme> References: <20050504230731.12be1bc3.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504230731.12be1bc3.davem@davemloft.net> User-Agent: Mutt/1.5.9i X-archive-position: 837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 1725 Lines: 45 Hi Dave, > Ok, here it is, first draft of the new TSO handling > I promised so long ago :-) I was lazy and waited until > today to implement the entire thing. I fired off socklib (just a TCP stream test) and things look much better. I dumped the size of the data+frags for each packet that the e1000 created. It looks like frags are working in multiples of MTU, but we also have to split when we hit page boundaries. Is this expected? BTW the 4 bytes at the end is due to an e1000 workaround for a hw bug. Thanks for working on this :) Anton data: 42 frags: data: 74 frags: data: 66 frags: 1448 1444 4 data: 66 frags: 1024 424 1444 4 data: 66 frags: 1448 512 932 4 data: 66 frags: 1448 1444 4 data: 66 frags: 1448 data: 66 frags: 1448 1024 424 1448 1448 512 936 1444 4 data: 66 frags: 1448 1444 4 data: 66 frags: 1448 1024 420 4 data: 66 frags: 1448 1444 4 data: 66 frags: 512 936 1448 1448 1448 1448 1024 424 1448 1448 512 936 1444 4 data: 66 frags: 1448 1448 1444 4 data: 66 frags: 1024 424 1448 1448 512 936 1448 1448 1444 4 data: 66 frags: 1448 1024 424 1448 1448 372 4 data: 66 frags: 128 1320 1448 1152 296 1448 1448 640 808 1444 4 data: 66 frags: 1448 128 1320 1444 4 data: 66 frags: 1152 296 1448 1448 640 804 4 data: 66 frags: 1448 1448 128 1316 4 data: 66 frags: 1448 1152 296 1444 4 data: 66 frags: 1448 640 808 1448 1448 128 1320 1448 1152 296 1448 1448 640 808 1448 1444 4 data: 66 frags: 128 1320 1448 1152 296 1448 1444 4 data: 66 frags: 640 808 1448 1444 4 data: 66 frags: 128 1320 1448 1152 296 1448 1448 372 4 data: 66 frags: 256 1192 1448 1280 168 1448 1448 768 680 1448 1448 256 1192 1448 1280 168 1444 4 data: 66 frags: 1448 768 680 1448 1444 4 data: 66 frags: 256 1192 1448 1280 168 1448 1444 4 From anton@ozlabs.org Thu May 5 22:48:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 22:48:59 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j465mtOv009353 for ; Thu, 5 May 2005 22:48:56 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id A74FC67A70; Fri, 6 May 2005 15:48:38 +1000 (EST) Date: Fri, 6 May 2005 15:45:16 +1000 From: Anton Blanchard To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-ID: <20050506054516.GE8255@krispykreme> References: <20050504230731.12be1bc3.davem@davemloft.net> <20050506043653.GD8255@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050506043653.GD8255@krispykreme> User-Agent: Mutt/1.5.9i X-archive-position: 838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 958 Lines: 25 Hi, With a 9000 byte MTU I see page sized frags as expected. There are still some pages broken in two which is interesting. Anton data: 66 frags: 3584 4096 1268 2816 4096 2032 4 data: 66 frags: 2048 4096 2804 1280 4096 3568 4 data: 66 frags: 512 4096 4096 244 3840 4096 1008 4 data: 66 frags: 3072 4096 1780 2304 4096 2544 4 data: 66 frags: 1536 4096 3316 768 4096 4080 4 data: 66 frags: 4096 4096 756 3328 4096 1520 4 data: 66 frags: 2560 4096 2292 1792 4096 3056 4 data: 66 frags: 1024 4096 3828 256 4096 4096 496 4 data: 66 frags: 3584 4096 1268 2816 4096 2032 4 data: 66 frags: 2048 4096 2804 1280 4096 3568 4 data: 66 frags: 512 4096 4096 244 3840 4096 1008 4 data: 66 frags: 3072 4096 1780 2304 4096 2544 4 data: 66 frags: 1536 4096 3316 768 4096 4080 4 data: 66 frags: 4096 4096 756 3328 4096 1520 4 data: 66 frags: 2560 4096 2292 1792 4096 3056 4 data: 66 frags: 1024 4096 3828 256 4096 4096 496 4 data: 66 frags: 3584 4096 1268 2816 4096 2032 4 From davem@davemloft.net Thu May 5 23:26:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 23:26:08 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j466Q4Ov011104 for ; Thu, 5 May 2005 23:26:04 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTw5p-0002V5-00; Thu, 05 May 2005 23:13:45 -0700 Date: Thu, 5 May 2005 23:13:45 -0700 From: "David S. Miller" To: Anton Blanchard Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-Id: <20050505231345.4296d9b5.davem@davemloft.net> In-Reply-To: <20050506054516.GE8255@krispykreme> References: <20050504230731.12be1bc3.davem@davemloft.net> <20050506043653.GD8255@krispykreme> <20050506054516.GE8255@krispykreme> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 648 Lines: 21 On Fri, 6 May 2005 15:45:16 +1000 Anton Blanchard wrote: > With a 9000 byte MTU I see page sized frags as expected. There are still > some pages broken in two which is interesting. I know what is causing the breaks, it's the "cache line align" crap in tcp_sendmsg(). Comment out this alignment code in net/ipv4/tcp.c and see how it goes: /* If page is cached, align * offset to L1 cache boundary */ off = (off + L1_CACHE_BYTES - 1) & ~(L1_CACHE_BYTES - 1); This alignment causes TSO coalescing to fail at these spots. You should not see this effect when sendfile() is used for the transfer. From m.iatrou@freemail.gr Thu May 5 23:56:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 May 2005 23:56:29 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j466uOOv012458 for ; Thu, 5 May 2005 23:56:25 -0700 Received: (qmail 505 invoked by uid 111); 5 May 2005 21:56:06 -0000 Received: from 150.140.129.29 by nic.upatras.gr (envelope-from , uid 103) with qmail-scanner-1.25 (clamdscan: 0.83/706. Clear:RC:1(150.140.129.29):. Processed in 0.083211 secs); 05 May 2005 21:56:06 -0000 Received: from patreas.upatras.gr (150.140.129.29) by nic.upatras.gr with SMTP; 5 May 2005 21:56:06 -0000 Received: (qmail 8435 invoked from network); 5 May 2005 21:56:05 -0000 Received: from upnet-dialinpool-89.upnet.gr ([150.140.128.165]) (envelope-sender ) by patreas.upatras.gr (qmail-ldap-1.03) with SMTP for ; 5 May 2005 21:56:05 -0000 From: Michael Iatrou To: Rick Jones Subject: Re: e1000 (?) jumbo frames performance issue Date: Fri, 6 May 2005 00:55:55 +0300 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <200505051928.32496.m.iatrou@freemail.gr> <427A7F5B.8050704@hp.com> In-Reply-To: <427A7F5B.8050704@hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505060055.55778.m.iatrou@freemail.gr> X-archive-position: 840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: m.iatrou@freemail.gr Precedence: bulk X-list: netdev Content-Length: 1595 Lines: 46 When the date was Thursday 05 May 2005 23:17, Rick Jones wrote: > What settings, if any, did you use for -s, -S and in particular -m in > netperf? -s 0 -S 0 -m 16384 For both ends: /proc/sys/net/core/wmem_max: 16777216 /proc/sys/net/core/rmem_max: 16777216 /proc/sys/net/ipv4/tcp_rmem: 16384 349520 16777216 /proc/sys/net/ipv4/tcp_wmem: 16384 262144 16777216 > I seem to recall that some of the stack defaults for SO_SNDBUF (IIRC) would > result in netperf sending 16KB at a time into the connection - once you > sent the MTU above 16K you may have started running into issues with Nagle > and delayed ACK? The problem firstly appears at 12KB... > You could try some tests adding a test-specific -D to > disable Nagle, or -C to set TCP_CORK, or use -m to set the send size to > say, 32KB. I 've already tested -m 32KB and its the same as 16KB. I will try -D and -C too. > It might be good to add CPU utilization figures - for 2.3pl1 that means > editing the makefile to add a -DUSE_PROC_STAT and recompiling. Or you can > grab netperf 2.4.0-rc3 from: > > ftp://ftp.cup.hp.com/dist/networking/benchmarks/netperf/experimental/ > > if you cannot find it elsewhere, and that will (try to) compile-in the > right CPU utilization mechanism automagically. I already did a custom CPU usage instrumentation (based on infos from /proc/stat -- the latest netperf does the same thing, doesn't it?) and it seems that system has plenty of idle time (up to 50% if I recall correct) -- Michael Iatrou Electrical and Computer Engineering Dept. University of Patras, Greece From anton@ozlabs.org Fri May 6 00:14:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 00:14:28 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j467EPOv015012 for ; Fri, 6 May 2005 00:14:25 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 90AE867B31; Fri, 6 May 2005 17:14:06 +1000 (EST) Date: Fri, 6 May 2005 17:10:05 +1000 From: Anton Blanchard To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-ID: <20050506071005.GG8255@krispykreme> References: <20050504230731.12be1bc3.davem@davemloft.net> <20050506043653.GD8255@krispykreme> <20050506054516.GE8255@krispykreme> <20050505231345.4296d9b5.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505231345.4296d9b5.davem@davemloft.net> User-Agent: Mutt/1.5.9i X-archive-position: 841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 1736 Lines: 60 > I know what is causing the breaks, it's the "cache line align" crap > in tcp_sendmsg(). > > Comment out this alignment code in net/ipv4/tcp.c and see how it goes: > > /* If page is cached, align > * offset to L1 cache boundary > */ > off = (off + L1_CACHE_BYTES - 1) & > ~(L1_CACHE_BYTES - 1); > > This alignment causes TSO coalescing to fail at these spots. > > You should not see this effect when sendfile() is used for > the transfer. Nice work! Its looking much better now. Anton 1500 MTU: eth0 data: 74 frags: eth0 data: 66 frags: 2892 4 eth0 data: 66 frags: 1200 1692 4 eth0 data: 66 frags: 2400 492 4 eth0 data: 66 frags: 2892 4 eth0 data: 66 frags: 704 744 eth0 data: 66 frags: 3352 4096 1236 4 eth0 data: 66 frags: 2856 36 4 1500 MTU+sendfile: eth0 data: 74 frags: eth0 data: 66 frags: 2892 4 eth0 data: 66 frags: 1200 1692 4 eth0 data: 66 frags: 2400 492 4 eth0 data: 66 frags: 2892 4 eth0 data: 66 frags: 704 744 eth0 data: 66 frags: 3348 4 eth0 data: 66 frags: 4092 4 9000 MTU: eth0 data: 74 frags: eth0 data: 66 frags: 4096 4096 4096 4096 1508 4 eth0 data: 66 frags: 2584 4096 2268 eth0 data: 66 frags: 1828 4096 3024 eth0 data: 66 frags: 1072 4096 4096 4096 4096 4096 4096 1192 4 eth0 data: 66 frags: 2900 4096 4096 4096 2704 4 eth0 data: 66 frags: 1388 4096 3464 eth0 data: 66 frags: 632 4096 4096 4096 4096 876 4 9000 MTU+sendfile: eth0 data: 74 frags: eth0 data: 66 frags: 4096 4096 4092 4 eth0 data: 66 frags: 4096 4096 4096 4096 1508 4 eth0 data: 66 frags: 2584 4096 4092 4 eth0 data: 66 frags: 4096 4096 4096 4096 1508 4 eth0 data: 66 frags: 2584 4096 4096 4096 3020 4 eth0 data: 66 frags: 1072 4096 4096 4096 4096 436 4 eth0 data: 66 frags: 3656 4096 4096 4096 1948 4 From domen@coderock.org Fri May 6 01:04:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 01:04:47 -0700 (PDT) Received: from trashy.coderock.org (coderock.org [193.77.147.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4684gOv020340 for ; Fri, 6 May 2005 01:04:43 -0700 Received: by trashy.coderock.org (Postfix, from userid 780) id 7D97C1F386; Fri, 6 May 2005 10:04:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 8EB701F380; Fri, 6 May 2005 10:04:19 +0200 (CEST) Received: from localhost (coderock.org [193.77.147.115]) by trashy.coderock.org (Postfix) with ESMTP id C6CF41F245; Fri, 6 May 2005 10:04:16 +0200 (CEST) Date: Fri, 6 May 2005 10:04:15 +0200 From: Domen Puncer To: Benjamin Reed Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] dynamic wep keys for airo.c Message-ID: <20050506080415.GD3917@nd47.coderock.org> References: <200505030826.42564.breed@zuzulu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505030826.42564.breed@zuzulu.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 492 Lines: 17 On 03/05/05 08:26 -0700, Benjamin Reed wrote: > module_param_array(ssids, charp, NULL, 0); > module_param(auto_wep, int, 0); > +module_param(perm_key_support, int, 1); ^ permissions in sysfs > if (rc!=SUCCESS) printk(KERN_ERR "airo: WEP_TEMP set %x\n", rc); > if (perm) { > + // We make these messages debug. They really should be error, > + // but no one seems to use the TEMP flag and writing a PERM key > + // with the MAC disable throws this error /* */? Domen From davem@davemloft.net Fri May 6 01:32:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 01:32:23 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j468WHOv021632 for ; Fri, 6 May 2005 01:32:18 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTy3w-0003JU-00; Fri, 06 May 2005 01:19:56 -0700 Date: Fri, 6 May 2005 01:19:54 -0700 From: "David S. Miller" To: Anton Blanchard Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-Id: <20050506011954.18176751.davem@davemloft.net> In-Reply-To: <20050506071005.GG8255@krispykreme> References: <20050504230731.12be1bc3.davem@davemloft.net> <20050506043653.GD8255@krispykreme> <20050506054516.GE8255@krispykreme> <20050505231345.4296d9b5.davem@davemloft.net> <20050506071005.GG8255@krispykreme> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 362 Lines: 16 On Fri, 6 May 2005 17:10:05 +1000 Anton Blanchard wrote: > Nice work! Its looking much better now. Great, thanks for testing. BTW: > eth0 data: 66 frags: 2892 4 What does this "66 frags" mean? Is it "tso_segs" from the SKB? skb_shinfo(skb)->nr_frags can never be that large (MAX_SKB_FRAGS is (65536/PAGE_SIZE + 2)) so it can't be that. From anton@ozlabs.org Fri May 6 01:39:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 01:40:00 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j468dvOv022409 for ; Fri, 6 May 2005 01:39:58 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id B43EB67B3D; Fri, 6 May 2005 18:39:40 +1000 (EST) Date: Fri, 6 May 2005 18:36:59 +1000 From: Anton Blanchard To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded Message-ID: <20050506083659.GH8255@krispykreme> References: <20050504230731.12be1bc3.davem@davemloft.net> <20050506043653.GD8255@krispykreme> <20050506054516.GE8255@krispykreme> <20050505231345.4296d9b5.davem@davemloft.net> <20050506071005.GG8255@krispykreme> <20050506011954.18176751.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050506011954.18176751.davem@davemloft.net> User-Agent: Mutt/1.5.9i X-archive-position: 844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 358 Lines: 12 > > eth0 data: 66 frags: 2892 4 > > What does this "66 frags" mean? Is it "tso_segs" from > the SKB? skb_shinfo(skb)->nr_frags can never be that > large (MAX_SKB_FRAGS is (65536/PAGE_SIZE + 2)) so it > can't be that. Nah I just dump the skb mapping then the subsequent frags. So 66 is the size of the header. In this case there is only 2 frags. Anton From herbert@gondor.apana.org.au Fri May 6 01:54:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 01:54:46 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j468seOv023259 for ; Fri, 6 May 2005 01:54:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DTyb3-0001Yo-00; Fri, 06 May 2005 18:54:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DTyaz-0006yo-00; Fri, 06 May 2005 18:54:05 +1000 Date: Fri, 6 May 2005 18:54:05 +1000 To: jamal Cc: "David S. Miller" , netdev Subject: Re: resend patch: xfrm policybyid Message-ID: <20050506085404.GA26719@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115345403.7660.49.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1820 Lines: 41 On Thu, May 05, 2005 at 10:10:03PM -0400, jamal wrote: > > > The way I'm seeing it is that the index is simply a read-only value > > that's only provided by the kernel to the user as an aid in locating > > policies. > > IOW, they are search keys. I'm afraid I still disagree. There should only be one key that the user gets to set when adding policies that is guaranteed to be unique. As it is it's the selector. Letting the user specify two independent keys which need to be unique is what is making your patch ugly and what IMHO will make the code unmaintainable. Here is an analogy. Think of the policies as files and the indicies as file descriptors. The index is only valid while the policy is in the policy list (the file descriptor is only valid while the file is open). When you add the policy, you don't get to specify what the index is (when you open a file, you don't get to specify what the file descriptor is). Once the policy has been added, you will be given an index that you can use to read/delete the policy (once the file has been opened, you will be given a file descriptor that you can use to access/close the file). Now you may argue that file descriptors can be set to whatever value you want using dup. However, the difference here is that you can only do this on an open file. Similarly, changing the index of a policy that's already in the list can be done cleanly since we already have verified that its primary key (the selector) is unique. However, I must say that I still have absolutely no idea why anyone would need to set the index to arbitrary values. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From m.iatrou@freemail.gr Fri May 6 02:25:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 02:25:18 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j469PDOv024793 for ; Fri, 6 May 2005 02:25:14 -0700 Received: (qmail 13276 invoked by uid 111); 6 May 2005 09:24:48 -0000 Received: from 150.140.129.29 by nic.upatras.gr (envelope-from , uid 103) with qmail-scanner-1.25 (clamdscan: 0.83/706. Clear:RC:1(150.140.129.29):. Processed in 0.174069 secs); 06 May 2005 09:24:48 -0000 Received: from patreas.upatras.gr (150.140.129.29) by nic.upatras.gr with SMTP; 6 May 2005 09:24:47 -0000 Received: (qmail 4973 invoked from network); 6 May 2005 09:24:47 -0000 Received: from upnet-dialupb-92.upnet.gr (HELO [150.140.131.92]) ([150.140.131.92]) (envelope-sender ) by patreas.upatras.gr (qmail-ldap-1.03) with SMTP for ; 6 May 2005 09:24:47 -0000 From: Michael Iatrou To: Rick Jones Subject: Re: e1000 (?) jumbo frames performance issue Date: Fri, 6 May 2005 01:26:09 +0300 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <200505051928.32496.m.iatrou@freemail.gr> <427A7F5B.8050704@hp.com> <200505060055.55778.m.iatrou@freemail.gr> In-Reply-To: <200505060055.55778.m.iatrou@freemail.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505060126.09062.m.iatrou@freemail.gr> X-archive-position: 846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: m.iatrou@freemail.gr Precedence: bulk X-list: netdev Content-Length: 430 Lines: 15 When the date was Friday 06 May 2005 00:55, Michael Iatrou wrote: > > You could try some tests adding a test-specific -D to > > disable Nagle, or -C to set TCP_CORK, or use -m to set the send size to > > say, 32KB. > > I 've already tested -m 32KB and its the same as 16KB. > I will try -D and -C too. Done, (almost) nothing changed. -- Michael Iatrou Electrical and Computer Engineering Dept. University of Patras, Greece From herbert@gondor.apana.org.au Fri May 6 03:58:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 03:59:01 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46AwsOv028202 for ; Fri, 6 May 2005 03:58:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DU0XQ-0002IM-00; Fri, 06 May 2005 20:58:32 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DU0XM-0001wJ-00; Fri, 06 May 2005 20:58:28 +1000 From: Herbert Xu To: webmaster@rapidforum.com (Christian Schmid) Subject: Re: MultiPath Routing Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Organization: Core In-Reply-To: <427A70ED.3010305@rapidforum.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 06 May 2005 20:58:28 +1000 X-archive-position: 847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 704 Lines: 18 Christian Schmid wrote: > > Yes I enabled it. But it shouldnt do anything because its no forwarded traffic here. I just used > example-IPs. Or does the bug also break non-forwarded traffic? Did you select one of the multipath algorithm options? If you selected them as modules did you load them? If no algorithms are available it will degenerate into deterministic routing. It will also work properly if you disable IP_ROUTE_MULTIPATH_CACHED completely. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri May 6 04:05:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 04:05:23 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46B5GOv028921 for ; Fri, 6 May 2005 04:05:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DU0dV-0002JU-00; Fri, 06 May 2005 21:04:49 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DU0dR-0001xK-00; Fri, 06 May 2005 21:04:45 +1000 Date: Fri, 6 May 2005 21:04:45 +1000 To: jamal Cc: "David S. Miller" , netdev Subject: Re: resend patch: xfrm policybyid Message-ID: <20050506110445.GA7507@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115331436.8006.112.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 469 Lines: 14 On Thu, May 05, 2005 at 06:17:15PM -0400, jamal wrote: > > BTW, are the event patches in Davems queue somewhere? > I have a few ipsec ones (cosmetic) that i will send later. I can queue them up for you and bounce them to Dave once 2.6.13 opens up. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From webmaster@rapidforum.com Fri May 6 04:17:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 04:17:34 -0700 (PDT) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46BHROv030262 for ; Fri, 6 May 2005 04:17:28 -0700 Received: (qmail 18266 invoked by uid 1004); 6 May 2005 11:17:10 -0000 Received: from p549f29e1.dip0.t-ipconnect.de (HELO ?84.159.41.225?) (dragony@84.159.41.225) by www.rapidforum.com with SMTP; 6 May 2005 11:17:10 -0000 Message-ID: <427B521E.2040302@rapidforum.com> Date: Fri, 06 May 2005 13:16:46 +0200 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: de, en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: MultiPath Routing References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 708 Lines: 18 I tried disabling MULTIPATH_CACHED and now it completely works :) Thank you for your help. I thought your hint only is for NATed traffic but it seems its for all traffic. Herbert Xu wrote: > Christian Schmid wrote: > >>Yes I enabled it. But it shouldnt do anything because its no forwarded traffic here. I just used >>example-IPs. Or does the bug also break non-forwarded traffic? > > > Did you select one of the multipath algorithm options? If you selected > them as modules did you load them? If no algorithms are available it > will degenerate into deterministic routing. > > It will also work properly if you disable IP_ROUTE_MULTIPATH_CACHED > completely. > > Cheers, From Robert.Olsson@data.slu.se Fri May 6 04:31:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 04:31:39 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46BVaOv002693 for ; Fri, 6 May 2005 04:31:36 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j46BVEj3021033; Fri, 6 May 2005 13:31:14 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 648C1EE1E9; Fri, 6 May 2005 13:31:14 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17019.21890.234387.549229@robur.slu.se> Date: Fri, 6 May 2005 13:31:14 +0200 To: Andre Tomt Cc: Robert Olsson , netdev@oss.sgi.com, Jens.Laas@data.slu.se Subject: Re: (diet-)FIB alternative fib_hlist.c In-Reply-To: <427A7A09.4060900@tomt.net> References: <17016.62444.34282.625407@robur.slu.se> <427A7A09.4060900@tomt.net> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-archive-position: 850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1135 Lines: 29 Andre Tomt writes: > > Probably we soon want to specify differnt lookup schemes for different > > tables say for local table fib_hash or fib_hlist. While for large main table > > fib_hash2/fib_trie would be better option. > > From a distribution[1] point of view, a boot time option would be much > better than choosing at compile time. Boot time plus a kconfig multiple > selection list would be even better. Another perhaps even more user > friendly option would be setting it runtime using f.ex. iproute, but I > guess that could end up messy.. Yes I'll guess kernel config would be the first step. Also we need to find out if there are any useful options to current FIB. Which is very general purpose. Anyway we have a cleaner interface to FIB also we have some new FIB options. Which should be a step forward and an advantage for linux and will hopefully lead to more development and understanding and so that Linux will used for development in this area. We will also lead to better understand the dst hash and FIB trade off. Experiences from tests or use are very welcome. Cheers. --ro From hadi@cyberus.ca Fri May 6 04:53:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 04:53:27 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46BrNOv004028 for ; Fri, 6 May 2005 04:53:24 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DU1OD-00029N-Rv for netdev@oss.sgi.com; Fri, 06 May 2005 07:53:05 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DU1OB-0001Uv-IH; Fri, 06 May 2005 07:53:03 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev In-Reply-To: <20050506085404.GA26719@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> <20050506085404.GA26719@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Fri, 06 May 2005 07:53:00 -0400 Message-Id: <1115380381.7660.123.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3621 Lines: 92 On Fri, 2005-06-05 at 18:54 +1000, Herbert Xu wrote: > On Thu, May 05, 2005 at 10:10:03PM -0400, jamal wrote: > > > > > The way I'm seeing it is that the index is simply a read-only value > > > that's only provided by the kernel to the user as an aid in locating > > > policies. > > > > IOW, they are search keys. > > I'm afraid I still disagree. You are a reasonable man, so i am hoping you will end agreeing or agreeing to disagree;-> > There should only be one key that the > user gets to set when adding policies that is guaranteed to be unique. > As it is it's the selector. > Note: The index was already guaranteed to be unique even without my patch. Just to make sure we are not speaking past each other: A key is a column in a table that can be uniquely used to identify said row. A table can have more than one key (a lot of relational databases do), although it adds a lot of gunk in the kernel. In this case actually the justification exists: The selector is needed for data/packet path lookup key. The index for manager side manageability. > Letting the user specify two independent keys which need to be unique > is what is making your patch ugly and what IMHO will make the code > unmaintainable. > I did not add the code for index, Herbert ;-> whoever did missed some basic details - I am rectifying that. It will be much easir to get rid of the index as a key - at which point it has no real value or fix it. You cant have it both ways. In my opinion the only key that should be used by the manager is the index. User space should be able to map the selector to an index - same with the SAD. Its a lot more manageable that way. But again thats a separate discussion (amongst a few other issues i have distate for in the SPD/SAD). This actually is the simple one ;-> > Here is an analogy. Think of the policies as files and the indicies > as file descriptors. The index is only valid while the policy is in > the policy list (the file descriptor is only valid while the file is > open). When you add the policy, you don't get to specify what the > index is (when you open a file, you don't get to specify what the > file descriptor is). Of course you can specify the index at creation time! it does make sense to. It's user space that manages these tables - much easier to specify an index that makes sense to the manager so it can manage its side of things easier. Otherwise all the MIBS and PIBS and policy management code that exists and uses the concept of row indices in the world is wrong. > Once the policy has been added, you will be > given an index that you can use to read/delete the policy (once the > file has been opened, you will be given a file descriptor that you > can use to access/close the file). > Good example that serves to make my point actually. Indeed you can look at the fd as a key that the kernel uses. The manager of the table is the kernel. The kernel dictates what the fd could be (with some exceptions) because it is easier that way to manage the addition, lookup and removal of these files. The SPD, OTOH, is a table of policies managed by some entity in user space like a KM (and not in the kernel). Standard approaches have long ago (probably before you and i were born) to use indices to manage tables. Look at SNMP, COPS, etc. There are some exceptions to this, but this is in cases where they cant be avoided. > However, I must say that I still have absolutely no idea why anyone > would need to set the index to arbitrary values. > But you do know why someone would want to search or delete by it, right?;-> cheers, jamal From hadi@cyberus.ca Fri May 6 04:56:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 04:56:42 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46BubOv004749 for ; Fri, 6 May 2005 04:56:39 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DU1RL-0002vM-5Y for netdev@oss.sgi.com; Fri, 06 May 2005 05:56:19 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DU1RN-00028z-1O; Fri, 06 May 2005 07:56:21 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev In-Reply-To: <20050506110445.GA7507@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050506110445.GA7507@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Fri, 06 May 2005 07:56:18 -0400 Message-Id: <1115380578.7660.126.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 247 Lines: 11 On Fri, 2005-06-05 at 21:04 +1000, Herbert Xu wrote: > I can queue them up for you and bounce them to Dave once 2.6.13 > opens up. I would appreciate that - i am famous for losing patches. Now queue that policybyid patch too ;-> cheers, jamal From tgraf@suug.ch Fri May 6 05:36:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 05:36:45 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46CacOv006716 for ; Fri, 6 May 2005 05:36:38 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 613101C0EB; Fri, 6 May 2005 14:36:39 +0200 (CEST) Date: Fri, 6 May 2005 14:36:39 +0200 From: Thomas Graf To: Pablo Neira Cc: netdev@oss.sgi.com, jamal Subject: Re: [RFC] textsearch infrastructure + skb_find_text() Message-ID: <20050506123639.GE28419@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> <427A51A2.8090600@eurodev.net> <20050505174224.GB25977@postel.suug.ch> <427AC96E.2020208@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427AC96E.2020208@eurodev.net> X-archive-position: 853 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 5036 Lines: 107 * Pablo Neira <427AC96E.2020208@eurodev.net> 2005-05-06 03:33 > >This is implemented in skb_find_text(), I just looked through rusty's > >code and it's very simliar so we could make the args in ts_state a > >union of long args[6] and char cb[XXX] so we can store skb_iter > >in there. > > Yes, we could just use one of those args in ts_state to store if we > found a partial match or not. This is not required, I will elaborate the core logic to clarify this. I guess you still think of the logic as: function find-text(pattern) foreach text-segment do call search-bm(text-segment, pattern); done end This is what most people naturally think of when dealing with this problem and it might be sufficient for many situations, however it requires the searching algorithm to store its state in some persistent memory which can be troublesome depending on the volume of these variables. My approach is to save the state of the text fetching progress and have the algorithm handle the fetching of new data (if needed), i.e: function serch-bm(pattern, get-text-callback) while get-text-callback() returns more data do do the matching here... done end function find-text(pattern) call search-bm(pattern, get-text-callback); end This allows the searching algorithm to see the text as a continuous byte stream. The get_text() callback is like a char device, altough it returns data in variable sized blocks, there is no random access. Why? Because it dramatically simplifies the searching algorithms since they can decide when to fetch the next block which is absolutely essential for cases like regular expression where the state machine gets quite complex and a single entry point (i.e. leaving the function and enter it again with new data) would make things much more complex. Minor advantages are a) the get_text() implementation is usually quite small and will hopefully not mess up the cacheline optimizations of the actual searching loop and b) it allows the searching algorithm to do prefetching. << coffee break >> Now on to the subject of matching over multiple skbs, in a perfect world we can try to do async searching by storing the partial match state in the conntrack entry but then again what do we do when we find a partial match in a skb? Drop it? We can't access the next skb or fragment just now to see if the full pattern is present. So what this would lead to is that we let the handshake and some payload pass until we find the skb that successfully ends a partial match. This is basically what IOS and JunOS do (correct me if I'm wrong). A common use case for this is to filter out malicious HTTP requests and other easy to identify data that might harm a service that is vulnerable but has no fix available just yet. In order to avoid DoS certain limits must be established such as maximum number of skbs or maximum payload scanned before aborting but most of these limits can be worked around for example by pretending huge HTTP headers in front of the malicious header line and it will be very hard to find a breakeven to actually be able to filter out some of it while not allowing a DoS due to massive filtering. Can we avoid letting through the initial handshake? Yes but it's probably not worth the effort. Will we be able to ultimatively solve the filtering facitily vs DoS vulnerability issue? No. Can we avoid letting through previous skbs which could do harm as well but only a partial match has been found? Not at this level or without nasty hacks such as acking the data but not passing it up. Worth it? Probably not. To my understanding it is not worth to try too hard and be perfect, I see the textsearch filtering as nice to have for filtering on the first few dozen bytes of the initial payload skb typically carrying enough headers to classify on layer7 basis. If someone thinks the small probability of having a match just between 2 fragments is important then please go ahead and put the matching state into ts_state as well. > Sure, your approach is definitely more generic because I just thought > about using such string matching framework for net apps, it's different > from that point of view, but I still see things that reminds me to my > proposed framework, say that ts_state thing ;). Note that your state variable stores the matching state and ts_state stores the state of the get_text() progress. > No problem mate. Just curious about something, since this stuff will > live under lib, what kind of applications in kernel space could use this > string matching framework ? I bet that non-net kernel guys will surely > ask about it ;-> It definitely belongs into lib/ to my understanding, nobody gets hurt by adding it there and the chances that someone other subsystem having need for it are not that low. One example (silly one though) that I did out of curiosity is a sys_findtext taking an inode returning the first match. It simply iterates over all blocks belonging to the file making use of the buffer cache if possible. It's really fast. ;-> From hadi@cyberus.ca Fri May 6 06:04:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 06:04:36 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46D4UOv008372 for ; Fri, 6 May 2005 06:04:33 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DU2V2-0003hG-Ba for netdev@oss.sgi.com; Fri, 06 May 2005 07:04:12 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DU2V1-0006nE-Pm; Fri, 06 May 2005 09:04:12 -0400 Subject: Re: [RFC] textsearch infrastructure + skb_find_text() From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Pablo Neira , netdev@oss.sgi.com In-Reply-To: <20050506123639.GE28419@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> <427A51A2.8090600@eurodev.net> <20050505174224.GB25977@postel.suug.ch> <427AC96E.2020208@eurodev.net> <20050506123639.GE28419@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 06 May 2005 09:04:08 -0400 Message-Id: <1115384649.7660.140.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1764 Lines: 55 On Fri, 2005-06-05 at 14:36 +0200, Thomas Graf wrote: [..] > function find-text(pattern) > foreach text-segment do > call search-bm(text-segment, pattern); > done > end > > This is what most people naturally think of when dealing with this > problem and it might be sufficient for many situations, however it > requires the searching algorithm to store its state in some persistent > memory which can be troublesome depending on the volume of these > variables. > [..] I dont see any difference between the two in terms of state storage. Can you really avoid storing state? Can you give an example? > Why? Because it dramatically simplifies the searching algorithms > since they can decide when to fetch the next block which is > absolutely essential for cases like regular expression where the > state machine gets quite complex and a single entry point The other scheme is to have the callback return a code which says "get me more text" or " enough/done" in which case the state machine for the search alg is no different in both cases. > (i.e. > leaving the function and enter it again with new data) would make > things much more complex. Minor advantages are a) the get_text() > implementation is usually quite small and will hopefully not mess > up the cacheline optimizations of the actual searching loop It depends on the search algorithm - if it is small, you benefit from either scheme. If it is large, you loose in both. > and > b) it allows the searching algorithm to do prefetching. > I am trying to sink this in; prefetching would be valuable for regexp, but why would the other scheme not be able to do it? > << coffee break >> > I have to run to work while you get coffee ;-> I will read the rest later. cheers, jamal From herbert@gondor.apana.org.au Fri May 6 06:24:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 06:24:25 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46DOEOv010194 for ; Fri, 6 May 2005 06:24:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DU2nJ-0003Hp-00; Fri, 06 May 2005 23:23:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DU2mw-0000UK-00; Fri, 06 May 2005 23:22:42 +1000 From: Herbert Xu To: kaber@trash.net (Patrick McHardy) Subject: Re: netfilter6: ICMPv6 type 143 doesn't match Cc: davem@davemloft.net, dlstevens@us.ibm.com, laforge@gnumonks.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, pb@bieringer.de, usagi-users@linux-ipv6.org, yasuyuki.kozakai@toshiba.co.jp, yoshfuji@linux-ipv6.org Organization: Core In-Reply-To: <427AA319.1040906@trash.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 06 May 2005 23:22:42 +1000 X-archive-position: 855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 824 Lines: 24 Patrick McHardy wrote: > > +static inline int mld_dev_queue_xmit2(struct sk_buff *skb) > +{ > + struct net_device *dev = skb->dev; > + > + if (dev->hard_header) { > + unsigned char ha[MAX_ADDR_LEN]; > + int err; > + > + ndisc_mc_map(&skb->nh.ipv6h->daddr, ha, dev, 1); > + err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); > + if (err < 0) { > + IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); You're now incrementing this twice since the callers will also increment this. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri May 6 06:29:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 06:29:04 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46DSxOv010794 for ; Fri, 6 May 2005 06:29:00 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DU2sa-0003KR-00; Fri, 06 May 2005 23:28:32 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DU2sX-0000Va-00; Fri, 06 May 2005 23:28:29 +1000 Date: Fri, 6 May 2005 23:28:29 +1000 To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: resend patch: xfrm policybyid Message-ID: <20050506132829.GA1943@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505151820.672b89fa.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505151820.672b89fa.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 856 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 648 Lines: 19 On Thu, May 05, 2005 at 03:18:20PM -0700, David S. Miller wrote: > On Thu, 05 May 2005 18:17:15 -0400 > jamal wrote: > > > BTW, are the event patches in Davems queue somewhere? > > I have a few ipsec ones (cosmetic) that i will send later. > > I'm not queueing 2.6.13 material yet. > 2.6.12 bug fixes are a full time job yet :-) Dave, would you mind if I pushed these event patches into mm for some testing? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From leonid.grossman@neterion.com Fri May 6 07:10:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 07:10:24 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46EAAOv012490 for ; Fri, 6 May 2005 07:10:11 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j46E9KOC014726; Fri, 6 May 2005 10:09:20 -0400 (EDT) Received: from lgt40 ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j46E9HVG020066; Fri, 6 May 2005 10:09:18 -0400 (EDT) Message-Id: <200505061409.j46E9HVG020066@guinness.s2io.com> From: "Leonid Grossman" To: "'David S. Miller'" Cc: Subject: RE: [PATCH] TSO Reloaded Date: Fri, 6 May 2005 07:09:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050505203052.059125eb.davem@davemloft.net> Thread-Index: AcVR7aeMSRKrKKnoRTK9r+AOSdgNSAAU87Fg X-Scanned-By: MIMEDefang 2.34 X-archive-position: 857 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1979 Lines: 55 > -----Original Message----- > From: David S. Miller [mailto:davem@davemloft.net] > Sent: Thursday, May 05, 2005 8:31 PM > To: Leonid Grossman > Cc: netdev@oss.sgi.com > Subject: Re: [PATCH] TSO Reloaded > > On Thu, 5 May 2005 20:20:56 -0700 > "Leonid Grossman" wrote: > > > We will be testing on 10GbE NICs in the next couple weeks; will let you > > know. > > BTW - any plans for IPv6 support? > > What exactly does your NIC expect? Do you use the > NETIF_F_HW_CSUM flag to indicate generic checksumming support? > Otherwise, there is no other way to support ipv6 checksum offload > at the moment, and that is a requirement for ipv6 TSO. > > For TSO, the ipv6 header handling seems very non-trivial. > What is supposed to happen in cases where certain optional > extension headers should be present in some of the frames > but not the others? Our ASIC supports ipv6 CSUM and TSO (and header splitting) even if extension headers are present, but I suspect the majority ipv6-capable NICs will not implement this; the stack needs to query NIC header-processing capabilities (for both CSUM and TSO) and act accordingly. > > A specification of how your NIC support ipv6 TSO is necessary > in order for support to be written, see? We are planning to release the ASIC programming manual to the community fairly soon, this will provide a better view on IPv6 LSO and some other features. >Seems like you are > the most qualified person to write the support, therefore :-) > Really, it isn't that hard and you have something on which > to test whatever you write, whereas I don't. We will probably get to it sometime down the road; at the moment support for UDP LSO and receive side offloads are much higher on our list. Getting a vanilla (no support for extension headers) implementation from someone who knows the stack better than we do would be a good thing :-), I suspect this should be useful for more than one NIC vendor. Leonid From ja@ssi.bg Fri May 6 07:15:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 07:15:45 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46EFNOv013376 for ; Fri, 6 May 2005 07:15:36 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id j46ELMWW015834; Fri, 6 May 2005 17:21:23 +0300 Date: Fri, 6 May 2005 17:21:22 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: netdev@oss.sgi.com cc: Andrew Morton , Wensong Zhang , "David S. Miller" Subject: [PATCH] ipvs: add and reorder bh locks after moving to keventd Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607745702-2026925329-1115389282=:1504" X-archive-position: 858 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 3650 Lines: 74 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1607745702-2026925329-1115389282=:1504 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I hope this is correct addition to the last ipvs changes that move update_defense_level/si_meminfo to keventd: - ip_vs_random_dropentry now runs in process context and should use _bh locks to protect from softirqs - update_defense_level still needs _bh locks after si_meminfo is called, for the same purpose Dave, please apply on ack, the attached patch is against 2.6.12-rc3 Signed-off-by: Julian Anastasov --1607745702-2026925329-1115389282=:1504 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="use_bh.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Use _bh locks in keventd context Content-Disposition: attachment; filename="use_bh.diff" ZGlmZiAtdXIgdjIuNi4xMi1yYzMvbGludXgvbmV0L2lwdjQvaXB2cy9pcF92 c19jb25uLmMgbGludXgvbmV0L2lwdjQvaXB2cy9pcF92c19jb25uLmMNCi0t LSB2Mi42LjEyLXJjMy9saW51eC9uZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4u YwkyMDA1LTAzLTAzIDEwOjE3OjIzLjAwMDAwMDAwMCArMDIwMA0KKysrIGxp bnV4L25ldC9pcHY0L2lwdnMvaXBfdnNfY29ubi5jCTIwMDUtMDUtMDYgMTQ6 Mjk6MjguNDc4MzUwMDcyICswMzAwDQpAQCAtNzU5LDcgKzc1OSw3IEBADQog CXJldHVybiAxOw0KIH0NCiANCi0NCisvKiBDYWxsZWQgZnJvbSBrZXZlbnRk IGFuZCBtdXN0IHByb3RlY3QgaXRzZWxmIGZyb20gc29mdGlycXMgKi8NCiB2 b2lkIGlwX3ZzX3JhbmRvbV9kcm9wZW50cnkodm9pZCkNCiB7DQogCWludCBp ZHg7DQpAQCAtNzc1LDcgKzc3NSw3IEBADQogCQkvKg0KIAkJICogIExvY2sg aXMgYWN0dWFsbHkgbmVlZGVkIGluIHRoaXMgbG9vcC4NCiAJCSAqLw0KLQkJ Y3Rfd3JpdGVfbG9jayhoYXNoKTsNCisJCWN0X3dyaXRlX2xvY2tfYmgoaGFz aCk7DQogDQogCQlsaXN0X2Zvcl9lYWNoX2VudHJ5KGNwLCAmaXBfdnNfY29u bl90YWJbaGFzaF0sIGNfbGlzdCkgew0KIAkJCWlmICghY3AtPmNwb3J0ICYm ICEoY3AtPmZsYWdzICYgSVBfVlNfQ09OTl9GX05PX0NQT1JUKSkNCkBAIC04 MTcsNyArODE3LDcgQEANCiAJCQl9DQogCQkJY3Rfd3JpdGVfbG9jayhoYXNo KTsNCiAJCX0NCi0JCWN0X3dyaXRlX3VubG9jayhoYXNoKTsNCisJCWN0X3dy aXRlX3VubG9ja19iaChoYXNoKTsNCiAJfQ0KIH0NCiANCmRpZmYgLXVyIHYy LjYuMTItcmMzL2xpbnV4L25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMgbGlu dXgvbmV0L2lwdjQvaXB2cy9pcF92c19jdGwuYw0KLS0tIHYyLjYuMTItcmMz L2xpbnV4L25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMJMjAwNS0wNS0wNiAx MzowNDozNy4wMDAwMDAwMDAgKzAzMDANCisrKyBsaW51eC9uZXQvaXB2NC9p cHZzL2lwX3ZzX2N0bC5jCTIwMDUtMDUtMDYgMTQ6MjU6MTguNjM4MzMxNTI4 ICswMzAwDQpAQCAtOTAsNyArOTAsOCBAQA0KICNlbmRpZg0KIA0KIC8qDQot ICoJdXBkYXRlX2RlZmVuc2VfbGV2ZWwgaXMgY2FsbGVkIGZyb20ga2V2ZW50 ZCBhbmQgZnJvbSBzeXNjdGwuDQorICoJdXBkYXRlX2RlZmVuc2VfbGV2ZWwg aXMgY2FsbGVkIGZyb20ga2V2ZW50ZCBhbmQgZnJvbSBzeXNjdGwsDQorICoJ c28gaXQgbmVlZHMgdG8gcHJvdGVjdCBpdHNlbGYgZnJvbSBzb2Z0aXJxcw0K ICAqLw0KIHN0YXRpYyB2b2lkIHVwZGF0ZV9kZWZlbnNlX2xldmVsKHZvaWQp DQogew0KQEAgLTExMCw2ICsxMTEsOCBAQA0KIA0KIAlub21lbSA9IChhdmFp bG1lbSA8IHN5c2N0bF9pcF92c19hbWVtdGhyZXNoKTsNCiANCisJbG9jYWxf YmhfZGlzYWJsZSgpOw0KKw0KIAkvKiBkcm9wX2VudHJ5ICovDQogCXNwaW5f bG9jaygmX19pcF92c19kcm9wZW50cnlfbG9jayk7DQogCXN3aXRjaCAoc3lz Y3RsX2lwX3ZzX2Ryb3BfZW50cnkpIHsNCkBAIC0yMDYsNiArMjA5LDggQEAN CiAJaWYgKHRvX2NoYW5nZSA+PSAwKQ0KIAkJaXBfdnNfcHJvdG9jb2xfdGlt ZW91dF9jaGFuZ2Uoc3lzY3RsX2lwX3ZzX3NlY3VyZV90Y3A+MSk7DQogCXdy aXRlX3VubG9jaygmX19pcF92c19zZWN1cmV0Y3BfbG9jayk7DQorDQorCWxv Y2FsX2JoX2VuYWJsZSgpOw0KIH0NCiANCiANCkBAIC0xMzYwLDkgKzEzNjUs NyBAQA0KIAkJCS8qIFJlc3RvcmUgdGhlIGNvcnJlY3QgdmFsdWUgKi8NCiAJ CQkqdmFscCA9IHZhbDsNCiAJCX0gZWxzZSB7DQotCQkJbG9jYWxfYmhfZGlz YWJsZSgpOw0KIAkJCXVwZGF0ZV9kZWZlbnNlX2xldmVsKCk7DQotCQkJbG9j YWxfYmhfZW5hYmxlKCk7DQogCQl9DQogCX0NCiAJcmV0dXJuIHJjOw0K --1607745702-2026925329-1115389282=:1504-- From kaber@trash.net Fri May 6 07:40:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 07:41:01 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46EeoOv014753 for ; Fri, 6 May 2005 07:40:51 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DU3zb-0007YW-MB; Fri, 06 May 2005 16:39:51 +0200 Message-ID: <427B81B7.2010808@trash.net> Date: Fri, 06 May 2005 16:39:51 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, dlstevens@us.ibm.com, laforge@gnumonks.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, pb@bieringer.de, usagi-users@linux-ipv6.org, yasuyuki.kozakai@toshiba.co.jp, yoshfuji@linux-ipv6.org Subject: Re: netfilter6: ICMPv6 type 143 doesn't match References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 385 Lines: 13 Herbert Xu wrote: > Patrick McHardy wrote: >>+ err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); >>+ if (err < 0) { >>+ IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); > > You're now incrementing this twice since the callers will also > increment this. Thanks, I've removed the line again. Regards Patrick From tgraf@suug.ch Fri May 6 07:43:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 07:43:16 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46EhCOv015289 for ; Fri, 6 May 2005 07:43:13 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 559AF1C0EB; Fri, 6 May 2005 16:43:08 +0200 (CEST) Date: Fri, 6 May 2005 16:43:08 +0200 From: Thomas Graf To: jamal Cc: Pablo Neira , netdev@oss.sgi.com Subject: Re: [RFC] textsearch infrastructure + skb_find_text() Message-ID: <20050506144308.GF28419@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> <427A51A2.8090600@eurodev.net> <20050505174224.GB25977@postel.suug.ch> <427AC96E.2020208@eurodev.net> <20050506123639.GE28419@postel.suug.ch> <1115384649.7660.140.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115384649.7660.140.camel@localhost.localdomain> X-archive-position: 860 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4293 Lines: 118 * jamal <1115384649.7660.140.camel@localhost.localdomain> 2005-05-06 09:04 > I dont see any difference between the two in terms of state storage. > Can you really avoid storing state? Can you give an example? The state is kept on the stack since there is only one call to the algorithm's search function per match iteration. Look at the code below, it is called once and fetches the data continuously until EOF or a match has been found. get_text() sets *text to the start of the next buffer at the virtual absolute position `consumed' and returns the length of the new buffer. int i, q = 0, consumed = state->offset; for (;;) { text_len = conf->get_text(consumed, &text, conf, state); if (text_len == 0) break; /* no match found */ for (i = 0; i < text_len; i++) { while (q > 0 && pattern[q] != text[i]) q = prefix_tbl[q - 1]; if (pattern[q] == text[i]) q++; if (q == pattern_len) { state->offset = consumed + i - pattern_len + 1; return state->offset; } } consumed += text_len; } A very simple implementation of get_text() could look like this: static inline int get_linear_text(int offset, unsigned char **text, struct ts_config *conf, struct ts_state *state) { unsigned char *string = (unsigned char *) state->args[0]; size_t len = state->args[1]; if (offset < len) { *text = string + offset; return len - offset; } else return 0; } As you can see, it expects a char * in args[0] and the length of it in args[1]. All it does is check whether all bytes have been read already and if not return the remaining part of the buffer so even if the search algorithm can't consume all the bytes returned it will still work as expected. > The other scheme is to have the callback return a code which says > "get me more text" or " enough/done" in which case the state machine for > the search alg is no different in both cases. In the case of interruptable search algorithms, we have to make sure to save enough state information to continue at the same position. Surely this is no problem with KMP or BM but gets real complex in the case of automata based searching algorithms such as regular expressions. It would mean to have a set of conditional jumps into the algorithms, I tried it and it really gets complex. Example: Assume we are are processing a regular expression with automata approach and are currently look at a 'ANY' (+) recurrence. First thing we do is check if there are more torkens to parse, if not we can return true immediately. Otherwise we have to do a look ahead on the pattern and cycle through the text looking if we can find the token following the 'ANY' recurrence, e.g. pattern := "c*\d+A" current-token := \d+ next-token := 'A' text := "ccc123A" current-character := text[3] ('1') while NOT next-token matches current-character do if current-token matches current-character then goto no-match endif current-character := next(text) proceed-to-next-character() /* At this position we'd have to return, fetch new text and come back right here with the exact same state, difficult huh? */ if NOT more text to process then goto no-match endif endwhile Not sure if this is clear out of context but maybe it gives you an idea why it is easier to maintain state of get_text() rather than the state of a whole searching algorithm. > It depends on the search algorithm - if it is small, you benefit from > either scheme. If it is large, you loose in both. That's true, smallish algorithms such as KMP and BM don't gain much but for complex algorithms such as regexp my approach really is a lot faster. > > and > > b) it allows the searching algorithm to do prefetching. > > > > I am trying to sink this in; prefetching would be valuable for regexp, > but why would the other scheme not be able to do it? I'm really not an expert on the validity of L1 caches and how to optimize it best but I believe that the less memory movement is in between the more likely prefetching helps? Both schemes involve a switch to another stack namespace but get_text() tends to be a lot smaller and less intrusive than a store & reload of a complex state machine. I really can't tell which is better regarding this subject without trying it out actually. From kaber@trash.net Fri May 6 08:40:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 08:40:08 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46Fe4Ov022087 for ; Fri, 6 May 2005 08:40:04 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DU4vb-0000Ul-CJ; Fri, 06 May 2005 17:39:47 +0200 Message-ID: <427B8FC3.4000305@trash.net> Date: Fri, 06 May 2005 17:39:47 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev Subject: [NET]: Avoid useless iterating in netlink dump functions Content-Type: multipart/mixed; boundary="------------010904070101080906080802" X-archive-position: 861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 5587 Lines: 145 This is a multi-part message in MIME format. --------------010904070101080906080802 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This patch changes a couple of places like this: for (h = 0; h <= tbl->hash_mask; h++) { if (h < s_h) continue; to this: for (h = s_h; h <= tbl->hash_mask; h++) { The only difference is that we can now get past the loop with h > tbl->hash_mask if hash_mask was decreased between two callbacks and h was already past the new value. But it still behaves identical, nothing is dumped. --------------010904070101080906080802 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" [NET]: Avoid useless iterating in netlink dump functions Signed-off-by: Patrick McHardy --- commit 4c2ae3efd96b7c6ed7ae62d820c13e95ba8564f1 tree 9f5362e759864bc9b3185ba39b0441952b0b8468 parent 6a800d456a81a9046634bcd26d868fd537f0c9ae author Patrick McHardy 1115327686 +0200 committer Patrick McHardy 1115327686 +0200 Index: net/core/neighbour.c =================================================================== --- b969230022b6b8a7a93466b7ddef6b3d0a79fea3/net/core/neighbour.c (mode:100644 sha1:43bdc521e20d9564ccec6472b30d95328e7d1329) +++ 9f5362e759864bc9b3185ba39b0441952b0b8468/net/core/neighbour.c (mode:100644 sha1:71d444de4bb752511ea838710248130d1559eb4e) @@ -1598,9 +1598,7 @@ int rc, h, s_h = cb->args[1]; int idx, s_idx = idx = cb->args[2]; - for (h = 0; h <= tbl->hash_mask; h++) { - if (h < s_h) - continue; + for (h = s_h; h <= tbl->hash_mask; h++) { if (h > s_h) s_idx = 0; read_lock_bh(&tbl->lock); Index: net/core/rtnetlink.c =================================================================== --- b969230022b6b8a7a93466b7ddef6b3d0a79fea3/net/core/rtnetlink.c (mode:100644 sha1:00caf4b318b20831c8fad5226c7c3cd358b4995b) +++ 9f5362e759864bc9b3185ba39b0441952b0b8468/net/core/rtnetlink.c (mode:100644 sha1:bfb5b8efa710524ba4ee7cd14acf7c49a6fac004) @@ -419,9 +419,9 @@ if (s_idx == 0) s_idx = 1; - for (idx=1; idxnlh->nlmsg_type-RTM_BASE; - if (idx < s_idx || idx == PF_PACKET) + if (idx == PF_PACKET) continue; if (rtnetlink_links[idx] == NULL || rtnetlink_links[idx][type].dumpit == NULL) Index: net/decnet/dn_route.c =================================================================== --- b969230022b6b8a7a93466b7ddef6b3d0a79fea3/net/decnet/dn_route.c (mode:100644 sha1:1e7b5c3ea2154d94251d04ea0de69fda06f9f58e) +++ 9f5362e759864bc9b3185ba39b0441952b0b8468/net/decnet/dn_route.c (mode:100644 sha1:2b2bad3e4f902a8fb595596c35263c96e7c10779) @@ -1631,9 +1631,7 @@ s_h = cb->args[0]; s_idx = idx = cb->args[1]; - for(h = 0; h <= dn_rt_hash_mask; h++) { - if (h < s_h) - continue; + for(h = s_h; h <= dn_rt_hash_mask; h++) { if (h > s_h) s_idx = 0; rcu_read_lock_bh(); Index: net/decnet/dn_table.c =================================================================== --- b969230022b6b8a7a93466b7ddef6b3d0a79fea3/net/decnet/dn_table.c (mode:100644 sha1:dad5603912be3ed4959fb4d5565c9df4d5830f25) +++ 9f5362e759864bc9b3185ba39b0441952b0b8468/net/decnet/dn_table.c (mode:100644 sha1:23d106be9fdf41e4afd1e83377607084c08e8c68) @@ -394,9 +394,7 @@ int h, s_h; s_h = cb->args[2]; - for(h = 0; h < dz->dz_divisor; h++) { - if (h < s_h) - continue; + for(h = s_h; h < dz->dz_divisor; h++) { if (h > s_h) memset(&cb->args[3], 0, sizeof(cb->args) - 3*sizeof(cb->args[0])); if (dz->dz_hash == NULL || dz->dz_hash[h] == NULL) Index: net/ipv4/fib_frontend.c =================================================================== --- b969230022b6b8a7a93466b7ddef6b3d0a79fea3/net/ipv4/fib_frontend.c (mode:100644 sha1:563e7d61270612b64a5f67684c5eea1662b66a31) +++ 9f5362e759864bc9b3185ba39b0441952b0b8468/net/ipv4/fib_frontend.c (mode:100644 sha1:f398b2fc63c1c48cdbfb20fae330ff3a60e51ed8) @@ -344,8 +344,7 @@ if (s_t == 0) s_t = cb->args[0] = RT_TABLE_MIN; - for (t=s_t; t<=RT_TABLE_MAX; t++) { - if (t < s_t) continue; + for (t = s_t; t <= RT_TABLE_MAX; t++) { if (t > s_t) memset(&cb->args[1], 0, sizeof(cb->args)-sizeof(cb->args[0])); if ((tb = fib_get_table(t))==NULL) Index: net/ipv4/fib_hash.c =================================================================== --- b969230022b6b8a7a93466b7ddef6b3d0a79fea3/net/ipv4/fib_hash.c (mode:100644 sha1:6506dcc01b460e7c5af35ff756f4819c23bd5d30) +++ 9f5362e759864bc9b3185ba39b0441952b0b8468/net/ipv4/fib_hash.c (mode:100644 sha1:c1cebf82001b3a2c9d512c75b769baf0d4b6888f) @@ -723,8 +723,7 @@ int h, s_h; s_h = cb->args[2]; - for (h=0; h < fz->fz_divisor; h++) { - if (h < s_h) continue; + for (h = s_h; h < fz->fz_divisor; h++) { if (h > s_h) memset(&cb->args[3], 0, sizeof(cb->args) - 3*sizeof(cb->args[0])); Index: net/ipv4/route.c =================================================================== --- b969230022b6b8a7a93466b7ddef6b3d0a79fea3/net/ipv4/route.c (mode:100644 sha1:199311746932ee3952abebc5d008b8c9daf9c11b) +++ 9f5362e759864bc9b3185ba39b0441952b0b8468/net/ipv4/route.c (mode:100644 sha1:6a96ebfb4a1a23f7c6ce8a743160b3ae3e74020e) @@ -2770,8 +2770,7 @@ s_h = cb->args[0]; s_idx = idx = cb->args[1]; - for (h = 0; h <= rt_hash_mask; h++) { - if (h < s_h) continue; + for (h = s_h; h <= rt_hash_mask; h++) { if (h > s_h) s_idx = 0; rcu_read_lock_bh(); --------------010904070101080906080802-- From jdmason@us.ibm.com Fri May 6 09:04:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 09:04:11 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46G42Ov023573 for ; Fri, 6 May 2005 09:04:08 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j46G3cT9614680 for ; Fri, 6 May 2005 12:03:41 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j46G3c3w366832 for ; Fri, 6 May 2005 10:03:38 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j46G3bbX013991 for ; Fri, 6 May 2005 10:03:38 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j46G3bJn013965; Fri, 6 May 2005 10:03:37 -0600 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [patch linux-2.6.12-rc3-mm3 1/7] r8169: de-obfuscate supported PCI ID Date: Fri, 6 May 2005 11:03:34 -0500 User-Agent: KMail/1.7.2 Cc: Andrew Morton , netdev@oss.sgi.com, jgarzik@pobox.com References: <20050504221057.1e02a402.akpm@osdl.org> <20050505110052.62c1c2cb.akpm@osdl.org> <20050505225656.GA11200@electric-eye.fr.zoreil.com> In-Reply-To: <20050505225656.GA11200@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505061103.34705.jdmason@us.ibm.com> X-archive-position: 862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 36 Lines: 1 I only received patches 1,3, and 7. From tgraf@suug.ch Fri May 6 09:12:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 09:12:11 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46GC5Ov024568 for ; Fri, 6 May 2005 09:12:05 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 5FC2B1C0EB; Fri, 6 May 2005 18:12:09 +0200 (CEST) Date: Fri, 6 May 2005 18:12:09 +0200 From: Thomas Graf To: netdev@oss.sgi.com Subject: [PATCHSET] various iproute2 patches Message-ID: <20050506161209.GG28419@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2762 Lines: 74 Seems my previous attempt didn't get through the mailinglist, probably exceeded maximum attachment size. Patches can be found here: http://people.suug.ch/~tgr/iproute2/patches/2.6.12-rc2/ I merged my tree and sorted out all patches covering bits for the 2.6.12 release. ChangeLog | 13 Makefile | 7 etc/iproute2/ematch_map | 5 include/linux/ip_mp_alg.h | 22 + include/linux/rtnetlink.h | 21 - include/linux/tc_ematch/tc_em_cmp.h | 26 + include/linux/tc_ematch/tc_em_meta.h | 69 ++++ include/linux/tc_ematch/tc_em_nbyte.h | 13 include/linux/xfrm.h | 5 include/utils.h | 2 ip/iproute.c | 32 ++ tc/Makefile | 16 - tc/em_cmp.c | 188 ++++++++++++ tc/em_meta.c | 524 ++++++++++++++++++++++++++++++++++ tc/em_nbyte.c | 144 +++++++++ tc/em_u32.c | 178 +++++++++++ tc/emp_ematch.l | 143 +++++++++ tc/emp_ematch.y | 102 ++++++ tc/f_basic.c | 146 +++++++++ tc/m_ematch.c | 492 +++++++++++++++++++++++++++++++ tc/m_ematch.h | 177 +++++++++++ tc/tc.c | 19 - testsuite/Makefile | 36 +- testsuite/iproute2/Makefile | 33 ++ testsuite/lib/generic.sh | 88 +++++ testsuite/tests/cbq.t | 10 testsuite/tests/cls-testbed.t | 68 ++++ testsuite/tests/cls/attrs-testbed.t | 33 ++ testsuite/tests/cls/attrs/police.t | 20 + testsuite/tests/cls/route.t | 24 + testsuite/tests/cls/tcindex.t | 11 testsuite/tests/dsmark.t | 31 ++ testsuite/tests/policer | 13 testsuite/tests/std-cbq | 10 34 files changed, 2657 insertions(+), 64 deletions(-) 01_iproute2_ematch.diff Support for extended matches and basic classifier 02_iproute_ematch_map.diff ematch map file 03_iproute2_makefile_fixes.diff Fix clean/distclean to delete the bison output 04_iproute2_update_headers.diff Update to latest kernel header versions 05_iproute2_testsuite_update.diff Update to latest testsuite 06_iproute2_multipath_selection.diff IPv4 multipath routing algorithm selection 07_iproute2_cscope_target.diff cscope target for Makefile 08_iproute2_batching_fixes.diff Fix off-by-one during argument generation Assume stdin when no argument is given to -batch 09_iproute2_update_changelog.diff Update ChangeLog From akepner@sgi.com Fri May 6 09:14:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 09:14:02 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46GDxOv025110 for ; Fri, 6 May 2005 09:14:00 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j46GDgxT024196 for ; Fri, 6 May 2005 11:13:42 -0500 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-189.corp.sgi.com [134.15.0.189]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j46GDb5x22291832; Fri, 6 May 2005 09:13:37 -0700 (PDT) Date: Fri, 6 May 2005 09:12:00 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: "David S. Miller" cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: [TG3]: Add tagged status support In-Reply-To: <20050505211735.3829cff2.davem@davemloft.net> Message-ID: References: <20050505211735.3829cff2.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 864 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 417 Lines: 14 On Thu, 5 May 2005, David S. Miller wrote: > ..... > I also removed the MAILBOX readback in the normal interrupt handling > paths. Network processing overhead minded folks, particular the SGI > NUMA people (hint hint) should really really check out this patch :-) > I'll put it on my to-do list to check out this and other recent tg3 patches. It may be a week or so until I can get to this, however. -- Arthur From rick.jones2@hp.com Fri May 6 09:19:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 09:19:23 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46GJHOv025799 for ; Fri, 6 May 2005 09:19:19 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 0EECB402293; Fri, 6 May 2005 09:19:00 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id JAA20313; Fri, 6 May 2005 09:18:59 -0700 (PDT) Message-ID: <427B98F3.1020003@hp.com> Date: Fri, 06 May 2005 09:18:59 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Iatrou Cc: netdev@oss.sgi.com Subject: Re: e1000 (?) jumbo frames performance issue References: <200505051928.32496.m.iatrou@freemail.gr> <427A7F5B.8050704@hp.com> <200505060055.55778.m.iatrou@freemail.gr> In-Reply-To: <200505060055.55778.m.iatrou@freemail.gr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 865 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 775 Lines: 22 > >>It might be good to add CPU utilization figures - for 2.3pl1 that means >>editing the makefile to add a -DUSE_PROC_STAT and recompiling. Or you can >>grab netperf 2.4.0-rc3 from: >> >>ftp://ftp.cup.hp.com/dist/networking/benchmarks/netperf/experimental/ >> >>if you cannot find it elsewhere, and that will (try to) compile-in the >>right CPU utilization mechanism automagically. > > > I already did a custom CPU usage instrumentation (based on infos > from /proc/stat -- the latest netperf does the same thing, doesn't it?) and > it seems that system has plenty of idle time (up to 50% if I recall correct) IIRC you stated that the boxes were UP? If changing netperf settings didn't affect much, then kernel profiles and/or packet traces may be in order. rick From romieu@fr.zoreil.com Fri May 6 09:38:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 09:38:23 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46GcCOv026951 for ; Fri, 6 May 2005 09:38:13 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j46GbA5f004740; Fri, 6 May 2005 18:37:10 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j46Gb23S004739; Fri, 6 May 2005 18:37:02 +0200 Date: Fri, 6 May 2005 18:37:02 +0200 From: Francois Romieu To: Jon Mason Cc: Andrew Morton , netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch linux-2.6.12-rc3-mm3 1/7] r8169: de-obfuscate supported PCI ID Message-ID: <20050506163702.GA3475@electric-eye.fr.zoreil.com> References: <20050504221057.1e02a402.akpm@osdl.org> <20050505110052.62c1c2cb.akpm@osdl.org> <20050505225656.GA11200@electric-eye.fr.zoreil.com> <200505061103.34705.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505061103.34705.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 866 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 372 Lines: 15 Jon Mason : > I only received patches 1,3, and 7. If the DSNs don't lie, the messages should be somewhere in the pipe behind oss.sgi.com. Alternate location: - http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.12-rc3-mm3 More alternate location: - rsync://www.fr.zoreil.com/linux-2.6.git/ commit 778e3479a76e03b319fc18a6416cb9b766029cc3 -- Ueimor From baruch@ev-en.org Fri May 6 10:37:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 10:37:58 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46HboOv029306 for ; Fri, 6 May 2005 10:37:51 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 1CB8A11A6DC; Fri, 6 May 2005 20:37:32 +0300 (IDT) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id 83DBB11A6C4; Fri, 6 May 2005 20:37:29 +0300 (IDT) From: Baruch Even To: Stephen Hemminger Cc: netdev@oss.sgi.com, Baruch Even , Douglas Leith , "David S.Miller" Message-Id: <20050506173729.20140.93205.37072@galon.ev-en.org> Subject: [TCP 0/4] H-TCP patches on top of Stephens cc framework Date: Fri, 6 May 2005 20:37:29 +0300 (IDT) X-archive-position: 867 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 469 Lines: 9 This is a first post of the H-TCP framework on top of Stephens congestion control framework. Hopefully the use of the framework will make it easier to understand the logic of the H-TCP algorithm. It definitely helped me :-) The code is licensed under the GNU GPL v2, and according to that we know this gives an implicit patent license to users of this code. An explicit licensing to OSDL for the purpose of sub-licensing is in the works to alleviate any fear. Baruch From baruch@ev-en.org Fri May 6 10:38:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 10:38:57 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46HcqOv029373 for ; Fri, 6 May 2005 10:38:52 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id BB1AF11A6DC; Fri, 6 May 2005 20:38:34 +0300 (IDT) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id A7A8311A6C4; Fri, 6 May 2005 20:38:31 +0300 (IDT) From: Baruch Even To: Stephen Hemminger Cc: netdev@oss.sgi.com, Baruch Even , Douglas Leith , "David S.Miller" Message-Id: <20050506173831.20140.43017.29524@galon.ev-en.org> In-Reply-To: <20050506173729.20140.93205.37072@galon.ev-en.org> References: <20050506173729.20140.93205.37072@galon.ev-en.org> Subject: [PATCH TCP 1/4] Add undo callback to Stephens cc framework Date: Fri, 6 May 2005 20:38:31 +0300 (IDT) X-archive-position: 868 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1645 Lines: 43 When undoing a congestion event due to reordering detection, the ssthresh is multiplied by two. This is incorrect for anything other than (New)Reno, for example BIC and H-TCP. This patch adds a callback that these CC algorithms can attach to, the actual callback is not realized yet for BIC. The callback is already in use in the H-TCP patches. Signed-Off-By: Baruch Even --- include/net/tcp.h | 1 + net/ipv4/tcp_input.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) Index: 2.6.11-stephen-htcp/include/net/tcp.h =================================================================== --- 2.6.11-stephen-htcp.orig/include/net/tcp.h +++ 2.6.11-stephen-htcp/include/net/tcp.h @@ -1196,6 +1196,7 @@ struct tcp_ca_type { void (*set_state)(struct tcp_sock *tp, u8 new_state); void (*cwnd_event)(struct tcp_sock *tp, enum tcp_ca_event ev); + u32 (*undo_cwnd)(struct tcp_sock *tp); struct list_head list; struct module *owner; Index: 2.6.11-stephen-htcp/net/ipv4/tcp_input.c =================================================================== --- 2.6.11-stephen-htcp.orig/net/ipv4/tcp_input.c +++ 2.6.11-stephen-htcp/net/ipv4/tcp_input.c @@ -1573,7 +1573,10 @@ static void DBGUNDO(struct sock *sk, str static void tcp_undo_cwr(struct tcp_sock *tp, int undo) { if (tp->prior_ssthresh) { - tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); + if (tp->ca_proto->undo_cwnd) + tp->snd_cwnd = tp->ca_proto->undo_cwnd(tp); + else + tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); if (undo && tp->prior_ssthresh > tp->snd_ssthresh) { tp->snd_ssthresh = tp->prior_ssthresh; From baruch@ev-en.org Fri May 6 10:40:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 10:40:57 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46HerOv029965 for ; Fri, 6 May 2005 10:40:53 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 1769511A6DC; Fri, 6 May 2005 20:40:36 +0300 (IDT) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id 364FD11A6C4; Fri, 6 May 2005 20:40:34 +0300 (IDT) From: Baruch Even To: Stephen Hemminger Cc: netdev@oss.sgi.com, Baruch Even , Douglas Leith , "David S.Miller" Message-Id: <20050506174034.20140.37477.77065@galon.ev-en.org> In-Reply-To: <20050506173729.20140.93205.37072@galon.ev-en.org> References: <20050506173729.20140.93205.37072@galon.ev-en.org> Subject: [PATCH TCP 3/4] Adjust alpha according to RTT timing Date: Fri, 6 May 2005 20:40:34 +0300 (IDT) X-archive-position: 870 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1333 Lines: 40 This is another H-TCP layer patch. This patch adds an rtt scaling to the alpha parameter. This increases alpha for large distance networks. Signed-Off-By: Baruch Even --- net/ipv4/tcp_htcp.c | 13 +++++++++++++ 1 files changed, 13 insertions(+) Index: 2.6.11-stephen-htcp/net/ipv4/tcp_htcp.c =================================================================== --- 2.6.11-stephen-htcp.orig/net/ipv4/tcp_htcp.c +++ 2.6.11-stephen-htcp/net/ipv4/tcp_htcp.c @@ -12,6 +12,10 @@ #define BETA_MIN (1<<6) /* 0.5 with shift << 7 */ #define BETA_MAX 102 /* 0.8 with shift << 7 */ +static int use_rtt_scaling = 1; +module_param(use_rtt_scaling, int, 0644); +MODULE_PARM_DESC(use_rtt_scaling, "turn on/off RTT scaling"); + struct htcp_ca { u32 alpha; /* Fixed point arith, << 7 */ u32 beta; /* Fixed point arith, << 7 */ @@ -85,6 +89,15 @@ static inline void htcp_alpha_update(str ca->alpha = 2*factor*((1<<7)-ca->beta); if (!ca->alpha) ca->alpha = 1<<7; + + if (use_rtt_scaling && minRTT) { + u32 scale; + scale = (HZ<<3)/(10*minRTT); + scale = min(max(scale, 1U<<2), 10U<<3); /* clamping ratio to interval [0.5,10]<<3 */ + ca->alpha = (ca->alpha<<3)/scale; + if (!ca->alpha) + ca->alpha = 1<<7; + } } /* After we have the rtt data to calculate beta, we'd still prefer to wait one From baruch@ev-en.org Fri May 6 10:39:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 10:40:05 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46HdwOv029581 for ; Fri, 6 May 2005 10:39:58 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 008F211A6DC; Fri, 6 May 2005 20:39:40 +0300 (IDT) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id 276CC11A6C4; Fri, 6 May 2005 20:39:32 +0300 (IDT) From: Baruch Even To: Stephen Hemminger Cc: netdev@oss.sgi.com, Baruch Even , Douglas Leith , "David S.Miller" Message-Id: <20050506173932.20140.77512.44723@galon.ev-en.org> In-Reply-To: <20050506173729.20140.93205.37072@galon.ev-en.org> References: <20050506173729.20140.93205.37072@galon.ev-en.org> Subject: [PATCH TCP 2/4] Implement H-TCP congestion control algorithm Date: Fri, 6 May 2005 20:39:32 +0300 (IDT) X-archive-position: 869 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 7464 Lines: 257 H-TCP is a congestion control algorithm developed at the Hamilton Institute, by Douglas Leith and Robert Shorten. It is extending the standard Reno algorithm with mode switching is thus a relatively simple modification. H-TCP is defined in a layered manner as it is still a research platform. The basic form includes the modification of beta according to the ratio of maxRTT to min RTT and the alpha=2*factor*(1-beta) relation, where factor is dependant on the time since last congestion. The other layers improve convergence by adding appropriate factors to alpha. The following patch implements the H-TCP algorithm in it's basic form. Signed-Off-By: Baruch Even --- net/ipv4/Kconfig | 10 ++ net/ipv4/Makefile | 1 net/ipv4/tcp_htcp.c | 198 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 209 insertions(+) Index: 2.6.11-stephen-htcp/net/ipv4/tcp_htcp.c =================================================================== --- /dev/null +++ 2.6.11-stephen-htcp/net/ipv4/tcp_htcp.c @@ -0,0 +1,198 @@ +/* + * H-TCP congestion control. The algorithm is detailed in: + * R.N.Shorten, D.J.Leith: + * "H-TCP: TCP for high-speed and long-distance networks" + * Proc. PFLDnet, Argonne, 2004. + * http://www.hamilton.ie/net/htcp3.pdf + */ + +#include +#include +#include +#include + +#define BETA_MIN (1<<6) /* 0.5 with shift << 7 */ +#define BETA_MAX 102 /* 0.8 with shift << 7 */ + +struct htcp_ca { + u32 alpha; /* Fixed point arith, << 7 */ + u32 beta; /* Fixed point arith, << 7 */ + u32 modeswitch; /* Delay modeswitch until we had at least one congestion event */ + u32 ccount; /* Number of RTTs since last congestion event */ + u32 minRTT; + u32 maxRTT; + + u32 undo_ccount; + u32 undo_maxRTT; +}; + +static inline void htcp_reset(struct htcp_ca *ca) +{ + ca->undo_ccount = ca->ccount; + ca->undo_maxRTT = ca->maxRTT; + + ca->ccount = 0; +} + +static u32 htcp_cwnd_undo(struct tcp_sock *tp) +{ + struct htcp_ca *ca = tcp_ca(tp); + ca->ccount = ca->undo_ccount; + ca->maxRTT = ca->undo_maxRTT; + return max(tp->snd_cwnd, (tp->snd_ssthresh<<7)/ca->beta); +} + +static inline void measure_rtt(struct tcp_sock *tp) +{ + struct htcp_ca *ca = tcp_ca(tp); + u32 srtt = tp->srtt>>3; + + /* keep track of minimum RTT seen so far, minRTT is zero at first */ + if (ca->minRTT > srtt || !ca->minRTT) + ca->minRTT = srtt; + + /* max RTT */ + if (tp->ca_state == TCP_CA_Open && tp->snd_ssthresh < 0xFFFF && ca->ccount > 3) { + if (ca->maxRTT < ca->minRTT) + ca->maxRTT = ca->minRTT; + if (ca->maxRTT < srtt && srtt <= ca->maxRTT+HZ/50) + ca->maxRTT = srtt; + } +} + +static inline void htcp_beta_update(struct htcp_ca *ca, u32 minRTT, u32 maxRTT) +{ + if (ca->modeswitch && minRTT > max(HZ/100, 1) && maxRTT) { + ca->beta = (minRTT<<7)/maxRTT; + if (ca->beta < BETA_MIN) + ca->beta = BETA_MIN; + else if (ca->beta > BETA_MAX) + ca->beta = BETA_MAX; + } else { + ca->beta = BETA_MIN; + ca->modeswitch = 1; + } +} + +static inline void htcp_alpha_update(struct htcp_ca *ca, u32 minRTT) +{ + u32 factor = 1; + u32 diff = ca->ccount * minRTT; /* time since last backoff */ + + if (diff > HZ) { + diff -= HZ; + factor = 1+ ( 10*diff + ((diff/2)*(diff/2)/HZ) )/HZ; + } + + ca->alpha = 2*factor*((1<<7)-ca->beta); + if (!ca->alpha) + ca->alpha = 1<<7; +} + +/* After we have the rtt data to calculate beta, we'd still prefer to wait one + * rtt before we adjust our beta to ensure we are working from a consistent + * data. + * + * This function should be called when we hit a congestion event since only at + * that point do we really have a real sense of maxRTT (the queues en route + * were getting just too full now). + */ +static void htcp_param_update(struct tcp_sock *tp) +{ + struct htcp_ca *ca = tcp_ca(tp); + u32 minRTT = ca->minRTT; + u32 maxRTT = ca->maxRTT; + + htcp_beta_update(ca, minRTT, maxRTT); + htcp_alpha_update(ca, minRTT); + + /* add slowly fading memory for maxRTT to accommodate routing changes etc */ + if (minRTT > 0 && maxRTT > minRTT) + ca->maxRTT = minRTT + ((maxRTT-minRTT)*95)/100; +} + +static u32 htcp_recalc_ssthresh(struct tcp_sock *tp) +{ + struct htcp_ca *ca = tcp_ca(tp); + return max((tp->snd_cwnd * ca->beta) >> 7, 2U); +} + +static void htcp_cong_avoid(struct tcp_sock *tp, u32 ack, u32 rtt, u32 in_flight) +{ + struct htcp_ca *ca = tcp_ca(tp); + + if (in_flight < tp->snd_cwnd) + return; + + if (tp->snd_cwnd <= tp->snd_ssthresh) { + /* In "safe" area, increase. */ + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + } else { + measure_rtt(tp); + + /* In dangerous area, increase slowly. + * In theory this is tp->snd_cwnd += alpha / tp->snd_cwnd + */ + if (tp->snd_cwnd_cnt >= tp->snd_cwnd) { + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd += ca->alpha; + tp->snd_cwnd_cnt = 0; + ca->ccount++; + } else + tp->snd_cwnd_cnt++; + } +} + +static void htcp_start(struct tcp_sock *tp) +{ + struct htcp_ca *ca = tcp_ca(tp); + ca->alpha = 1<<7; + ca->beta = BETA_MIN; + ca->modeswitch = 0; + ca->ccount = 0; + ca->minRTT = 0; + ca->maxRTT = 0; +} + +static void htcp_ca_state(struct tcp_sock *tp, u8 new_state) +{ + if (new_state == TCP_CA_CWR || new_state == TCP_CA_Recovery) { + htcp_param_update(tp); + htcp_reset(tcp_ca(tp)); + } else if (new_state == TCP_CA_Loss) { + htcp_reset(tcp_ca(tp)); + } +} + +static struct tcp_ca_type htcp = { + .start = htcp_start, + .ssthresh = htcp_recalc_ssthresh, + .min_cwnd = tcp_reno_cwnd_min, + .cong_avoid = htcp_cong_avoid, + .set_state = htcp_ca_state, + .undo_cwnd = htcp_cwnd_undo, + + .owner = THIS_MODULE, + .name = "htcp", +}; + +static int __init htcp_init(void) +{ + BUILD_BUG_ON(sizeof(struct htcp_ca) > TCP_CA_PRIV_SIZE); + BUILD_BUG_ON(BETA_MIN >= BETA_MAX); + tcp_ca_register(&htcp); + return 0; +} + +static void __exit htcp_exit(void) +{ + tcp_ca_unregister(&htcp); +} + +module_init(htcp_init); +module_exit(htcp_exit); + +MODULE_AUTHOR("Baruch Even"); +MODULE_LICENSE("Unknown for now"); +MODULE_DESCRIPTION("H-TCP"); Index: 2.6.11-stephen-htcp/net/ipv4/Kconfig =================================================================== --- 2.6.11-stephen-htcp.orig/net/ipv4/Kconfig +++ 2.6.11-stephen-htcp/net/ipv4/Kconfig @@ -405,6 +405,16 @@ config TCP_CONG_WESTWOOD TCP Westwood+ significantly increases fairness wrt TCP Reno in wired networks and throughput over wireless links. +config TCP_CONG_HTCP + tristate "H-TCP" + default y + ---help--- + H-TCP is a send-side only modifications of the TCP Reno protocol stack + that optimizes the performance of TCP congestion control for high speed + network links. It uses a modeswitch to change the alpha and beta + parameters of TCP Reno based on network conditions and in a way so as + to be fair with other Reno and H-TCP flows. + endmenu Index: 2.6.11-stephen-htcp/net/ipv4/Makefile =================================================================== --- 2.6.11-stephen-htcp.orig/net/ipv4/Makefile +++ 2.6.11-stephen-htcp/net/ipv4/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_IP_PNP) += ipconfig.o obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ obj-$(CONFIG_IP_TCPDIAG) += tcp_diag.o +obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o From baruch@ev-en.org Fri May 6 10:41:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 10:42:02 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46HfwOv030471 for ; Fri, 6 May 2005 10:41:58 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 5D8DC11A6DC; Fri, 6 May 2005 20:41:40 +0300 (IDT) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id 93A7B11A6C4; Fri, 6 May 2005 20:41:35 +0300 (IDT) From: Baruch Even To: Stephen Hemminger Cc: netdev@oss.sgi.com, Baruch Even , Douglas Leith , "David S.Miller" Message-Id: <20050506174135.20140.18257.52874@galon.ev-en.org> In-Reply-To: <20050506173729.20140.93205.37072@galon.ev-en.org> References: <20050506173729.20140.93205.37072@galon.ev-en.org> Subject: [PATCH TCP 4/4] Switch out when bandwidth changes abruptly Date: Fri, 6 May 2005 20:41:35 +0300 (IDT) X-archive-position: 871 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 9668 Lines: 331 This is another H-TCP layer patch. This patch adds a bandwidth switcher so that when a new stream joins we quickly yield bandwidth to it by going back to a backoff factor of one-half. For this to work we have a bandwidth estimator and need a new hook for congestion control algorithms, this is in effect something that can be used generally and is not necessarily specific to H-TCP. But H-TCP is the only user for it at this time. A simple use for it is to export it to user-space for a more accurate bandwidth estimation on the sender side. Signed-Off-By: Baruch Even --- include/net/tcp.h | 1 net/ipv4/tcp_htcp.c | 138 +++++++++++++++++++++++++++++++++++++++------------ net/ipv4/tcp_input.c | 10 +++ 3 files changed, 117 insertions(+), 32 deletions(-) Index: 2.6.11-stephen-htcp/net/ipv4/tcp_htcp.c =================================================================== --- 2.6.11-stephen-htcp.orig/net/ipv4/tcp_htcp.c +++ 2.6.11-stephen-htcp/net/ipv4/tcp_htcp.c @@ -9,6 +9,7 @@ #include #include +#define ALPHA_BASE (1<<7) /* 1.0 with shift << 7 */ #define BETA_MIN (1<<6) /* 0.5 with shift << 7 */ #define BETA_MAX 102 /* 0.8 with shift << 7 */ @@ -16,24 +17,40 @@ static int use_rtt_scaling = 1; module_param(use_rtt_scaling, int, 0644); MODULE_PARM_DESC(use_rtt_scaling, "turn on/off RTT scaling"); +static int use_bandwidth_switch = 1; +module_param(use_bandwidth_switch, int, 0644); +MODULE_PARM_DESC(use_bandwidth_switch, "turn on/off bandwidth switcher"); + struct htcp_ca { - u32 alpha; /* Fixed point arith, << 7 */ - u32 beta; /* Fixed point arith, << 7 */ - u32 modeswitch; /* Delay modeswitch until we had at least one congestion event */ - u32 ccount; /* Number of RTTs since last congestion event */ + u16 alpha; /* Fixed point arith, << 7 */ + u8 beta; /* Fixed point arith, << 7 */ + u8 modeswitch; /* Delay modeswitch until we had at least one congestion event */ + u8 ccount; /* Number of RTTs since last congestion event */ + u8 undo_ccount; + u16 packetcount; u32 minRTT; u32 maxRTT; + u32 snd_cwnd_cnt2; - u32 undo_ccount; u32 undo_maxRTT; + u32 undo_old_maxB; + + /* Bandwidth estimation */ + u32 minB; + u32 maxB; + u32 old_maxB; + u32 Bi; + u32 lasttime; }; static inline void htcp_reset(struct htcp_ca *ca) { ca->undo_ccount = ca->ccount; ca->undo_maxRTT = ca->maxRTT; + ca->undo_old_maxB = ca->old_maxB; ca->ccount = 0; + ca->snd_cwnd_cnt2 = 0; } static u32 htcp_cwnd_undo(struct tcp_sock *tp) @@ -41,6 +58,7 @@ static u32 htcp_cwnd_undo(struct tcp_soc struct htcp_ca *ca = tcp_ca(tp); ca->ccount = ca->undo_ccount; ca->maxRTT = ca->undo_maxRTT; + ca->old_maxB = ca->undo_old_maxB; return max(tp->snd_cwnd, (tp->snd_ssthresh<<7)/ca->beta); } @@ -62,8 +80,53 @@ static inline void measure_rtt(struct tc } } +static void measure_achieved_throughput(struct tcp_sock *tp, u32 pkts_acked) +{ + struct htcp_ca *ca = tcp_ca(tp); + u32 now = tcp_time_stamp; + + /* achieved throughput calculations */ + if (tp->ca_state != TCP_CA_Open && tp->ca_state != TCP_CA_Disorder) { + ca->packetcount = 0; + ca->lasttime = now; + return; + } + + ca->packetcount += pkts_acked; + + if (ca->packetcount >= tp->snd_cwnd - (ca->alpha>>7? : 1) + && now - ca->lasttime >= ca->minRTT + && ca->minRTT > 0) { + __u32 cur_Bi = ca->packetcount*HZ/(now - ca->lasttime); + if (ca->ccount <= 3) { + /* just after backoff */ + ca->minB = ca->maxB = ca->Bi = cur_Bi; + } else { + ca->Bi = (3*ca->Bi + cur_Bi)/4; + if (ca->Bi > ca->maxB) + ca->maxB = ca->Bi; + if (ca->minB > ca->maxB) + ca->minB = ca->maxB; + } + ca->packetcount = 0; + ca->lasttime = now; + } +} + static inline void htcp_beta_update(struct htcp_ca *ca, u32 minRTT, u32 maxRTT) { + if (use_bandwidth_switch) { + u32 maxB = ca->maxB; + u32 old_maxB = ca->old_maxB; + ca->old_maxB = ca->maxB; + + if (!between(5*maxB, 4*old_maxB, 6*old_maxB)) { + ca->beta = BETA_MIN; + ca->modeswitch = 0; + return; + } + } + if (ca->modeswitch && minRTT > max(HZ/100, 1) && maxRTT) { ca->beta = (minRTT<<7)/maxRTT; if (ca->beta < BETA_MIN) @@ -76,8 +139,9 @@ static inline void htcp_beta_update(stru } } -static inline void htcp_alpha_update(struct htcp_ca *ca, u32 minRTT) +static inline void htcp_alpha_update(struct htcp_ca *ca) { + u32 minRTT = ca->minRTT; u32 factor = 1; u32 diff = ca->ccount * minRTT; /* time since last backoff */ @@ -86,18 +150,17 @@ static inline void htcp_alpha_update(str factor = 1+ ( 10*diff + ((diff/2)*(diff/2)/HZ) )/HZ; } - ca->alpha = 2*factor*((1<<7)-ca->beta); - if (!ca->alpha) - ca->alpha = 1<<7; - if (use_rtt_scaling && minRTT) { - u32 scale; - scale = (HZ<<3)/(10*minRTT); + u32 scale = (HZ<<3)/(10*minRTT); scale = min(max(scale, 1U<<2), 10U<<3); /* clamping ratio to interval [0.5,10]<<3 */ - ca->alpha = (ca->alpha<<3)/scale; - if (!ca->alpha) - ca->alpha = 1<<7; + factor = (factor<<3)/scale; + if (!factor) + factor = 1; } + + ca->alpha = 2*factor*((1<<7)-ca->beta); + if (!ca->alpha) + ca->alpha = ALPHA_BASE; } /* After we have the rtt data to calculate beta, we'd still prefer to wait one @@ -115,7 +178,7 @@ static void htcp_param_update(struct tcp u32 maxRTT = ca->maxRTT; htcp_beta_update(ca, minRTT, maxRTT); - htcp_alpha_update(ca, minRTT); + htcp_alpha_update(ca); /* add slowly fading memory for maxRTT to accommodate routing changes etc */ if (minRTT > 0 && maxRTT > minRTT) @@ -125,6 +188,7 @@ static void htcp_param_update(struct tcp static u32 htcp_recalc_ssthresh(struct tcp_sock *tp) { struct htcp_ca *ca = tcp_ca(tp); + htcp_param_update(tp); return max((tp->snd_cwnd * ca->beta) >> 7, 2U); } @@ -142,47 +206,57 @@ static void htcp_cong_avoid(struct tcp_s } else { measure_rtt(tp); + /* keep track of number of round-trip times since last backoff event */ + if (ca->snd_cwnd_cnt2++ > tp->snd_cwnd) { + ca->ccount++; + ca->snd_cwnd_cnt2 = 0; + htcp_alpha_update(ca); + } + /* In dangerous area, increase slowly. * In theory this is tp->snd_cwnd += alpha / tp->snd_cwnd */ - if (tp->snd_cwnd_cnt >= tp->snd_cwnd) { + if ((tp->snd_cwnd_cnt++ * ca->alpha)>>7 >= tp->snd_cwnd) { if (tp->snd_cwnd < tp->snd_cwnd_clamp) - tp->snd_cwnd += ca->alpha; + tp->snd_cwnd++; tp->snd_cwnd_cnt = 0; - ca->ccount++; - } else - tp->snd_cwnd_cnt++; + } } } +static u32 htcp_cwnd_min(struct tcp_sock *tp) +{ + return tp->snd_ssthresh; +} + static void htcp_start(struct tcp_sock *tp) { struct htcp_ca *ca = tcp_ca(tp); - ca->alpha = 1<<7; + memset(ca, 0, sizeof(struct htcp_ca)); + ca->alpha = ALPHA_BASE; ca->beta = BETA_MIN; - ca->modeswitch = 0; - ca->ccount = 0; - ca->minRTT = 0; - ca->maxRTT = 0; + printk(KERN_INFO "htcp started for %p/%p\n", tp, ca); } static void htcp_ca_state(struct tcp_sock *tp, u8 new_state) { - if (new_state == TCP_CA_CWR || new_state == TCP_CA_Recovery) { - htcp_param_update(tp); - htcp_reset(tcp_ca(tp)); - } else if (new_state == TCP_CA_Loss) { + switch (new_state) { + case TCP_CA_CWR: + case TCP_CA_Recovery: + case TCP_CA_Loss: htcp_reset(tcp_ca(tp)); + break; } } static struct tcp_ca_type htcp = { .start = htcp_start, .ssthresh = htcp_recalc_ssthresh, - .min_cwnd = tcp_reno_cwnd_min, + .min_cwnd = htcp_cwnd_min, .cong_avoid = htcp_cong_avoid, .set_state = htcp_ca_state, .undo_cwnd = htcp_cwnd_undo, + .pkts_acked = measure_achieved_throughput, .owner = THIS_MODULE, .name = "htcp", @@ -192,6 +266,8 @@ static int __init htcp_init(void) { BUILD_BUG_ON(sizeof(struct htcp_ca) > TCP_CA_PRIV_SIZE); BUILD_BUG_ON(BETA_MIN >= BETA_MAX); + if (!use_bandwidth_switch) + htcp.pkts_acked = NULL; tcp_ca_register(&htcp); return 0; } Index: 2.6.11-stephen-htcp/include/net/tcp.h =================================================================== --- 2.6.11-stephen-htcp.orig/include/net/tcp.h +++ 2.6.11-stephen-htcp/include/net/tcp.h @@ -1197,6 +1197,7 @@ struct tcp_ca_type { void (*cwnd_event)(struct tcp_sock *tp, enum tcp_ca_event ev); u32 (*undo_cwnd)(struct tcp_sock *tp); + void (*pkts_acked)(struct tcp_sock *tp, u32 num_acked); struct list_head list; struct module *owner; Index: 2.6.11-stephen-htcp/net/ipv4/tcp_input.c =================================================================== --- 2.6.11-stephen-htcp.orig/net/ipv4/tcp_input.c +++ 2.6.11-stephen-htcp/net/ipv4/tcp_input.c @@ -2030,6 +2030,7 @@ static int tcp_clean_rtx_queue(struct so __u32 now = tcp_time_stamp; int acked = 0; __s32 seq_rtt = -1; + u32 pkts_acked = 0; while ((skb = skb_peek(&sk->sk_write_queue)) && skb != sk->sk_send_head) { @@ -2041,9 +2042,12 @@ static int tcp_clean_rtx_queue(struct so * the other end. */ if (after(scb->end_seq, tp->snd_una)) { - if (tcp_skb_pcount(skb) > 1) + if (tcp_skb_pcount(skb) > 1) { + u32 pkts = tcp_skb_pcount(skb); acked |= tcp_tso_acked(sk, skb, now, &seq_rtt); + pkts_acked += pkts - tcp_skb_pcount(skb); + } break; } @@ -2056,6 +2060,7 @@ static int tcp_clean_rtx_queue(struct so */ if (!(scb->flags & TCPCB_FLAG_SYN)) { acked |= FLAG_DATA_ACKED; + pkts_acked += tcp_skb_pcount(skb); } else { acked |= FLAG_SYN_ACKED; tp->retrans_stamp = 0; @@ -2091,6 +2096,9 @@ static int tcp_clean_rtx_queue(struct so tcp_ack_packets_out(sk, tp); } + if (tp->ca_proto->pkts_acked) + tp->ca_proto->pkts_acked(tp, pkts_acked); + #if FASTRETRANS_DEBUG > 0 BUG_TRAP((int)tp->sacked_out >= 0); BUG_TRAP((int)tp->lost_out >= 0); From greg@kroah.com Fri May 6 11:09:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 11:09:39 -0700 (PDT) Received: from perch.kroah.org (mail.kroah.org [69.55.234.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46I9aOv032690 for ; Fri, 6 May 2005 11:09:36 -0700 Received: from [192.168.0.10] (c-24-22-118-199.hsd1.or.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j46I94i15504; Fri, 6 May 2005 11:09:06 -0700 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1DU7G6-5bi-00; Fri, 06 May 2005 11:09:06 -0700 Date: Fri, 6 May 2005 11:09:06 -0700 From: Greg KH To: Baruch Even Cc: netdev@oss.sgi.com, Douglas Leith , "David S.Miller" Subject: Re: [TCP 0/4] H-TCP patches on top of Stephens cc framework Message-ID: <20050506180906.GA21461@kroah.com> References: <20050506173729.20140.93205.37072@galon.ev-en.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050506173729.20140.93205.37072@galon.ev-en.org> User-Agent: Mutt/1.5.8i X-archive-position: 872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev Content-Length: 741 Lines: 16 On Fri, May 06, 2005 at 08:37:29PM +0300, Baruch Even wrote: > This is a first post of the H-TCP framework on top of Stephens congestion > control framework. Hopefully the use of the framework will make it easier to > understand the logic of the H-TCP algorithm. It definitely helped me :-) > > The code is licensed under the GNU GPL v2, and according to that we know this > gives an implicit patent license to users of this code. An explicit licensing > to OSDL for the purpose of sub-licensing is in the works to alleviate any fear. Why would OSDL have anything to do with "sub-licensing" a patent, unless they want to make money off of it? Why not do what other companies have done with GPL granted patents instead? thanks, greg k-h From davem@davemloft.net Fri May 6 11:33:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 11:33:17 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46IXCOv001716 for ; Fri, 6 May 2005 11:33:12 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DU7RJ-0007Jf-00; Fri, 06 May 2005 11:20:41 -0700 Date: Fri, 6 May 2005 11:20:41 -0700 From: "David S. Miller" To: Herbert Xu Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: resend patch: xfrm policybyid Message-Id: <20050506112041.23e51ab8.davem@davemloft.net> In-Reply-To: <20050506132829.GA1943@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505151820.672b89fa.davem@davemloft.net> <20050506132829.GA1943@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 873 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 548 Lines: 17 On Fri, 6 May 2005 23:28:29 +1000 Herbert Xu wrote: > On Thu, May 05, 2005 at 03:18:20PM -0700, David S. Miller wrote: > > On Thu, 05 May 2005 18:17:15 -0400 > > jamal wrote: > > > > > BTW, are the event patches in Davems queue somewhere? > > > I have a few ipsec ones (cosmetic) that i will send later. > > > > I'm not queueing 2.6.13 material yet. > > 2.6.12 bug fixes are a full time job yet :-) > > Dave, would you mind if I pushed these event patches into mm for > some testing? Feel free. From hadi@cyberus.ca Fri May 6 14:04:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:05:02 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46L4wOv010483 for ; Fri, 6 May 2005 14:04:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DUA03-0003To-7C for netdev@oss.sgi.com; Fri, 06 May 2005 17:04:43 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DU9zx-0001Hw-IY; Fri, 06 May 2005 17:04:37 -0400 Subject: Re: [NET]: Avoid useless iterating in netlink dump functions From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: "David S. Miller" , Maillist netdev In-Reply-To: <427B8FC3.4000305@trash.net> References: <427B8FC3.4000305@trash.net> Content-Type: text/plain Organization: unknown Date: Fri, 06 May 2005 17:04:33 -0400 Message-Id: <1115413473.13922.38.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 640 Lines: 24 On Fri, 2005-06-05 at 17:39 +0200, Patrick McHardy wrote: > This patch changes a couple of places like this: > > for (h = 0; h <= tbl->hash_mask; h++) { > if (h < s_h) > continue; > > to this: > > for (h = s_h; h <= tbl->hash_mask; h++) { > > The only difference is that we can now get past the loop with > h > tbl->hash_mask if hash_mask was decreased between two callbacks > and h was already past the new value. But it still behaves identical, > nothing is dumped. > Looks good - you may also wanna treat tcf_dump_walker() and xfrm_dump_sa() the same way then. cheers, jamal From kaber@trash.net Fri May 6 14:13:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:13:44 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46LDfOv011143 for ; Fri, 6 May 2005 14:13:42 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DUA7w-0001My-9h; Fri, 06 May 2005 23:12:52 +0200 Message-ID: <427BDDD4.1000808@trash.net> Date: Fri, 06 May 2005 23:12:52 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "David S. Miller" , Maillist netdev Subject: Re: [NET]: Avoid useless iterating in netlink dump functions References: <427B8FC3.4000305@trash.net> <1115413473.13922.38.camel@localhost.localdomain> In-Reply-To: <1115413473.13922.38.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 876 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 301 Lines: 11 jamal wrote: > Looks good - you may also wanna treat tcf_dump_walker() and > xfrm_dump_sa() the same way then. > action dumping is on my list for more treatment than this :) xfrm_dump_sa()/xfrm_state_walk() could be changed to skip smarter, but that is a different kind of change. Regards Patrick From hadi@cyberus.ca Fri May 6 14:17:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:17:25 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46LHNOv011700 for ; Fri, 6 May 2005 14:17:23 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DUAC6-0000lE-QU for netdev@oss.sgi.com; Fri, 06 May 2005 17:17:10 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DUAC2-0003Ce-Ty; Fri, 06 May 2005 17:17:07 -0400 Subject: Re: [NET]: Avoid useless iterating in netlink dump functions From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: "David S. Miller" , Maillist netdev In-Reply-To: <427BDDD4.1000808@trash.net> References: <427B8FC3.4000305@trash.net> <1115413473.13922.38.camel@localhost.localdomain> <427BDDD4.1000808@trash.net> Content-Type: text/plain Organization: unknown Date: Fri, 06 May 2005 17:17:02 -0400 Message-Id: <1115414222.13922.41.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 877 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 635 Lines: 23 On Fri, 2005-06-05 at 23:12 +0200, Patrick McHardy wrote: > jamal wrote: > > Looks good - you may also wanna treat tcf_dump_walker() and > > xfrm_dump_sa() the same way then. > > > > action dumping is on my list for more treatment than this :) Well, that does sound scary ;-> What do you have in mind. Recall, there are two paths to dumping actions - unlike any other thing in the kernel. > xfrm_dump_sa()/xfrm_state_walk() could be changed to skip > smarter, but that is a different kind of change. > I noticed the policy too is of the the same way. Those are actually a little more trickier than they appear. cheers, jamal From bunk@stusta.de Fri May 6 14:18:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:19:04 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46LIuOv012200 for ; Fri, 6 May 2005 14:18:57 -0700 Received: (qmail 10459 invoked from network); 6 May 2005 21:18:37 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 6 May 2005 21:18:37 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 4D70FBB4E8; Fri, 6 May 2005 23:18:35 +0200 (CEST) Date: Fri, 6 May 2005 23:18:34 +0200 From: Adrian Bunk To: ayyappan.veeraiyan@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] drivers/net/ixgb/: possible cleanups Message-ID: <20050506211834.GM3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 878 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 13234 Lines: 390 This patch contains the following possible cleanups: - make needlessly global code static - remove the following unused global functions: - ixgb_ee.c: ixgb_get_ee_compatibility - ixgb_ee.c: ixgb_get_ee_init_ctrl_reg_1 - ixgb_ee.c: ixgb_get_ee_init_ctrl_reg_2 - ixgb_ee.c: ixgb_get_ee_subsystem_id - ixgb_ee.c: ixgb_get_ee_subvendor_id - ixgb_ee.c: ixgb_get_ee_vendor_id - ixgb_ee.c: ixgb_get_ee_swdpins_reg - ixgb_ee.c: ixgb_get_ee_d3_power - ixgb_ee.c: ixgb_get_ee_d0_power Signed-off-by: Adrian Bunk --- A similar patch was already sent on: - 17 Feb 2005 drivers/net/ixgb/ixgb_ee.c | 170 -------------------------------- drivers/net/ixgb/ixgb_ethtool.c | 2 drivers/net/ixgb/ixgb_hw.c | 26 +++- drivers/net/ixgb/ixgb_hw.h | 26 ---- drivers/net/ixgb/ixgb_main.c | 6 - 5 files changed, 21 insertions(+), 209 deletions(-) --- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.h.old 2005-02-16 15:55:21.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.h 2005-02-16 16:06:28.000000000 +0100 @@ -784,23 +784,8 @@ extern boolean_t ixgb_adapter_stop(struct ixgb_hw *hw); extern boolean_t ixgb_init_hw(struct ixgb_hw *hw); extern boolean_t ixgb_adapter_start(struct ixgb_hw *hw); -extern void ixgb_init_rx_addrs(struct ixgb_hw *hw); extern void ixgb_check_for_link(struct ixgb_hw *hw); extern boolean_t ixgb_check_for_bad_link(struct ixgb_hw *hw); -extern boolean_t ixgb_setup_fc(struct ixgb_hw *hw); -extern void ixgb_clear_hw_cntrs(struct ixgb_hw *hw); -extern boolean_t mac_addr_valid(uint8_t *mac_addr); - -extern uint16_t ixgb_read_phy_reg(struct ixgb_hw *hw, - uint32_t reg_addr, - uint32_t phy_addr, - uint32_t device_type); - -extern void ixgb_write_phy_reg(struct ixgb_hw *hw, - uint32_t reg_addr, - uint32_t phy_addr, - uint32_t device_type, - uint16_t data); extern void ixgb_rar_set(struct ixgb_hw *hw, uint8_t *addr, @@ -818,21 +803,10 @@ uint32_t offset, uint32_t value); -extern void ixgb_clear_vfta(struct ixgb_hw *hw); - /* Access functions to eeprom data */ void ixgb_get_ee_mac_addr(struct ixgb_hw *hw, uint8_t *mac_addr); -uint16_t ixgb_get_ee_compatibility(struct ixgb_hw *hw); uint32_t ixgb_get_ee_pba_number(struct ixgb_hw *hw); -uint16_t ixgb_get_ee_init_ctrl_reg_1(struct ixgb_hw *hw); -uint16_t ixgb_get_ee_init_ctrl_reg_2(struct ixgb_hw *hw); -uint16_t ixgb_get_ee_subsystem_id(struct ixgb_hw *hw); -uint16_t ixgb_get_ee_subvendor_id(struct ixgb_hw *hw); uint16_t ixgb_get_ee_device_id(struct ixgb_hw *hw); -uint16_t ixgb_get_ee_vendor_id(struct ixgb_hw *hw); -uint16_t ixgb_get_ee_swdpins_reg(struct ixgb_hw *hw); -uint8_t ixgb_get_ee_d3_power(struct ixgb_hw *hw); -uint8_t ixgb_get_ee_d0_power(struct ixgb_hw *hw); boolean_t ixgb_get_eeprom_data(struct ixgb_hw *hw); uint16_t ixgb_get_eeprom_word(struct ixgb_hw *hw, uint16_t index); --- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ee.c.old 2005-02-16 15:55:34.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ee.c 2005-02-16 15:58:37.000000000 +0100 @@ -560,25 +560,6 @@ } /****************************************************************************** - * return the compatibility flags from EEPROM - * - * hw - Struct containing variables accessed by shared code - * - * Returns: - * compatibility flags if EEPROM contents are valid, 0 otherwise - ******************************************************************************/ -uint16_t -ixgb_get_ee_compatibility(struct ixgb_hw *hw) -{ - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; - - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->compatibility); - - return(0); -} - -/****************************************************************************** * return the Printed Board Assembly number from EEPROM * * hw - Struct containing variables accessed by shared code @@ -597,82 +578,6 @@ } /****************************************************************************** - * return the Initialization Control Word 1 from EEPROM - * - * hw - Struct containing variables accessed by shared code - * - * Returns: - * Initialization Control Word 1 if EEPROM contents are valid, 0 otherwise - ******************************************************************************/ -uint16_t -ixgb_get_ee_init_ctrl_reg_1(struct ixgb_hw *hw) -{ - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; - - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->init_ctrl_reg_1); - - return(0); -} - -/****************************************************************************** - * return the Initialization Control Word 2 from EEPROM - * - * hw - Struct containing variables accessed by shared code - * - * Returns: - * Initialization Control Word 2 if EEPROM contents are valid, 0 otherwise - ******************************************************************************/ -uint16_t -ixgb_get_ee_init_ctrl_reg_2(struct ixgb_hw *hw) -{ - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; - - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->init_ctrl_reg_2); - - return(0); -} - -/****************************************************************************** - * return the Subsystem Id from EEPROM - * - * hw - Struct containing variables accessed by shared code - * - * Returns: - * Subsystem Id if EEPROM contents are valid, 0 otherwise - ******************************************************************************/ -uint16_t -ixgb_get_ee_subsystem_id(struct ixgb_hw *hw) -{ - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; - - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->subsystem_id); - - return(0); -} - -/****************************************************************************** - * return the Sub Vendor Id from EEPROM - * - * hw - Struct containing variables accessed by shared code - * - * Returns: - * Sub Vendor Id if EEPROM contents are valid, 0 otherwise - ******************************************************************************/ -uint16_t -ixgb_get_ee_subvendor_id(struct ixgb_hw *hw) -{ - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; - - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->subvendor_id); - - return(0); -} - -/****************************************************************************** * return the Device Id from EEPROM * * hw - Struct containing variables accessed by shared code @@ -691,78 +596,3 @@ return(0); } -/****************************************************************************** - * return the Vendor Id from EEPROM - * - * hw - Struct containing variables accessed by shared code - * - * Returns: - * Device Id if EEPROM contents are valid, 0 otherwise - ******************************************************************************/ -uint16_t -ixgb_get_ee_vendor_id(struct ixgb_hw *hw) -{ - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; - - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->vendor_id); - - return(0); -} - -/****************************************************************************** - * return the Software Defined Pins Register from EEPROM - * - * hw - Struct containing variables accessed by shared code - * - * Returns: - * SDP Register if EEPROM contents are valid, 0 otherwise - ******************************************************************************/ -uint16_t -ixgb_get_ee_swdpins_reg(struct ixgb_hw *hw) -{ - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; - - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->swdpins_reg); - - return(0); -} - -/****************************************************************************** - * return the D3 Power Management Bits from EEPROM - * - * hw - Struct containing variables accessed by shared code - * - * Returns: - * D3 Power Management Bits if EEPROM contents are valid, 0 otherwise - ******************************************************************************/ -uint8_t -ixgb_get_ee_d3_power(struct ixgb_hw *hw) -{ - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; - - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->d3_power); - - return(0); -} - -/****************************************************************************** - * return the D0 Power Management Bits from EEPROM - * - * hw - Struct containing variables accessed by shared code - * - * Returns: - * D0 Power Management Bits if EEPROM contents are valid, 0 otherwise - ******************************************************************************/ -uint8_t -ixgb_get_ee_d0_power(struct ixgb_hw *hw) -{ - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; - - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->d0_power); - - return(0); -} --- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ethtool.c.old 2005-02-16 15:58:51.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ethtool.c 2005-02-16 15:59:00.000000000 +0100 @@ -665,7 +665,7 @@ } } -struct ethtool_ops ixgb_ethtool_ops = { +static struct ethtool_ops ixgb_ethtool_ops = { .get_settings = ixgb_get_settings, .set_settings = ixgb_set_settings, .get_drvinfo = ixgb_get_drvinfo, --- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.c.old 2005-02-16 16:03:16.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.c 2005-02-16 16:06:42.000000000 +0100 @@ -47,9 +47,17 @@ static ixgb_phy_type ixgb_identify_phy(struct ixgb_hw *hw); -uint32_t ixgb_mac_reset(struct ixgb_hw *hw); +static void ixgb_clear_hw_cntrs(struct ixgb_hw *hw); +static void ixgb_clear_vfta(struct ixgb_hw *hw); +static void ixgb_init_rx_addrs(struct ixgb_hw *hw); +static uint16_t ixgb_read_phy_reg(struct ixgb_hw *hw, + uint32_t reg_address, + uint32_t phy_address, + uint32_t device_type); +static boolean_t ixgb_setup_fc(struct ixgb_hw *hw); +static boolean_t mac_addr_valid(uint8_t *mac_addr); -uint32_t ixgb_mac_reset(struct ixgb_hw *hw) +static uint32_t ixgb_mac_reset(struct ixgb_hw *hw) { uint32_t ctrl_reg; @@ -335,7 +343,7 @@ * of the receive addresss registers. Clears the multicast table. Assumes * the receiver is in reset when the routine is called. *****************************************************************************/ -void +static void ixgb_init_rx_addrs(struct ixgb_hw *hw) { uint32_t i; @@ -604,7 +612,7 @@ * * hw - Struct containing variables accessed by shared code *****************************************************************************/ -void +static void ixgb_clear_vfta(struct ixgb_hw *hw) { uint32_t offset; @@ -620,7 +628,7 @@ * hw - Struct containing variables accessed by shared code *****************************************************************************/ -boolean_t +static boolean_t ixgb_setup_fc(struct ixgb_hw *hw) { uint32_t ctrl_reg; @@ -722,7 +730,7 @@ * This requires that first an address cycle command is sent, followed by a * read command. *****************************************************************************/ -uint16_t +static uint16_t ixgb_read_phy_reg(struct ixgb_hw *hw, uint32_t reg_address, uint32_t phy_address, @@ -815,7 +823,7 @@ * This requires that first an address cycle command is sent, followed by a * write command. *****************************************************************************/ -void +static void ixgb_write_phy_reg(struct ixgb_hw *hw, uint32_t reg_address, uint32_t phy_address, @@ -959,7 +967,7 @@ * * hw - Struct containing variables accessed by shared code *****************************************************************************/ -void +static void ixgb_clear_hw_cntrs(struct ixgb_hw *hw) { volatile uint32_t temp_reg; @@ -1114,7 +1122,7 @@ * mac_addr - pointer to MAC address. * *****************************************************************************/ -boolean_t +static boolean_t mac_addr_valid(uint8_t *mac_addr) { boolean_t is_valid = TRUE; --- linux-2.6.12-rc3-mm3-full/drivers/net/ixgb/ixgb_main.c.old 2005-05-06 22:08:38.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/drivers/net/ixgb/ixgb_main.c 2005-05-06 22:09:29.000000000 +0200 @@ -40,7 +40,7 @@ */ char ixgb_driver_name[] = "ixgb"; -char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver"; +static char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver"; #ifndef CONFIG_IXGB_NAPI #define DRIVERNAPI @@ -49,7 +49,7 @@ #endif #define DRV_VERSION "1.0.90-k2"DRIVERNAPI char ixgb_driver_version[] = DRV_VERSION; -char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation."; +static char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation."; /* ixgb_pci_tbl - PCI Device ID Table * @@ -130,7 +130,7 @@ static void ixgb_netpoll(struct net_device *dev); #endif -struct notifier_block ixgb_notifier_reboot = { +static struct notifier_block ixgb_notifier_reboot = { .notifier_call = ixgb_notify_reboot, .next = NULL, .priority = 0 From bunk@stusta.de Fri May 6 14:19:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:19:40 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46LJXOv012301 for ; Fri, 6 May 2005 14:19:34 -0700 Received: (qmail 10477 invoked from network); 6 May 2005 21:19:15 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 6 May 2005 21:19:15 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 7254EBB4E8; Fri, 6 May 2005 23:19:06 +0200 (CEST) Date: Fri, 6 May 2005 23:19:05 +0200 From: Adrian Bunk To: cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] drivers/net/e1000/: possible cleanups Message-ID: <20050506211905.GN3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 879 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 12590 Lines: 326 This patch contains the following possible cleanups: - make needlessly global code static - #if 0 the following unused functions: - e1000_hw.c: e1000_mc_addr_list_update - e1000_hw.c: e1000_read_reg_io - e1000_main.c: e1000_io_read Signed-off-by: Adrian Bunk --- A similar patch was already sent on: - 17 Feb 2005 drivers/net/e1000/e1000_ethtool.c | 2 - drivers/net/e1000/e1000_hw.c | 51 +++++++++++++++++++++--------- drivers/net/e1000/e1000_hw.h | 21 ------------ drivers/net/e1000/e1000_main.c | 8 ++-- 4 files changed, 43 insertions(+), 39 deletions(-) --- linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_ethtool.c.old 2005-02-16 15:26:52.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_ethtool.c 2005-02-16 15:27:03.000000000 +0100 @@ -1629,7 +1629,7 @@ } } -struct ethtool_ops e1000_ethtool_ops = { +static struct ethtool_ops e1000_ethtool_ops = { .get_settings = e1000_get_settings, .set_settings = e1000_set_settings, .get_drvinfo = e1000_get_drvinfo, --- linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_hw.h.old 2005-02-16 15:27:21.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_hw.h 2005-02-16 15:38:29.000000000 +0100 @@ -266,10 +266,8 @@ int32_t e1000_setup_link(struct e1000_hw *hw); int32_t e1000_phy_setup_autoneg(struct e1000_hw *hw); void e1000_config_collision_dist(struct e1000_hw *hw); -int32_t e1000_config_fc_after_link_up(struct e1000_hw *hw); int32_t e1000_check_for_link(struct e1000_hw *hw); int32_t e1000_get_speed_and_duplex(struct e1000_hw *hw, uint16_t * speed, uint16_t * duplex); -int32_t e1000_wait_autoneg(struct e1000_hw *hw); int32_t e1000_force_mac_fc(struct e1000_hw *hw); /* PHY */ @@ -277,13 +275,7 @@ int32_t e1000_write_phy_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t data); void e1000_phy_hw_reset(struct e1000_hw *hw); int32_t e1000_phy_reset(struct e1000_hw *hw); -int32_t e1000_detect_gig_phy(struct e1000_hw *hw); int32_t e1000_phy_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info); -int32_t e1000_phy_m88_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info); -int32_t e1000_phy_igp_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info); -int32_t e1000_get_cable_length(struct e1000_hw *hw, uint16_t *min_length, uint16_t *max_length); -int32_t e1000_check_polarity(struct e1000_hw *hw, uint16_t *polarity); -int32_t e1000_check_downshift(struct e1000_hw *hw); int32_t e1000_validate_mdi_setting(struct e1000_hw *hw); /* EEPROM Functions */ @@ -296,13 +288,10 @@ int32_t e1000_read_mac_addr(struct e1000_hw * hw); /* Filters (multicast, vlan, receive) */ -void e1000_init_rx_addrs(struct e1000_hw *hw); -void e1000_mc_addr_list_update(struct e1000_hw *hw, uint8_t * mc_addr_list, uint32_t mc_addr_count, uint32_t pad, uint32_t rar_used_count); uint32_t e1000_hash_mc_addr(struct e1000_hw *hw, uint8_t * mc_addr); void e1000_mta_set(struct e1000_hw *hw, uint32_t hash_value); void e1000_rar_set(struct e1000_hw *hw, uint8_t * mc_addr, uint32_t rar_index); void e1000_write_vfta(struct e1000_hw *hw, uint32_t offset, uint32_t value); -void e1000_clear_vfta(struct e1000_hw *hw); /* LED functions */ int32_t e1000_setup_led(struct e1000_hw *hw); @@ -314,7 +303,6 @@ /* Everything else */ uint32_t e1000_enable_mng_pass_thru(struct e1000_hw *hw); -void e1000_clear_hw_cntrs(struct e1000_hw *hw); void e1000_reset_adaptive(struct e1000_hw *hw); void e1000_update_adaptive(struct e1000_hw *hw); void e1000_tbi_adjust_stats(struct e1000_hw *hw, struct e1000_hw_stats *stats, uint32_t frame_len, uint8_t * mac_addr); @@ -325,16 +313,7 @@ void e1000_write_pci_cfg(struct e1000_hw *hw, uint32_t reg, uint16_t * value); /* Port I/O is only supported on 82544 and newer */ uint32_t e1000_io_read(struct e1000_hw *hw, unsigned long port); -uint32_t e1000_read_reg_io(struct e1000_hw *hw, uint32_t offset); void e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value); -void e1000_write_reg_io(struct e1000_hw *hw, uint32_t offset, uint32_t value); -int32_t e1000_config_dsp_after_link_change(struct e1000_hw *hw, boolean_t link_up); -int32_t e1000_set_d3_lplu_state(struct e1000_hw *hw, boolean_t active); - -#define E1000_READ_REG_IO(a, reg) \ - e1000_read_reg_io((a), E1000_##reg) -#define E1000_WRITE_REG_IO(a, reg, val) \ - e1000_write_reg_io((a), E1000_##reg, val) /* PCI Device IDs */ #define E1000_DEV_ID_82542 0x1000 --- linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_hw.c.old 2005-02-16 15:27:38.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_hw.c 2005-02-16 15:38:24.000000000 +0100 @@ -67,6 +67,25 @@ static int32_t e1000_set_vco_speed(struct e1000_hw *hw); static int32_t e1000_polarity_reversal_workaround(struct e1000_hw *hw); static int32_t e1000_set_phy_mode(struct e1000_hw *hw); +static int32_t e1000_check_downshift(struct e1000_hw *hw); +static int32_t e1000_check_polarity(struct e1000_hw *hw, uint16_t *polarity); +static void e1000_clear_hw_cntrs(struct e1000_hw *hw); +static void e1000_clear_vfta(struct e1000_hw *hw); +static int32_t e1000_config_dsp_after_link_change(struct e1000_hw *hw, + boolean_t link_up); +static int32_t e1000_config_fc_after_link_up(struct e1000_hw *hw); +static int32_t e1000_detect_gig_phy(struct e1000_hw *hw); +static int32_t e1000_get_cable_length(struct e1000_hw *hw, + uint16_t *min_length, + uint16_t *max_length); +static void e1000_init_rx_addrs(struct e1000_hw *hw); +static int32_t e1000_set_d3_lplu_state(struct e1000_hw *hw, boolean_t active); +static int32_t e1000_wait_autoneg(struct e1000_hw *hw); +static void e1000_write_reg_io(struct e1000_hw *hw, uint32_t offset, + uint32_t value); + +#define E1000_WRITE_REG_IO(a, reg, val) \ + e1000_write_reg_io((a), E1000_##reg, val) /* IGP cable length table */ static const @@ -1809,7 +1828,7 @@ * based on the flow control negotiated by the PHY. In TBI mode, the TFCE * and RFCE bits will be automaticaly set to the negotiated flow control mode. *****************************************************************************/ -int32_t +static int32_t e1000_config_fc_after_link_up(struct e1000_hw *hw) { int32_t ret_val; @@ -2311,7 +2330,7 @@ * * hw - Struct containing variables accessed by shared code ******************************************************************************/ -int32_t +static int32_t e1000_wait_autoneg(struct e1000_hw *hw) { int32_t ret_val; @@ -2767,7 +2786,7 @@ * * hw - Struct containing variables accessed by shared code ******************************************************************************/ -int32_t +static int32_t e1000_detect_gig_phy(struct e1000_hw *hw) { int32_t phy_init_status, ret_val; @@ -2854,7 +2873,7 @@ * hw - Struct containing variables accessed by shared code * phy_info - PHY information structure ******************************************************************************/ -int32_t +static int32_t e1000_phy_igp_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info) { @@ -2928,7 +2947,7 @@ * hw - Struct containing variables accessed by shared code * phy_info - PHY information structure ******************************************************************************/ -int32_t +static int32_t e1000_phy_m88_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info) { @@ -3907,7 +3926,7 @@ * of the receive addresss registers. Clears the multicast table. Assumes * the receiver is in reset when the routine is called. *****************************************************************************/ -void +static void e1000_init_rx_addrs(struct e1000_hw *hw) { uint32_t i; @@ -3941,6 +3960,7 @@ * for the first 15 multicast addresses, and hashes the rest into the * multicast table. *****************************************************************************/ +#if 0 void e1000_mc_addr_list_update(struct e1000_hw *hw, uint8_t *mc_addr_list, @@ -4000,6 +4020,7 @@ } DEBUGOUT("MC Update Complete\n"); } +#endif /* 0 */ /****************************************************************************** * Hashes an address to determine its location in the multicast table @@ -4140,7 +4161,7 @@ * * hw - Struct containing variables accessed by shared code *****************************************************************************/ -void +static void e1000_clear_vfta(struct e1000_hw *hw) { uint32_t offset; @@ -4411,7 +4432,7 @@ * * hw - Struct containing variables accessed by shared code *****************************************************************************/ -void +static void e1000_clear_hw_cntrs(struct e1000_hw *hw) { volatile uint32_t temp; @@ -4682,6 +4703,7 @@ * hw - Struct containing variables accessed by shared code * offset - offset to read from *****************************************************************************/ +#if 0 uint32_t e1000_read_reg_io(struct e1000_hw *hw, uint32_t offset) @@ -4692,6 +4714,7 @@ e1000_io_write(hw, io_addr, offset); return e1000_io_read(hw, io_data); } +#endif /* 0 */ /****************************************************************************** * Writes a value to one of the devices registers using port I/O (as opposed to @@ -4701,7 +4724,7 @@ * offset - offset to write to * value - value to write *****************************************************************************/ -void +static void e1000_write_reg_io(struct e1000_hw *hw, uint32_t offset, uint32_t value) @@ -4729,7 +4752,7 @@ * register to the minimum and maximum range. * For IGP phy's, the function calculates the range by the AGC registers. *****************************************************************************/ -int32_t +static int32_t e1000_get_cable_length(struct e1000_hw *hw, uint16_t *min_length, uint16_t *max_length) @@ -4843,7 +4866,7 @@ * return 0. If the link speed is 1000 Mbps the polarity status is in the * IGP01E1000_PHY_PCS_INIT_REG. *****************************************************************************/ -int32_t +static int32_t e1000_check_polarity(struct e1000_hw *hw, uint16_t *polarity) { @@ -4904,7 +4927,7 @@ * Link Health register. In IGP this bit is latched high, so the driver must * read it immediately after link is established. *****************************************************************************/ -int32_t +static int32_t e1000_check_downshift(struct e1000_hw *hw) { int32_t ret_val; @@ -4944,7 +4967,7 @@ * ****************************************************************************/ -int32_t +static int32_t e1000_config_dsp_after_link_change(struct e1000_hw *hw, boolean_t link_up) { @@ -5175,7 +5198,7 @@ * ****************************************************************************/ -int32_t +static int32_t e1000_set_d3_lplu_state(struct e1000_hw *hw, boolean_t active) { --- linux-2.6.12-rc3-mm3-full/drivers/net/e1000/e1000_main.c.old 2005-05-06 22:07:10.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/drivers/net/e1000/e1000_main.c 2005-05-06 22:26:36.000000000 +0200 @@ -59,7 +59,7 @@ */ char e1000_driver_name[] = "e1000"; -char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; +static char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; #ifndef CONFIG_E1000_NAPI #define DRIVERNAPI #else @@ -67,7 +67,7 @@ #endif #define DRV_VERSION "5.7.6-k2"DRIVERNAPI char e1000_driver_version[] = DRV_VERSION; -char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; +static char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table * @@ -187,7 +187,7 @@ static void e1000_netpoll (struct net_device *netdev); #endif -struct notifier_block e1000_notifier_reboot = { +static struct notifier_block e1000_notifier_reboot = { .notifier_call = e1000_notify_reboot, .next = NULL, .priority = 0 @@ -2885,11 +2885,13 @@ pci_write_config_word(adapter->pdev, reg, *value); } +#if 0 uint32_t e1000_io_read(struct e1000_hw *hw, unsigned long port) { return inl(port); } +#endif /* 0 */ void e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value) From kaber@trash.net Fri May 6 14:28:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:28:29 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46LSPOv013454 for ; Fri, 6 May 2005 14:28:26 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DUAMC-0001P2-1M; Fri, 06 May 2005 23:27:36 +0200 Message-ID: <427BE147.9080508@trash.net> Date: Fri, 06 May 2005 23:27:35 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "David S. Miller" , Maillist netdev Subject: Re: [NET]: Avoid useless iterating in netlink dump functions References: <427B8FC3.4000305@trash.net> <1115413473.13922.38.camel@localhost.localdomain> <427BDDD4.1000808@trash.net> <1115414222.13922.41.camel@localhost.localdomain> In-Reply-To: <1115414222.13922.41.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 880 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 737 Lines: 21 jamal wrote: > On Fri, 2005-06-05 at 23:12 +0200, Patrick McHardy wrote: > >>action dumping is on my list for more treatment than this :) > > Well, that does sound scary ;-> What do you have in mind. > Recall, there are two paths to dumping actions - unlike any other thing > in the kernel. Don't worry :) Its actually action walking that is on my list. What I have planed is roughly: - clean up and move hashing functions to act_common.c - put data needed for hashing (size, pointer to memory, ...) in struct tc_act_common, which is referenced by struct tc_action_ops - add callback based walking function so we don't need two of them This should also get rid of all the large functions contained in headerfiles. Regards Patrick From bunk@stusta.de Fri May 6 14:33:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:33:08 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46LX4Ov014024 for ; Fri, 6 May 2005 14:33:05 -0700 Received: (qmail 10758 invoked from network); 6 May 2005 21:32:46 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 6 May 2005 21:32:46 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id D37FBBB4E8; Fri, 6 May 2005 23:32:40 +0200 (CEST) Date: Fri, 6 May 2005 23:32:39 +0200 From: Adrian Bunk To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [-mm patch] net/ieee80211/: make two functions static Message-ID: <20050506213238.GS3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 881 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1264 Lines: 37 This patch makes two needlessly global functions static. Signed-off-by: Adrian Bunk --- net/ieee80211/ieee80211_crypt_ccmp.c | 4 ++-- net/ieee80211/ieee80211_tx.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) --- linux-2.6.12-rc3-mm2-full/net/ieee80211/ieee80211_crypt_ccmp.c.old 2005-05-05 02:29:22.000000000 +0200 +++ linux-2.6.12-rc3-mm2-full/net/ieee80211/ieee80211_crypt_ccmp.c 2005-05-05 02:29:35.000000000 +0200 @@ -59,8 +59,8 @@ u8 rx_b0[AES_BLOCK_LEN], rx_b[AES_BLOCK_LEN], rx_a[AES_BLOCK_LEN]; }; -void ieee80211_ccmp_aes_encrypt(struct crypto_tfm *tfm, - const u8 pt[16], u8 ct[16]) +static void ieee80211_ccmp_aes_encrypt(struct crypto_tfm *tfm, + const u8 pt[16], u8 ct[16]) { struct scatterlist src, dst; --- linux-2.6.12-rc3-mm2-full/net/ieee80211/ieee80211_tx.c.old 2005-05-05 02:29:51.000000000 +0200 +++ linux-2.6.12-rc3-mm2-full/net/ieee80211/ieee80211_tx.c 2005-05-05 02:29:59.000000000 +0200 @@ -211,8 +211,8 @@ kfree(txb); } -struct ieee80211_txb *ieee80211_alloc_txb(int nr_frags, int txb_size, - int gfp_mask) +static struct ieee80211_txb *ieee80211_alloc_txb(int nr_frags, int txb_size, + int gfp_mask) { struct ieee80211_txb *txb; int i; From tgraf@suug.ch Fri May 6 14:44:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:44:42 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46LiaOv014703 for ; Fri, 6 May 2005 14:44:36 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id DF0181C0EB; Fri, 6 May 2005 23:44:37 +0200 (CEST) Date: Fri, 6 May 2005 23:44:37 +0200 From: Thomas Graf To: netdev@oss.sgi.com Cc: Pablo Neira Subject: Re: [RFC] textsearch infrastructure + skb_find_text() Message-ID: <20050506214437.GH28419@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504234036.GH18452@postel.suug.ch> X-archive-position: 882 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 10564 Lines: 313 Quite silly regular expression implementation for textsearch infrastructure. Still has issues with textsearch_next() and can probably be optimized a lot but should be a good base to work on. diff -Nru -X dontdiff linux-2.6.12-rc3.orig/include/linux/textsearch_regexp.h linux-2.6.12-rc3/include/linux/textsearch_regexp.h --- linux-2.6.12-rc3.orig/include/linux/textsearch_regexp.h 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.12-rc3/include/linux/textsearch_regexp.h 2005-05-06 19:33:20.000000000 +0200 @@ -0,0 +1,47 @@ +#ifndef __LINUX_TEXTSEARCH_REGEXP_H +#define __LINUX_TEXTSEARCH_REGEXP_H + +#include + +enum { + TS_RE_SPECIFIC, /* specific character */ + TS_RE_WILDCARD, /* any character */ + TS_RE_DIGIT, /* isdigit() */ + TS_RE_XDIGIT, /* isxdigit() */ + TS_RE_PRINT, /* isprint() */ + TS_RE_ALPHA, /* isalpha() */ + TS_RE_ALNUM, /* isalnum() */ + TS_RE_ASCII, /* isascii() */ + TS_RE_CNTRL, /* iscntrl() */ + TS_RE_GRAPH, /* isgraph() */ + TS_RE_LOWER, /* islower() */ + TS_RE_UPPER, /* isupper() */ + TS_RE_PUNCT, /* ispunct() */ + TS_RE_SPACE, /* isspace() */ + __TS_RE_TYPE_MAX, +}; +#define TS_RE_TYPE_MAX (__TS_RE_TYPE_MAX - 1) + +enum { + TS_RE_SINGLE, /* 1 occurrence */ + TS_RE_PERHAPS, /* 1 or 0 occurrence */ + TS_RE_ANY, /* 0..n occurrences */ + TS_RE_MULTI, /* 1..n occurrences */ + __TS_RE_RECUR_MAX, +}; +#define TS_RE_RECUR_MAX (__TS_RE_RECUR_MAX - 1) + +/** + * struct ts_regexp_token - regular expression token + * @type: type of token + * @recur: number of recurrences + * @value: character value for TS_RE_SPECIFIC + */ +struct ts_regexp_token +{ + __u16 type; + __u8 recur; + __u8 value; +}; + +#endif diff -Nru -X dontdiff linux-2.6.12-rc3.orig/lib/ts_regexp.c linux-2.6.12-rc3/lib/ts_regexp.c --- linux-2.6.12-rc3.orig/lib/ts_regexp.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.12-rc3/lib/ts_regexp.c 2005-05-06 23:13:52.000000000 +0200 @@ -0,0 +1,253 @@ +/* + * lib/ts_regexp.c Naive and very limited regular expression + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include +#include +#include + +#define TS_RE_TOKENS(conf) \ + ((struct ts_regexp_token *) ((unsigned char *) (conf) \ + + sizeof(struct ts_config))) + +/* other values derived from ctype.h */ +#define _A 0x100 /* ascii */ +#define _W 0x200 /* wildcard */ + +/* Map to _ctype flags and some magic numbers */ +static u16 token_map[TS_RE_TYPE_MAX+1] = { + [TS_RE_SPECIFIC] = 0, + [TS_RE_WILDCARD] = _W, + [TS_RE_CNTRL] = _C, + [TS_RE_LOWER] = _L, + [TS_RE_UPPER] = _U, + [TS_RE_PUNCT] = _P, + [TS_RE_SPACE] = _S, + [TS_RE_DIGIT] = _D, + [TS_RE_XDIGIT] = _D | _X, + [TS_RE_ALPHA] = _U | _L, + [TS_RE_ALNUM] = _U | _L | _D, + [TS_RE_PRINT] = _P | _U | _L | _D | _SP, + [TS_RE_GRAPH] = _P | _U | _L | _D, + [TS_RE_ASCII] = _A, +}; + +static u16 token_lookup_tbl[256] = { +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 0- 3 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 4- 7 */ +_W|_A|_C, _W|_A|_C|_S, _W|_A|_C|_S, _W|_A|_C|_S, /* 8- 11 */ +_W|_A|_C|_S, _W|_A|_C|_S, _W|_A|_C, _W|_A|_C, /* 12- 15 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 16- 19 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 20- 23 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 24- 27 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 28- 31 */ +_W|_A|_S|_SP, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 32- 35 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 36- 39 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 40- 43 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 44- 47 */ +_W|_A|_D, _W|_A|_D, _W|_A|_D, _W|_A|_D, /* 48- 51 */ +_W|_A|_D, _W|_A|_D, _W|_A|_D, _W|_A|_D, /* 52- 55 */ +_W|_A|_D, _W|_A|_D, _W|_A|_P, _W|_A|_P, /* 56- 59 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 60- 63 */ +_W|_A|_P, _W|_A|_U|_X, _W|_A|_U|_X, _W|_A|_U|_X, /* 64- 67 */ +_W|_A|_U|_X, _W|_A|_U|_X, _W|_A|_U|_X, _W|_A|_U, /* 68- 71 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_U, /* 72- 75 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_U, /* 76- 79 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_U, /* 80- 83 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_U, /* 84- 87 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_P, /* 88- 91 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 92- 95 */ +_W|_A|_P, _W|_A|_L|_X, _W|_A|_L|_X, _W|_A|_L|_X, /* 96- 99 */ +_W|_A|_L|_X, _W|_A|_L|_X, _W|_A|_L|_X, _W|_A|_L, /* 100-103 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_L, /* 104-107 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_L, /* 108-111 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_L, /* 112-115 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_L, /* 116-119 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_P, /* 120-123 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_C, /* 124-127 */ +_W, _W, _W, _W, /* 128-131 */ +_W, _W, _W, _W, /* 132-135 */ +_W, _W, _W, _W, /* 136-139 */ +_W, _W, _W, _W, /* 140-143 */ +_W, _W, _W, _W, /* 144-147 */ +_W, _W, _W, _W, /* 148-151 */ +_W, _W, _W, _W, /* 152-155 */ +_W, _W, _W, _W, /* 156-159 */ +_W|_S|_SP, _W|_P, _W|_P, _W|_P, /* 160-163 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 164-167 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 168-171 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 172-175 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 176-179 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 180-183 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 184-187 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 188-191 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 192-195 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 196-199 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 200-203 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 204-207 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 208-211 */ +_W|_U, _W|_U, _W|_U, _W|_P, /* 212-215 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 216-219 */ +_W|_U, _W|_U, _W|_U, _W|_L, /* 220-223 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 224-227 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 228-231 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 232-235 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 236-239 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 240-243 */ +_W|_L, _W|_L, _W|_L, _W|_P, /* 244-247 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 248-251 */ +_W|_L, _W|_L, _W|_L, _W|_L}; /* 252-255 */ + +static inline int match_token(struct ts_regexp_token *t, u8 d) +{ + if (t->type) + return (token_lookup_tbl[d] & t->type) != 0; + else + return t->value == d; +} + +static int regexp_find(struct ts_config *conf, struct ts_state *state) +{ + int i, q, consumed = state->offset; + struct ts_regexp_token *t = NULL, *next; + struct ts_regexp_token *tokens = TS_RE_TOKENS(conf); + int ntokens = conf->pattern_len / sizeof(*t); + size_t text_len = 0; + unsigned char *text; + +#define GET_TEXT() \ + ({ i = 0; conf->get_text(consumed, &text, conf, state); }) + +#define end_of_text() (i >= text_len && !GET_TEXT()) +#define more_text() (i < text_len || GET_TEXT()) + +#define NEXT_CHAR() do { i++; consumed++; } while (0) + + for (i = 0, q = 0; q < ntokens; q++) { + t = &tokens[q]; + + if (likely(q < (ntokens - 1))) + next = &tokens[q+1]; + else + next = NULL; + + switch (t->recur) { + case TS_RE_SINGLE: + if (unlikely(end_of_text())) + goto no_match; + + if (!match_token(t, text[i])) + goto no_match; + break; + + case TS_RE_PERHAPS: + if (likely(more_text())) + if (match_token(t, text[i])) + break; + continue; + + case TS_RE_MULTI: + if (unlikely(end_of_text())) + goto no_match; + + if (!match_token(t, text[i])) + goto no_match; + + NEXT_CHAR(); + /* fall through */ + + case TS_RE_ANY: + if (next == NULL) + goto found_match; + + if (likely(more_text())) { + while (!match_token(next, text[i])) { + if (!match_token(t, text[i])) + goto no_match; + NEXT_CHAR(); + if (unlikely(end_of_text())) + goto no_match; + } + } + continue; + } + + NEXT_CHAR(); + } + + if (q >= (ntokens - 1)) + goto found_match; + +no_match: + return -1; + +found_match: + return 0; +} + +static struct ts_config *regexp_init(const unsigned char *pattern, size_t len, + int gfp_mask) +{ + int i, err = -EINVAL; + struct ts_config *conf; + struct ts_regexp_token *tokens = (struct ts_regexp_token *) pattern; + + if (len % sizeof(struct ts_regexp_token)) + goto errout; + + for (i = 0; i < len / sizeof(struct ts_regexp_token); i++) { + struct ts_regexp_token *t = &tokens[i]; + + if (t->type > TS_RE_TYPE_MAX || + t->type > TS_RE_RECUR_MAX) + goto errout; + + t->type = token_map[t->type]; + } + + conf = alloc_ts_config(len, gfp_mask); + if (IS_ERR(conf)) + return conf; + + conf->pattern_len = len; + memcpy(TS_RE_TOKENS(conf), pattern, len); + + return conf; + +errout: + return ERR_PTR(err); +} + +static struct ts_ops regexp_ops = { + .name = "regexp", + .find = regexp_find, + .init = regexp_init, + .owner = THIS_MODULE, + .list = LIST_HEAD_INIT(regexp_ops.list) +}; + +static int __init init_regexp(void) +{ + return textsearch_register(®exp_ops); +} + +static void __exit exit_regexp(void) +{ + textsearch_unregister(®exp_ops); +} + +MODULE_LICENSE("GPL"); + +module_init(init_regexp); +module_exit(exit_regexp); From asimshankar@gmail.com Fri May 6 14:54:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:54:13 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46Ls9Ov015343 for ; Fri, 6 May 2005 14:54:09 -0700 Received: by wproxy.gmail.com with SMTP id 68so263447wri for ; Fri, 06 May 2005 14:53:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fXr4hLjzSxdvB+Ua1qbnUA4nINko7xjmeXKv2doAPYKNHCpWlPuF/618CV0dFIDy0lY9cap7b5yJ0pFMcJz4WrHCwFL/fM7HQTBz7Ikl2jwzMwNKPoKFP4KWcH59+kapvt+6ZZq+kMlN/t4FUdLF1Dsy52ML9+M+8Ah43mex/uU= Received: by 10.54.22.53 with SMTP id 53mr1086867wrv; Fri, 06 May 2005 14:53:51 -0700 (PDT) Received: by 10.54.24.42 with HTTP; Fri, 6 May 2005 14:53:51 -0700 (PDT) Message-ID: <7bca1cb5050506145344d16b1e@mail.gmail.com> Date: Fri, 6 May 2005 16:53:51 -0500 From: Asim Shankar Reply-To: Asim Shankar To: netdev@oss.sgi.com Subject: SFQ: Reordering? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j46Ls9Ov015343 X-archive-position: 883 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 703 Lines: 20 Hi, I was looking through sch_sfq.c. From what I could make out, if the perturbation period is non-zero (say Xseconds), then ever X seconds, sfq_perturbation() is invoked. This changes the perturbation value that will be used by the hash function, however, packets already existing in the queue aren't rehashed. As a result, new packets being enqueued will have a different hash value and thus packet re-ordering will take place. I ran a quick test using netperf and tcpdump and seem to notice this re-ordering. Should complete rehashing take place in sfq_perturbation(), or am I missing something? (I was looking at 2.6.9 and also took a cursory glance at 2.6.11 on lxr.linux.no) Thanks, -- Asim From mjt@tls.msk.ru Fri May 6 14:59:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 14:59:56 -0700 (PDT) Received: from hobbit.corpit.ru (hobbit.corpit.ru [81.13.94.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46LxpOv015928 for ; Fri, 6 May 2005 14:59:52 -0700 Received: from localhost (localhost [127.0.0.1]) by hobbit.corpit.ru (Postfix) with ESMTP id 85222295F5; Sat, 7 May 2005 01:59:28 +0400 (MSD) (envelope-from mjt@tls.msk.ru) Received: from [192.168.1.1] (paltus.tls.msk.ru [192.168.1.1]) by hobbit.corpit.ru (Postfix) with ESMTP; Sat, 7 May 2005 01:59:28 +0400 (MSD) (envelope-from mjt@tls.msk.ru) Message-ID: <427BE8C0.3090108@tls.msk.ru> Date: Sat, 07 May 2005 01:59:28 +0400 From: Michael Tokarev User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: Kernel Mailing List Subject: Re: 3c509 module and 2.6 kernel: not all NICs are recognized? References: <427BD143.4010909@tls.msk.ru> <427BDD22.1080601@tls.msk.ru> <427BE3A0.7010000@didntduck.org> <427BE47B.303@tls.msk.ru> In-Reply-To: <427BE47B.303@tls.msk.ru> X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/mixed; boundary="------------050500020904080408090206" X-archive-position: 884 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mjt@tls.msk.ru Precedence: bulk X-list: netdev Content-Length: 2155 Lines: 80 This is a multi-part message in MIME format. --------------050500020904080408090206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Michael Tokarev wrote: > Brian Gerst wrote: > >>Michael Tokarev wrote: > > [] > >>>>It have 4 3c509 cards, one EISA and 3 ISA. Here's the dmesg > > [] > >>>All the ISA cards are in EISA mode (set in 3c5x9cfg.exe utility). >>>IRQs are assigned by the EISA bus (set by EISA configuration utility). >>>If any of the ISA cards are in non-EISA mode, the some of them >>>does not work at all, starting from EISA BIOS config during boot. >>>So I can't switch the cards into PNP mode. > > [] > >>what does dmesg|grep EISA show? > > > Looks like I already found it by looking at the driver source. > > struct eisa_device_id el3_eisa_ids[] = { > { "TCM5092" }, > { "TCM5093" }, > { "TCM5095" }, <==== I added this line > { "" } > }; > > and now it works. > > EISA: Probing bus 0 at 0000:00:06.0 > EISA: Mainboard ACR1C01 detected. > EISA: slot 2 : TCM5095 detected. > EISA: slot 3 : TCM5095 detected. > EISA: slot 4 : TCM5095 detected. > EISA: slot 5 : TCM5093 detected. > EISA: Detected 4 cards. > > > I'm not sure if it will work with ISA cards in ISA mode. > As I pointed out above, this machine does not want to > initialize EISA bus if at least one of the cards isn't > in EISA mode. Will "plain" (in ISA mode) 3c509 be shown > in EISA scan too? The trivial patch is attached. Please consider applying. /mjt --------------050500020904080408090206 Content-Type: text/plain; name="3c509-ISA-in-EISA-mode.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="3c509-ISA-in-EISA-mode.patch" This trivial patch adds support for ISA 3c509 cards in EISA mode. Signed-Off-By: Michael Tokarev --- a/drivers/net/3c509.c.orig Sat May 7 01:55:35 2005 +++ b/drivers/net/3c509.c Sat May 7 01:27:49 2005 @@ -217,6 +217,7 @@ struct eisa_device_id el3_eisa_ids[] = { { "TCM5092" }, { "TCM5093" }, + { "TCM5095" }, { "" } }; --------------050500020904080408090206-- From kaber@trash.net Fri May 6 15:08:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 15:08:05 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46M81Ov016622 for ; Fri, 6 May 2005 15:08:01 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DUAz1-00065m-8X; Sat, 07 May 2005 00:07:43 +0200 Message-ID: <427BEAAE.409@trash.net> Date: Sat, 07 May 2005 00:07:42 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Asim Shankar CC: netdev@oss.sgi.com Subject: Re: SFQ: Reordering? References: <7bca1cb5050506145344d16b1e@mail.gmail.com> In-Reply-To: <7bca1cb5050506145344d16b1e@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 885 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 800 Lines: 21 Asim Shankar wrote: > Hi, > > I was looking through sch_sfq.c. From what I could make out, if the > perturbation period is non-zero (say Xseconds), then ever X seconds, > sfq_perturbation() is invoked. This changes the perturbation value > that will be used by the hash function, however, packets already > existing in the queue aren't rehashed. > > As a result, new packets being enqueued will have a different hash > value and thus packet re-ordering will take place. I ran a quick test > using netperf and tcpdump and seem to notice this re-ordering. > > Should complete rehashing take place in sfq_perturbation(), or am I > missing something? (I was looking at 2.6.9 and also took a cursory > glance at 2.6.11 on lxr.linux.no) I think we should rehash. Can you send a patch? Regards Patrick From bunk@stusta.de Fri May 6 15:24:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 15:24:35 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46MOUOv017732 for ; Fri, 6 May 2005 15:24:31 -0700 Received: (qmail 12007 invoked from network); 6 May 2005 22:24:12 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 6 May 2005 22:24:12 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id A73FABB4E8; Sat, 7 May 2005 00:24:10 +0200 (CEST) Date: Sat, 7 May 2005 00:24:10 +0200 From: Adrian Bunk To: irda-users@lists.sourceforge.net Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/irda/: passible cleanups Message-ID: <20050506222410.GV3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 886 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 2616 Lines: 82 This patch contains the following possible cleanups: - make the following needlessly global function static: - irnet/irnet_ppp.c: irnet_init - remove the following unneeded EXPORT_SYMBOL's: - irlmp.c: sysctl_discovery_timeout - irlmp.c: irlmp_reasons - irlmp.c: irlmp_dup - irqueue.c: hashbin_find_next Please review which of these changes do make sense and which conflict with pending patches. Signed-off-by: Adrian Bunk --- net/irda/irlmp.c | 3 --- net/irda/irnet/irnet.h | 3 --- net/irda/irnet/irnet_ppp.c | 2 +- net/irda/irqueue.c | 1 - 4 files changed, 1 insertion(+), 8 deletions(-) --- linux-2.6.12-rc3-mm3-full/net/irda/irnet/irnet.h.old 2005-05-05 22:38:59.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/irda/irnet/irnet.h 2005-05-05 22:39:12.000000000 +0200 @@ -517,9 +517,6 @@ irda_irnet_init(void); /* Initialise IrDA part of IrNET */ extern void irda_irnet_cleanup(void); /* Teardown IrDA part of IrNET */ -/* ---------------------------- MODULE ---------------------------- */ -extern int - irnet_init(void); /* Initialise IrNET module */ /**************************** VARIABLES ****************************/ --- linux-2.6.12-rc3-mm3-full/net/irda/irnet/irnet_ppp.c.old 2005-05-05 22:39:21.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/irda/irnet/irnet_ppp.c 2005-05-05 22:39:29.000000000 +0200 @@ -1107,7 +1107,7 @@ /* * Module main entry point */ -int __init +static int __init irnet_init(void) { int err; --- linux-2.6.12-rc3-mm3-full/net/irda/irlmp.c.old 2005-05-05 22:46:47.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/irda/irlmp.c 2005-05-05 22:50:52.000000000 +0200 @@ -53,7 +53,6 @@ /* These can be altered by the sysctl interface */ int sysctl_discovery = 0; int sysctl_discovery_timeout = 3; /* 3 seconds by default */ -EXPORT_SYMBOL(sysctl_discovery_timeout); int sysctl_discovery_slots = 6; /* 6 slots by default */ int sysctl_lap_keepalive_time = LM_IDLE_TIMEOUT * 1000 / HZ; char sysctl_devname[65]; @@ -67,7 +66,6 @@ "LM_INIT_DISCONNECT", "ERROR, NOT USED", }; -EXPORT_SYMBOL(irlmp_reasons); /* * Function irlmp_init (void) @@ -675,7 +673,6 @@ return new; } -EXPORT_SYMBOL(irlmp_dup); /* * Function irlmp_disconnect_request (handle, userdata) --- linux-2.6.12-rc3-mm3-full/net/irda/irqueue.c.old 2005-05-05 22:48:55.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/irda/irqueue.c 2005-05-05 22:49:03.000000000 +0200 @@ -822,7 +822,6 @@ return entry; } -EXPORT_SYMBOL(hashbin_find_next); /* * Function hashbin_get_first (hashbin) From bunk@stusta.de Fri May 6 15:26:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 15:26:13 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46MQ9Ov018120 for ; Fri, 6 May 2005 15:26:10 -0700 Received: (qmail 12053 invoked from network); 6 May 2005 22:25:51 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 6 May 2005 22:25:51 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 06CDDBB4E8; Sat, 7 May 2005 00:25:50 +0200 (CEST) Date: Sat, 7 May 2005 00:25:50 +0200 From: Adrian Bunk To: sri@us.ibm.com Cc: lksctp-developers@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/sctp/: make two functions static Message-ID: <20050506222549.GW3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 887 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 2491 Lines: 66 This patch makes two needlessly global functions static. Signed-off-by: Adrian Bunk --- include/net/sctp/sm.h | 3 --- net/sctp/sm_statefuns.c | 13 +++++++++++-- 2 files changed, 11 insertions(+), 5 deletions(-) --- linux-2.6.12-rc3-mm3-full/include/net/sctp/sm.h.old 2005-05-05 22:59:54.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/include/net/sctp/sm.h 2005-05-06 00:17:40.000000000 +0200 @@ -130,7 +130,6 @@ sctp_state_fn_t sctp_sf_ootb; sctp_state_fn_t sctp_sf_pdiscard; sctp_state_fn_t sctp_sf_violation; -sctp_state_fn_t sctp_sf_violation_chunklen; sctp_state_fn_t sctp_sf_discard_chunk; sctp_state_fn_t sctp_sf_do_5_2_1_siminit; sctp_state_fn_t sctp_sf_do_5_2_2_dupinit; @@ -258,8 +257,6 @@ void sctp_chunk_assign_tsn(struct sctp_chunk *); void sctp_chunk_assign_ssn(struct sctp_chunk *); -void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error); - /* Prototypes for statetable processing. */ int sctp_do_sm(sctp_event_t event_type, sctp_subtype_t subtype, --- linux-2.6.12-rc3-mm3-full/net/sctp/sm_statefuns.c.old 2005-05-05 23:00:12.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/sctp/sm_statefuns.c 2005-05-06 00:19:11.000000000 +0200 @@ -92,6 +92,14 @@ sctp_cmd_seq_t *commands); static struct sctp_sackhdr *sctp_sm_pull_sack(struct sctp_chunk *chunk); +static void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error); + +static sctp_disposition_t sctp_sf_violation_chunklen( + const struct sctp_endpoint *ep, + const struct sctp_association *asoc, + const sctp_subtype_t type, + void *arg, + sctp_cmd_seq_t *commands); /* Small helper function that checks if the chunk length * is of the appropriate length. The 'required_length' argument @@ -2318,7 +2326,7 @@ * * This is common code called by several sctp_sf_*_abort() functions above. */ -void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error) +static void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error) { sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE, SCTP_STATE(SCTP_STATE_CLOSED)); @@ -3672,7 +3680,8 @@ * * Generate an ABORT chunk and terminate the association. */ -sctp_disposition_t sctp_sf_violation_chunklen(const struct sctp_endpoint *ep, +static sctp_disposition_t sctp_sf_violation_chunklen( + const struct sctp_endpoint *ep, const struct sctp_association *asoc, const sctp_subtype_t type, void *arg, From bunk@stusta.de Fri May 6 15:28:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 15:28:02 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46MRxOv018763 for ; Fri, 6 May 2005 15:27:59 -0700 Received: (qmail 12115 invoked from network); 6 May 2005 22:27:41 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 6 May 2005 22:27:41 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id C60F8BB4E8; Sat, 7 May 2005 00:27:39 +0200 (CEST) Date: Sat, 7 May 2005 00:27:39 +0200 From: Adrian Bunk To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [2.6 patch] net/socket.c: unexport move_addr_to_kernel Message-ID: <20050506222739.GX3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 888 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 532 Lines: 17 I didn't find any modular usage in the kernel. Signed-off-by: Adrian Bunk --- linux-2.6.12-rc3-mm2-full/net/socket.c.old 2005-05-03 11:03:23.000000000 +0200 +++ linux-2.6.12-rc3-mm2-full/net/socket.c 2005-05-03 11:03:53.000000000 +0200 @@ -2070,8 +2070,7 @@ } #endif /* CONFIG_PROC_FS */ -/* ABI emulation layers need these two */ -EXPORT_SYMBOL(move_addr_to_kernel); +/* ABI emulation layers need this one */ EXPORT_SYMBOL(move_addr_to_user); EXPORT_SYMBOL(sock_create); EXPORT_SYMBOL(sock_create_kern); From ganesh.venkatesan@gmail.com Fri May 6 15:35:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 15:35:13 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46MZ9Ov019373 for ; Fri, 6 May 2005 15:35:09 -0700 Received: by zproxy.gmail.com with SMTP id 8so938591nzo for ; Fri, 06 May 2005 15:34:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PaR6eJuJVmz6XNvuhx9J9Cg6TLqnVFYMzOZ9ea20+rMzN+sTf189a5f/f/YcEUajPbRr1C8KbBefgdkpdZmM10X8NnBSuXp56OXiq5TE9cRCurpysCJfAtvQ2+ic8On+2ThwPBPrwVACiKm0d+izo2wc4y59h+EPuxrXmHKrQUg= Received: by 10.36.23.5 with SMTP id 5mr852204nzw; Fri, 06 May 2005 15:34:51 -0700 (PDT) Received: by 10.36.65.5 with HTTP; Fri, 6 May 2005 15:34:51 -0700 (PDT) Message-ID: <5fc59ff305050615342ec77e31@mail.gmail.com> Date: Fri, 6 May 2005 15:34:51 -0700 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: Adrian Bunk Subject: Re: [2.6 patch] drivers/net/e1000/: possible cleanups Cc: cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20050506211905.GN3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050506211905.GN3590@stusta.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j46MZ9Ov019373 X-archive-position: 889 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 13780 Lines: 340 Adrian: Some of your suggestions are already part of the driver we are currently testing. This was based partly on your Feb '05 patch. We will not be able to apply your patch as is since some of the changes are in part of code that is shared with other drivers that are not GPLd. ganesh. On 5/6/05, Adrian Bunk wrote: > This patch contains the following possible cleanups: > - make needlessly global code static > - #if 0 the following unused functions: > - e1000_hw.c: e1000_mc_addr_list_update > - e1000_hw.c: e1000_read_reg_io > - e1000_main.c: e1000_io_read > > Signed-off-by: Adrian Bunk > > --- > > A similar patch was already sent on: > - 17 Feb 2005 > > drivers/net/e1000/e1000_ethtool.c | 2 - > drivers/net/e1000/e1000_hw.c | 51 +++++++++++++++++++++--------- > drivers/net/e1000/e1000_hw.h | 21 ------------ > drivers/net/e1000/e1000_main.c | 8 ++-- > 4 files changed, 43 insertions(+), 39 deletions(-) > > --- linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_ethtool.c.old 2005-02-16 15:26:52.000000000 +0100 > +++ linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_ethtool.c 2005-02-16 15:27:03.000000000 +0100 > @@ -1629,7 +1629,7 @@ > } > } > > -struct ethtool_ops e1000_ethtool_ops = { > +static struct ethtool_ops e1000_ethtool_ops = { > .get_settings = e1000_get_settings, > .set_settings = e1000_set_settings, > .get_drvinfo = e1000_get_drvinfo, > --- linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_hw.h.old 2005-02-16 15:27:21.000000000 +0100 > +++ linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_hw.h 2005-02-16 15:38:29.000000000 +0100 > @@ -266,10 +266,8 @@ > int32_t e1000_setup_link(struct e1000_hw *hw); > int32_t e1000_phy_setup_autoneg(struct e1000_hw *hw); > void e1000_config_collision_dist(struct e1000_hw *hw); > -int32_t e1000_config_fc_after_link_up(struct e1000_hw *hw); > int32_t e1000_check_for_link(struct e1000_hw *hw); > int32_t e1000_get_speed_and_duplex(struct e1000_hw *hw, uint16_t * speed, uint16_t * duplex); > -int32_t e1000_wait_autoneg(struct e1000_hw *hw); > int32_t e1000_force_mac_fc(struct e1000_hw *hw); > > /* PHY */ > @@ -277,13 +275,7 @@ > int32_t e1000_write_phy_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t data); > void e1000_phy_hw_reset(struct e1000_hw *hw); > int32_t e1000_phy_reset(struct e1000_hw *hw); > -int32_t e1000_detect_gig_phy(struct e1000_hw *hw); > int32_t e1000_phy_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info); > -int32_t e1000_phy_m88_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info); > -int32_t e1000_phy_igp_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info); > -int32_t e1000_get_cable_length(struct e1000_hw *hw, uint16_t *min_length, uint16_t *max_length); > -int32_t e1000_check_polarity(struct e1000_hw *hw, uint16_t *polarity); > -int32_t e1000_check_downshift(struct e1000_hw *hw); > int32_t e1000_validate_mdi_setting(struct e1000_hw *hw); > > /* EEPROM Functions */ > @@ -296,13 +288,10 @@ > int32_t e1000_read_mac_addr(struct e1000_hw * hw); > > /* Filters (multicast, vlan, receive) */ > -void e1000_init_rx_addrs(struct e1000_hw *hw); > -void e1000_mc_addr_list_update(struct e1000_hw *hw, uint8_t * mc_addr_list, uint32_t mc_addr_count, uint32_t pad, uint32_t rar_used_count); > uint32_t e1000_hash_mc_addr(struct e1000_hw *hw, uint8_t * mc_addr); > void e1000_mta_set(struct e1000_hw *hw, uint32_t hash_value); > void e1000_rar_set(struct e1000_hw *hw, uint8_t * mc_addr, uint32_t rar_index); > void e1000_write_vfta(struct e1000_hw *hw, uint32_t offset, uint32_t value); > -void e1000_clear_vfta(struct e1000_hw *hw); > > /* LED functions */ > int32_t e1000_setup_led(struct e1000_hw *hw); > @@ -314,7 +303,6 @@ > > /* Everything else */ > uint32_t e1000_enable_mng_pass_thru(struct e1000_hw *hw); > -void e1000_clear_hw_cntrs(struct e1000_hw *hw); > void e1000_reset_adaptive(struct e1000_hw *hw); > void e1000_update_adaptive(struct e1000_hw *hw); > void e1000_tbi_adjust_stats(struct e1000_hw *hw, struct e1000_hw_stats *stats, uint32_t frame_len, uint8_t * mac_addr); > @@ -325,16 +313,7 @@ > void e1000_write_pci_cfg(struct e1000_hw *hw, uint32_t reg, uint16_t * value); > /* Port I/O is only supported on 82544 and newer */ > uint32_t e1000_io_read(struct e1000_hw *hw, unsigned long port); > -uint32_t e1000_read_reg_io(struct e1000_hw *hw, uint32_t offset); > void e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value); > -void e1000_write_reg_io(struct e1000_hw *hw, uint32_t offset, uint32_t value); > -int32_t e1000_config_dsp_after_link_change(struct e1000_hw *hw, boolean_t link_up); > -int32_t e1000_set_d3_lplu_state(struct e1000_hw *hw, boolean_t active); > - > -#define E1000_READ_REG_IO(a, reg) \ > - e1000_read_reg_io((a), E1000_##reg) > -#define E1000_WRITE_REG_IO(a, reg, val) \ > - e1000_write_reg_io((a), E1000_##reg, val) > > /* PCI Device IDs */ > #define E1000_DEV_ID_82542 0x1000 > --- linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_hw.c.old 2005-02-16 15:27:38.000000000 +0100 > +++ linux-2.6.11-rc3-mm2-full/drivers/net/e1000/e1000_hw.c 2005-02-16 15:38:24.000000000 +0100 > @@ -67,6 +67,25 @@ > static int32_t e1000_set_vco_speed(struct e1000_hw *hw); > static int32_t e1000_polarity_reversal_workaround(struct e1000_hw *hw); > static int32_t e1000_set_phy_mode(struct e1000_hw *hw); > +static int32_t e1000_check_downshift(struct e1000_hw *hw); > +static int32_t e1000_check_polarity(struct e1000_hw *hw, uint16_t *polarity); > +static void e1000_clear_hw_cntrs(struct e1000_hw *hw); > +static void e1000_clear_vfta(struct e1000_hw *hw); > +static int32_t e1000_config_dsp_after_link_change(struct e1000_hw *hw, > + boolean_t link_up); > +static int32_t e1000_config_fc_after_link_up(struct e1000_hw *hw); > +static int32_t e1000_detect_gig_phy(struct e1000_hw *hw); > +static int32_t e1000_get_cable_length(struct e1000_hw *hw, > + uint16_t *min_length, > + uint16_t *max_length); > +static void e1000_init_rx_addrs(struct e1000_hw *hw); > +static int32_t e1000_set_d3_lplu_state(struct e1000_hw *hw, boolean_t active); > +static int32_t e1000_wait_autoneg(struct e1000_hw *hw); > +static void e1000_write_reg_io(struct e1000_hw *hw, uint32_t offset, > + uint32_t value); > + > +#define E1000_WRITE_REG_IO(a, reg, val) \ > + e1000_write_reg_io((a), E1000_##reg, val) > > /* IGP cable length table */ > static const > @@ -1809,7 +1828,7 @@ > * based on the flow control negotiated by the PHY. In TBI mode, the TFCE > * and RFCE bits will be automaticaly set to the negotiated flow control mode. > *****************************************************************************/ > -int32_t > +static int32_t > e1000_config_fc_after_link_up(struct e1000_hw *hw) > { > int32_t ret_val; > @@ -2311,7 +2330,7 @@ > * > * hw - Struct containing variables accessed by shared code > ******************************************************************************/ > -int32_t > +static int32_t > e1000_wait_autoneg(struct e1000_hw *hw) > { > int32_t ret_val; > @@ -2767,7 +2786,7 @@ > * > * hw - Struct containing variables accessed by shared code > ******************************************************************************/ > -int32_t > +static int32_t > e1000_detect_gig_phy(struct e1000_hw *hw) > { > int32_t phy_init_status, ret_val; > @@ -2854,7 +2873,7 @@ > * hw - Struct containing variables accessed by shared code > * phy_info - PHY information structure > ******************************************************************************/ > -int32_t > +static int32_t > e1000_phy_igp_get_info(struct e1000_hw *hw, > struct e1000_phy_info *phy_info) > { > @@ -2928,7 +2947,7 @@ > * hw - Struct containing variables accessed by shared code > * phy_info - PHY information structure > ******************************************************************************/ > -int32_t > +static int32_t > e1000_phy_m88_get_info(struct e1000_hw *hw, > struct e1000_phy_info *phy_info) > { > @@ -3907,7 +3926,7 @@ > * of the receive addresss registers. Clears the multicast table. Assumes > * the receiver is in reset when the routine is called. > *****************************************************************************/ > -void > +static void > e1000_init_rx_addrs(struct e1000_hw *hw) > { > uint32_t i; > @@ -3941,6 +3960,7 @@ > * for the first 15 multicast addresses, and hashes the rest into the > * multicast table. > *****************************************************************************/ > +#if 0 > void > e1000_mc_addr_list_update(struct e1000_hw *hw, > uint8_t *mc_addr_list, > @@ -4000,6 +4020,7 @@ > } > DEBUGOUT("MC Update Complete\n"); > } > +#endif /* 0 */ > > /****************************************************************************** > * Hashes an address to determine its location in the multicast table > @@ -4140,7 +4161,7 @@ > * > * hw - Struct containing variables accessed by shared code > *****************************************************************************/ > -void > +static void > e1000_clear_vfta(struct e1000_hw *hw) > { > uint32_t offset; > @@ -4411,7 +4432,7 @@ > * > * hw - Struct containing variables accessed by shared code > *****************************************************************************/ > -void > +static void > e1000_clear_hw_cntrs(struct e1000_hw *hw) > { > volatile uint32_t temp; > @@ -4682,6 +4703,7 @@ > * hw - Struct containing variables accessed by shared code > * offset - offset to read from > *****************************************************************************/ > +#if 0 > uint32_t > e1000_read_reg_io(struct e1000_hw *hw, > uint32_t offset) > @@ -4692,6 +4714,7 @@ > e1000_io_write(hw, io_addr, offset); > return e1000_io_read(hw, io_data); > } > +#endif /* 0 */ > > /****************************************************************************** > * Writes a value to one of the devices registers using port I/O (as opposed to > @@ -4701,7 +4724,7 @@ > * offset - offset to write to > * value - value to write > *****************************************************************************/ > -void > +static void > e1000_write_reg_io(struct e1000_hw *hw, > uint32_t offset, > uint32_t value) > @@ -4729,7 +4752,7 @@ > * register to the minimum and maximum range. > * For IGP phy's, the function calculates the range by the AGC registers. > *****************************************************************************/ > -int32_t > +static int32_t > e1000_get_cable_length(struct e1000_hw *hw, > uint16_t *min_length, > uint16_t *max_length) > @@ -4843,7 +4866,7 @@ > * return 0. If the link speed is 1000 Mbps the polarity status is in the > * IGP01E1000_PHY_PCS_INIT_REG. > *****************************************************************************/ > -int32_t > +static int32_t > e1000_check_polarity(struct e1000_hw *hw, > uint16_t *polarity) > { > @@ -4904,7 +4927,7 @@ > * Link Health register. In IGP this bit is latched high, so the driver must > * read it immediately after link is established. > *****************************************************************************/ > -int32_t > +static int32_t > e1000_check_downshift(struct e1000_hw *hw) > { > int32_t ret_val; > @@ -4944,7 +4967,7 @@ > * > ****************************************************************************/ > > -int32_t > +static int32_t > e1000_config_dsp_after_link_change(struct e1000_hw *hw, > boolean_t link_up) > { > @@ -5175,7 +5198,7 @@ > * > ****************************************************************************/ > > -int32_t > +static int32_t > e1000_set_d3_lplu_state(struct e1000_hw *hw, > boolean_t active) > { > --- linux-2.6.12-rc3-mm3-full/drivers/net/e1000/e1000_main.c.old 2005-05-06 22:07:10.000000000 +0200 > +++ linux-2.6.12-rc3-mm3-full/drivers/net/e1000/e1000_main.c 2005-05-06 22:26:36.000000000 +0200 > @@ -59,7 +59,7 @@ > */ > > char e1000_driver_name[] = "e1000"; > -char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; > +static char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; > #ifndef CONFIG_E1000_NAPI > #define DRIVERNAPI > #else > @@ -67,7 +67,7 @@ > #endif > #define DRV_VERSION "5.7.6-k2"DRIVERNAPI > char e1000_driver_version[] = DRV_VERSION; > -char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; > +static char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; > > /* e1000_pci_tbl - PCI Device ID Table > * > @@ -187,7 +187,7 @@ > static void e1000_netpoll (struct net_device *netdev); > #endif > > -struct notifier_block e1000_notifier_reboot = { > +static struct notifier_block e1000_notifier_reboot = { > .notifier_call = e1000_notify_reboot, > .next = NULL, > .priority = 0 > @@ -2885,11 +2885,13 @@ > pci_write_config_word(adapter->pdev, reg, *value); > } > > +#if 0 > uint32_t > e1000_io_read(struct e1000_hw *hw, unsigned long port) > { > return inl(port); > } > +#endif /* 0 */ > > void > e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value) > > From ganesh.venkatesan@gmail.com Fri May 6 15:36:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 15:36:14 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46MaAOv019551 for ; Fri, 6 May 2005 15:36:10 -0700 Received: by zproxy.gmail.com with SMTP id 8so938814nzo for ; Fri, 06 May 2005 15:35:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Tdt62absa/8RGnD9YtN19n/wyaoNy4ytQKVHes7ZbOX3vmWfOie3NTCRtHxZNEoCucm400chjHAfYklAGDh1xdQrkp5AtUxNQgg5fSr8P3xUVEGB+lApD3Z1rod5Ju3D7HHYC4QlwxfILd9Bw9t5g6j9+V75/EMG92OddFr69PY= Received: by 10.36.9.18 with SMTP id 18mr866353nzi; Fri, 06 May 2005 15:35:52 -0700 (PDT) Received: by 10.36.65.5 with HTTP; Fri, 6 May 2005 15:35:52 -0700 (PDT) Message-ID: <5fc59ff3050506153523cd12dd@mail.gmail.com> Date: Fri, 6 May 2005 15:35:52 -0700 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: Adrian Bunk Subject: Re: [2.6 patch] drivers/net/ixgb/: possible cleanups Cc: ayyappan.veeraiyan@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20050506211834.GM3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050506211834.GM3590@stusta.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j46MaAOv019551 X-archive-position: 890 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 15158 Lines: 404 Adrian: Some of your suggestions are already part of the driver we are currently testing. This was based partly on your Feb '05 patch. We will not be able to apply your patch as is since some of the changes are in part of code that is shared with other drivers that are not GPLd. ganesh. On 5/6/05, Adrian Bunk wrote: > This patch contains the following possible cleanups: > - make needlessly global code static > - remove the following unused global functions: > - ixgb_ee.c: ixgb_get_ee_compatibility > - ixgb_ee.c: ixgb_get_ee_init_ctrl_reg_1 > - ixgb_ee.c: ixgb_get_ee_init_ctrl_reg_2 > - ixgb_ee.c: ixgb_get_ee_subsystem_id > - ixgb_ee.c: ixgb_get_ee_subvendor_id > - ixgb_ee.c: ixgb_get_ee_vendor_id > - ixgb_ee.c: ixgb_get_ee_swdpins_reg > - ixgb_ee.c: ixgb_get_ee_d3_power > - ixgb_ee.c: ixgb_get_ee_d0_power > > Signed-off-by: Adrian Bunk > > --- > > A similar patch was already sent on: > - 17 Feb 2005 > > drivers/net/ixgb/ixgb_ee.c | 170 -------------------------------- > drivers/net/ixgb/ixgb_ethtool.c | 2 > drivers/net/ixgb/ixgb_hw.c | 26 +++- > drivers/net/ixgb/ixgb_hw.h | 26 ---- > drivers/net/ixgb/ixgb_main.c | 6 - > 5 files changed, 21 insertions(+), 209 deletions(-) > > --- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.h.old 2005-02-16 15:55:21.000000000 +0100 > +++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.h 2005-02-16 16:06:28.000000000 +0100 > @@ -784,23 +784,8 @@ > extern boolean_t ixgb_adapter_stop(struct ixgb_hw *hw); > extern boolean_t ixgb_init_hw(struct ixgb_hw *hw); > extern boolean_t ixgb_adapter_start(struct ixgb_hw *hw); > -extern void ixgb_init_rx_addrs(struct ixgb_hw *hw); > extern void ixgb_check_for_link(struct ixgb_hw *hw); > extern boolean_t ixgb_check_for_bad_link(struct ixgb_hw *hw); > -extern boolean_t ixgb_setup_fc(struct ixgb_hw *hw); > -extern void ixgb_clear_hw_cntrs(struct ixgb_hw *hw); > -extern boolean_t mac_addr_valid(uint8_t *mac_addr); > - > -extern uint16_t ixgb_read_phy_reg(struct ixgb_hw *hw, > - uint32_t reg_addr, > - uint32_t phy_addr, > - uint32_t device_type); > - > -extern void ixgb_write_phy_reg(struct ixgb_hw *hw, > - uint32_t reg_addr, > - uint32_t phy_addr, > - uint32_t device_type, > - uint16_t data); > > extern void ixgb_rar_set(struct ixgb_hw *hw, > uint8_t *addr, > @@ -818,21 +803,10 @@ > uint32_t offset, > uint32_t value); > > -extern void ixgb_clear_vfta(struct ixgb_hw *hw); > - > /* Access functions to eeprom data */ > void ixgb_get_ee_mac_addr(struct ixgb_hw *hw, uint8_t *mac_addr); > -uint16_t ixgb_get_ee_compatibility(struct ixgb_hw *hw); > uint32_t ixgb_get_ee_pba_number(struct ixgb_hw *hw); > -uint16_t ixgb_get_ee_init_ctrl_reg_1(struct ixgb_hw *hw); > -uint16_t ixgb_get_ee_init_ctrl_reg_2(struct ixgb_hw *hw); > -uint16_t ixgb_get_ee_subsystem_id(struct ixgb_hw *hw); > -uint16_t ixgb_get_ee_subvendor_id(struct ixgb_hw *hw); > uint16_t ixgb_get_ee_device_id(struct ixgb_hw *hw); > -uint16_t ixgb_get_ee_vendor_id(struct ixgb_hw *hw); > -uint16_t ixgb_get_ee_swdpins_reg(struct ixgb_hw *hw); > -uint8_t ixgb_get_ee_d3_power(struct ixgb_hw *hw); > -uint8_t ixgb_get_ee_d0_power(struct ixgb_hw *hw); > boolean_t ixgb_get_eeprom_data(struct ixgb_hw *hw); > uint16_t ixgb_get_eeprom_word(struct ixgb_hw *hw, uint16_t index); > > --- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ee.c.old 2005-02-16 15:55:34.000000000 +0100 > +++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ee.c 2005-02-16 15:58:37.000000000 +0100 > @@ -560,25 +560,6 @@ > } > > /****************************************************************************** > - * return the compatibility flags from EEPROM > - * > - * hw - Struct containing variables accessed by shared code > - * > - * Returns: > - * compatibility flags if EEPROM contents are valid, 0 otherwise > - ******************************************************************************/ > -uint16_t > -ixgb_get_ee_compatibility(struct ixgb_hw *hw) > -{ > - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; > - > - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) > - return(ee_map->compatibility); > - > - return(0); > -} > - > -/****************************************************************************** > * return the Printed Board Assembly number from EEPROM > * > * hw - Struct containing variables accessed by shared code > @@ -597,82 +578,6 @@ > } > > /****************************************************************************** > - * return the Initialization Control Word 1 from EEPROM > - * > - * hw - Struct containing variables accessed by shared code > - * > - * Returns: > - * Initialization Control Word 1 if EEPROM contents are valid, 0 otherwise > - ******************************************************************************/ > -uint16_t > -ixgb_get_ee_init_ctrl_reg_1(struct ixgb_hw *hw) > -{ > - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; > - > - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) > - return(ee_map->init_ctrl_reg_1); > - > - return(0); > -} > - > -/****************************************************************************** > - * return the Initialization Control Word 2 from EEPROM > - * > - * hw - Struct containing variables accessed by shared code > - * > - * Returns: > - * Initialization Control Word 2 if EEPROM contents are valid, 0 otherwise > - ******************************************************************************/ > -uint16_t > -ixgb_get_ee_init_ctrl_reg_2(struct ixgb_hw *hw) > -{ > - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; > - > - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) > - return(ee_map->init_ctrl_reg_2); > - > - return(0); > -} > - > -/****************************************************************************** > - * return the Subsystem Id from EEPROM > - * > - * hw - Struct containing variables accessed by shared code > - * > - * Returns: > - * Subsystem Id if EEPROM contents are valid, 0 otherwise > - ******************************************************************************/ > -uint16_t > -ixgb_get_ee_subsystem_id(struct ixgb_hw *hw) > -{ > - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; > - > - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) > - return(ee_map->subsystem_id); > - > - return(0); > -} > - > -/****************************************************************************** > - * return the Sub Vendor Id from EEPROM > - * > - * hw - Struct containing variables accessed by shared code > - * > - * Returns: > - * Sub Vendor Id if EEPROM contents are valid, 0 otherwise > - ******************************************************************************/ > -uint16_t > -ixgb_get_ee_subvendor_id(struct ixgb_hw *hw) > -{ > - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; > - > - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) > - return(ee_map->subvendor_id); > - > - return(0); > -} > - > -/****************************************************************************** > * return the Device Id from EEPROM > * > * hw - Struct containing variables accessed by shared code > @@ -691,78 +596,3 @@ > return(0); > } > > -/****************************************************************************** > - * return the Vendor Id from EEPROM > - * > - * hw - Struct containing variables accessed by shared code > - * > - * Returns: > - * Device Id if EEPROM contents are valid, 0 otherwise > - ******************************************************************************/ > -uint16_t > -ixgb_get_ee_vendor_id(struct ixgb_hw *hw) > -{ > - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; > - > - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) > - return(ee_map->vendor_id); > - > - return(0); > -} > - > -/****************************************************************************** > - * return the Software Defined Pins Register from EEPROM > - * > - * hw - Struct containing variables accessed by shared code > - * > - * Returns: > - * SDP Register if EEPROM contents are valid, 0 otherwise > - ******************************************************************************/ > -uint16_t > -ixgb_get_ee_swdpins_reg(struct ixgb_hw *hw) > -{ > - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; > - > - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) > - return(ee_map->swdpins_reg); > - > - return(0); > -} > - > -/****************************************************************************** > - * return the D3 Power Management Bits from EEPROM > - * > - * hw - Struct containing variables accessed by shared code > - * > - * Returns: > - * D3 Power Management Bits if EEPROM contents are valid, 0 otherwise > - ******************************************************************************/ > -uint8_t > -ixgb_get_ee_d3_power(struct ixgb_hw *hw) > -{ > - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; > - > - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) > - return(ee_map->d3_power); > - > - return(0); > -} > - > -/****************************************************************************** > - * return the D0 Power Management Bits from EEPROM > - * > - * hw - Struct containing variables accessed by shared code > - * > - * Returns: > - * D0 Power Management Bits if EEPROM contents are valid, 0 otherwise > - ******************************************************************************/ > -uint8_t > -ixgb_get_ee_d0_power(struct ixgb_hw *hw) > -{ > - struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; > - > - if(ixgb_check_and_get_eeprom_data(hw) == TRUE) > - return(ee_map->d0_power); > - > - return(0); > -} > --- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ethtool.c.old 2005-02-16 15:58:51.000000000 +0100 > +++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ethtool.c 2005-02-16 15:59:00.000000000 +0100 > @@ -665,7 +665,7 @@ > } > } > > -struct ethtool_ops ixgb_ethtool_ops = { > +static struct ethtool_ops ixgb_ethtool_ops = { > .get_settings = ixgb_get_settings, > .set_settings = ixgb_set_settings, > .get_drvinfo = ixgb_get_drvinfo, > --- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.c.old 2005-02-16 16:03:16.000000000 +0100 > +++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.c 2005-02-16 16:06:42.000000000 +0100 > @@ -47,9 +47,17 @@ > > static ixgb_phy_type ixgb_identify_phy(struct ixgb_hw *hw); > > -uint32_t ixgb_mac_reset(struct ixgb_hw *hw); > +static void ixgb_clear_hw_cntrs(struct ixgb_hw *hw); > +static void ixgb_clear_vfta(struct ixgb_hw *hw); > +static void ixgb_init_rx_addrs(struct ixgb_hw *hw); > +static uint16_t ixgb_read_phy_reg(struct ixgb_hw *hw, > + uint32_t reg_address, > + uint32_t phy_address, > + uint32_t device_type); > +static boolean_t ixgb_setup_fc(struct ixgb_hw *hw); > +static boolean_t mac_addr_valid(uint8_t *mac_addr); > > -uint32_t ixgb_mac_reset(struct ixgb_hw *hw) > +static uint32_t ixgb_mac_reset(struct ixgb_hw *hw) > { > uint32_t ctrl_reg; > > @@ -335,7 +343,7 @@ > * of the receive addresss registers. Clears the multicast table. Assumes > * the receiver is in reset when the routine is called. > *****************************************************************************/ > -void > +static void > ixgb_init_rx_addrs(struct ixgb_hw *hw) > { > uint32_t i; > @@ -604,7 +612,7 @@ > * > * hw - Struct containing variables accessed by shared code > *****************************************************************************/ > -void > +static void > ixgb_clear_vfta(struct ixgb_hw *hw) > { > uint32_t offset; > @@ -620,7 +628,7 @@ > * hw - Struct containing variables accessed by shared code > *****************************************************************************/ > > -boolean_t > +static boolean_t > ixgb_setup_fc(struct ixgb_hw *hw) > { > uint32_t ctrl_reg; > @@ -722,7 +730,7 @@ > * This requires that first an address cycle command is sent, followed by a > * read command. > *****************************************************************************/ > -uint16_t > +static uint16_t > ixgb_read_phy_reg(struct ixgb_hw *hw, > uint32_t reg_address, > uint32_t phy_address, > @@ -815,7 +823,7 @@ > * This requires that first an address cycle command is sent, followed by a > * write command. > *****************************************************************************/ > -void > +static void > ixgb_write_phy_reg(struct ixgb_hw *hw, > uint32_t reg_address, > uint32_t phy_address, > @@ -959,7 +967,7 @@ > * > * hw - Struct containing variables accessed by shared code > *****************************************************************************/ > -void > +static void > ixgb_clear_hw_cntrs(struct ixgb_hw *hw) > { > volatile uint32_t temp_reg; > @@ -1114,7 +1122,7 @@ > * mac_addr - pointer to MAC address. > * > *****************************************************************************/ > -boolean_t > +static boolean_t > mac_addr_valid(uint8_t *mac_addr) > { > boolean_t is_valid = TRUE; > --- linux-2.6.12-rc3-mm3-full/drivers/net/ixgb/ixgb_main.c.old 2005-05-06 22:08:38.000000000 +0200 > +++ linux-2.6.12-rc3-mm3-full/drivers/net/ixgb/ixgb_main.c 2005-05-06 22:09:29.000000000 +0200 > @@ -40,7 +40,7 @@ > */ > > char ixgb_driver_name[] = "ixgb"; > -char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver"; > +static char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver"; > > #ifndef CONFIG_IXGB_NAPI > #define DRIVERNAPI > @@ -49,7 +49,7 @@ > #endif > #define DRV_VERSION "1.0.90-k2"DRIVERNAPI > char ixgb_driver_version[] = DRV_VERSION; > -char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation."; > +static char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation."; > > /* ixgb_pci_tbl - PCI Device ID Table > * > @@ -130,7 +130,7 @@ > static void ixgb_netpoll(struct net_device *dev); > #endif > > -struct notifier_block ixgb_notifier_reboot = { > +static struct notifier_block ixgb_notifier_reboot = { > .notifier_call = ixgb_notify_reboot, > .next = NULL, > .priority = 0 > > From kaber@trash.net Fri May 6 15:46:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 15:46:51 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46MklOv020578 for ; Fri, 6 May 2005 15:46:48 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DUBaW-0001G3-KI; Sat, 07 May 2005 00:46:28 +0200 Message-ID: <427BF3C4.1030105@trash.net> Date: Sat, 07 May 2005 00:46:28 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Patrick McHardy CC: Asim Shankar , netdev@oss.sgi.com Subject: Re: SFQ: Reordering? References: <7bca1cb5050506145344d16b1e@mail.gmail.com> <427BEAAE.409@trash.net> In-Reply-To: <427BEAAE.409@trash.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 774 Lines: 19 Patrick McHardy wrote: > Asim Shankar wrote: > >>Should complete rehashing take place in sfq_perturbation(), or am I >>missing something? (I was looking at 2.6.9 and also took a cursory >>glance at 2.6.11 on lxr.linux.no) > > > I think we should rehash. Can you send a patch? Hmm wait, this is not so easy. We can't rehash by going over the buckets one by one. If we do so and we have a new clash of two flows previously contained in different buckets the packets will afterwards be sorted by flow in their new bucket. To retain fairness we need to iterate over all buckets containing packets and rehash them one packet per a bucket at a time. But this means we need lots of temporary storage to store the queues while rehashing. Can anyone thing of a better solution? From bunk@stusta.de Fri May 6 15:55:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 15:55:13 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46MtAOv021277 for ; Fri, 6 May 2005 15:55:10 -0700 Received: (qmail 12655 invoked from network); 6 May 2005 22:54:52 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 6 May 2005 22:54:52 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id D8616BB4E8; Sat, 7 May 2005 00:54:49 +0200 (CEST) Date: Sat, 7 May 2005 00:54:49 +0200 From: Adrian Bunk To: Andrew Morton , netdev@oss.sgi.com, jgarzik@pobox.com Cc: linux-kernel@vger.kernel.org Subject: [-mm patch] fix IEEE80211_CRYPT_* selects Message-ID: <20050506225449.GZ3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 2985 Lines: 89 Some of the options didn't obey the most important rule of select If you select something, you have to ensure that the dependencies of what you do select are fulfilled. resulting in the following compile error: <-- snip --> ... LD .tmp_vmlinux1 crypto/built-in.o(.init.text+0x31b): In function `aes_init': : undefined reference to `crypto_register_alg' crypto/built-in.o(.init.text+0x326): In function `michael_mic_init': : undefined reference to `crypto_register_alg' crypto/built-in.o(.exit.text+0x6): In function `aes_fini': : undefined reference to `crypto_unregister_alg' crypto/built-in.o(.exit.text+0x16): In function `michael_mic_exit': : undefined reference to `crypto_unregister_alg' net/built-in.o(.text+0x5ba52): In function `ieee80211_ccmp_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5ba94): In function `ieee80211_ccmp_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5bab7): In function `ieee80211_ccmp_deinit': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c5c2): In function `ieee80211_tkip_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5c5d5): In function `ieee80211_tkip_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5c623): In function `ieee80211_tkip_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c62a): In function `ieee80211_tkip_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c65e): In function `ieee80211_tkip_deinit': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c665): In function `ieee80211_tkip_deinit': : undefined reference to `crypto_free_tfm' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> This patch adds the missing selects of CRYPTO (similar to how IEEE80211_CRYPT_WEP already does it). Yes, you could argue whether CRYPTO should be select'ed by the CRYPTO_* options, but with the current CRYPTO* dependencies this patch is required. --- This patch was already sent on: - 26 Feb 2005 net/ieee80211/Kconfig | 2 ++ 1 files changed, 2 insertions(+) --- linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig.old 2005-02-26 12:12:44.000000000 +0100 +++ linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig 2005-02-26 12:13:47.000000000 +0100 @@ -42,10 +42,11 @@ "ieee80211_crypt_wep". config IEEE80211_CRYPT_CCMP tristate "IEEE 802.11i CCMP support" depends on IEEE80211 + select CRYPTO select CRYPTO_AES ---help--- Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled networks. @@ -54,10 +55,11 @@ "ieee80211_crypt_ccmp". config IEEE80211_CRYPT_TKIP tristate "IEEE 802.11i TKIP encryption" depends on IEEE80211 + select CRYPTO select CRYPTO_MICHAEL_MIC ---help--- Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with TKIP enabled networks. From tgraf@suug.ch Fri May 6 16:02:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 16:02:04 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46N1xOv021945 for ; Fri, 6 May 2005 16:02:00 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 9C33F1C0EB; Sat, 7 May 2005 01:02:03 +0200 (CEST) Date: Sat, 7 May 2005 01:02:03 +0200 From: Thomas Graf To: Patrick McHardy Cc: Asim Shankar , netdev@oss.sgi.com Subject: Re: SFQ: Reordering? Message-ID: <20050506230203.GI28419@postel.suug.ch> References: <7bca1cb5050506145344d16b1e@mail.gmail.com> <427BEAAE.409@trash.net> <427BF3C4.1030105@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427BF3C4.1030105@trash.net> X-archive-position: 893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 786 Lines: 14 * Patrick McHardy <427BF3C4.1030105@trash.net> 2005-05-07 00:46 > Hmm wait, this is not so easy. We can't rehash by going over > the buckets one by one. If we do so and we have a new clash of > two flows previously contained in different buckets the packets > will afterwards be sorted by flow in their new bucket. To retain > fairness we need to iterate over all buckets containing packets > and rehash them one packet per a bucket at a time. But this means > we need lots of temporary storage to store the queues while > rehashing. Can anyone thing of a better solution? We can maintain a second hash table and switch a pointer over to the new table but keep on dequeueing from the old one until it is empty. Anyways, any such behaviour should be made optional via a rtnetlink flag. From bunk@stusta.de Fri May 6 16:14:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 16:14:16 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46NEAOv022685 for ; Fri, 6 May 2005 16:14:10 -0700 Received: (qmail 13084 invoked from network); 6 May 2005 23:13:52 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 6 May 2005 23:13:52 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 2CE48BB4E8; Sat, 7 May 2005 01:13:50 +0200 (CEST) Date: Sat, 7 May 2005 01:13:49 +0200 From: Adrian Bunk To: neilb@cse.unsw.edu.au, trond.myklebust@fys.uio.no Cc: linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net, netdev@oss.sgi.com Subject: [RFC: 2.6 patch] net/sunrpc/: possible cleanups Message-ID: <20050506231349.GA3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 894 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 8245 Lines: 247 This patch contains the following possible cleanups: - make needlessly global code static - #if 0 the following unused global function: - xdr.c: xdr_decode_string - remove the following unneeded EXPORT_SYMBOL's: - auth_gss/gss_mech_switch.c: gss_mech_get - auth_gss/gss_mech_switch.c: gss_mech_get_by_name - auth_gss/gss_mech_switch.c: gss_mech_get_by_pseudoflavor - auth_gss/gss_mech_switch.c: gss_pseudoflavor_to_service - auth_gss/gss_mech_switch.c: gss_service_to_auth_domain_name - auth_gss/gss_mech_switch.c: gss_mech_put - sunrpc_syms.c: rpc_wake_up_next - sunrpc_syms.c: rpc_new_child - sunrpc_syms.c: rpc_run_child - sunrpc_syms.c: rpc_new_task - sunrpc_syms.c: rpc_release_task - sunrpc_syms.c: rpc_release_client - sunrpc_syms.c: xprt_udp_slot_table_entries - sunrpc_syms.c: xprt_tcp_slot_table_entries - sunrpc_syms.c: svc_drop - sunrpc_syms.c: svc_authenticate - sunrpc_syms.c: xdr_decode_string Please review which of these patches do make sense and which conflict with pending patches. Signed-off-by: Adrian Bunk --- include/linux/sunrpc/clnt.h | 1 - include/linux/sunrpc/gss_api.h | 3 --- include/linux/sunrpc/xdr.h | 2 -- net/sunrpc/auth_gss/gss_mech_switch.c | 13 +------------ net/sunrpc/clnt.c | 3 ++- net/sunrpc/sunrpc_syms.c | 11 ----------- net/sunrpc/xdr.c | 4 +++- 7 files changed, 6 insertions(+), 31 deletions(-) --- linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/gss_api.h.old 2005-05-05 23:05:01.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/gss_api.h 2005-05-05 23:05:10.000000000 +0200 @@ -110,9 +110,6 @@ /* Similar, but get by pseudoflavor. */ struct gss_api_mech *gss_mech_get_by_pseudoflavor(u32); -/* Just increments the mechanism's reference count and returns its input: */ -struct gss_api_mech * gss_mech_get(struct gss_api_mech *); - /* For every succesful gss_mech_get or gss_mech_get_by_* call there must be a * corresponding call to gss_mech_put. */ void gss_mech_put(struct gss_api_mech *); --- linux-2.6.12-rc3-mm3-full/net/sunrpc/auth_gss/gss_mech_switch.c.old 2005-05-05 23:05:17.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/sunrpc/auth_gss/gss_mech_switch.c 2005-05-05 23:19:33.000000000 +0200 @@ -133,14 +133,13 @@ EXPORT_SYMBOL(gss_mech_unregister); -struct gss_api_mech * +static struct gss_api_mech * gss_mech_get(struct gss_api_mech *gm) { __module_get(gm->gm_owner); return gm; } -EXPORT_SYMBOL(gss_mech_get); struct gss_api_mech * gss_mech_get_by_name(const char *name) @@ -160,8 +159,6 @@ } -EXPORT_SYMBOL(gss_mech_get_by_name); - static inline int mech_supports_pseudoflavor(struct gss_api_mech *gm, u32 pseudoflavor) { @@ -193,8 +190,6 @@ return gm; } -EXPORT_SYMBOL(gss_mech_get_by_pseudoflavor); - u32 gss_pseudoflavor_to_service(struct gss_api_mech *gm, u32 pseudoflavor) { @@ -207,8 +202,6 @@ return 0; } -EXPORT_SYMBOL(gss_pseudoflavor_to_service); - char * gss_service_to_auth_domain_name(struct gss_api_mech *gm, u32 service) { @@ -221,16 +214,12 @@ return NULL; } -EXPORT_SYMBOL(gss_service_to_auth_domain_name); - void gss_mech_put(struct gss_api_mech * gm) { module_put(gm->gm_owner); } -EXPORT_SYMBOL(gss_mech_put); - /* The mech could probably be determined from the token instead, but it's just * as easy for now to pass it in. */ int --- linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/clnt.h.old 2005-05-05 23:05:45.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/clnt.h 2005-05-05 23:05:50.000000000 +0200 @@ -134,7 +134,6 @@ void rpc_clnt_sigunmask(struct rpc_clnt *clnt, sigset_t *oldset); void rpc_setbufsize(struct rpc_clnt *, unsigned int, unsigned int); size_t rpc_max_payload(struct rpc_clnt *); -int rpc_ping(struct rpc_clnt *clnt, int flags); static __inline__ int rpc_call(struct rpc_clnt *clnt, u32 proc, void *argp, void *resp, int flags) --- linux-2.6.12-rc3-mm3-full/net/sunrpc/clnt.c.old 2005-05-05 23:05:58.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/sunrpc/clnt.c 2005-05-05 23:06:21.000000000 +0200 @@ -63,6 +63,7 @@ static u32 * call_header(struct rpc_task *task); static u32 * call_verify(struct rpc_task *task); +static int rpc_ping(struct rpc_clnt *clnt, int flags); static int rpc_setup_pipedir(struct rpc_clnt *clnt, char *dir_name) @@ -1178,7 +1179,7 @@ .p_decode = rpcproc_decode_null, }; -int rpc_ping(struct rpc_clnt *clnt, int flags) +static int rpc_ping(struct rpc_clnt *clnt, int flags) { struct rpc_message msg = { .rpc_proc = &rpcproc_null, --- linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/xdr.h.old 2005-05-05 23:06:40.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/xdr.h 2005-05-05 23:07:23.000000000 +0200 @@ -91,7 +91,6 @@ u32 * xdr_encode_opaque_fixed(u32 *p, const void *ptr, unsigned int len); u32 * xdr_encode_opaque(u32 *p, const void *ptr, unsigned int len); u32 * xdr_encode_string(u32 *p, const char *s); -u32 * xdr_decode_string(u32 *p, char **sp, int *lenp, int maxlen); u32 * xdr_decode_string_inplace(u32 *p, char **sp, int *lenp, int maxlen); u32 * xdr_encode_netobj(u32 *p, const struct xdr_netobj *); u32 * xdr_decode_netobj(u32 *p, struct xdr_netobj *); @@ -147,7 +146,6 @@ extern int xdr_buf_subsegment(struct xdr_buf *, struct xdr_buf *, int, int); extern int xdr_buf_read_netobj(struct xdr_buf *, struct xdr_netobj *, int); extern int read_bytes_from_xdr_buf(struct xdr_buf *, int, void *, int); -extern int write_bytes_to_xdr_buf(struct xdr_buf *, int, void *, int); /* * Helper structure for copying from an sk_buff. --- linux-2.6.12-rc3-mm3-full/net/sunrpc/xdr.c.old 2005-05-05 23:06:52.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/sunrpc/xdr.c 2005-05-05 23:07:56.000000000 +0200 @@ -95,6 +95,7 @@ return xdr_encode_array(p, string, strlen(string)); } +#if 0 u32 * xdr_decode_string(u32 *p, char **sp, int *lenp, int maxlen) { @@ -115,6 +116,7 @@ *sp = string; return p + XDR_QUADLEN(len); } +#endif /* 0 */ u32 * xdr_decode_string_inplace(u32 *p, char **sp, int *lenp, int maxlen) @@ -882,7 +884,7 @@ } /* obj is assumed to point to allocated memory of size at least len: */ -int +static int write_bytes_to_xdr_buf(struct xdr_buf *buf, int base, void *obj, int len) { struct xdr_buf subbuf; --- linux-2.6.12-rc3-mm3-full/net/sunrpc/sunrpc_syms.c.old 2005-05-05 23:07:30.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/sunrpc/sunrpc_syms.c 2005-05-05 23:36:43.000000000 +0200 @@ -29,15 +29,10 @@ EXPORT_SYMBOL(rpc_execute); EXPORT_SYMBOL(rpc_init_task); EXPORT_SYMBOL(rpc_sleep_on); -EXPORT_SYMBOL(rpc_wake_up_next); EXPORT_SYMBOL(rpc_wake_up_task); -EXPORT_SYMBOL(rpc_new_child); -EXPORT_SYMBOL(rpc_run_child); EXPORT_SYMBOL(rpciod_down); EXPORT_SYMBOL(rpciod_up); -EXPORT_SYMBOL(rpc_new_task); EXPORT_SYMBOL(rpc_wake_up_status); -EXPORT_SYMBOL(rpc_release_task); /* RPC client functions */ EXPORT_SYMBOL(rpc_create_client); @@ -45,7 +40,6 @@ EXPORT_SYMBOL(rpc_bind_new_program); EXPORT_SYMBOL(rpc_destroy_client); EXPORT_SYMBOL(rpc_shutdown_client); -EXPORT_SYMBOL(rpc_release_client); EXPORT_SYMBOL(rpc_killall_tasks); EXPORT_SYMBOL(rpc_call_sync); EXPORT_SYMBOL(rpc_call_async); @@ -63,8 +57,6 @@ /* Client transport */ EXPORT_SYMBOL(xprt_create_proto); EXPORT_SYMBOL(xprt_set_timeout); -EXPORT_SYMBOL(xprt_udp_slot_table_entries); -EXPORT_SYMBOL(xprt_tcp_slot_table_entries); /* Client credential cache */ EXPORT_SYMBOL(rpcauth_register); @@ -81,7 +73,6 @@ EXPORT_SYMBOL(svc_create_thread); EXPORT_SYMBOL(svc_exit_thread); EXPORT_SYMBOL(svc_destroy); -EXPORT_SYMBOL(svc_drop); EXPORT_SYMBOL(svc_process); EXPORT_SYMBOL(svc_recv); EXPORT_SYMBOL(svc_wake_up); @@ -89,7 +80,6 @@ EXPORT_SYMBOL(svc_reserve); EXPORT_SYMBOL(svc_auth_register); EXPORT_SYMBOL(auth_domain_lookup); -EXPORT_SYMBOL(svc_authenticate); EXPORT_SYMBOL(svc_set_client); /* RPC statistics */ @@ -122,7 +112,6 @@ /* Generic XDR */ EXPORT_SYMBOL(xdr_encode_string); -EXPORT_SYMBOL(xdr_decode_string); EXPORT_SYMBOL(xdr_decode_string_inplace); EXPORT_SYMBOL(xdr_decode_netobj); EXPORT_SYMBOL(xdr_encode_netobj); From bunk@stusta.de Fri May 6 16:18:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 16:18:26 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46NIMOv023243 for ; Fri, 6 May 2005 16:18:23 -0700 Received: (qmail 13188 invoked from network); 6 May 2005 23:18:05 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 6 May 2005 23:18:05 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 3981DBB4E8; Sat, 7 May 2005 01:18:03 +0200 (CEST) Date: Sat, 7 May 2005 01:18:03 +0200 From: Adrian Bunk To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [RFC: 2.6 patch] net/ipv4/: possible cleanups Message-ID: <20050506231803.GB3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 895 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 7896 Lines: 230 This patch contains the following possible cleanups: - make needlessly global code static - #if 0 the following unused global function: - xfrm4_state.c: xfrm4_state_fini - remove the following unneeded EXPORT_SYMBOL's: - ip_output.c: ip_finish_output - ip_output.c: sysctl_ip_default_ttl - fib_frontend.c: ip_dev_find - inetpeer.c: inet_peer_idlock - ip_options.c: ip_options_compile - ip_options.c: ip_options_undo - tcp_ipv4.c: sysctl_max_syn_backlog Please review which of these changes are correct and which might conflict with pending patches. Signed-off-by: Adrian Bunk --- include/net/ip.h | 2 -- include/net/route.h | 4 ---- include/net/tcp.h | 2 -- include/net/tcp_ecn.h | 13 ------------- include/net/xfrm.h | 1 - net/ipv4/fib_frontend.c | 1 - net/ipv4/inetpeer.c | 2 -- net/ipv4/ip_options.c | 3 --- net/ipv4/ip_output.c | 7 +------ net/ipv4/multipath_drr.c | 2 +- net/ipv4/route.c | 4 +++- net/ipv4/tcp_input.c | 15 ++++++++++++++- net/ipv4/tcp_ipv4.c | 1 - net/ipv4/xfrm4_state.c | 2 ++ 14 files changed, 21 insertions(+), 38 deletions(-) --- linux-2.6.12-rc3-mm2-full/include/net/ip.h.old 2005-05-05 02:35:00.000000000 +0200 +++ linux-2.6.12-rc3-mm2-full/include/net/ip.h 2005-05-05 02:35:07.000000000 +0200 @@ -140,8 +140,6 @@ void ip_send_reply(struct sock *sk, struct sk_buff *skb, struct ip_reply_arg *arg, unsigned int len); -extern int ip_finish_output(struct sk_buff *skb); - struct ipv4_config { int log_martians; --- linux-2.6.12-rc3-mm2-full/net/ipv4/multipath_drr.c.old 2005-05-05 02:37:58.000000000 +0200 +++ linux-2.6.12-rc3-mm2-full/net/ipv4/multipath_drr.c 2005-05-05 02:38:06.000000000 +0200 @@ -107,7 +107,7 @@ return NOTIFY_DONE; } -struct notifier_block drr_dev_notifier = { +static struct notifier_block drr_dev_notifier = { .notifier_call = drr_dev_event, }; --- linux-2.6.12-rc3-mm3-full/net/ipv4/ip_output.c.old 2005-05-05 21:43:22.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/ipv4/ip_output.c 2005-05-05 21:44:36.000000000 +0200 @@ -216,7 +216,7 @@ return -EINVAL; } -int ip_finish_output(struct sk_buff *skb) +static int ip_finish_output(struct sk_buff *skb) { struct net_device *dev = skb->dst->dev; @@ -1351,12 +1351,7 @@ #endif } -EXPORT_SYMBOL(ip_finish_output); EXPORT_SYMBOL(ip_fragment); EXPORT_SYMBOL(ip_generic_getfrag); EXPORT_SYMBOL(ip_queue_xmit); EXPORT_SYMBOL(ip_send_check); - -#ifdef CONFIG_SYSCTL -EXPORT_SYMBOL(sysctl_ip_default_ttl); -#endif --- linux-2.6.12-rc3-mm3-full/include/net/route.h.old 2005-05-05 21:21:09.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/include/net/route.h 2005-05-05 21:22:19.000000000 +0200 @@ -105,10 +105,6 @@ unsigned int out_hlist_search; }; -extern struct rt_cache_stat *rt_cache_stat; -#define RT_CACHE_STAT_INC(field) \ - (per_cpu_ptr(rt_cache_stat, _smp_processor_id())->field++) - extern struct ip_rt_acct *ip_rt_acct; struct in_device; --- linux-2.6.12-rc3-mm3-full/net/ipv4/route.c.old 2005-05-05 21:21:21.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/ipv4/route.c 2005-05-05 21:22:14.000000000 +0200 @@ -209,7 +209,9 @@ static int rt_hash_log; static unsigned int rt_hash_rnd; -struct rt_cache_stat *rt_cache_stat; +static struct rt_cache_stat *rt_cache_stat; +#define RT_CACHE_STAT_INC(field) \ + (per_cpu_ptr(rt_cache_stat, _smp_processor_id())->field++) static int rt_intern_hash(unsigned hash, struct rtable *rth, struct rtable **res); --- linux-2.6.12-rc3-mm3-full/include/net/tcp.h.old 2005-05-05 21:23:42.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/include/net/tcp.h 2005-05-05 21:23:52.000000000 +0200 @@ -825,8 +825,6 @@ } } -extern void tcp_enter_quickack_mode(struct tcp_sock *tp); - static __inline__ void tcp_delack_init(struct tcp_sock *tp) { memset(&tp->ack, 0, sizeof(tp->ack)); --- linux-2.6.12-rc3-mm3-full/include/net/tcp_ecn.h.old 2005-05-05 21:25:48.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/include/net/tcp_ecn.h 2005-05-05 21:25:57.000000000 +0200 @@ -78,19 +78,6 @@ tp->ecn_flags &= ~TCP_ECN_DEMAND_CWR; } -static inline void TCP_ECN_check_ce(struct tcp_sock *tp, struct sk_buff *skb) -{ - if (tp->ecn_flags&TCP_ECN_OK) { - if (INET_ECN_is_ce(TCP_SKB_CB(skb)->flags)) - tp->ecn_flags |= TCP_ECN_DEMAND_CWR; - /* Funny extension: if ECT is not set on a segment, - * it is surely retransmit. It is not in ECN RFC, - * but Linux follows this rule. */ - else if (INET_ECN_is_not_ect((TCP_SKB_CB(skb)->flags))) - tcp_enter_quickack_mode(tp); - } -} - static inline void TCP_ECN_rcv_synack(struct tcp_sock *tp, struct tcphdr *th) { if ((tp->ecn_flags&TCP_ECN_OK) && (!th->ece || th->cwr)) --- linux-2.6.12-rc3-mm3-full/net/ipv4/tcp_input.c.old 2005-05-05 21:24:11.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/ipv4/tcp_input.c 2005-05-05 21:25:04.000000000 +0200 @@ -183,13 +183,26 @@ tp->ack.quick = min(quickacks, TCP_MAX_QUICKACKS); } -void tcp_enter_quickack_mode(struct tcp_sock *tp) +static void tcp_enter_quickack_mode(struct tcp_sock *tp) { tcp_incr_quickack(tp); tp->ack.pingpong = 0; tp->ack.ato = TCP_ATO_MIN; } +static inline void TCP_ECN_check_ce(struct tcp_sock *tp, struct sk_buff *skb) +{ + if (tp->ecn_flags&TCP_ECN_OK) { + if (INET_ECN_is_ce(TCP_SKB_CB(skb)->flags)) + tp->ecn_flags |= TCP_ECN_DEMAND_CWR; + /* Funny extension: if ECT is not set on a segment, + * it is surely retransmit. It is not in ECN RFC, + * but Linux follows this rule. */ + else if (INET_ECN_is_not_ect((TCP_SKB_CB(skb)->flags))) + tcp_enter_quickack_mode(tp); + } +} + /* Send ACKs quickly, if "quick" count is not exhausted * and the session is not interactive. */ --- linux-2.6.12-rc3-mm3-full/include/net/xfrm.h.old 2005-05-05 21:26:56.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/include/net/xfrm.h 2005-05-05 21:27:01.000000000 +0200 @@ -799,7 +799,6 @@ extern void xfrm6_fini(void); extern void xfrm_state_init(void); extern void xfrm4_state_init(void); -extern void xfrm4_state_fini(void); extern void xfrm6_state_init(void); extern void xfrm6_state_fini(void); --- linux-2.6.12-rc3-mm3-full/net/ipv4/xfrm4_state.c.old 2005-05-05 21:27:09.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/ipv4/xfrm4_state.c 2005-05-05 21:27:24.000000000 +0200 @@ -119,8 +119,10 @@ xfrm_state_register_afinfo(&xfrm4_state_afinfo); } +#if 0 void __exit xfrm4_state_fini(void) { xfrm_state_unregister_afinfo(&xfrm4_state_afinfo); } +#endif /* 0 */ --- linux-2.6.12-rc3-mm3-full/net/ipv4/fib_frontend.c.old 2005-05-05 21:38:28.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/ipv4/fib_frontend.c 2005-05-05 21:38:40.000000000 +0200 @@ -607,5 +607,4 @@ } EXPORT_SYMBOL(inet_addr_type); -EXPORT_SYMBOL(ip_dev_find); EXPORT_SYMBOL(ip_rt_ioctl); --- linux-2.6.12-rc3-mm3-full/net/ipv4/inetpeer.c.old 2005-05-05 21:41:06.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/ipv4/inetpeer.c 2005-05-05 21:41:14.000000000 +0200 @@ -456,5 +456,3 @@ peer_total / inet_peer_threshold * HZ; add_timer(&peer_periodic_timer); } - -EXPORT_SYMBOL(inet_peer_idlock); --- linux-2.6.12-rc3-mm3-full/net/ipv4/ip_options.c.old 2005-05-05 21:42:02.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/ipv4/ip_options.c 2005-05-05 21:42:33.000000000 +0200 @@ -620,6 +620,3 @@ } return 0; } - -EXPORT_SYMBOL(ip_options_compile); -EXPORT_SYMBOL(ip_options_undo); --- linux-2.6.12-rc3-mm3-full/net/ipv4/tcp_ipv4.c.old 2005-05-05 21:58:55.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/ipv4/tcp_ipv4.c 2005-05-05 21:59:33.000000000 +0200 @@ -2660,7 +2660,6 @@ EXPORT_SYMBOL(tcp_proc_unregister); #endif EXPORT_SYMBOL(sysctl_local_port_range); -EXPORT_SYMBOL(sysctl_max_syn_backlog); EXPORT_SYMBOL(sysctl_tcp_low_latency); EXPORT_SYMBOL(sysctl_tcp_tw_reuse); From kaber@trash.net Fri May 6 16:19:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 16:19:36 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46NJXOv027217 for ; Fri, 6 May 2005 16:19:33 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DUC6F-0001K7-3u; Sat, 07 May 2005 01:19:15 +0200 Message-ID: <427BFB72.7080407@trash.net> Date: Sat, 07 May 2005 01:19:14 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: Asim Shankar , netdev@oss.sgi.com Subject: Re: SFQ: Reordering? References: <7bca1cb5050506145344d16b1e@mail.gmail.com> <427BEAAE.409@trash.net> <427BF3C4.1030105@trash.net> <20050506230203.GI28419@postel.suug.ch> In-Reply-To: <20050506230203.GI28419@postel.suug.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 485 Lines: 13 Thomas Graf wrote: > We can maintain a second hash table and switch a pointer over to the > new table but keep on dequeueing from the old one until it is empty. > Anyways, any such behaviour should be made optional via a rtnetlink > flag. This also introduces unfairness. Packets of a flow could be only in the new table while we're still working on the active table. A proper solution to avoid reordering shouldn't be optional IMO, perturbation is already optional. Regards Patrick From bunk@stusta.de Fri May 6 16:20:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 16:20:24 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j46NKKOv027511 for ; Fri, 6 May 2005 16:20:21 -0700 Received: (qmail 13221 invoked from network); 6 May 2005 23:20:02 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 6 May 2005 23:20:02 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id B2B91BB4E8; Sat, 7 May 2005 01:20:00 +0200 (CEST) Date: Sat, 7 May 2005 01:20:00 +0200 From: Adrian Bunk To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [RFC: 2.6 patch] net/ipv6/ipv6_syms.c: unexport fl6_sock_lookup Message-ID: <20050506232000.GC3590@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 432 Lines: 13 There is no usage of this EXPORT_SYMBOL in the kernel. Signed-off-by: Adrian Bunk --- linux-2.6.12-rc3-mm3-full/net/ipv6/ipv6_syms.c.old 2005-05-05 22:23:17.000000000 +0200 +++ linux-2.6.12-rc3-mm3-full/net/ipv6/ipv6_syms.c 2005-05-05 22:23:23.000000000 +0200 @@ -37,5 +37,4 @@ EXPORT_SYMBOL(xfrm6_rcv); #endif EXPORT_SYMBOL(rt6_lookup); -EXPORT_SYMBOL(fl6_sock_lookup); EXPORT_SYMBOL(ipv6_push_nfrag_opts); From mchan@broadcom.com Fri May 6 16:25:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 16:25:51 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46NPlOv028421 for ; Fri, 6 May 2005 16:25:47 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 06 May 2005 16:24:55 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 6 May 2005 16:25:12 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWY23712; Fri, 6 May 2005 16:25:08 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id QAA26862; Fri, 6 May 2005 16:25:08 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 May 2005 23:25:08 +0000 Received: from rh4 by nt-irva-0741; 06 May 2005 15:27:11 -0700 Subject: Re: [TG3]: Add tagged status support From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com In-Reply-To: <20050505211735.3829cff2.davem@davemloft.net> References: <20050505211735.3829cff2.davem@davemloft.net> Date: Fri, 06 May 2005 15:27:11 -0700 Message-ID: <1115418431.15156.153.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E65234D21S2617255-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 898 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1921 Lines: 42 On Thu, 2005-05-05 at 21:17 -0700, David S. Miller wrote: > I've been meaning to do this for a long time. > > This adds tagged status support. With this, we don't need to > poke the chip 10 times per second via the timer to keep from > losing interrupts. > > Michael, I didn't know what needs to be done wrt. MSI here. > So I didn't touch the MSI code until I understand things better, > which likely means that this patch breaks MSI (actually, I think > it will cause the MSI case to generate interrupts endlessly). > > My best hunch is that all MSI supporting chips support tagged > status, therefore I should just make the tg3_msi() interrupt > handler do the tp->last_tag stuff. That's right. All MSI capable chips support tagged mode. I tested the patch and it worked fine. But I'd like to suggest a few things: At the beginning of tg3_poll() before any work is done, update tp- >last_tag with the current tag from the status block. The reason is that under heavy traffic, tg3_poll() may be called multiple times before interrupts are re-enabled. During this time, there may be additional status block updates with updated tags. If tp->last_tag is not updated, when we finally re-enable interrupts, we may write an old tag that will cause the chip to interrupt us again unnecessarily. In tagged mode, when we call tg3_restart_ints(), it is not necessary to check for additional work and do "coalesce_now". The chip will do that for us by looking at the tag written to the mailbox. I think we can keep the same tg3_poll() for tagged and untagged modes by using a function pointer that gets assigned different versions of tg3_restart_ints() depending on the mode. The update of tp->last_tag at the beginning of tg3_poll() can be done unconditionally provided we add a check in tg3_enable_ints() to determine whether or not to use the tag. This should be ok since tg3_enable_ints() is not in the fast path. From yoshfuji@linux-ipv6.org Fri May 6 16:54:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 16:54:36 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j46NsWOv029552 for ; Fri, 6 May 2005 16:54:32 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D480833CC2; Sat, 7 May 2005 08:56:47 +0900 (JST) Date: Sat, 07 May 2005 08:56:39 +0900 (JST) Message-Id: <20050507.085639.75977025.yoshfuji@linux-ipv6.org> To: bunk@stusta.de, davem@davemloft.net Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org Subject: Re: [RFC: 2.6 patch] net/ipv6/ipv6_syms.c: unexport fl6_sock_lookup From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050506232000.GC3590@stusta.de> References: <20050506232000.GC3590@stusta.de> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 631 Lines: 17 In article <20050506232000.GC3590@stusta.de> (at Sat, 7 May 2005 01:20:00 +0200), Adrian Bunk says: > There is no usage of this EXPORT_SYMBOL in the kernel. > > Signed-off-by: Adrian Bunk Acked-by: Hideaki YOSHIFUJI > --- linux-2.6.12-rc3-mm3-full/net/ipv6/ipv6_syms.c.old 2005-05-05 22:23:17.000000000 +0200 > +++ linux-2.6.12-rc3-mm3-full/net/ipv6/ipv6_syms.c 2005-05-05 22:23:23.000000000 +0200 > @@ -37,5 +37,4 @@ > EXPORT_SYMBOL(xfrm6_rcv); > #endif > EXPORT_SYMBOL(rt6_lookup); > -EXPORT_SYMBOL(fl6_sock_lookup); > EXPORT_SYMBOL(ipv6_push_nfrag_opts); > > From yoshfuji@linux-ipv6.org Fri May 6 17:15:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 17:15:36 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j470FQOv030665 for ; Fri, 6 May 2005 17:15:27 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id ACA5833D10; Sat, 7 May 2005 09:17:50 +0900 (JST) Date: Sat, 07 May 2005 09:17:44 +0900 (JST) Message-Id: <20050507.091744.106860599.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch Cc: netdev@oss.sgi.com, pablo@eurodev.net, yoshfuji@linux-ipv6.org Subject: Re: [RFC] textsearch infrastructure + skb_find_text() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050506214437.GH28419@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> <20050506214437.GH28419@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 394 Lines: 11 In article <20050506214437.GH28419@postel.suug.ch> (at Fri, 6 May 2005 23:44:37 +0200), Thomas Graf says: > Quite silly regular expression implementation for textsearch > infrastructure. Still has issues with textsearch_next() and > can probably be optimized a lot but should be a good base > to work on. Would you add some reference(s) on algorithm etc.? Thanks. --yoshfuji From tgraf@suug.ch Fri May 6 17:36:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 17:36:13 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j470a9Ov031533 for ; Fri, 6 May 2005 17:36:10 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 713391C0EB; Sat, 7 May 2005 02:36:13 +0200 (CEST) Date: Sat, 7 May 2005 02:36:13 +0200 From: Thomas Graf To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: netdev@oss.sgi.com, pablo@eurodev.net Subject: Re: [RFC] textsearch infrastructure + skb_find_text() Message-ID: <20050507003613.GJ28419@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> <20050506214437.GH28419@postel.suug.ch> <20050507.091744.106860599.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050507.091744.106860599.yoshfuji@linux-ipv6.org> X-archive-position: 901 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 636 Lines: 13 * YOSHIFUJI Hideaki / ?$B5HF#1QL@ <20050507.091744.106860599.yoshfuji@linux-ipv6.org> 2005-05-07 09:17 > In article <20050506214437.GH28419@postel.suug.ch> (at Fri, 6 May 2005 23:44:37 +0200), Thomas Graf says: > > > Quite silly regular expression implementation for textsearch > > infrastructure. Still has issues with textsearch_next() and > > can probably be optimized a lot but should be a good base > > to work on. > > Would you add some reference(s) on algorithm etc.? Comes out of my own mind which means it's probably pretty poor, it simply takes a deterministic finite state machine and runs it on the text. From tgraf@suug.ch Fri May 6 17:58:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 17:58:52 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j470wlOv032394 for ; Fri, 6 May 2005 17:58:48 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 613871C0EB; Sat, 7 May 2005 02:58:51 +0200 (CEST) Date: Sat, 7 May 2005 02:58:51 +0200 From: Thomas Graf To: Patrick McHardy Cc: Asim Shankar , netdev@oss.sgi.com Subject: Re: SFQ: Reordering? Message-ID: <20050507005851.GK28419@postel.suug.ch> References: <7bca1cb5050506145344d16b1e@mail.gmail.com> <427BEAAE.409@trash.net> <427BF3C4.1030105@trash.net> <20050506230203.GI28419@postel.suug.ch> <427BFB72.7080407@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427BFB72.7080407@trash.net> X-archive-position: 902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 975 Lines: 19 * Patrick McHardy <427BFB72.7080407@trash.net> 2005-05-07 01:19 > Thomas Graf wrote: > > We can maintain a second hash table and switch a pointer over to the > > new table but keep on dequeueing from the old one until it is empty. > > Anyways, any such behaviour should be made optional via a rtnetlink > > flag. > > This also introduces unfairness. Packets of a flow could be only in > the new table while we're still working on the active table. > A proper solution to avoid reordering shouldn't be optional IMO, > perturbation is already optional. Yes, that's true but we can't reach perfect fairness anyway. What is your primary goal? No reordering inside flows while staying as fair as possible? I'm not sure whether it's worth to rehash every single enqueued packet, especially not at a perturbation interval of just a few seconds. Many scripts set it to a value of 1..5 to have a higher theoreticaly fairness. That's why I think this feature should be made optional From kaber@trash.net Fri May 6 18:28:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 18:29:00 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j471StOv001106 for ; Fri, 6 May 2005 18:28:56 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DUE7P-0002SS-CA; Sat, 07 May 2005 03:28:35 +0200 Message-ID: <427C19C3.5030304@trash.net> Date: Sat, 07 May 2005 03:28:35 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: Asim Shankar , netdev@oss.sgi.com Subject: Re: SFQ: Reordering? References: <7bca1cb5050506145344d16b1e@mail.gmail.com> <427BEAAE.409@trash.net> <427BF3C4.1030105@trash.net> <20050506230203.GI28419@postel.suug.ch> <427BFB72.7080407@trash.net> <20050507005851.GK28419@postel.suug.ch> In-Reply-To: <20050507005851.GK28419@postel.suug.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1332 Lines: 29 Thomas Graf wrote: > * Patrick McHardy <427BFB72.7080407@trash.net> 2005-05-07 01:19 > >>This also introduces unfairness. Packets of a flow could be only in >>the new table while we're still working on the active table. >>A proper solution to avoid reordering shouldn't be optional IMO, >>perturbation is already optional. > > > Yes, that's true but we can't reach perfect fairness anyway. What > is your primary goal? No reordering inside flows while staying > as fair as possible? I'm not sure whether it's worth to rehash > every single enqueued packet, especially not at a perturbation > interval of just a few seconds. Many scripts set it to a value > of 1..5 to have a higher theoreticaly fairness. That's why I think > this feature should be made optional You stated my goal precisely :) I know many people set the interval to too low values, but because of the tight limits, it shouldn't be very expensive anyways. Table switching OTOH would introduce frequently occuring unfairness, and the time to work through a full table is a lot longer, especially in the environments where SFQ is used. It would be interesting to see this in real-life, when a single flow is hashed to multiple buckets (it can be even more than two) and each bucket has some packets queued, the result should look pretty chaotic. Regards Patrick From jesse.brandeburg@intel.com Fri May 6 19:16:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 19:16:22 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j472GEOv002782 for ; Fri, 6 May 2005 19:16:19 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j472FthL001848; Sat, 7 May 2005 02:15:55 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j472Ftbo032143; Sat, 7 May 2005 02:15:55 GMT Received: from isotope.jf.intel.com (isotope.jf.intel.com [10.23.35.8]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j472FtSL026936; Fri, 6 May 2005 19:15:55 -0700 Date: Fri, 6 May 2005 19:15:54 -0700 (PDT) From: Jesse Brandeburg X-X-Sender: jbrandeb@isotope.jf.intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com Subject: [PATCH] ethtool: add support for latest Intel adapters Message-ID: ReplyTo: "Jesse Brandeburg" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-archive-position: 904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse.brandeburg@intel.com Precedence: bulk X-list: netdev Content-Length: 3191 Lines: 99 This patch adds register dump and device ID support for the new Intel PRO/1000 Server Adapters with a PCI-Express bus. It also took care of a little housekeeping of some missing device IDs. Signed-off-by: Jesse Brandeburg ===== e1000.c 1.5 vs edited ===== --- 1.5/e1000.c 2004-04-09 11:44:55 -07:00 +++ edited/e1000.c 2005-04-15 17:15:55 -07:00 @@ -137,10 +137,16 @@ #define E1000_DEV_ID_82547GI 0x1075 #define E1000_DEV_ID_82541GI 0x1076 #define E1000_DEV_ID_82541GI_MOBILE 0x1077 +#define E1000_DEV_ID_82541GI_LF 0x107C #define E1000_DEV_ID_82546GB_COPPER 0x1079 #define E1000_DEV_ID_82546GB_FIBER 0x107A #define E1000_DEV_ID_82546GB_SERDES 0x107B +#define E1000_DEV_ID_82546GB_PCIE 0x108A #define E1000_DEV_ID_82547EI 0x1019 +#define E1000_DEV_ID_82573E 0x108B +#define E1000_DEV_ID_82573E_IAMT 0x108C + +#define E1000_DEV_ID_82546GB_QUAD_COPPER 0x1099 #define E1000_82542_2_0_REV_ID 2 #define E1000_82542_2_1_REV_ID 3 @@ -162,6 +168,7 @@ e1000_82541_rev_2, e1000_82547, e1000_82547_rev_2, + e1000_82573, e1000_num_macs }; @@ -217,6 +224,8 @@ case E1000_DEV_ID_82546GB_COPPER: case E1000_DEV_ID_82546GB_FIBER: case E1000_DEV_ID_82546GB_SERDES: + case E1000_DEV_ID_82546GB_PCIE: + case E1000_DEV_ID_82546GB_QUAD_COPPER: mac_type = e1000_82546_rev_3; break; case E1000_DEV_ID_82541EI: @@ -225,6 +234,7 @@ break; case E1000_DEV_ID_82541ER: case E1000_DEV_ID_82541GI: + case E1000_DEV_ID_82541GI_LF: case E1000_DEV_ID_82541GI_MOBILE: mac_type = e1000_82541_rev_2; break; @@ -234,6 +244,10 @@ case E1000_DEV_ID_82547GI: mac_type = e1000_82547_rev_2; break; + case E1000_DEV_ID_82573E: + case E1000_DEV_ID_82573E_IAMT: + mac_type = e1000_82573; + break; default: /* list of supported devices probably needs updating */ mac_type = e1000_82543; @@ -309,7 +323,23 @@ reg, reg & E1000_STATUS_FD ? "full" : "half", reg & E1000_STATUS_LU ? "link config" : "no link config"); - if(mac_type >= e1000_82543) { + if(mac_type >= e1000_82573) { + fprintf(stdout, + " TBI mode: %s\n" + " Link speed: %s\n" + " Bus type: %s\n" + " Port number: %s\n", + reg & E1000_STATUS_TBIMODE ? "enabled" : "disabled", + (reg & E1000_STATUS_SPEED_MASK) == E1000_STATUS_SPEED_10 ? + "10Mb/s" : + (reg & E1000_STATUS_SPEED_MASK) == E1000_STATUS_SPEED_100 ? + "100Mb/s" : + (reg & E1000_STATUS_SPEED_MASK) == E1000_STATUS_SPEED_1000 ? + "1000Mb/s" : "not used", + "PCI-Express", + (reg & E1000_STATUS_FUNC_MASK) == 0 ? "0" : "1"); + } + else if(mac_type >= e1000_82543) { fprintf(stdout, " TBI mode: %s\n" " Link speed: %s\n" @@ -431,7 +461,9 @@ /* PHY type */ fprintf(stdout, "PHY type: %s\n", - regs_buff[12] == 0 ? "M88" : "IGP"); + regs_buff[12] == 0 ? "M88" : + regs_buff[12] == 1 ? "IGP" : + regs_buff[12] == 2 ? "IGP2" : "unknown" ); return 0; } From rocombs@hongkong.cs.nmsu.edu Fri May 6 21:11:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 21:11:05 -0700 (PDT) Received: from hongkong.cs.nmsu.edu ([128.123.64.160]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j474B1Ov009458 for ; Fri, 6 May 2005 21:11:02 -0700 Received: from hongkong.cs.nmsu.edu (IDENT:1236@localhost [127.0.0.1]) by hongkong.cs.nmsu.edu (8.12.11/8.12.11) with ESMTP id j474Ah63031928; Fri, 6 May 2005 22:10:43 -0600 Received: (from rocombs@localhost) by hongkong.cs.nmsu.edu (8.12.11/8.12.11/Submit) id j474Abb5031927; Fri, 6 May 2005 23:10:37 -0500 From: Ross Combs Date: Fri, 06 May 2005 23:10:37 -0500 To: achirica@ttd.net Cc: netdev@oss.sgi.com Subject: Small 2.6.11.8 airo.c issue Message-ID: <427C3FBD.mailOLE1FRMAW@hongkong> User-Agent: nail 10.7 3/19/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rocombs@cs.nmsu.edu Precedence: bulk X-list: netdev Content-Length: 1323 Lines: 31 I ran into a small configuration problem a couple of days ago while using menuconfig to setup a new kernel for my laptop. Basically, it refused to show the airo.c driver as an option. After looking at the Kconfig files I figured out it was because I did not have ISA enabled -- but I'm not using an ISA version of the card so it should not be a dependency. I originally reported it to Jean Tourrilhes but he said that netdev would be a better place to send it and that Javier might know why it was added. My original message is included below. > I just upgraded my system to a recent 2.6 kernel and noticed a small > bug in the configuration for the airo.c driver. It now requires > that ISA be enabled, though it is not a requirement for all hardware > using that driver. In my case, I'm using an IBM T30 laptop with a > mini-PCI card. > > Once I edited the Kconfig file to remove the ISA dependency (maybe it > should be an OR instead of an AND but removing it was easier for a > local change), I was able to select the driver. It compiled without > problems and I'm using it successfully with encryption for the first > time ever. > > I'm very happy with the new driver. > > Please let me know if this is not the right place to report bugs. I > just mailed the people listed in the source code. Thanks, -Ross From leonid.grossman@neterion.com Fri May 6 21:56:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 May 2005 21:56:47 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j474ugOv011084 for ; Fri, 6 May 2005 21:56:43 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j474mrOC017718; Sat, 7 May 2005 00:48:54 -0400 (EDT) Received: from lgt40 ([10.16.16.169]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j474mqVG021788; Sat, 7 May 2005 00:48:53 -0400 (EDT) Message-Id: <200505070448.j474mqVG021788@guinness.s2io.com> From: "Leonid Grossman" To: "'David S. Miller'" Cc: Subject: RE: [PATCH] TSO Reloaded Date: Fri, 6 May 2005 21:48:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050506123411.7073cf15.davem@davemloft.net> Thread-Index: AcVSdHo2woDDlpkYTrWg0+38qblb+gAR+m6Q X-Scanned-By: MIMEDefang 2.34 X-archive-position: 906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 2099 Lines: 59 > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > Behalf Of David S. Miller > Sent: Friday, May 06, 2005 12:34 PM > To: Leonid Grossman > Cc: netdev@oss.sgi.com > Subject: Re: [PATCH] TSO Reloaded > > On Fri, 6 May 2005 07:09:17 -0700 > "Leonid Grossman" wrote: > > > Our ASIC supports ipv6 CSUM and TSO (and header splitting) even if > extension > > headers are present, but I suspect the majority ipv6-capable NICs will > not > > implement this; the stack needs to query NIC header-processing > capabilities > > (for both CSUM and TSO) and act accordingly. > > Any particular reason for adding protocol specific checksumming > instead of a protocol agnostic one? That is what NETIF_F_CSUM_HW > represents, and we were hoping NIC vendors would do. I guess some NIC vendors choose to support a single pass/fail flag (rather than a 16-bit checksum field), because increasing the size of receive descriptors may not come for free. Our older card supports NETIF_F_IP_CSUM only, the newer card can support NETIF_F_HW_CSUM so we will probably change the driver at some point. > > If you supported this, then you wouldn't need to keep adding checksum > support for new protocols, NETIF_F_CSUM_HW works for anything which > uses a 16-bit 2's complement checksum stuffed to an arbitray 16-bit > location. The chip merely needs to: > > 1) calculate a 2's complement sum starting at the offset: > (skb->h.raw - skb->data) > into the packet, to the end. > 2) Place the 16-bit result at offset: > (skb->h.raw + skb->csum) - skb->data > > and that's it. This single checksumming engine works for ipv4 as well. > > See drivers/net/sunhme.c:happy_meal_start_xmit() and drivers/net/sungem.c: > gem_start_xmit() for two example implementations. Thanks for the pointer! Leonid > > I can't belive Sun understood this years ago and yet they are pretty > much the only vendor who has made networking cards supporting this > scheme. Probably the Microsoft's NDIS driver specification is to blame :- > / From herbert@gondor.apana.org.au Sat May 7 03:55:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 03:55:35 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47AtUOv030356 for ; Sat, 7 May 2005 03:55:31 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DUMxc-0002Lo-00; Sat, 07 May 2005 20:55:04 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DUMxY-0005I0-00; Sat, 07 May 2005 20:55:00 +1000 Date: Sat, 7 May 2005 20:55:00 +1000 To: jamal Cc: "David S. Miller" , netdev Subject: Re: resend patch: xfrm policybyid Message-ID: <20050507105500.GA20283@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> <20050506085404.GA26719@gondor.apana.org.au> <1115380381.7660.123.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115380381.7660.123.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1724 Lines: 48 On Fri, May 06, 2005 at 07:53:00AM -0400, jamal wrote: > > You are a reasonable man, so i am hoping you will end agreeing > or agreeing to disagree;-> If it weren't for the fact that the only way of achieving what you want here is through ugly code then I wouldn't have any problems with it at all. > > There should only be one key that the > > user gets to set when adding policies that is guaranteed to be unique. > > As it is it's the selector. > > Note: The index was already guaranteed to be unique even without my > patch. The difference is that the uniqueness is easy when we (the kernel) are the only ones setting it. Once you let the user choose the value for index, that's where the horror starts. > Just to make sure we are not speaking past each other: > A key is a column in a table that can be uniquely used to identify said > row. Yep. > In this case actually the justification exists: The selector is needed > for data/packet path lookup key. The index for manager side > manageability. I have no argument with the existence of the index per se. What I am yet to be convinced of is the need for the user to set its value. > > However, I must say that I still have absolutely no idea why anyone > > would need to set the index to arbitrary values. > > But you do know why someone would want to search or delete by it, > right?;-> What difference does it make if you can set the value of index? What things can't I do if I have to use the index value given by the kernel? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Sat May 7 05:04:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 05:04:44 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47C4eOv005688 for ; Sat, 7 May 2005 05:04:41 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DUO2i-0003R3-0a for netdev@oss.sgi.com; Sat, 07 May 2005 08:04:24 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DUO2e-0005GJ-IU; Sat, 07 May 2005 08:04:20 -0400 Subject: Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev In-Reply-To: <20050507072349.GH5753@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050507071434.GA5716@gondor.apana.org.au> <20050507071824.GA5753@gondor.apana.org.au> <20050507071930.GC5753@gondor.apana.org.au> <20050507072058.GD5753@gondor.apana.org.au> <20050507072139.GE5753@gondor.apana.org.au> <20050507072216.GF5753@gondor.apana.org.au> <20050507072251.GG5753@gondor.apana.org.au> <20050507072349.GH5753@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Sat, 07 May 2005 08:04:16 -0400 Message-Id: <1115467457.19561.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 917 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 934 Lines: 26 On Sat, 2005-07-05 at 17:23 +1000, Herbert Xu wrote: > Hi: > > This patch changes the format of the XFRM_MSG_DELSA and > XFRM_MSG_DELPOLICY notification so that the main message > sent is of the same format as that received by the kernel > if the original message was via netlink. This also means > that we won't lose the byid information carried in km_event. > This is incosistent in two ways: 1) Typical netlink behavior is to return the object being deleted. Every other netlink user behaves that way - the only exception is sone filters in tc and this is because they cant retrieve that detail (something that needs resolution at some point). There is nothing that xfrm_usersa_id provides that can be found in xfrm_usersa_info. Same for the policy. 2) You cant have one behavior when something is deleted by pfkey and a different one when it is deleted by netlink. So i would recommend pulling this one out. cheers, jamal From hadi@cyberus.ca Sat May 7 05:11:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 05:11:04 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47CB0Ov006487 for ; Sat, 7 May 2005 05:11:01 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DUO8q-0004pa-Jj for netdev@oss.sgi.com; Sat, 07 May 2005 08:10:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DUO8o-00066e-MR; Sat, 07 May 2005 08:10:42 -0400 Subject: Re: [NET]: Avoid useless iterating in netlink dump functions From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: "David S. Miller" , Maillist netdev In-Reply-To: <427BE147.9080508@trash.net> References: <427B8FC3.4000305@trash.net> <1115413473.13922.38.camel@localhost.localdomain> <427BDDD4.1000808@trash.net> <1115414222.13922.41.camel@localhost.localdomain> <427BE147.9080508@trash.net> Content-Type: text/plain Organization: unknown Date: Sat, 07 May 2005 08:10:39 -0400 Message-Id: <1115467839.19561.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1024 Lines: 29 On Fri, 2005-06-05 at 23:27 +0200, Patrick McHardy wrote: > jamal wrote: > > On Fri, 2005-06-05 at 23:12 +0200, Patrick McHardy wrote: > > > >>action dumping is on my list for more treatment than this :) > > > > Well, that does sound scary ;-> What do you have in mind. > > Recall, there are two paths to dumping actions - unlike any other thing > > in the kernel. > > Don't worry :) Its actually action walking that is on my list. > What I have planed is roughly: > - clean up and move hashing functions to act_common.c > - put data needed for hashing (size, pointer to memory, ...) in > struct tc_act_common, which is referenced by struct tc_action_ops > - add callback based walking function so we don't need two of them > > This should also get rid of all the large functions contained in > headerfiles. > Ah, ok ;-> Weve discussed this already - I think DaveM already took in the simple action patch that i posted a while back; it doesnt seem like you will collide with that - just double check. cheers, jamal From SRS0+0401f2181be033eb422d+622+infradead.org+arjan@pentafluge.srs.infradead.org Sat May 7 05:24:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 05:24:41 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47COcOv007814 for ; Sat, 7 May 2005 05:24:38 -0700 Received: from g133107.upc-g.chello.nl ([80.57.133.107] helo=[172.31.3.43]) by pentafluge.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1DUOLn-0005jj-22; Sat, 07 May 2005 13:24:09 +0100 Subject: Re: [2.6 patch] drivers/net/ixgb/: possible cleanups From: Arjan van de Ven To: Ganesh Venkatesan Cc: Adrian Bunk , ayyappan.veeraiyan@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <5fc59ff3050506153523cd12dd@mail.gmail.com> References: <20050506211834.GM3590@stusta.de> <5fc59ff3050506153523cd12dd@mail.gmail.com> Content-Type: text/plain Date: Sat, 07 May 2005 14:24:04 +0200 Message-Id: <1115468645.6388.37.camel@laptopd505.fenrus.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arjan@infradead.org Precedence: bulk X-list: netdev Content-Length: 661 Lines: 17 On Fri, 2005-05-06 at 15:35 -0700, Ganesh Venkatesan wrote: > Adrian: > > Some of your suggestions are already part of the driver we are > currently testing. This was based partly on your Feb '05 patch. We > will not be able to apply your patch as is since some of the changes > are in part of code that is shared with other drivers that are not > GPLd. this sounds really bad. Can you talk to the intel people in the ACPI group, they had a similar issue before but were able to resolve it by a proper dual license comment. It would be much preferable if people CAN do changes to the entire driver... what's the point of having it open source otherwise ;) From herbert@gondor.apana.org.au Sat May 7 05:26:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 05:26:09 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47CQ0Ov008218 for ; Sat, 7 May 2005 05:26:03 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DUOMo-0002xt-00; Sat, 07 May 2005 22:25:10 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DUOMi-0005ed-00; Sat, 07 May 2005 22:25:04 +1000 Date: Sat, 7 May 2005 22:25:04 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev Subject: Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification Message-ID: <20050507122504.GA21693@gondor.apana.org.au> References: <20050409105452.GA7171@gondor.apana.org.au> <20050507071434.GA5716@gondor.apana.org.au> <20050507071824.GA5753@gondor.apana.org.au> <20050507071930.GC5753@gondor.apana.org.au> <20050507072058.GD5753@gondor.apana.org.au> <20050507072139.GE5753@gondor.apana.org.au> <20050507072216.GF5753@gondor.apana.org.au> <20050507072251.GG5753@gondor.apana.org.au> <20050507072349.GH5753@gondor.apana.org.au> <1115467457.19561.5.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115467457.19561.5.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1137 Lines: 28 On Sat, May 07, 2005 at 08:04:16AM -0400, jamal wrote: > > This is incosistent in two ways: > 1) Typical netlink behavior is to return the object being deleted. > Every other netlink user behaves that way - the only exception is sone > filters in tc and this is because they cant retrieve that detail > (something that needs resolution at some point). There is nothing that > xfrm_usersa_id provides that can be found in xfrm_usersa_info. > Same for the policy. This analogy is flawed since unlike other rtnetlink delete operations the xfrm delete operations do not carry the same payload type as their add/update cousins. > 2) You cant have one behavior when something is deleted by pfkey and a > different one when it is deleted by netlink. As far as I can see the behaviour is identical. > So i would recommend pulling this one out. Well I don't really have time to get into another debate so I'll chuck this one out. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bunk@stusta.de Sat May 7 05:38:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 05:38:52 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j47CcmOv009379 for ; Sat, 7 May 2005 05:38:49 -0700 Received: (qmail 26345 invoked from network); 7 May 2005 12:38:29 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 7 May 2005 12:38:29 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 291ECBB9CE; Sat, 7 May 2005 14:38:20 +0200 (CEST) Date: Sat, 7 May 2005 14:38:17 +0200 From: Adrian Bunk To: Arjan van de Ven Cc: Ganesh Venkatesan , ayyappan.veeraiyan@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] drivers/net/ixgb/: possible cleanups Message-ID: <20050507123814.GJ3590@stusta.de> References: <20050506211834.GM3590@stusta.de> <5fc59ff3050506153523cd12dd@mail.gmail.com> <1115468645.6388.37.camel@laptopd505.fenrus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115468645.6388.37.camel@laptopd505.fenrus.org> User-Agent: Mutt/1.5.9i X-archive-position: 922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1181 Lines: 31 On Sat, May 07, 2005 at 02:24:04PM +0200, Arjan van de Ven wrote: > On Fri, 2005-05-06 at 15:35 -0700, Ganesh Venkatesan wrote: > > Adrian: > > > > Some of your suggestions are already part of the driver we are > > currently testing. This was based partly on your Feb '05 patch. We > > will not be able to apply your patch as is since some of the changes > > are in part of code that is shared with other drivers that are not > > GPLd. > > this sounds really bad. > > Can you talk to the intel people in the ACPI group, they had a similar > issue before but were able to resolve it by a proper dual license > comment. It would be much preferable if people CAN do changes to the > entire driver... what's the point of having it open source otherwise ;) I'm not sure whether Ganesh was really talking about license issues, or whether the problem is that my patch #if 0's away code they use in other non-GPL'ed drivers. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From hadi@cyberus.ca Sat May 7 05:38:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 05:38:42 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47CceOv009361 for ; Sat, 7 May 2005 05:38:40 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DUOZW-0006Qu-5O for netdev@oss.sgi.com; Sat, 07 May 2005 06:38:18 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DUOZX-0002bt-Cv; Sat, 07 May 2005 08:38:19 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev In-Reply-To: <20050507105500.GA20283@gondor.apana.org.au> References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> <20050506085404.GA26719@gondor.apana.org.au> <1115380381.7660.123.camel@localhost.localdomain> <20050507105500.GA20283@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Sat, 07 May 2005 08:38:16 -0400 Message-Id: <1115469496.19561.41.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 921 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2339 Lines: 57 On Sat, 2005-07-05 at 20:55 +1000, Herbert Xu wrote: > On Fri, May 06, 2005 at 07:53:00AM -0400, jamal wrote: > > > > You are a reasonable man, so i am hoping you will end agreeing > > or agreeing to disagree;-> > > If it weren't for the fact that the only way of achieving what you > want here is through ugly code then I wouldn't have any problems with > it at all. > Rewrite it Herbert ;-> I have no qualms as long as the feature is available. I even promised not to harass you ;-> > > Note: The index was already guaranteed to be unique even without my > > patch. > > The difference is that the uniqueness is easy when we (the kernel) are > the only ones setting it. Once you let the user choose the value for > index, that's where the horror starts. > But the uniqueness is still maintained. Nothing changes there. > this case actually the justification exists: The selector is needed > > for data/packet path lookup key. The index for manager side > > manageability. > > I have no argument with the existence of the index per se. What I am > yet to be convinced of is the need for the user to set its value. As i said in the last email, a lot of known management apps out there typically deal with row indices when managing tables: examples include SNMP, COPS, etc - and i am not sure how Racoon or pluto store their policies but they would be a good fit as well. If you can specify what indices get used, then you can do some fast lookups when need to (because you specify then based on how things are laid out in your current tables). This is the way things are - i am not trying to innovate anything here. How fast you add or delete these rules is a performance metric that affects your setup/teardown rates. Theres also another use of being able to use indices: HA synchronization in active/backup. If the manager wants to make sure the active and backup are exactly the same and it(the manager) maintains less amount of data it will ensure that both nodes have exactly the same indices as well for the same policy. Having said the above, the SAD as well oughta have an index; infact one exists (the reqid) but is quiet bizzare. I dont wanna touch the SAD, yet ;-> not for the next few months until we talk at netconf probably. Actually this is a digression, so just ignore i said it ;-> cheers, jamal From SRS0+4df647460b6a33999899+622+infradead.org+hch@pentafluge.srs.infradead.org Sat May 7 05:41:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 05:41:07 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47Cf4Ov010185 for ; Sat, 7 May 2005 05:41:04 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DUObp-0005no-Tx; Sat, 07 May 2005 13:40:41 +0100 Date: Sat, 7 May 2005 13:40:41 +0100 From: Christoph Hellwig To: Ganesh Venkatesan Cc: Adrian Bunk , ayyappan.veeraiyan@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] drivers/net/ixgb/: possible cleanups Message-ID: <20050507124041.GA22088@infradead.org> Mail-Followup-To: Christoph Hellwig , Ganesh Venkatesan , Adrian Bunk , ayyappan.veeraiyan@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050506211834.GM3590@stusta.de> <5fc59ff3050506153523cd12dd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fc59ff3050506153523cd12dd@mail.gmail.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 923 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 461 Lines: 12 On Fri, May 06, 2005 at 03:35:52PM -0700, Ganesh Venkatesan wrote: > Adrian: > > Some of your suggestions are already part of the driver we are > currently testing. This was based partly on your Feb '05 patch. We > will not be able to apply your patch as is since some of the changes > are in part of code that is shared with other drivers that are not > GPLd. I don't think Adrian can claim copyright on code removal even if he wanted to (which I doubt :)) From hadi@cyberus.ca Sat May 7 05:47:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 05:47:13 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47Cl6Ov011096 for ; Sat, 7 May 2005 05:47:07 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DUOhj-0007Yv-9D for netdev@oss.sgi.com; Sat, 07 May 2005 06:46:47 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DUOhj-0004OJ-Me; Sat, 07 May 2005 08:46:47 -0400 Subject: Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev In-Reply-To: <20050507122504.GA21693@gondor.apana.org.au> References: <20050409105452.GA7171@gondor.apana.org.au> <20050507071434.GA5716@gondor.apana.org.au> <20050507071824.GA5753@gondor.apana.org.au> <20050507071930.GC5753@gondor.apana.org.au> <20050507072058.GD5753@gondor.apana.org.au> <20050507072139.GE5753@gondor.apana.org.au> <20050507072216.GF5753@gondor.apana.org.au> <20050507072251.GG5753@gondor.apana.org.au> <20050507072349.GH5753@gondor.apana.org.au> <1115467457.19561.5.camel@localhost.localdomain> <20050507122504.GA21693@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Sat, 07 May 2005 08:46:44 -0400 Message-Id: <1115470004.19561.49.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 924 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1538 Lines: 43 On Sat, 2005-07-05 at 22:25 +1000, Herbert Xu wrote: > On Sat, May 07, 2005 at 08:04:16AM -0400, jamal wrote: > > > > This is incosistent in two ways: > > 1) Typical netlink behavior is to return the object being deleted. > > Every other netlink user behaves that way - the only exception is sone > > filters in tc and this is because they cant retrieve that detail > > (something that needs resolution at some point). There is nothing that > > xfrm_usersa_id provides that can be found in xfrm_usersa_info. > > Same for the policy. > > This analogy is flawed since unlike other rtnetlink delete operations > the xfrm delete operations do not carry the same payload type as their > add/update cousins. > No, this is not true. Study the tc code. It is nice to be able to return exactly the same detail - user space can then infer what exactly happened. It is nicer to be able to return more detail because user space doesnt have to infer anything. > > 2) You cant have one behavior when something is deleted by pfkey and a > > different one when it is deleted by netlink. > > As far as I can see the behaviour is identical. > If this is true, then #1 is forgivable. This was my main concern. You describe the patch this way --- This patch changes the format of the XFRM_MSG_DELSA and XFRM_MSG_DELPOLICY notification so that the main message sent is of the same format as that received by the kernel if the original message was via netlink. ---- That it only happens when you delete via netlink. Is this not so? cheers, jamal From hadi@znyx.com Sat May 7 06:03:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 06:03:34 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47D3TOv012226 for ; Sat, 7 May 2005 06:03:30 -0700 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050706061379:428 ; Sat, 7 May 2005 06:06:13 -0700 Subject: Re: [RFC] textsearch infrastructure + skb_find_text() From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Thomas Graf Cc: netdev@oss.sgi.com, Pablo Neira In-Reply-To: <20050506144308.GF28419@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> <427A51A2.8090600@eurodev.net> <20050505174224.GB25977@postel.suug.ch> <427AC96E.2020208@eurodev.net> <20050506123639.GE28419@postel.suug.ch> <1115384649.7660.140.camel@localhost.localdomain> <20050506144308.GF28419@postel.suug.ch> Organization: ZNYX Networks Date: Sat, 07 May 2005 09:03:04 -0400 Message-Id: <1115470985.19561.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/07/2005 06:06:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/07/2005 06:06:18 AM, Serialize complete at 05/07/2005 06:06:18 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 925 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 1860 Lines: 47 On Fri, 2005-06-05 at 16:43 +0200, Thomas Graf wrote: > As you can see, it expects a char * in args[0] and the length of it > in args[1]. All it does is check whether all bytes have been read > already and if not return the remaining part of the buffer so even > if the search algorithm can't consume all the bytes returned it will > still work as expected. > Ok, makes sense - in the case of a string spanning multi skbs, i suppose it wouldnt matter, correct? [..] > Not sure if this is clear out of context but maybe it gives you an idea > why it is easier to maintain state of get_text() rather than the state > of a whole searching algorithm. > I got it. I suppose in the case of text contained within one skb this would be an improvement (spanning across multi-skb should be no difference; an improvemengt nonetheless) > > > > I am trying to sink this in; prefetching would be valuable for regexp, > > but why would the other scheme not be able to do it? > > I'm really not an expert on the validity of L1 caches and how to optimize > it best but I believe that the less memory movement is in between the > more likely prefetching helps? Both schemes involve a switch to another > stack namespace but get_text() tends to be a lot smaller and less intrusive > than a store & reload of a complex state machine. I really can't tell > which is better regarding this subject without trying it out actually. > Sorry - I thought you were talking about pre-fetching text as in lookahead for text in a regexp state machine. I am not sure i see the L1 cache connection. Both seem to have tight for loops and depending on the algorithm there would be no difference in cache warmth afaics. Infact your scheme may suffer more because it has a lot of stuff on the stack. However, playing around with the code is the only way to find out. cheers, jamal From SRS0+0401f2181be033eb422d+622+infradead.org+arjan@pentafluge.srs.infradead.org Sat May 7 06:09:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 06:09:36 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47D9XOv012897 for ; Sat, 7 May 2005 06:09:34 -0700 Received: from g133107.upc-g.chello.nl ([80.57.133.107] helo=[172.31.3.43]) by pentafluge.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1DUP3H-0005sw-LI; Sat, 07 May 2005 14:09:04 +0100 Subject: Re: [2.6 patch] drivers/net/ixgb/: possible cleanups From: Arjan van de Ven To: Adrian Bunk Cc: Ganesh Venkatesan , ayyappan.veeraiyan@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20050507123814.GJ3590@stusta.de> References: <20050506211834.GM3590@stusta.de> <5fc59ff3050506153523cd12dd@mail.gmail.com> <1115468645.6388.37.camel@laptopd505.fenrus.org> <20050507123814.GJ3590@stusta.de> Content-Type: text/plain Date: Sat, 07 May 2005 15:09:01 +0200 Message-Id: <1115471341.6388.41.camel@laptopd505.fenrus.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 926 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arjan@infradead.org Precedence: bulk X-list: netdev Content-Length: 280 Lines: 9 > I'm not sure whether Ganesh was really talking about license issues, or > whether the problem is that my patch #if 0's away code they use in other > non-GPL'ed drivers. fair point, the solution for the later could be to use #ifndef __linux__ or something instead of #if 0 From kaber@trash.net Sat May 7 07:52:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 07:52:46 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47EqeOv017133 for ; Sat, 7 May 2005 07:52:40 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DUQeU-0007Zd-0I; Sat, 07 May 2005 16:51:34 +0200 Message-ID: <427CD5F5.9010605@trash.net> Date: Sat, 07 May 2005 16:51:33 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , Masahide NAKAMURA , jamal , netdev Subject: Re: [1/7] [IPSEC] Add complete xfrm event notification References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050507071434.GA5716@gondor.apana.org.au> <20050507071824.GA5753@gondor.apana.org.au> In-Reply-To: <20050507071824.GA5753@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------080705010204000004010703" X-archive-position: 927 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2523 Lines: 86 This is a multi-part message in MIME format. --------------080705010204000004010703 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Herbert Xu wrote: > @@ -1254,6 +1326,7 @@ static int pfkey_add(struct sock *sk, st > if (IS_ERR(x)) > return PTR_ERR(x); > > + xfrm_state_hold(x); This introduces a leak when xfrm_state_add()/xfrm_state_update() fail. We hold two references (one from xfrm_state_alloc(), one from xfrm_state_hold()), but only drop one. We need to take the reference because the reference from xfrm_state_alloc() can be dropped by __xfrm_state_delete(), so the fix is to drop both references on error. Same problem in xfrm_user.c. --------------080705010204000004010703 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" [XFRM]: Fix xfrm_state leaks in error path Signed-off-by: Patrick McHardy --- commit a4222e4b4f4fe6a28204e7960972ef833ac0c4ce tree c24f26cfe03081d10a3a3f66d5d3e503395090b4 parent 16efae13731912e8cd028a85257fb33726318770 author Patrick McHardy 1115477180 +0200 committer Patrick McHardy 1115477180 +0200 Index: net/key/af_key.c =================================================================== --- 6c0df7e8f613031668cf54aec5735e8b9f76aaa9/net/key/af_key.c (mode:100644 sha1:577f0bb5bb31816bb1ecf94848ae2758d9c2cbcf) +++ c24f26cfe03081d10a3a3f66d5d3e503395090b4/net/key/af_key.c (mode:100644 sha1:98b72f2024ffd84564530e5973861b908fd8f541) @@ -1333,7 +1333,7 @@ if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); - return err; + goto out; } if (hdr->sadb_msg_type == SADB_ADD) @@ -1343,8 +1343,8 @@ c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; km_state_notify(x, &c); +out: xfrm_state_put(x); - return err; } Index: net/xfrm/xfrm_user.c =================================================================== --- 6c0df7e8f613031668cf54aec5735e8b9f76aaa9/net/xfrm/xfrm_user.c (mode:100644 sha1:6c8c6d6924939fe30264caab9f6fca943cf70e3b) +++ c24f26cfe03081d10a3a3f66d5d3e503395090b4/net/xfrm/xfrm_user.c (mode:100644 sha1:4f37b4f2ea8a238b8ae5f97496b727df7489d5fb) @@ -287,7 +287,7 @@ if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); - return err; + goto out; } c.seq = nlh->nlmsg_seq; @@ -295,8 +295,8 @@ c.event = nlh->nlmsg_type; km_state_notify(x, &c); +out: xfrm_state_put(x); - return err; } --------------080705010204000004010703-- From chas@cmf.nrl.navy.mil Sat May 7 10:16:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 10:16:32 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47HGNOv025549 for ; Sat, 7 May 2005 10:16:23 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j47HFrbp016006; Sat, 7 May 2005 13:15:55 -0400 (EDT) Message-Id: <200505071715.j47HFrbp016006@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com, Roman Kagan Subject: [PATCH 1/1][ATM]: net/atm/ioctl.c: autoload pppoatm and br2684 Date: Sat, 07 May 2005 13:15:54 -0400 From: "chas williams - CONTRACTOR" X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 928 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1621 Lines: 64 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/05/07 09:15:32-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: net/atm/ioctl.c: autoload pppoatm and br2684 # # Signed-off-by: Roman Kagan # Signed-off-by: Chas Williams # # net/atm/ioctl.c # 2005/05/07 09:15:12-04:00 chas@relax.cmf.nrl.navy.mil +26 -8 # [ATM]: net/atm/ioctl.c: autoload pppoatm and br2684 # # Signed-off-by: Roman Kagan # Signed-off-by: Chas Williams # diff -Nru a/net/atm/ioctl.c b/net/atm/ioctl.c --- a/net/atm/ioctl.c 2005-05-07 09:16:19 -04:00 +++ b/net/atm/ioctl.c 2005-05-07 09:16:19 -04:00 @@ -104,16 +104,34 @@ if (!error) sock->state = SS_CONNECTED; goto done; - default: + case ATM_SETBACKEND: + case ATM_NEWBACKENDIF: + { + atm_backend_t backend; + error = get_user(backend, (atm_backend_t __user *) argp); + if (error) + goto done; + switch (backend) { + case ATM_BACKEND_PPP: + request_module("pppoatm"); + break; + case ATM_BACKEND_BR2684: + request_module("br2684"); + break; + } + } + break; + case ATMMPC_CTRL: + case ATMMPC_DATA: + request_module("mpoa"); + break; + case ATMARPD_CTRL: + request_module("clip"); + break; + case ATMLEC_CTRL: + request_module("lec"); break; } - - if (cmd == ATMMPC_CTRL || cmd == ATMMPC_DATA) - request_module("mpoa"); - if (cmd == ATMARPD_CTRL) - request_module("clip"); - if (cmd == ATMLEC_CTRL) - request_module("lec"); error = -ENOIOCTLCMD; From herbert@gondor.apana.org.au Sat May 7 12:36:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 12:36:34 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47JaQOv001399 for ; Sat, 7 May 2005 12:36:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DUV5U-0005YD-00; Sun, 08 May 2005 05:35:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DUV5O-0007Z7-00; Sun, 08 May 2005 05:35:38 +1000 Date: Sun, 8 May 2005 05:35:38 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev Subject: Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification Message-ID: <20050507193538.GA28991@gondor.apana.org.au> References: <20050507071824.GA5753@gondor.apana.org.au> <20050507071930.GC5753@gondor.apana.org.au> <20050507072058.GD5753@gondor.apana.org.au> <20050507072139.GE5753@gondor.apana.org.au> <20050507072216.GF5753@gondor.apana.org.au> <20050507072251.GG5753@gondor.apana.org.au> <20050507072349.GH5753@gondor.apana.org.au> <1115467457.19561.5.camel@localhost.localdomain> <20050507122504.GA21693@gondor.apana.org.au> <1115470004.19561.49.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115470004.19561.49.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 929 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1509 Lines: 40 On Sat, May 07, 2005 at 08:46:44AM -0400, jamal wrote: > > No, this is not true. Study the tc code. > It is nice to be able to return exactly the same detail - user space can > then infer what exactly happened. It is nicer to be able to return more > detail because user space doesnt have to infer anything. This patch is making it return more detail, not less! The full description of the deleted policy/state is still being returned, albeit as RTA payloads. Prior to the change, netlink users do not know whether the original policy delete request was by selector or by id. Now that information is also returned. > You describe the patch this way > > --- > This patch changes the format of the XFRM_MSG_DELSA and > XFRM_MSG_DELPOLICY notification so that the main message > sent is of the same format as that received by the kernel > if the original message was via netlink. > ---- > > That it only happens when you delete via netlink. Is this not so? The same change applies even if you sent the delete via pfkey. What the change does is to make netlink always send a delete message that is valid in the sense that if you sent it back to netlink then it would delete that policy/state. As it is the netlink delete messages sent by notification are invalid by its own standard. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat May 7 12:43:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 May 2005 12:43:25 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j47JhJOv001976 for ; Sat, 7 May 2005 12:43:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DUVCI-0005Zr-00; Sun, 08 May 2005 05:42:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DUVCG-0007a4-00; Sun, 08 May 2005 05:42:44 +1000 Date: Sun, 8 May 2005 05:42:44 +1000 To: Patrick McHardy Cc: "David S. Miller" , Masahide NAKAMURA , jamal , netdev Subject: Re: [1/7] [IPSEC] Add complete xfrm event notification Message-ID: <20050507194244.GB28991@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050507071434.GA5716@gondor.apana.org.au> <20050507071824.GA5753@gondor.apana.org.au> <427CD5F5.9010605@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427CD5F5.9010605@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 930 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 706 Lines: 15 On Sat, May 07, 2005 at 04:51:33PM +0200, Patrick McHardy wrote: > > This introduces a leak when xfrm_state_add()/xfrm_state_update() > fail. We hold two references (one from xfrm_state_alloc(), one > from xfrm_state_hold()), but only drop one. We need to take the > reference because the reference from xfrm_state_alloc() can > be dropped by __xfrm_state_delete(), so the fix is to drop both > references on error. Same problem in xfrm_user.c. Patch applied. Thanks for plugging the leaks :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun May 8 01:08:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 01:08:22 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4888DOv003306 for ; Sun, 8 May 2005 01:08:14 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DUgpA-0000fL-00; Sun, 08 May 2005 18:07:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DUgp0-0002rB-00; Sun, 08 May 2005 18:07:30 +1000 Date: Sun, 8 May 2005 18:07:30 +1000 To: jamal Cc: "David S. Miller" , netdev Subject: Re: resend patch: xfrm policybyid Message-ID: <20050508080730.GA30512@gondor.apana.org.au> References: <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> <20050506085404.GA26719@gondor.apana.org.au> <1115380381.7660.123.camel@localhost.localdomain> <20050507105500.GA20283@gondor.apana.org.au> <1115469496.19561.41.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115469496.19561.41.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 932 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2677 Lines: 58 On Sat, May 07, 2005 at 08:38:16AM -0400, jamal wrote: > > Rewrite it Herbert ;-> I have no qualms as long as the feature is > available. I even promised not to harass you ;-> Sorry, I can't think of any good ways to implement what you want. > > The difference is that the uniqueness is easy when we (the kernel) are > > the only ones setting it. Once you let the user choose the value for > > index, that's where the horror starts. > > But the uniqueness is still maintained. Nothing changes there. The difference is that we now have to guarantee the uniqueness of two unrelated fields during insertion: the index as well as the selector. This is where the complexity of your patch comes from. > As i said in the last email, a lot of known management apps out there > typically deal with row indices when managing tables: examples include > SNMP, COPS, etc - and i am not sure how Racoon or pluto store their > policies but they would be a good fit as well. > If you can specify what indices get used, then you can do some fast > lookups when need to (because you specify then based on how things are > laid out in your current tables). This is the way things are - i am not > trying to innovate anything here. > How fast you add or delete these rules is a performance metric that > affects your setup/teardown rates. I'm afraid I don't buy this. The policies are not stored in a linear random-access data structure. So setting the index doesn't help performance one tiny bit. In future it'll probably become a hash table or a tree, in neither case will there be a linear index that could be used to determine insertion/deletion. > Theres also another use of being able to use indices: HA > synchronization in active/backup. If the manager wants to make sure the > active and backup are exactly the same and it(the manager) maintains > less amount of data it will ensure that both nodes have exactly the same > indices as well for the same policy. Please elaborate by giving an example of how the index is actually used. Sorry, but as it is I'm too thick to see your point :) > Having said the above, the SAD as well oughta have an index; infact one > exists (the reqid) but is quiet bizzare. I dont wanna touch the SAD, > yet ;-> not for the next few months until we talk at netconf probably. The reqid is definitely not an index. In fact it is not unique at all. It's a way of condensing all the fields in a SA template into one u32. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From pravin.shelar@gmail.com Sun May 8 04:37:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 04:37:54 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48BbnOv013216 for ; Sun, 8 May 2005 04:37:49 -0700 Received: by rproxy.gmail.com with SMTP id 40so150912rnz for ; Sun, 08 May 2005 04:37:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type; b=MK5fPMYIhKCp2pMnxANtc+hsm37+SwA5BoBX/DrcIl0NOlcX/7mp2zvmxZs7C4BoCwXi5eGF67sPxjqT0Lc3X9TT1/sYvpvHDQKEBKo61uX92jZ+10zu+f3cbT32NbCSD1FborIADJdJSjSsI6FPZLSyV6tft+ZTMxTCGWuIry4= Received: by 10.11.117.68 with SMTP id p68mr484590cwc; Sun, 08 May 2005 04:37:26 -0700 (PDT) Received: by 10.11.117.12 with HTTP; Sun, 8 May 2005 04:37:26 -0700 (PDT) Message-ID: Date: Sun, 8 May 2005 17:07:26 +0530 From: pravin Reply-To: pravin To: netdev@oss.sgi.com Subject: [PATCH] bug-fix in multipath_drr.c Cc: Einar Lueck , "David S. Miller" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_252_1849904.1115552246650" X-archive-position: 933 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pravin.shelar@gmail.com Precedence: bulk X-list: netdev Content-Length: 1446 Lines: 31 ------=_Part_252_1849904.1115552246650 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline hi This patch fixes a small bug in multipath-drr algorithm registration cod= e. In function drr_init :: multipath_alg_register(..) is called with wrong algorithm ID (AFAIU). Regards, Pravin. ------=_Part_252_1849904.1115552246650 Content-Type: text/x-patch; name="multipath_drr-algo-register-fix.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multipath_drr-algo-register-fix.patch" U2lnbmVkLW9mZiBieTogUHJhdmluIEIuIFNoZWxhciA8cHJhdmluc0BjYWxzb2Z0aW5jLmNvbT4K VGhpcyBwYXRjaCBmaXhlcyBhIHNtYWxsIGJ1ZyBpbiBtdWx0aXBhdGhfZHJyIGFsZ29yaXRobSBy ZWdpc3RyYXRpb24gY29kZS4KCkluZGV4OiBsaW51eC0yLjYuMTItcmM0L25ldC9pcHY0L211bHRp cGF0aF9kcnIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBsaW51eC0yLjYuMTItcmM0Lm9yaWcvbmV0L2lwdjQv bXVsdGlwYXRoX2Ryci5jCTIwMDUtMDUtMDYgMjI6MjA6MzEuMDAwMDAwMDAwIC0wNzAwCisrKyBs aW51eC0yLjYuMTItcmM0L25ldC9pcHY0L211bHRpcGF0aF9kcnIuYwkyMDA1LTA1LTA4IDAzOjI0 OjAyLjAwMDAwMDAwMCAtMDcwMApAQCAtMjQ0LDcgKzI0NCw3IEBACiAJaWYgKGVycikKIAkJcmV0 dXJuIGVycjsKIAotCWVyciA9IG11bHRpcGF0aF9hbGdfcmVnaXN0ZXIoJmRycl9vcHMsIElQX01Q X0FMR19SUik7CisJZXJyID0gbXVsdGlwYXRoX2FsZ19yZWdpc3RlcigmZHJyX29wcywgSVBfTVBf QUxHX0RSUik7CiAJaWYgKGVycikKIAkJZ290byBmYWlsOwogCg== ------=_Part_252_1849904.1115552246650-- From tgraf@suug.ch Sun May 8 04:45:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 04:45:48 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48BjjOv013869 for ; Sun, 8 May 2005 04:45:45 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 41A911C0ED; Sun, 8 May 2005 13:45:39 +0200 (CEST) Date: Sun, 8 May 2005 13:45:39 +0200 From: Thomas Graf To: Jamal Hadi Salim Cc: netdev@oss.sgi.com, Pablo Neira Subject: Re: [RFC] textsearch infrastructure + skb_find_text() Message-ID: <20050508114539.GP28419@postel.suug.ch> References: <20050504234036.GH18452@postel.suug.ch> <427A51A2.8090600@eurodev.net> <20050505174224.GB25977@postel.suug.ch> <427AC96E.2020208@eurodev.net> <20050506123639.GE28419@postel.suug.ch> <1115384649.7660.140.camel@localhost.localdomain> <20050506144308.GF28419@postel.suug.ch> <1115470985.19561.58.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115470985.19561.58.camel@localhost.localdomain> X-archive-position: 934 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1379 Lines: 28 * Jamal Hadi Salim <1115470985.19561.58.camel@localhost.localdomain> 2005-05-07 09:03 > On Fri, 2005-06-05 at 16:43 +0200, Thomas Graf wrote: > > > As you can see, it expects a char * in args[0] and the length of it > > in args[1]. All it does is check whether all bytes have been read > > already and if not return the remaining part of the buffer so even > > if the search algorithm can't consume all the bytes returned it will > > still work as expected. > > > > Ok, makes sense - in the case of a string spanning multi skbs, i suppose > it wouldnt matter, correct? Strings spanning multiple skbs can be handled just like a paged skbs _iff_ all skbs are known at the point the search starts, otherwise we'll need more trickering. > Sorry - I thought you were talking about pre-fetching text as in > lookahead for text in a regexp state machine. > I am not sure i see the L1 cache connection. Both seem to have tight for > loops and depending on the algorithm there would be no difference > in cache warmth afaics. Infact your scheme may suffer more because it > has a lot of stuff on the stack. However, playing around with the code > is the only way to find out. You're probably right, I suspect mine to perform better because in a typical search there is less work to do per loop and the interruption to fetch the next block of text is less intrusive. Time will tell. From tgraf@suug.ch Sun May 8 04:50:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 04:51:03 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48BoxOv014480 for ; Sun, 8 May 2005 04:50:59 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 832E01C0ED; Sun, 8 May 2005 13:51:00 +0200 (CEST) Date: Sun, 8 May 2005 13:51:00 +0200 From: Thomas Graf To: Patrick McHardy Cc: Asim Shankar , netdev@oss.sgi.com Subject: Re: SFQ: Reordering? Message-ID: <20050508115100.GQ28419@postel.suug.ch> References: <7bca1cb5050506145344d16b1e@mail.gmail.com> <427BEAAE.409@trash.net> <427BF3C4.1030105@trash.net> <20050506230203.GI28419@postel.suug.ch> <427BFB72.7080407@trash.net> <20050507005851.GK28419@postel.suug.ch> <427C19C3.5030304@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427C19C3.5030304@trash.net> X-archive-position: 935 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 901 Lines: 15 * Patrick McHardy <427C19C3.5030304@trash.net> 2005-05-07 03:28 > You stated my goal precisely :) I know many people set the interval > to too low values, but because of the tight limits, it shouldn't be > very expensive anyways. Table switching OTOH would introduce frequently > occuring unfairness, and the time to work through a full table is > a lot longer, especially in the environments where SFQ is used. I think you are right on this so forget about my thought. Maybe as an additional input it might be worth mentioning that I have patches ready to a) make the sfq depth adjustable and b) hash algorithm selection to a few builtin ones and additional to read theh hash from tc_classid set by an action. A real world example where this is useful is for routers primarly doing SNAT without any own local traffic where hashing algorithm primarly based on the source port makes a lot more sense. From hasso@estpak.ee Sun May 8 05:32:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 05:32:35 -0700 (PDT) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48CWCOv016132 for ; Sun, 8 May 2005 05:32:13 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DUkwH-0000s5-79; Sun, 08 May 2005 15:31:17 +0300 From: Hasso Tepper To: Harald Welte Subject: Re: primary and secondary ip addresses Date: Sun, 8 May 2005 15:31:15 +0300 User-Agent: KMail/1.8 Cc: jamal , Thomas Graf , Henrik Nordstrom , "David S. Miller" , Andrea G Forte , nhorman@redhat.com, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <1103550901.1050.292.camel@jzny.localdomain> <20050412105442.GV7510@sunbeam.de.gnumonks.org> In-Reply-To: <20050412105442.GV7510@sunbeam.de.gnumonks.org> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505081531.16106.hasso@estpak.ee> X-archive-position: 936 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 631 Lines: 21 Harald Welte wrote: > On Mon, Dec 20, 2004 at 08:55:02AM -0500, jamal wrote: > > > Didnt boot ;-> > > A small silly magic number i missed. Now boots - but doesnt mean it > > works. And i dont have much time to spare chasing it. > > Due to a customer having again trouble with this issue, I was forced to > actually spend some time testing it (and merging it to a current > kernel). At least in my simple tests, it worked like a charm :) I'm using it for some weeks in production and haven't noticed any issues either. Would be really good to see it kernel. regards, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From hadi@cyberus.ca Sun May 8 06:57:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 06:57:07 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48Dv4Ov019371 for ; Sun, 8 May 2005 06:57:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DUmH0-0003Gm-Rm for netdev@oss.sgi.com; Sun, 08 May 2005 09:56:46 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DUmGt-0007CM-CI; Sun, 08 May 2005 09:56:39 -0400 Subject: Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev In-Reply-To: <20050507193538.GA28991@gondor.apana.org.au> References: <20050507071824.GA5753@gondor.apana.org.au> <20050507071930.GC5753@gondor.apana.org.au> <20050507072058.GD5753@gondor.apana.org.au> <20050507072139.GE5753@gondor.apana.org.au> <20050507072216.GF5753@gondor.apana.org.au> <20050507072251.GG5753@gondor.apana.org.au> <20050507072349.GH5753@gondor.apana.org.au> <1115467457.19561.5.camel@localhost.localdomain> <20050507122504.GA21693@gondor.apana.org.au> <1115470004.19561.49.camel@localhost.localdomain> <20050507193538.GA28991@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Sun, 08 May 2005 09:56:33 -0400 Message-Id: <1115560594.19561.117.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 937 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2682 Lines: 68 On Sun, 2005-08-05 at 05:35 +1000, Herbert Xu wrote: > On Sat, May 07, 2005 at 08:46:44AM -0400, jamal wrote: > > > > No, this is not true. Study the tc code. > > It is nice to be able to return exactly the same detail - user space can > > then infer what exactly happened. It is nicer to be able to return more > > detail because user space doesnt have to infer anything. > > This patch is making it return more detail, not less! The full > description of the deleted policy/state is still being returned, > albeit as RTA payloads. It's the other extreme of what i thought. The only thing user space needs to know is what object was deleted. If you just passed the id, it could be deduced if user space maintained state; if you pass the object, no such deduction is needed. > Prior to the change, netlink users do not know whether the original > policy delete request was by selector or by id. Now that information > is also returned. > Why would someone need to deduce whether it has been deleted by index or selector? If you gave me the object - i can reproduce the action of deleting it. Thats the _only_ important_ thing. > > You describe the patch this way > > > > --- > > This patch changes the format of the XFRM_MSG_DELSA and > > XFRM_MSG_DELPOLICY notification so that the main message > > sent is of the same format as that received by the kernel > > if the original message was via netlink. > > ---- > > > > That it only happens when you delete via netlink. Is this not so? > > The same change applies even if you sent the delete via pfkey. What > the change does is to make netlink always send a delete message that > is valid in the sense that if you sent it back to netlink then it > would delete that policy/state. > Does pfkey have ability to delete by index and selector? If yes, how do you distinguish the two cases when you are sending the netlink event? > As it is the netlink delete messages sent by notification are invalid > by its own standard. > It doesnt seem to me what you provided in the patch produces exactly the same thing that was sent by user space back in the event. You introduce some other new TLVs to reflect it back. But even that is besides the point: None of those xfrm objects obey any of the standard rules netlink uses to begin with - you have more than one way of deleting an object. What you need to do is the detail of what object was deleted. Heres what i will say so we can put this to rest: The patch is unneeded (i hate to use strong words like bogus - but it is getting close to that), but if you feel strongly about it just lets have it well documented and provide the iproute2 patch as well. cheers, jamal From hadi@cyberus.ca Sun May 8 07:31:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 07:31:16 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48EVCOv020743 for ; Sun, 8 May 2005 07:31:13 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DUmny-0004Q7-6g for netdev@oss.sgi.com; Sun, 08 May 2005 10:30:50 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DUmnv-0003gd-Th; Sun, 08 May 2005 10:30:48 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev In-Reply-To: <20050508080730.GA30512@gondor.apana.org.au> References: <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> <20050506085404.GA26719@gondor.apana.org.au> <1115380381.7660.123.camel@localhost.localdomain> <20050507105500.GA20283@gondor.apana.org.au> <1115469496.19561.41.camel@localhost.localdomain> <20050508080730.GA30512@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Sun, 08 May 2005 10:30:43 -0400 Message-Id: <1115562643.19561.148.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 938 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2608 Lines: 66 On Sun, 2005-08-05 at 18:07 +1000, Herbert Xu wrote: > On Sat, May 07, 2005 at 08:38:16AM -0400, jamal wrote: > > > > Rewrite it Herbert ;-> I have no qualms as long as the feature is > > available. I even promised not to harass you ;-> > > Sorry, I can't think of any good ways to implement what you want. > There is really nothing in my (small) patch that you have pointed out that is unresolvable;-> You just dont like the idea, period. > > > The difference is that the uniqueness is easy when we (the kernel) are > > > the only ones setting it. Once you let the user choose the value for > > > index, that's where the horror starts. > > > > But the uniqueness is still maintained. Nothing changes there. > > The difference is that we now have to guarantee the uniqueness of > two unrelated fields during insertion: the index as well as the > selector. This is where the complexity of your patch comes from. Both the index and the selector MUST be unique, no question about that. What i did is introduce setting of the index - and that makes the checking do a little more. It would be worng not to do the checking. > I'm afraid I don't buy this. The policies are not stored in a > linear random-access data structure. So setting the index > doesn't help performance one tiny bit. > > In future it'll probably become a hash table or a tree, in neither > case will there be a linear index that could be used to determine > insertion/deletion. > I am talking about user space apps - not the kernel. Have you ever looked at IPSEC related MIBs and PIBs? or apps that implement those sorts of entities? I suspect you have not otherwise we would have closed this ages ago. > Please elaborate by giving an example of how the index is actually > used. Sorry, but as it is I'm too thick to see your point :) > I have given you enough info that i am concluding this is now becoming a debate for the sake of one;-> Sorry, Herbert, I strongly disagree with your views on this topic. This is one of those moments when it becomes obvious there can be no compromise. So I am hoping that someone following this discussion or writing management apps would speak up. > > Having said the above, the SAD as well oughta have an index; infact one > > exists (the reqid) but is quiet bizzare. I dont wanna touch the SAD, > > yet ;-> not for the next few months until we talk at netconf probably. > > The reqid is definitely not an index. In fact it is not unique at all. > It's a way of condensing all the fields in a SA template into one u32. > I dont wanna talk about this right now; cheers, jamal From kaber@trash.net Sun May 8 08:25:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 08:25:11 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48FP6Ov026203 for ; Sun, 8 May 2005 08:25:06 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DUndN-0001CJ-AD; Sun, 08 May 2005 17:23:57 +0200 Message-ID: <427E2F0D.4040902@trash.net> Date: Sun, 08 May 2005 17:23:57 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Herbert Xu , "David S. Miller" , netdev Subject: Re: resend patch: xfrm policybyid References: <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> <20050506085404.GA26719@gondor.apana.org.au> <1115380381.7660.123.camel@localhost.localdomain> <20050507105500.GA20283@gondor.apana.org.au> <1115469496.19561.41.camel@localhost.localdomain> <20050508080730.GA30512@gondor.apana.org.au> <1115562643.19561.148.camel@localhost.localdomain> In-Reply-To: <1115562643.19561.148.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 966 Lines: 28 jamal wrote: > On Sun, 2005-08-05 at 18:07 +1000, Herbert Xu wrote: > >>Please elaborate by giving an example of how the index is actually >>used. Sorry, but as it is I'm too thick to see your point :) > > I have given you enough info that i am concluding this is now becoming a > debate for the sake of one;-> > > Sorry, Herbert, I strongly disagree with your views on this topic. This > is one of those moments when it becomes obvious there can be no > compromise. So I am hoping that someone following this discussion or > writing management apps would speak up. Allowing the user to freely set indices breaks racoon: #ifdef __linux__ /* bsd skips over per-socket policies because there will be no * src and dst extensions in spddump messages. On Linux the only * way to achieve the same is check for policy id. */ if (xpl->sadb_x_policy_id % 8 >= 3) return 0; #endif So how could we handle this? Regards Patrick From kaber@trash.net Sun May 8 09:03:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 09:03:50 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48G3kOv027458 for ; Sun, 8 May 2005 09:03:46 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DUoFT-0001Gu-NY; Sun, 08 May 2005 18:03:19 +0200 Message-ID: <427E3847.3050709@trash.net> Date: Sun, 08 May 2005 18:03:19 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: Asim Shankar , netdev@oss.sgi.com Subject: Re: SFQ: Reordering? References: <7bca1cb5050506145344d16b1e@mail.gmail.com> <427BEAAE.409@trash.net> <427BF3C4.1030105@trash.net> <20050506230203.GI28419@postel.suug.ch> <427BFB72.7080407@trash.net> <20050507005851.GK28419@postel.suug.ch> <427C19C3.5030304@trash.net> <20050508115100.GQ28419@postel.suug.ch> In-Reply-To: <20050508115100.GQ28419@postel.suug.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 940 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1673 Lines: 37 Thomas Graf wrote: > * Patrick McHardy <427C19C3.5030304@trash.net> 2005-05-07 03:28 > >>You stated my goal precisely :) I know many people set the interval >>to too low values, but because of the tight limits, it shouldn't be >>very expensive anyways. Table switching OTOH would introduce frequently >>occuring unfairness, and the time to work through a full table is >>a lot longer, especially in the environments where SFQ is used. > > I think you are right on this so forget about my thought. Actually I was beginning to think you're right about having this feature optional. Paul McKenney's paper on SFQ states multiple times that perturbation can cause reordering if implemented the easy way, the Debian sfq manpage mentions this as well. So it appears to be a design-choice. Anyways, I suggest to make the decision when we know what the costs are. BTW, this is the URL for the paper: http://rdrop.com/users/paulmck/paper/sfq.2002.06.04.pdf > Maybe as > an additional input it might be worth mentioning that I have patches > ready to a) make the sfq depth adjustable and b) hash algorithm > selection to a few builtin ones and additional to read theh hash > from tc_classid set by an action. A real world example where this > is useful is for routers primarly doing SNAT without any own local > traffic where hashing algorithm primarly based on the source port > makes a lot more sense. I agree both make sense. Are you talking about run-time adjustable or compile-time adjustable? For SNAT it would also be nice to be able to use the original address, unfortunately this isn't possible anymore since we now drop the conntrack reference early. Regards Patrick From hadi@cyberus.ca Sun May 8 10:24:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 10:24:37 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48HOTOv030341 for ; Sun, 8 May 2005 10:24:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DUpVg-0004s4-R8 for netdev@oss.sgi.com; Sun, 08 May 2005 13:24:08 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DUpVb-0006CW-Rr; Sun, 08 May 2005 13:24:04 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Herbert Xu , "David S. Miller" , netdev In-Reply-To: <427E2F0D.4040902@trash.net> References: <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> <20050506085404.GA26719@gondor.apana.org.au> <1115380381.7660.123.camel@localhost.localdomain> <20050507105500.GA20283@gondor.apana.org.au> <1115469496.19561.41.camel@localhost.localdomain> <20050508080730.GA30512@gondor.apana.org.au> <1115562643.19561.148.camel@localhost.localdomain> <427E2F0D.4040902@trash.net> Content-Type: text/plain Organization: unknown Date: Sun, 08 May 2005 13:23:58 -0400 Message-Id: <1115573038.19561.174.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 941 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1264 Lines: 35 On Sun, 2005-08-05 at 17:23 +0200, Patrick McHardy wrote: > Allowing the user to freely set indices breaks racoon: > > #ifdef __linux__ > /* bsd skips over per-socket policies because there will be no > * src and dst extensions in spddump messages. On Linux the only > * way to achieve the same is check for policy id. > */ > if (xpl->sadb_x_policy_id % 8 >= 3) return 0; > #endif > I can see where the %8 >= 3 comes from. [per socket creation with calls xfrm_gen_index(XFRM_POLICY_MAX+dir) and the kernel does things in increments of 8] I didnt quiet understand that check in racoon: Why this guess work? if per-socket policies need to be identified, why dont they get explicitly marked as per-socket somehow? I am actually curious why that check is needed. Sorry have never stared at the racoon code. Do other IKE/ISAKMP daemons depend on it? > So how could we handle this? > We can disallow the explicit setting of any index which passes test (index % 8 >= 3) - but it does seem to me the whole concept of reserving those indices for per-socket policies is a bit of a hack and may need a rethinking. Maybe we need to maintain a mark in the kernel for per-socket polices and do the same as BSD? cheers, jamal From tgraf@suug.ch Sun May 8 11:33:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 11:34:34 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48IXBOv032724 for ; Sun, 8 May 2005 11:33:11 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 2991C1C0ED; Sun, 8 May 2005 20:33:10 +0200 (CEST) Date: Sun, 8 May 2005 20:33:10 +0200 From: Thomas Graf To: Patrick McHardy Cc: Asim Shankar , netdev@oss.sgi.com Subject: Re: SFQ: Reordering? Message-ID: <20050508183310.GU28419@postel.suug.ch> References: <7bca1cb5050506145344d16b1e@mail.gmail.com> <427BEAAE.409@trash.net> <427BF3C4.1030105@trash.net> <20050506230203.GI28419@postel.suug.ch> <427BFB72.7080407@trash.net> <20050507005851.GK28419@postel.suug.ch> <427C19C3.5030304@trash.net> <20050508115100.GQ28419@postel.suug.ch> <427E3847.3050709@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427E3847.3050709@trash.net> X-archive-position: 942 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1302 Lines: 26 * Patrick McHardy <427E3847.3050709@trash.net> 2005-05-08 18:03 > Actually I was beginning to think you're right about having this > feature optional. Paul McKenney's paper on SFQ states multiple times > that perturbation can cause reordering if implemented the easy way, > the Debian sfq manpage mentions this as well. So it appears to be a > design-choice. Anyways, I suggest to make the decision when we know > what the costs are. > > BTW, this is the URL for the paper: > http://rdrop.com/users/paulmck/paper/sfq.2002.06.04.pdf Indeed, well I think it depends on the perturbation interval, complexity and cost of the hashing function and the average queue length so having a flag to toggle this feature is certainly not a bad idea. Assuming a considerable queue length and a perturbation level of 1-5 seconds it probably doesn't make sense to rehash. > I agree both make sense. Are you talking about run-time adjustable > or compile-time adjustable? For SNAT it would also be nice to be > able to use the original address, unfortunately this isn't possible > anymore since we now drop the conntrack reference early. We can compute the hash at ingress or just before we drop the reference, store it in tc_classid and then use it at the egress sfq. Needs some more thinking but should be doable. From herbert@gondor.apana.org.au Sun May 8 14:42:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 14:42:06 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j48LfvOv009805 for ; Sun, 8 May 2005 14:41:59 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DUtWB-00064a-00; Mon, 09 May 2005 07:40:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DUtW5-0003lM-00; Mon, 09 May 2005 07:40:49 +1000 Date: Mon, 9 May 2005 07:40:49 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev Subject: Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification Message-ID: <20050508214049.GA14415@gondor.apana.org.au> References: <20050507072058.GD5753@gondor.apana.org.au> <20050507072139.GE5753@gondor.apana.org.au> <20050507072216.GF5753@gondor.apana.org.au> <20050507072251.GG5753@gondor.apana.org.au> <20050507072349.GH5753@gondor.apana.org.au> <1115467457.19561.5.camel@localhost.localdomain> <20050507122504.GA21693@gondor.apana.org.au> <1115470004.19561.49.camel@localhost.localdomain> <20050507193538.GA28991@gondor.apana.org.au> <1115560594.19561.117.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115560594.19561.117.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 943 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1523 Lines: 42 On Sun, May 08, 2005 at 09:56:33AM -0400, jamal wrote: > > Why would someone need to deduce whether it has been deleted by index or > selector? It isn't just about deducing the message. It's about sending a delete message in the same format as we would receive them. As it is the delete message sent would be not be accepted if you sent it back to the > Does pfkey have ability to delete by index and selector? Yes. > If yes, how do you distinguish the two cases when you are sending the > netlink event? Using the byid attribute that *you* introduced :) > > As it is the netlink delete messages sent by notification are invalid > > by its own standard. > > It doesnt seem to me what you provided in the patch produces exactly the > same thing that was sent by user space back in the event. That's not the point. The point is if you send exactly the same message to the kernel, even with the RTAs attached, the kernel would accept it and perform the deletion if there is a matching policy. > Heres what i will say so we can put this to rest: > The patch is unneeded (i hate to use strong words like bogus - but it is > getting close to that), but if you feel strongly about it just lets have > it well documented and provide the iproute2 patch as well. I'll leave the decision up to Dave. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Sun May 8 17:07:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 17:07:18 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4907GOv019087 for ; Sun, 8 May 2005 17:07:16 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DUvnK-00020w-7d for netdev@oss.sgi.com; Sun, 08 May 2005 18:06:46 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DUvnK-0002AZ-52; Sun, 08 May 2005 20:06:46 -0400 Subject: Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev In-Reply-To: <20050508214049.GA14415@gondor.apana.org.au> References: <20050507072058.GD5753@gondor.apana.org.au> <20050507072139.GE5753@gondor.apana.org.au> <20050507072216.GF5753@gondor.apana.org.au> <20050507072251.GG5753@gondor.apana.org.au> <20050507072349.GH5753@gondor.apana.org.au> <1115467457.19561.5.camel@localhost.localdomain> <20050507122504.GA21693@gondor.apana.org.au> <1115470004.19561.49.camel@localhost.localdomain> <20050507193538.GA28991@gondor.apana.org.au> <1115560594.19561.117.camel@localhost.localdomain> <20050508214049.GA14415@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Sun, 08 May 2005 20:06:39 -0400 Message-Id: <1115597200.19561.215.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 944 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2464 Lines: 65 On Mon, 2005-09-05 at 07:40 +1000, Herbert Xu wrote: > On Sun, May 08, 2005 at 09:56:33AM -0400, jamal wrote: > > > > Why would someone need to deduce whether it has been deleted by index or > > selector? > > It isn't just about deducing the message. It's about sending a delete > message in the same format as we would receive them. As it is the > delete message sent would be not be accepted if you sent it back to the > If you enumerate all netlink messages, you will see this is not always the case. It is a nice but not a necessary condition; infact, not even what you generate with that patch is _the same_ message that was sent (you add new TLVs in the response that didnt exist in user->kernel). What is necessary is that if i look at the event i know exactly what was deleted. If i have such detail, i can build the message that was sent from user->kernel to delete the object (because i know exactly what was deleted). As an example: I can derive the xfrm_usersa_id that was sent to the kernel if the event sent me xfrm_usersa_info and therefore build the same a message that will delete _exactly_ the same object. It does get worse on occasion (I can point at tc filters) - where you really cant derive the deleted object. > > If yes, how do you distinguish the two cases when you are sending the > > netlink event? > > Using the byid attribute that *you* introduced :) > Ok, theres no inconsistency then. > > It doesnt seem to me what you provided in the patch produces exactly the > > same thing that was sent by user space back in the event. > > That's not the point. The point is if you send exactly the same > message to the kernel, even with the RTAs attached, the kernel > would accept it and perform the deletion if there is a matching > policy. So you are depending on the kernel not checking for the extra TLVs you send?;-> Refer to what i said above. > > > Heres what i will say so we can put this to rest: > > The patch is unneeded (i hate to use strong words like bogus - but it is > > getting close to that), but if you feel strongly about it just lets have > > it well documented and provide the iproute2 patch as well. > > I'll leave the decision up to Dave. Like i said: I think its extraneous stuff that is unneeded(what is in there at the moment is sufficient detail) - but because theres no inconsistency, i will not squirm in pain if it is included. I am agreeing to disagree essentially ;-> cheers, jamal From herbert@gondor.apana.org.au Sun May 8 20:05:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 20:05:38 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4935VOv025896 for ; Sun, 8 May 2005 20:05:32 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DUyZU-0007PE-00; Mon, 09 May 2005 13:04:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DUyZO-0004Fp-00; Mon, 09 May 2005 13:04:34 +1000 From: Herbert Xu To: pizza@shaftnet.org (Stuffed Crust) Subject: Re: [PATCH] fix long-standing bug in 2.6/2.4 skb_copy/skb_copy_expand Cc: davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050508143259.GA30676@shaftnet.org> X-Newsgroups: apana.lists.os.linux.kernel User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 09 May 2005 13:04:34 +1000 X-archive-position: 945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 772 Lines: 18 Stuffed Crust wrote: > > This is, fortunately, generally true. But if the alloc_skb function > allocates extra head room (ie calls skb_reserve() on the skb before it > passes it to the callee, this doesn't quite work. Instead, it should be > rewritten as: As far as I know the alloc_skb funciton in the kernel tree doesn't do that so your patch is not necessary unless we decide to change the way alloc_skb works. If that's what you want then please provide a patch to alloc_skb and a rationale as to why we should do that. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From sri@us.ibm.com Sun May 8 21:28:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 May 2005 21:29:00 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j494SkOv000447 for ; Sun, 8 May 2005 21:28:52 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j494SOwN000678 for ; Mon, 9 May 2005 00:28:24 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j494SOND106566 for ; Mon, 9 May 2005 00:28:24 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j494SOhg019691 for ; Mon, 9 May 2005 00:28:24 -0400 Received: from [127.0.0.1] (sig-9-49-142-192.mts.ibm.com [9.49.142.192]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j494SLhO019660; Mon, 9 May 2005 00:28:23 -0400 Message-ID: <427EE6E2.5050000@us.ibm.com> Date: Sun, 08 May 2005 21:28:18 -0700 From: Sridhar Samudrala User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: lksctp-developers@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] net/sctp/: make two functions static References: <20050506222549.GW3590@stusta.de> In-Reply-To: <20050506222549.GW3590@stusta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2637 Lines: 76 Adrian Bunk wrote: >This patch makes two needlessly global functions static. > >Signed-off-by: Adrian Bunk > > Acked-by: Sridhar Samudrala >--- > > include/net/sctp/sm.h | 3 --- > net/sctp/sm_statefuns.c | 13 +++++++++++-- > 2 files changed, 11 insertions(+), 5 deletions(-) > >--- linux-2.6.12-rc3-mm3-full/include/net/sctp/sm.h.old 2005-05-05 22:59:54.000000000 +0200 >+++ linux-2.6.12-rc3-mm3-full/include/net/sctp/sm.h 2005-05-06 00:17:40.000000000 +0200 >@@ -130,7 +130,6 @@ > sctp_state_fn_t sctp_sf_ootb; > sctp_state_fn_t sctp_sf_pdiscard; > sctp_state_fn_t sctp_sf_violation; >-sctp_state_fn_t sctp_sf_violation_chunklen; > sctp_state_fn_t sctp_sf_discard_chunk; > sctp_state_fn_t sctp_sf_do_5_2_1_siminit; > sctp_state_fn_t sctp_sf_do_5_2_2_dupinit; >@@ -258,8 +257,6 @@ > void sctp_chunk_assign_tsn(struct sctp_chunk *); > void sctp_chunk_assign_ssn(struct sctp_chunk *); > >-void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error); >- > /* Prototypes for statetable processing. */ > > int sctp_do_sm(sctp_event_t event_type, sctp_subtype_t subtype, >--- linux-2.6.12-rc3-mm3-full/net/sctp/sm_statefuns.c.old 2005-05-05 23:00:12.000000000 +0200 >+++ linux-2.6.12-rc3-mm3-full/net/sctp/sm_statefuns.c 2005-05-06 00:19:11.000000000 +0200 >@@ -92,6 +92,14 @@ > sctp_cmd_seq_t *commands); > static struct sctp_sackhdr *sctp_sm_pull_sack(struct sctp_chunk *chunk); > >+static void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error); >+ >+static sctp_disposition_t sctp_sf_violation_chunklen( >+ const struct sctp_endpoint *ep, >+ const struct sctp_association *asoc, >+ const sctp_subtype_t type, >+ void *arg, >+ sctp_cmd_seq_t *commands); > > /* Small helper function that checks if the chunk length > * is of the appropriate length. The 'required_length' argument >@@ -2318,7 +2326,7 @@ > * > * This is common code called by several sctp_sf_*_abort() functions above. > */ >-void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error) >+static void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error) > { > sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE, > SCTP_STATE(SCTP_STATE_CLOSED)); >@@ -3672,7 +3680,8 @@ > * > * Generate an ABORT chunk and terminate the association. > */ >-sctp_disposition_t sctp_sf_violation_chunklen(const struct sctp_endpoint *ep, >+static sctp_disposition_t sctp_sf_violation_chunklen( >+ const struct sctp_endpoint *ep, > const struct sctp_association *asoc, > const sctp_subtype_t type, > void *arg, > > > > From cranium2003@yahoo.com Mon May 9 01:31:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 01:31:40 -0700 (PDT) Received: from web41414.mail.yahoo.com (web41414.mail.yahoo.com [66.218.93.80]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j498VbOv014317 for ; Mon, 9 May 2005 01:31:37 -0700 Received: (qmail 42573 invoked by uid 60001); 9 May 2005 08:31:13 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=kEa/JnfywPmXcFrx6/NuSgqs7PZVAvvA7/SAwuLzCY27HvHlTst7eNbSysjJfTDyLxz+vWKAa1ZABG/Sn1ZNwz/NUCG634IrClPV2Ys/UNJ+ciRbTQp4t5ytoz3hyxUxNAfgq05vhwEkXI3XZ1465jNmXfG9513bC9H+2CcDcQg= ; Message-ID: <20050509083113.42571.qmail@web41414.mail.yahoo.com> Received: from [203.199.141.99] by web41414.mail.yahoo.com via HTTP; Mon, 09 May 2005 01:31:13 PDT Date: Mon, 9 May 2005 01:31:13 -0700 (PDT) From: cranium2003 Subject: SNAT help To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 947 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 651 Lines: 21 hello, I want to execute my code at NF_IP_POST_ROUTING. For that First i want to know which functions are executing at NF_IP_POST_ROUTING Hook. Then i have enabled SNAT and I have wrriten code at NF_IP_POST_ROUTING but i want to get outgoing packets' IP address as new one SNAT'ed IP address not the one that is before SNAT? How can i do that? I observe that my code and SNAT are executing at same HOOK NF_IP_POST_ROUTING. But my code is executed first and then SNAT is doen but how to reverse that? regards, cranium Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From kaber@trash.net Mon May 9 04:46:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 04:46:46 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49BkTOv030288 for ; Mon, 9 May 2005 04:46:32 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DV6hM-0006Rj-R6; Mon, 09 May 2005 13:45:20 +0200 Message-ID: <427F4D50.4060702@trash.net> Date: Mon, 09 May 2005 13:45:20 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Herbert Xu , "David S. Miller" , netdev Subject: Re: resend patch: xfrm policybyid References: <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> <20050506085404.GA26719@gondor.apana.org.au> <1115380381.7660.123.camel@localhost.localdomain> <20050507105500.GA20283@gondor.apana.org.au> <1115469496.19561.41.camel@localhost.localdomain> <20050508080730.GA30512@gondor.apana.org.au> <1115562643.19561.148.camel@localhost.localdomain> <427E2F0D.4040902@trash.net> <1115573038.19561.174.camel@localhost.localdomain> In-Reply-To: <1115573038.19561.174.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 948 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1390 Lines: 33 jamal wrote: > I can see where the %8 >= 3 comes from. > [per socket creation with calls xfrm_gen_index(XFRM_POLICY_MAX+dir) > and the kernel does things in increments of 8] > > I didnt quiet understand that check in racoon: Why this guess work? if > per-socket policies need to be identified, why dont they get explicitly > marked as per-socket somehow? I am actually curious why that check is > needed. Sorry have never stared at the racoon code. Do other IKE/ISAKMP > daemons depend on it? Not sure why they're not marked as per-socket. Probably because sadb_x_policy_id is a KAME extension and KAME pf_key doesn't dump these policies with SADB_X_SPDDUMP. Racoon needs to skip them to avoid adding them to its internal SPD, they could conflict with global policies. >>So how could we handle this? >> > We can disallow the explicit setting of any index which passes test > (index % 8 >= 3) - but it does seem to me the whole concept of reserving > those indices for per-socket policies is a bit of a hack and may need a > rethinking. Maybe we need to maintain a mark in the kernel for > per-socket polices and do the same as BSD? Disallowing this special case seems a bit inconsistent to me. We can deduce which are per-socket from the list they are contained in. We don't notify on per-socket policy change, perhaps we should also skip them when dumping in pf_key. Regards Patrick From hadi@cyberus.ca Mon May 9 06:11:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 06:11:12 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49DB0Ov003602 for ; Mon, 9 May 2005 06:11:00 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DV81s-0005OY-2Y for netdev@oss.sgi.com; Mon, 09 May 2005 09:10:36 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DV81p-0005xB-4q; Mon, 09 May 2005 09:10:33 -0400 Subject: Re: resend patch: xfrm policybyid From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Herbert Xu , "David S. Miller" , netdev In-Reply-To: <427F4D50.4060702@trash.net> References: <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au> <1115345403.7660.49.camel@localhost.localdomain> <20050506085404.GA26719@gondor.apana.org.au> <1115380381.7660.123.camel@localhost.localdomain> <20050507105500.GA20283@gondor.apana.org.au> <1115469496.19561.41.camel@localhost.localdomain> <20050508080730.GA30512@gondor.apana.org.au> <1115562643.19561.148.camel@localhost.localdomain> <427E2F0D.4040902@trash.net> <1115573038.19561.174.camel@localhost.localdomain> <427F4D50.4060702@trash.net> Content-Type: text/plain Organization: unknown Date: Mon, 09 May 2005 09:10:29 -0400 Message-Id: <1115644229.19561.263.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1378 Lines: 37 On Mon, 2005-09-05 at 13:45 +0200, Patrick McHardy wrote: > Not sure why they're not marked as per-socket. Probably because > sadb_x_policy_id is a KAME extension and KAME pf_key doesn't dump > these policies with SADB_X_SPDDUMP. Racoon needs to skip them > to avoid adding them to its internal SPD, they could conflict > with global policies. > But as you can see without having some KAME extension or explicit flag it resorts to some hack. I have a feeling they may have to put a different hack for each OS that is not BSD derived. > >>So how could we handle this? > >> > > We can disallow the explicit setting of any index which passes test > > (index % 8 >= 3) - but it does seem to me the whole concept of reserving > > those indices for per-socket policies is a bit of a hack and may need a > > rethinking. Maybe we need to maintain a mark in the kernel for > > per-socket polices and do the same as BSD? > > Disallowing this special case seems a bit inconsistent to me. Well, those indices are "reserved" in a sense; so if we can get rid of that speacial casing even better. > We can > deduce which are per-socket from the list they are contained in. We > don't notify on per-socket policy change, perhaps we should also skip > them when dumping in pf_key. this sounds reasonable and would remove the necessity of special-casing those indices. cheers, jamal From hhh@imada.sdu.dk Mon May 9 06:14:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 06:14:11 -0700 (PDT) Received: from berlioz.imada.sdu.dk (berlioz.imada.sdu.dk [130.225.128.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49DDwOv004155 for ; Mon, 9 May 2005 06:13:59 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.imada.sdu.dk (Postfix) with ESMTP id EEFAB62742 for ; Mon, 9 May 2005 15:13:33 +0200 (CEST) Received: from berlioz.imada.sdu.dk ([127.0.0.1]) by localhost (berlioz.imada.sdu.dk [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 02756-05 for ; Mon, 9 May 2005 13:13:33 +0000 (UTC) Received: from [139.91.76.126] (unknown [139.91.76.126]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by berlioz.imada.sdu.dk (Postfix) with ESMTP id C4B066273D for ; Mon, 9 May 2005 15:13:32 +0200 (CEST) From: Hans Henrik Happe To: netdev@oss.sgi.com Subject: PROBLEM: INET TCP socket communication through loopback Date: Mon, 9 May 2005 15:07:50 +0200 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_mC2fCmC2MLhfCfd" Message-Id: <200505091507.50387.hhh@imada.sdu.dk> X-archive-position: 950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hhh@imada.sdu.dk Precedence: bulk X-list: netdev Content-Length: 14360 Lines: 526 --Boundary-00=_mC2fCmC2MLhfCfd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I have experienced some odd behavior when communicating between multiple processes through the loopback device using poll() to wait for input. Attachment 'random-inet.c' is a program that shows the problem. Basically it starts a number of processes. Each process makes a connection to the each of the other processes (resembling MPI implementations such as lam-mpi). Now a given number of messages are sent to a pseudo-random destination. When a process receives one of the messages it forwards it to another randomly chosen destination. The program is run as follows: ./random-inet <# processes> <# messages> Problem: One would expect that this program would use up all the available CPU-time, but this is not the case. Allready with 3 processes and 1 message there is still some idle CPU-time and it becomes worse when more process are added. As a sanity check i created the same program using UNIX socket created by socketpair() (random-spair.c). This makes the problem go away. I have also attached the MPI program 'random-mpi.c' showing the same problem with lam-mpi 7.0.6. Another MPI program that does NOT have the problem is 'ring-mpi.c'. This sends the messages around in a ring of processes. The controlled communication pattern somehow makes the problem go away. I have attached the 'ver-linux' of the systems that I have tested. I know these are not mainline kernels but I have not found any mention of such a problem in the latest changelogs. I will gladly try it on the mainline if that would help. I'm not on the list so please CC. Hans Henrik Happe --Boundary-00=_mC2fCmC2MLhfCfd Content-Type: text/x-csrc; charset="us-ascii"; name="random-inet.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="random-inet.c" /* * usage: random-inet <# processes> <# messages> */ #include #include #include #include #include #include #include int do_connect(int port) { int n, sock, on=1; struct addrinfo hints, *res; char str[6]; void *adr; memset(&hints, 0, sizeof(struct addrinfo)); hints.ai_flags = AI_PASSIVE; hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_STREAM; sprintf(str, "%d", port); n = getaddrinfo("localhost", str, &hints, &res); if (n != 0) { fprintf(stderr, "getaddrinfo error: [%s]\n", gai_strerror(n)); return -1; } sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) { perror("socket"); return -1; } if (setsockopt(sock, SOL_TCP, TCP_NODELAY, &on, sizeof(on)) == -1) { perror("setsockopt"); return -1; } if (connect(sock, (struct sockaddr *)res->ai_addr, sizeof(*res->ai_addr)) == -1) { perror("connect"); return -1; } freeaddrinfo(res); return sock; } int start_listen(int port) { int n, on=1; int sock; struct sockaddr_in name; sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) { perror("socket"); return -1; } if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)) == -1) { perror("setsockopt"); return -1; } name.sin_family = AF_INET; name.sin_port = htons (port); name.sin_addr.s_addr = htonl (INADDR_ANY); if (bind (sock, (struct sockaddr *) &name, sizeof (name)) == -1) { perror("bind"); return -1; } if (listen(sock, 10) == -1) { perror("listen"); return -1; } return sock; } int do_accept(int lsock) { struct sockaddr addr; socklen_t len = sizeof(addr); int sock, on=1; if ((sock = accept(lsock, &addr, &len)) == -1) { perror("accept"); return -1; } if (setsockopt(sock, SOL_TCP, TCP_NODELAY, &on, sizeof(on)) == -1) { perror("setsockopt"); return -1; } return sock; } int main(int argc, char *argv[]) { int i, j, n, cnt, pid, rank, dest; int lsock; char data = 'h'; int port = 11100; /* # processes */ cnt = atoi(argv[1]); /* # messages */ n = atoi(argv[2]); { int socks[cnt-1]; struct pollfd pfds[cnt-1]; /* Create processes */ rank = 0; for (i=1; i #include /* * Sends 'n' messages between processes. When a process * receives a message it chooses a new destination at random. * * usage: random-mpi */ main(int argc, char **argv) { int n, i, data[1]; int dest, size, rank; MPI_Init(&argc, &argv); MPI_Comm_size(MPI_COMM_WORLD,&size); MPI_Comm_rank(MPI_COMM_WORLD,&rank); n = atoi(argv[1]); srandom(rank); /* Send 'n' startup messages. */ if (rank < n) { while ((dest = (random()%size)) == rank); MPI_Send(data, 1, MPI_INT, dest, 0, MPI_COMM_WORLD); } while (1) { MPI_Recv(data, 1, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); /* Don't send to self. */ while ((dest = (random()%size)) == rank); MPI_Send(data, 1, MPI_INT, dest, 0, MPI_COMM_WORLD); } MPI_Finalize(); } --Boundary-00=_mC2fCmC2MLhfCfd Content-Type: text/x-csrc; charset="us-ascii"; name="random-spair.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="random-spair.c" /* * usage: random-spair <# processes> <# messages> */ #include #include #include #include #include #include #include int main(int argc, char *argv[]) { int i, j, n, cnt, pid, rank, dest; int lsock; char data; int port = 11100; cnt = atoi(argv[1]); n = atoi(argv[2]); { int socks[cnt-1]; struct pollfd pfds[cnt-1]; int spairs[2*cnt*cnt]; for (i=0; i<2*cnt*cnt; i+=2) { socketpair(AF_UNIX, SOCK_STREAM, 0, spairs+i); } /* Create processes */ rank = 0; for (i=1; i #include /* * Sends 'n' messages in a ring of processes. * * usage: ring-mpi */ main(int argc, char **argv) { int n, i, data[1]; int size, rank, dest; MPI_Init(&argc, &argv); MPI_Comm_size(MPI_COMM_WORLD,&size); MPI_Comm_rank(MPI_COMM_WORLD,&rank); n = atoi(argv[1]); dest = (rank+1)%size; /* Send 'n' startup messages. */ if (rank%(size/n) == 0) { MPI_Send(data, 1, MPI_INT, dest, 0, MPI_COMM_WORLD); } while (1) { MPI_Recv(data, 1, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); MPI_Send(data, 1, MPI_INT, dest, 0, MPI_COMM_WORLD); } MPI_Finalize(); } --Boundary-00=_mC2fCmC2MLhfCfd-- From Jeff@steinhagen.ch Mon May 9 07:34:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 07:34:51 -0700 (PDT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49EYcOv008457 for ; Mon, 9 May 2005 07:34:39 -0700 Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IG800ETE8H3W5@ms-dienst.rz.rwth-aachen.de> for netdev@oss.sgi.com; Mon, 09 May 2005 16:34:16 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Mon, 09 May 2005 16:34:14 +0200 (MEST) Received: from PCAB20.cern.ch (pcab20.cern.ch [137.138.196.37]) by relay.rwth-aachen.de (8.13.3/8.13.3/1) with ESMTP id j49EYDaj028430 for ; Mon, 09 May 2005 16:34:13 +0200 (MEST) Date: Mon, 09 May 2005 14:58:42 +0200 From: "'Jeff' R. Steinhagen" Subject: forcing a packet to go through hw net device To: netdev@oss.sgi.com Message-id: <200505091458.42118.Jeff@steinhagen.ch> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7.1 X-archive-position: 951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Jeff@steinhagen.ch Precedence: bulk X-list: netdev Content-Length: 572 Lines: 20 Hi! I have a (maybe trivial) question about the kernel's networking code: A packet with an "outside" destination goes through all layers including the hardware interface (user->socket->protocol->IP->HW). However if the packet is addressed to a local IP the transport through and checks by the hardware layer are avoided. This is perfectly OK for "normal" network usage. I am profiling some network hardware and related code. Is it possible to force an internally generated packet to be send through all/the hardware layers? Thanks for your help! Cheers, Jeff From davem@davemloft.net Mon May 9 12:49:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 12:49:13 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49Jn8Ov027645 for ; Mon, 9 May 2005 12:49:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DVEEz-00059o-00; Mon, 09 May 2005 12:48:33 -0700 Date: Mon, 9 May 2005 12:48:32 -0700 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com Subject: Re: [TG3]: Add tagged status support Message-Id: <20050509124832.2a073e11.davem@davemloft.net> In-Reply-To: <1115418431.15156.153.camel@rh4> References: <20050505211735.3829cff2.davem@davemloft.net> <1115418431.15156.153.camel@rh4> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 952 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 13425 Lines: 392 On Fri, 06 May 2005 15:27:11 -0700 "Michael Chan" wrote: > I tested the patch and it worked fine. But I'd like to suggest a few > things: Thanks for the feedback. I decided that it's better to just test the tg3 flag instead of make a special function pointer, since the flag bits sit in the cpu cache all the time already and the branches should be always predicted properly. Here is my current patch, how does it look. If there are no problems, we can integrate the hw coalescing bits on top of this. [TG3]: Add tagged status support. When supported, use the TAGGED interrupt processing support the chip provides. In this mode, instead of a "on/off" binary semaphore, an incrementing tag scheme is used to ACK interrupts. All MSI supporting chips support TAGGED mode, so the tg3_msi() interrupt handler uses it unconditionally. This invariant is verified when MSI support is tested. Since we can invoke tg3_poll() multiple times per interrupt under high packet load, we fetch a new copy of the tag value in the status block right before we actually do the work. Also, because the tagged status tells the chip exactly which work we have processed, we can make two optimizations: 1) tg3_restart_ints() need not check tg3_has_work() 2) the tg3_timer() need not poke the chip 10 times per second to keep from losing interrupt events Based upon valuable feedback from Michael Chan Signed-off-by: David S. Miller --- 1/drivers/net/tg3.c.~1~ 2005-05-05 17:15:59.000000000 -0700 +++ 2/drivers/net/tg3.c 2005-05-09 12:34:28.000000000 -0700 @@ -420,7 +420,8 @@ static void tg3_enable_ints(struct tg3 * { tw32(TG3PCI_MISC_HOST_CTRL, (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); - tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000); + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + (tp->last_tag << 24)); tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); tg3_cond_int(tp); @@ -455,10 +456,16 @@ static void tg3_restart_ints(struct tg3 { tw32(TG3PCI_MISC_HOST_CTRL, (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); - tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000); + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + tp->last_tag << 24); mmiowb(); - if (tg3_has_work(tp)) + /* When doing tagged status, this work check is unnecessary. + * The last_tag we write above tells the chip which piece of + * work we've completed. + */ + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) && + tg3_has_work(tp)) tw32(HOSTCC_MODE, tp->coalesce_mode | (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW)); } @@ -2862,6 +2869,9 @@ static int tg3_poll(struct net_device *n spin_lock_irqsave(&tp->lock, flags); + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + tp->last_tag = sblk->status_tag; + /* handle link change and other phy events */ if (!(tp->tg3_flags & (TG3_FLAG_USE_LINKCHG_REG | @@ -2928,22 +2938,21 @@ static irqreturn_t tg3_msi(int irq, void spin_lock_irqsave(&tp->lock, flags); /* - * writing any value to intr-mbox-0 clears PCI INTA# and + * Writing any value to intr-mbox-0 clears PCI INTA# and * chip-internal interrupt pending events. - * writing non-zero to intr-mbox-0 additional tells the + * Writing non-zero to intr-mbox-0 additional tells the * NIC to stop sending us irqs, engaging "in-intr-handler" * event coalescing. */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); + tp->last_tag = sblk->status_tag; sblk->status &= ~SD_STATUS_UPDATED; - if (likely(tg3_has_work(tp))) netif_rx_schedule(dev); /* schedule NAPI poll */ else { - /* no work, re-enable interrupts - */ + /* No work, re-enable interrupts. */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, - 0x00000000); + tp->last_tag << 24); } spin_unlock_irqrestore(&tp->lock, flags); @@ -2969,21 +2978,62 @@ static irqreturn_t tg3_interrupt(int irq if ((sblk->status & SD_STATUS_UPDATED) || !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) { /* - * writing any value to intr-mbox-0 clears PCI INTA# and + * Writing any value to intr-mbox-0 clears PCI INTA# and * chip-internal interrupt pending events. - * writing non-zero to intr-mbox-0 additional tells the + * Writing non-zero to intr-mbox-0 additional tells the * NIC to stop sending us irqs, engaging "in-intr-handler" * event coalescing. */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); + sblk->status &= ~SD_STATUS_UPDATED; + if (likely(tg3_has_work(tp))) + netif_rx_schedule(dev); /* schedule NAPI poll */ + else { + /* No work, shared interrupt perhaps? re-enable + * interrupts, and flush that PCI write + */ + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + 0x00000000); + tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + } + } else { /* shared interrupt */ + handled = 0; + } + + spin_unlock_irqrestore(&tp->lock, flags); + + return IRQ_RETVAL(handled); +} + +static irqreturn_t tg3_interrupt_tagged(int irq, void *dev_id, struct pt_regs *regs) +{ + struct net_device *dev = dev_id; + struct tg3 *tp = netdev_priv(dev); + struct tg3_hw_status *sblk = tp->hw_status; + unsigned long flags; + unsigned int handled = 1; + + spin_lock_irqsave(&tp->lock, flags); + + /* In INTx mode, it is possible for the interrupt to arrive at + * the CPU before the status block posted prior to the interrupt. + * Reading the PCI State register will confirm whether the + * interrupt is ours and will flush the status block. + */ + if ((sblk->status & SD_STATUS_UPDATED) || + !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) { /* - * Flush PCI write. This also guarantees that our - * status block has been flushed to host memory. + * writing any value to intr-mbox-0 clears PCI INTA# and + * chip-internal interrupt pending events. + * writing non-zero to intr-mbox-0 additional tells the + * NIC to stop sending us irqs, engaging "in-intr-handler" + * event coalescing. */ - tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + 0x00000001); + tp->last_tag = sblk->status_tag; sblk->status &= ~SD_STATUS_UPDATED; - if (likely(tg3_has_work(tp))) netif_rx_schedule(dev); /* schedule NAPI poll */ else { @@ -2991,7 +3041,7 @@ static irqreturn_t tg3_interrupt(int irq * interrupts, and flush that PCI write */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, - 0x00000000); + tp->last_tag << 24); tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); } } else { /* shared interrupt */ @@ -5445,7 +5495,8 @@ static int tg3_reset_hw(struct tg3 *tp) udelay(100); tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0); - tr32(MAILBOX_INTERRUPT_0); + tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + tp->last_tag = 0; if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { tw32_f(DMAC_MODE, DMAC_MODE_ENABLE); @@ -5723,31 +5774,33 @@ static void tg3_timer(unsigned long __op spin_lock_irqsave(&tp->lock, flags); spin_lock(&tp->tx_lock); - /* All of this garbage is because when using non-tagged - * IRQ status the mailbox/status_block protocol the chip - * uses with the cpu is race prone. - */ - if (tp->hw_status->status & SD_STATUS_UPDATED) { - tw32(GRC_LOCAL_CTRL, - tp->grc_local_ctrl | GRC_LCLCTRL_SETINT); - } else { - tw32(HOSTCC_MODE, tp->coalesce_mode | - (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW)); - } + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) { + /* All of this garbage is because when using non-tagged + * IRQ status the mailbox/status_block protocol the chip + * uses with the cpu is race prone. + */ + if (tp->hw_status->status & SD_STATUS_UPDATED) { + tw32(GRC_LOCAL_CTRL, + tp->grc_local_ctrl | GRC_LCLCTRL_SETINT); + } else { + tw32(HOSTCC_MODE, tp->coalesce_mode | + (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW)); + } - if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) { - tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER; - spin_unlock(&tp->tx_lock); - spin_unlock_irqrestore(&tp->lock, flags); - schedule_work(&tp->reset_task); - return; + if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) { + tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER; + spin_unlock(&tp->tx_lock); + spin_unlock_irqrestore(&tp->lock, flags); + schedule_work(&tp->reset_task); + return; + } } - if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) - tg3_periodic_fetch_stats(tp); - /* This part only runs once per second. */ if (!--tp->timer_counter) { + if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) + tg3_periodic_fetch_stats(tp); + if (tp->tg3_flags & TG3_FLAG_USE_LINKCHG_REG) { u32 mac_stat; int phy_event; @@ -5846,9 +5899,13 @@ static int tg3_test_interrupt(struct tg3 if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) err = request_irq(tp->pdev->irq, tg3_msi, SA_SAMPLE_RANDOM, dev->name, dev); - else - err = request_irq(tp->pdev->irq, tg3_interrupt, + else { + irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + fn = tg3_interrupt_tagged; + err = request_irq(tp->pdev->irq, fn, SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + } if (err) return err; @@ -5900,9 +5957,14 @@ static int tg3_test_msi(struct tg3 *tp) tp->tg3_flags2 &= ~TG3_FLG2_USING_MSI; - err = request_irq(tp->pdev->irq, tg3_interrupt, - SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + { + irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + fn = tg3_interrupt_tagged; + err = request_irq(tp->pdev->irq, fn, + SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + } if (err) return err; @@ -5959,9 +6021,14 @@ static int tg3_open(struct net_device *d if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) err = request_irq(tp->pdev->irq, tg3_msi, SA_SAMPLE_RANDOM, dev->name, dev); - else - err = request_irq(tp->pdev->irq, tg3_interrupt, + else { + irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + fn = tg3_interrupt_tagged; + + err = request_irq(tp->pdev->irq, fn, SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + } if (err) { if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) { @@ -5980,9 +6047,16 @@ static int tg3_open(struct net_device *d tg3_halt(tp, 1); tg3_free_rings(tp); } else { - tp->timer_offset = HZ / 10; - tp->timer_counter = tp->timer_multiplier = 10; - tp->asf_counter = tp->asf_multiplier = (10 * 120); + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + tp->timer_offset = HZ; + else + tp->timer_offset = HZ / 10; + + BUG_ON(tp->timer_offset > HZ); + tp->timer_counter = tp->timer_multiplier = + (HZ / tp->timer_offset); + tp->asf_counter = tp->asf_multiplier = + ((HZ / tp->timer_offset) * 120); init_timer(&tp->timer); tp->timer.expires = jiffies + tp->timer_offset; @@ -6005,6 +6079,16 @@ static int tg3_open(struct net_device *d if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) { err = tg3_test_msi(tp); + + /* All MSI supporting chips should support tagged + * status. Assert that this is the case. + */ + if (!(tp->tg3_flags2 & TG3_FLAG_TAGGED_STATUS)) { + printk(KERN_WARNING PFX "%s: MSI without TAGGED? " + "Not using MSI.\n", tp->dev->name); + err = -EINVAL; + } + if (err) { spin_lock_irq(&tp->lock); spin_lock(&tp->tx_lock); @@ -8422,15 +8506,7 @@ static int __devinit tg3_get_invariants( if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG; - /* Only 5701 and later support tagged irq status mode. - * Also, 5788 chips cannot use tagged irq status. - * - * However, since we are using NAPI avoid tagged irq status - * because the interrupt condition is more difficult to - * fully clear in that mode. - */ tp->coalesce_mode = 0; - if (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_AX && GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_BX) tp->coalesce_mode |= HOSTCC_MODE_32BYTE; @@ -8494,6 +8570,18 @@ static int __devinit tg3_get_invariants( grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788M)) tp->tg3_flags2 |= TG3_FLG2_IS_5788; + if (!(tp->tg3_flags2 & TG3_FLG2_IS_5788) && + (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700)) + tp->tg3_flags |= TG3_FLAG_TAGGED_STATUS; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) { + tp->coalesce_mode |= (HOSTCC_MODE_CLRTICK_RXBD | + HOSTCC_MODE_CLRTICK_TXBD); + + tp->misc_host_ctrl |= MISC_HOST_CTRL_TAGGED_STATUS; + pci_write_config_dword(tp->pdev, TG3PCI_MISC_HOST_CTRL, + tp->misc_host_ctrl); + } + /* these are limited to 10/100 only */ if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 && (grc_misc_cfg == 0x8000 || grc_misc_cfg == 0x4000)) || --- 1/drivers/net/tg3.h.~1~ 2005-05-05 17:15:59.000000000 -0700 +++ 2/drivers/net/tg3.h 2005-05-05 20:58:56.000000000 -0700 @@ -2023,6 +2023,7 @@ struct tg3 { struct tg3_hw_status *hw_status; dma_addr_t status_mapping; + u32 last_tag; u32 msg_enable; @@ -2068,6 +2069,7 @@ struct tg3 { u32 rx_offset; u32 tg3_flags; +#define TG3_FLAG_TAGGED_STATUS 0x00000001 #define TG3_FLAG_TXD_MBOX_HWBUG 0x00000002 #define TG3_FLAG_RX_CHECKSUMS 0x00000004 #define TG3_FLAG_USE_LINKCHG_REG 0x00000008 From mchan@broadcom.com Mon May 9 15:43:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 15:43:20 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49MhDOv003414 for ; Mon, 9 May 2005 15:43:17 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 09 May 2005 15:42:15 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 9 May 2005 15:42:38 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AXJ30549; Mon, 9 May 2005 15:42:33 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA10285; Mon, 9 May 2005 15:42:33 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 9 May 2005 22:42:29 +0000 Received: from rh4 by nt-irva-0741; 09 May 2005 14:44:42 -0700 Subject: Re: [TG3]: Add tagged status support From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com In-Reply-To: <20050509124832.2a073e11.davem@davemloft.net> References: <20050505211735.3829cff2.davem@davemloft.net> <1115418431.15156.153.camel@rh4> <20050509124832.2a073e11.davem@davemloft.net> Date: Mon, 09 May 2005 14:44:42 -0700 Message-ID: <1115675082.8570.10.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E6138CD0UW3266318-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 2140 Lines: 71 On Mon, 2005-05-09 at 12:48 -0700, David S. Miller wrote: > Here is my current patch, how does it look. > > @@ -6005,6 +6079,16 @@ static int tg3_open(struct net_device *d > > if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) { > err = tg3_test_msi(tp); > + > + /* All MSI supporting chips should support tagged > + * status. Assert that this is the case. > + */ > + if (!(tp->tg3_flags2 & TG3_FLAG_TAGGED_STATUS)) { > + printk(KERN_WARNING PFX "%s: MSI without TAGGED? " > + "Not using MSI.\n", tp->dev->name); > + err = -EINVAL; > + } > + > if (err) { > spin_lock_irq(&tp->lock); > spin_lock(&tp->tx_lock); I found one typo during testing, flags2 should have been flags: + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) { I think it will be better to move up this block of code because here we are at the point of returning error from tg3_open(). Something like this: diff -Nru h/drivers/net/tg3.c i/drivers/net/tg3.c --- h/drivers/net/tg3.c 2005-05-09 14:12:37.000000000 -0700 +++ i/drivers/net/tg3.c 2005-05-09 14:24:19.000000000 -0700 @@ -6010,7 +6010,14 @@ if ((tp->tg3_flags2 & TG3_FLG2_5750_PLUS) && (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5750_AX) && (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5750_BX)) { - if (pci_enable_msi(tp->pdev) == 0) { + /* All MSI supporting chips should support tagged + * status. Assert that this is the case. + */ + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) { + printk(KERN_WARNING PFX "%s: MSI without TAGGED? " + "Not using MSI.\n", tp->dev->name); + } + else if (pci_enable_msi(tp->pdev) == 0) { u32 msi_mode; msi_mode = tr32(MSGINT_MODE); @@ -6080,15 +6087,6 @@ if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) { err = tg3_test_msi(tp); - /* All MSI supporting chips should support tagged - * status. Assert that this is the case. - */ - if (!(tp->tg3_flags2 & TG3_FLAG_TAGGED_STATUS)) { - printk(KERN_WARNING PFX "%s: MSI without TAGGED? " - "Not using MSI.\n", tp->dev->name); - err = -EINVAL; - } - if (err) { spin_lock_irq(&tp->lock); spin_lock(&tp->tx_lock); From davem@davemloft.net Mon May 9 15:55:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 15:55:14 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49Mt8Ov004162 for ; Mon, 9 May 2005 15:55:08 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVH9A-0000d5-NZ; Mon, 09 May 2005 15:54:44 -0700 Date: Mon, 09 May 2005 15:54:44 -0700 (PDT) Message-Id: <20050509.155444.74750731.davem@davemloft.net> To: mchan@broadcom.com Cc: netdev@oss.sgi.com Subject: Re: [TG3]: Add tagged status support From: "David S. Miller" In-Reply-To: <1115675082.8570.10.camel@rh4> References: <1115418431.15156.153.camel@rh4> <20050509124832.2a073e11.davem@davemloft.net> <1115675082.8570.10.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 954 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 13702 Lines: 397 From: "Michael Chan" Subject: Re: [TG3]: Add tagged status support Date: Mon, 09 May 2005 14:44:42 -0700 > I found one typo during testing, flags2 should have been flags: > > + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) { Good catch, fixed. > I think it will be better to move up this block of code because here we > are at the point of returning error from tg3_open(). I agree. Here is the updated version of the patch. [TG3]: Add tagged status support. When supported, use the TAGGED interrupt processing support the chip provides. In this mode, instead of a "on/off" binary semaphore, an incrementing tag scheme is used to ACK interrupts. All MSI supporting chips support TAGGED mode, so the tg3_msi() interrupt handler uses it unconditionally. This invariant is verified when MSI support is tested. Since we can invoke tg3_poll() multiple times per interrupt under high packet load, we fetch a new copy of the tag value in the status block right before we actually do the work. Also, because the tagged status tells the chip exactly which work we have processed, we can make two optimizations: 1) tg3_restart_ints() need not check tg3_has_work() 2) the tg3_timer() need not poke the chip 10 times per second to keep from losing interrupt events Based upon valuable feedback from Michael Chan Signed-off-by: David S. Miller --- 1/drivers/net/tg3.c.~1~ 2005-05-09 15:51:29.000000000 -0700 +++ 2/drivers/net/tg3.c 2005-05-09 15:52:32.000000000 -0700 @@ -420,7 +420,8 @@ static void tg3_enable_ints(struct tg3 * { tw32(TG3PCI_MISC_HOST_CTRL, (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); - tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000); + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + (tp->last_tag << 24)); tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); tg3_cond_int(tp); @@ -455,10 +456,16 @@ static void tg3_restart_ints(struct tg3 { tw32(TG3PCI_MISC_HOST_CTRL, (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); - tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000); + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + tp->last_tag << 24); mmiowb(); - if (tg3_has_work(tp)) + /* When doing tagged status, this work check is unnecessary. + * The last_tag we write above tells the chip which piece of + * work we've completed. + */ + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) && + tg3_has_work(tp)) tw32(HOSTCC_MODE, tp->coalesce_mode | (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW)); } @@ -2862,6 +2869,9 @@ static int tg3_poll(struct net_device *n spin_lock_irqsave(&tp->lock, flags); + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + tp->last_tag = sblk->status_tag; + /* handle link change and other phy events */ if (!(tp->tg3_flags & (TG3_FLAG_USE_LINKCHG_REG | @@ -2928,22 +2938,21 @@ static irqreturn_t tg3_msi(int irq, void spin_lock_irqsave(&tp->lock, flags); /* - * writing any value to intr-mbox-0 clears PCI INTA# and + * Writing any value to intr-mbox-0 clears PCI INTA# and * chip-internal interrupt pending events. - * writing non-zero to intr-mbox-0 additional tells the + * Writing non-zero to intr-mbox-0 additional tells the * NIC to stop sending us irqs, engaging "in-intr-handler" * event coalescing. */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); + tp->last_tag = sblk->status_tag; sblk->status &= ~SD_STATUS_UPDATED; - if (likely(tg3_has_work(tp))) netif_rx_schedule(dev); /* schedule NAPI poll */ else { - /* no work, re-enable interrupts - */ + /* No work, re-enable interrupts. */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, - 0x00000000); + tp->last_tag << 24); } spin_unlock_irqrestore(&tp->lock, flags); @@ -2969,21 +2978,62 @@ static irqreturn_t tg3_interrupt(int irq if ((sblk->status & SD_STATUS_UPDATED) || !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) { /* - * writing any value to intr-mbox-0 clears PCI INTA# and + * Writing any value to intr-mbox-0 clears PCI INTA# and * chip-internal interrupt pending events. - * writing non-zero to intr-mbox-0 additional tells the + * Writing non-zero to intr-mbox-0 additional tells the * NIC to stop sending us irqs, engaging "in-intr-handler" * event coalescing. */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); + sblk->status &= ~SD_STATUS_UPDATED; + if (likely(tg3_has_work(tp))) + netif_rx_schedule(dev); /* schedule NAPI poll */ + else { + /* No work, shared interrupt perhaps? re-enable + * interrupts, and flush that PCI write + */ + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + 0x00000000); + tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + } + } else { /* shared interrupt */ + handled = 0; + } + + spin_unlock_irqrestore(&tp->lock, flags); + + return IRQ_RETVAL(handled); +} + +static irqreturn_t tg3_interrupt_tagged(int irq, void *dev_id, struct pt_regs *regs) +{ + struct net_device *dev = dev_id; + struct tg3 *tp = netdev_priv(dev); + struct tg3_hw_status *sblk = tp->hw_status; + unsigned long flags; + unsigned int handled = 1; + + spin_lock_irqsave(&tp->lock, flags); + + /* In INTx mode, it is possible for the interrupt to arrive at + * the CPU before the status block posted prior to the interrupt. + * Reading the PCI State register will confirm whether the + * interrupt is ours and will flush the status block. + */ + if ((sblk->status & SD_STATUS_UPDATED) || + !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) { /* - * Flush PCI write. This also guarantees that our - * status block has been flushed to host memory. + * writing any value to intr-mbox-0 clears PCI INTA# and + * chip-internal interrupt pending events. + * writing non-zero to intr-mbox-0 additional tells the + * NIC to stop sending us irqs, engaging "in-intr-handler" + * event coalescing. */ - tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, + 0x00000001); + tp->last_tag = sblk->status_tag; sblk->status &= ~SD_STATUS_UPDATED; - if (likely(tg3_has_work(tp))) netif_rx_schedule(dev); /* schedule NAPI poll */ else { @@ -2991,7 +3041,7 @@ static irqreturn_t tg3_interrupt(int irq * interrupts, and flush that PCI write */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, - 0x00000000); + tp->last_tag << 24); tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); } } else { /* shared interrupt */ @@ -5445,7 +5495,8 @@ static int tg3_reset_hw(struct tg3 *tp) udelay(100); tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0); - tr32(MAILBOX_INTERRUPT_0); + tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); + tp->last_tag = 0; if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { tw32_f(DMAC_MODE, DMAC_MODE_ENABLE); @@ -5723,31 +5774,33 @@ static void tg3_timer(unsigned long __op spin_lock_irqsave(&tp->lock, flags); spin_lock(&tp->tx_lock); - /* All of this garbage is because when using non-tagged - * IRQ status the mailbox/status_block protocol the chip - * uses with the cpu is race prone. - */ - if (tp->hw_status->status & SD_STATUS_UPDATED) { - tw32(GRC_LOCAL_CTRL, - tp->grc_local_ctrl | GRC_LCLCTRL_SETINT); - } else { - tw32(HOSTCC_MODE, tp->coalesce_mode | - (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW)); - } + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) { + /* All of this garbage is because when using non-tagged + * IRQ status the mailbox/status_block protocol the chip + * uses with the cpu is race prone. + */ + if (tp->hw_status->status & SD_STATUS_UPDATED) { + tw32(GRC_LOCAL_CTRL, + tp->grc_local_ctrl | GRC_LCLCTRL_SETINT); + } else { + tw32(HOSTCC_MODE, tp->coalesce_mode | + (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW)); + } - if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) { - tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER; - spin_unlock(&tp->tx_lock); - spin_unlock_irqrestore(&tp->lock, flags); - schedule_work(&tp->reset_task); - return; + if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) { + tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER; + spin_unlock(&tp->tx_lock); + spin_unlock_irqrestore(&tp->lock, flags); + schedule_work(&tp->reset_task); + return; + } } - if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) - tg3_periodic_fetch_stats(tp); - /* This part only runs once per second. */ if (!--tp->timer_counter) { + if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) + tg3_periodic_fetch_stats(tp); + if (tp->tg3_flags & TG3_FLAG_USE_LINKCHG_REG) { u32 mac_stat; int phy_event; @@ -5846,9 +5899,13 @@ static int tg3_test_interrupt(struct tg3 if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) err = request_irq(tp->pdev->irq, tg3_msi, SA_SAMPLE_RANDOM, dev->name, dev); - else - err = request_irq(tp->pdev->irq, tg3_interrupt, + else { + irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + fn = tg3_interrupt_tagged; + err = request_irq(tp->pdev->irq, fn, SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + } if (err) return err; @@ -5900,9 +5957,14 @@ static int tg3_test_msi(struct tg3 *tp) tp->tg3_flags2 &= ~TG3_FLG2_USING_MSI; - err = request_irq(tp->pdev->irq, tg3_interrupt, - SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + { + irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + fn = tg3_interrupt_tagged; + err = request_irq(tp->pdev->irq, fn, + SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + } if (err) return err; @@ -5948,7 +6010,13 @@ static int tg3_open(struct net_device *d if ((tp->tg3_flags2 & TG3_FLG2_5750_PLUS) && (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5750_AX) && (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5750_BX)) { - if (pci_enable_msi(tp->pdev) == 0) { + /* All MSI supporting chips should support tagged + * status. Assert that this is the case. + */ + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) { + printk(KERN_WARNING PFX "%s: MSI without TAGGED? " + "Not using MSI.\n", tp->dev->name); + } else if (pci_enable_msi(tp->pdev) == 0) { u32 msi_mode; msi_mode = tr32(MSGINT_MODE); @@ -5959,9 +6027,14 @@ static int tg3_open(struct net_device *d if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) err = request_irq(tp->pdev->irq, tg3_msi, SA_SAMPLE_RANDOM, dev->name, dev); - else - err = request_irq(tp->pdev->irq, tg3_interrupt, + else { + irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + fn = tg3_interrupt_tagged; + + err = request_irq(tp->pdev->irq, fn, SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); + } if (err) { if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) { @@ -5980,9 +6053,16 @@ static int tg3_open(struct net_device *d tg3_halt(tp, 1); tg3_free_rings(tp); } else { - tp->timer_offset = HZ / 10; - tp->timer_counter = tp->timer_multiplier = 10; - tp->asf_counter = tp->asf_multiplier = (10 * 120); + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + tp->timer_offset = HZ; + else + tp->timer_offset = HZ / 10; + + BUG_ON(tp->timer_offset > HZ); + tp->timer_counter = tp->timer_multiplier = + (HZ / tp->timer_offset); + tp->asf_counter = tp->asf_multiplier = + ((HZ / tp->timer_offset) * 120); init_timer(&tp->timer); tp->timer.expires = jiffies + tp->timer_offset; @@ -6005,6 +6085,7 @@ static int tg3_open(struct net_device *d if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) { err = tg3_test_msi(tp); + if (err) { spin_lock_irq(&tp->lock); spin_lock(&tp->tx_lock); @@ -8422,15 +8503,7 @@ static int __devinit tg3_get_invariants( if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG; - /* Only 5701 and later support tagged irq status mode. - * Also, 5788 chips cannot use tagged irq status. - * - * However, since we are using NAPI avoid tagged irq status - * because the interrupt condition is more difficult to - * fully clear in that mode. - */ tp->coalesce_mode = 0; - if (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_AX && GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_BX) tp->coalesce_mode |= HOSTCC_MODE_32BYTE; @@ -8494,6 +8567,18 @@ static int __devinit tg3_get_invariants( grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788M)) tp->tg3_flags2 |= TG3_FLG2_IS_5788; + if (!(tp->tg3_flags2 & TG3_FLG2_IS_5788) && + (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700)) + tp->tg3_flags |= TG3_FLAG_TAGGED_STATUS; + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) { + tp->coalesce_mode |= (HOSTCC_MODE_CLRTICK_RXBD | + HOSTCC_MODE_CLRTICK_TXBD); + + tp->misc_host_ctrl |= MISC_HOST_CTRL_TAGGED_STATUS; + pci_write_config_dword(tp->pdev, TG3PCI_MISC_HOST_CTRL, + tp->misc_host_ctrl); + } + /* these are limited to 10/100 only */ if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 && (grc_misc_cfg == 0x8000 || grc_misc_cfg == 0x4000)) || --- 1/drivers/net/tg3.h.~1~ 2005-05-09 15:51:32.000000000 -0700 +++ 2/drivers/net/tg3.h 2005-05-09 15:51:40.000000000 -0700 @@ -2023,6 +2023,7 @@ struct tg3 { struct tg3_hw_status *hw_status; dma_addr_t status_mapping; + u32 last_tag; u32 msg_enable; @@ -2068,6 +2069,7 @@ struct tg3 { u32 rx_offset; u32 tg3_flags; +#define TG3_FLAG_TAGGED_STATUS 0x00000001 #define TG3_FLAG_TXD_MBOX_HWBUG 0x00000002 #define TG3_FLAG_RX_CHECKSUMS 0x00000004 #define TG3_FLAG_USE_LINKCHG_REG 0x00000008 From andy.furniss@dsl.pipex.com Mon May 9 16:13:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 16:13:44 -0700 (PDT) Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49NDdOv005631 for ; Mon, 9 May 2005 16:13:40 -0700 Received: from [192.168.0.3] (81-178-211-36.dsl.pipex.com [81.178.211.36]) by ranger.systems.pipex.net (Postfix) with ESMTP id 18ABDE000134; Tue, 10 May 2005 00:13:13 +0100 (BST) Message-ID: <427FEEE7.2040104@dsl.pipex.com> Date: Tue, 10 May 2005 00:14:47 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Patrick McHardy Cc: Thomas Graf , Asim Shankar , netdev@oss.sgi.com Subject: Re: SFQ: Reordering? References: <7bca1cb5050506145344d16b1e@mail.gmail.com> <427BEAAE.409@trash.net> <427BF3C4.1030105@trash.net> <20050506230203.GI28419@postel.suug.ch> <427BFB72.7080407@trash.net> <20050507005851.GK28419@postel.suug.ch> <427C19C3.5030304@trash.net> In-Reply-To: <427C19C3.5030304@trash.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 955 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 370 Lines: 11 Patrick McHardy wrote: > It would be interesting to see this in real-life, when a single flow > is hashed to multiple buckets (it can be even more than two) and > each bucket has some packets queued, the result should look pretty > chaotic. It certainly hurts latency if used for ingress shaping, perturb nearly always makes the sender backoff and then burst. Andy. From shemminger@osdl.org Mon May 9 16:22:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 16:22:52 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j49NMiOv011112 for ; Mon, 9 May 2005 16:22:44 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j49NMFU3005302 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 9 May 2005 16:22:15 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j49NMEXr015099; Mon, 9 May 2005 16:22:14 -0700 Date: Mon, 9 May 2005 16:22:14 -0700 From: Stephen Hemminger To: Baruch Even Cc: netdev@oss.sgi.com, Baruch Even , Douglas Leith , "David S.Miller" Subject: [RFC] TCP congestion infrastructure Message-ID: <20050509162214.0a8c9ceb@dxpl.pdx.osdl.net> In-Reply-To: <20050506173729.20140.93205.37072@galon.ev-en.org> References: <20050506173729.20140.93205.37072@galon.ev-en.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 239 Lines: 5 I rebased the H-TCP patches on my current work and 2.6.12-rc4 and put them in http://developer.osdl.org/shemminger/patches/2.6.12-rc4-tcp/ Includes infrastructure and all the current variants: BIC, Westwood, Vegas plus H-TCP, Hybla From davem@davemloft.net Mon May 9 17:17:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 17:17:47 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4A0HgOv013037 for ; Mon, 9 May 2005 17:17:42 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVIQy-0000hj-25; Mon, 09 May 2005 17:17:12 -0700 Date: Mon, 09 May 2005 17:17:11 -0700 (PDT) Message-Id: <20050509.171711.75189002.davem@davemloft.net> To: shemminger@osdl.org Cc: baruch@ev-en.org, netdev@oss.sgi.com, doug.leith@nuim.ie Subject: Re: [RFC] TCP congestion infrastructure From: "David S. Miller" In-Reply-To: <20050509162214.0a8c9ceb@dxpl.pdx.osdl.net> References: <20050506173729.20140.93205.37072@galon.ev-en.org> <20050509162214.0a8c9ceb@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 957 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 700 Lines: 18 From: Stephen Hemminger Subject: [RFC] TCP congestion infrastructure Date: Mon, 9 May 2005 16:22:14 -0700 > I rebased the H-TCP patches on my current work and 2.6.12-rc4 and put them in > http://developer.osdl.org/shemminger/patches/2.6.12-rc4-tcp/ > > Includes infrastructure and all the current variants: BIC, Westwood, Vegas > plus H-TCP, Hybla I like it. Looks fine from here. This, along with the TSO reworking, will go in at the next opportunity which is likely 2.6.13 of course. I'm considering putting the TSO stuff into 2.6.12 because in many ways it is a bug fix, TSO is fairly broken without it. There are some loose ends I need to resolve first though. From sumit@elitecore.com Mon May 9 23:05:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 23:05:08 -0700 (PDT) Received: from elitecore.com ([203.88.135.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4A651Ov026538 for ; Mon, 9 May 2005 23:05:03 -0700 Received: (qmail 2165 invoked from network); 10 May 2005 05:49:29 -0000 Received: from unknown (HELO elitecore.com) ([127.0.0.1]) (envelope-sender ) by elitecore.com (qmail-ldap-1.03) with SMTP for ; 10 May 2005 05:49:29 -0000 Received: (qmail 2158 invoked from network); 10 May 2005 05:49:29 -0000 Received: from unknown (HELO sumit) ([192.168.1.57])(envelope-sender )by elitecore.com (qmail-ldap-1.03) with SMTPfor ; 10 May 2005 05:49:29 -0000 From: "Sumit" To: "'Jeff' R. Steinhagen" , Subject: RE: forcing a packet to go through hw net device Date: Tue, 10 May 2005 11:32:17 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <200505091458.42118.Jeff@steinhagen.ch> Importance: Normal X-imss-version: 2.19 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-archive-position: 958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sumit@elitecore.com Precedence: bulk X-list: netdev Content-Length: 748 Lines: 24 Check out netfilter ROUTE target. All the best, -- Sumit > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com]On > Behalf Of 'Jeff' R. Steinhagen > > Hi! > > I have a (maybe trivial) question about the kernel's networking code: > > A packet with an "outside" destination goes through all layers > including the > hardware interface (user->socket->protocol->IP->HW). However if > the packet is > addressed to a local IP the transport through and checks by the hardware > layer are avoided. This is perfectly OK for "normal" network usage. > > I am profiling some network hardware and related code. Is it > possible to force > an internally generated packet to be send through all/the hardware layers? > From dtor_core@ameritech.net Mon May 9 23:19:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 May 2005 23:19:25 -0700 (PDT) Received: from smtp802.mail.sc5.yahoo.com (smtp802.mail.sc5.yahoo.com [66.163.168.181]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4A6JDOv027468 for ; Mon, 9 May 2005 23:19:13 -0700 Received: from unknown (HELO core.corenet.prv) (dtor?core@ameritech.net@68.23.10.155 with plain) by smtp802.mail.sc5.yahoo.com with SMTP; 10 May 2005 06:18:49 -0000 From: Dmitry Torokhov To: Evgeniy Polyakov Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Date: Tue, 10 May 2005 01:18:46 -0500 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan References: <20050411125932.GA19538@uganda.factory.vocord.ru> In-Reply-To: <20050411125932.GA19538@uganda.factory.vocord.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505100118.48027.dtor_core@ameritech.net> X-archive-position: 959 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtor_core@ameritech.net Precedence: bulk X-list: netdev Content-Length: 19020 Lines: 702 On Monday 11 April 2005 07:59, Evgeniy Polyakov wrote: > /*****************************************/ > Kernel Connector. > /*****************************************/ > > Kernel connector - new netlink based userspace <-> kernel space easy to use communication module. > Hi Evgeniy, I have looked at the connector implementation one more time and I think it can be improved in the following ways: - drop unneeded refcounting; - start only one workqueue entry instead of one for every callback type; - drop cn_dev - there is only one connector; - simplify cn_notify_request to carry only one range - it simplifies code quite a bit - nothing stops clientd from sending several notification requests; - implement internal queuefor callbacks so we are not at mercy of scheduler; - admit that SKBs are message medium and do not mess up with passing around destructor functions. - In callback notifier switch to using GFP_KERNEL since it can sleep just fine; - more... Because there were a lot of changes I decided against doing relative patch but instead a replacement patch for affected files. I have cut out cbus and documentation to keep it smaller so it will be easier to review. The patch is compile-tested only. BTW, I do not think that "All rights reserved" statement is applicable/ compatible with GPL this software is supposedly released under, I have taken liberty of removing this statement. > +/* > + * connector.c > + * > + * 2004 Copyright (c) Evgeniy Polyakov > + * All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. Please look it over. -- Dmitry drivers/Kconfig | 2 drivers/Makefile | 2 drivers/connector/Kconfig | 12 + drivers/connector/Makefile | 1 drivers/connector/connector.c | 481 ++++++++++++++++++++++++++++++++++++++++++ include/linux/connector.h | 103 ++++++++ 6 files changed, 601 insertions(+) Index: dtor/drivers/connector/connector.c =================================================================== --- /dev/null +++ dtor/drivers/connector/connector.c @@ -0,0 +1,481 @@ +/* + * connector.c + * + * 2004 Copyright (c) Evgeniy Polyakov + * 2005 Copyright (c) Dmitry Torokhov + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Evgeniy Polyakov "); +MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector."); + +static int unit = NETLINK_NFLOG; +module_param(unit, int, 0); +MODULE_PARM_DESC(unit, "Netlink socket to use."); + +static u32 cn_idx = CN_IDX_CONNECTOR; +module_param_named(idx, cn_idx, uint, 0); +MODULE_PARM_DESC(idx, "Connector's main device idx."); + +static u32 cn_val = CN_VAL_CONNECTOR; +module_param_named(val, cn_val, uint, 0); +MODULE_PARM_DESC(val, "Connector's main device val."); + +static u32 cn_max_backlog = 100; +module_param_named(max_backlog, cn_max_backlog, uint, 0); +MODULE_PARM_DESC(max_backlog, "Connector's maximum request backlog."); + +static LIST_HEAD(notify_list); +static DECLARE_MUTEX(notify_list_lock); + +static LIST_HEAD(callback_list); +static DEFINE_SPINLOCK(callback_list_lock); + +static struct sock *cn_netlink_socket; +static struct workqueue_struct *cn_workqueue; +static struct cb_id cn_id; +static int cn_initialized; + +#define DEBUG +#define PFX "connector: " + +#ifdef DEBUG +#define dprintk(fmt, args...) printk(KERN_DEBUG PFX "%s: " fmt, \ + __FUNCTION__, ## args) +#else +#define dprintk(fmt, args...) +#endif + +/* + * cn_cb_equal() - checks whether 2 callback IDs are equal. + */ +static inline int cn_cb_equal(struct cb_id *i1, struct cb_id *i2) +{ + dprintk("comparing %04x.%04x and %04x.%04x\n", + i1->idx, i1->val, + i2->idx, i2->val); + + return i1->idx == i2->idx && i1->val == i2->val; +} + +/* + * cn_find_callback() - locates registered callback structure + * by its id. Caller must hold callback_list_lock. + */ +static struct cn_callback *cn_find_callback(struct cb_id *id) +{ + struct cn_callback *cb; + + list_for_each_entry(cb, &callback_list, node) + if (cn_cb_equal(&cb->id, id)) + return cb; + + return NULL; +} + +/* + * msg->seq and msg->ack are used to determine message genealogy. + * When someone sends message it puts there locally unique sequence + * and random acknowledge numbers. + * Sequence number may also be copied into nlmsghdr->nlmsg_seq. + * + * Sequence number is incremented with each message to be sent. + * + * If we expect reply to our message, + * then sequence number in received message MUST be the same as in + * original message, and acknowledge number MUST be the same + 1. + * + * If we receive a message and it's sequence number is not equal to + * the one we are expecting, then it is new message. + * If we receive a message and it's sequence number is the same as + * the one we are expecting, but it's acknowledge is not equal to the + * acknowledge number in original message + 1, then it is ialso a new + * message. + */ +int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask) +{ + struct cn_callback *cb; + struct sk_buff *skb; + struct nlmsghdr *nlh; + unsigned int size; + u32 groups = 0; + + if (!cn_initialized) + return -EAGAIN; + + if (!__groups) { + spin_lock_bh(&callback_list_lock); + cb = cn_find_callback(&msg->id); + if (cb) + groups = cb->group; + spin_unlock_bh(&callback_list_lock); + + if (!cb) { + dprintk("Failed to find callback %#x.%#x, seq=%u\n", + msg->id.idx, msg->id.val, msg->seq); + return -ENODEV; + } + } + else + groups = __groups; + + size = sizeof(struct cn_msg) + msg->len; + + skb = alloc_skb(NLMSG_SPACE(size), gfp_mask); + if (!skb) { + printk(KERN_ERR PFX "Failed to allocate skb with size=%u\n", + NLMSG_SPACE(size)); + return -ENOMEM; + } + + dprintk("len=%u, seq=%u, ack=%u, group=%u.\n", + msg->len, msg->seq, msg->ack, groups); + + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size); + memcpy(NLMSG_DATA(nlh), msg, sizeof(struct cn_msg) + msg->len); + + NETLINK_CB(skb).dst_groups = groups; + + netlink_broadcast(cn_netlink_socket, skb, 0, groups, gfp_mask); + return 0; + + nlmsg_failure: + kfree_skb(skb); + return -ENOMEM; +} + +/* + * cn_execute_callback() - executes callback and frees associated + * skb and work structures. + */ +static void cn_execute_callback(void *data) +{ + struct cn_callback_work *cb_work = data; + + cb_work->cb->callback(cb_work->msg->data); + + spin_lock_bh(&callback_list_lock); + cb_work->cb->requests--; + spin_unlock_bh(&callback_list_lock); + + kfree_skb(cb_work->skb); + kfree(cb_work); +} + +/* + * cn_schedule_callback() - allocates work structure and + * schedules callback for execution on cn_workqueue + */ +static int cn_schedule_callback(struct sk_buff *skb) +{ + struct nlmsghdr *nlh = (struct nlmsghdr *)skb->data; + struct cn_msg *msg = NLMSG_DATA(nlh); + struct cn_callback_work *cb_work; + struct cn_callback *cb; + int error; + + cb_work = kcalloc(1, sizeof(struct cn_callback_work), GFP_KERNEL); + if (!cb_work) + return -ENOMEM; + + spin_lock_bh(&callback_list_lock); + cb = cn_find_callback(&msg->id); + if (!cb) + error = -ENODEV; + else if (cb->requests >= cn_max_backlog) + error = -ENOSPC; + else { + cb_work->cb = cb; + cb_work->msg = msg; + cb_work->skb = skb_get(skb); + INIT_WORK(&cb_work->work, cn_execute_callback, cb_work); + queue_work(cn_workqueue, &cb_work->work); + cb->requests++; + error = 0; + } + spin_unlock_bh(&callback_list_lock); + + if (error) + kfree(cb_work); + + return error; +} + +/* + * cn_validate_skb() - performs basic checks on skb to ensure + * that received message has correct structure. + */ +static int cn_validate_skb(struct sk_buff *skb) +{ + struct nlmsghdr *nlh; + struct cn_msg *msg; + + dprintk("skb: len=%u, data_len=%u, truesize=%u, proto=%u, " + "cloned=%d, shared=%d\n", + skb->len, skb->data_len, skb->truesize, skb->protocol, + skb_cloned(skb), skb_shared(skb)); + + if (skb->len < NLMSG_SPACE(0)) { + printk(KERN_ERR PFX "empty skb received\n"); + return -EINVAL; + } + + nlh = (struct nlmsghdr *)skb->data; + if (skb->len < nlh->nlmsg_len) { + printk(KERN_ERR PFX + "skb is too short, skb_len=%u, nlmsg_len=%u\n", + skb->len, nlh->nlmsg_len); + return -EINVAL; + } + + msg = (struct cn_msg *)NLMSG_DATA(nlh); + if (NLMSG_SPACE(msg->len + sizeof(*msg)) != nlh->nlmsg_len) { + printk(KERN_ERR PFX "invalid netlink message length, " + "msg->len=%u[%u], nlh->nlmsg_len=%u\n", + msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)), + nlh->nlmsg_len); + return -EINVAL; + } + + dprintk("pid=%u, uid=%u, seq=%u, group=%u\n", + NETLINK_CREDS(skb)->pid, NETLINK_CREDS(skb)->uid, + nlh->nlmsg_seq, NETLINK_CB((skb)).groups); + + return 0; +} + +/* + * cn_input() - netlink socket input handler. Dequeues skb and, + * after validating reveived data, schedules requested callback + * for subsequent execution. + */ +static void cn_input(struct sock *sk, int len) +{ + struct sk_buff *skb; + + while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL) { + if (cn_validate_skb(skb)) + cn_schedule_callback(skb); + + kfree_skb(skb); + } +} + +/* + * cn_notify() - notifies registered listeners about an event. + * Currently is used to notify userspace about add/remove callback + * requests being processed by connector. + */ +static void cn_notify(struct cb_id *id, u32 notify_event) +{ + struct cn_notify_entry *entry; + struct cn_notify_req *req; + struct cn_msg notify_msg; + + down(¬ify_list_lock); + list_for_each_entry(entry, ¬ify_list, node) { + + req = &entry->req; + + if (id->idx >= req->idx_first && + id->idx < req->idx_first + req->idx_range && + id->val >= req->val_first && + id->val < req->val_first + req->val_range) { + + dprintk("Notifying group %x - %#x.%#x: event %u\n", + req->group, id->idx, id->val, notify_event); + + memset(¬ify_msg, 0, sizeof(notify_msg)); + notify_msg.id = *id; + notify_msg.ack = notify_event; + + cn_netlink_send(¬ify_msg, req->group, GFP_KERNEL); + } + } + up(¬ify_list_lock); +} + +/* + * cn_add_callback() - installs callback with specified callback ID + */ +int cn_add_callback(struct cb_id *id, char *name, void (*callback)(void *)) +{ + struct cn_callback *cb; + int retval = 0; + + cb = kcalloc(1, sizeof(struct cn_callback), GFP_KERNEL); + if (!cb) { + printk(KERN_ERR PFX + "Failed to allocate new struct cn_callback\n"); + return -ENOMEM; + } + + cb->id = *id; + snprintf(cb->name, sizeof(cb->name), "%s", name); + cb->callback = callback; + + spin_lock_bh(&callback_list_lock); + if (cn_find_callback(id)) { + kfree(cb); + retval = -EEXIST; + } else + list_add_tail(&cb->node, &callback_list); + spin_unlock_bh(&callback_list_lock); + + if (retval == 0) + cn_notify(id, 0); + + return retval; +} + +/* + * cn_del_callback() - deletes callback with specified callback ID + * Will wait until all scheduled instances of the callback complete. + */ +void cn_del_callback(struct cb_id *id) +{ + struct cn_callback *cb; + + spin_lock_bh(&callback_list_lock); + cb = cn_find_callback(id); + if (cb) + list_del(&cb->node); + spin_unlock_bh(&callback_list_lock); + + if (cb) { + flush_workqueue(cn_workqueue); + kfree(cb); + cn_notify(id, 1); + } else + printk(KERN_WARNING PFX + "Attempting do delete non-existing callback %x/%x\n", + id->idx, id->val); +} + +/* + * cn_notify_req_same() - compares two connector notify requestes + */ +static inline int cn_notify_req_same(struct cn_notify_req *r1, + struct cn_notify_req *r2) +{ + return r1->group == r2->group && + r1->idx_first == r2->idx_first && + r1->idx_range == r2->idx_range && + r1->val_first == r2->val_first && + r1->val_range == r2->val_range; +} + +/* + * cn_connector_callback() - callback installed and used by connector + * itself to manage connector notification requests. + */ +static void cn_connector_callback(void *data) +{ + struct cn_msg *msg = data; + struct cn_notify_req *req; + struct cn_notify_entry *entry; + int found = 0; + + if (msg->len != sizeof(struct cn_notify_req)) { + printk(KERN_ERR PFX + "Wrong notify request size (%u, must be %u)\n", + msg->len, sizeof(struct cn_notify_req)); + return; + } + + req = (struct cn_notify_req *)msg->data; + + down(¬ify_list_lock); + + list_for_each_entry(entry, ¬ify_list, node) { + if (cn_notify_req_same(&entry->req, req)) { + list_del(&entry->node); + kfree(entry); + found = 1; + break; + } + } + + if (!found) { + entry = kcalloc(1, sizeof(*entry), GFP_KERNEL); + if (!entry) + printk(KERN_ERR PFX + "Failed to allocate new notify entry\n"); + else { + entry->req = *req; + list_add_tail(&entry->node, ¬ify_list); + } + } + + up(¬ify_list_lock); +} + +static int cn_init(void) +{ + int error; + + cn_workqueue = create_workqueue("cqueue"); + if (!cn_workqueue) { + printk(KERN_ERR PFX "Failed to create workqueue\n"); + return -ENOMEM; + } + + cn_netlink_socket = netlink_kernel_create(unit, cn_input); + if (!cn_netlink_socket) { + printk(KERN_ERR PFX + "Failed to create new netlink socket(%u)\n", unit); + destroy_workqueue(cn_workqueue); + return -ENOMEM; + } + + cn_id.idx = cn_idx; + cn_id.val = cn_val; + error = cn_add_callback(&cn_id, "connector", cn_connector_callback); + if (error) { + printk(KERN_ERR PFX "Failed to install 'connector' callback\n"); + sock_release(cn_netlink_socket->sk_socket); + destroy_workqueue(cn_workqueue); + return error; + } + + cn_initialized = 1; + return 0; +} + +static void cn_exit(void) +{ + cn_del_callback(&cn_id); + sock_release(cn_netlink_socket->sk_socket); + destroy_workqueue(cn_workqueue); +} + +module_init(cn_init); +module_exit(cn_exit); + +EXPORT_SYMBOL_GPL(cn_add_callback); +EXPORT_SYMBOL_GPL(cn_del_callback); +EXPORT_SYMBOL_GPL(cn_netlink_send); Index: dtor/drivers/connector/Makefile =================================================================== --- /dev/null +++ dtor/drivers/connector/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_CONNECTOR) += connector.o Index: dtor/drivers/connector/Kconfig =================================================================== --- /dev/null +++ dtor/drivers/connector/Kconfig @@ -0,0 +1,12 @@ +menu "Connector - unified userspace <-> kernelspace linker" + +config CONNECTOR + tristate "Connector - unified userspace <-> kernelspace linker" + depends on NET + ---help--- + This is unified userspace <-> kernelspace connector working on top + of the netlink socket protocol. + + Connector support can also be built as a module. If so, the module + will be called connector.ko. +endmenu Index: dtor/include/linux/connector.h =================================================================== --- /dev/null +++ dtor/include/linux/connector.h @@ -0,0 +1,103 @@ +/* + * connector.h + * + * 2004 Copyright (c) Evgeniy Polyakov + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __CONNECTOR_H +#define __CONNECTOR_H + +#include + +#define CN_IDX_CONNECTOR 0xffffffff +#define CN_VAL_CONNECTOR 0xffffffff + +/* + * idx and val are unique identifiers which + * are used for message routing and + * must be registered in connector.h for in-kernel usage. + */ + +struct cb_id +{ + __u32 idx; + __u32 val; +}; + +struct cn_msg +{ + struct cb_id id; + + __u32 seq; + __u32 ack; + + __u32 len; /* Length of the following data */ + __u8 data[0]; +}; + +/* + * Notify structure - requests notification about + * registering/unregistering idx/val in range [first, first+range). + */ +struct cn_notify_req +{ + __u32 group; + __u32 idx_first, idx_range; + __u32 val_first, val_range; +}; + +#ifdef __KERNEL__ + +#include + +#include +#include + +#include + +#define CN_CBQ_NAMELEN 32 + +struct cn_callback +{ + struct cb_id id; + unsigned char name[CN_CBQ_NAMELEN]; + int group; + void (*callback)(void *); + int requests; + struct list_head node; +}; + +struct cn_callback_work { + struct cn_callback *cb; + struct cn_msg *msg; + struct sk_buff *skb; + struct work_struct work; +}; + +struct cn_notify_entry +{ + struct list_head node; + struct cn_notify_req req; +}; + +int cn_add_callback(struct cb_id *, char *, void (* callback)(void *)); +void cn_del_callback(struct cb_id *); +int cn_netlink_send(struct cn_msg *, u32, int); + +#endif /* __KERNEL__ */ +#endif /* __CONNECTOR_H */ Index: dtor/drivers/Makefile =================================================================== --- dtor.orig/drivers/Makefile +++ dtor/drivers/Makefile @@ -17,6 +17,8 @@ obj-$(CONFIG_PNP) += pnp/ # default. obj-y += char/ +obj-$(CONFIG_CONNECTOR) += connector/ + # i810fb and intelfb depend on char/agp/ obj-$(CONFIG_FB_I810) += video/i810/ obj-$(CONFIG_FB_INTEL) += video/intelfb/ Index: dtor/drivers/Kconfig =================================================================== --- dtor.orig/drivers/Kconfig +++ dtor/drivers/Kconfig @@ -4,6 +4,8 @@ menu "Device Drivers" source "drivers/base/Kconfig" +source "drivers/connector/Kconfig" + source "drivers/mtd/Kconfig" source "drivers/parport/Kconfig" From Jeff@steinhagen.ch Tue May 10 00:57:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 00:57:29 -0700 (PDT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4A7vOOv002937 for ; Tue, 10 May 2005 00:57:25 -0700 Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IG90061MKR0RW@ms-dienst.rz.rwth-aachen.de> for netdev@oss.sgi.com; Tue, 10 May 2005 09:57:00 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Tue, 10 May 2005 09:56:59 +0200 (MEST) Received: from PCAB20.cern.ch (pcab20.cern.ch [137.138.196.37]) by relay.rwth-aachen.de (8.13.3/8.13.3/1) with ESMTP id j4A7upW7024891; Tue, 10 May 2005 09:56:59 +0200 (MEST) Date: Tue, 10 May 2005 08:21:12 +0200 From: "'Jeff' R. Steinhagen" Subject: Re: forcing a packet to go through hw net device In-reply-to: To: Sumit Cc: netdev@oss.sgi.com Message-id: <200505100821.12636.Jeff@steinhagen.ch> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7.1 References: X-archive-position: 969 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Jeff@steinhagen.ch Precedence: bulk X-list: netdev Content-Length: 1377 Lines: 46 Hi! Thanks. The binding to a specific device does not seem to solve the problem. The bypass seem to be behind the filter layer. It know that it works if the packet is created on the device level itself, but I would like to ("cleanly") profile the whole closed loop including the _physical_ device: application->socket1-> ...kernel...-> physical layer -> .. kernel..-> socket2 -> application without bypassing e.g. the arp. Hoped to avoid modifying and temporarily removing the bypass from the kernel (-> ugly hack). Cheers, Jeff On Tuesday 10 May 2005 08:02, you wrote: > Check out netfilter ROUTE target. > All the best, > -- Sumit > > > -----Original Message----- > > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com]On > > Behalf Of 'Jeff' R. Steinhagen > > > > Hi! > > > > I have a (maybe trivial) question about the kernel's networking code: > > > > A packet with an "outside" destination goes through all layers > > including the > > hardware interface (user->socket->protocol->IP->HW). However if > > the packet is > > addressed to a local IP the transport through and checks by the hardware > > layer are avoided. This is perfectly OK for "normal" network usage. > > > > I am profiling some network hardware and related code. Is it > > possible to force > > an internally generated packet to be send through all/the hardware > > layers? From mperaya@alcazaba.unex.es Tue May 10 02:33:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 02:33:57 -0700 (PDT) Received: from www.fcdyc.unex.es (alcazaba.unex.es [158.49.151.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4A9XqOv006667 for ; Tue, 10 May 2005 02:33:53 -0700 Received: from webmail.fcdyc.unex.es ([158.49.151.11] ident=Debian-exim) by www.fcdyc.unex.es with esmtp (Exim 4.50) id 1DVR6y-000309-JQ for netdev@oss.sgi.com; Tue, 10 May 2005 11:33:08 +0200 Received: from www-data by webmail.fcdyc.unex.es with local (Exim 4.50) id 1DVR6y-0001SQ-Gs for netdev@oss.sgi.com; Tue, 10 May 2005 11:33:08 +0200 Received: from tecno-1.fcdyc.unex.es (tecno-1.fcdyc.unex.es [158.49.151.18]) by 158.49.151.11 (Horde MIME library) with HTTP for ; Tue, 10 May 2005 11:33:08 +0200 Message-ID: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> X-Priority: 3 (Normal) Date: Tue, 10 May 2005 11:33:08 +0200 From: Manuel Perez Ayala To: netdev@oss.sgi.com Subject: tg3 support broken on PPC, a workaround MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-FCDyC-UEx-MailScanner: Found to be clean X-FCDyC-UEx-MailScanner-From: mperaya@alcazaba.unex.es Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4A9XqOv006667 X-archive-position: 970 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mperaya@alcazaba.unex.es Precedence: bulk X-list: netdev Content-Length: 4777 Lines: 138 Hello, Since linux kernel 2.6.8 the tg3 support was broken on my PPC machines (Power Mac G4 silver) with data corruption. After a while finally I've found the code responsible of my problems: On debian kernel 2.6.8 in the tg3.c file, at line 7356 (inside the tg3_test_dma function) there are a conditional piece of code that compiles only if the platform is NOT 386: #ifndef CONFIG_X86 { u8 byte; int cacheline_size; pci_read_config_byte(tp->pdev, PCI_CACHE_LINE_SIZE, &byte); if (byte == 0) cacheline_size = 1024; else cacheline_size = (int) byte * 4; switch (cacheline_size) { case 16: case 32: case 64: case 128: if ((tp->tg3_flags & TG3_FLAG_PCIX_MODE) && !(tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS)) { tp->dma_rwctrl |= DMA_RWCTRL_WRITE_BNDRY_384_PCIX; break; } else if (tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS) { tp->dma_rwctrl &= ~(DMA_RWCTRL_PCI_WRITE_CMD); tp->dma_rwctrl |= DMA_RWCTRL_WRITE_BNDRY_128_PCIE; break; } /* fallthrough */ case 256: if (!(tp->tg3_flags & TG3_FLAG_PCIX_MODE) && !(tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS)) tp->dma_rwctrl |= DMA_RWCTRL_WRITE_BNDRY_256; else if (!(tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS)) tp->dma_rwctrl |= DMA_RWCTRL_WRITE_BNDRY_256_PCIX; }; } #endif This has changed from version 2.6.7 (also Debian dist). At line 6964 (inside the same function) was: #ifndef CONFIG_X86 { u8 byte; int cacheline_size; pci_read_config_byte(tp->pdev, PCI_CACHE_LINE_SIZE, &byte); if (byte == 0) cacheline_size = 1024; else cacheline_size = (int) byte * 4; tp->dma_rwctrl &= ~(DMA_RWCTRL_READ_BNDRY_MASK | DMA_RWCTRL_WRITE_BNDRY_MASK); switch (cacheline_size) { case 16: tp->dma_rwctrl |= (DMA_RWCTRL_READ_BNDRY_16 | DMA_RWCTRL_WRITE_BNDRY_16); break; case 32: tp->dma_rwctrl |= (DMA_RWCTRL_READ_BNDRY_32 | DMA_RWCTRL_WRITE_BNDRY_32); break; case 64: tp->dma_rwctrl |= (DMA_RWCTRL_READ_BNDRY_64 | DMA_RWCTRL_WRITE_BNDRY_64); break; case 128: tp->dma_rwctrl |= (DMA_RWCTRL_READ_BNDRY_128 | DMA_RWCTRL_WRITE_BNDRY_128); break; case 256: tp->dma_rwctrl |= (DMA_RWCTRL_READ_BNDRY_256 | DMA_RWCTRL_WRITE_BNDRY_256); break; case 512: tp->dma_rwctrl |= (DMA_RWCTRL_READ_BNDRY_512 | DMA_RWCTRL_WRITE_BNDRY_512); break; case 1024: tp->dma_rwctrl |= (DMA_RWCTRL_READ_BNDRY_1024 | DMA_RWCTRL_WRITE_BNDRY_1024); break; }; } #endif If I replace the 2.6.8 piece of code with the 2.6.7 one and compile the code, it seems to work without problems of data corruption. Perhaps is there a better solution adding or modifiyng only certain 2.6.8 code to make the thinks works, but this works for me. If anybody can sugest anything about it I will be very happy to try and report anything about it. Thanks. ---------- Manuel Perez Ayala mperaya@alcazaba.unex.es Facultad de Biblioteconomía y Documentación Universidad de Extremadura From johnpol@2ka.mipt.ru Tue May 10 03:06:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 03:06:46 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AA6YOv008250 for ; Tue, 10 May 2005 03:06:37 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with ESMTP id j4AA4r1R032439; Tue, 10 May 2005 14:04:53 +0400 Date: Tue, 10 May 2005 14:04:45 +0400 From: Evgeniy Polyakov To: Dmitry Torokhov Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050510140445.36cc15cb@zanzibar.2ka.mipt.ru> In-Reply-To: <200505100118.48027.dtor_core@ameritech.net> References: <20050411125932.GA19538@uganda.factory.vocord.ru> <200505100118.48027.dtor_core@ameritech.net> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Tue, 10 May 2005 14:04:57 +0400 (MSD) X-archive-position: 971 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2725 Lines: 84 On Tue, 10 May 2005 01:18:46 -0500 Dmitry Torokhov wrote: > On Monday 11 April 2005 07:59, Evgeniy Polyakov wrote: > > /*****************************************/ > > Kernel Connector. > > /*****************************************/ > > > > Kernel connector - new netlink based userspace <-> kernel space easy to use communication module. > > > > Hi Evgeniy, Hello, Dmitriy. > I have looked at the connector implementation one more time and I think > it can be improved in the following ways: > > - drop unneeded refcounting; It is already. > - start only one workqueue entry instead of one for every callback type; There is only one queue per callback device. > - drop cn_dev - there is only one connector; There may be several connectors with different socket types. I use it in my environment for tests. > - simplify cn_notify_request to carry only one range - it simplifies code > quite a bit - nothing stops clientd from sending several notification > requests; ? Nothing stops clients from sending several notification requests now. I do not see how it simplifies the things? Feel free to set idx_num and val_num to 1 and you will have the same. > - implement internal queuefor callbacks so we are not at mercy of scheduler; Current implementation has big warning about such theoretical behaviour, if it will be triggered, I will fix that behaviour, more likely not by naive work allocation - there might be at least cache/memory pool or something... > - admit that SKBs are message medium and do not mess up with passing around > destructor functions. You mess up layers. I do not see why you want it. > - In callback notifier switch to using GFP_KERNEL since it can sleep just > fine; Yes, it is correct > - more... > > Because there were a lot of changes I decided against doing relative patch > but instead a replacement patch for affected files. I have cut out cbus and > documentation to keep it smaller so it will be easier to review. The patch > is compile-tested only. Connector with your changes just does not work. Dmitry, I do not understand why do you change things in so radical manner, especially when there are no 1. new interesting features, 2. no performance improvements, 3. no right design changes. > BTW, I do not think that "All rights reserved" statement is applicable/ > compatible with GPL this software is supposedly released under, I have > taken liberty of removing this statement. You substitute license agreements with copyright. "All rights reserved" is targeted to copyright (avtorskoe pravo, zakon N 5351/1-1) of the code and has nothing with license. Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From horms@koto.vergenet.net Tue May 10 03:47:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 03:47:09 -0700 (PDT) Received: from koto.vergenet.net (koto.vergenet.net [210.128.90.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AAl5Ov009972 for ; Tue, 10 May 2005 03:47:05 -0700 Received: by koto.vergenet.net (Postfix, from userid 7100) id D81B43402B; Tue, 10 May 2005 19:20:14 +0900 (JST) Date: Tue, 10 May 2005 19:44:37 +0900 From: Horms To: Ross Combs , netdev@oss.sgi.com Subject: Re: Small 2.6.11.8 airo.c issue Message-ID: <20050510104437.GB27913@verge.net.au> Mail-Followup-To: Ross Combs , netdev@oss.sgi.com References: <427C3FBD.mailOLE1FRMAW@hongkong> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427C3FBD.mailOLE1FRMAW@hongkong> X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i X-archive-position: 972 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: horms@verge.net.au Precedence: bulk X-list: netdev Content-Length: 3783 Lines: 109 On Fri, May 06, 2005 at 11:10:37PM -0500, Ross Combs wrote: > I ran into a small configuration problem a couple of days ago while > using menuconfig to setup a new kernel for my laptop. Basically, > it refused to show the airo.c driver as an option. After looking > at the Kconfig files I figured out it was because I did not have ISA > enabled -- but I'm not using an ISA version of the card so it should > not be a dependency. > > I originally reported it to Jean Tourrilhes but he said that netdev > would be a better place to send it and that Javier might know why it > was added. My original message is included below. > > > > I just upgraded my system to a recent 2.6 kernel and noticed a small > > bug in the configuration for the airo.c driver. It now requires > > that ISA be enabled, though it is not a requirement for all hardware > > using that driver. In my case, I'm using an IBM T30 laptop with a > > mini-PCI card. > > > > Once I edited the Kconfig file to remove the ISA dependency (maybe it > > should be an OR instead of an AND but removing it was easier for a > > local change), I was able to select the driver. It compiled without > > problems and I'm using it successfully with encryption for the first > > time ever. > > > > I'm very happy with the new driver. > > > > Please let me know if this is not the right place to report bugs. I > > just mailed the people listed in the source code. > > Thanks, > -Ross This patch might help your cause. Though I note that airo is marked as broken unless pci is enabled, makes me wonder if isa cards work at all. -- Horms drivers/net/wireless/Kconfig: needs update drivers/net/wireless/airo.c: needs update Index: drivers/net/wireless/Kconfig =================================================================== --- eed337ef5e9ae7d62caa84b7974a11fddc7f06e0/drivers/net/wireless/Kconfig (mode:100644) +++ uncommitted/drivers/net/wireless/Kconfig (mode:100644) @@ -139,7 +139,7 @@ config AIRO tristate "Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards" - depends on NET_RADIO && ISA && (PCI || BROKEN) + depends on NET_RADIO && (PCI || BROKEN) ---help--- This is the standard Linux driver to support Cisco/Aironet ISA and PCI 802.11 wireless cards. Index: drivers/net/wireless/airo.c =================================================================== --- eed337ef5e9ae7d62caa84b7974a11fddc7f06e0/drivers/net/wireless/airo.c (mode:100644) +++ uncommitted/drivers/net/wireless/airo.c (mode:100644) @@ -217,8 +217,10 @@ static int basic_rate; static char *ssids[3]; +#ifdef CONFIG_ISA static int io[4]; static int irq[4]; +#endif static int maxencrypt /* = 0 */; /* The highest rate that the card can encrypt at. @@ -245,8 +247,10 @@ for PCMCIA when used with airo_cs."); MODULE_LICENSE("Dual BSD/GPL"); MODULE_SUPPORTED_DEVICE("Aironet 4500, 4800 and Cisco 340/350"); +#ifdef CONFIG_ISA module_param_array(io, int, NULL, 0); module_param_array(irq, int, NULL, 0); +#endif module_param(basic_rate, int, 0); module_param_array(rates, int, NULL, 0); module_param_array(ssids, charp, NULL, 0); @@ -5542,7 +5546,10 @@ static int __init airo_init_module( void ) { - int i, have_isa_dev = 0; + int i; +#ifdef CONFIG_ISA + int have_isa_dev = 0; +#endif airo_entry = create_proc_entry("aironet", S_IFDIR | airo_perm, @@ -5550,6 +5557,7 @@ airo_entry->uid = proc_uid; airo_entry->gid = proc_gid; +#ifdef CONFIG_ISA for( i = 0; i < 4 && io[i] && irq[i]; i++ ) { printk( KERN_INFO "airo: Trying to configure ISA adapter at irq=%d io=0x%x\n", @@ -5557,6 +5565,7 @@ if (init_airo_card( irq[i], io[i], 0, NULL )) have_isa_dev = 1; } +#endif #ifdef CONFIG_PCI printk( KERN_INFO "airo: Probing for PCI adapters\n" ); From chamas@h4.dion.ne.jp Tue May 10 05:44:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 05:44:23 -0700 (PDT) Received: from hfep06.dion.ne.jp (hfep06.dion.ne.jp [203.181.105.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ACiJOv018066 for ; Tue, 10 May 2005 05:44:20 -0700 Received: from localhost ([221.119.91.194]) by hfep06.dion.ne.jp with ESMTP id <20050510124335053.BZGU@hfep06.dion.ne.jp> for ; Tue, 10 May 2005 21:43:35 +0900 Date: Tue, 10 May 2005 21:43:32 +0900 (JST) Message-Id: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> To: netdev@oss.sgi.com Subject: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) From: Ken-ichirou MATSUZAWA X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_May_10_21_43_32_2005_990)--" Content-Transfer-Encoding: 7bit X-archive-position: 973 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chamas@h4.dion.ne.jp Precedence: bulk X-list: netdev Content-Length: 2291 Lines: 96 ----Next_Part(Tue_May_10_21_43_32_2005_990)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello. Everytime on shutting down, the subject message is logged. It seems that the reason is do_one_broadcast may preempt netlink_recvmsg. Added patch to 2.6.12-rc4 seems resolving this problem. But I'm not a kernel hacker. I don't understand design, detail and the intenstion of struct netlink_broadcast_data, so that I hope someone to do more tidy work. In addition, please check 2.4 kernel and pfkey_broadcast_one too. Thanks. ----Next_Part(Tue_May_10_21_43_32_2005_990)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="af_netlink.diff" --- net/netlink/af_netlink.c.orig 2005-05-10 21:03:11.000000000 +0900 +++ net/netlink/af_netlink.c 2005-05-10 21:10:39.000000000 +0900 @@ -721,7 +721,7 @@ int congested; int delivered; int allocation; - struct sk_buff *skb, *skb2; + struct sk_buff *skb; }; static inline int do_one_broadcast(struct sock *sk, @@ -729,6 +729,7 @@ { struct netlink_sock *nlk = nlk_sk(sk); int val; + struct sk_buff *skb; if (p->exclude_sk == sk) goto out; @@ -741,25 +742,21 @@ goto out; } - sock_hold(sk); - if (p->skb2 == NULL) { - if (atomic_read(&p->skb->users) != 1) { - p->skb2 = skb_clone(p->skb, p->allocation); - } else { - p->skb2 = p->skb; - atomic_inc(&p->skb->users); - } - } - if (p->skb2 == NULL) { + skb = skb_clone(p->skb, p->allocation); + if (skb == NULL) { netlink_overrun(sk); /* Clone failed. Notify ALL listeners. */ p->failure = 1; - } else if ((val = netlink_broadcast_deliver(sk, p->skb2)) < 0) { + goto out; + } + + sock_hold(sk); + if ((val = netlink_broadcast_deliver(sk, skb)) < 0) { netlink_overrun(sk); + kfree_skb(skb); } else { p->congested |= val; p->delivered = 1; - p->skb2 = NULL; } sock_put(sk); @@ -784,7 +781,6 @@ info.delivered = 0; info.allocation = allocation; info.skb = skb; - info.skb2 = NULL; /* While we sleep in clone, do not allow to change socket list */ @@ -795,8 +791,6 @@ netlink_unlock_table(); - if (info.skb2) - kfree_skb(info.skb2); kfree_skb(skb); if (info.delivered) { ----Next_Part(Tue_May_10_21_43_32_2005_990)---- From dcbw@redhat.com Tue May 10 06:46:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 06:46:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ADkIOv020809 for ; Tue, 10 May 2005 06:46:19 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4ADjqrt027237; Tue, 10 May 2005 09:45:52 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4ADjqO11913; Tue, 10 May 2005 09:45:52 -0400 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j4ADjpBA013307; Tue, 10 May 2005 09:45:51 -0400 Subject: resend: [PATCH 2.6.11.8] drivers/net/wireless/airo.c: airo WEXT and quality corrections From: Dan Williams To: netdev@oss.sgi.com Cc: davem@davemloft.net, breed@users.sourceforge.net, jgarzik@pobox.com Content-Type: text/plain Date: Tue, 10 May 2005 09:45:51 -0400 Message-Id: <1115732751.16008.8.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-3) Content-Transfer-Encoding: 7bit X-archive-position: 974 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Content-Length: 10323 Lines: 312 This patch brings the airo driver into line with the current WEXT specification of signal quality. It also fixes the values used to determine signal quality and level for MPI & PCMCIA 350 cards. It turns out that BSSListRid.rssi was actually in dBm for 350 series cards, and that we can use the normalized signal strength reported by the card as our "quality" value, on a scale of 0 - 100. Since signal level values are in dBm for this driver, max_qual->level MUST be 0, as specified in the WEXT spec. This patch also uses the IW_QUAL constants new in WEXT version 17. Signed-off-by: Dan Williams --- a/drivers/net/wireless/airo.c 2005-02-10 18:36:58.000000000 -0500 +++ a/drivers/net/wireless/airo.c 2005-02-11 15:45:19.000000000 -0500 @@ -754,7 +754,7 @@ u8 zero; u8 ssidLen; u8 ssid[32]; - u16 rssi; + u16 dBm; #define CAP_ESS (1<<0) #define CAP_IBSS (1<<1) #define CAP_PRIVACY (1<<4) @@ -1125,6 +1125,9 @@ static int encapsulate(struct airo_info *ai, etherHead *pPacket, MICBuffer *buffer, int len); static int decapsulate(struct airo_info *ai, MICBuffer *mic, etherHead *pPacket, u16 payLen); +static u8 airo_rssi_to_dbm (tdsRssiEntry *rssi_rid, u8 rssi); +static u8 airo_dbm_to_pct (tdsRssiEntry *rssi_rid, u8 dbm); + #include #endif @@ -1714,6 +1717,7 @@ list->fh.dwell = le16_to_cpu(list->fh.dwell); list->dsChannel = le16_to_cpu(list->dsChannel); list->atimWindow = le16_to_cpu(list->atimWindow); + list->dBm = le16_to_cpu(list->dBm); return rc; } @@ -3248,7 +3252,10 @@ wstats.level = 0x100 - apriv->rssi[hdr.rssi[1]].rssidBm; else wstats.level = (hdr.rssi[1] + 321) / 2; - wstats.updated = 3; + wstats.noise = apriv->wstats.qual.noise; + wstats.updated = IW_QUAL_LEVEL_UPDATED + | IW_QUAL_QUAL_UPDATED + | IW_QUAL_NOISE_UPDATED; /* Update spy records */ wireless_spy_update(dev, sa, &wstats); } @@ -3591,7 +3598,10 @@ wstats.level = 0x100 - ai->rssi[hdr.rssi[1]].rssidBm; else wstats.level = (hdr.rssi[1] + 321) / 2; - wstats.updated = 3; + wstats.noise = ai->wstats.qual.noise; + wstats.updated = IW_QUAL_QUAL_UPDATED + | IW_QUAL_LEVEL_UPDATED + | IW_QUAL_NOISE_UPDATED; /* Update spy records */ wireless_spy_update(ai->dev, sa, &wstats); } @@ -3682,7 +3692,7 @@ status = PC4500_readrid(ai,RID_RSSI,&rssi_rid,sizeof(rssi_rid),lock); if ( status == SUCCESS ) { if (ai->rssi || (ai->rssi = kmalloc(512, GFP_KERNEL)) != NULL) - memcpy(ai->rssi, (u8*)&rssi_rid + 2, 512); + memcpy(ai->rssi, (u8*)&rssi_rid + 2, 512); /* Skip RID length member */ } else { if (ai->rssi) { @@ -5351,7 +5361,7 @@ (int)BSSList_rid.bssid[5], (int)BSSList_rid.ssidLen, BSSList_rid.ssid, - (int)BSSList_rid.rssi); + (int)BSSList_rid.dBm); ptr += sprintf(ptr, " channel = %d %s %s %s %s\n", (int)BSSList_rid.dsChannel, BSSList_rid.cap & CAP_ESS ? "ESS" : "", @@ -5596,6 +5606,29 @@ * would not work at all... - Jean II */ +static u8 airo_rssi_to_dbm (tdsRssiEntry *rssi_rid, u8 rssi) +{ + if( !rssi_rid ) + return 0; + + return (0x100 - rssi_rid[rssi].rssidBm); +} + +static u8 airo_dbm_to_pct (tdsRssiEntry *rssi_rid, u8 dbm) +{ + int i; + + if( !rssi_rid ) + return 0; + + for( i = 0; i < 256; i++ ) + if (rssi_rid[i].rssidBm == dbm) + return rssi_rid[i].rssipct; + + return 0; +} + + static int airo_get_quality (StatusRid *status_rid, CapabilityRid *cap_rid) { int quality = 0; @@ -6446,11 +6479,29 @@ } range->num_frequency = k; + range->sensitivity = 65535; + /* Hum... Should put the right values there */ - range->max_qual.qual = airo_get_max_quality(&cap_rid); - range->max_qual.level = 0x100 - 120; /* -120 dBm */ + if (local->rssi) + range->max_qual.qual = 100; /* % */ + else + range->max_qual.qual = airo_get_max_quality(&cap_rid); + range->max_qual.level = 0; /* 0 means we use dBm */ range->max_qual.noise = 0; - range->sensitivity = 65535; + range->max_qual.updated = 0; + + /* Experimental measurements - boundary 11/5.5 Mb/s */ + /* Note : with or without the (local->rssi), results + * are somewhat different. - Jean II */ + if (local->rssi) { + range->avg_qual.qual = 50; /* % */ + range->avg_qual.level = 186; /* -70 dBm */ + } else { + range->avg_qual.qual = airo_get_avg_quality(&cap_rid); + range->avg_qual.level = 176; /* -80 dBm */ + } + range->avg_qual.noise = 0; + range->avg_qual.updated = 0; for(i = 0 ; i < 8 ; i++) { range->bitrate[i] = cap_rid.supportedRates[i] * 500000; @@ -6511,15 +6562,6 @@ range->max_retry = 65535; range->min_r_time = 1024; range->max_r_time = 65535 * 1024; - /* Experimental measurements - boundary 11/5.5 Mb/s */ - /* Note : with or without the (local->rssi), results - * are somewhat different. - Jean II */ - range->avg_qual.qual = airo_get_avg_quality(&cap_rid); - if (local->rssi) - range->avg_qual.level = 186; /* -70 dBm */ - else - range->avg_qual.level = 176; /* -80 dBm */ - range->avg_qual.noise = 0; /* Event capability (kernel + driver) */ range->event_capa[0] = (IW_EVENT_CAPA_K_0 | @@ -6679,12 +6721,18 @@ loseSync = 0; memcpy(address[i].sa_data, BSSList.bssid, ETH_ALEN); address[i].sa_family = ARPHRD_ETHER; - if (local->rssi) - qual[i].level = 0x100 - local->rssi[BSSList.rssi].rssidBm; - else - qual[i].level = (BSSList.rssi + 321) / 2; - qual[i].qual = qual[i].noise = 0; - qual[i].updated = 2; + if (local->rssi) { + qual[i].level = 0x100 - BSSList.dBm; + qual[i].qual = airo_dbm_to_pct( local->rssi, BSSList.dBm ); + qual[i].updated = IW_QUAL_QUAL_UPDATED; + } else { + qual[i].level = (BSSList.dBm + 321) / 2; + qual[i].qual = 0; + qual[i].updated = IW_QUAL_QUAL_INVALID; + } + qual[i].noise = local->wstats.qual.noise; + qual[i].updated = IW_QUAL_LEVEL_UPDATED + | IW_QUAL_NOISE_UPDATED; if (BSSList.index == 0xffff) break; } @@ -6763,7 +6811,7 @@ static inline char *airo_translate_scan(struct net_device *dev, char *current_ev, char *end_buf, - BSSListRid *list) + BSSListRid *bss) { struct airo_info *ai = dev->priv; struct iw_event iwe; /* Temporary buffer */ @@ -6774,22 +6822,22 @@ /* First entry *MUST* be the AP MAC address */ iwe.cmd = SIOCGIWAP; iwe.u.ap_addr.sa_family = ARPHRD_ETHER; - memcpy(iwe.u.ap_addr.sa_data, list->bssid, ETH_ALEN); + memcpy(iwe.u.ap_addr.sa_data, bss->bssid, ETH_ALEN); current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_ADDR_LEN); /* Other entries will be displayed in the order we give them */ /* Add the ESSID */ - iwe.u.data.length = list->ssidLen; + iwe.u.data.length = bss->ssidLen; if(iwe.u.data.length > 32) iwe.u.data.length = 32; iwe.cmd = SIOCGIWESSID; iwe.u.data.flags = 1; - current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, list->ssid); + current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, bss->ssid); /* Add mode */ iwe.cmd = SIOCGIWMODE; - capabilities = le16_to_cpu(list->cap); + capabilities = le16_to_cpu(bss->cap); if(capabilities & (CAP_ESS | CAP_IBSS)) { if(capabilities & CAP_ESS) iwe.u.mode = IW_MODE_MASTER; @@ -6800,19 +6848,25 @@ /* Add frequency */ iwe.cmd = SIOCGIWFREQ; - iwe.u.freq.m = le16_to_cpu(list->dsChannel); + iwe.u.freq.m = le16_to_cpu(bss->dsChannel); iwe.u.freq.m = frequency_list[iwe.u.freq.m] * 100000; iwe.u.freq.e = 1; current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_FREQ_LEN); /* Add quality statistics */ iwe.cmd = IWEVQUAL; - if (ai->rssi) - iwe.u.qual.level = 0x100 - ai->rssi[list->rssi].rssidBm; - else - iwe.u.qual.level = (list->rssi + 321) / 2; - iwe.u.qual.noise = 0; - iwe.u.qual.qual = 0; + if (ai->rssi) { + iwe.u.qual.level = 0x100 - bss->dBm; + iwe.u.qual.qual = airo_dbm_to_pct( ai->rssi, bss->dBm ); + iwe.u.qual.updated = IW_QUAL_QUAL_UPDATED; + } else { + iwe.u.qual.level = (bss->dBm + 321) / 2; + iwe.u.qual.qual = 0; + iwe.u.qual.updated = IW_QUAL_QUAL_INVALID; + } + iwe.u.qual.noise = ai->wstats.qual.noise; + iwe.u.qual.updated = IW_QUAL_LEVEL_UPDATED + | IW_QUAL_NOISE_UPDATED; current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_QUAL_LEN); /* Add encryption capability */ @@ -6822,7 +6876,7 @@ else iwe.u.data.flags = IW_ENCODE_DISABLED; iwe.u.data.length = 0; - current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, list->ssid); + current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, bss->ssid); /* Rate : stuffing multiple values in a single event require a bit * more of magic - Jean II */ @@ -6834,10 +6888,10 @@ /* Max 8 values */ for(i = 0 ; i < 8 ; i++) { /* NULL terminated */ - if(list->rates[i] == 0) + if(bss->rates[i] == 0) break; /* Bit rate given in 500 kb/s units (+ 0x80) */ - iwe.u.bitrate.value = ((list->rates[i] & 0x7f) * 500000); + iwe.u.bitrate.value = ((bss->rates[i] & 0x7f) * 500000); /* Add new value to event */ current_val = iwe_stream_add_value(current_ev, current_val, end_buf, &iwe, IW_EV_PARAM_LEN); } @@ -7156,18 +7210,22 @@ /* The status */ local->wstats.status = status_rid.mode; - /* Signal quality and co. But where is the noise level ??? */ - local->wstats.qual.qual = airo_get_quality(&status_rid, &cap_rid); - if (local->rssi) - local->wstats.qual.level = 0x100 - local->rssi[status_rid.sigQuality].rssidBm; - else + /* Signal quality and co */ + if (local->rssi) { + local->wstats.qual.level = airo_rssi_to_dbm( local->rssi, status_rid.sigQuality ); + /* normalizedSignalStrength appears to be a percentage */ + local->wstats.qual.qual = status_rid.normalizedSignalStrength; + } else { local->wstats.qual.level = (status_rid.normalizedSignalStrength + 321) / 2; + local->wstats.qual.qual = airo_get_quality(&status_rid, &cap_rid); + } + local->wstats.qual.updated = IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED; if (status_rid.len >= 124) { - local->wstats.qual.noise = 256 - status_rid.noisedBm; - local->wstats.qual.updated = 7; + local->wstats.qual.noise = 0x100 - status_rid.noisedBm; + local->wstats.qual.updated |= IW_QUAL_NOISE_UPDATED; } else { local->wstats.qual.noise = 0; - local->wstats.qual.updated = 3; + local->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } /* Packets discarded in the wireless adapter due to wireless From baruch@ev-en.org Tue May 10 07:06:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 07:07:02 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AE6mOv021864 for ; Tue, 10 May 2005 07:06:49 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 8F00311A6DC; Tue, 10 May 2005 17:06:24 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 7E87C11A6C4; Tue, 10 May 2005 17:06:21 +0300 (IDT) Message-ID: <4280BFDA.3000909@ev-en.org> Date: Tue, 10 May 2005 15:06:18 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: netdev@oss.sgi.com, Douglas Leith , "David S.Miller" Subject: Re: [RFC] TCP congestion infrastructure References: <20050506173729.20140.93205.37072@galon.ev-en.org> <20050509162214.0a8c9ceb@dxpl.pdx.osdl.net> In-Reply-To: <20050509162214.0a8c9ceb@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 975 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 528 Lines: 20 Stephen Hemminger wrote: > I rebased the H-TCP patches on my current work and 2.6.12-rc4 and put them in > http://developer.osdl.org/shemminger/patches/2.6.12-rc4-tcp/ > > Includes infrastructure and all the current variants: BIC, Westwood, Vegas > plus H-TCP, Hybla I compiled westwood and vegas as modules and got: *** Warning: "tcpdiag_put" [net/ipv4/tcp_westwood.ko] undefined! *** Warning: "tcpdiag_put" [net/ipv4/tcp_vegas.ko] undefined! This is due to: # CONFIG_IP_TCPDIAG is not set in the .config. Baruch From baruch@ev-en.org Tue May 10 07:31:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 07:31:44 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AEVUOv023659 for ; Tue, 10 May 2005 07:31:31 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id A3E8811A6DC; Tue, 10 May 2005 17:31:06 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id A307D11A6C4; Tue, 10 May 2005 17:31:02 +0300 (IDT) Message-ID: <4280C5A4.4050708@ev-en.org> Date: Tue, 10 May 2005 15:31:00 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: netdev@oss.sgi.com, Douglas Leith , "David S.Miller" Subject: Re: [RFC] TCP congestion infrastructure References: <20050506173729.20140.93205.37072@galon.ev-en.org> <20050509162214.0a8c9ceb@dxpl.pdx.osdl.net> In-Reply-To: <20050509162214.0a8c9ceb@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 977 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 403 Lines: 12 Stephen Hemminger wrote: > I rebased the H-TCP patches on my current work and 2.6.12-rc4 and put them in > http://developer.osdl.org/shemminger/patches/2.6.12-rc4-tcp/ > > Includes infrastructure and all the current variants: BIC, Westwood, Vegas > plus H-TCP, Hybla > In the tcpdiag struct you have TCPDIAG_VEGASINFO which is also used by WestWood. Maybe a change of name is in order? Baruch From dmitry.torokhov@gmail.com Tue May 10 07:57:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 07:57:14 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AEv9Ov024599 for ; Tue, 10 May 2005 07:57:09 -0700 Received: by rproxy.gmail.com with SMTP id r35so940905rna for ; Tue, 10 May 2005 07:56:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YZ7+H/DE2BeD9vO4HQJRZy3py5Jw8mJTytLdQbxwtWVHokXfGY07RAwaFywuH50EgKGfrIJJS1B/zwzUfk5txdK7ecjgGtFEOlkgFBQGykfmim+tb54DlDiJ9pr4e+ZAM6kh/CFP0HOViRsl/dmuH6qCpffJJAnLs3jFfKBKuVs= Received: by 10.38.90.57 with SMTP id n57mr2094553rnb; Tue, 10 May 2005 07:56:45 -0700 (PDT) Received: by 10.38.24.62 with HTTP; Tue, 10 May 2005 07:56:45 -0700 (PDT) Message-ID: Date: Tue, 10 May 2005 09:56:45 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: johnpol@2ka.mipt.ru Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan In-Reply-To: <20050510140445.36cc15cb@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050411125932.GA19538@uganda.factory.vocord.ru> <200505100118.48027.dtor_core@ameritech.net> <20050510140445.36cc15cb@zanzibar.2ka.mipt.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4AEv9Ov024599 X-archive-position: 978 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry.torokhov@gmail.com Precedence: bulk X-list: netdev Content-Length: 3302 Lines: 84 On 5/10/05, Evgeniy Polyakov wrote: > On Tue, 10 May 2005 01:18:46 -0500 > Dmitry Torokhov wrote: > > > - drop cn_dev - there is only one connector; > > There may be several connectors with different socket types. > I use it in my environment for tests. > Why do you need that? u32 ID space is not enough? > > - simplify cn_notify_request to carry only one range - it simplifies code > > quite a bit - nothing stops clientd from sending several notification > > requests; > > ? Nothing stops clients from sending several notification requests now. > I do not see how it simplifies the things? > Feel free to set idx_num and val_num to 1 and you will have the same. Compare the implementaion - without variable-length notification requests the code is much simplier and flexible. > > - implement internal queuefor callbacks so we are not at mercy of scheduler; > > Current implementation has big warning about such theoretical behaviour, > if it will be triggered, I will fix that behaviour, > more likely not by naive work allocation - there might be > at least cache/memory pool or something... What is the average expected rate for such messages? Not particularly high I think. We just need to sustain sudden bursts, naive work allocation will work just fine here. > > - admit that SKBs are message medium and do not mess up with passing around > > destructor functions. > > You mess up layers. > I do not see why you want it. What layers? Connector core is not an onion, with my patch it is 481 line .c file(down from 900+), comments probably take 1/3 of it. We just need to keep it simple, that's all. > Connector with your changes just does not work. As in "I tried to run it and adjusted the application for the new cn_notify_req size and it does not work" or "I am saying it does not work"? > Dmitry, I do not understand why do you change things in so radical manner, > especially when there are no 1. new interesting features, 2. no performance > improvements, 3. no right design changes. There is a right design change - it keeps the code simple. It peels all the layers you invented for something that does not really need layers - connector is just a simple wrapper over raw netlink. When I look at the code I see the mess of unneeded refcounting, wrong kinds of locking, over-engineering. Of course I want to change it. Keep it simple. Except for your testing environment why do you need to have separate netlink sockets? You have an ample ID space. Why do you need separate cn_dev and cn_queue_dev (and in the end have them at all)? Why do you need "input" handler, do you expect to use different handlers? If so which? And why? Do you expect to use other transports? If so which? And why? You need to have justifiction for every additional layer you putting on. > > > BTW, I do not think that "All rights reserved" statement is applicable/ > > compatible with GPL this software is supposedly released under, I have > > taken liberty of removing this statement. > > You substitute license agreements with copyright. > "All rights reserved" is targeted to copyright > (avtorskoe pravo, zakon N 5351/1-1) of the code > and has nothing with license. Yes, you are probably right, sorry for the noise... -- Dmitry From johnpol@2ka.mipt.ru Tue May 10 08:42:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 08:42:50 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AFgeOv029759 for ; Tue, 10 May 2005 08:42:41 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with ESMTP id j4AFfZpN025409; Tue, 10 May 2005 19:41:35 +0400 Date: Tue, 10 May 2005 19:41:28 +0400 From: Evgeniy Polyakov To: dtor_core@ameritech.net Cc: dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050510194128.075abb67@zanzibar.2ka.mipt.ru> In-Reply-To: References: <20050411125932.GA19538@uganda.factory.vocord.ru> <200505100118.48027.dtor_core@ameritech.net> <20050510140445.36cc15cb@zanzibar.2ka.mipt.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Tue, 10 May 2005 19:41:36 +0400 (MSD) X-archive-position: 979 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 5810 Lines: 144 On Tue, 10 May 2005 09:56:45 -0500 Dmitry Torokhov wrote: > On 5/10/05, Evgeniy Polyakov wrote: > > On Tue, 10 May 2005 01:18:46 -0500 > > Dmitry Torokhov wrote: > > > > > - drop cn_dev - there is only one connector; > > > > There may be several connectors with different socket types. > > I use it in my environment for tests. > > > > Why do you need that? u32 ID space is not enough? They use different netlink sockets. One of them can fail during initialisation, for example... > > > - simplify cn_notify_request to carry only one range - it simplifies code > > > quite a bit - nothing stops clientd from sending several notification > > > requests; > > > > ? Nothing stops clients from sending several notification requests now. > > I do not see how it simplifies the things? > > Feel free to set idx_num and val_num to 1 and you will have the same. > > Compare the implementaion - without variable-length notification > requests the code is much simplier and flexible. Hmm, old request had a length, new one - does not. But instead of atomically addition of the whole set, one need to send couple of events. I do not see any profit here. > > > - implement internal queuefor callbacks so we are not at mercy of scheduler; > > > > Current implementation has big warning about such theoretical behaviour, > > if it will be triggered, I will fix that behaviour, > > more likely not by naive work allocation - there might be > > at least cache/memory pool or something... > > What is the average expected rate for such messages? Not particularly > high I think. We just need to sustain sudden bursts, naive work > allocation will work just fine here. Probably - I still think it is theoretical "misbehaviour" [dropping input messages under the high load] that can not be triggered, if it will - I will fix it. > > > - admit that SKBs are message medium and do not mess up with passing around > > > destructor functions. > > > > You mess up layers. > > I do not see why you want it. > > What layers? Connector core is not an onion, with my patch it is 481 > line .c file(down from 900+), comments probably take 1/3 of it. We > just need to keep it simple, that's all. There is low-level medium layer - skbs. There is middle-level layer - logical handling attached data and appropriate callback invocation. There is high-level layer - various protocols over connector. Why any of them should know that others exist? Your changes with destructor removing only saved < 10 lines of code, btw. > > Connector with your changes just does not work. > > As in "I tried to run it and adjusted the application for the new > cn_notify_req size and it does not work" or "I am saying it does not > work"? Second, i.e. "I am saing it does not work". With your changes userspace just does not see any message being sent by kernelspace. > > Dmitry, I do not understand why do you change things in so radical manner, > > especially when there are no 1. new interesting features, 2. no performance > > improvements, 3. no right design changes. > > There is a right design change - it keeps the code simple. It peels > all the layers you invented for something that does not really need > layers - connector is just a simple wrapper over raw netlink. That is your opinion. Code is already as simple as possible, since it is layered and each piece of code is separated from different logical entities. > When I look at the code I see the mess of unneeded refcounting, wrong > kinds of locking, over-engineering. Of course I want to change it. There are no unneded reference counting now. Locking was not wrong - you only placed semaphore instead of notify BH lock just to have ability to sleep under the lock and send callback addition/removing notification with GFP_KERNEL mask, and it is probably right change from the first view, as I said, but it can be implemented in a different way. > Keep it simple. Except for your testing environment why do you need to > have separate netlink sockets? You have an ample ID space. Why do you > need separate cn_dev and cn_queue_dev (and in the end have them at > all)? Why do you need "input" handler, do you expect to use different > handlers? If so which? And why? Do you expect to use other transports? > If so which? And why? You need to have justifiction for every > additional layer you putting on. Sigh. It was already answered so many times, as far as I remember... Ok, let's do it again. Several netlink sockets - if you can see, connector uses NETLINK_ULOG for it's notification, you can not use the same socket twice, so you may have new device with new socket, or several of them, and system may work if one initialisation failed. cn_dev is connector device structure, cn_queue_dev - it's queueing part. input handler is needed for ability to receive messages. Couple of next questions can be answered in one reply: original connector's idea was to implement notification based not on top of netlink protocol, but using ioctls of char device, so there could be different connector device, input method, transport and so on. Probably I will not implement it thought. Over-engineering? I can not call it so... :) > > > BTW, I do not think that "All rights reserved" statement is applicable/ > > > compatible with GPL this software is supposedly released under, I have > > > taken liberty of removing this statement. > > > > You substitute license agreements with copyright. > > "All rights reserved" is targeted to copyright > > (avtorskoe pravo, zakon N 5351/1-1) of the code > > and has nothing with license. > > Yes, you are probably right, sorry for the noise... > > -- > Dmitry Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From shemminger@osdl.org Tue May 10 09:14:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 09:14:11 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AGE4Ov031101 for ; Tue, 10 May 2005 09:14:04 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4AGD9U3014174 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 May 2005 09:13:10 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4AGD9Rh020862; Tue, 10 May 2005 09:13:09 -0700 Date: Tue, 10 May 2005 09:13:09 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: baruch@ev-en.org, netdev@oss.sgi.com, doug.leith@nuim.ie Subject: Re: [RFC] TCP congestion infrastructure Message-ID: <20050510091309.3d887c73@dxpl.pdx.osdl.net> In-Reply-To: <20050509.171711.75189002.davem@davemloft.net> References: <20050506173729.20140.93205.37072@galon.ev-en.org> <20050509162214.0a8c9ceb@dxpl.pdx.osdl.net> <20050509.171711.75189002.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 981 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 922 Lines: 24 On Mon, 09 May 2005 17:17:11 -0700 (PDT) "David S. Miller" wrote: > From: Stephen Hemminger > Subject: [RFC] TCP congestion infrastructure > Date: Mon, 9 May 2005 16:22:14 -0700 > > > I rebased the H-TCP patches on my current work and 2.6.12-rc4 and put them in > > http://developer.osdl.org/shemminger/patches/2.6.12-rc4-tcp/ > > > > Includes infrastructure and all the current variants: BIC, Westwood, Vegas > > plus H-TCP, Hybla > > I like it. Looks fine from here. > > This, along with the TSO reworking, will go in at the next > opportunity which is likely 2.6.13 of course. > > I'm considering putting the TSO stuff into 2.6.12 because > in many ways it is a bug fix, TSO is fairly broken without > it. There are some loose ends I need to resolve first though. I'll put tso-reloaded in next set (2.6.12-rc4-tcp2) so if you have a better version send me it. From shemminger@osdl.org Tue May 10 09:12:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 09:12:22 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AGCEOv030995 for ; Tue, 10 May 2005 09:12:15 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4AGBNU3014025 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 May 2005 09:11:24 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4AGBNHR020780; Tue, 10 May 2005 09:11:23 -0700 Date: Tue, 10 May 2005 09:11:23 -0700 From: Stephen Hemminger To: Baruch Even Cc: netdev@oss.sgi.com, Douglas Leith , "David S.Miller" Subject: Re: [RFC] TCP congestion infrastructure Message-ID: <20050510091123.18db2f0d@dxpl.pdx.osdl.net> In-Reply-To: <4280C5A4.4050708@ev-en.org> References: <20050506173729.20140.93205.37072@galon.ev-en.org> <20050509162214.0a8c9ceb@dxpl.pdx.osdl.net> <4280C5A4.4050708@ev-en.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 980 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 599 Lines: 16 On Tue, 10 May 2005 15:31:00 +0100 Baruch Even wrote: > Stephen Hemminger wrote: > > I rebased the H-TCP patches on my current work and 2.6.12-rc4 and put them in > > http://developer.osdl.org/shemminger/patches/2.6.12-rc4-tcp/ > > > > Includes infrastructure and all the current variants: BIC, Westwood, Vegas > > plus H-TCP, Hybla > > > > In the tcpdiag struct you have TCPDIAG_VEGASINFO which is also used by > WestWood. Maybe a change of name is in order? I would but, that name is by now committed in the netlink API. Changing it would break source compatibility. From m.iatrou@freemail.gr Tue May 10 09:49:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 09:49:47 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4AGnWOv000452 for ; Tue, 10 May 2005 09:49:34 -0700 Received: (qmail 23817 invoked by uid 111); 10 May 2005 16:49:07 -0000 Received: from 150.140.129.29 by nic.upatras.gr (envelope-from , uid 103) with qmail-scanner-1.25 (clamdscan: 0.83/706. Clear:RC:1(150.140.129.29):. Processed in 0.086498 secs); 10 May 2005 16:49:07 -0000 Received: from patreas.upatras.gr (150.140.129.29) by nic.upatras.gr with SMTP; 10 May 2005 16:49:07 -0000 Received: (qmail 21753 invoked from network); 10 May 2005 16:49:07 -0000 Received: from upnet-dialinpool-55.upnet.gr ([150.140.128.199]) (envelope-sender ) by patreas.upatras.gr (qmail-ldap-1.03) with SMTP for ; 10 May 2005 16:49:07 -0000 From: Michael Iatrou To: netdev@oss.sgi.com Subject: IPsec performance over UDP Date: Tue, 10 May 2005 19:49:12 +0300 User-Agent: KMail/1.8 X-Face: *8Gl!va:8&HzlgC%IRQaxD*[{;>3OMj];U1I;[rtNn@,hA7h/cTR1!!0J`koxA2)=?utf-8?q?xj=7ELd9=0A=09N4LpVN=24=5CaU=27r?=2l}1-ae/$k1heNY.:5"9IYPy>X$msqG MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505101949.12236.m.iatrou@freemail.gr> X-archive-position: 982 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: m.iatrou@freemail.gr Precedence: bulk X-list: netdev Content-Length: 982 Lines: 38 Hi, I did some testing for IPsec performance over UDP. I used two identical PCs, connected back-to-back, with Intel Xeon 2.8GHz (SMP/SMT disabled), 512MB RAM, e1000 (82546EB), running Linux 2.6.11.7. I tested AES {128,192,256}, DES, 3DES, SHA, MD5 and various combinations of them for ESP and AH. Network performance: http://members.hellug.gr/iatrou/udp-throughput.png CPU utilization: http://members.hellug.gr/iatrou/udp-cpu.png The "unexpected" result is that there is 30% idle time even if the network is not saturated! On the other hand, TCP seems to behave more normally: Network performance: http://members.hellug.gr/iatrou/tcp-throughput.png CPU utilization: http://members.hellug.gr/iatrou/tcp-cpu.png Any ideas? All tests are 100% reproducible. Additional infos: MTU 1500 IPsec mode: transport, using preshared keys netperf 2.3pl1 CPU utilization from /proc/stat -- Michael Iatrou Electrical and Computer Engineering Dept. University of Patras, Greece From afleming@freescale.com Tue May 10 10:05:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 10:06:02 -0700 (PDT) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AH5vOv001675 for ; Tue, 10 May 2005 10:05:59 -0700 Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j4AH9W1c008727; Tue, 10 May 2005 10:09:32 -0700 (MST) Received: from [192.168.0.2] ([10.214.72.80]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id j4AH5r8c021985; Tue, 10 May 2005 12:05:54 -0500 (CDT) In-Reply-To: <42625DDB.4090600@katalix.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> <423734FB.40101@katalix.com> <96c50184a02557c88dee0e6d17f3a539@freescale.com> <42625DDB.4090600@katalix.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: multipart/mixed; boundary=Apple-Mail-1--1458116 Message-Id: <30d87aabd768216ef8bee800f3e09b9e@freescale.com> Cc: netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org, Benjamin Herrenschmidt From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Tue, 10 May 2005 12:04:55 -0500 To: James Chapman X-Mailer: Apple Mail (2.622) X-archive-position: 983 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 91371 Lines: 3384 --Apple-Mail-1--1458116 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Apr 17, 2005, at 08:00, James Chapman wrote: > Andy Fleming wrote: >> Ok, here's the new patch with changes suggested by James Chapman: > > I guess I still have questions about the way interrupts are used. > > Using an interrupt to schedule a work queue which then sets a variable > that is used by a timer seems odd. Why not do all the work in the work > queue and schedule it from the interrupt handler or timer? Ok, I've set up a new system for handling interrupts. There are now two "special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT. The first one is used to indicate that the PHY layer will poll the PHY for state changes, and won't enable interrupts. The second indicates that the PHY layer will neither poll, nor enable interrupts, and thus will allow the driver to handle interrupts. The PHY layer will still operate its state machine, though. The driver must insure a couple things: 1) It must set phydev->state to PHY_CHANGELINK 2) It must do that in a work queue (or other non-interrupt time) The first one tells the PHY layer that the link state changed (it has to grab a lock to do this). The second one is required in order to properly take the lock. > > Also, did you mean to leave the #if 0 code in davicom.c? For now. It worked around a problem some people were reporting, so I'd like to see if they report it again now that the code's out. If so, they have a fairly easy fix, and I can reinsert it (or at least reevaluate it) in the future. > > /james Andy --Apple-Mail-1--1458116 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="phy_05_09_2005.patch" Content-Disposition: attachment; filename=phy_05_09_2005.patch diff -Nru a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/Documentation/networking/phy.txt 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,203 @@ + +------- +PHY Abstraction Layer + +Purpose + + Most network devices consist of set of registers which provide an interface + to a MAC layer, which communicates with the physical connection through a + PHY. The PHY concerns itself with negotiating link parameters with the link + partner on the other side of the network connection (typically, an ethernet + cable), and provides a register interface to allow drivers to determine what + settings were chosen, and to configure what settings are allowed. + + While these devices are distinct from the network devices, and conform to a + standard layout for the registers, it has been common practice to integrate + the PHY management code with the network driver. This has resulted in large + amounts of redundant code. Also, on embedded systems with multiple (and + sometimes quite different) ethernet controllers connected to the same + management bus, it is difficult to ensure safe use of the bus. + + Since the PHYs are devices, and the management busses through which they are + accessed are, in fact, busses, the PHY Abstraction Layer treats them as such. + In doing so, it has these goals: + + 1) Increase code-reuse + 2) Increase overall code-maintainability + 3) Speed development time for new network drivers, and for new systems + + Basically, this layer is meant to provide an interface to PHY devices which + allows network driver writers to write as little code as possible, while + still providing a full feature set. + +The MDIO bus + + Most network devices are connected to a PHY by means of a management bus. + Different devices use different busses (though some share common interfaces). + In order to take advantage of the PAL, each bus interface needs to be + registered as a distinct device. + + 1) read and write functions must be implemented. Their prototypes are: + + int write(struct mii_bus *bus, int mii_id, int regnum, u16 value); + int read(struct mii_bus *bus, int mii_id, int regnum); + + mii_id is the address on the bus for the PHY, and regnum is the register + number. These functions are guaranteed not to be called from interrupt + time, so it is safe for them to block, waiting for an interrupt to signal + the operation is complete + + 2) A reset function is necessary. This is used to return the bus to an + initialized state. + + 3) A probe function is needed. This function should set up anything the bus + driver needs, setup the mii_bus structure, and register with the PAL using + mdiobus_register. Similarly, there's a remove function to undo all of + that (use mdiobus_unregister). + + 4) Like any driver, the device_driver structure must be configured, and init + exit functions are used to register the driver. + + 5) The bus must also be declared somewhere as a device, and registered. + + As an example for how one driver implemented an mdio bus driver, see + drivers/net/gianfar_mii.c and arch/ppc/syslib/mpc85xx_devices.c + +Connecting to a PHY + + Sometime during startup, the network driver needs to establish a connection + between the PHY device, and the network device. At this time, the PHY's bus + and drivers need to all have been loaded, so it is ready for the connection. + At this point, there are several ways to connect to the PHY: + + 1) The PAL handles everything, and only calls the network driver when + the link state changes, so it can react. + + 2) The PAL handles everything except interrupts (usually because the + controller has the interrupt registers). + + 3) The PAL handles everything, but checks in with the driver every second, + allowing the network driver to react first to any changes before the PAL + does. + + 4) The PAL serves only as a library of functions, with the network device + manually calling functions to update status, and configure the PHY + + +Letting the PHY Abstraction Layer do Everything + + If you choose option 1 (The hope is that every driver can, but to still be + useful to drivers that can't), connecting to the PHY is simple: + + First, you need a function to react to changes in the link state. This + function follows this protocol: + + static void adjust_link(struct net_device *dev); + + Next, you need to know the device name of the PHY connected to this device. + The name will look something like, "phy0:0", where the first number is the + bus id, and the second is the PHY's address on that bus. + + Now, to connect, just call this function: + + phydev = phy_connect(dev, phy_name, &adjust_link); + + It is possible you don't need to react to changes in link state. If so, you + can pass in NULL as the last argument, and the PAL will not bother your + driver. + + phydev is a pointer to the phy_device structure which represents the PHY. If + phy_connect is successful, it will return the pointer. dev, here, is the + pointer to your net_device. Once done, this function will have started the + PHY's software state machine, and registered for the PHY's interrupt, if it + has one. The phydev structure will be populated with information about the + current state, though the PHY will not yet be truly operational at this + point. + + Now just make sure that phydev->supported and phydev->advertising have any + values pruned from them which don't make sense for your controller (a 10/100 + controller may be connected to a gigabit capable PHY, so you would need to + mask off SUPPORTED_1000baseT*). See include/linux/ethtool.h for definitions + for these bitfields. Note that you should not SET any bits, or the PHY may + get put into an unsupported state. + + Lastly, once the controller is ready to handle network traffic, you call + phy_start(phydev). This tells the PAL that you are ready, and configures the + PHY to connect to the network. If you want to handle your own interrupts, + just set phydev->irq to PHY_IGNORE_INTERRUPT before you call phy_start. + Similarly, if you don't want to use interrupts, set phydev->irq to PHY_POLL. + + When you want to disconnect from the network (even if just briefly), you call + phy_stop(phydev). + +Keeping Close Tabs on the PAL + + It is possible that the PAL's built-in state machine needs a little help to + keep your network device and the PHY properly in sync. If so, you can + register a helper function when connecting to the PHY, which will be called + every second before the state machine reacts to any changes. To do this, you + need to manually call phy_attach() and phy_prepare_link(), and then call + phy_start_machine() with the second argument set to point to your special + handler. + + Currently there are no examples of how to use this functionality, and testing + on it has been limited because the author does not have any drivers which use + it (they all use option 1). So Caveat Emptor. + +Doing it all yourself + + There's a remote chance that the PAL's built-in state machine cannot track + the complex interactions between the PHY and your network device. If this is + so, you can simply call phy_attach(), and not call phy_start_machine or + phy_prepare_link(). This will mean that phydev->state is entirely yours to + handle (phy_start and phy_stop toggle between some of the states, so you + might need to avoid them). + + An effort has been made to make sure that useful functionality can be + accessed without the state-machine running, and most of these functions are + descended from functions which did not interact with a complex state-machine. + However, again, no effort has been made so far to test running without the + state machine, so tryer beware. + + Here is a brief rundown of the functions: + + int phy_read(struct phy_device *phydev, u16 regnum); + int phy_write(struct phy_device *phydev, u16 regnum, u16 val); + + Simple read/write primitives. They invoke the bus's read/write function + pointers. + + int phy_clear_interrupt(struct phy_device *phydev); + int phy_config_interrupt(struct phy_device *phydev, u32 interrupts); + + Clear the PHY's interrupt, and configure which ones are allowed, + respectively. Currently only supports all on, or all off. + + struct phy_device * phy_attach(struct net_device *dev, const char *phy_id); + + Attaches a network device to a particular PHY, binding the PHY to a generic + driver if none was found during bus initialization. + + int phy_start_aneg(struct phy_device *phydev); + + Using variables inside the phydev structure, either configures advertising + and resets autonegotiation, or disables autonegotiation, and configures + forced settings. + + static inline int phy_read_status(struct phy_device *phydev); + + Fills the phydev structure with up-to-date information about the current + settings in the PHY. + + int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd); + int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd); + + Ethtool convenience functions. + + int phy_mii_ioctl(struct phy_device *phydev, + struct mii_ioctl_data *mii_data, int cmd); + + The MII ioctl. Note that this function will completely screw up the state + machine if you write registers like BMCR, BMSR, ADVERTISE, etc. Best to + use this only to write registers which are not standard, and don't set off + a renegotiation. diff -Nru a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2005-05-09 13:19:26 -05:00 +++ b/drivers/net/Kconfig 2005-05-09 13:19:26 -05:00 @@ -153,6 +153,8 @@ source "drivers/net/arcnet/Kconfig" endif +source "drivers/net/phy/Kconfig" + # # Ethernet # @@ -2056,6 +2058,8 @@ config GIANFAR tristate "Gianfar Ethernet" depends on 85xx || 83xx + select PHYLIB + select PHYCONTROL help This driver supports the Gigabit TSEC on the MPC85xx family of chips, and the FEC on the 8540 diff -Nru a/drivers/net/Makefile b/drivers/net/Makefile --- a/drivers/net/Makefile 2005-05-09 13:19:25 -05:00 +++ b/drivers/net/Makefile 2005-05-09 13:19:25 -05:00 @@ -12,7 +12,7 @@ obj-$(CONFIG_BONDING) += bonding/ obj-$(CONFIG_GIANFAR) += gianfar_driver.o -gianfar_driver-objs := gianfar.o gianfar_ethtool.o gianfar_phy.o +gianfar_driver-objs := gianfar.o gianfar_ethtool.o gianfar_mii.o # # link order important here @@ -63,6 +63,7 @@ # obj-$(CONFIG_MII) += mii.o +obj-$(CONFIG_PHYLIB) += phy/ obj-$(CONFIG_SUNDANCE) += sundance.o obj-$(CONFIG_HAMACHI) += hamachi.o diff -Nru a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/Kconfig 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,57 @@ +# +# PHY Layer Configuration +# + +menu "PHY device support" + +config PHYLIB + bool "PHY Device support and infrastructure" + depends on NET_ETHERNET + help + Ethernet controllers are usually attached to PHY + devices. This option provides infrastructure for + managing PHY devices. + +config PHYCONTROL + bool "Support for automatically handling PHY state changes" + depends on PHYLIB + help + Adds code to perform all the work for keeping PHY link + state (speed/duplex/etc) up-to-date. Also handles + interrupts. + +comment "MII PHY device drivers" + depends on PHYLIB + +config MARVELL_PHY + bool "Drivers for Marvell PHYs" + depends on PHYLIB + ---help--- + Currently has a driver for the 88E1011S + +config DAVICOM_PHY + bool "Drivers for Davicom PHYs" + depends on PHYLIB + ---help--- + Currently supports dm9161e and dm9131 + +config QSEMI_PHY + bool "Drivers for Quality Semiconductor PHYs" + depends on PHYLIB + ---help--- + Currently supports the qs6612 + +config LXT_PHY + bool "Drivers for the Intel LXT PHYs" + depends on PHYLIB + ---help--- + Currently supports the lxt970, lxt971 + +config CICADA_PHY + bool "Drivers for the Cicada PHYs" + depends on PHYLIB + ---help--- + Currently supports the cis8204 + +endmenu + diff -Nru a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/Makefile 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,9 @@ +# Makefile for Linux PHY drivers + +obj-$(CONFIG_PHYLIB) += phy.o phy_device.o mdio_bus.o + +obj-$(CONFIG_MARVELL_PHY) += marvell.o +obj-$(CONFIG_DAVICOM_PHY) += davicom.o +obj-$(CONFIG_CICADA_PHY) += cicada.o +obj-$(CONFIG_LXT_PHY) += lxt.o +obj-$(CONFIG_QSEMI_PHY) += qsemi.o diff -Nru a/drivers/net/phy/cicada.c b/drivers/net/phy/cicada.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/cicada.c 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,134 @@ +/* + * drivers/net/phy/cicada.c + * + * Driver for Cicada PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* Cicada Extended Control Register 1 */ +#define MII_CIS8201_EXT_CON1 0x17 +#define MII_CIS8201_EXTCON1_INIT 0x0000 + +/* Cicada Interrupt Mask Register */ +#define MII_CIS8201_IMASK 0x19 +#define MII_CIS8201_IMASK_IEN 0x8000 +#define MII_CIS8201_IMASK_SPEED 0x4000 +#define MII_CIS8201_IMASK_LINK 0x2000 +#define MII_CIS8201_IMASK_DUPLEX 0x1000 +#define MII_CIS8201_IMASK_MASK 0xf000 + +/* Cicada Interrupt Status Register */ +#define MII_CIS8201_ISTAT 0x1a +#define MII_CIS8201_ISTAT_STATUS 0x8000 +#define MII_CIS8201_ISTAT_SPEED 0x4000 +#define MII_CIS8201_ISTAT_LINK 0x2000 +#define MII_CIS8201_ISTAT_DUPLEX 0x1000 + +/* Cicada Auxiliary Control/Status Register */ +#define MII_CIS8201_AUX_CONSTAT 0x1c +#define MII_CIS8201_AUXCONSTAT_INIT 0x0004 +#define MII_CIS8201_AUXCONSTAT_DUPLEX 0x0020 +#define MII_CIS8201_AUXCONSTAT_SPEED 0x0018 +#define MII_CIS8201_AUXCONSTAT_GBIT 0x0010 +#define MII_CIS8201_AUXCONSTAT_100 0x0008 + + +static int cis820x_probe(struct phy_device *phydev) +{ + int err; + + err = phy_write(phydev, MII_CIS8201_AUX_CONSTAT, + MII_CIS8201_AUXCONSTAT_INIT); + + if (err < 0) + return err; + + err = phy_write(phydev, MII_CIS8201_EXT_CON1, + MII_CIS8201_EXTCON1_INIT); + + return err; +} + +static int cis820x_ack_interrupt(struct phy_device *phydev) +{ + int err = phy_read(phydev, MII_CIS8201_ISTAT); + + return (err < 0) ? err : 0; +} + +static int cis820x_config_intr(struct phy_device *phydev) +{ + int err; + + if(phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_CIS8201_IMASK, + MII_CIS8201_IMASK_MASK); + else + err = phy_write(phydev, MII_CIS8201_IMASK, 0); + + return err; +} + +/* Cicada 820x */ +static struct phy_driver cis8204_driver = { + 0x000fc440, + "Cicada Cis8204", + 0x000fffc0, + .features = PHY_GBIT_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .probe = &cis820x_probe, + .config_aneg = &genphy_config_aneg, + .read_status = &genphy_read_status, + .ack_interrupt = &cis820x_ack_interrupt, + .config_intr = &cis820x_config_intr, +}; + +int __init cis8204_init(void) +{ + int retval; + + retval = phy_driver_register(&cis8204_driver); + + return retval; +} + +static void __exit cis8204_exit(void) +{ + phy_driver_unregister(&cis8204_driver); +} + +module_init(cis8204_init); +module_exit(cis8204_exit); diff -Nru a/drivers/net/phy/davicom.c b/drivers/net/phy/davicom.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/davicom.c 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,275 @@ +/* + * drivers/net/phy/davicom.c + * + * Driver for Davicom PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define MII_DM9161_SCR 0x10 +#define MII_DM9161_SCR_INIT 0x0610 + +/* DM9161 Interrupt Register */ +#define MII_DM9161_INTR 0x15 +#define MII_DM9161_INTR_PEND 0x8000 +#define MII_DM9161_INTR_DPLX_MASK 0x0800 +#define MII_DM9161_INTR_SPD_MASK 0x0400 +#define MII_DM9161_INTR_LINK_MASK 0x0200 +#define MII_DM9161_INTR_MASK 0x0100 +#define MII_DM9161_INTR_DPLX_CHANGE 0x0010 +#define MII_DM9161_INTR_SPD_CHANGE 0x0008 +#define MII_DM9161_INTR_LINK_CHANGE 0x0004 +#define MII_DM9161_INTR_INIT 0x0000 +#define MII_DM9161_INTR_STOP \ +(MII_DM9161_INTR_DPLX_MASK | MII_DM9161_INTR_SPD_MASK \ + | MII_DM9161_INTR_LINK_MASK | MII_DM9161_INTR_MASK) + +/* DM9161 10BT Configuration/Status */ +#define MII_DM9161_10BTCSR 0x12 +#define MII_DM9161_10BTCSR_INIT 0x7800 + +struct dm9161_private { + struct timer_list timer; + int resetdone; +}; + +#define DM9161_DELAY 1 +int dm9161_config_intr(struct phy_device *phydev) +{ + int temp; + + temp = phy_read(phydev, MII_DM9161_INTR); + + if (temp < 0) + return temp; + + if(PHY_INTERRUPT_ENABLED == phydev->interrupts ) + temp &= ~(MII_DM9161_INTR_STOP); + else + temp |= MII_DM9161_INTR_STOP; + + temp = phy_write(phydev, MII_DM9161_INTR, temp); + + return temp; +} + + +#if 0 +static void dm9161_timer(unsigned long data) +{ + struct phy_device *phydev = (struct phy_device *)data; + struct dm9161_private *priv = phydev->priv; + int status = phy_read(phydev, MII_BMSR); + + if (status < 0) { + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); + return; + } + + spin_lock(&phydev->lock); + if (status & BMSR_ANEGCOMPLETE) { + if (PHY_PENDING == phydev->state) + phydev->state = PHY_UP; + else + phydev->state = PHY_READY; + } else + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); + + spin_unlock(&phydev->lock); +} +#endif + + +static int dm9161_config_aneg(struct phy_device *phydev) +{ + int err; + + /* Isolate the PHY */ + err = phy_write(phydev, MII_BMCR, BMCR_ISOLATE); + + if (err < 0) + return err; + + /* Configure the new settings */ + err = genphy_config_advert(phydev); + + if (err < 0) + return err; + + /* Reconnect the PHY, and enable Autonegotiation */ + err = phy_write(phydev, MII_BMCR, BMCR_ANENABLE); + + if (err < 0) + return err; + +#if 0 + /* Start a timer for DM9161_DELAY seconds to wait + * for the PHY to be ready */ + init_timer(&priv->timer); + priv->timer.function = &dm9161_timer; + priv->timer.data = (unsigned long) phydev; + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); +#endif + + return 0; +} + +static int dm9161_probe(struct phy_device *phydev) +{ + struct dm9161_private *priv; + int err; + + /* Allocate the private data structure */ + priv = kmalloc(sizeof(struct dm9161_private), GFP_KERNEL); + + if (NULL == priv) + return -ENOMEM; + + phydev->priv = priv; + + /* Reset is not done yet */ + priv->resetdone = 0; + + /* Isolate the PHY */ + err = phy_write(phydev, MII_BMCR, BMCR_ISOLATE); + + if (err < 0) + return err; + + /* Do not bypass the scrambler/descrambler */ + err = phy_write(phydev, MII_DM9161_SCR, MII_DM9161_SCR_INIT); + + if (err < 0) + return err; + + /* Clear 10BTCSR to default */ + err = phy_write(phydev, MII_DM9161_10BTCSR, MII_DM9161_10BTCSR_INIT); + + if (err < 0) + return err; + + /* Reconnect the PHY, and enable Autonegotiation */ + err = phy_write(phydev, MII_BMCR, BMCR_ANENABLE); + + if (err < 0) + return err; + +#if 0 + phydev->state = PHY_STARTING; + + /* Start a timer for DM9161_DELAY seconds to wait + * for the PHY to be ready */ + init_timer(&priv->timer); + priv->timer.function = &dm9161_timer; + priv->timer.data = (unsigned long) phydev; + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); + + pr_info("Bringing up a Davicom PHY, " + "this could take a while...\n"); +#endif + return 0; +} + +static void dm9161_remove(struct phy_device *phydev) +{ + struct dm9161_private *priv = phydev->priv; + +// del_timer_sync(&priv->timer); + kfree(priv); +} + +static int dm9161_ack_interrupt(struct phy_device *phydev) +{ + int err = phy_read(phydev, MII_DM9161_INTR); + + return (err < 0) ? err : 0; +} + +static struct phy_driver dm9161_driver = { + .phy_id = 0x0181b880, + .name = "Davicom DM9161E", + .phy_id_mask = 0x0ffffff0, + .features = PHY_BASIC_FEATURES, + .probe = dm9161_probe, + .config_aneg = dm9161_config_aneg, + .read_status = genphy_read_status, + .remove = dm9161_remove, +}; + +static struct phy_driver dm9131_driver = { + .phy_id = 0x00181b80, + .name = "Davicom DM9131", + .phy_id_mask = 0x0ffffff0, + .features = PHY_BASIC_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, + .ack_interrupt = dm9161_ack_interrupt, + .config_intr = dm9161_config_intr, +}; + +int __init dm9161_init(void) +{ + int retval; + + retval = phy_driver_register(&dm9161_driver); + + return retval; +} + +static void __exit dm9161_exit(void) +{ + phy_driver_unregister(&dm9161_driver); +} + +module_init(dm9161_init); +module_exit(dm9161_exit); + +int __init dm9131_init(void) +{ + int retval; + + retval = phy_driver_register(&dm9131_driver); + + return retval; +} + +static void __exit dm9131_exit(void) +{ + phy_driver_unregister(&dm9131_driver); +} + +module_init(dm9131_init); +module_exit(dm9131_exit); diff -Nru a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/lxt.c 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,179 @@ +/* + * drivers/net/phy/lxt.c + * + * Driver for Intel LXT PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* The Level one LXT970 is used by many boards */ + +#define MII_LXT970_IER 17 /* Interrupt Enable Register */ + +#define MII_LXT970_IER_IEN 0x0002 + +#define MII_LXT970_ISR 18 /* Interrupt Status Register */ + +#define MII_LXT970_CONFIG 19 /* Configuration Register */ + +/* ------------------------------------------------------------------------- */ +/* The Level one LXT971 is used on some of my custom boards */ + +/* register definitions for the 971 */ +#define MII_LXT971_IER 18 /* Interrupt Enable Register */ +#define MII_LXT971_IER_IEN 0x00f2 + +#define MII_LXT971_ISR 19 /* Interrupt Status Register */ + + +static int lxt970_ack_interrupt(struct phy_device *phydev) +{ + int err; + + err = phy_read(phydev, MII_BMSR); + + if (err < 0) + return err; + + err = phy_read(phydev, MII_LXT970_ISR); + + if (err < 0) + return err; + + return 0; +} + +static int lxt970_config_intr(struct phy_device *phydev) +{ + int err; + + if(phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_LXT970_IER, MII_LXT970_IER_IEN); + else + err = phy_write(phydev, MII_LXT970_IER, 0); + + return err; +} + +static int lxt970_probe(struct phy_device *phydev) +{ + int err; + + err = phy_write(phydev, MII_LXT970_CONFIG, 0); + + return err; +} + + +static int lxt971_ack_interrupt(struct phy_device *phydev) +{ + int err = phy_read(phydev, MII_LXT971_ISR); + + if (err < 0) + return err; + + return 0; +} + +static int lxt971_config_intr(struct phy_device *phydev) +{ + int err; + + if(phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_LXT971_IER, MII_LXT971_IER_IEN); + else + err = phy_write(phydev, MII_LXT971_IER, 0); + + return err; +} + +static struct phy_driver lxt970_driver = { + .phy_id = 0x07810000, + .name = "LXT970", + .phy_id_mask = 0x0fffffff, + .features = PHY_BASIC_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .probe = lxt970_probe, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, + .ack_interrupt = lxt970_ack_interrupt, + .config_intr = lxt970_config_intr, +}; + +static struct phy_driver lxt971_driver = { + .phy_id = 0x0001378e, + .name = "LXT971", + .phy_id_mask = 0x0fffffff, + .features = PHY_BASIC_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, + .ack_interrupt = lxt971_ack_interrupt, + .config_intr = lxt971_config_intr, +}; + +int __init lxt970_init(void) +{ + int retval; + + retval = phy_driver_register(&lxt970_driver); + + return retval; +} + +static void __exit lxt970_exit(void) +{ + phy_driver_unregister(&lxt970_driver); +} + +module_init(lxt970_init); +module_exit(lxt970_exit); + +int __init lxt971_init(void) +{ + int retval; + + retval = phy_driver_register(&lxt971_driver); + + return retval; +} + +static void __exit lxt971_exit(void) +{ + phy_driver_unregister(&lxt971_driver); +} + +module_init(lxt971_init); +module_exit(lxt971_exit); diff -Nru a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/marvell.c 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,139 @@ +/* + * drivers/net/phy/marvell.c + * + * Driver for Marvell PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define MII_M1011_IEVENT 0x13 +#define MII_M1011_IEVENT_CLEAR 0x0000 + +#define MII_M1011_IMASK 0x12 +#define MII_M1011_IMASK_INIT 0x6400 +#define MII_M1011_IMASK_CLEAR 0x0000 + +static int marvell_ack_interrupt(struct phy_device *phydev) +{ + int err; + + /* Clear the interrupts by reading the reg */ + err = phy_read(phydev, MII_M1011_IEVENT); + + if (err < 0) + return err; + + return 0; +} + +static int marvell_config_intr(struct phy_device *phydev) +{ + int err; + + if(phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_M1011_IMASK, MII_M1011_IMASK_INIT); + else + err = phy_write(phydev, MII_M1011_IMASK, MII_M1011_IMASK_CLEAR); + + return err; +} + +static int marvell_config_aneg(struct phy_device *phydev) +{ + int err; + + /* The Marvell PHY has an errata which requires + * that certain registers get written in order + * to restart autonegotiation */ + err = phy_write(phydev, MII_BMCR, BMCR_RESET); + + if (err < 0) + return err; + + err = phy_write(phydev, 0x1d, 0x1f); + if (err < 0) + return err; + + err = phy_write(phydev, 0x1e, 0x200c); + if (err < 0) + return err; + + err = phy_write(phydev, 0x1d, 0x5); + if (err < 0) + return err; + + err = phy_write(phydev, 0x1e, 0); + if (err < 0) + return err; + + err = phy_write(phydev, 0x1e, 0x100); + if (err < 0) + return err; + + + err = genphy_config_aneg(phydev); + + return err; +} + + +static struct phy_driver m88e1101_driver = { + .phy_id = 0x01410c00, + .phy_id_mask = 0xffffff00, + .name = "Marvell 88E1101", + .features = PHY_GBIT_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .config_aneg = &marvell_config_aneg, + .read_status = &genphy_read_status, + .ack_interrupt = &marvell_ack_interrupt, + .config_intr = &marvell_config_intr, +}; + +int __init marvell_init(void) +{ + int retval; + + retval = phy_driver_register(&m88e1101_driver); + + return retval; +} + +static void __exit marvell_exit(void) +{ + phy_driver_unregister(&m88e1101_driver); +} + +module_init(marvell_init); +module_exit(marvell_exit); diff -Nru a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/mdio_bus.c 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,175 @@ +/* + * drivers/net/phy/mdio_bus.c + * + * MDIO Bus interface + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* register_mdiobus + * + * description: Called by a bus driver to bring up all the PHYs + * on a given bus, and attach them to the bus + */ +int mdiobus_register(struct mii_bus *bus) +{ + int i; + int err = 0; + + spin_lock_init(&bus->mdio_lock); + + if (NULL == bus || NULL == bus->name || + NULL == bus->read || + NULL == bus->write) + return -EINVAL; + + if (bus->reset) + bus->reset(bus); + + for (i=0; i < PHY_MAX_ADDR; i++) { + struct phy_device *phydev; + + phydev = get_phy_device(bus, i); + + /* There's a PHY at this address + * We need to set: + * 1) IRQ + * 2) bus_id + * 3) parent + * 4) bus + * 5) mii_bus + * And, we need to register it */ + if (phydev) { + phydev->irq = bus->irq[i]; + + phydev->dev.parent = bus->dev; + + phydev->dev.bus = &mdio_bus_type; + + phydev->bus = bus; + + sprintf(phydev->dev.bus_id, "phy%d:%d", bus->id, i); + + err = device_register(&phydev->dev); + + if (err) + printk("phy %d did not register (%d)\n", + i, err); + + /* If get_phy_device returned NULL, it may be + * because an error occurred. If so, we return + * that error */ + } else if (errno) + return errno; + + bus->phy_map[i] = phydev; + } + + pr_info("%s: probed\n", bus->name); + + return err; +} +EXPORT_SYMBOL(mdiobus_register); + +void mdiobus_unregister(struct mii_bus *bus) +{ + int i; + + for (i=0; i < PHY_MAX_ADDR; i++) + if (bus->phy_map[i]) { + device_unregister(&bus->phy_map[i]->dev); + kfree(bus->phy_map[i]); + } + +} +EXPORT_SYMBOL(mdiobus_unregister); + +/* mdio_bus_match + * + * description: Given a PHY device, and a PHY driver, return 1 if + * the driver supports the device. Otherwise, return 0 + */ +int mdio_bus_match(struct device *dev, struct device_driver *drv) +{ + struct phy_device *phydev = to_phy_device(dev); + struct phy_driver *phydrv = to_phy_driver(drv); + + return (phydrv->phy_id == (phydev->phy_id & phydrv->phy_id_mask)); +} + +/* Suspend and resume. Copied from platform_suspend and + * platform_resume + */ +static int mdio_bus_suspend(struct device * dev, u32 state) +{ + int ret = 0; + + if (dev->driver && dev->driver->suspend) { + ret = dev->driver->suspend(dev, state, SUSPEND_DISABLE); + if (ret == 0) + ret = dev->driver->suspend(dev, state, SUSPEND_SAVE_STATE); + if (ret == 0) + ret = dev->driver->suspend(dev, state, SUSPEND_POWER_DOWN); + } + return ret; +} + +static int mdio_bus_resume(struct device * dev) +{ + int ret = 0; + + if (dev->driver && dev->driver->resume) { + ret = dev->driver->resume(dev, RESUME_POWER_ON); + if (ret == 0) + ret = dev->driver->resume(dev, RESUME_RESTORE_STATE); + if (ret == 0) + ret = dev->driver->resume(dev, RESUME_ENABLE); + } + return ret; +} + +struct bus_type mdio_bus_type = { + .name = "mdio_bus", + .match = mdio_bus_match, + .suspend= mdio_bus_suspend, + .resume = mdio_bus_resume, +}; + +int __init mdio_bus_init(void) +{ + return bus_register(&mdio_bus_type); +} + +subsys_initcall(mdio_bus_init); diff -Nru a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/phy.c 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,819 @@ +/* + * drivers/net/phy/phy.c + * + * Framework for configuring and reading PHY devices + * Based on code in sungem_phy.c and gianfar_phy.c + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +int phy_read(struct phy_device *phydev, u16 regnum); +int phy_write(struct phy_device *phydev, u16 regnum, u16 val); +void phy_change(void *data); +void phy_timer(unsigned long data); + +/* Convenience functions for reading/writing a given PHY + * register. They MUST NOT be called from interrupt context, + * because the bus read/write functions may wait for an interrupt + * to conclude the operation. */ +int phy_read(struct phy_device *phydev, u16 regnum) +{ + int retval; + struct mii_bus *bus = phydev->bus; + + spin_lock_bh(&bus->mdio_lock); + retval = bus->read(bus, phydev->addr, regnum); + spin_unlock_bh(&bus->mdio_lock); + + return retval; +} + +int phy_write(struct phy_device *phydev, u16 regnum, u16 val) +{ + int err; + struct mii_bus *bus = phydev->bus; + + spin_lock_bh(&bus->mdio_lock); + err = bus->write(bus, phydev->addr, regnum, val); + spin_unlock_bh(&bus->mdio_lock); + + return err; +} + + +int phy_clear_interrupt(struct phy_device *phydev) +{ + int err = 0; + + if (phydev->drv->ack_interrupt) + err = phydev->drv->ack_interrupt(phydev); + + return err; +} + + +int phy_config_interrupt(struct phy_device *phydev, u32 interrupts) +{ + int err = 0; + + phydev->interrupts = interrupts; + if (phydev->drv->config_intr) + err = phydev->drv->config_intr(phydev); + + return err; +} + + +static inline int phy_read_status(struct phy_device *phydev) +{ + return phydev->drv->read_status(phydev); +} + +/* phy_aneg_done + * + * description: Reads the status register and returns 0 either if + * auto-negotiation is incomplete, or if there was an error. + * Returns BMSR_ANEGCOMPLETE if auto-negotiation is done. + */ +static inline int phy_aneg_done(struct phy_device *phydev) +{ + int retval; + + retval = phy_read(phydev, MII_BMSR); + + if (retval < 0) + return retval; + + return retval & BMSR_ANEGCOMPLETE; +} + +/* phy_start_aneg + * + * description: Calls the PHY driver's config_aneg, and then + * sets the PHY state to PHY_AN if auto-negotiation is enabled, + * and to PHY_FORCING if auto-negotiation is disabled. Unless + * the PHY is currently HALTED. + */ +int phy_start_aneg(struct phy_device *phydev) +{ + int err = 0; + + spin_lock(&phydev->lock); + + if (AUTONEG_DISABLE == phydev->autoneg) + phy_sanitize_settings(phydev); + + err = phydev->drv->config_aneg(phydev); + + if (err < 0) + return err; + + if (phydev->state != PHY_HALTED) { + if (AUTONEG_ENABLE == phydev->autoneg) { + phydev->state = PHY_AN; + phydev->link_timeout = PHY_AN_TIMEOUT; + } else { + phydev->state = PHY_FORCING; + phydev->link_timeout = PHY_FORCE_TIMEOUT; + } + } + + spin_unlock(&phydev->lock); + + return err; +} + + +/* A structure for mapping a particular speed and duplex + * combination to a particular SUPPORTED and ADVERTISED value */ +struct phy_setting { + int speed; + int duplex; + u32 setting; +}; + +/* A mapping of all SUPPORTED settings to speed/duplex */ +static struct phy_setting settings[] = { + { .speed = 10000, .duplex = DUPLEX_FULL, + .setting = SUPPORTED_10000baseT_Full, + }, + { .speed = SPEED_1000, .duplex = DUPLEX_FULL, + .setting = SUPPORTED_1000baseT_Full, + }, + { .speed = SPEED_1000, .duplex = DUPLEX_HALF, + .setting = SUPPORTED_1000baseT_Half, + }, + { .speed = SPEED_100, .duplex = DUPLEX_FULL, + .setting = SUPPORTED_100baseT_Full, + }, + { .speed = SPEED_100, .duplex = DUPLEX_HALF, + .setting = SUPPORTED_100baseT_Half, + }, + { .speed = SPEED_10, .duplex = DUPLEX_FULL, + .setting = SUPPORTED_10baseT_Full, + }, + { .speed = SPEED_10, .duplex = DUPLEX_HALF, + .setting = SUPPORTED_10baseT_Half, + }, +}; + +#define MAX_NUM_SETTINGS (sizeof(settings)/sizeof(struct phy_setting)) + +/* phy_find_setting + * + * description: Searches the settings array for the setting which + * matches the desired speed and duplex, and returns the index + * of that setting. Returns the index of the last setting if + * none of the others match. + */ +static inline int phy_find_setting(int speed, int duplex) +{ + int idx = 0; + + while (idx < MAX_NUM_SETTINGS && + (settings[idx].speed != speed || + settings[idx].duplex != duplex)) + idx++; + + return idx < MAX_NUM_SETTINGS ? idx : MAX_NUM_SETTINGS - 1; +} + +/* phy_find_valid + * idx: The first index in settings[] to search + * features: A mask of the valid settings + * + * description: Returns the index of the first valid setting less + * than or equal to the one pointed to by idx, as determined by + * the mask in features. Returns the index of the last setting + * if nothing else matches. + */ +static inline int phy_find_valid(int idx, u32 features) +{ + while (idx < MAX_NUM_SETTINGS && !(settings[idx].setting & features)) + idx++; + + return idx < MAX_NUM_SETTINGS ? idx : MAX_NUM_SETTINGS - 1; +} + +/* phy_sanitize_settings + * + * description: Make sure the PHY is set to supported speeds and + * duplexes. Drop down by one in this order: 1000/FULL, + * 1000/HALF, 100/FULL, 100/HALF, 10/FULL, 10/HALF + */ +void phy_sanitize_settings(struct phy_device *phydev) +{ + u32 features = phydev->supported; + int idx; + + /* Sanitize settings based on PHY capabilities */ + if ((features & SUPPORTED_Autoneg) == 0) + phydev->autoneg = 0; + + idx = phy_find_valid(phy_find_setting(phydev->speed, phydev->duplex), + features); + + phydev->speed = settings[idx].speed; + phydev->duplex = settings[idx].duplex; +} + +/* phy_force_reduction + * + * description: Reduces the speed/duplex settings by + * one notch. The order is so: + * 1000/FULL, 1000/HALF, 100/FULL, 100/HALF, + * 10/FULL, 10/HALF. The function bottoms out at 10/HALF. + */ +void phy_force_reduction(struct phy_device *phydev) +{ + int idx; + + idx = phy_find_setting(phydev->speed, phydev->duplex); + + idx++; + + idx = phy_find_valid(idx, phydev->supported); + + phydev->speed = settings[idx].speed; + phydev->duplex = settings[idx].duplex; + + pr_info("Trying %d/%s\n", phydev->speed, + DUPLEX_FULL == phydev->duplex ? + "FULL" : "HALF"); +} + +/* phy_ethtool_sset: + * A generic ethtool sset function. Handles all the details + * + * A few notes about parameter checking: + * - We don't set port or transceiver, so we don't care what they + * were set to. + * - phy_start_aneg() will make sure forced settings are sane, and + * choose the next best ones from the ones selected, so we don't + * care if ethtool tries to give us bad values + */ +int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd) +{ + if (cmd->phy_address != phydev->addr) + return -EINVAL; + + /* We make sure that we don't pass unsupported + * values in to the PHY */ + cmd->advertising &= phydev->supported; + + /* Verify the settings we care about. */ + if (cmd->autoneg != AUTONEG_ENABLE && cmd->autoneg != AUTONEG_DISABLE) + return -EINVAL; + + if (cmd->autoneg == AUTONEG_ENABLE && cmd->advertising == 0) + return -EINVAL; + + if (cmd->autoneg == AUTONEG_DISABLE + && ((cmd->speed != SPEED_1000 + && cmd->speed != SPEED_100 + && cmd->speed != SPEED_10) + || (cmd->duplex != DUPLEX_HALF + && cmd->duplex != DUPLEX_FULL))) + return -EINVAL; + + phydev->autoneg = cmd->autoneg; + + phydev->speed = cmd->speed; + + phydev->advertising = cmd->advertising; + + if (AUTONEG_ENABLE == cmd->autoneg) + phydev->advertising |= ADVERTISED_Autoneg; + else + phydev->advertising &= ~ADVERTISED_Autoneg; + + phydev->duplex = cmd->duplex; + + /* Restart the PHY */ + phy_start_aneg(phydev); + + return 0; +} + +int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd) +{ + cmd->supported = phydev->supported; + + cmd->advertising = phydev->advertising; + + cmd->speed = phydev->speed; + cmd->duplex = phydev->duplex; + cmd->port = PORT_MII; + cmd->phy_address = phydev->addr; + cmd->transceiver = XCVR_EXTERNAL; + cmd->autoneg = phydev->autoneg; + + return 0; +} + + +/* Note that this function is currently incompatible with the + * PHYCONTROL layer. It changes registers without regard to + * current state. Use at own risk + */ +int phy_mii_ioctl(struct phy_device *phydev, + struct mii_ioctl_data *mii_data, int cmd) +{ + u16 val = mii_data->val_in; + + switch (cmd) { + case SIOCGMIIPHY: + mii_data->phy_id = phydev->addr; + break; + case SIOCGMIIREG: + mii_data->val_out = phy_read(phydev, mii_data->reg_num); + break; + + case SIOCSMIIREG: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + + if (mii_data->phy_id == phydev->addr) { + switch(mii_data->reg_num) { + case MII_BMCR: + if (val & (BMCR_RESET|BMCR_ANENABLE)) + phydev->autoneg = AUTONEG_DISABLE; + else + phydev->autoneg = AUTONEG_ENABLE; + if ((!phydev->autoneg) && (val & BMCR_FULLDPLX)) + phydev->duplex = DUPLEX_FULL; + else + phydev->duplex = DUPLEX_HALF; + break; + case MII_ADVERTISE: + phydev->advertising = val; + break; + default: + /* do nothing */ + break; + } + } + + phy_write(phydev, mii_data->reg_num, val); + break; + } + + return 0; +} + +/* phy_start_machine: + * + * description: The PHY infrastructure can run a state machine + * which tracks whether the PHY is starting up, negotiating, + * etc. This function starts the timer which tracks the state + * of the PHY. If you want to be notified when the state + * changes, pass in the callback, otherwise, pass NULL. If you + * want to maintain your own state machine, do not call this + * function. */ +void phy_start_machine(struct phy_device *phydev, + void (*handler)(struct net_device *)) +{ + phydev->adjust_state = handler; + + init_timer(&phydev->phy_timer); + phydev->phy_timer.function = &phy_timer; + phydev->phy_timer.data = (unsigned long) phydev; + mod_timer(&phydev->phy_timer, jiffies + HZ); +} + +/* phy_stop_machine + * + * description: Stops the state machine timer, sets the state to + * UP (unless it wasn't up yet), and then frees the interrupt, + * if it is in use. This function must be called BEFORE + * phy_detach. + */ +void phy_stop_machine(struct phy_device *phydev) +{ + del_timer_sync(&phydev->phy_timer); + + spin_lock(&phydev->lock); + if (phydev->state > PHY_UP) + phydev->state = PHY_UP; + spin_unlock(&phydev->lock); + + if (phydev->irq != PHY_POLL) { + phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED); + phy_clear_interrupt(phydev); + free_irq(phydev->irq, phydev); + } + + phydev->adjust_state = NULL; +} + + +#ifdef CONFIG_PHYCONTROL +/* phy_error: + * + * Moves the PHY to the HALTED state in response to a read + * or write error, and tells the controller the link is down. + * Must not be called from interrupt context, or while the + * phydev->lock is held. + */ +void phy_error(struct phy_device *phydev) +{ + spin_lock(&phydev->lock); + phydev->state = PHY_HALTED; + spin_unlock(&phydev->lock); +} + +/* phy_interrupt + * + * description: When a PHY interrupt occurs, the handler disables + * interrupts, and schedules a work task to clear the interrupt. + */ +static irqreturn_t phy_interrupt(int irq, void *phy_dat, struct pt_regs *regs) +{ + struct phy_device *phydev = phy_dat; + + /* The MDIO bus is not allowed to be written in interrupt + * context, so we need to disable the irq here. A work + * queue will write the PHY to disable and clear the + * interrupt, and then reenable the irq line. */ + disable_irq_nosync(irq); + + schedule_work(&phydev->phy_queue); + + return IRQ_HANDLED; +} + +/* Enable the interrupts from the PHY side */ +int phy_enable_interrupts(struct phy_device *phydev) +{ + int err; + + err = phy_clear_interrupt(phydev); + + if (err < 0) + return err; + + err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED); + + return err; +} + +/* Disable the PHY interrupts from the PHY side */ +int phy_disable_interrupts(struct phy_device *phydev) +{ + int err; + + /* Disable PHY interrupts */ + err = phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED); + + if (err) + goto phy_err; + + /* Clear the interrupt */ + err = phy_clear_interrupt(phydev); + + if (err) + goto phy_err; + +phy_err: + phy_error(phydev); +} + +/* phy_start_interrupts + * + * description: Request the interrupt for the given PHY. If + * this fails, then we set irq to PHY_POLL. + * Otherwise, we enable the interrupts in the PHY. + * Returns 0 on success. + * This should only be called with a valid IRQ number. + */ +int phy_start_interrupts(struct phy_device *phydev) +{ + int err = 0; + + INIT_WORK(&phydev->phy_queue, phy_change, phydev); + + if (request_irq(phydev->irq, phy_interrupt, + SA_SHIRQ, + "phy_interrupt", + phydev) < 0) { + printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n", + phydev->bus->name, + phydev->irq); + phydev->irq = PHY_POLL; + return 0; + } + + err = phy_enable_interrupts(phydev); + + return err; +} + +/* Scheduled by the phy_interrupt/timer to handle PHY changes */ +void phy_change(void *data) +{ + int err; + struct phy_device *phydev = data; + + err = phy_disable_interrupts(phydev); + + if (err) + goto phy_err; + + spin_lock(&phydev->lock); + if ((PHY_RUNNING == phydev->state) || (PHY_NOLINK == phydev->state)) + phydev->state = PHY_CHANGELINK; + spin_unlock(&phydev->lock); + + enable_irq(phydev->irq); + + /* Reenable interrupts */ + err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED); + + if (err) + goto irq_enable_err; + + return; + +irq_enable_err: + disable_irq(phydev->irq); +phy_err: + phy_error(phydev); +} + +/* Bring down the PHY link, and stop checking the status. */ +void phy_stop(struct phy_device *phydev) +{ + spin_lock(&phydev->lock); + + if (PHY_HALTED == phydev->state) { + spin_unlock(&phydev->lock); + return; + } + + if (phydev->irq != PHY_POLL) { + /* Clear any pending interrupts */ + phy_clear_interrupt(phydev); + + /* Disable PHY Interrupts */ + phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED); + } + + phydev->state = PHY_HALTED; + + spin_unlock(&phydev->lock); +} + + +/* phy_start + * + * description: Indicates the attached device's readiness to + * handle PHY-related work. Used during startup to start the + * PHY, and after a call to phy_stop() to resume operation. + * Also used to indicate the MDIO bus has cleared an error + * condition. + */ +void phy_start(struct phy_device *phydev) +{ + spin_lock(&phydev->lock); + + switch (phydev->state) { + case PHY_STARTING: + phydev->state = PHY_PENDING; + break; + case PHY_READY: + phydev->state = PHY_UP; + break; + case PHY_HALTED: + phydev->state = PHY_RESUMING; + default: + break; + } + spin_unlock(&phydev->lock); +} +EXPORT_SYMBOL(phy_stop); +EXPORT_SYMBOL(phy_start); + +/* PHY timer which handles the state machine */ +void phy_timer(unsigned long data) +{ + struct phy_device *phydev = (struct phy_device *)data; + int needs_aneg = 0; + int err = 0; + + spin_lock(&phydev->lock); + + if (phydev->adjust_state) + phydev->adjust_state(phydev->attached_dev); + + switch(phydev->state) { + case PHY_DOWN: + case PHY_STARTING: + case PHY_READY: + case PHY_PENDING: + break; + case PHY_UP: + needs_aneg = 1; + + phydev->link_timeout = PHY_AN_TIMEOUT; + + /* Start interrupts if we're handling them */ + if (phydev->irq >= 0) + err = phy_start_interrupts(phydev); + + break; + case PHY_AN: + /* Check if negotiation is done. Break + * if there's an error */ + err = phy_aneg_done(phydev); + if (err < 0) + break; + + /* If auto-negotiation is done, we change to + * either RUNNING, or NOLINK */ + if (err > 0) { + err = phy_read_status(phydev); + + if (err) + break; + + if (phydev->link) { + phydev->state = PHY_RUNNING; + netif_carrier_on(phydev->attached_dev); + } else { + phydev->state = PHY_NOLINK; + netif_carrier_off(phydev->attached_dev); + } + + phydev->adjust_link(phydev->attached_dev); + + } else if (0 == phydev->link_timeout--) { + /* The counter expired, so either we + * switch to forced mode, or the + * magic_aneg bit exists, and we try aneg + * again */ + if (!(phydev->drv->flags & PHY_HAS_MAGICANEG)) { + int idx; + + /* We'll start from the + * fastest speed, and work + * our way down */ + idx = phy_find_valid(0, + phydev->supported); + + phydev->speed = settings[idx].speed; + phydev->duplex = settings[idx].duplex; + + phydev->autoneg = AUTONEG_DISABLE; + phydev->state = PHY_FORCING; + phydev->link_timeout = + PHY_FORCE_TIMEOUT; + + pr_info("Trying %d/%s\n", + phydev->speed, + DUPLEX_FULL == + phydev->duplex ? + "FULL" : "HALF"); + } + + needs_aneg = 1; + } + break; + case PHY_NOLINK: + err = phy_read_status(phydev); + + if (err) + break; + + if (phydev->link) { + phydev->state = PHY_RUNNING; + netif_carrier_on(phydev->attached_dev); + phydev->adjust_link(phydev->attached_dev); + } + break; + case PHY_FORCING: + err = phy_read_status(phydev); + + if (err) + break; + + if (phydev->link) { + phydev->state = PHY_RUNNING; + netif_carrier_on(phydev->attached_dev); + } else { + if (0 == phydev->link_timeout--) { + phy_force_reduction(phydev); + needs_aneg = 1; + } + } + + phydev->adjust_link(phydev->attached_dev); + break; + case PHY_RUNNING: + /* Only register a CHANGE if we are + * polling */ + if (PHY_POLL == phydev->irq) + phydev->state = PHY_CHANGELINK; + break; + case PHY_CHANGELINK: + err = phy_read_status(phydev); + + if (err) + break; + + if (phydev->link) { + phydev->state = PHY_RUNNING; + netif_carrier_on(phydev->attached_dev); + } else { + phydev->state = PHY_NOLINK; + netif_carrier_off(phydev->attached_dev); + } + + phydev->adjust_link(phydev->attached_dev); + + if (PHY_POLL != phydev->irq) + err = phy_config_interrupt(phydev, + PHY_INTERRUPT_ENABLED); + break; + case PHY_HALTED: + if (phydev->link) { + phydev->link = 0; + netif_carrier_off(phydev->attached_dev); + phydev->adjust_link(phydev->attached_dev); + } + break; + case PHY_RESUMING: + + err = phy_clear_interrupt(phydev); + + if (err) + break; + + err = phy_config_interrupt(phydev, + PHY_INTERRUPT_ENABLED); + + if (err) + break; + + if (AUTONEG_ENABLE == phydev->autoneg) { + err = phy_aneg_done(phydev); + if (err < 0) + break; + + /* err > 0 if AN is done. + * Otherwise, it's 0, and we're + * still waiting for AN */ + if (err > 0) { + phydev->state = PHY_RUNNING; + } else { + phydev->state = PHY_AN; + phydev->link_timeout = PHY_AN_TIMEOUT; + } + } else + phydev->state = PHY_RUNNING; + break; + } + + spin_unlock(&phydev->lock); + + if (needs_aneg) + err = phy_start_aneg(phydev); + + if (err < 0) + phy_error(phydev); + + mod_timer(&phydev->phy_timer, jiffies + PHY_STATE_TIME * HZ); +} + +#endif /* CONFIG_PHYCONTROL */ diff -Nru a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/phy_device.c 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,677 @@ +/* + * drivers/net/phy/phy_device.c + * + * Framework for finding and configuring PHYs. + * Also contains generic PHY driver + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* get_phy_device + * + * description: Reads the ID registers of the PHY at addr on the + * bus, then allocates and returns the phy_device to + * represent it. + */ +struct phy_device * get_phy_device(struct mii_bus *bus, uint addr) +{ + int phy_reg; + u32 phy_id; + struct phy_device *dev = NULL; + + errno = 0; + + /* Grab the bits from PHYIR1, and put them + * in the upper half */ + phy_reg = bus->read(bus, addr, MII_PHYSID1); + + if (phy_reg < 0) { + errno = phy_reg; + return NULL; + } + + phy_id = (phy_reg & 0xffff) << 16; + + /* Grab the bits from PHYIR2, and put them in the lower half */ + phy_reg = bus->read(bus, addr, MII_PHYSID2); + + if (phy_reg < 0) { + errno = phy_reg; + return NULL; + } + + phy_id |= (phy_reg & 0xffff); + + /* If the phy_id is all Fs, there is no device there */ + if (0xffffffff == phy_id) + return NULL; + + /* Otherwise, we allocate the device, and initialize the + * default values */ + dev = kmalloc(sizeof(*dev), GFP_KERNEL); + + if (NULL == dev) { + errno = -ENOMEM; + return NULL; + } + + memset(dev, 0, sizeof(*dev)); + + dev->speed = 0; + dev->duplex = -1; + dev->pause = dev->asym_pause = 0; + dev->link = 1; + + dev->autoneg = AUTONEG_ENABLE; + + dev->addr = addr; + dev->phy_id = phy_id; + dev->bus = bus; + + dev->state = PHY_DOWN; + + spin_lock_init(&dev->lock); + + return dev; +} + +/* phy_prepare_link: + * + * description: Tells the PHY infrastructure to handle the + * gory details on monitoring link status (whether through + * polling or an interrupt), and to call back to the + * connected device driver when the link status changes. + * If you want to monitor your own link state, don't call + * this function */ +void phy_prepare_link(struct phy_device *phydev, + void (*handler)(struct net_device *)) +{ + phydev->adjust_link = handler; +} + +#ifdef CONFIG_PHYCONTROL +/* phy_connect: + * + * description: Convenience function for connecting ethernet + * devices to PHY devices. The default behavior is for + * the PHY infrastructure to handle everything, and only notify + * the connected driver when the link status changes. If you + * don't want, or can't use the provided functionality, you may + * choose to call only the subset of functions which provide + * the desired functionality. + */ +struct phy_device * phy_connect(struct net_device *dev, const char *phy_id, + void (*handler)(struct net_device *)) +{ + struct phy_device *phydev; + + phydev = phy_attach(dev, phy_id); + + if (NULL == phydev) + return phydev; + + phy_prepare_link(phydev, handler); + + phy_start_machine(phydev, NULL); + + return phydev; +} +EXPORT_SYMBOL(phy_connect); + +void phy_disconnect(struct phy_device *phydev) +{ + phy_stop_machine(phydev); + + phydev->adjust_link = NULL; + + phy_detach(phydev); +} +EXPORT_SYMBOL(phy_disconnect); + +#endif /* CONFIG_PHYCONTROL */ + +/* phy_attach: + * + * description: Called by drivers to attach to a particular PHY + * device. The phy_device is found, and properly hooked up + * to the phy_driver. If no driver is attached, then the + * genphy_driver is used. The phy_device is given a ptr to + * the attaching device, and given a callback for link status + * change. The phy_device is returned to the attaching + * driver. + */ +struct phy_device *phy_attach(struct net_device *dev, const char *phy_id) +{ + struct phy_device *phydev = NULL; + struct bus_type *bus = &mdio_bus_type; + struct list_head *entry; + + /* Search the list of PHY devices on the mdio bus for the + * PHY with the requested name */ + list_for_each(entry, &bus->devices.list) + { + struct device *d = container_of(entry, struct device, bus_list); + + if (!strcmp(phy_id, d->bus_id)) { + phydev = to_phy_device(d); + break; + } + } + + if (NULL == phydev) { + printk(KERN_ERR "%s not found\n", phy_id); + errno = -ENODEV; + return NULL; + } + + /* Assume that if there is no driver, that it doesn't + * exist, and we should use the genphy driver. */ + if (NULL == phydev->dev.driver) { + int err; + down_write(&phydev->dev.bus->subsys.rwsem); + phydev->dev.driver = &genphy_driver.driver; + + err = phydev->dev.driver->probe(&phydev->dev); + + if (err < 0) { + errno = err; + return NULL; + } + + device_bind_driver(&phydev->dev); + up_write(&phydev->dev.bus->subsys.rwsem); + } + + if (phydev->attached_dev) { + printk(KERN_ERR "%s: %s already attached\n", + dev->name, phy_id); + errno = -EBUSY; + return NULL; + } + + phydev->attached_dev = dev; + + return phydev; +} +EXPORT_SYMBOL(phy_attach); + +void phy_detach(struct phy_device *phydev) +{ + phydev->attached_dev = NULL; + + /* If the device had no specific driver before (i.e. - it + * was using the generic driver), we unbind the device + * from the generic driver so that there's a chance a + * real driver could be loaded */ + if (phydev->dev.driver == &genphy_driver.driver) { + down_write(&phydev->dev.bus->subsys.rwsem); + device_release_driver(&phydev->dev); + up_write(&phydev->dev.bus->subsys.rwsem); + } +} +EXPORT_SYMBOL(phy_detach); + + +/* Generic PHY support and helper functions */ + +/* genphy_config_advert + * + * description: Writes MII_ADVERTISE with the appropriate values, + * after sanitizing the values to make sure we only advertise + * what is supported + */ +int genphy_config_advert(struct phy_device *phydev) +{ + u32 advertise; + int adv; + int err; + + /* Only allow advertising what + * this PHY supports */ + phydev->advertising &= phydev->supported; + advertise = phydev->advertising; + + /* Setup standard advertisement */ + adv = phy_read(phydev, MII_ADVERTISE); + + if (adv < 0) + return adv; + + adv &= ~(ADVERTISE_ALL | ADVERTISE_100BASE4 | ADVERTISE_PAUSE_CAP | + ADVERTISE_PAUSE_ASYM); + if (advertise & ADVERTISED_10baseT_Half) + adv |= ADVERTISE_10HALF; + if (advertise & ADVERTISED_10baseT_Full) + adv |= ADVERTISE_10FULL; + if (advertise & ADVERTISED_100baseT_Half) + adv |= ADVERTISE_100HALF; + if (advertise & ADVERTISED_100baseT_Full) + adv |= ADVERTISE_100FULL; + if (advertise & ADVERTISED_Pause) + adv |= ADVERTISE_PAUSE_CAP; + if (advertise & ADVERTISED_Asym_Pause) + adv |= ADVERTISE_PAUSE_ASYM; + + err = phy_write(phydev, MII_ADVERTISE, adv); + + if (err < 0) + return err; + + /* Configure gigabit if it's supported */ + if (phydev->supported & (SUPPORTED_1000baseT_Half | + SUPPORTED_1000baseT_Full)) { + adv = phy_read(phydev, MII_CTRL1000); + + if (adv < 0) + return adv; + + adv &= ~(ADVERTISE_1000FULL | ADVERTISE_1000HALF); + if (advertise & SUPPORTED_1000baseT_Half) + adv |= ADVERTISE_1000HALF; + if (advertise & SUPPORTED_1000baseT_Full) + adv |= ADVERTISE_1000FULL; + err = phy_write(phydev, MII_CTRL1000, adv); + + if (err < 0) + return err; + } + + return adv; +} + + +/* genphy_setup_forced + * + * description: Configures MII_BMCR to force speed/duplex + * to the values in phydev. Assumes that the values are valid. + * Please see phy_sanitize_settings() */ +int genphy_setup_forced(struct phy_device *phydev) +{ + int ctl = phy_read(phydev, MII_BMCR); + + if (ctl < 0) + return ctl; + + phydev->pause = phydev->asym_pause = 0; + + ctl &= ~(BMCR_FULLDPLX|BMCR_SPEED100|BMCR_SPEED1000|BMCR_ANENABLE); + ctl |= BMCR_RESET; + + if (SPEED_1000 == phydev->speed) + ctl |= BMCR_SPEED1000; + else if (SPEED_100 == phydev->speed) + ctl |= BMCR_SPEED100; + + if (DUPLEX_FULL == phydev->duplex) + ctl |= BMCR_FULLDPLX; + + ctl = phy_write(phydev, MII_BMCR, ctl); + + return ctl; +} + + +/* Enable and Restart Autonegotiation */ +int genphy_restart_aneg(struct phy_device *phydev) +{ + int ctl; + + ctl = phy_read(phydev, MII_BMCR); + + if (ctl < 0) + return ctl; + + ctl |= (BMCR_ANENABLE | BMCR_ANRESTART); + + ctl = phy_write(phydev, MII_BMCR, ctl); + + return ctl; +} + + +/* genphy_config_aneg + * + * description: If auto-negotiation is enabled, we configure the + * advertising, and then restart auto-negotiation. If it is not + * enabled, then we write the BMCR + */ +int genphy_config_aneg(struct phy_device *phydev) +{ + int err = 0; + + if (AUTONEG_ENABLE == phydev->autoneg) { + err = genphy_config_advert(phydev); + + if (err < 0) + return err; + + err = genphy_restart_aneg(phydev); + } else + err = genphy_setup_forced(phydev); + + return err; +} + + +/* genphy_update_link + * + * description: Update the value in phydev->link to reflect the + * current link value. In order to do this, we need to read + * the status register twice, keeping the second value + */ +int genphy_update_link(struct phy_device *phydev) +{ + int status; + + /* Do a fake read */ + status = phy_read(phydev, MII_BMSR); + + if (status < 0) + return status; + + /* Read link and autonegotiation status */ + status = phy_read(phydev, MII_BMSR); + + if (status < 0) + return status; + + if ((status & BMSR_LSTATUS) == 0) + phydev->link = 0; + else + phydev->link = 1; + + return 0; +} + +/* genphy_read_status + * + * description: Check the link, then figure out the current state + * by comparing what we advertise with what the link partner + * advertises. Start by checking the gigabit possibilities, + * then move on to 10/100. + */ +int genphy_read_status(struct phy_device *phydev) +{ + int adv; + int err; + int lpa; + int lpagb = 0; + + /* Update the link, but return if there + * was an error */ + err = genphy_update_link(phydev); + if (err) + return err; + + if (AUTONEG_ENABLE == phydev->autoneg) { + if (phydev->supported & (SUPPORTED_1000baseT_Half + | SUPPORTED_1000baseT_Full)) { + lpagb = phy_read(phydev, MII_STAT1000); + + if (lpagb < 0) + return lpagb; + + adv = phy_read(phydev, MII_CTRL1000); + + if (adv < 0) + return adv; + + lpagb &= adv << 2; + } + + lpa = phy_read(phydev, MII_LPA); + + if (lpa < 0) + return lpa; + + adv = phy_read(phydev, MII_ADVERTISE); + + if (adv < 0) + return adv; + + lpa &= adv; + + phydev->speed = SPEED_10; + phydev->duplex = DUPLEX_HALF; + phydev->pause = phydev->asym_pause = 0; + + if (lpagb & (LPA_1000FULL | LPA_1000HALF)) { + phydev->speed = SPEED_1000; + + if (lpagb & LPA_1000FULL) + phydev->duplex = DUPLEX_FULL; + } else if (lpa & (LPA_100FULL | LPA_100HALF)) { + phydev->speed = SPEED_100; + + if (lpa & LPA_100FULL) + phydev->duplex = DUPLEX_FULL; + } else + if (lpa & LPA_10FULL) + phydev->duplex = DUPLEX_FULL; + + if (phydev->duplex == DUPLEX_FULL){ + phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0; + phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0; + } + } else { + int bmcr = phy_read(phydev, MII_BMCR); + if (bmcr < 0) + return bmcr; + + if (bmcr & BMCR_FULLDPLX) + phydev->duplex = DUPLEX_FULL; + else + phydev->duplex = DUPLEX_HALF; + + if (bmcr & BMCR_SPEED1000) + phydev->speed = SPEED_1000; + else if (bmcr & BMCR_SPEED100) + phydev->speed = SPEED_100; + else + phydev->speed = SPEED_10; + + phydev->pause = phydev->asym_pause = 0; + } + + return 0; +} + + +static int genphy_probe(struct phy_device *phydev) +{ + u32 val; + u32 features; + + /* For now, I'll claim that the generic driver supports + * all possible port types */ + features = (SUPPORTED_TP | SUPPORTED_MII + | SUPPORTED_AUI | SUPPORTED_FIBRE | + SUPPORTED_BNC); + + /* Do we support autonegotiation? */ + val = phy_read(phydev, MII_BMSR); + + if (val < 0) + return val; + + if (val & BMSR_ANEGCAPABLE) + features |= SUPPORTED_Autoneg; + + if (val & BMSR_100FULL) + features |= SUPPORTED_100baseT_Full; + if (val & BMSR_100HALF) + features |= SUPPORTED_100baseT_Half; + if (val & BMSR_10FULL) + features |= SUPPORTED_10baseT_Full; + if (val & BMSR_10HALF) + features |= SUPPORTED_10baseT_Half; + + if (val & BMSR_ESTATEN) { + val = phy_read(phydev, MII_ESTATUS); + + if (val < 0) + return val; + + if (val & ESTATUS_1000_TFULL) + features |= SUPPORTED_1000baseT_Full; + if (val & ESTATUS_1000_THALF) + features |= SUPPORTED_1000baseT_Half; + } + + phydev->supported = features; + phydev->advertising = features; + + return 0; +} + + +/* phy_probe + * + * description: Take care of setting up the phy_device structure, + * set the state to READY (the driver's probe function should + * set it to STARTING if needed). + */ +int phy_probe(struct device *dev) +{ + struct phy_device *phydev; + struct phy_driver *phydrv; + struct device_driver *drv; + int err = 0; + + phydev = to_phy_device(dev); + + /* Make sure the driver is held. + * XXX -- Is this correct? */ + drv = get_driver(phydev->dev.driver); + phydrv = to_phy_driver(drv); + phydev->drv = phydrv; + + /* Disable the interrupt if the PHY doesn't support it */ + if (!(phydrv->flags & PHY_HAS_INTERRUPT)) + phydev->irq = PHY_POLL; + + spin_lock(&phydev->lock); + + /* Start out supporting everything. Eventually, + * a controller will attach, and may modify one + * or both of these values */ + phydev->supported = phydrv->features; + phydev->advertising = phydrv->features; + + /* Set the state to READY by default */ + phydev->state = PHY_READY; + + if (phydev->drv->probe) + err = phydev->drv->probe(phydev); + + spin_unlock(&phydev->lock); + + return err; +} + +int phy_remove(struct device *dev) +{ + struct phy_device *phydev; + + phydev = to_phy_device(dev); + + spin_lock(&phydev->lock); + phydev->state = PHY_DOWN; + spin_unlock(&phydev->lock); + + if (phydev->drv->remove) + phydev->drv->remove(phydev); + + put_driver(phydev->dev.driver); + phydev->drv = NULL; + + return 0; +} + +int phy_driver_register(struct phy_driver *new_driver) +{ + int retval; + + memset(&new_driver->driver, 0, sizeof(new_driver->driver)); + new_driver->driver.name = new_driver->name; + new_driver->driver.bus = &mdio_bus_type; + new_driver->driver.probe = phy_probe; + new_driver->driver.remove = phy_remove; + + retval = driver_register(&new_driver->driver); + + if (retval) { + printk(KERN_ERR "%s: Error %d in registering driver\n", + new_driver->name, retval); + + return retval; + } + + pr_info("%s: Registered new driver\n", new_driver->name); + + return 0; +} + +void phy_driver_unregister(struct phy_driver *drv) +{ + driver_unregister(&drv->driver); +} + +struct phy_driver genphy_driver = { + .phy_id = 0xffffffff, + .phy_id_mask = 0xffffffff, + .name = "Generic PHY", + .probe = genphy_probe, + .features = 0, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, +}; + +static int __init genphy_init(void) +{ + int retval; + + retval = phy_driver_register(&genphy_driver); + + return retval; +} + +static void __exit genphy_exit(void) +{ + phy_driver_unregister(&genphy_driver); +} + +module_init(genphy_init); +module_exit(genphy_exit); diff -Nru a/drivers/net/phy/qsemi.c b/drivers/net/phy/qsemi.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/qsemi.c 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,143 @@ +/* + * drivers/net/phy/qsemi.c + * + * Driver for Quality Semiconductor PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* ------------------------------------------------------------------------- */ +/* The Quality Semiconductor QS6612 is used on the RPX CLLF */ + +/* register definitions */ + +#define MII_QS6612_MCR 17 /* Mode Control Register */ +#define MII_QS6612_FTR 27 /* Factory Test Register */ +#define MII_QS6612_MCO 28 /* Misc. Control Register */ +#define MII_QS6612_ISR 29 /* Interrupt Source Register */ +#define MII_QS6612_IMR 30 /* Interrupt Mask Register */ +#define MII_QS6612_IMR_INIT 0x003a +#define MII_QS6612_PCR 31 /* 100BaseTx PHY Control Reg. */ + +#define QS6612_PCR_AN_COMPLETE 0x1000 +#define QS6612_PCR_RLBEN 0x0200 +#define QS6612_PCR_DCREN 0x0100 +#define QS6612_PCR_4B5BEN 0x0040 +#define QS6612_PCR_TX_ISOLATE 0x0020 +#define QS6612_PCR_MLT3_DIS 0x0002 +#define QS6612_PCR_SCRM_DESCRM 0x0001 + + +/* Returns 0, unless there's a write error */ +int qs6612_probe(struct phy_device *phydev) +{ + /* The PHY powers up isolated on the RPX, + * so send a command to allow operation. + * XXX - My docs indicate this should be 0x0940 + * ...or something. The current value sets three + * reserved bits, bit 11, which specifies it should be + * set to one, bit 10, which specifies it should be set + * to 0, and bit 7, which doesn't specify. However, my + * docs are preliminary, and I will leave it like this + * until someone more knowledgable corrects me or it. + * -- Andy Fleming + */ + return phy_write(phydev, MII_QS6612_PCR, 0x0dc0); +} + +int qs6612_ack_interrupt(struct phy_device *phydev) +{ + int err; + + err = phy_read(phydev, MII_QS6612_ISR); + + if (err < 0) + return err; + + err = phy_read(phydev, MII_BMSR); + + if (err < 0) + return err; + + err = phy_read(phydev, MII_EXPANSION); + + if (err < 0) + return err; + + return 0; +} + +int qs6612_config_intr(struct phy_device *phydev) +{ + int err; + if (phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_QS6612_IMR, + MII_QS6612_IMR_INIT); + else + err = phy_write(phydev, MII_QS6612_IMR, 0); + + return err; + +} + +static struct phy_driver qs6612_driver = { + .phy_id = 0x00181440, + .name = "QS6612", + .phy_id_mask = 0xfffffff0, + .features = PHY_BASIC_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .probe = qs6612_probe, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, + .ack_interrupt = qs6612_ack_interrupt, + .config_intr = qs6612_config_intr, +}; + +int __init qs6612_init(void) +{ + int retval; + + retval = phy_driver_register(&qs6612_driver); + + return retval; +} + +static void __exit qs6612_exit(void) +{ + phy_driver_unregister(&qs6612_driver); +} + +module_init(qs6612_init); +module_exit(qs6612_exit); diff -Nru a/include/linux/mii.h b/include/linux/mii.h --- a/include/linux/mii.h 2005-05-09 13:19:25 -05:00 +++ b/include/linux/mii.h 2005-05-09 13:19:25 -05:00 @@ -22,6 +22,7 @@ #define MII_EXPANSION 0x06 /* Expansion register */ #define MII_CTRL1000 0x09 /* 1000BASE-T control */ #define MII_STAT1000 0x0a /* 1000BASE-T status */ +#define MII_ESTATUS 0x0f /* Extended Status */ #define MII_DCOUNTER 0x12 /* Disconnect counter */ #define MII_FCSCOUNTER 0x13 /* False carrier counter */ #define MII_NWAYTEST 0x14 /* N-way auto-neg test reg */ @@ -54,7 +55,10 @@ #define BMSR_ANEGCAPABLE 0x0008 /* Able to do auto-negotiation */ #define BMSR_RFAULT 0x0010 /* Remote fault detected */ #define BMSR_ANEGCOMPLETE 0x0020 /* Auto-negotiation complete */ -#define BMSR_RESV 0x07c0 /* Unused... */ +#define BMSR_RESV 0x00c0 /* Unused... */ +#define BMSR_ESTATEN 0x0100 /* Extended Status in R15 */ +#define BMSR_100FULL2 0x0200 /* Can do 100BASE-T2 HDX */ +#define BMSR_100HALF2 0x0400 /* Can do 100BASE-T2 FDX */ #define BMSR_10HALF 0x0800 /* Can do 10mbps, half-duplex */ #define BMSR_10FULL 0x1000 /* Can do 10mbps, full-duplex */ #define BMSR_100HALF 0x2000 /* Can do 100mbps, half-duplex */ @@ -105,6 +109,9 @@ #define EXPANSION_NPCAPABLE 0x0008 /* Link partner supports npage */ #define EXPANSION_MFAULTS 0x0010 /* Multiple faults detected */ #define EXPANSION_RESV 0xffe0 /* Unused... */ + +#define ESTATUS_1000_TFULL 0x2000 /* Can do 1000BT Full */ +#define ESTATUS_1000_THALF 0x1000 /* Can do 1000BT Half */ /* N-way test register. */ #define NWAYTEST_RESV1 0x00ff /* Unused... */ diff -Nru a/include/linux/phy.h b/include/linux/phy.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/include/linux/phy.h 2005-05-09 13:19:26 -05:00 @@ -0,0 +1,362 @@ +/* + * include/linux/phy.h + * + * Framework and drivers for configuring and reading different PHYs + * Based on code in sungem_phy.c and gianfar_phy.c + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#ifndef __PHY_H +#define __PHY_H + +#include +#include + +#define PHY_BASIC_FEATURES (SUPPORTED_10baseT_Half | \ + SUPPORTED_10baseT_Full | \ + SUPPORTED_100baseT_Half | \ + SUPPORTED_100baseT_Full | \ + SUPPORTED_Autoneg | \ + SUPPORTED_TP | \ + SUPPORTED_MII) + +#define PHY_GBIT_FEATURES (PHY_BASIC_FEATURES | \ + SUPPORTED_1000baseT_Half | \ + SUPPORTED_1000baseT_Full) + +/* Set phydev->irq to PHY_POLL if interrupts are not supported, + * or not desired for this PHY. Set to PHY_IGNORE_INTERRUPT if + * the attached driver handles the interrupt + */ +#define PHY_POLL -1 +#define PHY_IGNORE_INTERRUPT -2 + +#define PHY_HAS_INTERRUPT 0x00000001 +#define PHY_HAS_MAGICANEG 0x00000002 + +#define MII_BUS_MAX 4 + + +#define PHY_INIT_TIMEOUT 100000 +#define PHY_STATE_TIME 1 +#define PHY_FORCE_TIMEOUT 10 +#define PHY_AN_TIMEOUT 10 + +#define PHY_MAX_ADDR 32 + +/* The Bus class for PHYs. Devices which provide access to + * PHYs should register using this structure */ +struct mii_bus { + const char *name; + int id; + void *priv; + int (*read)(struct mii_bus *bus, int phy_id, int regnum); + int (*write)(struct mii_bus *bus, int phy_id, int regnum, u16 val); + int (*reset)(struct mii_bus *bus); + + /* A lock to ensure that only one thing can read/write + * the MDIO bus at a time */ + spinlock_t mdio_lock; + + struct device *dev; + + /* list of all PHYs on bus */ + struct phy_device *phy_map[PHY_MAX_ADDR]; + + /* Pointer to an array of interrupts, each PHY's + * interrupt at the index matching its address */ + int *irq; +}; + +#define PHY_INTERRUPT_DISABLED 0x0 +#define PHY_INTERRUPT_ENABLED 0x80000000 + +/* PHY state machine states: + * + * DOWN: PHY device and driver are not ready for anything. probe + * should be called if and only if the PHY is in this state, + * given that the PHY device exists. + * - PHY driver probe function will, depending on the PHY, set + * the state to STARTING or READY + * + * STARTING: PHY device is coming up, and the ethernet driver is + * not ready. PHY drivers may set this in the probe function. + * If they do, they are responsible for making sure the state is + * eventually set to indicate whether the PHY is UP or READY, + * depending on the state when the PHY is done starting up. + * - PHY driver will set the state to READY + * - start will set the state to PENDING + * + * READY: PHY is ready to send and receive packets, but the + * controller is not. By default, PHYs which do not implement + * probe will be set to this state by phy_probe(). If the PHY + * driver knows the PHY is ready, and the PHY state is STARTING, + * then it sets this STATE. + * - start will set the state to UP + * + * PENDING: PHY device is coming up, but the ethernet driver is + * ready. phy_start will set this state if the PHY state is + * STARTING. + * - PHY driver will set the state to UP when the PHY is ready + * + * UP: The PHY and attached device are ready to do work. + * Interrupts should be started here. + * - timer moves to AN + * + * AN: The PHY is currently negotiating the link state. Link is + * therefore down for now. phy_timer will set this state when it + * detects the state is UP. config_aneg will set this state + * whenever called with phydev->autoneg set to AUTONEG_ENABLE. + * - If autonegotiation finishes, but there's no link, it sets + * the state to NOLINK. + * - If aneg finishes with link, it sets the state to RUNNING, + * and calls adjust_link + * - If autonegotiation did not finish after an arbitrary amount + * of time, autonegotiation should be tried again if the PHY + * supports "magic" autonegotiation (back to AN) + * - If it didn't finish, and no magic_aneg, move to FORCING. + * + * NOLINK: PHY is up, but not currently plugged in. + * - If the timer notes that the link comes back, we move to RUNNING + * - config_aneg moves to AN + * - phy_stop moves to HALTED + * + * FORCING: PHY is being configured with forced settings + * - if link is up, move to RUNNING + * - If link is down, we drop to the next highest setting, and + * retry (FORCING) after a timeout + * - phy_stop moves to HALTED + * + * RUNNING: PHY is currently up, running, and possibly sending + * and/or receiving packets + * - timer will set CHANGELINK if we're polling (this ensures the + * link state is polled every other cycle of this state machine, + * which makes it every other second) + * - irq will set CHANGELINK + * - config_aneg will set AN + * - phy_stop moves to HALTED + * + * CHANGELINK: PHY experienced a change in link state + * - timer moves to RUNNING if link + * - timer moves to NOLINK if the link is down + * - phy_stop moves to HALTED + * + * HALTED: PHY is up, but no polling or interrupts are done. Or + * PHY is in an error state. + * + * - phy_start moves to RESUMING + * + * RESUMING: PHY was halted, but now wants to run again. + * - If we are forcing, or aneg is done, timer moves to RUNNING + * - If aneg is not done, timer moves to AN + * - phy_stop moves to HALTED + */ +enum phy_state { + PHY_DOWN=0, + PHY_STARTING, + PHY_READY, + PHY_PENDING, + PHY_UP, + PHY_AN, + PHY_RUNNING, + PHY_NOLINK, + PHY_FORCING, + PHY_CHANGELINK, + PHY_HALTED, + PHY_RESUMING +}; + +/* phy_device: An instance of a PHY + * + * drv: Pointer to the driver for this PHY instance + * bus: Pointer to the bus this PHY is on + * dev: driver model device structure for this PHY + * phy_id: UID for this device found during discovery + * state: state of the PHY for management purposes + * addr: Bus address of PHY + * link_timeout: The number of timer firings to wait before the + * giving up on the current attempt at acquiring a link + * irq: IRQ number of the PHY's interrupt (-1 if none) + * phy_timer: The timer for handling the state machine + * phy_queue: A work_queue for the interrupt + * attached_dev: The attached enet driver's device instance ptr + * adjust_link: Callback for the enet controller to respond to + * changes in the link state. + * adjust_state: Callback for the enet driver to respond to + * changes in the state machine. + * + * speed, duplex, pause, supported, advertising, and + * autoneg are used like in mii_if_info + * + * interrupts currently only supports enabled or disabled, + * but could be changed in the future to support enabling + * and disabling specific interrupts + * + * Contains some infrastructure for polling and interrupt + * handling, as well as handling shifts in PHY hardware state + */ +struct phy_device { + /* Information about the PHY type */ + /* And management functions */ + struct phy_driver *drv; + + struct mii_bus *bus; + + struct device dev; + + u32 phy_id; + + enum phy_state state; + + /* Bus address of the PHY (0-32) */ + int addr; + + /* forced speed & duplex (no autoneg) + * partner speed & duplex & pause (autoneg) + */ + int speed; + int duplex; + int pause; + int asym_pause; + + /* The most recently read link state */ + int link; + + /* Enabled Interrupts */ + u32 interrupts; + + /* Union of PHY and Attached devices' supported modes */ + /* See mii.h for more info */ + u32 supported; + u32 advertising; + + int autoneg; + + int link_timeout; + + /* Interrupt number for this PHY + * -1 means no interrupt */ + int irq; + + /* private data pointer */ + /* For use by PHYs to maintain extra state */ + void *priv; + + /* Interrupt and Polling infrastructure */ + struct work_struct phy_queue; + struct timer_list phy_timer; + + spinlock_t lock; + + struct net_device *attached_dev; + + void (*adjust_link)(struct net_device *dev); + + void (*adjust_state)(struct net_device *dev); +}; +#define to_phy_device(d) container_of(d, struct phy_device, dev) + +/* struct phy_driver: Driver structure for a particular PHY type + * + * phy_id: The result of reading the UID registers of this PHY + * type, and ANDing them with the phy_id_mask. This driver + * only works for PHYs with IDs which match this field + * name: The friendly name of this PHY type + * phy_id_mask: Defines the important bits of the phy_id + * features: A list of features (speed, duplex, etc) supported + * by this PHY + * flags: A bitfield defining certain other features this PHY + * supports (like interrupts) + * + * The drivers must implement config_aneg and read_status. All + * other functions are optional. Note that none of these + * functions should be called from interrupt time. The goal is + * for the bus read/write functions to be able to block when the + * bus transaction is happening, and be freed up by an interrupt + * (The MPC85xx has this ability, though it is not currently + * supported in the driver). + */ +struct phy_driver { + u32 phy_id; + char *name; + unsigned int phy_id_mask; + u32 features; + u32 flags; + + /* Called to initialize the PHY */ + int (*probe)(struct phy_device *phydev); + + /* PHY Power Management */ + int (*suspend)(struct phy_device *phydev); + int (*resume)(struct phy_device *phydev); + + /* Configures the advertisement and resets + * autonegotiation if phydev->autoneg is on, + * forces the speed to the current settings in phydev + * if phydev->autoneg is off */ + int (*config_aneg)(struct phy_device *phydev); + + /* Determines the negotiated speed and duplex */ + int (*read_status)(struct phy_device *phydev); + + /* Clears any pending interrupts */ + int (*ack_interrupt)(struct phy_device *phydev); + + /* Enables or disables interrupts */ + int (*config_intr)(struct phy_device *phydev); + + /* Clears up any memory if needed */ + void (*remove)(struct phy_device *phydev); + + struct device_driver driver; +}; +#define to_phy_driver(d) container_of(d, struct phy_driver, driver) + +int phy_read(struct phy_device *phydev, u16 regnum); +int phy_write(struct phy_device *phydev, u16 regnum, u16 val); +struct phy_device* get_phy_device(struct mii_bus *bus, uint addr); +int phy_clear_interrupt(struct phy_device *phydev); +int phy_config_interrupt(struct phy_device *phydev, u32 interrupts); +struct phy_device * phy_attach(struct net_device *dev, const char *phy_id); +struct phy_device * phy_connect(struct net_device *dev, const char *phy_id, + void (*handler)(struct net_device *)); +void phy_disconnect(struct phy_device *phydev); +void phy_detach(struct phy_device *phydev); +void phy_start(struct phy_device *phydev); +void phy_stop(struct phy_device *phydev); +int phy_start_aneg(struct phy_device *phydev); +int phy_read_status(struct phy_device *phydev); +int mdiobus_register(struct mii_bus *bus); +void mdiobus_unregister(struct mii_bus *bus); +void phy_sanitize_settings(struct phy_device *phydev); + +int genphy_config_advert(struct phy_device *phydev); +int genphy_setup_forced(struct phy_device *phydev); +int genphy_restart_aneg(struct phy_device *phydev); +int genphy_config_aneg(struct phy_device *phydev); +int genphy_update_link(struct phy_device *phydev); +int genphy_read_status(struct phy_device *phydev); +void phy_driver_unregister(struct phy_driver *drv); +int phy_driver_register(struct phy_driver *new_driver); +void phy_prepare_link(struct phy_device *phydev, + void (*adjust_link)(struct net_device *)); +void phy_start_machine(struct phy_device *phydev, + void (*handler)(struct net_device *)); +void phy_stop_machine(struct phy_device *phydev); +int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd); +int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd); +int phy_mii_ioctl(struct phy_device *phydev, + struct mii_ioctl_data *mii_data, int cmd); + +extern struct bus_type mdio_bus_type; +extern struct phy_driver genphy_driver; +#endif /* __PHY_H */ diff -Nru a/include/linux/ethtool.h b/include/linux/ethtool.h --- a/include/linux/ethtool.h 2005-05-09 13:19:25 -05:00 +++ b/include/linux/ethtool.h 2005-05-09 13:19:25 -05:00 @@ -389,6 +389,7 @@ #define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */ #define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */ + /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET #define SPARC_ETH_SSET ETHTOOL_SSET @@ -407,6 +408,8 @@ #define SUPPORTED_FIBRE (1 << 10) #define SUPPORTED_BNC (1 << 11) #define SUPPORTED_10000baseT_Full (1 << 12) +#define SUPPORTED_Pause (1 << 13) +#define SUPPORTED_Asym_Pause (1 << 14) /* Indicates what features are advertised by the interface. */ #define ADVERTISED_10baseT_Half (1 << 0) @@ -422,6 +425,8 @@ #define ADVERTISED_FIBRE (1 << 10) #define ADVERTISED_BNC (1 << 11) #define ADVERTISED_10000baseT_Full (1 << 12) +#define ADVERTISED_Pause (1 << 13) +#define ADVERTISED_Asym_Pause (1 << 14) /* The following are all involved in forcing a particular link * mode for the device for setting things. When getting the --Apple-Mail-1--1458116-- From asimshankar@gmail.com Tue May 10 10:12:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 10:12:47 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AHCiOv002329 for ; Tue, 10 May 2005 10:12:44 -0700 Received: by wproxy.gmail.com with SMTP id 68so1688998wri for ; Tue, 10 May 2005 10:12:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MzgQqTsaTmmJHkWOyv38JqBiAppikjt/4Y72RbcURyHpFGO6i5ELKZLN9fiOpuOCAWcwOBqCHXhqiVox5iZ4sha0TIcsA/S/AnEJsObomkFLnNufeh4AJlDCWopV59tjlpw/b1JB1ijW3ovDLvI1U9SNPDKLt2r34u+v0cTSYlQ= Received: by 10.54.50.73 with SMTP id x73mr614057wrx; Tue, 10 May 2005 10:12:20 -0700 (PDT) Received: by 10.54.24.42 with HTTP; Tue, 10 May 2005 10:12:20 -0700 (PDT) Message-ID: <7bca1cb505051010123f0d0a26@mail.gmail.com> Date: Tue, 10 May 2005 12:12:20 -0500 From: Asim Shankar Reply-To: Asim Shankar To: cranium2003 Subject: Re: SNAT help Cc: net dev In-Reply-To: <20050509083113.42571.qmail@web41414.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050509083113.42571.qmail@web41414.mail.yahoo.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4AHCiOv002329 X-archive-position: 984 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 588 Lines: 17 > i have enabled SNAT and I have wrriten code > at NF_IP_POST_ROUTING but i want to get outgoing > packets' IP address as new one SNAT'ed IP address not > the one that is before SNAT? How can i do that? I think changing the priority (struct nf_hook_ops.priority) when registering the hook would do your job. ip_nat_out_ops registers a hook with a priority NF_IP_PRI_NAT_SRC. If you register your hook with a priority greater than NF_IP_PRI_NAT_SRC (like (NF_IP_PRI_NAT_SRC + 1) or NF_IP_PRI_LAST) then your hook will be called after the ip_nat_out_ops hook. Hope that helps, -- Asim From dmitry.torokhov@gmail.com Tue May 10 10:51:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 10:51:34 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AHpLOv004504 for ; Tue, 10 May 2005 10:51:22 -0700 Received: by rproxy.gmail.com with SMTP id r35so964810rna for ; Tue, 10 May 2005 10:50:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=txyRjWDfG9LtuXYp8/JYH6gaWx/O7qGX8rzpiwn7eqAi7DSAjlV5HSLDWXyegS3miIaAT0UvMg85v+bbKdMCWhdvMQXgVJrEKxgzE2UE08QXCAnAASOCaDsXXPJHtvVpoLpr+wpmFoG9F6iplArT76N5Qhs+j3rR6kG+qeIhN00= Received: by 10.38.12.30 with SMTP id 30mr2181085rnl; Tue, 10 May 2005 10:50:55 -0700 (PDT) Received: by 10.38.24.62 with HTTP; Tue, 10 May 2005 10:50:55 -0700 (PDT) Message-ID: Date: Tue, 10 May 2005 12:50:55 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: johnpol@2ka.mipt.ru Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan In-Reply-To: <20050510194128.075abb67@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050411125932.GA19538@uganda.factory.vocord.ru> <200505100118.48027.dtor_core@ameritech.net> <20050510140445.36cc15cb@zanzibar.2ka.mipt.ru> <20050510194128.075abb67@zanzibar.2ka.mipt.ru> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4AHpLOv004504 X-archive-position: 986 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry.torokhov@gmail.com Precedence: bulk X-list: netdev Content-Length: 5972 Lines: 143 On 5/10/05, Evgeniy Polyakov wrote: > On Tue, 10 May 2005 09:56:45 -0500 > Dmitry Torokhov wrote: > > > On 5/10/05, Evgeniy Polyakov wrote: > > > On Tue, 10 May 2005 01:18:46 -0500 > > > Dmitry Torokhov wrote: > > > > > > > - drop cn_dev - there is only one connector; > > > > > > There may be several connectors with different socket types. > > > I use it in my environment for tests. > > > > > > > Why do you need that? u32 ID space is not enough? > > They use different netlink sockets. > One of them can fail during initialisation, for example... Are you saying that there more chances successfully allocating 2 netlink sockets than one? > > > > > - simplify cn_notify_request to carry only one range - it simplifies code > > > > quite a bit - nothing stops clientd from sending several notification > > > > requests; > > > > > > ? Nothing stops clients from sending several notification requests now. > > > I do not see how it simplifies the things? > > > Feel free to set idx_num and val_num to 1 and you will have the same. > > > > Compare the implementaion - without variable-length notification > > requests the code is much simplier and flexible. > > Hmm, old request had a length, new one - does not. > But instead of atomically addition of the whole set, one need to send > couple of events. > I do not see any profit here. Smaller kernel code, simpler notification structure, ability to stop listenig to a certain events without re-registering the rest of the block. > > > > - admit that SKBs are message medium and do not mess up with passing around > > > > destructor functions. > > > > > > You mess up layers. > > > I do not see why you want it. > > > > What layers? Connector core is not an onion, with my patch it is 481 > > line .c file(down from 900+), comments probably take 1/3 of it. We > > just need to keep it simple, that's all. > > There is low-level medium layer - skbs. > There is middle-level layer - logical handling attached data and appropriate callback invocation. > There is high-level layer - various protocols over connector. > > Why any of them should know that others exist? > Your changes with destructor removing only saved < 10 lines of code, btw. Yes, line here and line there - all in all couple hundred lines. > > > Connector with your changes just does not work. > > > > As in "I tried to run it and adjusted the application for the new > > cn_notify_req size and it does not work" or "I am saying it does not > > work"? > > Second, i.e. "I am saing it does not work". > With your changes userspace just does not see any message being sent by kernelspace. Would you care to elaborate on this please. As far as I know kernel->userspace path was not changed at all. > > > > Dmitry, I do not understand why do you change things in so radical manner, > > > especially when there are no 1. new interesting features, 2. no performance > > > improvements, 3. no right design changes. > > > > There is a right design change - it keeps the code simple. It peels > > all the layers you invented for something that does not really need > > layers - connector is just a simple wrapper over raw netlink. > > That is your opinion. > > Code is already as simple as possible, since it is layered and each > piece of code is separated from different logical entities. > > > When I look at the code I see the mess of unneeded refcounting, wrong > > kinds of locking, over-engineering. Of course I want to change it. > > There are no unneded reference counting now. > Locking was not wrong - you only placed semaphore instead of notify BH lock > just to have ability to sleep under the lock and send callback addition/removing > notification with GFP_KERNEL mask, > and it is probably right change from the first view, as I said, > but it can be implemented in a different way. That's what I was referring to as "wring locking". Notifications do not need to stop bottom handlers, a spinlock or semaphore willl work just fine. SInce I wanted to allocate memory only after I determined that it is a new notify request a semaphore was a better choise. > > Keep it simple. Except for your testing environment why do you need to > > have separate netlink sockets? You have an ample ID space. Why do you > > need separate cn_dev and cn_queue_dev (and in the end have them at > > all)? Why do you need "input" handler, do you expect to use different > > handlers? If so which? And why? Do you expect to use other transports? > > If so which? And why? You need to have justifiction for every > > additional layer you putting on. > > Sigh. > It was already answered so many times, as far as I remember... > Ok, let's do it again. > > Several netlink sockets - if you can see, connector uses NETLINK_ULOG > for it's notification, you can not use the same socket twice, so you > may have new device with new socket, or several of them, and system > may work if one initialisation failed. Or it may not. Why do you think that having several sockets is safer than using one? After all, it is just a matter of setting it up and finally allocating a separate socket number for connector. > cn_dev is connector device structure, cn_queue_dev - it's queueing part. > input handler is needed for ability to receive messages. You chose not to understand my question. Why do you need to have is as a pointer? Do you expect to have different input handler? > Couple of next questions can be answered in one reply: > original connector's idea was to implement notification based > not on top of netlink protocol, but using ioctls of char device, > so there could be different connector device, input method, > transport and so on. Probably I will not implement it thought. IOW this all is remnants of an older design. You have no plans to utilize the framework and therefore it is not needed anymore and can be dropped. -- Dmitry From mchan@broadcom.com Tue May 10 10:51:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 10:51:25 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AHpIOv004498 for ; Tue, 10 May 2005 10:51:18 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 10 May 2005 10:50:54 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 10 May 2005 10:50:40 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AXN62376; Tue, 10 May 2005 10:50:38 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA12163; Tue, 10 May 2005 10:50:37 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 10 May 2005 17:50:37 +0000 Received: from rh4 by nt-irva-0741; 10 May 2005 09:52:46 -0700 Subject: Re: tg3 support broken on PPC, a workaround From: "Michael Chan" To: "Manuel Perez Ayala" cc: netdev@oss.sgi.com In-Reply-To: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> Date: Tue, 10 May 2005 09:52:46 -0700 Message-ID: <1115743966.8570.26.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E9E2BF421S3614560-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 985 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 765 Lines: 21 On Tue, 2005-05-10 at 11:33 +0200, Manuel Perez Ayala wrote: > > If I replace the 2.6.8 piece of code with the 2.6.7 one and compile the code, it > seems to work without problems of data corruption. > Can you print out the value of tp->dma_rwctrl in hex just before it is written to the register in the line: tw32(TG3PCI_DMA_RW_CTRL, tp->dma_rwctrl); Please do this for the working and non-working driver versions. I assume you have a 5700 or 5701 as this code that controls the DMA boundaries only affects those devices. Please confirm with the lspci output or tg3's probing output. In the new code, the DMA write bursts will disconnect at multiples of cache lines instead of 1 cache line. And DMA read bursts will not disconnect at cache line boundaries. From johnpol@2ka.mipt.ru Tue May 10 11:25:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 11:25:55 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AIPhOv006680 for ; Tue, 10 May 2005 11:25:44 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with ESMTP id j4AIOVmm023848; Tue, 10 May 2005 22:24:31 +0400 Date: Tue, 10 May 2005 22:24:24 +0400 From: Evgeniy Polyakov To: dtor_core@ameritech.net Cc: dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050510222424.5b411c89@zanzibar.2ka.mipt.ru> In-Reply-To: References: <20050411125932.GA19538@uganda.factory.vocord.ru> <200505100118.48027.dtor_core@ameritech.net> <20050510140445.36cc15cb@zanzibar.2ka.mipt.ru> <20050510194128.075abb67@zanzibar.2ka.mipt.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Tue, 10 May 2005 22:24:32 +0400 (MSD) X-archive-position: 987 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 9209 Lines: 210 On Tue, 10 May 2005 12:50:55 -0500 Dmitry Torokhov wrote: > On 5/10/05, Evgeniy Polyakov wrote: > > On Tue, 10 May 2005 09:56:45 -0500 > > Dmitry Torokhov wrote: > > > > > On 5/10/05, Evgeniy Polyakov wrote: > > > > On Tue, 10 May 2005 01:18:46 -0500 > > > > Dmitry Torokhov wrote: > > > > > > > > > - drop cn_dev - there is only one connector; > > > > > > > > There may be several connectors with different socket types. > > > > I use it in my environment for tests. > > > > > > > > > > Why do you need that? u32 ID space is not enough? > > > > They use different netlink sockets. > > One of them can fail during initialisation, for example... > > Are you saying that there more chances successfully allocating 2 > netlink sockets than one? Of course - one may be in use by ipt_ULOG for example. Although probably it could be better to get new unit from David Miller. I want to create some kind of unused-in-kernel socket number - each netlink user outside kernel might use it without kernel users bothering. > > > > > > > - simplify cn_notify_request to carry only one range - it simplifies code > > > > > quite a bit - nothing stops clientd from sending several notification > > > > > requests; > > > > > > > > ? Nothing stops clients from sending several notification requests now. > > > > I do not see how it simplifies the things? > > > > Feel free to set idx_num and val_num to 1 and you will have the same. > > > > > > Compare the implementaion - without variable-length notification > > > requests the code is much simplier and flexible. > > > > Hmm, old request had a length, new one - does not. > > But instead of atomically addition of the whole set, one need to send > > couple of events. > > I do not see any profit here. > > Smaller kernel code, simpler notification structure, ability to stop > listenig to a certain events without re-registering the rest of the > block. As I said - set idx and val numbers to one and you will have the same behaviour. Code is neither smaller [ok, you removed a loop] nor simplier - it is functionality decreasing. > > > > > - admit that SKBs are message medium and do not mess up with passing around > > > > > destructor functions. > > > > > > > > You mess up layers. > > > > I do not see why you want it. > > > > > > What layers? Connector core is not an onion, with my patch it is 481 > > > line .c file(down from 900+), comments probably take 1/3 of it. We > > > just need to keep it simple, that's all. > > > > There is low-level medium layer - skbs. > > There is middle-level layer - logical handling attached data and appropriate callback invocation. > > There is high-level layer - various protocols over connector. > > > > Why any of them should know that others exist? > > Your changes with destructor removing only saved < 10 lines of code, btw. > > Yes, line here and line there - all in all couple hundred lines. It is not unused bits - it is framework which allows easy functionality extending. > > > > Connector with your changes just does not work. > > > > > > As in "I tried to run it and adjusted the application for the new > > > cn_notify_req size and it does not work" or "I am saying it does not > > > work"? > > > > Second, i.e. "I am saing it does not work". > > With your changes userspace just does not see any message being sent by kernelspace. > > Would you care to elaborate on this please. As far as I know > kernel->userspace path was not changed at all. I inserted your module and test module, which sends a message using cn_netlink_send() one time per second. Usersace application bound to -1 group does not receive that messages. If I remove test module and your module, then insert vanilla connector module and test module, then userspace application begins to receive messages. Here is part of dmesg: cn_test_callback: 403117737: idx=123, val=457, seq=9, ack=0, len=12: counter = 9. cn_test_callback: 403118737: idx=123, val=457, seq=10, ack=0, len=13: counter = 10. cn_test_callback: 403119737: idx=123, val=457, seq=11, ack=0, len=13: counter = 11. cn_test_callback: 403120737: idx=123, val=457, seq=12, ack=0, len=13: counter = 12. connector: cn_cb_equal: comparing ffffffff.ffffffff and 0123.0456 connector: cn_cb_equal: comparing ffffffff.ffffffff and 0123.0457 connector: cn_cb_equal: comparing 0123.0456 and 0123.0457 connector: cn_cb_equal: comparing ffffffff.ffffffff and 0123.0457 connector: cn_cb_equal: comparing 0123.0456 and 0123.0457 connector: cn_cb_equal: comparing 0123.0457 and 0123.0457 connector: cn_netlink_send: len=12, seq=0, ack=0, group=0. I can not say where the problem is and completely misunderstand how test callback can be called several times... Something is broken. > > > > > > Dmitry, I do not understand why do you change things in so radical manner, > > > > especially when there are no 1. new interesting features, 2. no performance > > > > improvements, 3. no right design changes. > > > > > > There is a right design change - it keeps the code simple. It peels > > > all the layers you invented for something that does not really need > > > layers - connector is just a simple wrapper over raw netlink. > > > > That is your opinion. > > > > Code is already as simple as possible, since it is layered and each > > piece of code is separated from different logical entities. > > > > > When I look at the code I see the mess of unneeded refcounting, wrong > > > kinds of locking, over-engineering. Of course I want to change it. > > > > There are no unneded reference counting now. > > Locking was not wrong - you only placed semaphore instead of notify BH lock > > just to have ability to sleep under the lock and send callback addition/removing > > notification with GFP_KERNEL mask, > > and it is probably right change from the first view, as I said, > > but it can be implemented in a different way. > > That's what I was referring to as "wring locking". Notifications do > not need to stop bottom handlers, a spinlock or semaphore willl work > just fine. SInce I wanted to allocate memory only after I determined > that it is a new notify request a semaphore was a better choise. I will think of it, but in long-time I do not like such approach - it is some kind of deadlock - we have no memory, so we sleep in allocation, so we can not remove callback since it will sleep in allocation... > > > Keep it simple. Except for your testing environment why do you need to > > > have separate netlink sockets? You have an ample ID space. Why do you > > > need separate cn_dev and cn_queue_dev (and in the end have them at > > > all)? Why do you need "input" handler, do you expect to use different > > > handlers? If so which? And why? Do you expect to use other transports? > > > If so which? And why? You need to have justifiction for every > > > additional layer you putting on. > > > > Sigh. > > It was already answered so many times, as far as I remember... > > Ok, let's do it again. > > > > Several netlink sockets - if you can see, connector uses NETLINK_ULOG > > for it's notification, you can not use the same socket twice, so you > > may have new device with new socket, or several of them, and system > > may work if one initialisation failed. > > Or it may not. Why do you think that having several sockets is safer > than using one? After all, it is just a matter of setting it up and > finally allocating a separate socket number for connector. Yes, there can be such a way. But when connector was not in mainline it used TUN/TAP netlink sockets and tried to get one by one, until successfully allocated. Using dmesg userspace could find needed socket number for itself. > > cn_dev is connector device structure, cn_queue_dev - it's queueing part. > > input handler is needed for ability to receive messages. > > You chose not to understand my question. Why do you need to have is as > a pointer? Do you expect to have different input handler? In runtime - no. cn_dev is a main transport structure, while cn_queue_dev is for callback queue handling. > > Couple of next questions can be answered in one reply: > > original connector's idea was to implement notification based > > not on top of netlink protocol, but using ioctls of char device, > > so there could be different connector device, input method, > > transport and so on. Probably I will not implement it thought. > > IOW this all is remnants of an older design. You have no plans to > utilize the framework and therefore it is not needed anymore and can > be dropped. Different connector devices still there. They use different sockets. Concider netlink2 [with guaranteed delivering - I have some ideas about it] - one just needs to add a new connector device, no new braindumping and recalling how it was cool before. It will require some changes to the connector structure, but it will not be complete rewrite because some time ago someone decided we do not need it and completely removed anything that lives outside simple netlink wrapper. > -- > Dmitry Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From rick.jones2@hp.com Tue May 10 11:41:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 11:41:56 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AIfqOv007628 for ; Tue, 10 May 2005 11:41:52 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id 12153509C; Tue, 10 May 2005 11:41:28 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id LAA02195; Tue, 10 May 2005 11:41:27 -0700 (PDT) Message-ID: <42810057.4020800@hp.com> Date: Tue, 10 May 2005 11:41:27 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Iatrou Cc: netdev@oss.sgi.com Subject: Re: IPsec performance over UDP References: <200505101949.12236.m.iatrou@freemail.gr> In-Reply-To: <200505101949.12236.m.iatrou@freemail.gr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 662 Lines: 22 Michael Iatrou wrote: > Hi, > > I did some testing for IPsec performance over UDP. I used two identical PCs, > connected back-to-back, with Intel Xeon 2.8GHz (SMP/SMT disabled), 512MB RAM, > e1000 (82546EB), running Linux 2.6.11.7. > > I tested AES {128,192,256}, DES, 3DES, SHA, MD5 and various combinations of > them for ESP and AH. > > Network performance: > http://members.hellug.gr/iatrou/udp-throughput.png > > CPU utilization: > http://members.hellug.gr/iatrou/udp-cpu.png > > The "unexpected" result is that there is 30% idle time even if the network is > not saturated! Perhaps the sending side got intra-stack flow-controlled? rick jones From davem@davemloft.net Tue May 10 12:14:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 12:14:44 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AJEVOv009292 for ; Tue, 10 May 2005 12:14:34 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVa9T-0001ta-Ex; Tue, 10 May 2005 12:12:19 -0700 Date: Tue, 10 May 2005 12:12:14 -0700 (PDT) Message-Id: <20050510.121214.39158393.davem@davemloft.net> To: mchan@broadcom.com Cc: mperaya@alcazaba.unex.es, netdev@oss.sgi.com Subject: Re: tg3 support broken on PPC, a workaround From: "David S. Miller" In-Reply-To: <1115743966.8570.26.camel@rh4> References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 989 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1030 Lines: 25 From: "Michael Chan" Subject: Re: tg3 support broken on PPC, a workaround Date: Tue, 10 May 2005 09:52:46 -0700 > In the new code, the DMA write bursts will disconnect at multiples of > cache lines instead of 1 cache line. And DMA read bursts will not > disconnect at cache line boundaries. We really should be disconnecting at single cacheline boundaries on RISC systems. The PCI controllers on RISC machines are going to disconnect the tg3 when it crosses a cache line boundary, so all these setting do is waste PCI bandwidth. From the sparc64 PCI controller programmer's manual: "When a DMA burst transfer attempts to go past a cache line (64B) boundary, U2P generates a disconnect. This should cause the master device to attempt the transaction again beginning at the address of the next untransferred data." Most other RISC systems have PCI controllers which behave similarly if not identically, although there are probably some exceptions. Anyways, it is clear this code needs to change. :-) From davem@davemloft.net Tue May 10 13:34:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 13:34:14 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AKYBOv016287 for ; Tue, 10 May 2005 13:34:11 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVbPX-0002N0-DN; Tue, 10 May 2005 13:32:59 -0700 Date: Tue, 10 May 2005 13:32:58 -0700 (PDT) Message-Id: <20050510.133258.08322422.davem@davemloft.net> To: mchan@broadcom.com Cc: mperaya@alcazaba.unex.es, netdev@oss.sgi.com Subject: Re: tg3 support broken on PPC, a workaround From: "David S. Miller" In-Reply-To: <20050510.132642.85686818.davem@davemloft.net> References: <1115743966.8570.26.camel@rh4> <20050510.121214.39158393.davem@davemloft.net> <20050510.132642.85686818.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 374 Lines: 13 From: "David S. Miller" Subject: Re: tg3 support broken on PPC, a workaround Date: Tue, 10 May 2005 13:26:42 -0700 (PDT) > + case 1024: > + default: > + tp->dma_rwctrl |= > + (DMA_RWCTRL_READ_BNDRY_512 | > + DMA_RWCTRL_WRITE_BNDRY_512); > + break; This should use the _1024 bit values, of course. I've fixed that in my local copy. From davem@davemloft.net Tue May 10 13:28:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 13:28:03 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AKRxOv015611 for ; Tue, 10 May 2005 13:28:00 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVbJX-0002LG-Pd; Tue, 10 May 2005 13:26:47 -0700 Date: Tue, 10 May 2005 13:26:42 -0700 (PDT) Message-Id: <20050510.132642.85686818.davem@davemloft.net> To: mchan@broadcom.com Cc: mperaya@alcazaba.unex.es, netdev@oss.sgi.com Subject: Re: tg3 support broken on PPC, a workaround From: "David S. Miller" In-Reply-To: <20050510.121214.39158393.davem@davemloft.net> References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> <20050510.121214.39158393.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 990 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 4143 Lines: 152 From: "David S. Miller" Subject: Re: tg3 support broken on PPC, a workaround Date: Tue, 10 May 2005 12:12:14 -0700 (PDT) > Anyways, it is clear this code needs to change. :-) I propose something like the patch below. I unfortunately discovered that the PCI-X boundary controls are limited, and even worse PCI-E only allows controlling the write side and not the read site at all. :-( I think this should really be considered to be fixed in future chip revisions, as performance will suffer unnecessarily without proper boundary controls. Even just a single bit in the DMA RW control register which says "do not cross PCI_CACHELINE_SIZE boundary" would work just fine as that is essentially what the code below is trying to convince the Tigon3 chip to do. :) I am running this patch now on my sparc64 SunBlade1500 workstation's onboard 5703. Comments? [TG3]: Do not burst across cache line boundary on non-X86 PCI controllers on these systems will disconnect the tg3 when it crosses a cache line boundary anyways, wasting precious PCI bandwidth. Signed-off-by: David S. Miller --- drivers/net/tg3.c.~3~ 2005-05-09 15:52:32.000000000 -0700 +++ drivers/net/tg3.c 2005-05-10 13:16:51.000000000 -0700 @@ -8865,33 +8865,93 @@ else cacheline_size = (int) byte * 4; - switch (cacheline_size) { - case 16: - case 32: - case 64: - case 128: - if ((tp->tg3_flags & TG3_FLAG_PCIX_MODE) && - !(tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS)) { - tp->dma_rwctrl |= - DMA_RWCTRL_WRITE_BNDRY_384_PCIX; - break; - } else if (tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS) { - tp->dma_rwctrl &= - ~(DMA_RWCTRL_PCI_WRITE_CMD); + /* PCI controllers on most RISC systems tend to disconnect + * when a device tries to burst across a cache-line boundary. + * Therefore, letting tg3 do so just wastes PCI bandwidth. + * + * Unfortunately, for PCI-E there are only limited + * write-side controls for this, and thus for reads + * we will still get the disconnects. + */ + if ((tp->tg3_flags & TG3_FLAG_PCIX_MODE) && + !(tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS)) { + switch (cacheline_size) { + case 16: + case 32: + case 64: + case 128: tp->dma_rwctrl |= - DMA_RWCTRL_WRITE_BNDRY_128_PCIE; + (DMA_RWCTRL_READ_BNDRY_128_PCIX | + DMA_RWCTRL_WRITE_BNDRY_128_PCIX); break; - } - /* fallthrough */ - case 256: - if (!(tp->tg3_flags & TG3_FLAG_PCIX_MODE) && - !(tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS)) + + case 256: + tp->dma_rwctrl |= + (DMA_RWCTRL_READ_BNDRY_256_PCIX | + DMA_RWCTRL_WRITE_BNDRY_256_PCIX); + break; + + default: + tp->dma_rwctrl |= + (DMA_RWCTRL_READ_BNDRY_384_PCIX | + DMA_RWCTRL_WRITE_BNDRY_384_PCIX); + break; + }; + } else if (tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS) { + switch (cacheline_size) { + case 16: + case 32: + case 64: + tp->dma_rwctrl |= + DMA_RWCTRL_WRITE_BNDRY_64_PCIE; + break; + + case 128: + default: + tp->dma_rwctrl |= + DMA_RWCTRL_WRITE_BNDRY_128_PCIE; + break; + }; + } else { + switch (cacheline_size) { + case 16: + tp->dma_rwctrl |= + (DMA_RWCTRL_READ_BNDRY_16 | + DMA_RWCTRL_WRITE_BNDRY_16); + break; + case 32: + tp->dma_rwctrl |= + (DMA_RWCTRL_READ_BNDRY_32 | + DMA_RWCTRL_WRITE_BNDRY_32); + break; + case 64: + tp->dma_rwctrl |= + (DMA_RWCTRL_READ_BNDRY_64 | + DMA_RWCTRL_WRITE_BNDRY_64); + break; + case 128: tp->dma_rwctrl |= - DMA_RWCTRL_WRITE_BNDRY_256; - else if (!(tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS)) + (DMA_RWCTRL_READ_BNDRY_128 | + DMA_RWCTRL_WRITE_BNDRY_128); + break; + case 256: + tp->dma_rwctrl |= + (DMA_RWCTRL_READ_BNDRY_256 | + DMA_RWCTRL_WRITE_BNDRY_256); + break; + case 512: tp->dma_rwctrl |= - DMA_RWCTRL_WRITE_BNDRY_256_PCIX; - }; + (DMA_RWCTRL_READ_BNDRY_512 | + DMA_RWCTRL_WRITE_BNDRY_512); + break; + case 1024: + default: + tp->dma_rwctrl |= + (DMA_RWCTRL_READ_BNDRY_512 | + DMA_RWCTRL_WRITE_BNDRY_512); + break; + }; + } } #endif From m.iatrou@freemail.gr Tue May 10 13:35:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 13:35:48 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4AKZhOv016794 for ; Tue, 10 May 2005 13:35:44 -0700 Received: (qmail 26250 invoked by uid 111); 10 May 2005 20:35:15 -0000 Received: from 150.140.129.29 by nic.upatras.gr (envelope-from , uid 103) with qmail-scanner-1.25 (clamdscan: 0.83/706. Clear:RC:1(150.140.129.29):. Processed in 0.083368 secs); 10 May 2005 20:35:15 -0000 Received: from patreas.upatras.gr (150.140.129.29) by nic.upatras.gr with SMTP; 10 May 2005 20:35:14 -0000 Received: (qmail 22071 invoked from network); 10 May 2005 20:35:14 -0000 Received: from upnet-dialinpool-22.upnet.gr ([150.140.128.232]) (envelope-sender ) by patreas.upatras.gr (qmail-ldap-1.03) with SMTP for ; 10 May 2005 20:35:14 -0000 From: Michael Iatrou To: Rick Jones Subject: Re: IPsec performance over UDP Date: Tue, 10 May 2005 23:35:19 +0300 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <200505101949.12236.m.iatrou@freemail.gr> <42810057.4020800@hp.com> In-Reply-To: <42810057.4020800@hp.com> X-Face: *8Gl!va:8&HzlgC%IRQaxD*[{;>3OMj];U1I;[rtNn@,hA7h/cTR1!!0J`koxA2)=?utf-8?q?xj=7ELd9=0A=09N4LpVN=24=5CaU=27r?=2l}1-ae/$k1heNY.:5"9IYPy>X$msqG MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505102335.20023.m.iatrou@freemail.gr> X-archive-position: 992 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: m.iatrou@freemail.gr Precedence: bulk X-list: netdev Content-Length: 394 Lines: 13 When the date was Tuesday 10 May 2005 21:41, Rick Jones wrote: > > The "unexpected" result is that there is 30% idle time even if the > > network is not saturated! > > Perhaps the sending side got intra-stack flow-controlled? In that case, plain IP should't also have the same problem (it hasn't)? -- Michael Iatrou Electrical and Computer Engineering Dept. University of Patras, Greece From mchan@broadcom.com Tue May 10 13:42:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 13:42:10 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AKg5Ov017454 for ; Tue, 10 May 2005 13:42:06 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 10 May 2005 13:42:01 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 10 May 2005 13:41:23 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AXO12640; Tue, 10 May 2005 13:41:22 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA01705; Tue, 10 May 2005 13:41:22 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 10 May 2005 20:41:18 +0000 Received: from rh4 by nt-irva-0741; 10 May 2005 12:43:30 -0700 Subject: Re: tg3 support broken on PPC, a workaround From: "Michael Chan" To: "David S.Miller" cc: mperaya@alcazaba.unex.es, netdev@oss.sgi.com In-Reply-To: <20050510.121214.39158393.davem@davemloft.net> References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> <20050510.121214.39158393.davem@davemloft.net> Date: Tue, 10 May 2005 12:43:30 -0700 Message-ID: <1115754210.8570.63.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E9FC3131MW3735230-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 993 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1596 Lines: 39 On Tue, 2005-05-10 at 12:12 -0700, David S.Miller wrote: > From: "Michael Chan" > Subject: Re: tg3 support broken on PPC, a workaround > Date: Tue, 10 May 2005 09:52:46 -0700 > > > In the new code, the DMA write bursts will disconnect at multiples of > > cache lines instead of 1 cache line. And DMA read bursts will not > > disconnect at cache line boundaries. > > We really should be disconnecting at single cacheline boundaries > on RISC systems. The PCI controllers on RISC machines are > going to disconnect the tg3 when it crosses a cache line > boundary, so all these setting do is waste PCI bandwidth. > > From the sparc64 PCI controller programmer's manual: > > "When a DMA burst transfer attempts to go past a cache line (64B) > boundary, U2P generates a disconnect. This should cause the > master device to attempt the transaction again beginning at the > address of the next untransferred data." > This should be fine. If the bridge requires termination at every cache line, the bridge (target) will initiate disconnect and data will terminate. There is clear benefit in doing longer bursts when the bridge can handle it. It was explained to me that on some risc systems such as ppc, and assuming the bridge can handle long DMA bursts, it is still best to disconnect at page or cache line boundaries. The reason is that if the burst stops at any arbitrary address, the bridge has to refetch the cache line and often the mapping information. Disconnecting at multiple cache lines is to address this problem while still achieving longer DMA bursts. From mchan@broadcom.com Tue May 10 14:12:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 14:12:58 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ALCrOv019033 for ; Tue, 10 May 2005 14:12:54 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 10 May 2005 14:12:24 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 10 May 2005 14:12:21 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AXO21584; Tue, 10 May 2005 14:12:21 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA12259; Tue, 10 May 2005 14:12:21 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 10 May 2005 21:12:20 +0000 Received: from rh4 by nt-irva-0741; 10 May 2005 13:14:30 -0700 Subject: Re: tg3 support broken on PPC, a workaround From: "Michael Chan" To: "David S.Miller" cc: mperaya@alcazaba.unex.es, netdev@oss.sgi.com In-Reply-To: <20050510.132642.85686818.davem@davemloft.net> References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> <20050510.121214.39158393.davem@davemloft.net> <20050510.132642.85686818.davem@davemloft.net> Date: Tue, 10 May 2005 13:14:30 -0700 Message-ID: <1115756070.8570.76.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E9FFC3221S3659910-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 994 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1640 Lines: 45 On Tue, 2005-05-10 at 13:26 -0700, David S.Miller wrote: > From: "David S. Miller" > Subject: Re: tg3 support broken on PPC, a workaround > Date: Tue, 10 May 2005 12:12:14 -0700 (PDT) > > > Anyways, it is clear this code needs to change. :-) > > I propose something like the patch below. I unfortunately > discovered that the PCI-X boundary controls are limited, and > even worse PCI-E only allows controlling the write side and > not the read site at all. :-( > > I think this should really be considered to be fixed > in future chip revisions, as performance will suffer > unnecessarily without proper boundary controls. Even > just a single bit in the DMA RW control register which > says "do not cross PCI_CACHELINE_SIZE boundary" would > work just fine as that is essentially what the code below > is trying to convince the Tigon3 chip to do. :) > > I am running this patch now on my sparc64 SunBlade1500 > workstation's onboard 5703. > > Comments? DMA boundary control bits are only valid on 5700 and 5701. On all other PCI/PCIX chips, these bits are no longer defined. On PCI Express systems, the cache line size register is not used and is set to zero on most systems. > > [TG3]: Do not burst across cache line boundary on non-X86 > > PCI controllers on these systems will disconnect the tg3 > when it crosses a cache line boundary anyways, wasting > precious PCI bandwidth. I don't think target-initiated disconnects will waste PCI bandwidth compared to master-initiated terminations. In both cases, you see the same DMA bursts across the bus, only the termination of each burst is different. From davem@davemloft.net Tue May 10 14:16:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 14:16:49 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ALGfOv020054 for ; Tue, 10 May 2005 14:16:44 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVc4j-0002SU-2G; Tue, 10 May 2005 14:15:33 -0700 Date: Tue, 10 May 2005 14:15:25 -0700 (PDT) Message-Id: <20050510.141525.23014027.davem@davemloft.net> To: mchan@broadcom.com Cc: mperaya@alcazaba.unex.es, netdev@oss.sgi.com Subject: Re: tg3 support broken on PPC, a workaround From: "David S. Miller" In-Reply-To: <1115754210.8570.63.camel@rh4> References: <1115743966.8570.26.camel@rh4> <20050510.121214.39158393.davem@davemloft.net> <1115754210.8570.63.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 995 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1236 Lines: 34 From: "Michael Chan" Subject: Re: tg3 support broken on PPC, a workaround Date: Tue, 10 May 2005 12:43:30 -0700 > There is clear benefit in doing longer bursts when the bridge can handle > it. No question. > It was explained to me that on some risc systems such as ppc, and > assuming the bridge can handle long DMA bursts, it is still best to > disconnect at page or cache line boundaries. The reason is that if the > burst stops at any arbitrary address, the bridge has to refetch the > cache line and often the mapping information. Disconnecting at multiple > cache lines is to address this problem while still achieving longer DMA > bursts. Ok, I see. It is aparently causing some kind of trouble for this person on his PPC system though. I think we should back down to single-cacheline on non-X86 until we really can get a grasp on what machines it is both: 1) beneficial 2) does not corrupt data And that is what my patch aims to do for the time being. Even once the problem case is resolved, that setting should be bracketed in some test that specifically only enables the longer bursting where it actually helps not hinders. It definitely should not be done unconditonally for all non-X86 systems. From mchan@broadcom.com Tue May 10 14:48:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 14:48:16 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ALmAOv022773 for ; Tue, 10 May 2005 14:48:10 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 10 May 2005 14:48:13 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 10 May 2005 14:47:36 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AXO31224; Tue, 10 May 2005 14:47:30 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA23927; Tue, 10 May 2005 14:47:30 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 10 May 2005 21:47:30 +0000 Received: from rh4 by nt-irva-0741; 10 May 2005 13:49:39 -0700 Subject: Re: tg3 support broken on PPC, a workaround From: "Michael Chan" To: "David S.Miller" cc: mperaya@alcazaba.unex.es, netdev@oss.sgi.com In-Reply-To: <20050510.142319.70222971.davem@davemloft.net> References: <20050510.121214.39158393.davem@davemloft.net> <20050510.132642.85686818.davem@davemloft.net> <1115756070.8570.76.camel@rh4> <20050510.142319.70222971.davem@davemloft.net> Date: Tue, 10 May 2005 13:49:39 -0700 Message-ID: <1115758179.8570.79.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E9FF3971MW3749858-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 996 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1174 Lines: 28 On Tue, 2005-05-10 at 14:23 -0700, David S.Miller wrote: > From: "Michael Chan" > Subject: Re: tg3 support broken on PPC, a workaround > Date: Tue, 10 May 2005 13:14:30 -0700 > > > I don't think target-initiated disconnects will waste PCI bandwidth > > compared to master-initiated terminations. In both cases, you see the > > same DMA bursts across the bus, only the termination of each burst is > > different. > > I think it does Michael. Performance on sparc64 went non-trivially up > when I added the read/write boundary settings initially long ago. > > You have the extra phase where the tg3 tries to start the DMA of the > next cacheline, and that is where unnecessary time is lost. I think > it's about 2 clocks you lose if the PCI controller disconnects instead > of tg3. > > Tigon3 will drive the data of the next cacheline for 1 cycle and this > is when the PCI controller will disconnect. Tigon3 will drop the data > and respond to the disconnect sometime in the next cycle or so. > You're right. This is Disconnect Without Data and it does cost a few clock cycles compared to Disconnect With Data or master initiated termination. From davem@davemloft.net Tue May 10 14:54:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 14:54:21 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ALsIOv023566 for ; Tue, 10 May 2005 14:54:18 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVcCL-0002TD-N0; Tue, 10 May 2005 14:23:25 -0700 Date: Tue, 10 May 2005 14:23:19 -0700 (PDT) Message-Id: <20050510.142319.70222971.davem@davemloft.net> To: mchan@broadcom.com Cc: mperaya@alcazaba.unex.es, netdev@oss.sgi.com Subject: Re: tg3 support broken on PPC, a workaround From: "David S. Miller" In-Reply-To: <1115756070.8570.76.camel@rh4> References: <20050510.121214.39158393.davem@davemloft.net> <20050510.132642.85686818.davem@davemloft.net> <1115756070.8570.76.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 997 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1096 Lines: 25 From: "Michael Chan" Subject: Re: tg3 support broken on PPC, a workaround Date: Tue, 10 May 2005 13:14:30 -0700 > I don't think target-initiated disconnects will waste PCI bandwidth > compared to master-initiated terminations. In both cases, you see the > same DMA bursts across the bus, only the termination of each burst is > different. I think it does Michael. Performance on sparc64 went non-trivially up when I added the read/write boundary settings initially long ago. You have the extra phase where the tg3 tries to start the DMA of the next cacheline, and that is where unnecessary time is lost. I think it's about 2 clocks you lose if the PCI controller disconnects instead of tg3. Tigon3 will drive the data of the next cacheline for 1 cycle and this is when the PCI controller will disconnect. Tigon3 will drop the data and respond to the disconnect sometime in the next cycle or so. All of this activity will not occur if Tigon3 just ends the data phase itself when the cacheline boundary is hit. Or are you talking about PCI reads as opposed to writes? From herbert@gondor.apana.org.au Tue May 10 15:08:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 15:08:29 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AM8OOv024539 for ; Tue, 10 May 2005 15:08:25 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DVctQ-0000hf-00; Wed, 11 May 2005 08:07:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DVctL-00007i-00; Wed, 11 May 2005 08:07:51 +1000 Date: Wed, 11 May 2005 08:07:51 +1000 To: Ken-ichirou MATSUZAWA Cc: netdev@oss.sgi.com Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Message-ID: <20050510220751.GA459@gondor.apana.org.au> References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 998 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 739 Lines: 20 On Tue, May 10, 2005 at 12:43:32PM +0000, Ken-ichirou MATSUZAWA wrote: > > Everytime on shutting down, the subject message is logged. > It seems that the reason is do_one_broadcast may preempt > netlink_recvmsg. Added patch to 2.6.12-rc4 seems resolving this > problem. Thanks for the patch. To help me understand the problem better, could you please tell me: 1) Is this reproducible under 2.6.12-rc4 without your patch? 2) What application is holding the netlink socket? 3) Is your machine SMP, PREEMPT, or both? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From rick.jones2@hp.com Tue May 10 15:13:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 15:13:53 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4AMDoOv025223 for ; Tue, 10 May 2005 15:13:51 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id AC0DFE8C for ; Tue, 10 May 2005 15:13:26 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA03324; Tue, 10 May 2005 15:13:25 -0700 (PDT) Message-ID: <42813205.1040709@hp.com> Date: Tue, 10 May 2005 15:13:25 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: Grant Grundler Subject: Re: tg3 support broken on PPC, a workaround References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> <20050510.121214.39158393.davem@davemloft.net> In-Reply-To: <20050510.121214.39158393.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 999 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 470 Lines: 11 David S. Miller wrote: > We really should be disconnecting at single cacheline boundaries > on RISC systems. The PCI controllers on RISC machines are > going to disconnect the tg3 when it crosses a cache line > boundary, so all these setting do is waste PCI bandwidth. It is my understanding that PA-RISC and IA64 controllers behave differently. For confirmation one way or the other, I've cc'd someone who could talk about it much more cogently than I. rick jones From grundler@cup.hp.com Tue May 10 16:20:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 16:20:05 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ANJoOv031205 for ; Tue, 10 May 2005 16:20:02 -0700 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel12.hp.com (Postfix) with ESMTP id C82044005DF for ; Tue, 10 May 2005 16:19:25 -0700 (PDT) Received: from localhost.localdomain (debian.cup.hp.com [15.244.57.47]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id QAA24492; Tue, 10 May 2005 16:14:03 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 1000) id C5BFC8FC56; Tue, 10 May 2005 16:21:32 -0700 (PDT) Date: Tue, 10 May 2005 16:21:32 -0700 From: Grant Grundler To: Rick Jones Cc: netdev@oss.sgi.com, Grant Grundler Subject: Re: tg3 support broken on PPC, a workaround Message-ID: <20050510232132.GZ5495@esmail.cup.hp.com> References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> <20050510.121214.39158393.davem@davemloft.net> <42813205.1040709@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42813205.1040709@hp.com> User-Agent: Mutt/1.5.9i X-archive-position: 1000 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: iod00d@hp.com Precedence: bulk X-list: netdev Content-Length: 906 Lines: 26 On Tue, May 10, 2005 at 03:13:25PM -0700, Rick Jones wrote: > David S. Miller wrote: > >We really should be disconnecting at single cacheline boundaries > >on RISC systems. The PCI controllers on RISC machines are > >going to disconnect the tg3 when it crosses a cache line > >boundary, so all these setting do is waste PCI bandwidth. > > It is my understanding that PA-RISC and IA64 controllers behave > differently. For confirmation one way or the other, I've cc'd someone who > could talk about it much more cogently than I. Yup, thanks rick. Dave, HP PCI bus controllers don't disconnect after a cacheline. The latest "LBA" (aka Mercury) will disconnect on 4k page boundaries. Alex Williamson confirmed. Has anyone confirmed PPC, PPC64 and Alpha PCI/PCI-X bus controllers do the same? ISTR MMRBC (PCI-X only) allows one to specify shorter blocks. I'd have to look that up again. thanks, grant From davem@davemloft.net Tue May 10 16:37:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 16:37:31 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ANbROv032108 for ; Tue, 10 May 2005 16:37:28 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVeHS-0002jQ-7R; Tue, 10 May 2005 16:36:50 -0700 Date: Tue, 10 May 2005 16:36:50 -0700 (PDT) Message-Id: <20050510.163650.66182323.davem@davemloft.net> To: iod00d@hp.com Cc: rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: tg3 support broken on PPC, a workaround From: "David S. Miller" In-Reply-To: <20050510232132.GZ5495@esmail.cup.hp.com> References: <20050510.121214.39158393.davem@davemloft.net> <42813205.1040709@hp.com> <20050510232132.GZ5495@esmail.cup.hp.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1001 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1164 Lines: 33 From: Grant Grundler Subject: Re: tg3 support broken on PPC, a workaround Date: Tue, 10 May 2005 16:21:32 -0700 > HP PCI bus controllers don't disconnect after a cacheline. > The latest "LBA" (aka Mercury) will disconnect on 4k page > boundaries. Alex Williamson confirmed. Ok, good data point. > Has anyone confirmed PPC, PPC64 and Alpha PCI/PCI-X bus > controllers do the same? > > ISTR MMRBC (PCI-X only) allows one to specify > shorter blocks. I'd have to look that up again. BTW, I just noticed this in the NetBSD tigon3 driver: #ifdef __brokenalpha__ /* * Must insure that we do not cross an 8K (bytes) boundary * for DMA reads. Our highest limit is 1K bytes. This is a * restriction on some ALPHA platforms with early revision * 21174 PCI chipsets, such as the AlphaPC 164lx */ PCI_SETBIT(sc, BGE_PCI_DMA_RW_CTL, BGE_PCI_READ_BNDRY_1024, 4); #endif This whole DMA boundary issue is turning into a very non-trivial one. And if it is really true that plain PCI boundary crossing cannot be controlled on non 5700/5701 chips, the tigon3 is certainly not going to work reliably on systems such as the Alpha mentioned above. From herbert@gondor.apana.org.au Tue May 10 17:59:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 17:59:18 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4B0xAOv002597 for ; Tue, 10 May 2005 17:59:11 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DVfYd-0001yZ-00; Wed, 11 May 2005 10:58:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DVfYa-0000Ri-00; Wed, 11 May 2005 10:58:36 +1000 Date: Wed, 11 May 2005 10:58:36 +1000 To: Ken-ichirou MATSUZAWA Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Message-ID: <20050511005836.GA1674@gondor.apana.org.au> References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> <20050510220751.GA459@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <20050510220751.GA459@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1002 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2127 Lines: 71 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 11, 2005 at 08:07:51AM +1000, herbert wrote: > On Tue, May 10, 2005 at 12:43:32PM +0000, Ken-ichirou MATSUZAWA wrote: > > > > Everytime on shutting down, the subject message is logged. > > It seems that the reason is do_one_broadcast may preempt > > netlink_recvmsg. Added patch to 2.6.12-rc4 seems resolving this > > problem. > > Thanks for the patch. To help me understand the problem better, > could you please tell me: I think I understand your patch now. What's happening is that 1) The skb is sent to socket 1. 2) Someone does a recvmsg on socket 1 and drops the ref on the skb. Note that the rmalloc is not returned at this point since the skb is still referenced. 3) The same skb is now sent to socket 2. I agree with your solution except that we should still do the skb_get if we can. Here is my version where we only do the skb_get at the start. Signed-off-by: Herbert Xu Please let me know whether this works for you or not. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -735,12 +735,7 @@ static inline int do_one_broadcast(struc sock_hold(sk); if (p->skb2 == NULL) { - if (atomic_read(&p->skb->users) != 1) { - p->skb2 = skb_clone(p->skb, p->allocation); - } else { - p->skb2 = p->skb; - atomic_inc(&p->skb->users); - } + p->skb2 = skb_clone(p->skb, p->allocation); } if (p->skb2 == NULL) { netlink_overrun(sk); @@ -776,7 +771,8 @@ int netlink_broadcast(struct sock *ssk, info.delivered = 0; info.allocation = allocation; info.skb = skb; - info.skb2 = NULL; + info.skb2 = skb; + skb_get(skb); /* While we sleep in clone, do not allow to change socket list */ --uAKRQypu60I7Lcqm-- From dtor_core@ameritech.net Tue May 10 22:47:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 22:47:15 -0700 (PDT) Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4B5kxOv014255 for ; Tue, 10 May 2005 22:47:03 -0700 Received: from unknown (HELO core.corenet.prv) (dtor?core@ameritech.net@68.23.10.155 with plain) by smtp814.mail.sc5.yahoo.com with SMTP; 11 May 2005 05:46:34 -0000 From: Dmitry Torokhov To: johnpol@2ka.mipt.ru Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Date: Wed, 11 May 2005 00:46:27 -0500 User-Agent: KMail/1.8 Cc: dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050510222424.5b411c89@zanzibar.2ka.mipt.ru> In-Reply-To: <20050510222424.5b411c89@zanzibar.2ka.mipt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505110046.28797.dtor_core@ameritech.net> X-archive-position: 1003 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtor_core@ameritech.net Precedence: bulk X-list: netdev Content-Length: 9623 Lines: 240 On Tuesday 10 May 2005 13:24, Evgeniy Polyakov wrote: > On Tue, 10 May 2005 12:50:55 -0500 > Dmitry Torokhov wrote: > > > On 5/10/05, Evgeniy Polyakov wrote: > > > On Tue, 10 May 2005 09:56:45 -0500 > > > Dmitry Torokhov wrote: > > > > > > > On 5/10/05, Evgeniy Polyakov wrote: > > > > > On Tue, 10 May 2005 01:18:46 -0500 > > > > > Dmitry Torokhov wrote: > > > > > > > > > > > - drop cn_dev - there is only one connector; > > > > > > > > > > There may be several connectors with different socket types. > > > > > I use it in my environment for tests. > > > > > > > > > > > > > Why do you need that? u32 ID space is not enough? > > > > > > They use different netlink sockets. > > > One of them can fail during initialisation, for example... > > > > Are you saying that there more chances successfully allocating 2 > > netlink sockets than one? > > Of course - one may be in use by ipt_ULOG for example. And what does it have to do with multiple connectors and different sockets? You just need to find one free socket, once you found it you have only one instance of connector running. > Although probably it could be better to get new unit from David Miller. > I want to create some kind of unused-in-kernel socket number - > each netlink user outside kernel might use it without kernel users > bothering. Right. > > > > > > > > > - simplify cn_notify_request to carry only one range - it simplifies code > > > > > > quite a bit - nothing stops clientd from sending several notification > > > > > > requests; > > > > > > > > > > ? Nothing stops clients from sending several notification requests now. > > > > > I do not see how it simplifies the things? > > > > > Feel free to set idx_num and val_num to 1 and you will have the same. > > > > > > > > Compare the implementaion - without variable-length notification > > > > requests the code is much simplier and flexible. > > > > > > Hmm, old request had a length, new one - does not. > > > But instead of atomically addition of the whole set, one need to send > > > couple of events. > > > I do not see any profit here. > > > > Smaller kernel code, simpler notification structure, ability to stop > > listenig to a certain events without re-registering the rest of the > > block. > > As I said - set idx and val numbers to one and you will have the same > behaviour. > Code is neither smaller [ok, you removed a loop] nor simplier > - it is functionality decreasing. Actually, I would do yet another step and just put something like int cn_request_notify(u32 group, u32 idx, u32 idx_range, u32 val, u32 val_range) int cn_cancel_notify(u32 group, u32 idx, u32 idx_range, u32 val, u32 val_range) into connector core. Then drivers could do something like this: static int cn_test_want_notify(void) { int error; error = cn_request_notify(1, cn_test_id.idx, 10, cn_test_id.val, 10); if (error) return error; error = cn_request_notify(1, cn_test_id.idx, 10, cn_test_id.val + 20, 10); if (error) { /* unregister */ cn_cancel_notify(1, cn_test_id.idx, 10, cn_test_id.val, 10); return error; } return 0; } No messing up with memory allocations and complex message structures. > > > > > Connector with your changes just does not work. > > > > > > > > As in "I tried to run it and adjusted the application for the new > > > > cn_notify_req size and it does not work" or "I am saying it does not > > > > work"? > > > > > > Second, i.e. "I am saing it does not work". > > > With your changes userspace just does not see any message being sent by kernelspace. > > > > Would you care to elaborate on this please. As far as I know > > kernel->userspace path was not changed at all. > > I inserted your module and test module, which sends a message using cn_netlink_send() > one time per second. > Usersace application bound to -1 group does not receive that messages. Works for me: root@core cntest]# ./a.out recvfrom successful counter = 0 recvfrom successful counter = 1 recvfrom successful counter = 2 recvfrom successful counter = 3 recvfrom successful counter = 4 recvfrom successful counter = 5 recvfrom successful counter = 6 recvfrom successful counter = 7 recvfrom successful counter = 8 (I won't ever show anyone that gutted piece of ulogd that produced these messages :) ) Try recompiling your userspace application, messages were changed a bit. > > > > > Dmitry, I do not understand why do you change things in so radical manner, > > > > > especially when there are no 1. new interesting features, 2. no performance > > > > > improvements, 3. no right design changes. > > > > > > > > There is a right design change - it keeps the code simple. It peels > > > > all the layers you invented for something that does not really need > > > > layers - connector is just a simple wrapper over raw netlink. > > > > > > That is your opinion. > > > > > > Code is already as simple as possible, since it is layered and each > > > piece of code is separated from different logical entities. > > > > > > > When I look at the code I see the mess of unneeded refcounting, wrong > > > > kinds of locking, over-engineering. Of course I want to change it. > > > > > > There are no unneded reference counting now. > > > Locking was not wrong - you only placed semaphore instead of notify BH lock > > > just to have ability to sleep under the lock and send callback addition/removing > > > notification with GFP_KERNEL mask, > > > and it is probably right change from the first view, as I said, > > > but it can be implemented in a different way. > > > > That's what I was referring to as "wring locking". Notifications do > > not need to stop bottom handlers, a spinlock or semaphore willl work > > just fine. SInce I wanted to allocate memory only after I determined > > that it is a new notify request a semaphore was a better choise. > > I will think of it, but in long-time I do not like such approach - > it is some kind of deadlock - we have no memory, so we sleep in allocation, > so we can not remove callback since it will sleep in allocation... There is no deadlock. We are not waiting for memory to be freed, we are waiting for paging. > > > > Keep it simple. Except for your testing environment why do you need to > > > > have separate netlink sockets? You have an ample ID space. Why do you > > > > need separate cn_dev and cn_queue_dev (and in the end have them at > > > > all)? Why do you need "input" handler, do you expect to use different > > > > handlers? If so which? And why? Do you expect to use other transports? > > > > If so which? And why? You need to have justifiction for every > > > > additional layer you putting on. > > > > > > Sigh. > > > It was already answered so many times, as far as I remember... > > > Ok, let's do it again. > > > > > > Several netlink sockets - if you can see, connector uses NETLINK_ULOG > > > for it's notification, you can not use the same socket twice, so you > > > may have new device with new socket, or several of them, and system > > > may work if one initialisation failed. > > > > Or it may not. Why do you think that having several sockets is safer > > than using one? After all, it is just a matter of setting it up and > > finally allocating a separate socket number for connector. > > Yes, there can be such a way. > But when connector was not in mainline it used TUN/TAP netlink sockets > and tried to get one by one, until successfully allocated. > Using dmesg userspace could find needed socket number for itself. > And in the end you have one connector bound to some socket. There is no multiple connectors - the goal (as far as I see it) was to have single transport web of messages and callbacks for entire kernel. It does not make sense to divide it. > > > cn_dev is connector device structure, cn_queue_dev - it's queueing part. > > > input handler is needed for ability to receive messages. > > > > You chose not to understand my question. Why do you need to have is as > > a pointer? Do you expect to have different input handler? > > In runtime - no. > cn_dev is a main transport structure, while cn_queue_dev is for > callback queue handling. > > > > Couple of next questions can be answered in one reply: > > > original connector's idea was to implement notification based > > > not on top of netlink protocol, but using ioctls of char device, > > > so there could be different connector device, input method, > > > transport and so on. Probably I will not implement it thought. > > > > IOW this all is remnants of an older design. You have no plans to > > utilize the framework and therefore it is not needed anymore and can > > be dropped. > > Different connector devices still there. > They use different sockets. > Concider netlink2 [with guaranteed delivering - I have some ideas about it] - > one just needs to add a new connector device, no new braindumping and > recalling how it was cool before. > It will require some changes to the connector structure, but it will not > be complete rewrite because some time ago someone decided we do not > need it and completely removed anything that lives outside simple > netlink wrapper. Think about implications some more - userspace needs to be aware and chose what socket to bind to, applications will change... Messages will change. In-kernel users will also have to select kind of transport they want to use (guaranteed delivery or not) - it looks like you'll be better off having these connectors completely separated. -- Dmitry From mperaya@alcazaba.unex.es Tue May 10 23:11:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 23:11:21 -0700 (PDT) Received: from www.fcdyc.unex.es (alcazaba.unex.es [158.49.151.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4B6BFOv015133 for ; Tue, 10 May 2005 23:11:16 -0700 Received: from webmail.fcdyc.unex.es ([158.49.151.11] ident=Debian-exim) by www.fcdyc.unex.es with esmtp (Exim 4.50) id 1DVkKs-0005UM-O7; Wed, 11 May 2005 08:04:46 +0200 Received: from www-data by webmail.fcdyc.unex.es with local (Exim 4.50) id 1DVkKs-0002UD-GN; Wed, 11 May 2005 08:04:46 +0200 Received: from 79.red-217-125-250.pooles.rima-tde.net (79.red-217-125-250.pooles.rima-tde.net [217.125.250.79]) by 158.49.151.11 (Horde MIME library) with HTTP for ; Wed, 11 May 2005 08:04:46 +0200 Message-ID: <20050511080446.fnstrvtzq8gk8884@158.49.151.11> X-Priority: 3 (Normal) Date: Wed, 11 May 2005 08:04:46 +0200 From: Manuel Perez Ayala To: Michael Chan Cc: netdev@oss.sgi.com Subject: Re: tg3 support broken on PPC, a workaround References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> In-Reply-To: <1115743966.8570.26.camel@rh4> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-FCDyC-UEx-MailScanner: Found to be clean X-FCDyC-UEx-MailScanner-From: mperaya@alcazaba.unex.es Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4B6BFOv015133 X-archive-position: 1004 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mperaya@alcazaba.unex.es Precedence: bulk X-list: netdev Content-Length: 2610 Lines: 95 > > I assume you have a 5700 or 5701 as this code that controls the DMA > boundaries only affects those devices. Please confirm with the lspci > output or tg3's probing output. > This is the lspci output 0000:00:0b.0 Host bridge: Apple Computer Inc. UniNorth 1.5 AGP 0000:00:10.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) 0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 1.5 PCI 0001:10:13.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5700 Gigabit Ethernet (rev 12) 0001:10:17.0 ff00: Apple Computer Inc. KeyLargo Mac I/O (rev 03) 0001:10:18.0 USB Controller: Apple Computer Inc. KeyLargo USB 0001:10:19.0 USB Controller: Apple Computer Inc. KeyLargo USB 0002:20:0b.0 Host bridge: Apple Computer Inc. UniNorth 1.5 Internal PCI 0002:20:0e.0 ffff: Lucent Microelectronics FW323 (rev ff) 0002:20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth GMAC (Sun GEM) (rev 01) > Can you print out the value of tp->dma_rwctrl in hex just before it is > written to the register in the line: > > tw32(TG3PCI_DMA_RW_CTRL, tp->dma_rwctrl); > > Please do this for the working and non-working driver versions. Value of tp->dma_rwctrl non-working driver: On init of driver tg3.c:v3.10 (September 14, 2004) PCI: Enabling device 0001:10:13.0 (0014 -> 0016) tg3: tg3_test_dma #1: 76FF280F eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:04:76:3b:51:ae eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0] I've added the output of the tp->dma_rwctrl value in hex to kern messages: tg3: tg3_test_dma #1: 76FF280F On init of network interface: tg3: tg3_reset_hw: 76FF280F tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is on for TX and on for RX. I've added too the output of the tp->dma_rwctrl value in hex in the tg3_reset_hw function: tg3: tg3_reset_hw: 76FF280F Working driver: On init of driver: tg3.c:v3.10 (September 14, 2004) PCI: Enabling device 0001:10:13.0 (0014 -> 0016) tg3: tg3_test_dma #1: 76FF120F eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:04:76:3b:51:ae eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0] And on init of the network interface: tg3: tg3_reset_hw: 76FF120F tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is on for TX and on for RX. Hope this will be useful Thanks ---------- Manuel Perez Ayala mperaya@alcazaba.unex.es Facultad de Biblioteconomía y Documentación Universidad de Extremadura From johnpol@2ka.mipt.ru Tue May 10 23:42:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 10 May 2005 23:42:57 -0700 (PDT) Received: from vocord.com (user-edvans3.msk.internet2.ru [217.25.93.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4B6gmOv016700 for ; Tue, 10 May 2005 23:42:49 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j4B6emAS001832; Wed, 11 May 2005 10:40:48 +0400 Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Dmitry Torokhov Cc: dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan In-Reply-To: <200505110046.28797.dtor_core@ameritech.net> References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050510222424.5b411c89@zanzibar.2ka.mipt.ru> <200505110046.28797.dtor_core@ameritech.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ie3WZAlwwj3NWxta+but" Organization: MIPT Date: Wed, 11 May 2005 10:48:50 +0400 Message-Id: <1115794130.6096.30.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Wed, 11 May 2005 10:41:09 +0400 (MSD) X-archive-position: 1005 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 12701 Lines: 349 --=-ie3WZAlwwj3NWxta+but Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-05-11 at 00:46 -0500, Dmitry Torokhov wrote: > > > > > > > > > > > > > - drop cn_dev - there is only one connector; > > > > > > > > > > > > There may be several connectors with different socket types. > > > > > > I use it in my environment for tests. > > > > > > > > > > > > > > > > Why do you need that? u32 ID space is not enough? > > > >=20 > > > > They use different netlink sockets. > > > > One of them can fail during initialisation, for example... > > >=20 > > > Are you saying that there more chances successfully allocating 2 > > > netlink sockets than one? > >=20 > > Of course - one may be in use by ipt_ULOG for example. >=20 > And what does it have to do with multiple connectors and different socket= s? > You just need to find one free socket, once you found it you have only on= e > instance of connector running. Because one connector may be added for general-purpose socket like existing one, any other connectors can be added for different transport layer for example. > > Although probably it could be better to get new unit from David Miller. > > I want to create some kind of unused-in-kernel socket number -=20 > > each netlink user outside kernel might use it without kernel users > > bothering. >=20 > Right. >=20 > > > >=20 > > > > > > > - simplify cn_notify_request to carry only one range - it sim= plifies code > > > > > > > quite a bit - nothing stops clientd from sending several no= tification > > > > > > > requests; > > > > > > > > > > > > ? Nothing stops clients from sending several notification reque= sts now. > > > > > > I do not see how it simplifies the things? > > > > > > Feel free to set idx_num and val_num to 1 and you will have the= same. > > > > > > > > > > Compare the implementaion - without variable-length notification > > > > > requests the code is much simplier and flexible. > > > >=20 > > > > Hmm, old request had a length, new one - does not. > > > > But instead of atomically addition of the whole set, one need to se= nd > > > > couple of events. > > > > I do not see any profit here. > > >=20 > > > Smaller kernel code, simpler notification structure, ability to stop > > > listenig to a certain events without re-registering the rest of the > > > block. > >=20 > > As I said - set idx and val numbers to one and you will have the same=20 > > behaviour. > > Code is neither smaller [ok, you removed a loop] nor simplier=20 > > - it is functionality decreasing. >=20 > Actually, I would do yet another step and just put something like >=20 > int cn_request_notify(u32 group, u32 idx, u32 idx_range, u32 val, u32 val= _range) > int cn_cancel_notify(u32 group, u32 idx, u32 idx_range, u32 val, u32 val_= range) >=20 > into connector core. Then drivers could do something like this: >=20 > static int cn_test_want_notify(void) > { > int error; >=20 > error =3D cn_request_notify(1, cn_test_id.idx, 10, cn_test_id.val, 10); > if (error) > return error; >=20 > error =3D cn_request_notify(1, cn_test_id.idx, 10, cn_test_id.val + 20, = 10); > if (error) { > /* unregister */ > cn_cancel_notify(1, cn_test_id.idx, 10, cn_test_id.val, 10); > return error; > } >=20 > return 0; > } >=20 > No messing up with memory allocations and complex message structures. Yep, it could be done, but it has nothing in common with request structure changes. I will place it into TODO, thanks. > > > > > > Connector with your changes just does not work. > > > > > > > > > > As in "I tried to run it and adjusted the application for the new > > > > > cn_notify_req size and it does not work" or "I am saying it does = not > > > > > work"? > > > >=20 > > > > Second, i.e. "I am saing it does not work". > > > > With your changes userspace just does not see any message being sen= t by kernelspace. > > >=20 > > > Would you care to elaborate on this please. As far as I know > > > kernel->userspace path was not changed at all. > >=20 > > I inserted your module and test module, which sends a message using cn_= netlink_send() > > one time per second. > > Usersace application bound to -1 group does not receive that messages. >=20 > Works for me: >=20 > root@core cntest]# ./a.out > recvfrom successful > counter =3D 0 > recvfrom successful > counter =3D 1 > recvfrom successful > counter =3D 2 > recvfrom successful > counter =3D 3 > recvfrom successful > counter =3D 4 > recvfrom successful > counter =3D 5 > recvfrom successful > counter =3D 6 > recvfrom successful > counter =3D 7 > recvfrom successful > counter =3D 8 >=20 > (I won't ever show anyone that gutted piece of ulogd that produced these > messages :) ) > =20 > Try recompiling your userspace application, messages were changed a bit. I recompiled everything - still does not work. Application is just reading from socket after polling, it even does not know about messages itself. > > > > > > Dmitry, I do not understand why do you change things in so radi= cal manner, > > > > > > especially when there are no 1. new interesting features, 2. no= performance > > > > > > improvements, 3. no right design changes. > > > > > > > > > > There is a right design change - it keeps the code simple. It pee= ls > > > > > all the layers you invented for something that does not really ne= ed > > > > > layers - connector is just a simple wrapper over raw netlink. > > > >=20 > > > > That is your opinion. > > > >=20 > > > > Code is already as simple as possible, since it is layered and each > > > > piece of code is separated from different logical entities. > > > >=20 > > > > > When I look at the code I see the mess of unneeded refcounting, w= rong > > > > > kinds of locking, over-engineering. Of course I want to change it= . > > > >=20 > > > > There are no unneded reference counting now. > > > > Locking was not wrong - you only placed semaphore instead of notify= BH lock > > > > just to have ability to sleep under the lock and send callback addi= tion/removing > > > > notification with GFP_KERNEL mask, > > > > and it is probably right change from the first view, as I said, > > > > but it can be implemented in a different way. > > >=20 > > > That's what I was referring to as "wring locking". Notifications do > > > not need to stop bottom handlers, a spinlock or semaphore willl work > > > just fine. SInce I wanted to allocate memory only after I determined > > > that it is a new notify request a semaphore was a better choise. > >=20 > > I will think of it, but in long-time I do not like such approach -=20 > > it is some kind of deadlock - we have no memory, so we sleep in allocat= ion, > > so we can not remove callback since it will sleep in allocation... >=20 > There is no deadlock. We are not waiting for memory to be freed, we are > waiting for paging. Yep. That is why pool is better. Actually I even want some kind of pools for skb, but do not think it will be a good idea. That will require several of them for different sizes and so on... > > > > > Keep it simple. Except for your testing environment why do you ne= ed to > > > > > have separate netlink sockets? You have an ample ID space. Why do= you > > > > > need separate cn_dev and cn_queue_dev (and in the end have them a= t > > > > > all)? Why do you need "input" handler, do you expect to use diffe= rent > > > > > handlers? If so which? And why? Do you expect to use other transp= orts? > > > > > If so which? And why? You need to have justifiction for every > > > > > additional layer you putting on. > > > >=20 > > > > Sigh. > > > > It was already answered so many times, as far as I remember... > > > > Ok, let's do it again. > > > >=20 > > > > Several netlink sockets - if you can see, connector uses NETLINK_UL= OG > > > > for it's notification, you can not use the same socket twice, so yo= u > > > > may have new device with new socket, or several of them, and system > > > > may work if one initialisation failed. > > >=20 > > > Or it may not. Why do you think that having several sockets is safer > > > than using one? After all, it is just a matter of setting it up and > > > finally allocating a separate socket number for connector. > >=20 > > Yes, there can be such a way. > > But when connector was not in mainline it used TUN/TAP netlink sockets > > and tried to get one by one, until successfully allocated. > > Using dmesg userspace could find needed socket number for itself. > > >=20 > And in the end you have one connector bound to some socket. There is no > multiple connectors - the goal (as far as I see it) was to have single > transport web of messages and callbacks for entire kernel. It does not ma= ke > sense to divide it. Callbacks and messages live in cn_queue_dev - it could be the same for different transport layers, transport layer - it is cn_dev, they might be different. You want to remove even ability to extend the system, since you do not see and want to understand that with existing design it could be somehow extended, with your patch - it will be completely closed system. > > > > cn_dev is connector device structure, cn_queue_dev - it's queueing = part. > > > > input handler is needed for ability to receive messages. > > >=20 > > > You chose not to understand my question. Why do you need to have is a= s > > > a pointer? Do you expect to have different input handler? > >=20 > > In runtime - no. > > cn_dev is a main transport structure, while cn_queue_dev is for > > callback queue handling. > >=20 > > > > Couple of next questions can be answered in one reply: > > > > original connector's idea was to implement notification based > > > > not on top of netlink protocol, but using ioctls of char device, > > > > so there could be different connector device, input method, > > > > transport and so on. Probably I will not implement it thought. > > >=20 > > > IOW this all is remnants of an older design. You have no plans to > > > utilize the framework and therefore it is not needed anymore and can > > > be dropped. > >=20 > > Different connector devices still there. > > They use different sockets. > > Concider netlink2 [with guaranteed delivering - I have some ideas about= it] -=20 > > one just needs to add a new connector device, no new braindumping and > > recalling how it was cool before. > > It will require some changes to the connector structure, but it will no= t=20 > > be complete rewrite because some time ago someone decided we do not > > need it and completely removed anything that lives outside simple > > netlink wrapper. >=20 > Think about implications some more - userspace needs to be aware and chos= e > what socket to bind to, applications will change... Messages will change. > In-kernel users will also have to select kind of transport they want to u= se > (guaranteed delivery or not) - it looks like you'll be better off having > these connectors completely separated. No, I do not think messages will be changed, they are quite selfcontained,=20 may be some kind of flags - but existing 32bit length can be closed to 16 bit -=20 16kb is quite enough, especiall with 1024byte checks in connector itself. It is only transport layer that will be changed. Naive approach is just attaching a timer to selected skb and reinit it each time socket has overrun until some timeout, of course with some simple congestion mechanism. Logical high-level messages were separated specially to hide transport layer. We do not change route table when switching from UDP to TCP routes,=20 and connector message header is exactly a "route" for included message. Using flags in connector message header one may select desired connector from kernelspace, binding to different socket or using ioctl selects appropriate=20 connector from userspace. And even better - kernelspace might use not flags, but might add/remove callback to appropriate transport device and thus cn_netlink_send will select required device using message idx.val. Your changes break this idea completely - it will require new queues, new request lists, new set of messages, new ids - almost all will be duplicated instead of new device strucutre which is 28 bytes in size and has a pointer to the common part, which=20 has reference counter for such kind of use. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-ie3WZAlwwj3NWxta+but Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCgarSIKTPhE+8wY0RAnxnAJ423+l9JmEw6CiafZmRKeOT4sEDGgCfQTCt s7tuL5uxf8CqALxaOIT9+UU= =1yn0 -----END PGP SIGNATURE----- --=-ie3WZAlwwj3NWxta+but-- From alan@lxorguk.ukuu.org.uk Wed May 11 07:49:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 07:49:30 -0700 (PDT) Received: from lxorguk.ukuu.org.uk ([81.2.110.250]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BEn8Ov009950 for ; Wed, 11 May 2005 07:49:11 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j4BEA9Ia010534; Wed, 11 May 2005 15:10:09 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id j4BEA2WU010529; Wed, 11 May 2005 15:10:02 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. From: Alan Cox To: Dmitry Torokhov Cc: Evgeniy Polyakov , netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , Linux Kernel Mailing List , Andrew Morton , Thomas Graf , Jay Lan In-Reply-To: <200505100118.48027.dtor_core@ameritech.net> References: <20050411125932.GA19538@uganda.factory.vocord.ru> <200505100118.48027.dtor_core@ameritech.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1115820593.9371.255.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 11 May 2005 15:09:59 +0100 X-archive-position: 1006 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 382 Lines: 11 > BTW, I do not think that "All rights reserved" statement is applicable/ > compatible with GPL this software is supposedly released under, I have > taken liberty of removing this statement. Its perfectly compatible with the GPL and BSD license. All rights reserved is simply asserting all your rights (moral and other). It then goes on to say you can use it under the GPL Alan From chamas@h4.dion.ne.jp Wed May 11 08:21:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 08:21:24 -0700 (PDT) Received: from hfep04.dion.ne.jp (hfep04.dion.ne.jp [203.181.105.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BFLHOv016147 for ; Wed, 11 May 2005 08:21:17 -0700 Received: from localhost ([222.7.40.249]) by hfep04.dion.ne.jp with ESMTP id <20050511152043503.NZNJ@hfep04.dion.ne.jp>; Thu, 12 May 2005 00:20:43 +0900 Date: Thu, 12 May 2005 00:20:41 +0900 (JST) Message-Id: <20050512.002041.-1300550735.chamas@h4.dion.ne.jp> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) From: Ken-ichirou MATSUZAWA In-Reply-To: <20050511005836.GA1674@gondor.apana.org.au> References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> <20050510220751.GA459@gondor.apana.org.au> <20050511005836.GA1674@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1007 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chamas@h4.dion.ne.jp Precedence: bulk X-list: netdev Content-Length: 273 Lines: 9 Hello. From: Herbert Xu Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Date: Wed, 11 May 2005 10:58:36 +1000 > Please let me know whether this works for you or not. It worked, thank you. From mchan@broadcom.com Wed May 11 09:23:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 09:23:19 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BGNGOv019193 for ; Wed, 11 May 2005 09:23:16 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Wed, 11 May 2005 09:22:52 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 11 May 2005 09:22:35 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AXS36721; Wed, 11 May 2005 09:22:34 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id JAA26818; Wed, 11 May 2005 09:22:33 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 May 2005 16:22:33 +0000 Received: from rh4 by nt-irva-0741; 11 May 2005 08:24:41 -0700 Subject: Re: tg3 support broken on PPC, a workaround From: "Michael Chan" To: "Manuel Perez Ayala" cc: netdev@oss.sgi.com In-Reply-To: <20050511080446.fnstrvtzq8gk8884@158.49.151.11> References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> <20050511080446.fnstrvtzq8gk8884@158.49.151.11> Date: Wed, 11 May 2005 08:24:41 -0700 Message-ID: <1115825081.8570.93.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E9CEED60UW3752471-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1008 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 763 Lines: 37 On Wed, 2005-05-11 at 08:04 +0200, Manuel Perez Ayala wrote: > Working driver: > > On init of driver: > > tg3.c:v3.10 (September 14, 2004) > PCI: Enabling device 0001:10:13.0 (0014 -> 0016) > > tg3: tg3_test_dma #1: 76FF120F > This tells me that your cache line size is 32 bytes. Let's try some experiments and see what works and what doesn't. Please hardcode the following values in tp->dma_rwctrl before it is written to the register: 1. DMA read/write boundaries set to 256: tp->dma_rwctrl = 0x76ff2d0f; 2. DMA read boundary 256, write boundary 32: tp->dma_rwctrl = 0x76ff150f; 3. DMA read boundary 32, write boundary 256 tp->dma_rwctrl = 0x76ff2a0f; 4. Let's also try without asserting all byte enables: tp->dma_rwctrl = 0x763f2d0f; Thanks. From marcelo.tosatti@cyclades.com Wed May 11 10:35:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 10:35:24 -0700 (PDT) Received: from parcelfarce.linux.theplanet.co.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BHZHOv023866 for ; Wed, 11 May 2005 10:35:18 -0700 Received: from [127.0.0.1] (helo=logos.cnet) by parcelfarce.linux.theplanet.co.uk with esmtp (Exim 4.43) id 1DVv6b-0004rX-EZ; Wed, 11 May 2005 18:35:01 +0100 Received: by logos.cnet (Postfix, from userid 500) id 61A371230C3; Wed, 11 May 2005 09:46:40 -0300 (BRT) Date: Wed, 11 May 2005 09:46:40 -0300 From: Marcelo Tosatti To: Manfred Schwarb Cc: linux-kernel@vger.kernel.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: 2.4.30-hf1 do_IRQ stack overflows Message-ID: <20050511124640.GE8541@logos.cnet> References: <5.2.1.1.2.20050511093252.01c887b0@mail.meteodat.ch> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20050511093252.01c887b0@mail.meteodat.ch> User-Agent: Mutt/1.5.5.1i X-archive-position: 1009 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: netdev Content-Length: 23442 Lines: 181 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Manfred, On Wed, May 11, 2005 at 10:15:02AM +0200, Manfred Schwarb wrote: > Hi, > with recent versions of the 2.4 kernel (Vanilla), I get an increasing amount of do_IRQ stack overflows. > This night, I got 3 of them. > With 2.4.28 I got an overflow about twice a year, with 2.4.29 nearly once a month and with > 2.4.30 nearly every day 8-(( The system is getting dangerously close to an actual stack overflow, which would crash the system. "do_IRQ: stack overflow: " indicates how many bytes are still available. The traces show huge networking execution paths. It seems you are using some packet scheduler (CONFIG_NET_SCHED)? Pretty much all traces show functions from sch_generic.c. Can you disable that for a test? > My layout: Pentium4 HT SMP, raid1 on a promise card, driven by libata_promise, > everything using reiserfs, heavy nfs and network traffic, with a Linksys (tulip) and a Realtek (8139too) NIC. > The used 2.4.30-hf1 is pure Vanilla. > > Below my three overflow messages. Would the stack reduction patches of Badari Pulavarty > help in my case? If so, I would strongly vote for inclusion into 2.4 series!! It has been decided that the stack reduction patches were too intrusive to be merged at this stage of v2.4 life. We did not receive any report either - v2.4's 8KB kernel stack seems to be enough for vast majority of situations. --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="stack_ovf_2430.log" May 11 04:22:09 server kernel: do_IRQ: stack overflow: 628 May 11 04:22:09 server kernel: f3668824 00000274 e9a40380 00000000 00000003 f7e5d280 f3668000 0000000e May 11 04:22:09 server kernel: c010d948 00000003 f7e5d318 f7e5d308 f7e5d280 f3668000 0000000e 00000006 May 11 04:22:09 server kernel: f1960018 f1a00018 ffffff14 c024893e 00000010 00000202 f7e5d280 f196cc00 May 11 04:22:09 server kernel: Call Trace: [call_do_IRQ+5/13] [pfifo_fast_dequeue+62/80] [qdisc_restart+31/432] [dev_queue_xmit+383/880] [neigh_resolve_output+321/624] May 11 04:22:09 server kernel: Call Trace: [] [] [] [] [] May 11 04:22:09 server kernel: [ip_finish_output2+184/336] [ip_finish_output2+0/336] [ip_finish_output2+0/336] [nf_hook_slow+478/528] [ip_finish_output2+0/336] [ip_output+334/480] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [ip_finish_output2+0/336] [ip_queue_xmit2+213/671] [ip_queue_xmit2+0/671] [ip_queue_xmit2+0/671] [nf_hook_slow+478/528] [ip_queue_xmit2+0/671] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [ip_queue_xmit+845/1536] [ip_queue_xmit2+0/671] [dev_queue_xmit+383/880] [tcp_v4_send_check+160/240] [tcp_transmit_skb+1001/1792] [tcp_send_ack+132/208] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [tcp_rfree+0/32] [tcp_rfree+0/32] [tcp_rcv_established+2042/2640] [tcp_v4_do_rcv+314/352] [tcp_v4_rcv+1726/1952] [ip_local_deliver_finish+351/416] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [ip_local_deliver_finish+0/416] [nf_hook_slow+478/528] [ip_local_deliver_finish+0/416] [ip_local_deliver+399/576] [ip_local_deliver_finish+0/416] [ip_rcv_finish+553/700] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [ip_rcv_finish+0/700] [ip_rcv_finish+0/700] [nf_hook_slow+478/528] [ip_rcv_finish+0/700] [ip_rcv+905/1216] [ip_rcv_finish+0/700] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [netif_receive_skb+485/544] [process_backlog+147/304] [net_rx_action+250/368] [do_softirq+118/224] [do_IRQ+244/304] [call_do_IRQ+5/13] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [__switch_to+82/256] [schedule+738/1344] [schedule_timeout+84/160] [process_timeout+0/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294702743/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294703097/96] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294703275/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294709446/96] [] [] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288825300/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288879050/96] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288713668/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288789620/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288713668/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288712232/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288755907/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288791678/96] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288800963/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288763515/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288713480/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288763309/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288815612/96] [__kfree_skb+254/352] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [__kfree_skb+254/352] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294624756/96] [qdisc_restart+31/432] [dev_queue_xmit+383/880] [neigh_resolve_output+321/624] [__kfree_skb+254/352] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294624756/96] [qdisc_restart+31/432] [dev_queue_xmit+383/880] [neigh_resolve_output+321/624] [ip_finish_output2+184/336] [ip_finish_output2+0/336] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [ip_finish_output2+0/336] [nf_hook_slow+478/528] [ip_finish_output2+0/336] [ip_output+334/480] [ip_finish_output2+0/336] [ip_queue_xmit2+213/671] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [ip_queue_xmit2+0/671] [ip_queue_xmit2+0/671] [nf_hook_slow+478/528] [ip_queue_xmit2+0/671] [ip_queue_xmit+845/1536] [ip_queue_xmit2+0/671] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [skb_checksum+92/800] [sock_def_readable+99/128] [tcp_rfree+0/32] [tcp_rfree+0/32] [tcp_rcv_established+1981/2640] [tcp_v4_do_rcv+314/352] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [tcp_v4_rcv+1726/1952] [locate_hd_struct+56/160] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288606771/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288606771/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288607559/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288679225/96] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288574821/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288906935/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288935563/96] [bh_action+106/112] [tasklet_hi_action+83/160] [sys_ioctl+677/785] May 11 04:22:09 server kernel: [] [] [] [] [] [] May 11 04:22:09 server kernel: [system_call+51/56] May 11 04:22:09 server kernel: [] ####################################################### May 11 04:26:28 server kernel: do_IRQ: stack overflow: 1000 May 11 04:26:28 server kernel: f3668998 000003e8 00000000 00000000 f3668000 f3668ac0 f3668a34 00000000 May 11 04:26:28 server kernel: c010d948 f3668000 0001961a 00000944 f3668ac0 f3668a34 00000000 00000944 May 11 04:26:28 server kernel: 00000018 f1960018 ffffff14 f90820a7 00000010 00000246 f3668a34 f40a9ec0 May 11 04:26:28 server kernel: Call Trace: [call_do_IRQ+5/13] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294250663/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294268736/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294250842/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294254302/96] May 11 04:26:28 server kernel: Call Trace: [] [] [] [] [] May 11 04:26:28 server kernel: [ip_queue_xmit2+0/671] [nf_iterate+85/160] [ip_queue_xmit2+0/671] [ip_queue_xmit2+0/671] [nf_hook_slow+247/528] [ip_queue_xmit2+0/671] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294266808/96] [ip_queue_xmit+845/1536] [ip_queue_xmit2+0/671] [tcp_v4_rcv+1726/1952] [tcp_v4_send_check+160/240] [tcp_transmit_skb+1001/1792] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [tcp_send_ack+132/208] [tcp_rfree+0/32] [tcp_rfree+0/32] [tcp_rcv_established+2042/2640] [tcp_v4_do_rcv+314/352] [tcp_v4_rcv+1726/1952] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [ip_local_deliver_finish+351/416] [ip_local_deliver_finish+0/416] [nf_hook_slow+478/528] [ip_local_deliver_finish+0/416] [ip_local_deliver+399/576] [ip_local_deliver_finish+0/416] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [ip_rcv_finish+553/700] [ip_rcv_finish+0/700] [ip_rcv_finish+0/700] [nf_hook_slow+478/528] [ip_rcv_finish+0/700] [ip_rcv+905/1216] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [ip_rcv_finish+0/700] [netif_receive_skb+485/544] [process_backlog+147/304] [net_rx_action+250/368] [do_softirq+118/224] [do_IRQ+244/304] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [call_do_IRQ+5/13] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294701080/96] [] [] [] [] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [isofs_read_super+1131/2048] [] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288825300/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288879050/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288713668/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288789620/96] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288713668/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288712232/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288755907/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288791678/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288800963/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288763515/96] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288713480/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288763309/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288815612/96] [__kfree_skb+254/352] [__kfree_skb+254/352] [__kfree_skb+254/352] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294624756/96] [qdisc_restart+31/432] [dev_queue_xmit+383/880] [neigh_resolve_output+321/624] [ip_finish_output2+184/336] [ip_finish_output2+0/336] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [ip_finish_output2+0/336] [nf_hook_slow+478/528] [ip_finish_output2+0/336] [ip_output+334/480] [ip_finish_output2+0/336] [ip_queue_xmit2+213/671] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [ip_queue_xmit2+0/671] [ip_queue_xmit2+0/671] [nf_hook_slow+478/528] [ip_queue_xmit2+0/671] [ip_queue_xmit+845/1536] [ip_queue_xmit2+0/671] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [nf_hook_slow+478/528] [tcp_v4_send_check+160/240] [tcp_transmit_skb+1001/1792] [sock_def_readable+99/128] [tcp_rfree+0/32] [tcp_rfree+0/32] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [tcp_rcv_established+1981/2640] [tcp_v4_do_rcv+314/352] [tcp_v4_rcv+1726/1952] [ip_local_deliver_finish+351/416] [ip_local_deliver_finish+0/416] [nf_hook_slow+478/528] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [ip_local_deliver_finish+0/416] [ip_local_deliver+399/576] [ip_local_deliver_finish+0/416] [ip_rcv_finish+553/700] [ip_rcv_finish+0/700] [ip_rcv_finish+0/700] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [nf_hook_slow+478/528] [schedule+738/1344] [schedule_timeout+94/160] [poll_freewait+68/80] [do_select+569/592] [sys_select+660/1248] May 11 04:26:28 server kernel: [] [] [] [] [] [] May 11 04:26:28 server kernel: [sys_ioctl+677/785] [sys_time+21/80] [system_call+51/56] May 11 04:26:28 server kernel: [] [] [] ############################################################# May 11 04:30:06 server kernel: do_IRQ: stack overflow: 640 May 11 04:30:06 server kernel: f3668830 00000280 f2c73080 00000000 f196cd80 d2029180 d2029180 00000042 May 11 04:30:06 server kernel: c010d948 f196cd80 f008a0ec d2029180 d2029180 d2029180 00000042 f008a080 May 11 04:30:06 server kernel: f1960018 f5fd0018 ffffff14 c0238723 00000010 00000202 d2029180 d2029180 May 11 04:30:06 server kernel: Call Trace: [call_do_IRQ+5/13] [__kfree_skb+99/352] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294624756/96] [qdisc_restart+114/432] [dev_queue_xmit+383/880] May 11 04:30:06 server kernel: Call Trace: [] [] [] [] [] May 11 04:30:06 server kernel: [ip_finish_output2+184/336] [ip_finish_output2+0/336] [ip_finish_output2+0/336] [nf_hook_slow+478/528] [ip_finish_output2+0/336] [ip_output+334/480] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [ip_finish_output2+0/336] [ip_queue_xmit2+213/671] [ip_queue_xmit2+0/671] [ip_queue_xmit2+0/671] [nf_hook_slow+478/528] [ip_queue_xmit2+0/671] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [ip_queue_xmit+845/1536] [ip_queue_xmit2+0/671] [tcp_v4_send_check+160/240] [tcp_transmit_skb+1001/1792] [tcp_send_ack+132/208] [tcp_rfree+0/32] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [tcp_rfree+0/32] [tcp_rcv_established+2042/2640] [tcp_v4_do_rcv+314/352] [tcp_v4_rcv+1726/1952] [ip_local_deliver_finish+351/416] [ip_local_deliver_finish+0/416] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [nf_hook_slow+478/528] [ip_local_deliver_finish+0/416] [ip_local_deliver+399/576] [ip_local_deliver_finish+0/416] [ip_rcv_finish+553/700] [ip_rcv_finish+0/700] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [ip_rcv_finish+0/700] [nf_hook_slow+478/528] [ip_rcv_finish+0/700] [ip_rcv+905/1216] [ip_rcv_finish+0/700] [netif_receive_skb+485/544] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [process_backlog+147/304] [net_rx_action+250/368] [do_softirq+118/224] [do_IRQ+244/304] [call_do_IRQ+5/13] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294806243/96] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294808580/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294815256/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294702477/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294702701/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294703097/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294703275/96] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294709446/96] [] [isofs_read_super+1131/2048] [] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288825300/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288879050/96] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288713668/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288789620/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288713668/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288712232/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288755907/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288791678/96] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288800963/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288763515/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288713480/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288763309/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4288815612/96] [__kfree_skb+254/352] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [netif_rx+147/496] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294626081/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294624756/96] [__kfree_skb+254/352] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294624756/96] [__kfree_skb+254/352] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [__kfree_skb+254/352] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294624756/96] [qdisc_restart+31/432] [dev_queue_xmit+383/880] [ip_finish_output2+184/336] [ip_finish_output2+0/336] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [ip_finish_output2+0/336] [nf_hook_slow+478/528] [ip_finish_output2+0/336] [ip_output+334/480] [ip_finish_output2+0/336] [ip_queue_xmit2+213/671] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [ip_queue_xmit2+0/671] [ip_queue_xmit2+0/671] [nf_hook_slow+478/528] [ip_queue_xmit2+0/671] [ip_queue_xmit+845/1536] [ip_queue_xmit2+0/671] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [sock_def_readable+99/128] [tcp_rfree+0/32] [tcp_rfree+0/32] [tcp_rcv_established+1981/2640] [tcp_v4_do_rcv+314/352] [tcp_v4_rcv+1726/1952] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [ip_local_deliver_finish+351/416] [ip_local_deliver_finish+0/416] [nf_hook_slow+478/528] [ip_local_deliver_finish+0/416] [ip_local_deliver+399/576] [ip_local_deliver_finish+0/416] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [ip_rcv_finish+553/700] [__alloc_pages+100/640] [poll_freewait+68/80] [do_select+569/592] [sys_select+660/1248] [sys_ioctl+677/785] May 11 04:30:06 server kernel: [] [] [] [] [] [] May 11 04:30:06 server kernel: [sys_time+21/80] [system_call+51/56] May 11 04:30:06 server kernel: [] [] --SLDf9lqlvOQaIe6s-- From jdmason@us.ibm.com Wed May 11 11:36:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 11:36:39 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BIaTOv026246 for ; Wed, 11 May 2005 11:36:36 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4BIZvmD349708 for ; Wed, 11 May 2005 14:35:57 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4BIZuMA254158 for ; Wed, 11 May 2005 12:35:56 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4BIZuED024094 for ; Wed, 11 May 2005 12:35:56 -0600 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4BIZu6g024068 for ; Wed, 11 May 2005 12:35:56 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.10) with ESMTP id j4BIZtFv143204; Wed, 11 May 2005 13:35:55 -0500 Received: from dreadnought (dreadnought.austin.ibm.com [9.53.90.32]) by popmail.austin.ibm.com (AIX5.1/8.11.6p2/8.9.3) with SMTP id j4BIZse37532; Wed, 11 May 2005 13:35:54 -0500 Received: by dreadnought (sSMTP sendmail emulation); Wed, 11 May 2005 13:35:54 -0500 Date: Wed, 11 May 2005 13:35:54 -0500 From: Jon Mason To: netdev@oss.sgi.com Cc: Nivedita Singhvi , Andrew Theurer Subject: Interdomain/interpartition communication without a checksum Message-ID: <20050511183554.GA28298@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i X-archive-position: 1010 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2900 Lines: 67 I have been working on a Xen project to remove unnecessary TCP/UDP checksums for local (interdomain) communication, while still having the checksum for all external network communication. background: Xen uses a controlling partition (domain 0 in Xen terms) to connect all guest partitions to physical devices (disk, ethernet, etc). For network traffic, the guest partitions connect to the controlling partition via virtual ethernet devices. These virtual ethernet devices are either bridged or routed to the physical ethernet to connect to the external network. In its current implimentation, Xen guest partitions checksum packets regardless of their intended destination (local or remote) and regardless of adapter hardware checksum offload capabilities for the physical adapter. I have a working prototype which corrects both of these issues in Xen, but it requires minor changes to two files (net/core/dev.c and include/linux/netdevice.h). I have not submitted this patch to the Xen mailing list, as I wanted all of you to comment on it first. The changes are abstract enough to where they can be used by anyone wanting interdomain/interpartition communication without a checksum (e.g., not Xen specific). I have only included the Linux files, but if anyone is interested I can also include the modified Xen files. Thanks, Jon --- ../xen-unstable-pristine/linux-2.6.11-xen0/net/core/dev.c 2005-03-02 01:38:09.000000000 -0600 +++ linux-2.6.11-xen0/net/core/dev.c 2005-05-11 08:00:28.234919880 -0500 @@ -98,6 +98,7 @@ #include #include #include +#include #include #include #include @@ -1236,6 +1237,15 @@ int dev_queue_xmit(struct sk_buff *skb) __skb_linearize(skb, GFP_ATOMIC)) goto out_kfree_skb; + /* If packet is forwarded to a device that needs a checksum and not + * checksummed, correct the pointers and enable checksumming in the + * next function. + */ + if (!(dev->features & NETIF_F_FWD_NO_CSUM) && skb->csum) { + skb->ip_summed = CHECKSUM_HW; + skb->h.raw = (void *)skb->nh.iph + (skb->nh.iph->ihl * 4); + } + /* If packet is not checksummed and device does not support * checksumming for this protocol, complete checksumming here. */ --- ../xen-unstable-pristine/linux-2.6.11-xen0/include/linux/netdevice.h 2005-03-02 01:38:26.000000000 -0600 +++ linux-2.6.11-xen0/include/linux/netdevice.h 2005-05-10 11:03:25.000000000 -0500 @@ -416,6 +416,7 @@ struct net_device #define NETIF_F_VLAN_CHALLENGED 1024 /* Device cannot handle VLAN packets */ #define NETIF_F_TSO 2048 /* Can offload TCP/IP segmentation */ #define NETIF_F_LLTX 4096 /* LockLess TX */ +#define NETIF_F_FWD_NO_CSUM 8192 /* Forwards unchecksumed packets */ /* Called after device is detached from network. */ void (*uninit)(struct net_device *dev); From pizza@shaft.shaftnet.org Wed May 11 13:42:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 13:42:06 -0700 (PDT) Received: from shaft.shaftnet.org (rrcs-24-73-230-86.se.biz.rr.com [24.73.230.86]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BKfxOv001431 for ; Wed, 11 May 2005 13:42:00 -0700 Received: from shaft.shaftnet.org (localhost [127.0.0.1]) by shaft.shaftnet.org (8.12.10/8.12.10) with ESMTP id j4BKcnDn011439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2005 16:38:49 -0400 Received: (from pizza@localhost) by shaft.shaftnet.org (8.12.10/8.12.8/Submit) id j4BKcjOt011437; Wed, 11 May 2005 16:38:45 -0400 Date: Wed, 11 May 2005 16:38:45 -0400 From: Stuffed Crust To: Herbert Xu Cc: davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] fix long-standing bug in 2.6/2.4 skb_copy/skb_copy_expand Message-ID: <20050511203845.GA10770@shaftnet.org> References: <20050508143259.GA30676@shaftnet.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Scanned-By: milter-7bit/0.7.101 (localhost [127.0.0.1]); Wed, 11 May 2005 16:38:51 -0400 X-Scanned-By: milter-date/0.12.160 (localhost [127.0.0.1]); Wed, 11 May 2005 16:38:51 -0400 X-milter-date-PASS: YES X-milter-7bit-Pass: YES X-archive-position: 1011 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pizza@shaftnet.org Precedence: bulk X-list: netdev Content-Length: 1508 Lines: 46 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 09, 2005 at 01:04:34PM +1000, Herbert Xu wrote: > > This is, fortunately, generally true. But if the alloc_skb function=20 > > allocates extra head room (ie calls skb_reserve() on the skb before it= =20 > > passes it to the callee, this doesn't quite work. Instead, it should b= e=20 > > rewritten as: >=20 > As far as I know the alloc_skb funciton in the kernel tree doesn't do > that so your patch is not necessary unless we decide to change the way > alloc_skb works. If that's what you want then please provide a patch > to alloc_skb and a rationale as to why we should do that. It does not, and I have no intention of submitting a patch to change it.=20 As I said in my original message, it was a crude hack which has since been relegated to the great bitbucket of the sky. All that's left is that "bugfix" patch. I've performed my due-diligence in airing it to the powers that be, so=20 I'll go way now. - Solomon --=20 Solomon Peachy ICQ: 1318344 Melbourne, FL JID: pitha@myjabber.net Quidquid latine dictum sit, altum viditur --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCgm1VPuLgii2759ARAp58AJ0YTlpIfHfZzO1FPsrKwvO/nkSDMwCg34Fy oyb6OWUtCSERK967FUx7Pks= =vclu -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From davem@davemloft.net Wed May 11 13:57:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 13:57:56 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BKvoOv002658 for ; Wed, 11 May 2005 13:57:50 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVyG6-0005xG-5c; Wed, 11 May 2005 13:56:46 -0700 Date: Wed, 11 May 2005 13:56:45 -0700 (PDT) Message-Id: <20050511.135645.124868850.davem@davemloft.net> To: pizza@shaftnet.org Cc: herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] fix long-standing bug in 2.6/2.4 skb_copy/skb_copy_expand From: "David S. Miller" In-Reply-To: <20050511203845.GA10770@shaftnet.org> References: <20050508143259.GA30676@shaftnet.org> <20050511203845.GA10770@shaftnet.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1012 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 494 Lines: 11 From: Stuffed Crust Subject: Re: [PATCH] fix long-standing bug in 2.6/2.4 skb_copy/skb_copy_expand Date: Wed, 11 May 2005 16:38:45 -0400 > As I said in my original message, it was a crude hack which has since > been relegated to the great bitbucket of the sky. All that's left is > that "bugfix" patch. If alloc_skb() does not do an skb_reserve(), then the bug fix patch is unnecessary. The "bug" only exists if you happen to change alloc_skb() to do an skb_reserve(). From davem@davemloft.net Wed May 11 14:16:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 14:16:32 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BLGOOv004058 for ; Wed, 11 May 2005 14:16:29 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DVyYF-0005z5-1W; Wed, 11 May 2005 14:15:31 -0700 Date: Wed, 11 May 2005 14:15:30 -0700 (PDT) Message-Id: <20050511.141530.57445142.davem@davemloft.net> To: netdev@oss.sgi.com CC: mchan@broadcom.com Subject: [TG3]: Add hw coalescing infrastructure. From: "David S. Miller" X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1013 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 6907 Lines: 191 Ok, now that we have the tagged status stuff sorted I began to work on putting the hw mitigation bits back into the driver. The discussion on the DMA rw-ctrl settings is still ongoing, but I will get back to it shortly. This is the first step, we cache the settings in the tg3 struct and put those values into the chip via tg3_set_coalesce(). ETHTOOL_GCOALESCE is supported, setting is not. The idea is that if we add dynamnic mitigation or ETHTOOL_SCOALESCE, it will simply invoke this routine to program the hardware. It seems that we should also be avoiding the HOSTCC_{R,T}XCOAL_MAXF_INT registers when TG3_FLG2_5705_PLUS. I didn't make that change yet, just preserving what we were doing previously. Another thing which occurred to me is that these settings are line rate dependant. For example, the 20 usec value is for gigabit. So we may wish to adjust the values we use based upon the negotiated line speed. But that's a future refinement that can wait. I think with the removal of that I/O readback done by the tagged status changes, and this coalescing stuff below, the SGI NUMA performance should be significantly higher. Comments? Signed-off-by: David S. Miller --- 1/drivers/net/tg3.c.~1~ 2005-05-11 11:46:11.000000000 -0700 +++ 2/drivers/net/tg3.c 2005-05-11 13:47:17.000000000 -0700 @@ -2507,7 +2507,7 @@ static int tg3_setup_phy(struct tg3 *tp, if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { if (netif_carrier_ok(tp->dev)) { tw32(HOSTCC_STAT_COAL_TICKS, - DEFAULT_STAT_COAL_TICKS); + tp->coal.stats_block_coalesce_usecs); } else { tw32(HOSTCC_STAT_COAL_TICKS, 0); } @@ -5094,6 +5094,22 @@ static void tg3_set_bdinfo(struct tg3 *t } static void __tg3_set_rx_mode(struct net_device *); +static void tg3_set_coalesce(struct tg3 *tp, struct ethtool_coalesce *ec) +{ + tw32(HOSTCC_RXCOL_TICKS, ec->rx_coalesce_usecs); + tw32(HOSTCC_TXCOL_TICKS, ec->tx_coalesce_usecs); + tw32(HOSTCC_RXMAX_FRAMES, ec->rx_max_coalesced_frames); + tw32(HOSTCC_TXMAX_FRAMES, ec->tx_max_coalesced_frames); + if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { + tw32(HOSTCC_RXCOAL_TICK_INT, ec->rx_coalesce_usecs_irq); + tw32(HOSTCC_TXCOAL_TICK_INT, ec->tx_coalesce_usecs_irq); + } + tw32(HOSTCC_RXCOAL_MAXF_INT, ec->rx_max_coalesced_frames_irq); + tw32(HOSTCC_TXCOAL_MAXF_INT, ec->tx_max_coalesced_frames_irq); + if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) + tw32(HOSTCC_STAT_COAL_TICKS, + ec->stats_block_coalesce_usecs); +} /* tp->lock is held. */ static int tg3_reset_hw(struct tg3 *tp) @@ -5416,16 +5432,7 @@ static int tg3_reset_hw(struct tg3 *tp) udelay(10); } - tw32(HOSTCC_RXCOL_TICKS, 0); - tw32(HOSTCC_TXCOL_TICKS, LOW_TXCOL_TICKS); - tw32(HOSTCC_RXMAX_FRAMES, 1); - tw32(HOSTCC_TXMAX_FRAMES, LOW_RXMAX_FRAMES); - if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { - tw32(HOSTCC_RXCOAL_TICK_INT, 0); - tw32(HOSTCC_TXCOAL_TICK_INT, 0); - } - tw32(HOSTCC_RXCOAL_MAXF_INT, 1); - tw32(HOSTCC_TXCOAL_MAXF_INT, 0); + tg3_set_coalesce(tp, &tp->coal); /* set status block DMA address */ tw32(HOSTCC_STATUS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, @@ -5438,8 +5445,6 @@ static int tg3_reset_hw(struct tg3 *tp) * the tg3_periodic_fetch_stats call there, and * tg3_get_stats to see how this works for 5705/5750 chips. */ - tw32(HOSTCC_STAT_COAL_TICKS, - DEFAULT_STAT_COAL_TICKS); tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, ((u64) tp->stats_mapping >> 32)); tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_LOW, @@ -7284,6 +7289,14 @@ static void tg3_vlan_rx_kill_vid(struct } #endif +static int tg3_get_coalesce(struct net_device *dev, struct ethtool_coalesce *ec) +{ + struct tg3 *tp = netdev_priv(dev); + + memcpy(ec, &tp->coal, sizeof(*ec)); + return 0; +} + static struct ethtool_ops tg3_ethtool_ops = { .get_settings = tg3_get_settings, .set_settings = tg3_set_settings, @@ -7316,6 +7329,7 @@ static struct ethtool_ops tg3_ethtool_op .get_strings = tg3_get_strings, .get_stats_count = tg3_get_stats_count, .get_ethtool_stats = tg3_get_ethtool_stats, + .get_coalesce = tg3_get_coalesce, }; static void __devinit tg3_get_eeprom_size(struct tg3 *tp) @@ -9096,6 +9110,31 @@ static struct pci_dev * __devinit tg3_fi return peer; } +static void __devinit tg3_init_coal(struct tg3 *tp) +{ + struct ethtool_coalesce *ec = &tp->coal; + + memset(ec, 0, sizeof(*ec)); + ec->cmd = ETHTOOL_GCOALESCE; + ec->rx_coalesce_usecs = LOW_RXCOL_TICKS; + ec->tx_coalesce_usecs = LOW_TXCOL_TICKS; + ec->rx_max_coalesced_frames = LOW_RXMAX_FRAMES; + ec->tx_max_coalesced_frames = LOW_TXMAX_FRAMES; + ec->rx_coalesce_usecs_irq = DEFAULT_RXCOAL_TICK_INT; + ec->tx_coalesce_usecs_irq = DEFAULT_TXCOAL_TICK_INT; + ec->rx_max_coalesced_frames_irq = DEFAULT_RXCOAL_MAXF_INT; + ec->tx_max_coalesced_frames_irq = DEFAULT_TXCOAL_MAXF_INT; + ec->stats_block_coalesce_usecs = DEFAULT_STAT_COAL_TICKS; + + if (tp->coalesce_mode & (HOSTCC_MODE_CLRTICK_RXBD | + HOSTCC_MODE_CLRTICK_TXBD)) { + ec->rx_coalesce_usecs = LOW_RXCOL_TICKS_CLRTCKS; + ec->rx_coalesce_usecs_irq = DEFAULT_RXCOAL_TICK_INT_CLRTCKS; + ec->tx_coalesce_usecs = LOW_TXCOL_TICKS_CLRTCKS; + ec->tx_coalesce_usecs_irq = DEFAULT_TXCOAL_TICK_INT_CLRTCKS; + } +} + static int __devinit tg3_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -9341,6 +9380,8 @@ static int __devinit tg3_init_one(struct /* flow control autonegotiation is default behavior */ tp->tg3_flags |= TG3_FLAG_PAUSE_AUTONEG; + tg3_init_coal(tp); + err = register_netdev(dev); if (err) { printk(KERN_ERR PFX "Cannot register net device, " --- 1/drivers/net/tg3.h.~1~ 2005-05-11 11:46:11.000000000 -0700 +++ 2/drivers/net/tg3.h 2005-05-11 13:48:14.000000000 -0700 @@ -876,10 +876,12 @@ #define HOSTCC_STATUS_ERROR_ATTN 0x00000004 #define HOSTCC_RXCOL_TICKS 0x00003c08 #define LOW_RXCOL_TICKS 0x00000032 +#define LOW_RXCOL_TICKS_CLRTCKS 0x00000014 #define DEFAULT_RXCOL_TICKS 0x00000048 #define HIGH_RXCOL_TICKS 0x00000096 #define HOSTCC_TXCOL_TICKS 0x00003c0c #define LOW_TXCOL_TICKS 0x00000096 +#define LOW_TXCOL_TICKS_CLRTCKS 0x00000048 #define DEFAULT_TXCOL_TICKS 0x0000012c #define HIGH_TXCOL_TICKS 0x00000145 #define HOSTCC_RXMAX_FRAMES 0x00003c10 @@ -892,8 +894,10 @@ #define HIGH_TXMAX_FRAMES 0x00000052 #define HOSTCC_RXCOAL_TICK_INT 0x00003c18 #define DEFAULT_RXCOAL_TICK_INT 0x00000019 +#define DEFAULT_RXCOAL_TICK_INT_CLRTCKS 0x00000014 #define HOSTCC_TXCOAL_TICK_INT 0x00003c1c #define DEFAULT_TXCOAL_TICK_INT 0x00000019 +#define DEFAULT_TXCOAL_TICK_INT_CLRTCKS 0x00000014 #define HOSTCC_RXCOAL_MAXF_INT 0x00003c20 #define DEFAULT_RXCOAL_MAXF_INT 0x00000005 #define HOSTCC_TXCOAL_MAXF_INT 0x00003c24 @@ -2227,7 +2231,7 @@ struct tg3 { #define SST_25VF0X0_PAGE_SIZE 4098 - + struct ethtool_coalesce coal; }; #endif /* !(_T3_H) */ From herbert@gondor.apana.org.au Wed May 11 14:40:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 14:41:06 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BLedOv005144 for ; Wed, 11 May 2005 14:40:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DVyvb-0001Ee-00; Thu, 12 May 2005 07:39:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DVyuq-0005Sf-00; Thu, 12 May 2005 07:38:52 +1000 From: Herbert Xu To: marcelo.tosatti@cyclades.com (Marcelo Tosatti) Subject: Re: 2.4.30-hf1 do_IRQ stack overflows Cc: manfred99@gmx.ch, linux-kernel@vger.kernel.org, davem@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050511124640.GE8541@logos.cnet> X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 12 May 2005 07:38:52 +1000 X-archive-position: 1014 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 740 Lines: 14 Marcelo Tosatti wrote: > > May 11 04:22:09 server kernel: [__switch_to+82/256] [schedule+738/1344] [schedule_timeout+84/160] [process_timeout+0/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294702743/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294703097/96] The stack trace becomes unreadable at this point. Please run klogd with -X and then decode the messages with ksymoops. Alternatively run ksymoops on the output of dmesg directly. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tommy.christensen@tpack.net Wed May 11 15:15:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 15:15:49 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4BMFhOv006438 for ; Wed, 11 May 2005 15:15:44 -0700 Received: (qmail 30053 invoked from network); 11 May 2005 22:15:13 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.3) by 0 with SMTP; 11 May 2005 22:15:13 -0000 Message-ID: <4282846F.6070403@tpack.net> Date: Thu, 12 May 2005 00:17:19 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: Ken-ichirou MATSUZAWA , netdev@oss.sgi.com, "David S. Miller" Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> <20050510220751.GA459@gondor.apana.org.au> <20050511005836.GA1674@gondor.apana.org.au> In-Reply-To: <20050511005836.GA1674@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------060109090905070101010608" X-archive-position: 1016 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 1877 Lines: 50 This is a multi-part message in MIME format. --------------060109090905070101010608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > I think I understand your patch now. What's happening is that > > 1) The skb is sent to socket 1. > 2) Someone does a recvmsg on socket 1 and drops the ref on the skb. > Note that the rmalloc is not returned at this point since the > skb is still referenced. > 3) The same skb is now sent to socket 2. Ahh, even I get the point now. I actually thought this was caused by another race. More on that later. > I agree with your solution except that we should still do the skb_get > if we can. Here is my version where we only do the skb_get at the > start. What about an alternative fix, that avoids even more cloning (where possible)? This resurrects the skb_orphan call that was moved out, last time we had 'shared-skb troubles'. It is practically a no-op in the common case, but still prevents the possible race with recvmsg. (And I have a weakness for one-line-fixes). :-) Signed-off-by: Tommy S. Christensen --------------060109090905070101010608 Content-Type: text/plain; name="netlink-1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink-1.patch" diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c --- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200 +++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 00:08:33.634344658 +0200 @@ -697,6 +697,7 @@ if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf && !test_bit(0, &nlk->state)) { + skb_orphan(skb); skb_set_owner_r(skb, sk); skb_queue_tail(&sk->sk_receive_queue, skb); sk->sk_data_ready(sk, skb->len); --------------060109090905070101010608-- From pavel@ucw.cz Wed May 11 15:14:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 15:14:06 -0700 (PDT) Received: from amd.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BMDuOv006274 for ; Wed, 11 May 2005 15:13:59 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 0E0298D0F7; Wed, 11 May 2005 23:43:07 +0200 (CEST) Date: Wed, 11 May 2005 23:43:07 +0200 From: Pavel Machek To: jketreno@linux.intel.com Cc: kernel list , netdev@oss.sgi.com Subject: kill unused define in ipw Message-ID: <20050511214307.GA3777@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.6+20040907i X-archive-position: 1015 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@ucw.cz Precedence: bulk X-list: netdev Content-Length: 919 Lines: 33 Hi! This kills unused KILL_CHECK_THRESHOLD and KERNEL_SYSCALLS. They should not be needed any more. Please apply, [What is the merge status? Version 1.1 seems quite okay, but it could use some "#ifdef 2.6.10" removal". Can I help?] Pavel PS: Please Cc me, I'm not on netdev. Signed-off-by: Pavel Machek --- /data/l/clean-mm/drivers/net/wireless/ipw2100.c 2005-05-11 22:00:02.000000000 +0200 +++ linux-mm/drivers/net/wireless/ipw2100.c 2005-05-11 23:37:25.000000000 +0200 @@ -150,7 +150,6 @@ #include #include #include -#define __KERNEL_SYSCALLS__ #include #include #include @@ -1117,7 +1116,6 @@ { #define MAX_RF_KILL_CHECKS 5 #define RF_KILL_CHECK_DELAY 40 -#define RF_KILL_CHECK_THRESHOLD 3 unsigned short value = 0; u32 reg = 0; -- Boycott Kodak -- for their patent abuse against Java. From mchan@broadcom.com Wed May 11 15:16:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 15:16:14 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BMGAOv006572 for ; Wed, 11 May 2005 15:16:10 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Wed, 11 May 2005 15:16:11 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 11 May 2005 15:15:32 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AXT33576; Wed, 11 May 2005 15:15:28 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA20888; Wed, 11 May 2005 15:15:28 -0700 (PDT) Received: from 10.7.19.105 ([10.7.19.105]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 May 2005 22:15:27 +0000 Received: from rh4 by nt-irva-0741; 11 May 2005 14:17:36 -0700 Subject: Re: [TG3]: Add hw coalescing infrastructure. From: "Michael Chan" To: "David S.Miller" cc: netdev@oss.sgi.com In-Reply-To: <20050511.141530.57445142.davem@davemloft.net> References: <20050511.141530.57445142.davem@davemloft.net> Date: Wed, 11 May 2005 14:17:36 -0700 Message-ID: <1115846256.8570.109.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E9C5BA11MW4057376-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1017 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1272 Lines: 32 On Wed, 2005-05-11 at 14:15 -0700, David S.Miller wrote: > It seems that we should also be avoiding the HOSTCC_{R,T}XCOAL_MAXF_INT > registers when TG3_FLG2_5705_PLUS. I didn't make that change yet, just > preserving what we were doing previously. These registers are still defined for 5705_PLUS chips, only the maximum value has been reduced to 255. So we're ok. > > Another thing which occurred to me is that these settings are line > rate dependant. For example, the 20 usec value is for gigabit. > So we may wish to adjust the values we use based upon the negotiated > line speed. But that's a future refinement that can wait. > Yes, and MTU size dependent too. But we may not want to coalesce the same way when running at 10/100 Mbps. For example, if one packet has arrived, we don't want to wait 120 usec or 1200 usec to see if another packet will arrive before we interrupt at 100 and 10 Mbps respectively. > I think with the removal of that I/O readback done by the tagged > status changes, and this coalescing stuff below, the SGI NUMA > performance should be significantly higher. > > Comments? Other than adding a check for netif_carrier_ok() before setting the HOSTCC_STAT_COAL_TICKS register in tg3_set_coalesce(), everything looks good to me. From tommy.christensen@tpack.net Wed May 11 15:17:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 15:17:28 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4BMHMOv007402 for ; Wed, 11 May 2005 15:17:23 -0700 Received: (qmail 30324 invoked from network); 11 May 2005 22:16:56 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.3) by 0 with SMTP; 11 May 2005 22:16:56 -0000 Message-ID: <428284D6.9000804@tpack.net> Date: Thu, 12 May 2005 00:19:02 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" , Herbert Xu CC: netdev@oss.sgi.com, Ken-ichirou MATSUZAWA Subject: [PATCH] netlink: defer socket destruction a bit Content-Type: multipart/mixed; boundary="------------030308070803010407050700" X-archive-position: 1018 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 1373 Lines: 42 This is a multi-part message in MIME format. --------------030308070803010407050700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In netlink_broadcast() we're sending shared skb's to netlink listeners when possible (saves some copying). This is OK, since we hold the only other reference to the skb. However, this implies that we must drop our reference on the skb, before allowing a receiving socket to disappear. Otherwise, the socket buffer accounting is disrupted. Signed-off-by: Tommy S. Christensen --------------030308070803010407050700 Content-Type: text/plain; name="netlink-2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink-2.patch" diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c --- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200 +++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 00:11:08.990990172 +0200 @@ -785,11 +785,12 @@ sk_for_each_bound(sk, node, &nl_table[ssk->sk_protocol].mc_list) do_one_broadcast(sk, &info); + kfree_skb(skb); + netlink_unlock_table(); if (info.skb2) kfree_skb(info.skb2); - kfree_skb(skb); if (info.delivered) { if (info.congested && (allocation & __GFP_WAIT)) --------------030308070803010407050700-- From herbert@gondor.apana.org.au Wed May 11 15:22:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 15:22:52 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BMMkOv008371 for ; Wed, 11 May 2005 15:22:47 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DVzan-0001Zo-00; Thu, 12 May 2005 08:22:13 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DVzak-0005Xc-00; Thu, 12 May 2005 08:22:10 +1000 Date: Thu, 12 May 2005 08:22:10 +1000 To: Tommy Christensen Cc: Ken-ichirou MATSUZAWA , netdev@oss.sgi.com, "David S. Miller" Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Message-ID: <20050511222210.GA21280@gondor.apana.org.au> References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> <20050510220751.GA459@gondor.apana.org.au> <20050511005836.GA1674@gondor.apana.org.au> <4282846F.6070403@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4282846F.6070403@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1019 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 807 Lines: 22 On Thu, May 12, 2005 at 12:17:19AM +0200, Tommy Christensen wrote: > > I actually thought this was caused by another race. More on that later. Please elaborate. > What about an alternative fix, that avoids even more cloning (where > possible)? This resurrects the skb_orphan call that was moved out, last > time we had 'shared-skb troubles'. It is practically a no-op in the > common case, but still prevents the possible race with recvmsg. > (And I have a weakness for one-line-fixes). :-) Yep this is much better. Thanks Tommy. Acked-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Wed May 11 15:24:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 15:24:59 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BMOsOv008788 for ; Wed, 11 May 2005 15:24:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DVzcs-0001bZ-00; Thu, 12 May 2005 08:24:22 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DVzcr-0005YU-00; Thu, 12 May 2005 08:24:21 +1000 Date: Thu, 12 May 2005 08:24:21 +1000 To: Tommy Christensen Cc: "David S. Miller" , netdev@oss.sgi.com, Ken-ichirou MATSUZAWA Subject: Re: [PATCH] netlink: defer socket destruction a bit Message-ID: <20050511222421.GA21331@gondor.apana.org.au> References: <428284D6.9000804@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428284D6.9000804@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1020 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 858 Lines: 25 On Thu, May 12, 2005 at 12:19:02AM +0200, Tommy Christensen wrote: > > diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c > --- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200 > +++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 00:11:08.990990172 +0200 > @@ -785,11 +785,12 @@ > sk_for_each_bound(sk, node, &nl_table[ssk->sk_protocol].mc_list) > do_one_broadcast(sk, &info); > > + kfree_skb(skb); > + > netlink_unlock_table(); > > if (info.skb2) > kfree_skb(info.skb2); > - kfree_skb(skb); Good catch. But doesn't this affect skb2 as well? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From pavel@ucw.cz Wed May 11 15:28:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 15:28:22 -0700 (PDT) Received: from amd.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BMS4Ov009409 for ; Wed, 11 May 2005 15:28:06 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 8611B8D0F9; Thu, 12 May 2005 00:05:22 +0200 (CEST) Date: Thu, 12 May 2005 00:05:22 +0200 From: Pavel Machek To: jketreno@linux.intel.com, netdev@oss.sgi.com, kernel list Subject: ipw2100: invasive cleanups Message-ID: <20050511220522.GA4357@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.6+20040907i X-archive-position: 1021 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@ucw.cz Precedence: bulk X-list: netdev Content-Length: 22444 Lines: 942 Hi! Here are some more invasive cleanups for ipw2100... I do not know what X__ prefixes were meant for. I removed them. Along with some debugging infrastructure and tests for obsolete kernels. Maybe this makes it more acceptable at least for -mm tree? Oh BTW DRV_COPYRIGHT probably needs an update, its 2005 now :-). Pavel --- /data/l/clean-mm/drivers/net/wireless/ipw2100.c 2005-05-11 22:00:02.000000000 +0200 +++ linux-mm/drivers/net/wireless/ipw2100.c 2005-05-11 23:58:20.000000000 +0200 @@ -106,7 +106,7 @@ tx_pend_list : Holds used Tx buffers waiting to go into the TBD ring TAIL modified ipw2100_tx() - HEAD modified by X__ipw2100_tx_send_data() + HEAD modified by ipw2100_tx_send_data() msg_free_list : Holds pre-allocated Msg (Command) buffers TAIL modified in __ipw2100_tx_process() @@ -114,7 +114,7 @@ msg_pend_list : Holds used Msg buffers waiting to go into the TBD ring TAIL modified in ipw2100_hw_send_command() - HEAD modified in X__ipw2100_tx_send_commands() + HEAD modified in ipw2100_tx_send_commands() The flow of data on the TX side is as follows: @@ -150,7 +150,6 @@ #include #include #include -#define __KERNEL_SYSCALLS__ #include #include #include @@ -174,11 +173,6 @@ #define DRV_COPYRIGHT "Copyright(c) 2003-2004 Intel Corporation" -/* Debugging stuff */ -#ifdef CONFIG_IPW_DEBUG -#define CONFIG_IPW2100_RX_DEBUG /* Reception debugging */ -#endif - MODULE_DESCRIPTION(DRV_DESCRIPTION); MODULE_VERSION(DRV_VERSION); MODULE_AUTHOR(DRV_COPYRIGHT); @@ -189,9 +183,7 @@ static int channel = 0; static int associate = 1; static int disable = 0; -#ifdef CONFIG_PM static struct ipw2100_fw ipw2100_firmware; -#endif #include module_param(debug, int, 0444); @@ -286,8 +278,8 @@ /* Pre-decl until we get the code solid and then we can clean it up */ -static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv); -static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv); +static void ipw2100_tx_send_commands(struct ipw2100_priv *priv); +static void ipw2100_tx_send_data(struct ipw2100_priv *priv); static int ipw2100_adapter_setup(struct ipw2100_priv *priv); static void ipw2100_queues_initialize(struct ipw2100_priv *priv); @@ -735,8 +727,8 @@ list_add_tail(element, &priv->msg_pend_list); INC_STAT(&priv->msg_pend_stat); - X__ipw2100_tx_send_commands(priv); - X__ipw2100_tx_send_data(priv); + ipw2100_tx_send_commands(priv); + ipw2100_tx_send_data(priv); spin_unlock_irqrestore(&priv->low_lock, flags); @@ -915,12 +907,10 @@ if (i == 10000) return -EIO; /* TODO: better error value */ -//#if CONFIG_IPW2100_D0ENABLED /* set D0 standby bit */ read_register(priv->net_dev, IPW_REG_GP_CNTRL, &r); write_register(priv->net_dev, IPW_REG_GP_CNTRL, r | IPW_AUX_HOST_GP_CNTRL_BIT_HOST_ALLOWS_STANDBY); -//#endif return 0; } @@ -940,11 +930,8 @@ { u32 address; int err; - -#ifndef CONFIG_PM /* Fetch the firmware and microcode */ struct ipw2100_fw ipw2100_firmware; -#endif if (priv->fatal_error) { IPW_DEBUG_ERROR("%s: ipw2100_download_firmware called after " @@ -953,7 +940,6 @@ return -EINVAL; } -#ifdef CONFIG_PM if (!ipw2100_firmware.version) { err = ipw2100_get_firmware(priv, &ipw2100_firmware); if (err) { @@ -963,15 +949,6 @@ goto fail; } } -#else - err = ipw2100_get_firmware(priv, &ipw2100_firmware); - if (err) { - IPW_DEBUG_ERROR("%s: ipw2100_get_firmware failed: %d\n", - priv->net_dev->name, err); - priv->fatal_error = IPW2100_ERR_FW_LOAD; - goto fail; - } -#endif priv->firmware_version = ipw2100_firmware.version; /* s/w reset and clock stabilization */ @@ -1026,7 +1003,6 @@ goto fail; } -#ifndef CONFIG_PM /* * When the .resume method of the driver is called, the other * part of the system, i.e. the ide driver could still stay in @@ -1036,7 +1012,6 @@ /* free any storage allocated for firmware image */ ipw2100_release_firmware(priv, &ipw2100_firmware); -#endif /* zero out Domain 1 area indirectly (Si requirement) */ for (address = IPW_HOST_FW_SHARED_AREA0; @@ -1083,8 +1058,6 @@ { struct ipw2100_ordinals *ord = &priv->ordinals; - IPW_DEBUG_INFO("enter\n"); - read_register(priv->net_dev, IPW_MEM_HOST_SHARED_ORDINALS_TABLE_1, &ord->table1_addr); @@ -1095,10 +1068,6 @@ read_nic_dword(priv->net_dev, ord->table2_addr, &ord->table2_size); ord->table2_size &= 0x0000FFFF; - - IPW_DEBUG_INFO("table 1 size: %d\n", ord->table1_size); - IPW_DEBUG_INFO("table 2 size: %d\n", ord->table2_size); - IPW_DEBUG_INFO("exit\n"); } static inline void ipw2100_hw_set_gpio(struct ipw2100_priv *priv) @@ -1117,7 +1086,6 @@ { #define MAX_RF_KILL_CHECKS 5 #define RF_KILL_CHECK_DELAY 40 -#define RF_KILL_CHECK_THRESHOLD 3 unsigned short value = 0; u32 reg = 0; @@ -1198,8 +1166,6 @@ int i; u32 inta, inta_mask, gpio; - IPW_DEBUG_INFO("enter\n"); - if (priv->status & STATUS_RUNNING) return 0; @@ -1286,9 +1252,6 @@ /* The adapter has been reset; we are not associated */ priv->status &= ~(STATUS_ASSOCIATING | STATUS_ASSOCIATED); - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -1598,8 +1561,6 @@ }; int err; - IPW_DEBUG_INFO("enter\n"); - IPW_DEBUG_SCAN("setting scan options\n"); cmd.host_command_parameters[0] = 0; @@ -1643,8 +1604,6 @@ return 0; } - IPW_DEBUG_INFO("enter\n"); - /* Not clearing here; doing so makes iwlist always return nothing... * * We should modify the table logic to use aging tables vs. clearing @@ -1657,8 +1616,6 @@ if (err) priv->status &= ~STATUS_SCANNING; - IPW_DEBUG_INFO("exit\n"); - return err; } @@ -2285,18 +2242,10 @@ * The size of the constructed ethernet * */ -#ifdef CONFIG_IPW2100_RX_DEBUG -u8 packet_data[IPW_RX_NIC_BUFFER_LENGTH]; -#endif static inline void ipw2100_corruption_detected(struct ipw2100_priv *priv, int i) { -#ifdef CONFIG_IPW_DEBUG_C3 - struct ipw2100_status *status = &priv->status_queue.drv[i]; - u32 match, reg; - int j; -#endif #ifdef ACPI_CSTATE_LIMIT_DEFINED int limit; #endif @@ -2314,35 +2263,6 @@ } #endif -#ifdef CONFIG_IPW_DEBUG_C3 - /* Halt the fimrware so we can get a good image */ - write_register(priv->net_dev, IPW_REG_RESET_REG, - IPW_AUX_HOST_RESET_REG_STOP_MASTER); - j = 5; - do { - udelay(IPW_WAIT_RESET_MASTER_ASSERT_COMPLETE_DELAY); - read_register(priv->net_dev, IPW_REG_RESET_REG, ®); - - if (reg & IPW_AUX_HOST_RESET_REG_MASTER_DISABLED) - break; - } while (j--); - - match = ipw2100_match_buf(priv, (u8*)status, - sizeof(struct ipw2100_status), - SEARCH_SNAPSHOT); - if (match < SEARCH_SUCCESS) - IPW_DEBUG_INFO("%s: DMA status match in Firmware at " - "offset 0x%06X, length %d:\n", - priv->net_dev->name, match, - sizeof(struct ipw2100_status)); - else - IPW_DEBUG_INFO("%s: No DMA status match in " - "Firmware.\n", priv->net_dev->name); - - printk_buf((u8*)priv->status_queue.drv, - sizeof(struct ipw2100_status) * RX_QUEUE_LENGTH); -#endif - priv->fatal_error = IPW2100_ERR_C3_CORRUPTION; priv->ieee->stats.rx_errors++; schedule_reset(priv); @@ -2394,19 +2314,7 @@ skb_put(packet->skb, status->frame_size); -#ifdef CONFIG_IPW2100_RX_DEBUG - /* Make a copy of the frame so we can dump it to the logs if - * ieee80211_rx fails */ - memcpy(packet_data, packet->skb->data, - min(status->frame_size, IPW_RX_NIC_BUFFER_LENGTH)); -#endif - if (!ieee80211_rx(priv->ieee, packet->skb, stats)) { -#ifdef CONFIG_IPW2100_RX_DEBUG - IPW_DEBUG_DROP("%s: Non consumed packet:\n", - priv->net_dev->name); - printk_buf(IPW_DL_DROP, packet_data, status->frame_size); -#endif priv->ieee->stats.rx_errors++; /* ieee80211_rx failed, so it didn't free the SKB */ @@ -2847,7 +2755,7 @@ } -static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv) +static void ipw2100_tx_send_commands(struct ipw2100_priv *priv) { struct list_head *element; struct ipw2100_tx_packet *packet; @@ -2915,10 +2823,10 @@ /* - * X__ipw2100_tx_send_data + * ipw2100_tx_send_data * */ -static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv) +static void ipw2100_tx_send_data(struct ipw2100_priv *priv) { struct list_head *element; struct ipw2100_tx_packet *packet; @@ -3133,8 +3041,8 @@ IPW2100_INTA_TX_TRANSFER); __ipw2100_tx_complete(priv); - X__ipw2100_tx_send_commands(priv); - X__ipw2100_tx_send_data(priv); + ipw2100_tx_send_commands(priv); + ipw2100_tx_send_data(priv); } if (inta & IPW2100_INTA_TX_COMPLETE) { @@ -3192,8 +3100,6 @@ ipw2100_enable_interrupts(priv); spin_unlock_irqrestore(&priv->low_lock, flags); - - IPW_DEBUG_ISR("exit\n"); } @@ -3285,7 +3191,7 @@ list_add_tail(element, &priv->tx_pend_list); INC_STAT(&priv->tx_pend_stat); - X__ipw2100_tx_send_data(priv); + ipw2100_tx_send_data(priv); spin_unlock_irqrestore(&priv->low_lock, flags); return 0; @@ -3662,96 +3568,6 @@ } static DEVICE_ATTR(hardware, S_IRUGO, show_hardware, NULL); - -static ssize_t show_memory(struct device *d, char *buf) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - struct net_device *dev = priv->net_dev; - static unsigned long loop = 0; - int len = 0; - u32 buffer[4]; - int i; - char line[81]; - - if (loop >= 0x30000) - loop = 0; - - /* sysfs provides us PAGE_SIZE buffer */ - while (len < PAGE_SIZE - 128 && loop < 0x30000) { - - if (priv->snapshot[0]) for (i = 0; i < 4; i++) - buffer[i] = *(u32 *)SNAPSHOT_ADDR(loop + i * 4); - else for (i = 0; i < 4; i++) - read_nic_dword(dev, loop + i * 4, &buffer[i]); - - if (priv->dump_raw) - len += sprintf(buf + len, - "%c%c%c%c" - "%c%c%c%c" - "%c%c%c%c" - "%c%c%c%c", - ((u8*)buffer)[0x0], - ((u8*)buffer)[0x1], - ((u8*)buffer)[0x2], - ((u8*)buffer)[0x3], - ((u8*)buffer)[0x4], - ((u8*)buffer)[0x5], - ((u8*)buffer)[0x6], - ((u8*)buffer)[0x7], - ((u8*)buffer)[0x8], - ((u8*)buffer)[0x9], - ((u8*)buffer)[0xa], - ((u8*)buffer)[0xb], - ((u8*)buffer)[0xc], - ((u8*)buffer)[0xd], - ((u8*)buffer)[0xe], - ((u8*)buffer)[0xf]); - else - len += sprintf(buf + len, "%s\n", - snprint_line(line, sizeof(line), - (u8*)buffer, 16, loop)); - loop += 16; - } - - return len; -} - -static ssize_t store_memory(struct device *d, const char *buf, size_t count) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - struct net_device *dev = priv->net_dev; - const char *p = buf; - - if (count < 1) - return count; - - if (p[0] == '1' || - (count >= 2 && tolower(p[0]) == 'o' && tolower(p[1]) == 'n')) { - IPW_DEBUG_INFO("%s: Setting memory dump to RAW mode.\n", - dev->name); - priv->dump_raw = 1; - - } else if (p[0] == '0' || (count >= 2 && tolower(p[0]) == 'o' && - tolower(p[1]) == 'f')) { - IPW_DEBUG_INFO("%s: Setting memory dump to HEX mode.\n", - dev->name); - priv->dump_raw = 0; - - } else if (tolower(p[0]) == 'r') { - IPW_DEBUG_INFO("%s: Resetting firmware snapshot.\n", - dev->name); - ipw2100_snapshot_free(priv); - - } else - IPW_DEBUG_INFO("%s: Usage: 0|on = HEX, 1|off = RAW, " - "reset = clear memory snapshot\n", - dev->name); - - return count; -} -static DEVICE_ATTR(memory, S_IWUSR|S_IRUGO, show_memory, store_memory); - - static ssize_t show_ordinals(struct device *d, char *buf) { struct ipw2100_priv *priv = dev_get_drvdata(d); @@ -3837,11 +3653,9 @@ priv->ieee->iw_mode = mode; -#ifdef CONFIG_PM /* Indicate ipw2100_download_firmware download firmware * from disk instead of memory. */ ipw2100_firmware.version = 0; -#endif printk(KERN_INFO "%s: Reseting on mode change.\n", priv->net_dev->name); @@ -4030,8 +3844,6 @@ unsigned long val; char *p = buffer; - IPW_DEBUG_INFO("enter\n"); - strncpy(buffer, buf, len); buffer[len] = 0; @@ -4049,8 +3861,6 @@ priv->ieee->scan_age = val; IPW_DEBUG_INFO("set scan_age = %u\n", priv->ieee->scan_age); } - - IPW_DEBUG_INFO("exit\n"); return len; } static DEVICE_ATTR(scan_age, S_IWUSR | S_IRUGO, show_scan_age, store_scan_age); @@ -4117,7 +3927,6 @@ &dev_attr_stats.attr, &dev_attr_internals.attr, &dev_attr_bssinfo.attr, - &dev_attr_memory.attr, &dev_attr_scan_age.attr, &dev_attr_fatal_error.attr, &dev_attr_rf_kill.attr, @@ -4136,8 +3945,6 @@ { struct ipw2100_status_queue *q = &priv->status_queue; - IPW_DEBUG_INFO("enter\n"); - q->size = entries * sizeof(struct ipw2100_status); q->drv = (struct ipw2100_status *)pci_alloc_consistent( priv->pci_dev, q->size, &q->nic); @@ -4148,31 +3955,22 @@ } memset(q->drv, 0, q->size); - - IPW_DEBUG_INFO("exit\n"); - return 0; } static void status_queue_free(struct ipw2100_priv *priv) { - IPW_DEBUG_INFO("enter\n"); - if (priv->status_queue.drv) { pci_free_consistent( priv->pci_dev, priv->status_queue.size, priv->status_queue.drv, priv->status_queue.nic); priv->status_queue.drv = NULL; } - - IPW_DEBUG_INFO("exit\n"); } static int bd_queue_allocate(struct ipw2100_priv *priv, struct ipw2100_bd_queue *q, int entries) { - IPW_DEBUG_INFO("enter\n"); - memset(q, 0, sizeof(struct ipw2100_bd_queue)); q->entries = entries; @@ -4183,17 +3981,12 @@ return -ENOMEM; } memset(q->drv, 0, q->size); - - IPW_DEBUG_INFO("exit\n"); - return 0; } static void bd_queue_free(struct ipw2100_priv *priv, struct ipw2100_bd_queue *q) { - IPW_DEBUG_INFO("enter\n"); - if (!q) return; @@ -4202,24 +3995,18 @@ q->size, q->drv, q->nic); q->drv = NULL; } - - IPW_DEBUG_INFO("exit\n"); } static void bd_queue_initialize( struct ipw2100_priv *priv, struct ipw2100_bd_queue * q, u32 base, u32 size, u32 r, u32 w) { - IPW_DEBUG_INFO("enter\n"); - IPW_DEBUG_INFO("initializing bd queue at virt=%p, phys=%08x\n", q->drv, q->nic); write_register(priv->net_dev, base, q->nic); write_register(priv->net_dev, size, q->entries); write_register(priv->net_dev, r, q->oldest); write_register(priv->net_dev, w, q->next); - - IPW_DEBUG_INFO("exit\n"); } static void ipw2100_kill_workqueue(struct ipw2100_priv *priv) @@ -4243,8 +4030,6 @@ void *v; dma_addr_t p; - IPW_DEBUG_INFO("enter\n"); - err = bd_queue_allocate(priv, &priv->tx_queue, TX_QUEUE_LENGTH); if (err) { IPW_DEBUG_ERROR("%s: failed bd_queue_allocate\n", @@ -4299,8 +4084,6 @@ { int i; - IPW_DEBUG_INFO("enter\n"); - /* * reinitialize packet info lists */ @@ -4339,17 +4122,12 @@ IPW_MEM_HOST_SHARED_TX_QUEUE_BD_SIZE, IPW_MEM_HOST_SHARED_TX_QUEUE_READ_INDEX, IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX); - - IPW_DEBUG_INFO("exit\n"); - } static void ipw2100_tx_free(struct ipw2100_priv *priv) { int i; - IPW_DEBUG_INFO("enter\n"); - bd_queue_free(priv, &priv->tx_queue); if (!priv->tx_buffers) @@ -4370,8 +4148,6 @@ kfree(priv->tx_buffers); priv->tx_buffers = NULL; - - IPW_DEBUG_INFO("exit\n"); } @@ -4380,8 +4156,6 @@ { int i, j, err = -EINVAL; - IPW_DEBUG_INFO("enter\n"); - err = bd_queue_allocate(priv, &priv->rx_queue, RX_QUEUE_LENGTH); if (err) { IPW_DEBUG_INFO("failed bd_queue_allocate\n"); @@ -4448,8 +4222,6 @@ static void ipw2100_rx_initialize(struct ipw2100_priv *priv) { - IPW_DEBUG_INFO("enter\n"); - priv->rx_queue.oldest = 0; priv->rx_queue.available = priv->rx_queue.entries - 1; priv->rx_queue.next = priv->rx_queue.entries - 1; @@ -4466,16 +4238,12 @@ /* set up the status queue */ write_register(priv->net_dev, IPW_MEM_HOST_SHARED_RX_STATUS_BASE, priv->status_queue.nic); - - IPW_DEBUG_INFO("exit\n"); } static void ipw2100_rx_free(struct ipw2100_priv *priv) { int i; - IPW_DEBUG_INFO("enter\n"); - bd_queue_free(priv, &priv->rx_queue); status_queue_free(priv); @@ -4494,8 +4262,6 @@ kfree(priv->rx_buffers); priv->rx_buffers = NULL; - - IPW_DEBUG_INFO("exit\n"); } static int ipw2100_read_mac_address(struct ipw2100_priv *priv) @@ -4536,8 +4302,6 @@ IPW_DEBUG_HC("SET_MAC_ADDRESS\n"); - IPW_DEBUG_INFO("enter\n"); - if (priv->config & CFG_CUSTOM_MAC) { memcpy(cmd.host_command_parameters, priv->mac_addr, ETH_ALEN); @@ -4547,8 +4311,6 @@ ETH_ALEN); err = ipw2100_hw_send_command(priv, &cmd); - - IPW_DEBUG_INFO("exit\n"); return err; } @@ -4805,47 +4567,6 @@ return 0; } -#if 0 -int ipw2100_set_fragmentation_threshold(struct ipw2100_priv *priv, - u32 threshold, int batch_mode) -{ - struct host_command cmd = { - .host_command = FRAG_THRESHOLD, - .host_command_sequence = 0, - .host_command_length = 4, - .host_command_parameters[0] = 0, - }; - int err; - - if (!batch_mode) { - err = ipw2100_disable_adapter(priv); - if (err) - return err; - } - - if (threshold == 0) - threshold = DEFAULT_FRAG_THRESHOLD; - else { - threshold = max(threshold, MIN_FRAG_THRESHOLD); - threshold = min(threshold, MAX_FRAG_THRESHOLD); - } - - cmd.host_command_parameters[0] = threshold; - - IPW_DEBUG_HC("FRAG_THRESHOLD: %u\n", threshold); - - err = ipw2100_hw_send_command(priv, &cmd); - - if (!batch_mode) - ipw2100_enable_adapter(priv); - - if (!err) - priv->frag_threshold = threshold; - - return err; -} -#endif - int ipw2100_set_short_retry(struct ipw2100_priv *priv, u32 retry) { struct host_command cmd = { @@ -4935,8 +4656,6 @@ int err; int len; - IPW_DEBUG_HC("DISASSOCIATION_BSSID\n"); - len = ETH_ALEN; /* The Firmware currently ignores the BSSID and just disassociates from * the currently associated AP -- but in the off chance that a future @@ -4950,37 +4669,6 @@ } #endif -/* - * Pseudo code for setting up wpa_frame: - */ -#if 0 -void x(struct ieee80211_assoc_frame *wpa_assoc) -{ - struct ipw2100_wpa_assoc_frame frame; - frame->fixed_ie_mask = IPW_WPA_CAPABILTIES | - IPW_WPA_LISTENINTERVAL | - IPW_WPA_AP_ADDRESS; - frame->capab_info = wpa_assoc->capab_info; - frame->lisen_interval = wpa_assoc->listent_interval; - memcpy(frame->current_ap, wpa_assoc->current_ap, ETH_ALEN); - - /* UNKNOWN -- I'm not postivive about this part; don't have any WPA - * setup here to test it with. - * - * Walk the IEs in the wpa_assoc and figure out the total size of all - * that data. Stick that into frame->var_ie_len. Then memcpy() all of - * the IEs from wpa_frame into frame. - */ - frame->var_ie_len = calculate_ie_len(wpa_assoc); - memcpy(frame->var_ie, wpa_assoc->variable, frame->var_ie_len); - - ipw2100_set_wpa_ie(priv, &frame, 0); -} -#endif - - - - static int ipw2100_set_wpa_ie(struct ipw2100_priv *, struct ipw2100_wpa_assoc_frame *, int) __attribute__ ((unused)); @@ -4996,8 +4684,6 @@ }; int err; - IPW_DEBUG_HC("SET_WPA_IE\n"); - if (!batch_mode) { err = ipw2100_disable_adapter(priv); if (err) @@ -5123,8 +4809,6 @@ cmd.host_command_parameters[0] = interval; - IPW_DEBUG_INFO("enter\n"); - if (priv->ieee->iw_mode == IW_MODE_ADHOC) { if (!batch_mode) { err = ipw2100_disable_adapter(priv); @@ -5140,9 +4824,6 @@ return err; } } - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -5502,8 +5183,6 @@ int batch_mode = 1; u8 *bssid; - IPW_DEBUG_INFO("enter\n"); - err = ipw2100_disable_adapter(priv); if (err) return err; @@ -5512,9 +5191,6 @@ err = ipw2100_set_channel(priv, priv->channel, batch_mode); if (err) return err; - - IPW_DEBUG_INFO("exit\n"); - return 0; } #endif /* CONFIG_IPW2100_MONITOR */ @@ -5591,9 +5267,6 @@ if (err) return err; */ - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -5656,8 +5329,6 @@ struct list_head *element; struct ipw2100_tx_packet *packet; - IPW_DEBUG_INFO("enter\n"); - spin_lock_irqsave(&priv->low_lock, flags); if (priv->status & STATUS_ASSOCIATED) @@ -5679,9 +5350,6 @@ INC_STAT(&priv->tx_free_stat); } spin_unlock_irqrestore(&priv->low_lock, flags); - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -6440,8 +6108,6 @@ int registered = 0; u32 val; - IPW_DEBUG_INFO("enter\n"); - mem_start = pci_resource_start(pci_dev, 0); mem_len = pci_resource_len(pci_dev, 0); mem_flags = pci_resource_flags(pci_dev, 0); @@ -6589,8 +6255,6 @@ ipw2100_start_scan(priv); } - IPW_DEBUG_INFO("exit\n"); - priv->status |= STATUS_INITIALIZED; up(&priv->action_sem); @@ -6644,10 +6308,9 @@ dev = priv->net_dev; sysfs_remove_group(&pci_dev->dev.kobj, &ipw2100_attribute_group); -#ifdef CONFIG_PM if (ipw2100_firmware.version) ipw2100_release_firmware(priv, &ipw2100_firmware); -#endif + /* Take down the hardware */ ipw2100_down(priv); @@ -6680,17 +6343,11 @@ pci_release_regions(pci_dev); pci_disable_device(pci_dev); - - IPW_DEBUG_INFO("exit\n"); } #ifdef CONFIG_PM -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) -static int ipw2100_suspend(struct pci_dev *pci_dev, u32 state) -#else static int ipw2100_suspend(struct pci_dev *pci_dev, pm_message_t state) -#endif { struct ipw2100_priv *priv = pci_get_drvdata(pci_dev); struct net_device *dev = priv->net_dev; @@ -6707,17 +6364,9 @@ /* Remove the PRESENT state of the device */ netif_device_detach(dev); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) - pci_save_state(pci_dev, priv->pm_state); -#else pci_save_state(pci_dev); -#endif pci_disable_device (pci_dev); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) - pci_set_power_state(pci_dev, state); -#else pci_set_power_state(pci_dev, PCI_D3hot); -#endif up(&priv->action_sem); @@ -6738,17 +6387,9 @@ IPW_DEBUG_INFO("%s: Coming out of suspend...\n", dev->name); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) - pci_set_power_state(pci_dev, 0); -#else pci_set_power_state(pci_dev, PCI_D0); -#endif pci_enable_device(pci_dev); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) - pci_restore_state(pci_dev, priv->pm_state); -#else pci_restore_state(pci_dev); -#endif /* * Suspend/Resume resets the PCI configuration space, so we have to @@ -8295,8 +7936,6 @@ down(&priv->action_sem); - IPW_DEBUG_WX("enter\n"); - up(&priv->action_sem); wrqu.ap_addr.sa_family = ARPHRD_ETHER; -- Boycott Kodak -- for their patent abuse against Java. From tommy.christensen@tpack.net Wed May 11 15:33:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 15:33:30 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4BMXQOv010032 for ; Wed, 11 May 2005 15:33:27 -0700 Received: (qmail 455 invoked from network); 11 May 2005 22:33:00 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.3) by 0 with SMTP; 11 May 2005 22:33:00 -0000 Message-ID: <4282889A.7080409@tpack.net> Date: Thu, 12 May 2005 00:35:06 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com, Ken-ichirou MATSUZAWA Subject: Re: [PATCH] netlink: defer socket destruction a bit References: <428284D6.9000804@tpack.net> <20050511222421.GA21331@gondor.apana.org.au> In-Reply-To: <20050511222421.GA21331@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1022 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 797 Lines: 25 Herbert Xu wrote: > On Thu, May 12, 2005 at 12:19:02AM +0200, Tommy Christensen wrote: > >>diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c >>--- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200 >>+++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 00:11:08.990990172 +0200 >>@@ -785,11 +785,12 @@ >> sk_for_each_bound(sk, node, &nl_table[ssk->sk_protocol].mc_list) >> do_one_broadcast(sk, &info); >> >>+ kfree_skb(skb); >>+ >> netlink_unlock_table(); >> >> if (info.skb2) >> kfree_skb(info.skb2); >>- kfree_skb(skb); > > > Good catch. But doesn't this affect skb2 as well? No, skb2 cannot be shared with a listening socket. As I read the code, it can only be non-null when delivery has failed. -Tommy From herbert@gondor.apana.org.au Wed May 11 16:04:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 16:04:16 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BN3jOv011494 for ; Wed, 11 May 2005 16:03:47 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DW0ES-0001si-00; Thu, 12 May 2005 09:03:12 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DW0EP-0005bw-00; Thu, 12 May 2005 09:03:09 +1000 Date: Thu, 12 May 2005 09:03:09 +1000 To: Tommy Christensen Cc: "David S. Miller" , netdev@oss.sgi.com, Ken-ichirou MATSUZAWA Subject: Re: [PATCH] netlink: defer socket destruction a bit Message-ID: <20050511230309.GA21547@gondor.apana.org.au> References: <428284D6.9000804@tpack.net> <20050511222421.GA21331@gondor.apana.org.au> <4282889A.7080409@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4282889A.7080409@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1023 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 640 Lines: 21 On Thu, May 12, 2005 at 12:35:06AM +0200, Tommy Christensen wrote: > > No, skb2 cannot be shared with a listening socket. As I read the code, > it can only be non-null when delivery has failed. What about this code path: 1) skb2 = skb, refcnt++. 2) Devliered to socket 1. 3) Socket 1 frees skb through recvmsg. 4) skb2 = skb, refcnt++. 5) Delivery fails. Now skb2 is identical to skb and they both refer to socket 1. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Wed May 11 16:18:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 16:18:41 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BNIQOv012194 for ; Wed, 11 May 2005 16:18:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DW0Sf-0001zj-00; Thu, 12 May 2005 09:17:53 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DW0Sd-0005fd-00; Thu, 12 May 2005 09:17:51 +1000 Date: Thu, 12 May 2005 09:17:51 +1000 To: Tommy Christensen Cc: Ken-ichirou MATSUZAWA , netdev@oss.sgi.com, "David S. Miller" Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Message-ID: <20050511231751.GA21781@gondor.apana.org.au> References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> <20050510220751.GA459@gondor.apana.org.au> <20050511005836.GA1674@gondor.apana.org.au> <4282846F.6070403@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4282846F.6070403@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1024 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 732 Lines: 17 On Thu, May 12, 2005 at 12:17:19AM +0200, Tommy Christensen wrote: > > What about an alternative fix, that avoids even more cloning (where > possible)? This resurrects the skb_orphan call that was moved out, last > time we had 'shared-skb troubles'. It is practically a no-op in the > common case, but still prevents the possible race with recvmsg. > (And I have a weakness for one-line-fixes). :-) BTW, we could also move the skb_orphan to the skb_get path since the cloned packets don't need the orphan call. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From shemminger@osdl.org Wed May 11 16:50:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 16:50:27 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4BNoJOv017333 for ; Wed, 11 May 2005 16:50:19 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4BNnfU3028405 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 May 2005 16:49:42 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4BNnecX009733; Wed, 11 May 2005 16:49:40 -0700 Date: Wed, 11 May 2005 16:49:39 -0700 From: Stephen Hemminger To: "David S. Miller" , Baruch Even , Daniele Lacamera , "Angelo Dell'Aera" Cc: netdev@oss.sgi.com Subject: 2.6.12-rc4-tcp2 Message-ID: <20050511164939.1ec95f2f@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1025 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 607 Lines: 28 http://developer.osdl.org/shemminger/patches/2.6.12-rc4-tcp2 Patches that should probably go in 2.6.13. Note: Westwood and Hybla need more debugging and don't seem to work correctly. # stuff to cleanup netif_rx fastroute-stats-remove.diff no-congestion.diff no-throttle.diff bigger-backlog.diff fix-weightp.diff tso-reloaded.patch # TCP congestion infrastructure tcp_infra.patches tcp_bic.patch westwood.patch hstcp.patch hybla.patch vegas.patch h-tcp.patch # Rearrange sk_buff to make room for bigger cb[] # This allows adding ptr for SACK improvement without # more memory skbuff-del-security.patch From arnaldo.melo@gmail.com Wed May 11 17:12:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 17:12:49 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C0ChOv018378 for ; Wed, 11 May 2005 17:12:43 -0700 Received: by zproxy.gmail.com with SMTP id 34so290707nzf for ; Wed, 11 May 2005 17:12:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DTM9eEFveLGgjBNbRyFy3mTT1DIYRX3PanX0CPTiIsH/udCHQaDwB0Yew7A78AE8YSJBZaDxRaF9kT9vzQBOUOiI+dxNUoJeI6jm2fwAe1B2ZeT+NP/zTlWq3C/BIxzV0gwf4C6PxoiQLe7vTkRWzmHF8ST3OA6XEj8BfmAb75Y= Received: by 10.36.148.8 with SMTP id v8mr459509nzd; Wed, 11 May 2005 17:12:17 -0700 (PDT) Received: by 10.36.56.15 with HTTP; Wed, 11 May 2005 17:12:17 -0700 (PDT) Message-ID: <39e6f6c7050511171244fa6661@mail.gmail.com> Date: Wed, 11 May 2005 21:12:17 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@ghostprotocols.net To: Stephen Hemminger Subject: Re: 2.6.12-rc4-tcp2 Cc: "David S. Miller" , Baruch Even , Daniele Lacamera , "Angelo Dell'Aera" , netdev@oss.sgi.com In-Reply-To: <20050511164939.1ec95f2f@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050511164939.1ec95f2f@dxpl.pdx.osdl.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4C0ChOv018378 X-archive-position: 1026 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 908 Lines: 43 On 5/11/05, Stephen Hemminger wrote: > http://developer.osdl.org/shemminger/patches/2.6.12-rc4-tcp2 > > Patches that should probably go in 2.6.13. > Note: Westwood and Hybla need more debugging and don't seem > to work correctly. > > # stuff to cleanup netif_rx > fastroute-stats-remove.diff > no-congestion.diff > no-throttle.diff > bigger-backlog.diff > fix-weightp.diff > > tso-reloaded.patch > > # TCP congestion infrastructure > tcp_infra.patches + /* cleanup private data (optional) */ + void (*destory)(struct tcp_sock *tp); ^^^^^ Typo 8) + /* return slow satrt threshold (required) */ > tcp_bic.patch > westwood.patch > hstcp.patch > hybla.patch > vegas.patch > h-tcp.patch > > # Rearrange sk_buff to make room for bigger cb[] > # This allows adding ptr for SACK improvement without > # more memory > skbuff-del-security.patch > > -- - Arnaldo From davem@davemloft.net Wed May 11 19:29:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 19:29:25 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C2THOv023830 for ; Wed, 11 May 2005 19:29:22 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DW3Qx-0006eF-SV; Wed, 11 May 2005 19:28:19 -0700 Date: Wed, 11 May 2005 19:28:19 -0700 (PDT) Message-Id: <20050511.192819.24336786.davem@davemloft.net> To: mchan@broadcom.com Cc: netdev@oss.sgi.com Subject: Re: [TG3]: Add hw coalescing infrastructure. From: "David S. Miller" In-Reply-To: <1115846256.8570.109.camel@rh4> References: <20050511.141530.57445142.davem@davemloft.net> <1115846256.8570.109.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1027 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 8589 Lines: 236 From: "Michael Chan" Subject: Re: [TG3]: Add hw coalescing infrastructure. Date: Wed, 11 May 2005 14:17:36 -0700 > On Wed, 2005-05-11 at 14:15 -0700, David S.Miller wrote: > > > Another thing which occurred to me is that these settings are line > > rate dependant. For example, the 20 usec value is for gigabit. > > So we may wish to adjust the values we use based upon the negotiated > > line speed. But that's a future refinement that can wait. > > > Yes, and MTU size dependent too. But we may not want to coalesce the > same way when running at 10/100 Mbps. For example, if one packet has > arrived, we don't want to wait 120 usec or 1200 usec to see if another > packet will arrive before we interrupt at 100 and 10 Mbps respectively. That's a good point. I think it would be wise for us to try and come up with a dynamic mitigation algorithm that is as MTU and link speed agnostic as possible. One thing to note is that what we're really trying to do is maximize the amount of work done per interrupt, without unduly adding latency to packet reception. Work done per-interrupt, and maximum latency, are better goals because formulas based upon those values will automatically take differences in CPU and BUS I/O speed into account. > > I think with the removal of that I/O readback done by the tagged > > status changes, and this coalescing stuff below, the SGI NUMA > > performance should be significantly higher. > > > > Comments? > > Other than adding a check for netif_carrier_ok() before setting the > HOSTCC_STAT_COAL_TICKS register in tg3_set_coalesce(), everything looks > good to me. Good catch. Here is the final version. I'm still debating whether to pursue the dynamic mitigation setting idea. I'd like to see some new numbers from the SGI NUMA folks first. I think we certainly should add ETHTOOL_SCOALESCE support. It isn't in there now because I have to think a bit about how to verify the user's settings. As you know, some combinations of values could wedge the driver and cause no interrupts to be generated for TX or RX even when packets are transmitted/received. And there's that 256 limit on 5705_plus chips which you mentioned. [TG3]: Set minimal hw interrupt mitigation. Even though we do software interrupt mitigation via NAPI, it still helps to have some minimal hw assisted mitigation. This helps, particularly, on systems where register I/O overhead is much greater than the CPU horsepower. For example, it helps on NUMA systems. In such cases the PIO overhead to disable interrupts for NAPI accounts for the majority of the packet processing cost. The CPU is fast enough such that only a single packet is processed by each NAPI poll call. Thanks to Michael Chan for reviewing this patch. Signed-off-by: David S. Miller --- 1/drivers/net/tg3.c.~1~ 2005-05-11 11:46:11.000000000 -0700 +++ 2/drivers/net/tg3.c 2005-05-11 19:26:28.000000000 -0700 @@ -2507,7 +2507,7 @@ static int tg3_setup_phy(struct tg3 *tp, if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { if (netif_carrier_ok(tp->dev)) { tw32(HOSTCC_STAT_COAL_TICKS, - DEFAULT_STAT_COAL_TICKS); + tp->coal.stats_block_coalesce_usecs); } else { tw32(HOSTCC_STAT_COAL_TICKS, 0); } @@ -5094,6 +5094,27 @@ static void tg3_set_bdinfo(struct tg3 *t } static void __tg3_set_rx_mode(struct net_device *); +static void tg3_set_coalesce(struct tg3 *tp, struct ethtool_coalesce *ec) +{ + tw32(HOSTCC_RXCOL_TICKS, ec->rx_coalesce_usecs); + tw32(HOSTCC_TXCOL_TICKS, ec->tx_coalesce_usecs); + tw32(HOSTCC_RXMAX_FRAMES, ec->rx_max_coalesced_frames); + tw32(HOSTCC_TXMAX_FRAMES, ec->tx_max_coalesced_frames); + if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { + tw32(HOSTCC_RXCOAL_TICK_INT, ec->rx_coalesce_usecs_irq); + tw32(HOSTCC_TXCOAL_TICK_INT, ec->tx_coalesce_usecs_irq); + } + tw32(HOSTCC_RXCOAL_MAXF_INT, ec->rx_max_coalesced_frames_irq); + tw32(HOSTCC_TXCOAL_MAXF_INT, ec->tx_max_coalesced_frames_irq); + if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { + u32 val = ec->stats_block_coalesce_usecs; + + if (!netif_carrier_ok(tp->dev)) + val = 0; + + tw32(HOSTCC_STAT_COAL_TICKS, val); + } +} /* tp->lock is held. */ static int tg3_reset_hw(struct tg3 *tp) @@ -5416,16 +5437,7 @@ static int tg3_reset_hw(struct tg3 *tp) udelay(10); } - tw32(HOSTCC_RXCOL_TICKS, 0); - tw32(HOSTCC_TXCOL_TICKS, LOW_TXCOL_TICKS); - tw32(HOSTCC_RXMAX_FRAMES, 1); - tw32(HOSTCC_TXMAX_FRAMES, LOW_RXMAX_FRAMES); - if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { - tw32(HOSTCC_RXCOAL_TICK_INT, 0); - tw32(HOSTCC_TXCOAL_TICK_INT, 0); - } - tw32(HOSTCC_RXCOAL_MAXF_INT, 1); - tw32(HOSTCC_TXCOAL_MAXF_INT, 0); + tg3_set_coalesce(tp, &tp->coal); /* set status block DMA address */ tw32(HOSTCC_STATUS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, @@ -5438,8 +5450,6 @@ static int tg3_reset_hw(struct tg3 *tp) * the tg3_periodic_fetch_stats call there, and * tg3_get_stats to see how this works for 5705/5750 chips. */ - tw32(HOSTCC_STAT_COAL_TICKS, - DEFAULT_STAT_COAL_TICKS); tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, ((u64) tp->stats_mapping >> 32)); tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_LOW, @@ -7284,6 +7294,14 @@ static void tg3_vlan_rx_kill_vid(struct } #endif +static int tg3_get_coalesce(struct net_device *dev, struct ethtool_coalesce *ec) +{ + struct tg3 *tp = netdev_priv(dev); + + memcpy(ec, &tp->coal, sizeof(*ec)); + return 0; +} + static struct ethtool_ops tg3_ethtool_ops = { .get_settings = tg3_get_settings, .set_settings = tg3_set_settings, @@ -7316,6 +7334,7 @@ static struct ethtool_ops tg3_ethtool_op .get_strings = tg3_get_strings, .get_stats_count = tg3_get_stats_count, .get_ethtool_stats = tg3_get_ethtool_stats, + .get_coalesce = tg3_get_coalesce, }; static void __devinit tg3_get_eeprom_size(struct tg3 *tp) @@ -9096,6 +9115,31 @@ static struct pci_dev * __devinit tg3_fi return peer; } +static void __devinit tg3_init_coal(struct tg3 *tp) +{ + struct ethtool_coalesce *ec = &tp->coal; + + memset(ec, 0, sizeof(*ec)); + ec->cmd = ETHTOOL_GCOALESCE; + ec->rx_coalesce_usecs = LOW_RXCOL_TICKS; + ec->tx_coalesce_usecs = LOW_TXCOL_TICKS; + ec->rx_max_coalesced_frames = LOW_RXMAX_FRAMES; + ec->tx_max_coalesced_frames = LOW_TXMAX_FRAMES; + ec->rx_coalesce_usecs_irq = DEFAULT_RXCOAL_TICK_INT; + ec->tx_coalesce_usecs_irq = DEFAULT_TXCOAL_TICK_INT; + ec->rx_max_coalesced_frames_irq = DEFAULT_RXCOAL_MAXF_INT; + ec->tx_max_coalesced_frames_irq = DEFAULT_TXCOAL_MAXF_INT; + ec->stats_block_coalesce_usecs = DEFAULT_STAT_COAL_TICKS; + + if (tp->coalesce_mode & (HOSTCC_MODE_CLRTICK_RXBD | + HOSTCC_MODE_CLRTICK_TXBD)) { + ec->rx_coalesce_usecs = LOW_RXCOL_TICKS_CLRTCKS; + ec->rx_coalesce_usecs_irq = DEFAULT_RXCOAL_TICK_INT_CLRTCKS; + ec->tx_coalesce_usecs = LOW_TXCOL_TICKS_CLRTCKS; + ec->tx_coalesce_usecs_irq = DEFAULT_TXCOAL_TICK_INT_CLRTCKS; + } +} + static int __devinit tg3_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -9341,6 +9385,8 @@ static int __devinit tg3_init_one(struct /* flow control autonegotiation is default behavior */ tp->tg3_flags |= TG3_FLAG_PAUSE_AUTONEG; + tg3_init_coal(tp); + err = register_netdev(dev); if (err) { printk(KERN_ERR PFX "Cannot register net device, " --- 1/drivers/net/tg3.h.~1~ 2005-05-11 11:46:11.000000000 -0700 +++ 2/drivers/net/tg3.h 2005-05-11 13:48:14.000000000 -0700 @@ -876,10 +876,12 @@ #define HOSTCC_STATUS_ERROR_ATTN 0x00000004 #define HOSTCC_RXCOL_TICKS 0x00003c08 #define LOW_RXCOL_TICKS 0x00000032 +#define LOW_RXCOL_TICKS_CLRTCKS 0x00000014 #define DEFAULT_RXCOL_TICKS 0x00000048 #define HIGH_RXCOL_TICKS 0x00000096 #define HOSTCC_TXCOL_TICKS 0x00003c0c #define LOW_TXCOL_TICKS 0x00000096 +#define LOW_TXCOL_TICKS_CLRTCKS 0x00000048 #define DEFAULT_TXCOL_TICKS 0x0000012c #define HIGH_TXCOL_TICKS 0x00000145 #define HOSTCC_RXMAX_FRAMES 0x00003c10 @@ -892,8 +894,10 @@ #define HIGH_TXMAX_FRAMES 0x00000052 #define HOSTCC_RXCOAL_TICK_INT 0x00003c18 #define DEFAULT_RXCOAL_TICK_INT 0x00000019 +#define DEFAULT_RXCOAL_TICK_INT_CLRTCKS 0x00000014 #define HOSTCC_TXCOAL_TICK_INT 0x00003c1c #define DEFAULT_TXCOAL_TICK_INT 0x00000019 +#define DEFAULT_TXCOAL_TICK_INT_CLRTCKS 0x00000014 #define HOSTCC_RXCOAL_MAXF_INT 0x00003c20 #define DEFAULT_RXCOAL_MAXF_INT 0x00000005 #define HOSTCC_TXCOAL_MAXF_INT 0x00003c24 @@ -2227,7 +2231,7 @@ struct tg3 { #define SST_25VF0X0_PAGE_SIZE 4098 - + struct ethtool_coalesce coal; }; #endif /* !(_T3_H) */ From imipak@yahoo.com Wed May 11 21:41:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 21:41:08 -0700 (PDT) Received: from web31504.mail.mud.yahoo.com (web31504.mail.mud.yahoo.com [68.142.198.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4C4f6Ov032010 for ; Wed, 11 May 2005 21:41:06 -0700 Received: (qmail 61362 invoked by uid 60001); 12 May 2005 04:40:40 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=219BcwM0gtMtV94kZ9tWrXe6nitggeLcVhnawdlJrOxu86G4NtBc6wo/Ua56OnABMR2HwYpL6zKCOQP/50AZ2V+HSb/7AFyZDR0BeW3yI3TTrRFj8A5d/fu2hLqqWmQ6BtIRXSZeVZofzt8vO46nO8rWqMMY5kl/OilqOYCQwW8= ; Message-ID: <20050512044040.61360.qmail@web31504.mail.mud.yahoo.com> Received: from [65.102.2.8] by web31504.mail.mud.yahoo.com via HTTP; Wed, 11 May 2005 21:40:39 PDT Date: Wed, 11 May 2005 21:40:39 -0700 (PDT) From: Jonathan Day Subject: Questions wrt QoS code on Linux To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1028 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imipak@yahoo.com Precedence: bulk X-list: netdev Content-Length: 986 Lines: 31 Hi, Wondering if someone can answer a few questions on the QoS code in Linux. First off, I notice that all the code is lumped together and much of it is generically labelled "scheduling". I'm wondering if it might not be more readable if the list were divided into four sections - "queueing disciplines", "scheduling", "packet classification" and "everything else". Would that seem sensible? Or would it risk making things over-structured? Secondly, there seem to be an awful lot of QoS methods not represented in Linux. Implementing them all might easily double the kernel size for not very much benefit, even if anyone could find the time to do so. On the other hand, there are probably some that are under development and others high on the wishlist. Does anyone know what projects are currently underway or being planned? Jonathan __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From imipak@yahoo.com Wed May 11 21:47:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 21:47:45 -0700 (PDT) Received: from web31504.mail.mud.yahoo.com (web31504.mail.mud.yahoo.com [68.142.198.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4C4leOv032629 for ; Wed, 11 May 2005 21:47:43 -0700 Received: (qmail 62497 invoked by uid 60001); 12 May 2005 04:47:14 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=gWWoKT5xL8mtEwptkpBcbz5JWWm7/T+v11M7glDzAb+YQOrEyTMTcgu9ncQYsW7GgNCJN+fW1BlRiXZhS4ELr+9O2Dfmlc/ybbXVPRPMCPPcdHtMvb8lYFujT8h0vtquo8M/KYlR1Vuv5Idojc1DjUK9ECQhHWKCMV1hIRz2Et0= ; Message-ID: <20050512044714.62495.qmail@web31504.mail.mud.yahoo.com> Received: from [65.102.2.8] by web31504.mail.mud.yahoo.com via HTTP; Wed, 11 May 2005 21:47:14 PDT Date: Wed, 11 May 2005 21:47:14 -0700 (PDT) From: Jonathan Day Subject: A different question, on SGI's STP for Linux To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1029 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imipak@yahoo.com Precedence: bulk X-list: netdev Content-Length: 716 Lines: 26 Hi, Another quick question, chasing the ones on QoS. At one point, SGI had an intriguing prototype implementation of something called the "Scheduled Transfer Protocol" for Linux. Sadly, this project seems to have vanished into the mists. I -think- I have a copy, somewhere, that I downloaded from the Open Source projects site. I presume, from the fact that nobody else seems to have picked it up, that STP isn't as useful as it sounds. Is it something that would be worth forward-porting to a recent kernel, or is it more of a dead-end approach that can be done as well by other means? Jonathan Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From davem@davemloft.net Wed May 11 22:31:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 22:31:40 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C5VbOv002060 for ; Wed, 11 May 2005 22:31:37 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DW6HM-0007D1-KZ for netdev@oss.sgi.com; Wed, 11 May 2005 22:30:36 -0700 Date: Wed, 11 May 2005 22:30:36 -0700 (PDT) Message-Id: <20050511.223036.39664020.davem@davemloft.net> To: netdev@oss.sgi.com Subject: issue with new TCP TSO stuff From: "David S. Miller" X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1030 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1189 Lines: 28 It's more expensive than the old code. And I know the main reason. There is a higher cost now because we do a large number of page refcount grabs and releases now, that never occurred before. Before, we just cloned and thus grabbed a ref to the whole TSO data area in one go. This shows up in testing where the connection is application limited. For example, an "scp" goes more slowly over TSO now, there are less cpu cycles available for the encryption. It's tricky to come up with a scheme to fix this. I would love to be able to not do the page grabs/releases in the actual TSO frame. I really haven't come up with a clean way to do that however. Basically, if we could somehow delay the freeing of the actual SKBs in the socket write queue until the device frees up the TSO frame, we could avoid the page gets and puts. Almost all the time, this delay would never actually be needed, because the ACKs come back _long_ after the device liberates the TSO frame. But it can due to packet taps, packet reordering, and other reasons. So we do have to handle it. I don't know, maybe we can do something clever with the skb_shinfo(skb)->frag_list pointer. Any bright ideas? :-) From panto@intracom.gr Wed May 11 23:25:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 11 May 2005 23:25:59 -0700 (PDT) Received: from mailserv.intranet.gr (mailserv.intranet.GR [146.124.14.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C6PpOv004181 for ; Wed, 11 May 2005 23:25:53 -0700 Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id j4C6U6xk023532 for ; Thu, 12 May 2005 09:30:08 +0300 (EEST) Received: from ifaistos.intranet.gr (ifaistos.intranet.GR [146.124.20.203]) by mailserv.intranet.gr (8.13.1/8.13.1) with ESMTP id j4C6U37D023501; Thu, 12 May 2005 09:30:03 +0300 (EEST) Received: from [146.124.120.118] (voipkopsias.intranet.GR [146.124.120.118]) by ifaistos.intranet.gr (8.11.7p1+Sun/8.11.7) with ESMTP id j4C6KEe08124; Thu, 12 May 2005 09:20:15 +0300 (EEST) Message-ID: <4282F2EF.4020307@intracom.gr> Date: Thu, 12 May 2005 09:08:47 +0300 From: Pantelis Antoniou User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050328) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Fleming CC: James Chapman , netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org Subject: Re: RFC: PHY Abstraction Layer II References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> <423734FB.40101@katalix.com> <96c50184a02557c88dee0e6d17f3a539@freescale.com> <42625DDB.4090600@katalix.com> <30d87aabd768216ef8bee800f3e09b9e@freescale.com> In-Reply-To: <30d87aabd768216ef8bee800f3e09b9e@freescale.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1031 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: panto@intracom.gr Precedence: bulk X-list: netdev Content-Length: 2102 Lines: 66 Andy Fleming wrote: > > On Apr 17, 2005, at 08:00, James Chapman wrote: > >> Andy Fleming wrote: >> >>> Ok, here's the new patch with changes suggested by James Chapman: >> >> >> I guess I still have questions about the way interrupts are used. >> >> Using an interrupt to schedule a work queue which then sets a variable >> that is used by a timer seems odd. Why not do all the work in the work >> queue and schedule it from the interrupt handler or timer? > > > Ok, I've set up a new system for handling interrupts. There are now two > "special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT. The > first one is used to indicate that the PHY layer will poll the PHY for > state changes, and won't enable interrupts. The second indicates that > the PHY layer will neither poll, nor enable interrupts, and thus will > allow the driver to handle interrupts. The PHY layer will still operate > its state machine, though. > > The driver must insure a couple things: > > 1) It must set phydev->state to PHY_CHANGELINK > 2) It must do that in a work queue (or other non-interrupt time) > > The first one tells the PHY layer that the link state changed (it has to > grab a lock to do this). The second one is required in order to > properly take the lock. > >> >> Also, did you mean to leave the #if 0 code in davicom.c? > > > For now. It worked around a problem some people were reporting, so I'd > like to see if they report it again now that the code's out. If so, > they have a fairly easy fix, and I can reinsert it (or at least > reevaluate it) in the future. > >> >> /james > > > Andy > > > ------------------------------------------------------------------------ > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded Hi Andy. Mind taking a look at the combined FEC/FCC driver I've posted and comment on how hard it'll be to use your PAL? I'd be especially interested at any API mismatches, and problems you might find. Regards Pantelis From michael@ellerman.id.au Thu May 12 00:47:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 00:47:58 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C7lsOv012189 for ; Thu, 12 May 2005 00:47:55 -0700 Received: from localhost (ozlabs.org [203.10.76.45]) by ozlabs.org (Postfix) with ESMTP id 6CFCF67A59; Thu, 12 May 2005 17:47:27 +1000 (EST) From: Michael Ellerman Reply-To: michael@ellerman.id.au To: Andrew Morton , Jeff Garzik Subject: [PATCH 1/4] iseries_veth: Don't send packets to LPARs which aren't up Date: Thu, 12 May 2005 17:47:27 +1000 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200505121747.27752.michael@ellerman.id.au> X-archive-position: 1032 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michael@ellerman.id.au Precedence: bulk X-list: netdev Content-Length: 994 Lines: 31 Hi Andrew, Jeff, The iseries_veth driver has a logic bug which means it will erroneously send packets to LPARs for which we don't have a connection. This usually isn't a big problem because the Hypervisor call fails gracefully and we return, but if packets are TX'ed during the negotiation of the connection bad things might happen. Regardless, the right thing is to bail early if we know there's no connection. Signed-off-by: Michael Ellerman -- iseries_veth.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: veth-fixes/drivers/net/iseries_veth.c =================================================================== --- veth-fixes.orig/drivers/net/iseries_veth.c +++ veth-fixes/drivers/net/iseries_veth.c @@ -924,7 +924,7 @@ static int veth_transmit_to_one(struct s spin_lock_irqsave(&cnx->lock, flags); - if (! cnx->state & VETH_STATE_READY) + if (! (cnx->state & VETH_STATE_READY)) goto drop; if ((skb->len - 14) > VETH_MAX_MTU) From Axel.Reinhold@le-gobw.de Thu May 12 00:49:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 00:49:42 -0700 (PDT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C7nXOv012345 for ; Thu, 12 May 2005 00:49:37 -0700 Received: from fwd21.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1DW8RJ-0003Jx-00; Thu, 12 May 2005 09:49:01 +0200 Received: from l0p.le-gobw.de (VyqE7TZJQepOQz0Br50aS0n+OkEvAWc55Y5tRxtiuWBL-7ExiC8foj@[62.226.107.205]) by fwd21.sul.t-online.de with esmtp id 1DW8R6-0UXFjC0; Thu, 12 May 2005 09:48:48 +0200 Received: from york (lw0030 [10.1.33.127]) by l0p.le-gobw.de (8.13.3/8.13.1/Post@Bote) with ESMTP id j4C7hWKI011583 for ; Thu, 12 May 2005 09:43:32 +0200 Message-Id: <200505120743.j4C7hWKI011583@l0p.le-gobw.de> From: "Axel Reinhold" To: Subject: Sis900 and VLAN 8021q.o incompatible/MTU troubles Date: Thu, 12 May 2005 09:43:13 +0200 Organization: Le-go Bekleidungswerke GmbH MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVWxkACGOktsrGvTrKSX1VOC9xP/w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Logged: Logged by l0p.le-gobw.de as j4C7hWKI011583 at Thu May 12 09:43:32 2005 X-ID: VyqE7TZJQepOQz0Br50aS0n+OkEvAWc55Y5tRxtiuWBL-7ExiC8foj@t-dialin.net X-TOI-MSGID: 2ba9ba75-e825-4145-9bb5-06c238b45a9c X-archive-position: 1033 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Axel.Reinhold@le-gobw.de Precedence: bulk X-list: netdev Content-Length: 3291 Lines: 75 Dear Venza, my sis900 is running fine in standard mode. Together with 8021q.o i get all kinds of troubles - for example samba is no more working at all - without vlan everything is fine - with vlans everything basically works - but only to a certain point, then it screws up. Is sis900.o incompatible with 8021q.o? Has the driver the MTU-troubles known from other old ethernet drivers? May 11 20:03:20 bongo kernel: sis900.c: v1.08.07 11/02/2003 May 11 20:03:20 bongo kernel: PCI: Found IRQ 12 for device 00:01.1 May 11 20:03:20 bongo kernel: eth0: SiS 900 Internal MII PHY transceiver found at address 1. May 11 20:03:20 bongo kernel: eth0: Using transceiver found at address 1 as default May 11 20:03:20 bongo kernel: eth0: SiS 900 PCI Fast Ethernet at 0xd400, IRQ 12, 00:e0:18:3a:db:1a. May 11 20:03:20 bongo kernel: 802.1Q VLAN Support v1.8 Ben Greear May 11 20:03:20 bongo kernel: All bugs added by David S. Miller [2005/05/11 21:01:23, 0] lib/util_sock.c:get_peer_addr(1150) getpeername failed. Error was Transport endpoint is not connected [2005/05/11 21:01:23, 0] lib/util_sock.c:get_peer_addr(1150) getpeername failed. Error was Transport endpoint is not connected [2005/05/11 21:01:23, 0] lib/access.c:check_access(328) [2005/05/11 21:01:23, 0] lib/util_sock.c:get_peer_addr(1150) getpeername failed. Error was Transport endpoint is not connected [2005/05/11 21:01:23, 0] lib/util_sock.c:get_peer_addr(1150) getpeername failed. Error was Transport endpoint is not connected [2005/05/11 21:01:23, 0] lib/util_sock.c:write_socket_data(430) write_socket_data: write failure. Error = Connection reset by peer [2005/05/11 21:01:23, 0] lib/util_sock.c:write_socket(455) write_socket: Error writing 5 bytes to socket 30: ERRNO = Connection reset by peer [2005/05/11 21:01:23, 0] lib/util_sock.c:send_smb(647) Error writing 5 bytes to client. -1. (Connection reset by peer) [2005/05/11 21:23:14, 0] smbd/server.c:main(798) [2005/05/11 21:01:23, 0] lib/util_sock.c:get_peer_addr(1150) getpeername failed. Error was Transport endpoint is not connected [2005/05/11 21:01:23, 0] lib/util_sock.c:get_peer_addr(1150) getpeername failed. Error was Transport endpoint is not connected [2005/05/11 21:01:23, 0] lib/util_sock.c:write_socket_data(430) write_socket_data: write failure. Error = Connection reset by peer [2005/05/11 21:01:23, 0] lib/util_sock.c:write_socket(455) write_socket: Error writing 5 bytes to socket 30: ERRNO = Connection reset by peer [2005/05/11 21:01:23, 0] lib/util_sock.c:send_smb(647) Error writing 5 bytes to client. -1. (Connection reset by peer) [2005/05/11 21:23:14, 0] smbd/server.c:main(798) -- |------------------------+--------------------------------------| | Axel Reinhold | Fax: +49-9287-8244 | | Franz-Heinrich-Str. 20 | eMail: axel@freakout.de | | 95100 Selb | http://www.freakout.de | | Germany | Please do not send more than 100 kilobytes | |------------------+--------------------------------------------| | Fingerprint: 8D EF 9F 22 DF 9A 9B 68 E5 8C 12 C7 8D 6A 97 4E | |---------------------------------------------------------------| | Legal Warning: Do NOT send unsolicited commercial email to me | From michael@ellerman.id.au Thu May 12 00:53:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 00:53:48 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C7rjOv013231 for ; Thu, 12 May 2005 00:53:45 -0700 Received: from localhost (ozlabs.org [203.10.76.45]) by ozlabs.org (Postfix) with ESMTP id 53A0667B3E; Thu, 12 May 2005 17:53:18 +1000 (EST) From: Michael Ellerman Reply-To: michael@ellerman.id.au To: Andrew Morton , Jeff Garzik Subject: [PATCH 2/4] iseries_veth: Set dev->trans_start so watchdog timer works right Date: Thu, 12 May 2005 17:53:18 +1000 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505121753.19267.michael@ellerman.id.au> X-archive-position: 1034 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michael@ellerman.id.au Precedence: bulk X-list: netdev Content-Length: 774 Lines: 25 Hi Andrew, Jeff, The iseries_veth driver doesn't set dev->trans_start in it's TX path. This will cause the net device watchdog timer to fire earlier than we want it to, which causes the driver to needlessly reset its connections to other LPARs. Signed-off-by: Michael Ellerman -- iseries_veth.c | 2 ++ 1 files changed, 2 insertions(+) Index: veth-fixes/drivers/net/iseries_veth.c =================================================================== --- veth-fixes.orig/drivers/net/iseries_veth.c +++ veth-fixes/drivers/net/iseries_veth.c @@ -1023,6 +1023,8 @@ static int veth_start_xmit(struct sk_buf lpmask = veth_transmit_to_many(skb, lpmask, dev); + dev->trans_start = jiffies; + if (! lpmask) { dev_kfree_skb(skb); } else { From Robert.Olsson@data.slu.se Thu May 12 00:54:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 00:54:30 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C7sOOv013468 for ; Thu, 12 May 2005 00:54:25 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j4C7rrYB022086; Thu, 12 May 2005 09:53:53 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 2560AEE1E9; Thu, 12 May 2005 09:53:53 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17027.2961.116716.572730@robur.slu.se> Date: Thu, 12 May 2005 09:53:53 +0200 To: "David S. Miller" Cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: [TG3]: Add hw coalescing infrastructure. In-Reply-To: <20050511.192819.24336786.davem@davemloft.net> References: <20050511.141530.57445142.davem@davemloft.net> <1115846256.8570.109.camel@rh4> <20050511.192819.24336786.davem@davemloft.net> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-archive-position: 1035 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1190 Lines: 31 David S. Miller writes: > From: "Michael Chan" > Subject: Re: [TG3]: Add hw coalescing infrastructure. > Date: Wed, 11 May 2005 14:17:36 -0700 > > Yes, and MTU size dependent too. But we may not want to coalesce the > > same way when running at 10/100 Mbps. For example, if one packet has > > arrived, we don't want to wait 120 usec or 1200 usec to see if another > > packet will arrive before we interrupt at 100 and 10 Mbps respectively. > > That's a good point. I think it would be wise for us to try > and come up with a dynamic mitigation algorithm that is as MTU > and link speed agnostic as possible. Size of RX-ring is also to be taken to account. You probably have to design for samllest packets otherwise you risk RX-ring overrun and packet drop. > One thing to note is that what we're really trying to do is > maximize the amount of work done per interrupt, without > unduly adding latency to packet reception. > > Work done per-interrupt, and maximum latency, are better goals > because formulas based upon those values will automatically take > differences in CPU and BUS I/O speed into account. Yes. Cheers. --ro From michael@ellerman.id.au Thu May 12 00:55:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 00:55:38 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C7tYOv014230 for ; Thu, 12 May 2005 00:55:35 -0700 Received: from localhost (ozlabs.org [203.10.76.45]) by ozlabs.org (Postfix) with ESMTP id 1CB8C67B2D; Thu, 12 May 2005 17:55:08 +1000 (EST) From: Michael Ellerman Reply-To: michael@ellerman.id.au To: Andrew Morton , Jeff Garzik Subject: [PATCH 3/4] iseries_veth: Don't leak skbs in RX path Date: Thu, 12 May 2005 17:55:08 +1000 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505121755.09132.michael@ellerman.id.au> X-archive-position: 1036 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michael@ellerman.id.au Precedence: bulk X-list: netdev Content-Length: 1368 Lines: 42 Hi Andrew, Jeff, Under some strange circumstances the iseries_veth driver can leak skbs. Fix is simply to call dev_kfree_skb() in the right place. Fix up the comment as well. Signed-off-by: Michael Ellerman -- iseries_veth.c | 17 +++++++++++------ 1 files changed, 11 insertions(+), 6 deletions(-) Index: veth-fixes/drivers/net/iseries_veth.c =================================================================== --- veth-fixes.orig/drivers/net/iseries_veth.c +++ veth-fixes/drivers/net/iseries_veth.c @@ -1264,13 +1264,18 @@ static void veth_receive(struct veth_lpa vlan = skb->data[9]; dev = veth_dev[vlan]; - if (! dev) - /* Some earlier versions of the driver sent - broadcasts down all connections, even to - lpars that weren't on the relevant vlan. - So ignore packets belonging to a vlan we're - not on. */ + if (! dev) { + /* + * Some earlier versions of the driver sent + * broadcasts down all connections, even to lpars + * that weren't on the relevant vlan. So ignore + * packets belonging to a vlan we're not on. + * We can also be here if we receive packets while + * the driver is going down, because then dev is NULL. + */ + dev_kfree_skb_irq(skb); continue; + } port = (struct veth_port *)dev->priv; dest = *((u64 *) skb->data) & 0xFFFFFFFFFFFF0000; From manfred99@gmx.ch Thu May 12 01:00:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 01:00:23 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4C80HOv015018 for ; Thu, 12 May 2005 01:00:18 -0700 Received: (qmail 2863 invoked by uid 0); 12 May 2005 07:59:50 -0000 Received: from 212.55.205.40 by www69.gmx.net with HTTP; Thu, 12 May 2005 09:59:50 +0200 (MEST) Date: Thu, 12 May 2005 09:59:50 +0200 (MEST) From: "Manfred Schwarb" To: Marcelo Tosatti Cc: linux-kernel@vger.kernel.org, davem@redhat.com, netdev@oss.sgi.com MIME-Version: 1.0 References: <20050511124640.GE8541@logos.cnet> Subject: Re: 2.4.30-hf1 do_IRQ stack overflows X-Priority: 3 (Normal) X-Authenticated: #17170890 Message-ID: <8542.1115884790@www69.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 1037 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred99@gmx.ch Precedence: bulk X-list: netdev Content-Length: 893 Lines: 32 > > The traces show huge networking execution paths. > > It seems you are using some packet scheduler (CONFIG_NET_SCHED)? Pretty > much all > traces show functions from sch_generic.c. Can you disable that for a test? > Yes, indeed, I made some experiments with it, but do not need it urgently. I will disable it, thanks for the hint. And I will report back. > > > > Below my three overflow messages. Would the stack reduction patches of > Badari Pulavarty > > help in my case? If so, I would strongly vote for inclusion into 2.4 > series!! > > It has been decided that the stack reduction patches were too intrusive to > be merged > at this stage of v2.4 life. > OK, I got the message, I will consider upgrading to 2.6 sometime this year... -- +++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++ GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail From michael@ellerman.id.au Thu May 12 01:10:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 01:10:18 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C8ABOv015650 for ; Thu, 12 May 2005 01:10:11 -0700 Received: from localhost (ozlabs.org [203.10.76.45]) by ozlabs.org (Postfix) with ESMTP id 9861A67B3E; Thu, 12 May 2005 18:09:44 +1000 (EST) From: Michael Ellerman Reply-To: michael@ellerman.id.au To: Andrew Morton , Jeff Garzik Subject: [PATCH 4/4] iseries_veth: Cleanup skbs to prevent unregister_netdevice() hanging Date: Thu, 12 May 2005 18:09:45 +1000 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, "PPC64-dev" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505121809.45419.michael@ellerman.id.au> X-archive-position: 1038 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michael@ellerman.id.au Precedence: bulk X-list: netdev Content-Length: 1969 Lines: 53 Hi Andrew, Jeff, The iseries_veth driver is badly behaved in that it will keep TX packets hanging around forever if they're not ACK'ed and the queue never fills up. This causes the unregister_netdevice code to wait forever when we try to take the device down, because there's still skbs around with references to our struct net_device. There's already code to cleanup any un-ACK'ed packets in veth_stop_connection() but it's being called after we unregister the net_device, which is too late. The fix is to rearrange the module exit function so that we cleanup any outstanding skbs and then unregister the driver. Signed-off-by: Michael Ellerman -- drivers/net/iseries_veth.c | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) Index: veth-fixes/drivers/net/iseries_veth.c =================================================================== --- veth-fixes.orig/drivers/net/iseries_veth.c 2005-05-12 16:27:32.000000000 +1000 +++ veth-fixes/drivers/net/iseries_veth.c 2005-05-12 16:27:42.000000000 +1000 @@ -1388,18 +1388,25 @@ { int i; - vio_unregister_driver(&veth_driver); + /* Stop the queues first to stop any new packets being sent. */ + for (i = 0; i < HVMAXARCHITECTEDVIRTUALLANS; i++) + if (veth_dev[i]) + netif_stop_queue(veth_dev[i]); + /* Stop the connections before we unregister the driver. This + * ensures there's no skbs lying around holding the device open. */ for (i = 0; i < HVMAXARCHITECTEDLPS; ++i) veth_stop_connection(i); HvLpEvent_unregisterHandler(HvLpEvent_Type_VirtualLan); /* Hypervisor callbacks may have scheduled more work while we - * were destroying connections. Now that we've disconnected from + * were stoping connections. Now that we've disconnected from * the hypervisor make sure everything's finished. */ flush_scheduled_work(); + vio_unregister_driver(&veth_driver); + for (i = 0; i < HVMAXARCHITECTEDLPS; ++i) veth_destroy_connection(i); From manfred99@gmx.ch Thu May 12 01:45:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 01:45:16 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4C8jAOv017467 for ; Thu, 12 May 2005 01:45:10 -0700 Received: (qmail 23424 invoked by uid 0); 12 May 2005 08:44:38 -0000 Received: from 212.55.205.40 by www69.gmx.net with HTTP; Thu, 12 May 2005 10:44:37 +0200 (MEST) Date: Thu, 12 May 2005 10:44:37 +0200 (MEST) From: "Manfred Schwarb" To: Herbert Xu Cc: marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org, davem@redhat.com, netdev@oss.sgi.com MIME-Version: 1.0 References: Subject: Re: 2.4.30-hf1 do_IRQ stack overflows X-Priority: 3 (Normal) X-Authenticated: #17170890 Message-ID: <21780.1115887477@www69.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 1039 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred99@gmx.ch Precedence: bulk X-list: netdev Content-Length: 24110 Lines: 521 > Marcelo Tosatti wrote: > > > > May 11 04:22:09 server kernel: [__switch_to+82/256] > [schedule+738/1344] [schedule_timeout+84/160] [process_timeout+0/96] > [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294702743/96] > [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294703097/96] > > The stack trace becomes unreadable at this point. Please run klogd > with -X and then decode the messages with ksymoops. Alternatively > run ksymoops on the output of dmesg directly. > Here are the 3 ksymoopsified traces (ksymoops -i): May 11 04:22:09 tp-meteodat7 kernel: f3668824 00000274 e9a40380 00000000 00000003 f7e5d280 f3668000 0000000e May 11 04:22:09 tp-meteodat7 kernel: c010d948 00000003 f7e5d318 f7e5d308 f7e5d280 f3668000 0000000e 00000006 May 11 04:22:09 tp-meteodat7 kernel: f1960018 f1a00018 ffffff14 c024893e 00000010 00000202 f7e5d280 f196cc00 May 11 04:22:09 tp-meteodat7 kernel: Call Trace: [call_do_IRQ+5/13] [pfifo_fast_dequeue+62/80] [qdisc_restart+31/432] [dev_queue_xmit+383/880] [neigh_resolve_output+321/624] May 11 04:22:09 tp-meteodat7 kernel: Call Trace: [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:22:09 tp-meteodat7 kernel: [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c010d948 Trace; c024893e Trace; c02483df Trace; c023ccaf Trace; c0243af1 Trace; c025a2d8 Trace; c025a220 Trace; c025a220 Trace; c024763e Trace; c025a220 Trace; c0258a4e Trace; c025a220 Trace; c025a445 Trace; c025a370 Trace; c025a370 Trace; c024763e Trace; c025a370 Trace; c0258e2d Trace; c025a370 Trace; c023ccaf Trace; c0271c20 Trace; c026bdc9 Trace; c026e824 Trace; c025d4a0 Trace; c025d4a0 Trace; c026a2fa Trace; c0272eda Trace; c02735be Trace; c025581f Trace; c02556c0 Trace; c024763e Trace; c02556c0 Trace; c025514f Trace; c02556c0 Trace; c0255a89 Trace; c0255860 Trace; c0255860 Trace; c024763e Trace; c0255860 Trace; c0255589 Trace; c0255860 Trace; c023d505 Trace; c023d5d3 Trace; c023d76a Trace; c01254c6 Trace; c010b094 Trace; c010d948 Trace; c0107722 <__switch_to+52/100> Trace; c011cee2 Trace; c011cb14 Trace; c011ca60 Trace; f90f0697 <[usbcore]usb_start_wait_urb+a7/1a0> Trace; f90f07f9 <[usbcore]usb_internal_control_msg+69/80> Trace; f90f08ab <[usbcore]usb_control_msg+9b/b0> Trace; f90f20c6 <[usbcore]usb_get_report+76/80> Trace; f914d588 <[hid]hid_read_report+98/c0> Trace; f914f255 <[hid]hiddev_ioctl+565/cd0> Trace; f8b557d4 <[reiserfs]get_cnode+14/80> Trace; f8b629ca <[reiserfs].LC32+57e7/5a7d> Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0> Trace; f8b4cc74 <[reiserfs]leaf_insert_into_buf+1c4/2c0> Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0> Trace; f8b39e28 <[reiserfs]balance_leaf+30a8/3120> Trace; f8b448c3 <[reiserfs]ip_check_balance+2e3/bf0> Trace; f8b4d47e <[reiserfs]leaf_cut_from_buffer+28e/4b0> Trace; f8b4f8c3 <[reiserfs]pathrelse_and_restore+43/60> Trace; f8b4667b <[reiserfs]unfix_nodes+9b/180> Trace; f8b3a308 <[reiserfs]do_balance+d8/130> Trace; f8b465ad <[reiserfs]fix_nodes+3fd/430> Trace; f8b531fc <[reiserfs]reiserfs_insert_item+14c/150> Trace; c02387be <__kfree_skb+fe/160> Trace; c02387be <__kfree_skb+fe/160> Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180> Trace; c02483df Trace; c023ccaf Trace; c0243af1 Trace; c02387be <__kfree_skb+fe/160> Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180> Trace; c02483df Trace; c023ccaf Trace; c0243af1 Trace; c025a2d8 Trace; c025a220 Trace; c025a220 Trace; c024763e Trace; c025a220 Trace; c0258a4e Trace; c025a220 Trace; c025a445 Trace; c025a370 Trace; c025a370 Trace; c024763e Trace; c025a370 Trace; c0258e2d Trace; c025a370 Trace; c02399dc Trace; c0237f63 Trace; c025d4a0 Trace; c025d4a0 Trace; c026a2bd Trace; c0272eda Trace; c02735be Trace; c01e4308 Trace; f8b20233 <[scsi_mod]__scsi_end_request+233/240> Trace; f8b20233 <[scsi_mod]__scsi_end_request+233/240> Trace; f8b20547 <[scsi_mod]scsi_io_completion+1d7/4c0> Trace; f8b31d39 <[sd_mod]rw_intr+89/2c0> Trace; f8b18565 <[scsi_mod]scsi_finish_command+c5/110> Trace; f8b696b7 <[libata]ata_qc_complete+37/b0> Trace; f8b7068b <[sata_promise]pdc_interrupt+16b/1b0> Trace; c01258ca Trace; c0125753 Trace; c0158905 Trace; c0108fa7 ############################################################### May 11 04:26:28 tp-meteodat7 kernel: f3668998 000003e8 00000000 00000000 f3668000 f3668ac0 f3668a34 00000000 May 11 04:26:28 tp-meteodat7 kernel: c010d948 f3668000 0001961a 00000944 f3668ac0 f3668a34 00000000 00000944 May 11 04:26:28 tp-meteodat7 kernel: 00000018 f1960018 ffffff14 f90820a7 00000010 00000246 f3668a34 f40a9ec0 May 11 04:26:28 tp-meteodat7 kernel: Call Trace: [call_do_IRQ+5/13] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294250663/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294268736/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294250842/96] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294254302/96] May 11 04:26:28 tp-meteodat7 kernel: Call Trace: [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:26:28 tp-meteodat7 kernel: [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c010d948 Trace; f90820a7 <[ip_conntrack]__ip_conntrack_find+17/90> Trace; f9086740 <[ip_conntrack]ip_conntrack_protocol_tcp+0/40> Trace; f908215a <[ip_conntrack]ip_conntrack_find_get+3a/80> Trace; f9082ede <[ip_conntrack]ip_conntrack_in+1ae/2e0> Trace; c025a370 Trace; c0247185 Trace; c025a370 Trace; c025a370 Trace; c0247557 Trace; c025a370 Trace; f9085fb8 <[ip_conntrack]ip_conntrack_local_out_ops+0/18> Trace; c0258e2d Trace; c025a370 Trace; c02735be Trace; c0271c20 Trace; c026bdc9 Trace; c026e824 Trace; c025d4a0 Trace; c025d4a0 Trace; c026a2fa Trace; c0272eda Trace; c02735be Trace; c025581f Trace; c02556c0 Trace; c024763e Trace; c02556c0 Trace; c025514f Trace; c02556c0 Trace; c0255a89 Trace; c0255860 Trace; c0255860 Trace; c024763e Trace; c0255860 Trace; c0255589 Trace; c0255860 Trace; c023d505 Trace; c023d5d3 Trace; c023d76a Trace; c01254c6 Trace; c010b094 Trace; c010d948 Trace; f90f0018 <[usbcore]call_policy_interface+8/260> Trace; f914e620 <[hid]hiddev_send_event+0/b0> Trace; f914e7b6 <[hid]hiddev_report_event+66/80> Trace; f914d473 <[hid]hid_input_report+133/170> Trace; f914d5a6 <[hid]hid_read_report+b6/c0> Trace; c018480b Trace; f914f255 <[hid]hiddev_ioctl+565/cd0> Trace; f8b557d4 <[reiserfs]get_cnode+14/80> Trace; f8b629ca <[reiserfs].LC32+57e7/5a7d> Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0> Trace; f8b4cc74 <[reiserfs]leaf_insert_into_buf+1c4/2c0> Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0> Trace; f8b39e28 <[reiserfs]balance_leaf+30a8/3120> Trace; f8b448c3 <[reiserfs]ip_check_balance+2e3/bf0> Trace; f8b4d47e <[reiserfs]leaf_cut_from_buffer+28e/4b0> Trace; f8b4f8c3 <[reiserfs]pathrelse_and_restore+43/60> Trace; f8b4667b <[reiserfs]unfix_nodes+9b/180> Trace; f8b3a308 <[reiserfs]do_balance+d8/130> Trace; f8b465ad <[reiserfs]fix_nodes+3fd/430> Trace; f8b531fc <[reiserfs]reiserfs_insert_item+14c/150> Trace; c02387be <__kfree_skb+fe/160> Trace; c02387be <__kfree_skb+fe/160> Trace; c02387be <__kfree_skb+fe/160> Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180> Trace; c02483df Trace; c023ccaf Trace; c0243af1 Trace; c025a2d8 Trace; c025a220 Trace; c025a220 Trace; c024763e Trace; c025a220 Trace; c0258a4e Trace; c025a220 Trace; c025a445 Trace; c025a370 Trace; c025a370 Trace; c024763e Trace; c025a370 Trace; c0258e2d Trace; c025a370 Trace; c024763e Trace; c0271c20 Trace; c026bdc9 Trace; c0237f63 Trace; c025d4a0 Trace; c025d4a0 Trace; c026a2bd Trace; c0272eda Trace; c02735be Trace; c025581f Trace; c02556c0 Trace; c024763e Trace; c02556c0 Trace; c025514f Trace; c02556c0 Trace; c0255a89 Trace; c0255860 Trace; c0255860 Trace; c024763e Trace; c011cee2 Trace; c011cb1e Trace; c01594d4 Trace; c01598d9 Trace; c0159bb4 Trace; c0158905 Trace; c0124bb5 Trace; c0108fa7 ################################################################ May 11 04:30:06 tp-meteodat7 kernel: f3668830 00000280 f2c73080 00000000 f196cd80 d2029180 d2029180 00000042 May 11 04:30:06 tp-meteodat7 kernel: c010d948 f196cd80 f008a0ec d2029180 d2029180 d2029180 00000042 f008a080 May 11 04:30:06 tp-meteodat7 kernel: f1960018 f5fd0018 ffffff14 c0238723 00000010 00000202 d2029180 d2029180 May 11 04:30:06 tp-meteodat7 kernel: Call Trace: [call_do_IRQ+5/13] [__kfree_skb+99/352] [st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294624756/96] [qdisc_restart+114/432] [dev_queue_xmit+383/880] May 11 04:30:06 tp-meteodat7 kernel: Call Trace: [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] [] [] [] [] May 11 04:30:06 tp-meteodat7 kernel: [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c010d948 Trace; c0238723 <__kfree_skb+63/160> Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180> Trace; c0248432 Trace; c023ccaf Trace; c025a2d8 Trace; c025a220 Trace; c025a220 Trace; c024763e Trace; c025a220 Trace; c0258a4e Trace; c025a220 Trace; c025a445 Trace; c025a370 Trace; c025a370 Trace; c024763e Trace; c025a370 Trace; c0258e2d Trace; c025a370 Trace; c0271c20 Trace; c026bdc9 Trace; c026e824 Trace; c025d4a0 Trace; c025d4a0 Trace; c026a2fa Trace; c0272eda Trace; c02735be Trace; c025581f Trace; c02556c0 Trace; c024763e Trace; c02556c0 Trace; c025514f Trace; c02556c0 Trace; c0255a89 Trace; c0255860 Trace; c0255860 Trace; c024763e Trace; c0255860 Trace; c0255589 Trace; c0255860 Trace; c023d505 Trace; c023d5d3 Trace; c023d76a Trace; c01254c6 Trace; c010b094 Trace; c010d948 Trace; f9109ae3 <[usb-uhci]insert_qh+83/c0> Trace; f910a404 <[usb-uhci]uhci_submit_control_urb+244/370> Trace; f910be18 <[usb-uhci]uhci_submit_urb+3c8/400> Trace; f90f058d <[usbcore]usb_submit_urb+3d/40> Trace; f90f066d <[usbcore]usb_start_wait_urb+7d/1a0> Trace; f90f07f9 <[usbcore]usb_internal_control_msg+69/80> Trace; f90f08ab <[usbcore]usb_control_msg+9b/b0> Trace; f90f20c6 <[usbcore]usb_get_report+76/80> Trace; f914d588 <[hid]hid_read_report+98/c0> Trace; c018480b Trace; f914f255 <[hid]hiddev_ioctl+565/cd0> Trace; f8b557d4 <[reiserfs]get_cnode+14/80> Trace; f8b629ca <[reiserfs].LC32+57e7/5a7d> Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0> Trace; f8b4cc74 <[reiserfs]leaf_insert_into_buf+1c4/2c0> Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0> Trace; f8b39e28 <[reiserfs]balance_leaf+30a8/3120> Trace; f8b448c3 <[reiserfs]ip_check_balance+2e3/bf0> Trace; f8b4d47e <[reiserfs]leaf_cut_from_buffer+28e/4b0> Trace; f8b4f8c3 <[reiserfs]pathrelse_and_restore+43/60> Trace; f8b4667b <[reiserfs]unfix_nodes+9b/180> Trace; f8b3a308 <[reiserfs]do_balance+d8/130> Trace; f8b465ad <[reiserfs]fix_nodes+3fd/430> Trace; f8b531fc <[reiserfs]reiserfs_insert_item+14c/150> Trace; c02387be <__kfree_skb+fe/160> Trace; c023cfb3 Trace; f90ddb21 <[8139too]rtl8139_rx_interrupt+131/320> Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180> Trace; c02387be <__kfree_skb+fe/160> Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180> Trace; c02387be <__kfree_skb+fe/160> Trace; c02387be <__kfree_skb+fe/160> Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180> Trace; c02483df Trace; c023ccaf Trace; c025a2d8 Trace; c025a220 Trace; c025a220 Trace; c024763e Trace; c025a220 Trace; c0258a4e Trace; c025a220 Trace; c025a445 Trace; c025a370 Trace; c025a370 Trace; c024763e Trace; c025a370 Trace; c0258e2d Trace; c025a370 Trace; c0237f63 Trace; c025d4a0 Trace; c025d4a0 Trace; c026a2bd Trace; c0272eda Trace; c02735be Trace; c025581f Trace; c02556c0 Trace; c024763e Trace; c02556c0 Trace; c025514f Trace; c02556c0 Trace; c0255a89 Trace; c013e624 <__alloc_pages+64/280> Trace; c01594d4 Trace; c01598d9 Trace; c0159bb4 Trace; c0158905 Trace; c0124bb5 Trace; c0108fa7 -- +++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++ GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail From mperaya@alcazaba.unex.es Thu May 12 02:31:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 02:31:43 -0700 (PDT) Received: from www.fcdyc.unex.es (alcazaba.unex.es [158.49.151.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4C9VcOv019148 for ; Thu, 12 May 2005 02:31:39 -0700 Received: from webmail.fcdyc.unex.es ([158.49.151.11] ident=Debian-exim) by www.fcdyc.unex.es with esmtp (Exim 4.50) id 1DWA1P-0000vS-3q for netdev@oss.sgi.com; Thu, 12 May 2005 11:30:23 +0200 Received: from www-data by webmail.fcdyc.unex.es with local (Exim 4.50) id 1DWA1P-0004TA-20 for netdev@oss.sgi.com; Thu, 12 May 2005 11:30:23 +0200 Received: from tecno-1.fcdyc.unex.es (tecno-1.fcdyc.unex.es [158.49.151.18]) by 158.49.151.11 (Horde MIME library) with HTTP for ; Thu, 12 May 2005 11:28:27 +0200 Message-ID: <20050512112827.7danjtr4kckg8swc@158.49.151.11> X-Priority: 3 (Normal) Date: Thu, 12 May 2005 11:28:27 +0200 From: Manuel Perez Ayala To: Michael Chan Subject: Re: tg3 support broken on PPC, a workaround References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> <20050511080446.fnstrvtzq8gk8884@158.49.151.11> <1115825081.8570.93.camel@rh4> In-Reply-To: <1115825081.8570.93.camel@rh4> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Resent-Date: Thu, 12 May 2005 11:30:22 +0200 Resent-From: mperaya@alcazaba.unex.es Resent-To: netdev@oss.sgi.com Resent-Message-ID: <20050512113022.d1ujmnq88wccsk4s@158.49.151.11> User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-FCDyC-UEx-MailScanner: Found to be clean X-FCDyC-UEx-MailScanner-From: mperaya@alcazaba.unex.es Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4C9VcOv019148 X-archive-position: 1040 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mperaya@alcazaba.unex.es Precedence: bulk X-list: netdev Content-Length: 3110 Lines: 112 Michael Chan wrote: > > This tells me that your cache line size is 32 bytes. > > Let's try some experiments and see what works and what doesn't. Please > hardcode the following values in tp->dma_rwctrl before it is written to > the register: > Net performance of the working driver: Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.00 415.08 Tryouts: > 1. DMA read/write boundaries set to 256: > > tp->dma_rwctrl = 0x76ff2d0f; > tg3.c:v3.10 (September 14, 2004) PCI: Enabling device 0001:10:13.0 (0014 -> 0016) tg3: tg3_test_dma DMA read/write boundaries set to 256: 76FF2D0F eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:04:76:3b:51:ae eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0] --> DATA CORRUPTION > 2. DMA read boundary 256, write boundary 32: > > tp->dma_rwctrl = 0x76ff150f; > tg3.c:v3.10 (September 14, 2004) PCI: Enabling device 0001:10:13.0 (0014 -> 0016) tg3: tg3_test_dma DMA read boundary 256, write boundary 32: 76FF150F eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:04:76:3b:51:ae eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0] --> DATA OK Net Performance: Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.00 647.19 The net performance is grown over a 50% from the working driver default setting. > 3. DMA read boundary 32, write boundary 256 > > tp->dma_rwctrl = 0x76ff2a0f; > tg3.c:v3.10 (September 14, 2004) PCI: Enabling device 0001:10:13.0 (0014 -> 0016) tg3: tg3_test_dma DMA read boundary 32, write boundary 256: 76FF2A0F eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:04:76:3b:51:ae eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0] --> DATA CORRUPTION No net performance impact. > 4. Let's also try without asserting all byte enables: > > tp->dma_rwctrl = 0x763f2d0f; > tg3.c:v3.10 (September 14, 2004) PCI: Enabling device 0001:10:13.0 (0014 -> 0016) tg3: tg3_test_dma without asserting all byte enables: 763F2D0F eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:04:76:3b:51:ae eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0] --> DATA CORRUPTION Net performance like DMA read boundary 256, write boundary 32:, over 50%, but with data corruption. I've only tried whith the working driver (2.6.8 with dma code from 2.6.7). Do you need I also try the original 2.6.8? Before my initial report, I've tried the broadcom driver 8.1.55 with no success and the same kind of data corruption. Then I focused on the tg3 driver. ---------- Manuel Perez Ayala mperaya@alcazaba.unex.es Facultad de Biblioteconomía y Documentación Universidad de Extremadura From tommy.christensen@tpack.net Thu May 12 02:58:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 02:58:40 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4C9wYOv020220 for ; Thu, 12 May 2005 02:58:35 -0700 Received: (qmail 15617 invoked from network); 12 May 2005 09:58:07 -0000 Received: from tsc-6.cph.tpack.net (HELO ?192.168.9.22?) (192.168.9.22) by 0 with SMTP; 12 May 2005 09:58:07 -0000 Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) From: Tommy Christensen To: Herbert Xu Cc: Ken-ichirou MATSUZAWA , netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <20050511231751.GA21781@gondor.apana.org.au> References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> <20050510220751.GA459@gondor.apana.org.au> <20050511005836.GA1674@gondor.apana.org.au> <4282846F.6070403@tpack.net> <20050511231751.GA21781@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="=-PVeijJmpk17Glw/H2tA2" Message-Id: <1115891887.30106.89.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 May 2005 11:58:07 +0200 X-archive-position: 1042 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 1251 Lines: 43 --=-PVeijJmpk17Glw/H2tA2 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-05-12 at 01:17, Herbert Xu wrote: > BTW, we could also move the skb_orphan to the skb_get path since the > cloned packets don't need the orphan call. Yes, I like this better. Good idea. Signed-off-by: Tommy S. Christensen --=-PVeijJmpk17Glw/H2tA2 Content-Description: Content-Disposition: inline; filename=netlink-3.patch Content-Type: text/x-patch; charset=iso-8859-1 Content-Transfer-Encoding: 7bit diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c --- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200 +++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 11:51:57.427312857 +0200 @@ -735,11 +735,13 @@ sock_hold(sk); if (p->skb2 == NULL) { - if (atomic_read(&p->skb->users) != 1) { + if (skb_shared(p->skb)) { p->skb2 = skb_clone(p->skb, p->allocation); } else { - p->skb2 = p->skb; - atomic_inc(&p->skb->users); + p->skb2 = skb_get(p->skb); + /* skb ownership may have been set when + delivered to a previous socket. */ + skb_orphan(p->skb2); } } if (p->skb2 == NULL) { --=-PVeijJmpk17Glw/H2tA2-- From tommy.christensen@tpack.net Thu May 12 02:57:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 02:57:33 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4C9vTOv020091 for ; Thu, 12 May 2005 02:57:30 -0700 Received: (qmail 15429 invoked from network); 12 May 2005 09:57:01 -0000 Received: from tsc-6.cph.tpack.net (HELO ?192.168.9.22?) (192.168.9.22) by 0 with SMTP; 12 May 2005 09:57:01 -0000 Subject: Re: [PATCH] netlink: defer socket destruction a bit From: Tommy Christensen To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com, Ken-ichirou MATSUZAWA In-Reply-To: <20050511230309.GA21547@gondor.apana.org.au> References: <428284D6.9000804@tpack.net> <20050511222421.GA21331@gondor.apana.org.au> <4282889A.7080409@tpack.net> <20050511230309.GA21547@gondor.apana.org.au> Content-Type: text/plain Message-Id: <1115891821.30106.86.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 May 2005 11:57:01 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 1041 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 737 Lines: 27 On Thu, 2005-05-12 at 01:03, Herbert Xu wrote: > On Thu, May 12, 2005 at 12:35:06AM +0200, Tommy Christensen wrote: > > > > No, skb2 cannot be shared with a listening socket. As I read the code, > > it can only be non-null when delivery has failed. > > What about this code path: > > 1) skb2 = skb, refcnt++. > 2) Devliered to socket 1. > 3) Socket 1 frees skb through recvmsg. > 4) skb2 = skb, refcnt++. > 5) Delivery fails. > > Now skb2 is identical to skb and they both refer to socket 1. You're right, Herbert. The interception by recvmsg has to be considered in this case also. Tricky. I moved the call to skb_orphan in the other patch, as you suggested. I think that also makes this patch safe as it is. Right? -Tommy From hch@lst.de Thu May 12 03:24:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 03:24:16 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CAO9Ov021863 for ; Thu, 12 May 2005 03:24:11 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4CANb6t026672 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 May 2005 12:23:37 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j4CANapj026670; Thu, 12 May 2005 12:23:36 +0200 Date: Thu, 12 May 2005 12:23:36 +0200 From: Christoph Hellwig To: davem@davemloft.net Cc: netdev@oss.sgi.com Subject: [PATCH] use lookup_create in af_unix Message-ID: <20050512102336.GA26628@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1043 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 2065 Lines: 70 currently it opencodes it, but that's in the way of chaning the lookup_hash interface. I'd prefer to disallow modular af_unix over exporting lookup_create, but I'll leave that to you. Signed-off-by: Christoph Hellwig Index: fs/namei.c =================================================================== --- eed337ef5e9ae7d62caa84b7974a11fddc7f06e0/fs/namei.c (mode:100644 sha1:defe6781e003c208fc0a4b6e92bcf1dc2a0465de) +++ uncommitted/fs/namei.c (mode:100644) @@ -1580,6 +1580,7 @@ fail: return dentry; } +EXPORT_SYMBOL_GPL(lookup_create); int vfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev) { Index: net/unix/af_unix.c =================================================================== --- eed337ef5e9ae7d62caa84b7974a11fddc7f06e0/net/unix/af_unix.c (mode:100644 sha1:c478fc8db7768428580d23381856fa53fa31add2) +++ uncommitted/net/unix/af_unix.c (mode:100644) @@ -770,33 +770,12 @@ err = path_lookup(sunaddr->sun_path, LOOKUP_PARENT, &nd); if (err) goto out_mknod_parent; - /* - * Yucky last component or no last component at all? - * (foo/., foo/.., /////) - */ - err = -EEXIST; - if (nd.last_type != LAST_NORM) - goto out_mknod; - /* - * Lock the directory. - */ - down(&nd.dentry->d_inode->i_sem); - /* - * Do the final lookup. - */ - dentry = lookup_hash(&nd.last, nd.dentry); + + dentry = lookup_create(&nd, 0); err = PTR_ERR(dentry); if (IS_ERR(dentry)) goto out_mknod_unlock; - err = -ENOENT; - /* - * Special case - lookup gave negative, but... we had foo/bar/ - * From the vfs_mknod() POV we just have a negative dentry - - * all is fine. Let's be bastards - you had / on the end, you've - * been asking for (non-existent) directory. -ENOENT for you. - */ - if (nd.last.name[nd.last.len] && !dentry->d_inode) - goto out_mknod_dput; + /* * All right, let's create it. */ @@ -845,7 +824,6 @@ dput(dentry); out_mknod_unlock: up(&nd.dentry->d_inode->i_sem); -out_mknod: path_release(&nd); out_mknod_parent: if (err==-EEXIST) From herbert@gondor.apana.org.au Thu May 12 03:34:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 03:34:37 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CAYTOv022763 for ; Thu, 12 May 2005 03:34:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWAZj-0003fi-00; Thu, 12 May 2005 20:05:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWAZg-0006aD-00; Thu, 12 May 2005 20:05:48 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: issue with new TCP TSO stuff Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <20050511.223036.39664020.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 12 May 2005 20:05:48 +1000 X-archive-position: 1044 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1276 Lines: 33 Hi Dave: I've got a number of comments for your patch which I will send once I've finished reading it all. David S. Miller wrote: > > I don't know, maybe we can do something clever with the > skb_shinfo(skb)->frag_list pointer. This was in fact going to be one of my comments :) What we could do is get the TSO drivers to all implement NETIF_F_FRAGLIST. Once they do that, you can simply chain up the skb's and send it off to them. The coalescing will need to be done in the drivers. However, that's not too bad because coalescing only has to be done at the skb boundaries. In fact, this is how we can simplify the unwinding stuff in your skb_append_pages function. Because the coalescing only needs to occur between skb's, you only need to check the first frag to know whether it can be coalesced or not. This means that the unwinding stuff can mostly go away. We'll have to watch out for retransmissions of the frame with a non-null frag_list pointer. They will need to be copied if their clone is still hanging around. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu May 12 03:37:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 03:37:23 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CAbIOv023098 for ; Thu, 12 May 2005 03:37:19 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWB3a-0004EB-00; Thu, 12 May 2005 20:36:42 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWB3X-0006fw-00; Thu, 12 May 2005 20:36:39 +1000 Date: Thu, 12 May 2005 20:36:39 +1000 To: Tommy Christensen Cc: "David S. Miller" , netdev@oss.sgi.com, Ken-ichirou MATSUZAWA Subject: Re: [PATCH] netlink: defer socket destruction a bit Message-ID: <20050512103639.GA25631@gondor.apana.org.au> References: <428284D6.9000804@tpack.net> <20050511222421.GA21331@gondor.apana.org.au> <4282889A.7080409@tpack.net> <20050511230309.GA21547@gondor.apana.org.au> <1115891821.30106.86.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115891821.30106.86.camel@tsc-6.cph.tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1045 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 591 Lines: 17 On Thu, May 12, 2005 at 11:57:01AM +0200, Tommy Christensen wrote: > > I moved the call to skb_orphan in the other patch, as you > suggested. I think that also makes this patch safe as it is. > > Right? Indeed it is. This also means that we don't hold onto the skb's share of rmalloc quota for an excessive amount of time if the number of broadcast sockets is large. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu May 12 03:43:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 03:43:13 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CAh6Ov023912 for ; Thu, 12 May 2005 03:43:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWB9D-0004sp-00; Thu, 12 May 2005 20:42:31 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWB9C-0006hK-00; Thu, 12 May 2005 20:42:30 +1000 Date: Thu, 12 May 2005 20:42:29 +1000 To: Tommy Christensen Cc: Ken-ichirou MATSUZAWA , netdev@oss.sgi.com, "David S. Miller" Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Message-ID: <20050512104229.GB25631@gondor.apana.org.au> References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> <20050510220751.GA459@gondor.apana.org.au> <20050511005836.GA1674@gondor.apana.org.au> <4282846F.6070403@tpack.net> <20050511231751.GA21781@gondor.apana.org.au> <1115891887.30106.89.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115891887.30106.89.camel@tsc-6.cph.tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1046 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1346 Lines: 41 On Thu, May 12, 2005 at 11:58:07AM +0200, Tommy Christensen wrote: > > Yes, I like this better. Good idea. I see that you've given up on the minimalism :) > Signed-off-by: Tommy S. Christensen It looks good to me too except for that comment of yours :) > diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c > --- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200 > +++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 11:51:57.427312857 +0200 > @@ -735,11 +735,13 @@ > > sock_hold(sk); > if (p->skb2 == NULL) { > - if (atomic_read(&p->skb->users) != 1) { > + if (skb_shared(p->skb)) { > p->skb2 = skb_clone(p->skb, p->allocation); > } else { > - p->skb2 = p->skb; > - atomic_inc(&p->skb->users); > + p->skb2 = skb_get(p->skb); > + /* skb ownership may have been set when > + delivered to a previous socket. */ For new comments please use the following style which is more standard in the kernel these days: /* * blah blah blah .... * for comments that don't fit on a single line. */ Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tommy.christensen@tpack.net Thu May 12 03:58:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 03:58:37 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4CAwUOv025012 for ; Thu, 12 May 2005 03:58:31 -0700 Received: (qmail 26266 invoked from network); 12 May 2005 10:58:03 -0000 Received: from tsc-6.cph.tpack.net (HELO ?192.168.9.22?) (192.168.9.22) by 0 with SMTP; 12 May 2005 10:58:03 -0000 Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) From: Tommy Christensen To: Herbert Xu Cc: Ken-ichirou MATSUZAWA , netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <20050512104229.GB25631@gondor.apana.org.au> References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> <20050510220751.GA459@gondor.apana.org.au> <20050511005836.GA1674@gondor.apana.org.au> <4282846F.6070403@tpack.net> <20050511231751.GA21781@gondor.apana.org.au> <1115891887.30106.89.camel@tsc-6.cph.tpack.net> <20050512104229.GB25631@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="=-003Ea2aw58LO0nPLrdAo" Message-Id: <1115895482.30106.95.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 May 2005 12:58:03 +0200 X-archive-position: 1047 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 1229 Lines: 45 --=-003Ea2aw58LO0nPLrdAo Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-05-12 at 12:42, Herbert Xu wrote: > For new comments please use the following style which is more standard > in the kernel these days: Sure, no problem. Signed-off-by: Tommy S. Christensen --=-003Ea2aw58LO0nPLrdAo Content-Description: Content-Disposition: inline; filename=netlink-4.patch Content-Type: text/x-patch; charset=iso-8859-1 Content-Transfer-Encoding: 7bit diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c --- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200 +++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 12:55:32.374430076 +0200 @@ -735,11 +735,15 @@ sock_hold(sk); if (p->skb2 == NULL) { - if (atomic_read(&p->skb->users) != 1) { + if (skb_shared(p->skb)) { p->skb2 = skb_clone(p->skb, p->allocation); } else { - p->skb2 = p->skb; - atomic_inc(&p->skb->users); + p->skb2 = skb_get(p->skb); + /* + * skb ownership may have been set when + * delivered to a previous socket. + */ + skb_orphan(p->skb2); } } if (p->skb2 == NULL) { --=-003Ea2aw58LO0nPLrdAo-- From herbert@gondor.apana.org.au Thu May 12 04:08:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 04:08:27 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CB8GOv025828 for ; Thu, 12 May 2005 04:08:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWBXZ-0005WB-00; Thu, 12 May 2005 21:07:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWBXW-0001YC-00; Thu, 12 May 2005 21:07:38 +1000 Date: Thu, 12 May 2005 21:07:38 +1000 To: Tommy Christensen Cc: Ken-ichirou MATSUZAWA , netdev@oss.sgi.com, "David S. Miller" Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Message-ID: <20050512110738.GA5937@gondor.apana.org.au> References: <20050510.214332.-1300551106.chamas@h4.dion.ne.jp> <20050510220751.GA459@gondor.apana.org.au> <20050511005836.GA1674@gondor.apana.org.au> <4282846F.6070403@tpack.net> <20050511231751.GA21781@gondor.apana.org.au> <1115891887.30106.89.camel@tsc-6.cph.tpack.net> <20050512104229.GB25631@gondor.apana.org.au> <1115895482.30106.95.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115895482.30106.95.camel@tsc-6.cph.tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1048 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 409 Lines: 12 On Thu, May 12, 2005 at 12:58:03PM +0200, Tommy Christensen wrote: > > Signed-off-by: Tommy S. Christensen Acked-by: Herbert Xu Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dgibson@ozlabs.org Thu May 12 04:30:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 04:30:31 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CBUOOv030999 for ; Thu, 12 May 2005 04:30:25 -0700 Received: by ozlabs.org (Postfix, from userid 1007) id 091AA67B5C; Thu, 12 May 2005 21:29:58 +1000 (EST) Date: Thu, 12 May 2005 21:28:57 +1000 From: David Gibson To: Michael Ellerman Cc: Andrew Morton , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, PPC64-dev Subject: Re: [PATCH 4/4] iseries_veth: Cleanup skbs to prevent unregister_netdevice() hanging Message-ID: <20050512112857.GC32694@localhost.localdomain> Mail-Followup-To: David Gibson , Michael Ellerman , Andrew Morton , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, PPC64-dev References: <200505121809.45419.michael@ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505121809.45419.michael@ellerman.id.au> User-Agent: Mutt/1.5.6+20040907i X-archive-position: 1049 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 1037 Lines: 27 On Thu, May 12, 2005 at 06:09:45PM +1000, Michael Ellerman wrote: > Hi Andrew, Jeff, > > The iseries_veth driver is badly behaved in that it will keep TX packets > hanging around forever if they're not ACK'ed and the queue never fills up. > > This causes the unregister_netdevice code to wait forever when we try to take > the device down, because there's still skbs around with references to our > struct net_device. > > There's already code to cleanup any un-ACK'ed packets in veth_stop_connection() > but it's being called after we unregister the net_device, which is too late. > > The fix is to rearrange the module exit function so that we cleanup any > outstanding skbs and then unregister the driver. > > Signed-off-by: Michael Ellerman Nice catch. Acked-by: David Gibson -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/people/dgibson From tgraf@suug.ch Thu May 12 05:20:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 05:20:23 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CCKHOv000653 for ; Thu, 12 May 2005 05:20:20 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id EAF301C0ED; Thu, 12 May 2005 14:20:01 +0200 (CEST) Date: Thu, 12 May 2005 14:20:01 +0200 From: Thomas Graf To: Jonathan Day Cc: netdev@oss.sgi.com Subject: Re: Questions wrt QoS code on Linux Message-ID: <20050512122001.GI28419@postel.suug.ch> References: <20050512044040.61360.qmail@web31504.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512044040.61360.qmail@web31504.mail.mud.yahoo.com> X-archive-position: 1050 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1561 Lines: 34 * Jonathan Day <20050512044040.61360.qmail@web31504.mail.mud.yahoo.com> 2005-05-11 21:40 > First off, I notice that all the code is lumped > together and much of it is generically labelled > "scheduling". I'm wondering if it might not be more > readable if the list were divided into four sections - > "queueing disciplines", "scheduling", "packet > classification" and "everything else". Would that seem > sensible? Or would it risk making things > over-structured? Sounds reasonable although I'm not sure if I understand the difference between "scheduling" and "qdisc". > Secondly, there seem to be an awful lot of QoS methods > not represented in Linux. Implementing them all might > easily double the kernel size for not very much > benefit, even if anyone could find the time to do so. > On the other hand, there are probably some that are > under development and others high on the wishlist. > Does anyone know what projects are currently underway > or being planned? We're lacking feedback on this subject from the users, we hear a lot from the typical home user wanting to get some control over his ADSL/cable link but not much from other areas. There have been some recent additions, mainly Jamal's actions and my small ematch API. They perfectly serve as a base to solve more complex problems but are still in a early stage of completness and documentation. The current development direction is to get away from big and complex problem solvers and focus on tiny and simple components that can be put together to solve problems more individually. From ak@muc.de Thu May 12 07:13:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 07:13:42 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CEDZOv006413 for ; Thu, 12 May 2005 07:13:38 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 30CB3D033E; Thu, 12 May 2005 16:13:05 +0200 (CEST) To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff References: <20050511.223036.39664020.davem@davemloft.net> From: Andi Kleen Date: Thu, 12 May 2005 16:13:05 +0200 In-Reply-To: <20050511.223036.39664020.davem@davemloft.net> (David S. Miller's message of "Wed, 11 May 2005 22:30:36 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1051 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 942 Lines: 24 "David S. Miller" writes: > > This shows up in testing where the connection is application limited. > For example, an "scp" goes more slowly over TSO now, there are less > cpu cycles available for the encryption. > > It's tricky to come up with a scheme to fix this. I would love to be > able to not do the page grabs/releases in the actual TSO frame. I > really haven't come up with a clean way to do that however. Are you sure a few atomic_inc/dec are really causing noticeable slowdown? That would surprise me unless you have lots of cache line bouncing on a MP system. What CPU did you test it on? Does it happen with only a single CPU? And did you actually see them in some profile? Assuming the struct page is in cache the P4 core is the slowest at that that I know, but even on that one it should be in the noise on the other overhead of talking to a NIC on a PCI bus. Perhaps it is something else.. -Andi From jim@ferrypath.org.uk Thu May 12 09:12:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 09:12:13 -0700 (PDT) Received: from prodigynet.co.uk (relay1.prodigynet.co.uk [213.232.80.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CGC5Ov014752 for ; Thu, 12 May 2005 09:12:08 -0700 Received: from ferrypath.org.uk (83-245-28-216.dsl.prodigynet.co.uk [83.245.28.216]) by prodigynet.co.uk (8.12.9/8.12.9) with ESMTP id j4CGBVqf031082 for ; Thu, 12 May 2005 17:11:35 +0100 Received: from jim (helo=localhost) by ferrypath.org.uk with local-esmtp (Exim 3.36 #1 (Debian)) id 1DWGHW-0000SC-00 for ; Thu, 12 May 2005 17:11:26 +0100 Date: Thu, 12 May 2005 17:11:26 +0100 (BST) From: Jim Minter To: netdev@oss.sgi.com Subject: More 'Badness in dst_release' messages Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1052 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jim@ferrypath.org.uk Precedence: bulk X-list: netdev Content-Length: 2372 Lines: 65 Hello, I'm getting 'Badness in dst_release' messages and associated occasional panics (dereferencing invalidated dst pointers), and am having some problems tracking down the cause. Could anyone spare a moment to advise me what I can do next to debug and resolve the issue? I'm running vanilla kernel-2.6.11, x86_64 SMP, on a single-CPU (but hyperthreaded) EM64T Xeon. I'm using IPv4, and that's where all the problems seem to be. IPv6 isn't compiled in; XFRM and bridging are, but I'm not using either. I've had similar problems with an equivalent 2.6.10 setup. These are all the types of backtraces that I'm getting (bear in mind that because it's x86_64, there's no CONFIG_FRAME_POINTER, so the backtraces are noisy). I have verified by hand that the top address in each corresponds to a dst_release call in the code, though. Call Trace:{tcp_v4_connect+1932} {lock_sock+200} {inet_stream_connect+226} {sprintf+136} {lock_sock+200} {fget+91} {sys_connect+122} {sockfd_lookup+32} {sys_getsockopt+132} {system_call+126} [corresponds to the __sk_dst_set(sk, &rt->u.dst); in tcp_v4_connect(): this seems to be curious to me] Call Trace:{inet_sock_destruct+555} {sk_free+30} {inet_release+88} {sock_release+33} {sock_close+53} {__fput+98} {filp_close+126} {sys_close+147} {system_call+126} Call Trace: {__kfree_skb+102} {:e1000:e1000_clean+389} {tcp_transmit_skb+1651} {sk_reset_timer+15} {net_rx_action+132} {__do_softirq+113} {do_softirq+53} {do_IRQ+71} {ret_from_intr+0} {mwait_idle+86} {cpu_idle+63} Any suggestions would be much appreciated as I haven't been able yet to replicate the bug elsewhere. Although I don't have physical access to the machine in question, I am able to arrange for debugging kernels to be put on it, if I know what to look for! Many thanks, Jim Minter From rick.jones2@hp.com Thu May 12 09:33:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 09:33:31 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CGXTOv017219 for ; Thu, 12 May 2005 09:33:29 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id DBE791C03EFA; Thu, 12 May 2005 09:33:01 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id JAA24480; Thu, 12 May 2005 09:33:01 -0700 (PDT) Message-ID: <4283853C.9070608@hp.com> Date: Thu, 12 May 2005 09:33:00 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manuel Perez Ayala Cc: Michael Chan , netdev Subject: Re: tg3 support broken on PPC, a workaround References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> <20050511080446.fnstrvtzq8gk8884@158.49.151.11> <1115825081.8570.93.camel@rh4> <20050512112827.7danjtr4kckg8swc@158.49.151.11> In-Reply-To: <20050512112827.7danjtr4kckg8swc@158.49.151.11> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1053 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 119 Lines: 4 Since both read and write boundaries are being changed, doesn't netperf need to be run in each direction? rick jones From mperaya@alcazaba.unex.es Thu May 12 11:07:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 11:07:48 -0700 (PDT) Received: from www.fcdyc.unex.es (alcazaba.unex.es [158.49.151.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CI7dOv021210 for ; Thu, 12 May 2005 11:07:40 -0700 Received: from webmail.fcdyc.unex.es ([158.49.151.11] ident=Debian-exim) by www.fcdyc.unex.es with esmtp (Exim 4.50) id 1DWI4a-0004OP-Mr; Thu, 12 May 2005 20:06:12 +0200 Received: from www-data by webmail.fcdyc.unex.es with local (Exim 4.50) id 1DWI4a-0005By-Gp; Thu, 12 May 2005 20:06:12 +0200 Received: from 79.red-217-125-250.pooles.rima-tde.net (79.red-217-125-250.pooles.rima-tde.net [217.125.250.79]) by 158.49.151.11 (Horde MIME library) with HTTP for ; Thu, 12 May 2005 20:06:12 +0200 Message-ID: <20050512200612.v4srgy5xk4o4oos4@158.49.151.11> X-Priority: 3 (Normal) Date: Thu, 12 May 2005 20:06:12 +0200 From: Manuel Perez Ayala To: Rick Jones Cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: tg3 support broken on PPC, a workaround References: <20050510113308.kbjo3ob1ck0404k8@158.49.151.11> <1115743966.8570.26.camel@rh4> <20050511080446.fnstrvtzq8gk8884@158.49.151.11> <1115825081.8570.93.camel@rh4> <20050512112827.7danjtr4kckg8swc@158.49.151.11> <4283853C.9070608@hp.com> In-Reply-To: <4283853C.9070608@hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-FCDyC-UEx-MailScanner: Found to be clean X-FCDyC-UEx-MailScanner-From: mperaya@alcazaba.unex.es Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4CI7dOv021210 X-archive-position: 1054 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mperaya@alcazaba.unex.es Precedence: bulk X-list: netdev Content-Length: 1378 Lines: 54 Rick Jones wrote: > Since both read and write boundaries are being changed, doesn't > netperf need to be run in each direction? I have two twin systems: PowerMac G4 both with 3com 3c996T connected to a 3com gigabit switch, same memomry, same disk, same os. I have compiled and installed the driver with the harcoded best dma configuration on both. These are the netperf results from one side: afs02-i:/usr/share/doc/netperf# netperf -H afs01-i TCP STREAM TEST to afs01-i Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.00 671.71 And these are the netperf results from the other side: afs01-i:~# netperf -H afs02-i TCP STREAM TEST to afs02-i Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.00 667.96 And on the local device: afs01-i:~# netperf -H afs01-i TCP STREAM TEST to afs01-i Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.00 1834.33 ---------- Manuel Perez Ayala mperaya@alcazaba.unex.es Facultad de Biblioteconomía y Documentación Universidad de Extremadura From imipak@yahoo.com Thu May 12 12:07:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 12:07:54 -0700 (PDT) Received: from web31508.mail.mud.yahoo.com (web31508.mail.mud.yahoo.com [68.142.198.137]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4CJ7mOv023714 for ; Thu, 12 May 2005 12:07:48 -0700 Received: (qmail 17520 invoked by uid 60001); 12 May 2005 19:07:21 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=OFFWD9NjrBBxArE6lRfAvXH2zkmVTjM93ikqa+cW59pKxGRdPyFW96GySMimqlkcxouRvoBrnToige7CvQ1xWWAGOEaB+VIDtDJiDbsjAxj32eRfaH0KcX/PtFLKqG+9/25LVSCARH1jMOowYco7CEWPzxN3shDbPQLrbvm/vSQ= ; Message-ID: <20050512190721.17518.qmail@web31508.mail.mud.yahoo.com> Received: from [63.86.107.226] by web31508.mail.mud.yahoo.com via HTTP; Thu, 12 May 2005 12:07:21 PDT Date: Thu, 12 May 2005 12:07:21 -0700 (PDT) From: Jonathan Day Subject: Re: Questions wrt QoS code on Linux To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1055 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imipak@yahoo.com Precedence: bulk X-list: netdev Content-Length: 2855 Lines: 87 I'll deal with the first part first, as it's the easiest. :) Very crudely, you can look at networking as being carried out in two stages - collecing the packets to be sent, and then sending them. Something like CBQ tells the machine how to go about collecting the packets, by creating a number of queues into which the packets can be placed. A distinct section of code for classifying packets is used to help the collector to identify the different types of packet so that the collector can handle them correctly. You've actually got another bit in there which determines the ordering of the packets. a FIFO queue won't be ordered the same as a PRIO queue, for example. A completely seperate stage is then needed to actually gather the packets from the queue(s). You might drain one queue completely before moving onto the next, you might work in a round-robin manner, you might even give a queue a fixed timeslice and grab as many packets as possible within that slice before moving on. An additional section handles the case where the network is overloaded. You can drop packets early, by using systems like RED, BLUE, GREEN or BLACK. (Of these, only RED and the variant GRED are in Linux at the moment.) At present, the Linux QoS menu is confusing. CBQ is listed as a packet scheduler, when it in fact queues the packets, rather than schedules them. RED is marked as a queue, whereas it really filters, it doesn't queue. My proposal is to do the following: 1. Rename the sched directory to qos 2. Add a sched subdirectory and move the schedulers into it 3. Add a queue subdirectory and move the queue handlers into it 4. Add a classifier subdirectory and move the packet classifiers into it 5. Add a processor subdirectory and move all code for processing packets (such as RED) into it Everything else would be left where it was. Help files and menu syntax would be changed to reflect what the option actually did. I would probably want to change the symbols as well, to make it easier to follow in the code as to what is happening. --- Thomas Graf wrote: > * Jonathan Day > <20050512044040.61360.qmail@web31504.mail.mud.yahoo.com> > 2005-05-11 21:40 > > First off, I notice that all the code is lumped > > together and much of it is generically labelled > > "scheduling". I'm wondering if it might not be > more > > readable if the list were divided into four > sections - > > "queueing disciplines", "scheduling", "packet > > classification" and "everything else". Would that > seem > > sensible? Or would it risk making things > > over-structured? > > Sounds reasonable although I'm not sure if I > understand > the difference between "scheduling" and "qdisc". __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From davem@davemloft.net Thu May 12 12:28:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 12:28:13 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CJS8Ov028362 for ; Thu, 12 May 2005 12:28:08 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWJKj-00082x-Kj; Thu, 12 May 2005 12:26:57 -0700 Date: Thu, 12 May 2005 12:26:57 -0700 (PDT) Message-Id: <20050512.122657.50069962.davem@davemloft.net> To: ak@muc.de Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff From: "David S. Miller" In-Reply-To: References: <20050511.223036.39664020.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1056 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 523 Lines: 15 From: Andi Kleen Subject: Re: issue with new TCP TSO stuff Date: Thu, 12 May 2005 16:13:05 +0200 > Are you sure a few atomic_inc/dec are really causing noticeable > slowdown? That would surprise me unless you have lots of cache line > bouncing on a MP system. It's about 7 or 8 times as many atomic gets and puts on pages compared to the older code (with an 8K page size). Some of it we can't get rid of, because we keep a normal write queue segmented set of SKBs around. But the TSO part we can eliminate. From davem@davemloft.net Thu May 12 13:04:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 13:04:53 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CK4oOv030601 for ; Thu, 12 May 2005 13:04:50 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWJuI-00086F-48; Thu, 12 May 2005 13:03:42 -0700 Date: Thu, 12 May 2005 13:03:41 -0700 (PDT) Message-Id: <20050512.130341.82102354.davem@davemloft.net> To: ak@muc.de Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff From: "David S. Miller" In-Reply-To: <20050512200251.GA72662@muc.de> References: <20050512.122657.50069962.davem@davemloft.net> <20050512200251.GA72662@muc.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1058 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 582 Lines: 13 From: Andi Kleen Subject: Re: issue with new TCP TSO stuff Date: 12 May 2005 22:02:51 +0200,Thu, 12 May 2005 22:02:51 +0200 > Sure, but did you verify it was the actual problem? (e.g. with a profiler) > If the cache line the atomic operation is done on is EXCLUSIVE to the > CPU then it should not take *that* long to do the atomic operations. Such issues cannot be measured like that, they tend to make other operations slower by inducing cache misses elsewhere. I used my brain to analyze this slowdown, instead of the computer, I'm sorry if that disturbs you :-) From davem@davemloft.net Thu May 12 13:15:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 13:15:04 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CKF0Ov031475 for ; Thu, 12 May 2005 13:15:00 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWK46-00087j-5T; Thu, 12 May 2005 13:13:50 -0700 Date: Thu, 12 May 2005 13:13:49 -0700 (PDT) Message-Id: <20050512.131349.32715242.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff From: "David S. Miller" In-Reply-To: References: <20050511.223036.39664020.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1059 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2298 Lines: 48 From: Herbert Xu Subject: Re: issue with new TCP TSO stuff Date: Thu, 12 May 2005 20:05:48 +1000 > What we could do is get the TSO drivers to all implement NETIF_F_FRAGLIST. > Once they do that, you can simply chain up the skb's and send it off to > them. The coalescing will need to be done in the drivers. However, that's > not too bad because coalescing only has to be done at the skb boundaries. > > In fact, this is how we can simplify the unwinding stuff in your > skb_append_pages function. Because the coalescing only needs to occur > between skb's, you only need to check the first frag to know whether it > can be coalesced or not. This means that the unwinding stuff can mostly > go away. > > We'll have to watch out for retransmissions of the frame with a non-null > frag_list pointer. They will need to be copied if their clone is still > hanging around. Yes, we can just add a frag_list pointer check to the skb_cloned() tests we do when cons'ing up retransmit SKBs for tcp_transmit_skb(). But this still has the early free problem, I think. If an ACK comes in which releases an SKB on the chain, while the driver is still working with that chain, we cannot free the SKB. We have to do it some time later. One way to prevent that would be to do an skb_get() on every SKB in the chain, but then we're back to the original problem of all the extra atomic operations. A secondary point is that I'd like to use a name other than NETIF_F_FRAGLIST because people are super confused as to what this device flag even means. Some people confuse it with NETIF_F_SG, others thing it takes a huge UDP frame and fragments it into MTU sized IP frames and checksums the whole thing. None of which are true. Loopback is the only driver which supports this properly, by simply doing nothing with the packet :-) So back to the main point, we are in quite a conundrum. The whole point of TSO is to offload the segmentation overhead, but we're in fact making the TCP output engine more expensive for the TSO path. I've also considered a longer term idea where we store the write queue in some minimal abstract format, instead of a list of SKBs. Just a data collection and some sequence numbers. But that would be a huge change with questionable gains. From ak@muc.de Thu May 12 13:26:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 13:27:04 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CKQuOv032539 for ; Thu, 12 May 2005 13:26:57 -0700 Received: (qmail 76218 invoked by uid 3709); 12 May 2005 20:26:29 -0000 Date: 12 May 2005 22:26:29 +0200 Date: Thu, 12 May 2005 22:26:29 +0200 From: Andi Kleen To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff Message-ID: <20050512202629.GB72662@muc.de> References: <20050512.122657.50069962.davem@davemloft.net> <20050512200251.GA72662@muc.de> <20050512.130341.82102354.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512.130341.82102354.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 1060 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 881 Lines: 22 On Thu, May 12, 2005 at 01:03:41PM -0700, David S. Miller wrote: > From: Andi Kleen > Subject: Re: issue with new TCP TSO stuff > Date: 12 May 2005 22:02:51 +0200,Thu, 12 May 2005 22:02:51 +0200 > > > Sure, but did you verify it was the actual problem? (e.g. with a profiler) > > If the cache line the atomic operation is done on is EXCLUSIVE to the > > CPU then it should not take *that* long to do the atomic operations. > > Such issues cannot be measured like that, they tend to make > other operations slower by inducing cache misses elsewhere. Atomic operations, especially with cache misses, normally show in a fine grained profile. They also don't cause additional cache misses over non atomic writes. > I used my brain to analyze this slowdown, instead of the > computer, I'm sorry if that disturbs you :-) What disturbs me is your conclusion :) -Andi From romieu@fr.zoreil.com Thu May 12 13:39:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 13:39:27 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CKdDOv000919 for ; Thu, 12 May 2005 13:39:14 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4CKbG5M032273; Thu, 12 May 2005 22:37:16 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4CKbBTC032272; Thu, 12 May 2005 22:37:11 +0200 Date: Thu, 12 May 2005 22:37:10 +0200 From: Francois Romieu To: Axel Reinhold Cc: netdev@oss.sgi.com Subject: Re: Sis900 and VLAN 8021q.o incompatible/MTU troubles Message-ID: <20050512203710.GA30261@electric-eye.fr.zoreil.com> References: <200505120743.j4C7hWKI011583@l0p.le-gobw.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505120743.j4C7hWKI011583@l0p.le-gobw.de> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1061 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 498 Lines: 14 Axel Reinhold : [...] > my sis900 is running fine in standard mode. Together with 8021q.o > i get all kinds of troubles - for example samba is no more working at > all - without vlan everything is fine - with vlans everything basically > works - but only to a certain point, then it screws up. It can help if you provide: - the kernel revision; - some vlan context (commands issued ? vlan only or mixed config ?); - the range of working size for simple ping. -- Ueimor From herbert@gondor.apana.org.au Thu May 12 14:48:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 14:48:27 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CLmKOv003690 for ; Thu, 12 May 2005 14:48:21 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWLX0-0001Yh-00; Fri, 13 May 2005 07:47:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWLWy-0005ip-00; Fri, 13 May 2005 07:47:44 +1000 Date: Fri, 13 May 2005 07:47:44 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff Message-ID: <20050512214744.GA21958@gondor.apana.org.au> References: <20050511.223036.39664020.davem@davemloft.net> <20050512.131349.32715242.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512.131349.32715242.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1062 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2042 Lines: 49 On Thu, May 12, 2005 at 01:13:49PM -0700, David S. Miller wrote: > > But this still has the early free problem, I think. If an ACK > comes in which releases an SKB on the chain, while the driver > is still working with that chain, we cannot free the SKB. We > have to do it some time later. This is fine because we have to skb_clone the packet. Otherwise the next pointer for the frag/xmit list will be messed up. > One way to prevent that would be to do an skb_get() on every > SKB in the chain, but then we're back to the original problem > of all the extra atomic operations. You're being frugal Dave :) I was happy with one skb_clone per skb and you're having problems with skb_get? :) Seriously, we already do one skb_clone for every packet sent so we won't be incurring any extra overhead with this. > A secondary point is that I'd like to use a name other than > NETIF_F_FRAGLIST because people are super confused as to what this > device flag even means. Some people confuse it with NETIF_F_SG, > others thing it takes a huge UDP frame and fragments it into MTU sized > IP frames and checksums the whole thing. None of which are true. Fine by me. But you know I'm not good with names :) > Loopback is the only driver which supports this properly, by > simply doing nothing with the packet :-) If we implement these in the TSO-capable drivers, IPsec could benefit as well. Two inbound IPsec fragments that are reassembled are currently linearised in dev_queue_xmit. With this it can be sent directly to the driver. > So back to the main point, we are in quite a conundrum. The whole > point of TSO is to offload the segmentation overhead, but we're in > fact making the TCP output engine more expensive for the TSO path. I'll need to finish reading the entire patch before I can respond to this. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu May 12 15:11:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 15:11:27 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CMBKOv004899 for ; Thu, 12 May 2005 15:11:21 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWLtI-0001jw-00; Fri, 13 May 2005 08:10:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWLtG-0005lJ-00; Fri, 13 May 2005 08:10:46 +1000 Date: Fri, 13 May 2005 08:10:46 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff Message-ID: <20050512221046.GA22136@gondor.apana.org.au> References: <20050511.223036.39664020.davem@davemloft.net> <20050512.131349.32715242.davem@davemloft.net> <20050512214744.GA21958@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512214744.GA21958@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1063 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1080 Lines: 27 On Fri, May 13, 2005 at 07:47:44AM +1000, herbert wrote: > > You're being frugal Dave :) I was happy with one skb_clone per > skb and you're having problems with skb_get? :) > > Seriously, we already do one skb_clone for every packet sent > so we won't be incurring any extra overhead with this. Nevermind, you're comparing to the existing TSO implementation. So how big exactly is the slowdown? > > A secondary point is that I'd like to use a name other than > > NETIF_F_FRAGLIST because people are super confused as to what this > > device flag even means. Some people confuse it with NETIF_F_SG, > > others thing it takes a huge UDP frame and fragments it into MTU sized > > IP frames and checksums the whole thing. None of which are true. > > Fine by me. But you know I'm not good with names :) This just occured to me, what about NETIF_F_SKBLIST? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Thu May 12 15:35:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 15:35:56 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CMZqOv006352 for ; Thu, 12 May 2005 15:35:52 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWMGM-0008IY-1C; Thu, 12 May 2005 15:34:38 -0700 Date: Thu, 12 May 2005 15:34:37 -0700 (PDT) Message-Id: <20050512.153437.111715835.davem@davemloft.net> To: ak@muc.de Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff From: "David S. Miller" In-Reply-To: <20050512202629.GB72662@muc.de> References: <20050512200251.GA72662@muc.de> <20050512.130341.82102354.davem@davemloft.net> <20050512202629.GB72662@muc.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1064 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 399 Lines: 11 From: Andi Kleen Subject: Re: issue with new TCP TSO stuff Date: 12 May 2005 22:26:29 +0200,Thu, 12 May 2005 22:26:29 +0200 > On Thu, May 12, 2005 at 01:03:41PM -0700, David S. Miller wrote: > > I used my brain to analyze this slowdown, instead of the > > computer, I'm sorry if that disturbs you :-) > > What disturbs me is your conclusion :) Fair enough, I'll get some numbers. :-) From davem@davemloft.net Thu May 12 15:48:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 15:48:12 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CMm8Ov007345 for ; Thu, 12 May 2005 15:48:08 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWMSE-0008KK-Gh; Thu, 12 May 2005 15:46:54 -0700 Date: Thu, 12 May 2005 15:46:54 -0700 (PDT) Message-Id: <20050512.154654.43008397.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff From: "David S. Miller" In-Reply-To: <20050512214744.GA21958@gondor.apana.org.au> References: <20050512.131349.32715242.davem@davemloft.net> <20050512214744.GA21958@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1065 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1494 Lines: 38 From: Herbert Xu Subject: Re: issue with new TCP TSO stuff Date: Fri, 13 May 2005 07:47:44 +1000 > On Thu, May 12, 2005 at 01:13:49PM -0700, David S. Miller wrote: > > One way to prevent that would be to do an skb_get() on every > > SKB in the chain, but then we're back to the original problem > > of all the extra atomic operations. > > You're being frugal Dave :) I was happy with one skb_clone per > skb and you're having problems with skb_get? :) > > Seriously, we already do one skb_clone for every packet sent > so we won't be incurring any extra overhead with this. It's "relative to existing TSO" that this cost is. For the existing TSO handling we do one atomic ref for the entire TSO frame. Now we're going to do it for the N frames that a TSO packet is composed of. So what this ends up meaning is that the new TSO code's only gain (relative to non-TSO) will basically be that we: 1) Incur only one trip down the device XMIT path for N frames. 2) Only send one set of headers of the bus to the device. Whereas the existing TSO support has a third benefit which is: 3) TSO frames are segmented as singular SKBs This reduction in SKB allocations and subsequent handling is non-trivial. It has ramifications beyond the transmit path. When the ACKs come back in, we do less kfree_skb() calls, for example. But then again, we had all of that ugly TSO partial-ACK trimming stuff. I'm going to do some profiling to make sure it really matters. From pavel@ucw.cz Thu May 12 15:51:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 15:51:36 -0700 (PDT) Received: from amd.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CMoQOv007939 for ; Thu, 12 May 2005 15:50:30 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id CD2B58CDE9; Fri, 13 May 2005 00:50:26 +0200 (CEST) Date: Fri, 13 May 2005 00:50:26 +0200 From: Pavel Machek To: jketreno@linux.intel.com, netdev@oss.sgi.com, kernel list Cc: jbohac@suse.cz, jbenc@suse.cz Subject: ipw2100: intrusive cleanups, working this time ;-) Message-ID: <20050512225026.GA2822@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.9i X-archive-position: 1066 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@ucw.cz Precedence: bulk X-list: netdev Content-Length: 28943 Lines: 1130 Hi! There's a lot to clean up in header file, too... And this time it actually works. Now, I'd like to clean it a bit more and then submit it to akpm for -mm series. Will someone hate me for doing that? Pavel --- clean-mm/drivers/net/wireless/ipw2100.c 2005-05-11 22:00:02.000000000 +0200 +++ linux-mm/drivers/net/wireless/ipw2100.c 2005-05-13 00:42:27.000000000 +0200 @@ -106,7 +106,7 @@ tx_pend_list : Holds used Tx buffers waiting to go into the TBD ring TAIL modified ipw2100_tx() - HEAD modified by X__ipw2100_tx_send_data() + HEAD modified by ipw2100_tx_send_data() msg_free_list : Holds pre-allocated Msg (Command) buffers TAIL modified in __ipw2100_tx_process() @@ -114,7 +114,7 @@ msg_pend_list : Holds used Msg buffers waiting to go into the TBD ring TAIL modified in ipw2100_hw_send_command() - HEAD modified in X__ipw2100_tx_send_commands() + HEAD modified in ipw2100_tx_send_commands() The flow of data on the TX side is as follows: @@ -150,7 +150,6 @@ #include #include #include -#define __KERNEL_SYSCALLS__ #include #include #include @@ -174,11 +173,6 @@ #define DRV_COPYRIGHT "Copyright(c) 2003-2004 Intel Corporation" -/* Debugging stuff */ -#ifdef CONFIG_IPW_DEBUG -#define CONFIG_IPW2100_RX_DEBUG /* Reception debugging */ -#endif - MODULE_DESCRIPTION(DRV_DESCRIPTION); MODULE_VERSION(DRV_VERSION); MODULE_AUTHOR(DRV_COPYRIGHT); @@ -189,9 +183,7 @@ static int channel = 0; static int associate = 1; static int disable = 0; -#ifdef CONFIG_PM static struct ipw2100_fw ipw2100_firmware; -#endif #include module_param(debug, int, 0444); @@ -286,8 +278,8 @@ /* Pre-decl until we get the code solid and then we can clean it up */ -static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv); -static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv); +static void ipw2100_tx_send_commands(struct ipw2100_priv *priv); +static void ipw2100_tx_send_data(struct ipw2100_priv *priv); static int ipw2100_adapter_setup(struct ipw2100_priv *priv); static void ipw2100_queues_initialize(struct ipw2100_priv *priv); @@ -735,8 +727,8 @@ list_add_tail(element, &priv->msg_pend_list); INC_STAT(&priv->msg_pend_stat); - X__ipw2100_tx_send_commands(priv); - X__ipw2100_tx_send_data(priv); + ipw2100_tx_send_commands(priv); + ipw2100_tx_send_data(priv); spin_unlock_irqrestore(&priv->low_lock, flags); @@ -915,12 +907,10 @@ if (i == 10000) return -EIO; /* TODO: better error value */ -//#if CONFIG_IPW2100_D0ENABLED /* set D0 standby bit */ read_register(priv->net_dev, IPW_REG_GP_CNTRL, &r); write_register(priv->net_dev, IPW_REG_GP_CNTRL, r | IPW_AUX_HOST_GP_CNTRL_BIT_HOST_ALLOWS_STANDBY); -//#endif return 0; } @@ -941,11 +931,6 @@ u32 address; int err; -#ifndef CONFIG_PM - /* Fetch the firmware and microcode */ - struct ipw2100_fw ipw2100_firmware; -#endif - if (priv->fatal_error) { IPW_DEBUG_ERROR("%s: ipw2100_download_firmware called after " "fatal error %d. Interface must be brought down.\n", @@ -953,7 +938,6 @@ return -EINVAL; } -#ifdef CONFIG_PM if (!ipw2100_firmware.version) { err = ipw2100_get_firmware(priv, &ipw2100_firmware); if (err) { @@ -963,15 +947,6 @@ goto fail; } } -#else - err = ipw2100_get_firmware(priv, &ipw2100_firmware); - if (err) { - IPW_DEBUG_ERROR("%s: ipw2100_get_firmware failed: %d\n", - priv->net_dev->name, err); - priv->fatal_error = IPW2100_ERR_FW_LOAD; - goto fail; - } -#endif priv->firmware_version = ipw2100_firmware.version; /* s/w reset and clock stabilization */ @@ -1026,18 +1001,6 @@ goto fail; } -#ifndef CONFIG_PM - /* - * When the .resume method of the driver is called, the other - * part of the system, i.e. the ide driver could still stay in - * the suspend stage. This prevents us from loading the firmware - * from the disk. --YZ - */ - - /* free any storage allocated for firmware image */ - ipw2100_release_firmware(priv, &ipw2100_firmware); -#endif - /* zero out Domain 1 area indirectly (Si requirement) */ for (address = IPW_HOST_FW_SHARED_AREA0; address < IPW_HOST_FW_SHARED_AREA0_END; address += 4) @@ -1083,8 +1046,6 @@ { struct ipw2100_ordinals *ord = &priv->ordinals; - IPW_DEBUG_INFO("enter\n"); - read_register(priv->net_dev, IPW_MEM_HOST_SHARED_ORDINALS_TABLE_1, &ord->table1_addr); @@ -1095,10 +1056,6 @@ read_nic_dword(priv->net_dev, ord->table2_addr, &ord->table2_size); ord->table2_size &= 0x0000FFFF; - - IPW_DEBUG_INFO("table 1 size: %d\n", ord->table1_size); - IPW_DEBUG_INFO("table 2 size: %d\n", ord->table2_size); - IPW_DEBUG_INFO("exit\n"); } static inline void ipw2100_hw_set_gpio(struct ipw2100_priv *priv) @@ -1117,7 +1074,6 @@ { #define MAX_RF_KILL_CHECKS 5 #define RF_KILL_CHECK_DELAY 40 -#define RF_KILL_CHECK_THRESHOLD 3 unsigned short value = 0; u32 reg = 0; @@ -1198,8 +1154,6 @@ int i; u32 inta, inta_mask, gpio; - IPW_DEBUG_INFO("enter\n"); - if (priv->status & STATUS_RUNNING) return 0; @@ -1286,9 +1240,6 @@ /* The adapter has been reset; we are not associated */ priv->status &= ~(STATUS_ASSOCIATING | STATUS_ASSOCIATED); - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -1598,8 +1549,6 @@ }; int err; - IPW_DEBUG_INFO("enter\n"); - IPW_DEBUG_SCAN("setting scan options\n"); cmd.host_command_parameters[0] = 0; @@ -1643,8 +1592,6 @@ return 0; } - IPW_DEBUG_INFO("enter\n"); - /* Not clearing here; doing so makes iwlist always return nothing... * * We should modify the table logic to use aging tables vs. clearing @@ -1657,8 +1604,6 @@ if (err) priv->status &= ~STATUS_SCANNING; - IPW_DEBUG_INFO("exit\n"); - return err; } @@ -2285,18 +2230,10 @@ * The size of the constructed ethernet * */ -#ifdef CONFIG_IPW2100_RX_DEBUG -u8 packet_data[IPW_RX_NIC_BUFFER_LENGTH]; -#endif static inline void ipw2100_corruption_detected(struct ipw2100_priv *priv, int i) { -#ifdef CONFIG_IPW_DEBUG_C3 - struct ipw2100_status *status = &priv->status_queue.drv[i]; - u32 match, reg; - int j; -#endif #ifdef ACPI_CSTATE_LIMIT_DEFINED int limit; #endif @@ -2314,35 +2251,6 @@ } #endif -#ifdef CONFIG_IPW_DEBUG_C3 - /* Halt the fimrware so we can get a good image */ - write_register(priv->net_dev, IPW_REG_RESET_REG, - IPW_AUX_HOST_RESET_REG_STOP_MASTER); - j = 5; - do { - udelay(IPW_WAIT_RESET_MASTER_ASSERT_COMPLETE_DELAY); - read_register(priv->net_dev, IPW_REG_RESET_REG, ®); - - if (reg & IPW_AUX_HOST_RESET_REG_MASTER_DISABLED) - break; - } while (j--); - - match = ipw2100_match_buf(priv, (u8*)status, - sizeof(struct ipw2100_status), - SEARCH_SNAPSHOT); - if (match < SEARCH_SUCCESS) - IPW_DEBUG_INFO("%s: DMA status match in Firmware at " - "offset 0x%06X, length %d:\n", - priv->net_dev->name, match, - sizeof(struct ipw2100_status)); - else - IPW_DEBUG_INFO("%s: No DMA status match in " - "Firmware.\n", priv->net_dev->name); - - printk_buf((u8*)priv->status_queue.drv, - sizeof(struct ipw2100_status) * RX_QUEUE_LENGTH); -#endif - priv->fatal_error = IPW2100_ERR_C3_CORRUPTION; priv->ieee->stats.rx_errors++; schedule_reset(priv); @@ -2394,19 +2302,7 @@ skb_put(packet->skb, status->frame_size); -#ifdef CONFIG_IPW2100_RX_DEBUG - /* Make a copy of the frame so we can dump it to the logs if - * ieee80211_rx fails */ - memcpy(packet_data, packet->skb->data, - min(status->frame_size, IPW_RX_NIC_BUFFER_LENGTH)); -#endif - if (!ieee80211_rx(priv->ieee, packet->skb, stats)) { -#ifdef CONFIG_IPW2100_RX_DEBUG - IPW_DEBUG_DROP("%s: Non consumed packet:\n", - priv->net_dev->name); - printk_buf(IPW_DL_DROP, packet_data, status->frame_size); -#endif priv->ieee->stats.rx_errors++; /* ieee80211_rx failed, so it didn't free the SKB */ @@ -2847,7 +2743,7 @@ } -static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv) +static void ipw2100_tx_send_commands(struct ipw2100_priv *priv) { struct list_head *element; struct ipw2100_tx_packet *packet; @@ -2915,10 +2811,10 @@ /* - * X__ipw2100_tx_send_data + * ipw2100_tx_send_data * */ -static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv) +static void ipw2100_tx_send_data(struct ipw2100_priv *priv) { struct list_head *element; struct ipw2100_tx_packet *packet; @@ -3133,8 +3029,8 @@ IPW2100_INTA_TX_TRANSFER); __ipw2100_tx_complete(priv); - X__ipw2100_tx_send_commands(priv); - X__ipw2100_tx_send_data(priv); + ipw2100_tx_send_commands(priv); + ipw2100_tx_send_data(priv); } if (inta & IPW2100_INTA_TX_COMPLETE) { @@ -3192,8 +3088,6 @@ ipw2100_enable_interrupts(priv); spin_unlock_irqrestore(&priv->low_lock, flags); - - IPW_DEBUG_ISR("exit\n"); } @@ -3285,7 +3179,7 @@ list_add_tail(element, &priv->tx_pend_list); INC_STAT(&priv->tx_pend_stat); - X__ipw2100_tx_send_data(priv); + ipw2100_tx_send_data(priv); spin_unlock_irqrestore(&priv->low_lock, flags); return 0; @@ -3662,96 +3556,6 @@ } static DEVICE_ATTR(hardware, S_IRUGO, show_hardware, NULL); - -static ssize_t show_memory(struct device *d, char *buf) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - struct net_device *dev = priv->net_dev; - static unsigned long loop = 0; - int len = 0; - u32 buffer[4]; - int i; - char line[81]; - - if (loop >= 0x30000) - loop = 0; - - /* sysfs provides us PAGE_SIZE buffer */ - while (len < PAGE_SIZE - 128 && loop < 0x30000) { - - if (priv->snapshot[0]) for (i = 0; i < 4; i++) - buffer[i] = *(u32 *)SNAPSHOT_ADDR(loop + i * 4); - else for (i = 0; i < 4; i++) - read_nic_dword(dev, loop + i * 4, &buffer[i]); - - if (priv->dump_raw) - len += sprintf(buf + len, - "%c%c%c%c" - "%c%c%c%c" - "%c%c%c%c" - "%c%c%c%c", - ((u8*)buffer)[0x0], - ((u8*)buffer)[0x1], - ((u8*)buffer)[0x2], - ((u8*)buffer)[0x3], - ((u8*)buffer)[0x4], - ((u8*)buffer)[0x5], - ((u8*)buffer)[0x6], - ((u8*)buffer)[0x7], - ((u8*)buffer)[0x8], - ((u8*)buffer)[0x9], - ((u8*)buffer)[0xa], - ((u8*)buffer)[0xb], - ((u8*)buffer)[0xc], - ((u8*)buffer)[0xd], - ((u8*)buffer)[0xe], - ((u8*)buffer)[0xf]); - else - len += sprintf(buf + len, "%s\n", - snprint_line(line, sizeof(line), - (u8*)buffer, 16, loop)); - loop += 16; - } - - return len; -} - -static ssize_t store_memory(struct device *d, const char *buf, size_t count) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - struct net_device *dev = priv->net_dev; - const char *p = buf; - - if (count < 1) - return count; - - if (p[0] == '1' || - (count >= 2 && tolower(p[0]) == 'o' && tolower(p[1]) == 'n')) { - IPW_DEBUG_INFO("%s: Setting memory dump to RAW mode.\n", - dev->name); - priv->dump_raw = 1; - - } else if (p[0] == '0' || (count >= 2 && tolower(p[0]) == 'o' && - tolower(p[1]) == 'f')) { - IPW_DEBUG_INFO("%s: Setting memory dump to HEX mode.\n", - dev->name); - priv->dump_raw = 0; - - } else if (tolower(p[0]) == 'r') { - IPW_DEBUG_INFO("%s: Resetting firmware snapshot.\n", - dev->name); - ipw2100_snapshot_free(priv); - - } else - IPW_DEBUG_INFO("%s: Usage: 0|on = HEX, 1|off = RAW, " - "reset = clear memory snapshot\n", - dev->name); - - return count; -} -static DEVICE_ATTR(memory, S_IWUSR|S_IRUGO, show_memory, store_memory); - - static ssize_t show_ordinals(struct device *d, char *buf) { struct ipw2100_priv *priv = dev_get_drvdata(d); @@ -3837,11 +3641,9 @@ priv->ieee->iw_mode = mode; -#ifdef CONFIG_PM /* Indicate ipw2100_download_firmware download firmware * from disk instead of memory. */ ipw2100_firmware.version = 0; -#endif printk(KERN_INFO "%s: Reseting on mode change.\n", priv->net_dev->name); @@ -4030,8 +3832,6 @@ unsigned long val; char *p = buffer; - IPW_DEBUG_INFO("enter\n"); - strncpy(buffer, buf, len); buffer[len] = 0; @@ -4049,8 +3849,6 @@ priv->ieee->scan_age = val; IPW_DEBUG_INFO("set scan_age = %u\n", priv->ieee->scan_age); } - - IPW_DEBUG_INFO("exit\n"); return len; } static DEVICE_ATTR(scan_age, S_IWUSR | S_IRUGO, show_scan_age, store_scan_age); @@ -4117,7 +3915,6 @@ &dev_attr_stats.attr, &dev_attr_internals.attr, &dev_attr_bssinfo.attr, - &dev_attr_memory.attr, &dev_attr_scan_age.attr, &dev_attr_fatal_error.attr, &dev_attr_rf_kill.attr, @@ -4136,8 +3933,6 @@ { struct ipw2100_status_queue *q = &priv->status_queue; - IPW_DEBUG_INFO("enter\n"); - q->size = entries * sizeof(struct ipw2100_status); q->drv = (struct ipw2100_status *)pci_alloc_consistent( priv->pci_dev, q->size, &q->nic); @@ -4148,31 +3943,22 @@ } memset(q->drv, 0, q->size); - - IPW_DEBUG_INFO("exit\n"); - return 0; } static void status_queue_free(struct ipw2100_priv *priv) { - IPW_DEBUG_INFO("enter\n"); - if (priv->status_queue.drv) { pci_free_consistent( priv->pci_dev, priv->status_queue.size, priv->status_queue.drv, priv->status_queue.nic); priv->status_queue.drv = NULL; } - - IPW_DEBUG_INFO("exit\n"); } static int bd_queue_allocate(struct ipw2100_priv *priv, struct ipw2100_bd_queue *q, int entries) { - IPW_DEBUG_INFO("enter\n"); - memset(q, 0, sizeof(struct ipw2100_bd_queue)); q->entries = entries; @@ -4183,17 +3969,12 @@ return -ENOMEM; } memset(q->drv, 0, q->size); - - IPW_DEBUG_INFO("exit\n"); - return 0; } static void bd_queue_free(struct ipw2100_priv *priv, struct ipw2100_bd_queue *q) { - IPW_DEBUG_INFO("enter\n"); - if (!q) return; @@ -4202,24 +3983,18 @@ q->size, q->drv, q->nic); q->drv = NULL; } - - IPW_DEBUG_INFO("exit\n"); } static void bd_queue_initialize( struct ipw2100_priv *priv, struct ipw2100_bd_queue * q, u32 base, u32 size, u32 r, u32 w) { - IPW_DEBUG_INFO("enter\n"); - IPW_DEBUG_INFO("initializing bd queue at virt=%p, phys=%08x\n", q->drv, q->nic); write_register(priv->net_dev, base, q->nic); write_register(priv->net_dev, size, q->entries); write_register(priv->net_dev, r, q->oldest); write_register(priv->net_dev, w, q->next); - - IPW_DEBUG_INFO("exit\n"); } static void ipw2100_kill_workqueue(struct ipw2100_priv *priv) @@ -4243,8 +4018,6 @@ void *v; dma_addr_t p; - IPW_DEBUG_INFO("enter\n"); - err = bd_queue_allocate(priv, &priv->tx_queue, TX_QUEUE_LENGTH); if (err) { IPW_DEBUG_ERROR("%s: failed bd_queue_allocate\n", @@ -4299,8 +4072,6 @@ { int i; - IPW_DEBUG_INFO("enter\n"); - /* * reinitialize packet info lists */ @@ -4339,17 +4110,12 @@ IPW_MEM_HOST_SHARED_TX_QUEUE_BD_SIZE, IPW_MEM_HOST_SHARED_TX_QUEUE_READ_INDEX, IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX); - - IPW_DEBUG_INFO("exit\n"); - } static void ipw2100_tx_free(struct ipw2100_priv *priv) { int i; - IPW_DEBUG_INFO("enter\n"); - bd_queue_free(priv, &priv->tx_queue); if (!priv->tx_buffers) @@ -4370,8 +4136,6 @@ kfree(priv->tx_buffers); priv->tx_buffers = NULL; - - IPW_DEBUG_INFO("exit\n"); } @@ -4380,8 +4144,6 @@ { int i, j, err = -EINVAL; - IPW_DEBUG_INFO("enter\n"); - err = bd_queue_allocate(priv, &priv->rx_queue, RX_QUEUE_LENGTH); if (err) { IPW_DEBUG_INFO("failed bd_queue_allocate\n"); @@ -4448,8 +4210,6 @@ static void ipw2100_rx_initialize(struct ipw2100_priv *priv) { - IPW_DEBUG_INFO("enter\n"); - priv->rx_queue.oldest = 0; priv->rx_queue.available = priv->rx_queue.entries - 1; priv->rx_queue.next = priv->rx_queue.entries - 1; @@ -4466,16 +4226,12 @@ /* set up the status queue */ write_register(priv->net_dev, IPW_MEM_HOST_SHARED_RX_STATUS_BASE, priv->status_queue.nic); - - IPW_DEBUG_INFO("exit\n"); } static void ipw2100_rx_free(struct ipw2100_priv *priv) { int i; - IPW_DEBUG_INFO("enter\n"); - bd_queue_free(priv, &priv->rx_queue); status_queue_free(priv); @@ -4494,8 +4250,6 @@ kfree(priv->rx_buffers); priv->rx_buffers = NULL; - - IPW_DEBUG_INFO("exit\n"); } static int ipw2100_read_mac_address(struct ipw2100_priv *priv) @@ -4536,8 +4290,6 @@ IPW_DEBUG_HC("SET_MAC_ADDRESS\n"); - IPW_DEBUG_INFO("enter\n"); - if (priv->config & CFG_CUSTOM_MAC) { memcpy(cmd.host_command_parameters, priv->mac_addr, ETH_ALEN); @@ -4547,8 +4299,6 @@ ETH_ALEN); err = ipw2100_hw_send_command(priv, &cmd); - - IPW_DEBUG_INFO("exit\n"); return err; } @@ -4805,47 +4555,6 @@ return 0; } -#if 0 -int ipw2100_set_fragmentation_threshold(struct ipw2100_priv *priv, - u32 threshold, int batch_mode) -{ - struct host_command cmd = { - .host_command = FRAG_THRESHOLD, - .host_command_sequence = 0, - .host_command_length = 4, - .host_command_parameters[0] = 0, - }; - int err; - - if (!batch_mode) { - err = ipw2100_disable_adapter(priv); - if (err) - return err; - } - - if (threshold == 0) - threshold = DEFAULT_FRAG_THRESHOLD; - else { - threshold = max(threshold, MIN_FRAG_THRESHOLD); - threshold = min(threshold, MAX_FRAG_THRESHOLD); - } - - cmd.host_command_parameters[0] = threshold; - - IPW_DEBUG_HC("FRAG_THRESHOLD: %u\n", threshold); - - err = ipw2100_hw_send_command(priv, &cmd); - - if (!batch_mode) - ipw2100_enable_adapter(priv); - - if (!err) - priv->frag_threshold = threshold; - - return err; -} -#endif - int ipw2100_set_short_retry(struct ipw2100_priv *priv, u32 retry) { struct host_command cmd = { @@ -4935,8 +4644,6 @@ int err; int len; - IPW_DEBUG_HC("DISASSOCIATION_BSSID\n"); - len = ETH_ALEN; /* The Firmware currently ignores the BSSID and just disassociates from * the currently associated AP -- but in the off chance that a future @@ -4950,37 +4657,6 @@ } #endif -/* - * Pseudo code for setting up wpa_frame: - */ -#if 0 -void x(struct ieee80211_assoc_frame *wpa_assoc) -{ - struct ipw2100_wpa_assoc_frame frame; - frame->fixed_ie_mask = IPW_WPA_CAPABILTIES | - IPW_WPA_LISTENINTERVAL | - IPW_WPA_AP_ADDRESS; - frame->capab_info = wpa_assoc->capab_info; - frame->lisen_interval = wpa_assoc->listent_interval; - memcpy(frame->current_ap, wpa_assoc->current_ap, ETH_ALEN); - - /* UNKNOWN -- I'm not postivive about this part; don't have any WPA - * setup here to test it with. - * - * Walk the IEs in the wpa_assoc and figure out the total size of all - * that data. Stick that into frame->var_ie_len. Then memcpy() all of - * the IEs from wpa_frame into frame. - */ - frame->var_ie_len = calculate_ie_len(wpa_assoc); - memcpy(frame->var_ie, wpa_assoc->variable, frame->var_ie_len); - - ipw2100_set_wpa_ie(priv, &frame, 0); -} -#endif - - - - static int ipw2100_set_wpa_ie(struct ipw2100_priv *, struct ipw2100_wpa_assoc_frame *, int) __attribute__ ((unused)); @@ -4996,8 +4672,6 @@ }; int err; - IPW_DEBUG_HC("SET_WPA_IE\n"); - if (!batch_mode) { err = ipw2100_disable_adapter(priv); if (err) @@ -5123,8 +4797,6 @@ cmd.host_command_parameters[0] = interval; - IPW_DEBUG_INFO("enter\n"); - if (priv->ieee->iw_mode == IW_MODE_ADHOC) { if (!batch_mode) { err = ipw2100_disable_adapter(priv); @@ -5140,9 +4812,6 @@ return err; } } - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -5502,8 +5171,6 @@ int batch_mode = 1; u8 *bssid; - IPW_DEBUG_INFO("enter\n"); - err = ipw2100_disable_adapter(priv); if (err) return err; @@ -5512,9 +5179,6 @@ err = ipw2100_set_channel(priv, priv->channel, batch_mode); if (err) return err; - - IPW_DEBUG_INFO("exit\n"); - return 0; } #endif /* CONFIG_IPW2100_MONITOR */ @@ -5591,9 +5255,6 @@ if (err) return err; */ - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -5656,8 +5317,6 @@ struct list_head *element; struct ipw2100_tx_packet *packet; - IPW_DEBUG_INFO("enter\n"); - spin_lock_irqsave(&priv->low_lock, flags); if (priv->status & STATUS_ASSOCIATED) @@ -5679,9 +5338,6 @@ INC_STAT(&priv->tx_free_stat); } spin_unlock_irqrestore(&priv->low_lock, flags); - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -6440,8 +6096,6 @@ int registered = 0; u32 val; - IPW_DEBUG_INFO("enter\n"); - mem_start = pci_resource_start(pci_dev, 0); mem_len = pci_resource_len(pci_dev, 0); mem_flags = pci_resource_flags(pci_dev, 0); @@ -6589,8 +6243,6 @@ ipw2100_start_scan(priv); } - IPW_DEBUG_INFO("exit\n"); - priv->status |= STATUS_INITIALIZED; up(&priv->action_sem); @@ -6644,10 +6296,9 @@ dev = priv->net_dev; sysfs_remove_group(&pci_dev->dev.kobj, &ipw2100_attribute_group); -#ifdef CONFIG_PM if (ipw2100_firmware.version) ipw2100_release_firmware(priv, &ipw2100_firmware); -#endif + /* Take down the hardware */ ipw2100_down(priv); @@ -6680,17 +6331,11 @@ pci_release_regions(pci_dev); pci_disable_device(pci_dev); - - IPW_DEBUG_INFO("exit\n"); } #ifdef CONFIG_PM -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) -static int ipw2100_suspend(struct pci_dev *pci_dev, u32 state) -#else static int ipw2100_suspend(struct pci_dev *pci_dev, pm_message_t state) -#endif { struct ipw2100_priv *priv = pci_get_drvdata(pci_dev); struct net_device *dev = priv->net_dev; @@ -6707,17 +6352,9 @@ /* Remove the PRESENT state of the device */ netif_device_detach(dev); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) - pci_save_state(pci_dev, priv->pm_state); -#else pci_save_state(pci_dev); -#endif pci_disable_device (pci_dev); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) - pci_set_power_state(pci_dev, state); -#else pci_set_power_state(pci_dev, PCI_D3hot); -#endif up(&priv->action_sem); @@ -6738,17 +6375,9 @@ IPW_DEBUG_INFO("%s: Coming out of suspend...\n", dev->name); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) - pci_set_power_state(pci_dev, 0); -#else pci_set_power_state(pci_dev, PCI_D0); -#endif pci_enable_device(pci_dev); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) - pci_restore_state(pci_dev, priv->pm_state); -#else pci_restore_state(pci_dev); -#endif /* * Suspend/Resume resets the PCI configuration space, so we have to @@ -8295,8 +7924,6 @@ down(&priv->action_sem); - IPW_DEBUG_WX("enter\n"); - up(&priv->action_sem); wrqu.ap_addr.sa_family = ARPHRD_ETHER; Only in linux-mm/drivers/net/wireless: ipw2100.c.bad Only in linux-mm/drivers/net/wireless: ipw2100.c.good --- clean-mm/drivers/net/wireless/ipw2100.h 2005-05-11 22:00:02.000000000 +0200 +++ linux-mm/drivers/net/wireless/ipw2100.h 2005-05-13 00:44:39.000000000 +0200 @@ -44,30 +44,6 @@ #include -#ifndef IRQ_NONE -typedef void irqreturn_t; -#define IRQ_NONE -#define IRQ_HANDLED -#define IRQ_RETVAL(x) -#endif - -#if WIRELESS_EXT < 17 -#define IW_QUAL_QUAL_INVALID 0x10 -#define IW_QUAL_LEVEL_INVALID 0x20 -#define IW_QUAL_NOISE_INVALID 0x40 -#endif - -#if ( LINUX_VERSION_CODE < KERNEL_VERSION(2,6,5) ) -#define pci_dma_sync_single_for_cpu pci_dma_sync_single -#define pci_dma_sync_single_for_device pci_dma_sync_single -#endif - -#ifndef HAVE_FREE_NETDEV -#define free_netdev(x) kfree(x) -#endif - - - struct ipw2100_priv; struct ipw2100_tx_packet; struct ipw2100_rx_packet; @@ -167,15 +143,6 @@ #define IPW_DEBUG_STATE(f, a...) IPW_DEBUG(IPW_DL_STATE | IPW_DL_ASSOC | IPW_DL_INFO, f, ## a) #define IPW_DEBUG_ASSOC(f, a...) IPW_DEBUG(IPW_DL_ASSOC | IPW_DL_INFO, f, ## a) - -#define VERIFY(f) \ -{ \ - int status = 0; \ - status = f; \ - if(status) \ - return status; \ -} - enum { IPW_HW_STATE_DISABLED = 1, IPW_HW_STATE_ENABLED = 0 @@ -210,8 +177,6 @@ } info; } __attribute__ ((packed)); -#define IPW_BUFDESC_LAST_FRAG 0 - struct ipw2100_bd { u32 host_addr; u32 buf_length; @@ -355,7 +320,7 @@ u16 fragment_size; } __attribute__ ((packed)); -// Host command data structure +/* Host command data structure */ struct host_command { u32 host_command; // COMMAND ID u32 host_command1; // COMMAND ID @@ -473,13 +438,8 @@ /* Power management code: enable or disable? */ enum { -#ifdef CONFIG_PM IPW2100_PM_DISABLED = 0, PM_STATE_SIZE = 16, -#else - IPW2100_PM_DISABLED = 1, - PM_STATE_SIZE = 0, -#endif }; #define STATUS_POWERED (1<<0) @@ -648,9 +608,6 @@ struct semaphore adapter_sem; wait_queue_head_t wait_command_queue; -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) - u32 pm_state[PM_STATE_SIZE]; -#endif }; @@ -701,7 +658,7 @@ #define MSDU_TX_RATES 62 -// Rogue AP Detection +/* Rogue AP Detection */ #define SET_STATION_STAT_BITS 64 #define CLEAR_STATIONS_STAT_BITS 65 #define LEAP_ROGUE_MODE 66 //TODO tbw replaced by CFG_LEAP_ROGUE_AP @@ -711,25 +668,16 @@ -// system configuration bit mask: -//#define IPW_CFG_ANTENNA_SETTING 0x03 -//#define IPW_CFG_ANTENNA_A 0x01 -//#define IPW_CFG_ANTENNA_B 0x02 +/* system configuration bit mask: */ #define IPW_CFG_MONITOR 0x00004 -//#define IPW_CFG_TX_STATUS_ENABLE 0x00008 #define IPW_CFG_PREAMBLE_AUTO 0x00010 #define IPW_CFG_IBSS_AUTO_START 0x00020 -//#define IPW_CFG_KERBEROS_ENABLE 0x00040 #define IPW_CFG_LOOPBACK 0x00100 -//#define IPW_CFG_WNMP_PING_PASS 0x00200 -//#define IPW_CFG_DEBUG_ENABLE 0x00400 #define IPW_CFG_ANSWER_BCSSID_PROBE 0x00800 -//#define IPW_CFG_BT_PRIORITY 0x01000 #define IPW_CFG_BT_SIDEBAND_SIGNAL 0x02000 #define IPW_CFG_802_1x_ENABLE 0x04000 #define IPW_CFG_BSS_MASK 0x08000 #define IPW_CFG_IBSS_MASK 0x10000 -//#define IPW_CFG_DYNAMIC_CW 0x10000 #define IPW_SCAN_NOASSOCIATE (1<<0) #define IPW_SCAN_MIXED_CELL (1<<1) @@ -761,41 +709,6 @@ #define IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX \ (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND) - -#if 0 -#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x00) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x04) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x08) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0c) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x10) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x14) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x18) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x1c) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x80) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x84) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x88) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x8c) - -#define IPW_MEM_HOST_SHARED_TX_QUEUE_BD_BASE(QueueNum) \ - (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + (QueueNum<<3)) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_BD_SIZE(QueueNum) \ - (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0004+(QueueNum<<3)) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_READ_INDEX(QueueNum) \ - (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0080+(QueueNum<<2)) - -#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_WRITE_INDEX \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x00) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_WRITE_INDEX \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x04) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_WRITE_INDEX \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x08) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_WRITE_INDEX \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x0c) -#define IPW_MEM_HOST_SHARED_SLAVE_MODE_INT_REGISTER \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x78) - -#endif - #define IPW_MEM_HOST_SHARED_ORDINALS_TABLE_1 (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x180) #define IPW_MEM_HOST_SHARED_ORDINALS_TABLE_2 (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x184) @@ -913,7 +826,7 @@ } rx_data; } __attribute__ ((packed)); -// Bit 0-7 are for 802.11b tx rates - . Bit 5-7 are reserved +/* Bit 0-7 are for 802.11b tx rates - . Bit 5-7 are reserved */ #define TX_RATE_1_MBIT 0x0001 #define TX_RATE_2_MBIT 0x0002 #define TX_RATE_5_5_MBIT 0x0004 @@ -1193,7 +1106,6 @@ IPW_ORD_UCODE_VERSION, // Ucode Version IPW_ORD_HW_RF_SWITCH_STATE = 214, // HW RF Kill Switch State } ORDINALTABLE1; -//ENDOF TABLE1 // ordinal table 2 // Variable length data: -- Boycott Kodak -- for their patent abuse against Java. From davem@davemloft.net Thu May 12 15:53:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 15:53:45 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CMrfOv008434 for ; Thu, 12 May 2005 15:53:41 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWMXe-0008L4-Gd; Thu, 12 May 2005 15:52:30 -0700 Date: Thu, 12 May 2005 15:52:30 -0700 (PDT) Message-Id: <20050512.155230.132927874.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff From: "David S. Miller" In-Reply-To: <20050512221046.GA22136@gondor.apana.org.au> References: <20050512.131349.32715242.davem@davemloft.net> <20050512214744.GA21958@gondor.apana.org.au> <20050512221046.GA22136@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1067 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 771 Lines: 23 From: Herbert Xu Subject: Re: issue with new TCP TSO stuff Date: Fri, 13 May 2005 08:10:46 +1000 > Nevermind, you're comparing to the existing TSO implementation. > So how big exactly is the slowdown? The "scp largefile dest:" test case went down from 4.6MB/sec to 4.3MB/sec when I enable TSO on the tg3 device with the new TSO code. So that drop is relative to non-TSO. That's how I knew there was some trouble. TSO should definitely not have more overhead that non-TSO. For a clean transfer bulk transfer which is not application limited like scp is, we get full line rate. But that doesn't show how expensive TSO is, since the link is the bottleneck not the cpu. > This just occured to me, what about NETIF_F_SKBLIST? Sounds ok. From herbert@gondor.apana.org.au Thu May 12 16:11:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 16:11:24 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CNBGOv009612 for ; Thu, 12 May 2005 16:11:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWMpE-0002BR-00; Fri, 13 May 2005 09:10:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWMpC-0005qk-00; Fri, 13 May 2005 09:10:38 +1000 Date: Fri, 13 May 2005 09:10:38 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff Message-ID: <20050512231038.GA22440@gondor.apana.org.au> References: <20050512.131349.32715242.davem@davemloft.net> <20050512214744.GA21958@gondor.apana.org.au> <20050512221046.GA22136@gondor.apana.org.au> <20050512.155230.132927874.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512.155230.132927874.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1068 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1066 Lines: 27 On Thu, May 12, 2005 at 03:52:30PM -0700, David S. Miller wrote: > > The "scp largefile dest:" test case went down from 4.6MB/sec > to 4.3MB/sec when I enable TSO on the tg3 device with the > new TSO code. OK, I'm sure we can optimise the code so that it beats the non-TSO case. However, I think you're right that this does have some fundamental overheads compared to the existing TSO code which we can't remove. More specifically, the existing TSO code really does avoid segmentation in that no MTU-sized skb's are allocated unless the congestion window requires that to be done. The new code will always allocate MTU-sized skb's no matter what. The ideal solution should bring the best of both worlds :) That is, no segmentation on output unless required by the congestion window, while at the same time avoiding the tcp_skb_pcount logic. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Thu May 12 16:25:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 16:25:42 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CNPdOv014354 for ; Thu, 12 May 2005 16:25:39 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWN2Y-0008OX-Bu; Thu, 12 May 2005 16:24:26 -0700 Date: Thu, 12 May 2005 16:24:26 -0700 (PDT) Message-Id: <20050512.162426.75782784.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff From: "David S. Miller" In-Reply-To: <20050512231038.GA22440@gondor.apana.org.au> References: <20050512221046.GA22136@gondor.apana.org.au> <20050512.155230.132927874.davem@davemloft.net> <20050512231038.GA22440@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1069 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2269 Lines: 50 From: Herbert Xu Subject: Re: issue with new TCP TSO stuff Date: Fri, 13 May 2005 09:10:38 +1000 > However, I think you're right that this does have some fundamental > overheads compared to the existing TSO code which we can't remove. > > More specifically, the existing TSO code really does avoid > segmentation in that no MTU-sized skb's are allocated unless > the congestion window requires that to be done. The new code > will always allocate MTU-sized skb's no matter what. > > The ideal solution should bring the best of both worlds :) That is, > no segmentation on output unless required by the congestion window, > while at the same time avoiding the tcp_skb_pcount logic. Right. Ok, the two true downfalls of the current TSO code are: 1) It does not attempt to predict what the CWND will be at packet output time. So smaller than ideal TSO frames are built. 2) Packet loss is not handled gracefully, in fact TSO is disabled when this happens :-) So, I'm mentioning this because it may end up being better to try and solve those two problems instead of going to my new stuff. #2 could be handled by down-sizing TSO frames when packet loss occurs. Ie. tcp_retransmit_skb() or whatever will segmentize a TSO packet which is within the sequence it is trying to retransmit. Implementing this is non- trivial mostly due to the fact that it has to work handle GFP_ATOMIC memory failures and also get all the pcount crap correct. #1 is more tricky, and is the main reason I explored the "TSO Reloaded" idea. I wonder if we could just build enormous TSO frames _always_. We pass down these huge things to the output path, with a struct sk_buff local offset and size. That way, if the packet is too large for the congestion window, we're fine, we just set the offset and size appropriately. I think the tcp_snd_test() simplifications made by my TSO Reloaded patch would help a lot here. The send test is logically now split to it's two tests 1) whether to send anything at all, and 2) once #1 passes, how many such packets. This would be a sort of super-TSO that would do less segmenting work than even a "perfect" TSO segmenter would. I'm still not sure which approach is best, just throwing around some ideas. From tgraf@suug.ch Thu May 12 16:32:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 16:32:44 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CNWfOv015195 for ; Thu, 12 May 2005 16:32:41 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 87D591C0EB; Fri, 13 May 2005 01:32:35 +0200 (CEST) Date: Fri, 13 May 2005 01:32:35 +0200 From: Thomas Graf To: Jonathan Day Cc: netdev@oss.sgi.com Subject: Re: Questions wrt QoS code on Linux Message-ID: <20050512233235.GJ28419@postel.suug.ch> References: <20050512190721.17518.qmail@web31508.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512190721.17518.qmail@web31508.mail.mud.yahoo.com> X-archive-position: 1070 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2504 Lines: 67 * Jonathan Day <20050512190721.17518.qmail@web31508.mail.mud.yahoo.com> 2005-05-12 12:07 > You've actually got another bit in there which > determines the ordering of the packets. a FIFO queue > won't be ordered the same as a PRIO queue, for > example. I don't see the point why we should draw a line between something like PRIO and CBQ, I would agree that dsmark should be splitted though. > A completely seperate stage is then needed to actually > gather the packets from the queue(s). You might drain > one queue completely before moving onto the next, you > might work in a round-robin manner, you might even > give a queue a fixed timeslice and grab as many > packets as possible within that slice before moving > on. a) The qdisc _must_ be able to define the ordering, otherwise we cannot do rate limiting correctly. b) You definitely don't want reordering inside flows and the qdisc is the only player that is aware of the right ordering. > An additional section handles the case where the > network is overloaded. You can drop packets early, by > using systems like RED, BLUE, GREEN or BLACK. (Of > these, only RED and the variant GRED are in Linux at > the moment.) The current RED implementation uses a queue and its length as criteria for the congestion probability. However, I do agree that in theory this should be implemented differently, the detection and marking should take place before the queue possibly via actions. This would also easly allow for (colored) TSW and EWMA rate estimators to be put in front. Surely everyone can agree that there is potential in this area and I hope someone brave stands up one day doing all the work. > At present, the Linux QoS menu is confusing. CBQ is > listed as a packet scheduler, when it in fact queues > the packets, rather than schedules them. RED is marked > as a queue, whereas it really filters, it doesn't > queue. The menu really can be improved and I think such a patch would get accepted, although please leave the qdiscs alone for now. ;-> > 1. Rename the sched directory to qos I don't see any improvement comming along with change as well. > 2. Add a sched subdirectory and move the schedulers > into it > 3. Add a queue subdirectory and move the queue > handlers into it > 4. Add a classifier subdirectory and move the packet > classifiers into it > 5. Add a processor subdirectory and move all code for > processing packets (such as RED) into it I think the (sch_|cls_|em_) prefixes are just fine for now. From herbert@gondor.apana.org.au Thu May 12 16:53:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 16:53:18 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4CNrAOv016172 for ; Thu, 12 May 2005 16:53:11 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWNTq-0002Yg-00; Fri, 13 May 2005 09:52:38 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWNTo-0005vJ-00; Fri, 13 May 2005 09:52:36 +1000 Date: Fri, 13 May 2005 09:52:36 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff Message-ID: <20050512235236.GA22658@gondor.apana.org.au> References: <20050512221046.GA22136@gondor.apana.org.au> <20050512.155230.132927874.davem@davemloft.net> <20050512231038.GA22440@gondor.apana.org.au> <20050512.162426.75782784.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512.162426.75782784.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1071 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1814 Lines: 45 On Thu, May 12, 2005 at 04:24:26PM -0700, David S. Miller wrote: > > Ok, the two true downfalls of the current TSO code are: You're spot on. > #2 could be handled by down-sizing TSO frames when packet loss occurs. > Ie. tcp_retransmit_skb() or whatever will segmentize a TSO packet > which is within the sequence it is trying to retransmit. Implementing > this is non- trivial mostly due to the fact that it has to work handle > GFP_ATOMIC memory failures and also get all the pcount crap correct. I think most of the code to do that might already be there. Pity we'll have to keep track of the pcount though. > #1 is more tricky, and is the main reason I explored the "TSO > Reloaded" idea. I wonder if we could just build enormous TSO frames > _always_. We pass down these huge things to the output path, with a I agree that this is the way to go. > and size appropriately. I think the tcp_snd_test() simplifications > made by my TSO Reloaded patch would help a lot here. The send test is > logically now split to it's two tests 1) whether to send anything at > all, and 2) once #1 passes, how many such packets. That was another one of my comments to your patch :) I was going to suggest that we move the cwnd/in_flight loop from tcp_snd_test to emit_send_queue. > This would be a sort of super-TSO that would do less segmenting work > than even a "perfect" TSO segmenter would. > > I'm still not sure which approach is best, just throwing around some > ideas. On paper your new super-TSO approach sounds the best. However, I suppose we won't know for sure until we try :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bunk@stusta.de Thu May 12 17:48:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 17:48:06 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4D0luOv018593 for ; Thu, 12 May 2005 17:47:59 -0700 Received: (qmail 18491 invoked from network); 13 May 2005 00:47:28 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 13 May 2005 00:47:28 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 2360FBB5E5; Fri, 13 May 2005 02:47:28 +0200 (CEST) Date: Fri, 13 May 2005 02:47:28 +0200 From: Adrian Bunk To: Andrew Morton Cc: sailer@ife.ee.ethz.ch, linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: [2.6 patch] drivers/net/hamradio/baycom_epp.c: cleanups Message-ID: <20050513004728.GT3603@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 1072 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 6527 Lines: 186 The times when tricky goto's produced better codes are long gone. This patch should express the same in a better way. Signed-off-by: Adrian Bunk --- This patch was already sent on: - 30 Apr 2005 - 20 Apr 2005 drivers/net/hamradio/baycom_epp.c | 126 ++++++++---------------------- 1 files changed, 36 insertions(+), 90 deletions(-) --- linux-2.6.12-rc2-mm3/drivers/net/hamradio/baycom_epp.c.old 2005-04-20 16:18:47.000000000 +0200 +++ linux-2.6.12-rc2-mm3/drivers/net/hamradio/baycom_epp.c 2005-04-20 17:14:36.000000000 +0200 @@ -374,29 +374,6 @@ } /* --------------------------------------------------------------------- */ -/* - * high performance HDLC encoder - * yes, it's ugly, but generates pretty good code - */ - -#define ENCODEITERA(j) \ -({ \ - if (!(notbitstream & (0x1f0 << j))) \ - goto stuff##j; \ - encodeend##j: ; \ -}) - -#define ENCODEITERB(j) \ -({ \ - stuff##j: \ - bitstream &= ~(0x100 << j); \ - bitbuf = (bitbuf & (((2 << j) << numbit) - 1)) | \ - ((bitbuf & ~(((2 << j) << numbit) - 1)) << 1); \ - numbit++; \ - notbitstream = ~bitstream; \ - goto encodeend##j; \ -}) - static void encode_hdlc(struct baycom_state *bc) { @@ -405,6 +382,7 @@ int pkt_len; unsigned bitstream, notbitstream, bitbuf, numbit, crc; unsigned char crcarr[2]; + int j; if (bc->hdlctx.bufcnt > 0) return; @@ -429,24 +407,14 @@ pkt_len--; if (!pkt_len) bp = crcarr; - ENCODEITERA(0); - ENCODEITERA(1); - ENCODEITERA(2); - ENCODEITERA(3); - ENCODEITERA(4); - ENCODEITERA(5); - ENCODEITERA(6); - ENCODEITERA(7); - goto enditer; - ENCODEITERB(0); - ENCODEITERB(1); - ENCODEITERB(2); - ENCODEITERB(3); - ENCODEITERB(4); - ENCODEITERB(5); - ENCODEITERB(6); - ENCODEITERB(7); - enditer: + for (j = 0; j < 8; j++) + if (unlikely(!(notbitstream & (0x1f0 << j)))) { + bitstream &= ~(0x100 << j); + bitbuf = (bitbuf & (((2 << j) << numbit) - 1)) | + ((bitbuf & ~(((2 << j) << numbit) - 1)) << 1); + numbit++; + notbitstream = ~bitstream; + } numbit += 8; while (numbit >= 8) { *wp++ = bitbuf; @@ -612,37 +580,6 @@ bc->stats.rx_packets++; } -#define DECODEITERA(j) \ -({ \ - if (!(notbitstream & (0x0fc << j))) /* flag or abort */ \ - goto flgabrt##j; \ - if ((bitstream & (0x1f8 << j)) == (0xf8 << j)) /* stuffed bit */ \ - goto stuff##j; \ - enditer##j: ; \ -}) - -#define DECODEITERB(j) \ -({ \ - flgabrt##j: \ - if (!(notbitstream & (0x1fc << j))) { /* abort received */ \ - state = 0; \ - goto enditer##j; \ - } \ - if ((bitstream & (0x1fe << j)) != (0x0fc << j)) /* flag received */ \ - goto enditer##j; \ - if (state) \ - do_rxpacket(dev); \ - bc->hdlcrx.bufcnt = 0; \ - bc->hdlcrx.bufptr = bc->hdlcrx.buf; \ - state = 1; \ - numbits = 7-j; \ - goto enditer##j; \ - stuff##j: \ - numbits--; \ - bitbuf = (bitbuf & ((~0xff) << j)) | ((bitbuf & ~((~0xff) << j)) << 1); \ - goto enditer##j; \ -}) - static int receive(struct net_device *dev, int cnt) { struct baycom_state *bc = netdev_priv(dev); @@ -651,6 +588,7 @@ unsigned char tmp[128]; unsigned char *cp; int cnt2, ret = 0; + int j; numbits = bc->hdlcrx.numbits; state = bc->hdlcrx.state; @@ -671,24 +609,32 @@ bitbuf |= (*cp) << 8; numbits += 8; notbitstream = ~bitstream; - DECODEITERA(0); - DECODEITERA(1); - DECODEITERA(2); - DECODEITERA(3); - DECODEITERA(4); - DECODEITERA(5); - DECODEITERA(6); - DECODEITERA(7); - goto enddec; - DECODEITERB(0); - DECODEITERB(1); - DECODEITERB(2); - DECODEITERB(3); - DECODEITERB(4); - DECODEITERB(5); - DECODEITERB(6); - DECODEITERB(7); - enddec: + for (j = 0; j < 8; j++) { + + /* flag or abort */ + if (unlikely(!(notbitstream & (0x0fc << j)))) { + + /* abort received */ + if (!(notbitstream & (0x1fc << j))) + state = 0; + + /* not flag received */ + else if (!(bitstream & (0x1fe << j)) != (0x0fc << j)) { + if (state) + do_rxpacket(dev); + bc->hdlcrx.bufcnt = 0; + bc->hdlcrx.bufptr = bc->hdlcrx.buf; + state = 1; + numbits = 7-j; + } + } + + /* stuffed bit */ + else if (unlikely((bitstream & (0x1f8 << j)) == (0xf8 << j))) { + numbits--; + bitbuf = (bitbuf & ((~0xff) << j)) | ((bitbuf & ~((~0xff) << j)) << 1); + } + } while (state && numbits >= 8) { if (bc->hdlcrx.bufcnt >= TXBUFFER_SIZE) { state = 0; From jketreno@linux.intel.com Thu May 12 17:53:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 17:53:04 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D0r1Ov019278 for ; Thu, 12 May 2005 17:53:01 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4D0qXat028150; Fri, 13 May 2005 00:52:33 GMT Received: from [192.168.1.154] (hdlrvguser-282.hd.intel.com [10.127.53.45]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j4D0qUYb011156; Fri, 13 May 2005 00:52:31 GMT Message-ID: <4283FA4D.3010208@linux.intel.com> Date: Thu, 12 May 2005 19:52:29 -0500 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pavel Machek CC: netdev@oss.sgi.com, kernel list , jbohac@suse.cz, jbenc@suse.cz Subject: Re: ipw2100: intrusive cleanups, working this time ;-) References: <20050512225026.GA2822@elf.ucw.cz> In-Reply-To: <20050512225026.GA2822@elf.ucw.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1073 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 30921 Lines: 1156 Pavel Machek wrote: >Hi! > >There's a lot to clean up in header file, too... And this time it >actually works. > >Now, I'd like to clean it a bit more and then submit it to akpm for >-mm series. Will someone hate me for doing that? > > Initial look over the patch looks reasonable; no functionality changes, just code reduction. That said, I would like to pass it through a quick validation cycle before its picked up. We submitted ipw2100-1.1.0 to netdev a month or so ago. I would like to see it go in to -mm through the netdev tree. I'll ask our QA folks to run this patch through a quick regression cycle here just to do a sanity check on it. Assuming nothing comes up, and if Jeff hasn't merged the ipw2100 code yet, I'll resubmit the ipw2100 driver w/ your patch applied. Part of the process we have in place is to try and make sure that the versions that get picked up by distros and the majority of users have a 'known' level of quality. As part of that, we only want to get changes pushed to -mm and eventual mainline that have gone through regression testing. Sound workable? Thanks, James > Pavel > >--- clean-mm/drivers/net/wireless/ipw2100.c 2005-05-11 22:00:02.000000000 +0200 >+++ linux-mm/drivers/net/wireless/ipw2100.c 2005-05-13 00:42:27.000000000 +0200 >@@ -106,7 +106,7 @@ > > tx_pend_list : Holds used Tx buffers waiting to go into the TBD ring > TAIL modified ipw2100_tx() >- HEAD modified by X__ipw2100_tx_send_data() >+ HEAD modified by ipw2100_tx_send_data() > > msg_free_list : Holds pre-allocated Msg (Command) buffers > TAIL modified in __ipw2100_tx_process() >@@ -114,7 +114,7 @@ > > msg_pend_list : Holds used Msg buffers waiting to go into the TBD ring > TAIL modified in ipw2100_hw_send_command() >- HEAD modified in X__ipw2100_tx_send_commands() >+ HEAD modified in ipw2100_tx_send_commands() > > The flow of data on the TX side is as follows: > >@@ -150,7 +150,6 @@ > #include > #include > #include >-#define __KERNEL_SYSCALLS__ > #include > #include > #include >@@ -174,11 +173,6 @@ > #define DRV_COPYRIGHT "Copyright(c) 2003-2004 Intel Corporation" > > >-/* Debugging stuff */ >-#ifdef CONFIG_IPW_DEBUG >-#define CONFIG_IPW2100_RX_DEBUG /* Reception debugging */ >-#endif >- > MODULE_DESCRIPTION(DRV_DESCRIPTION); > MODULE_VERSION(DRV_VERSION); > MODULE_AUTHOR(DRV_COPYRIGHT); >@@ -189,9 +183,7 @@ > static int channel = 0; > static int associate = 1; > static int disable = 0; >-#ifdef CONFIG_PM > static struct ipw2100_fw ipw2100_firmware; >-#endif > > #include > module_param(debug, int, 0444); >@@ -286,8 +278,8 @@ > > > /* Pre-decl until we get the code solid and then we can clean it up */ >-static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv); >-static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv); >+static void ipw2100_tx_send_commands(struct ipw2100_priv *priv); >+static void ipw2100_tx_send_data(struct ipw2100_priv *priv); > static int ipw2100_adapter_setup(struct ipw2100_priv *priv); > > static void ipw2100_queues_initialize(struct ipw2100_priv *priv); >@@ -735,8 +727,8 @@ > list_add_tail(element, &priv->msg_pend_list); > INC_STAT(&priv->msg_pend_stat); > >- X__ipw2100_tx_send_commands(priv); >- X__ipw2100_tx_send_data(priv); >+ ipw2100_tx_send_commands(priv); >+ ipw2100_tx_send_data(priv); > > spin_unlock_irqrestore(&priv->low_lock, flags); > >@@ -915,12 +907,10 @@ > if (i == 10000) > return -EIO; /* TODO: better error value */ > >-//#if CONFIG_IPW2100_D0ENABLED > /* set D0 standby bit */ > read_register(priv->net_dev, IPW_REG_GP_CNTRL, &r); > write_register(priv->net_dev, IPW_REG_GP_CNTRL, > r | IPW_AUX_HOST_GP_CNTRL_BIT_HOST_ALLOWS_STANDBY); >-//#endif > > return 0; > } >@@ -941,11 +931,6 @@ > u32 address; > int err; > >-#ifndef CONFIG_PM >- /* Fetch the firmware and microcode */ >- struct ipw2100_fw ipw2100_firmware; >-#endif >- > if (priv->fatal_error) { > IPW_DEBUG_ERROR("%s: ipw2100_download_firmware called after " > "fatal error %d. Interface must be brought down.\n", >@@ -953,7 +938,6 @@ > return -EINVAL; > } > >-#ifdef CONFIG_PM > if (!ipw2100_firmware.version) { > err = ipw2100_get_firmware(priv, &ipw2100_firmware); > if (err) { >@@ -963,15 +947,6 @@ > goto fail; > } > } >-#else >- err = ipw2100_get_firmware(priv, &ipw2100_firmware); >- if (err) { >- IPW_DEBUG_ERROR("%s: ipw2100_get_firmware failed: %d\n", >- priv->net_dev->name, err); >- priv->fatal_error = IPW2100_ERR_FW_LOAD; >- goto fail; >- } >-#endif > priv->firmware_version = ipw2100_firmware.version; > > /* s/w reset and clock stabilization */ >@@ -1026,18 +1001,6 @@ > goto fail; > } > >-#ifndef CONFIG_PM >- /* >- * When the .resume method of the driver is called, the other >- * part of the system, i.e. the ide driver could still stay in >- * the suspend stage. This prevents us from loading the firmware >- * from the disk. --YZ >- */ >- >- /* free any storage allocated for firmware image */ >- ipw2100_release_firmware(priv, &ipw2100_firmware); >-#endif >- > /* zero out Domain 1 area indirectly (Si requirement) */ > for (address = IPW_HOST_FW_SHARED_AREA0; > address < IPW_HOST_FW_SHARED_AREA0_END; address += 4) >@@ -1083,8 +1046,6 @@ > { > struct ipw2100_ordinals *ord = &priv->ordinals; > >- IPW_DEBUG_INFO("enter\n"); >- > read_register(priv->net_dev, IPW_MEM_HOST_SHARED_ORDINALS_TABLE_1, > &ord->table1_addr); > >@@ -1095,10 +1056,6 @@ > read_nic_dword(priv->net_dev, ord->table2_addr, &ord->table2_size); > > ord->table2_size &= 0x0000FFFF; >- >- IPW_DEBUG_INFO("table 1 size: %d\n", ord->table1_size); >- IPW_DEBUG_INFO("table 2 size: %d\n", ord->table2_size); >- IPW_DEBUG_INFO("exit\n"); > } > > static inline void ipw2100_hw_set_gpio(struct ipw2100_priv *priv) >@@ -1117,7 +1074,6 @@ > { > #define MAX_RF_KILL_CHECKS 5 > #define RF_KILL_CHECK_DELAY 40 >-#define RF_KILL_CHECK_THRESHOLD 3 > > unsigned short value = 0; > u32 reg = 0; >@@ -1198,8 +1154,6 @@ > int i; > u32 inta, inta_mask, gpio; > >- IPW_DEBUG_INFO("enter\n"); >- > if (priv->status & STATUS_RUNNING) > return 0; > >@@ -1286,9 +1240,6 @@ > > /* The adapter has been reset; we are not associated */ > priv->status &= ~(STATUS_ASSOCIATING | STATUS_ASSOCIATED); >- >- IPW_DEBUG_INFO("exit\n"); >- > return 0; > } > >@@ -1598,8 +1549,6 @@ > }; > int err; > >- IPW_DEBUG_INFO("enter\n"); >- > IPW_DEBUG_SCAN("setting scan options\n"); > > cmd.host_command_parameters[0] = 0; >@@ -1643,8 +1592,6 @@ > return 0; > } > >- IPW_DEBUG_INFO("enter\n"); >- > /* Not clearing here; doing so makes iwlist always return nothing... > * > * We should modify the table logic to use aging tables vs. clearing >@@ -1657,8 +1604,6 @@ > if (err) > priv->status &= ~STATUS_SCANNING; > >- IPW_DEBUG_INFO("exit\n"); >- > return err; > } > >@@ -2285,18 +2230,10 @@ > * The size of the constructed ethernet > * > */ >-#ifdef CONFIG_IPW2100_RX_DEBUG >-u8 packet_data[IPW_RX_NIC_BUFFER_LENGTH]; >-#endif > > static inline void ipw2100_corruption_detected(struct ipw2100_priv *priv, > int i) > { >-#ifdef CONFIG_IPW_DEBUG_C3 >- struct ipw2100_status *status = &priv->status_queue.drv[i]; >- u32 match, reg; >- int j; >-#endif > #ifdef ACPI_CSTATE_LIMIT_DEFINED > int limit; > #endif >@@ -2314,35 +2251,6 @@ > } > #endif > >-#ifdef CONFIG_IPW_DEBUG_C3 >- /* Halt the fimrware so we can get a good image */ >- write_register(priv->net_dev, IPW_REG_RESET_REG, >- IPW_AUX_HOST_RESET_REG_STOP_MASTER); >- j = 5; >- do { >- udelay(IPW_WAIT_RESET_MASTER_ASSERT_COMPLETE_DELAY); >- read_register(priv->net_dev, IPW_REG_RESET_REG, ®); >- >- if (reg & IPW_AUX_HOST_RESET_REG_MASTER_DISABLED) >- break; >- } while (j--); >- >- match = ipw2100_match_buf(priv, (u8*)status, >- sizeof(struct ipw2100_status), >- SEARCH_SNAPSHOT); >- if (match < SEARCH_SUCCESS) >- IPW_DEBUG_INFO("%s: DMA status match in Firmware at " >- "offset 0x%06X, length %d:\n", >- priv->net_dev->name, match, >- sizeof(struct ipw2100_status)); >- else >- IPW_DEBUG_INFO("%s: No DMA status match in " >- "Firmware.\n", priv->net_dev->name); >- >- printk_buf((u8*)priv->status_queue.drv, >- sizeof(struct ipw2100_status) * RX_QUEUE_LENGTH); >-#endif >- > priv->fatal_error = IPW2100_ERR_C3_CORRUPTION; > priv->ieee->stats.rx_errors++; > schedule_reset(priv); >@@ -2394,19 +2302,7 @@ > > skb_put(packet->skb, status->frame_size); > >-#ifdef CONFIG_IPW2100_RX_DEBUG >- /* Make a copy of the frame so we can dump it to the logs if >- * ieee80211_rx fails */ >- memcpy(packet_data, packet->skb->data, >- min(status->frame_size, IPW_RX_NIC_BUFFER_LENGTH)); >-#endif >- > if (!ieee80211_rx(priv->ieee, packet->skb, stats)) { >-#ifdef CONFIG_IPW2100_RX_DEBUG >- IPW_DEBUG_DROP("%s: Non consumed packet:\n", >- priv->net_dev->name); >- printk_buf(IPW_DL_DROP, packet_data, status->frame_size); >-#endif > priv->ieee->stats.rx_errors++; > > /* ieee80211_rx failed, so it didn't free the SKB */ >@@ -2847,7 +2743,7 @@ > } > > >-static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv) >+static void ipw2100_tx_send_commands(struct ipw2100_priv *priv) > { > struct list_head *element; > struct ipw2100_tx_packet *packet; >@@ -2915,10 +2811,10 @@ > > > /* >- * X__ipw2100_tx_send_data >+ * ipw2100_tx_send_data > * > */ >-static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv) >+static void ipw2100_tx_send_data(struct ipw2100_priv *priv) > { > struct list_head *element; > struct ipw2100_tx_packet *packet; >@@ -3133,8 +3029,8 @@ > IPW2100_INTA_TX_TRANSFER); > > __ipw2100_tx_complete(priv); >- X__ipw2100_tx_send_commands(priv); >- X__ipw2100_tx_send_data(priv); >+ ipw2100_tx_send_commands(priv); >+ ipw2100_tx_send_data(priv); > } > > if (inta & IPW2100_INTA_TX_COMPLETE) { >@@ -3192,8 +3088,6 @@ > ipw2100_enable_interrupts(priv); > > spin_unlock_irqrestore(&priv->low_lock, flags); >- >- IPW_DEBUG_ISR("exit\n"); > } > > >@@ -3285,7 +3179,7 @@ > list_add_tail(element, &priv->tx_pend_list); > INC_STAT(&priv->tx_pend_stat); > >- X__ipw2100_tx_send_data(priv); >+ ipw2100_tx_send_data(priv); > > spin_unlock_irqrestore(&priv->low_lock, flags); > return 0; >@@ -3662,96 +3556,6 @@ > } > static DEVICE_ATTR(hardware, S_IRUGO, show_hardware, NULL); > >- >-static ssize_t show_memory(struct device *d, char *buf) >-{ >- struct ipw2100_priv *priv = dev_get_drvdata(d); >- struct net_device *dev = priv->net_dev; >- static unsigned long loop = 0; >- int len = 0; >- u32 buffer[4]; >- int i; >- char line[81]; >- >- if (loop >= 0x30000) >- loop = 0; >- >- /* sysfs provides us PAGE_SIZE buffer */ >- while (len < PAGE_SIZE - 128 && loop < 0x30000) { >- >- if (priv->snapshot[0]) for (i = 0; i < 4; i++) >- buffer[i] = *(u32 *)SNAPSHOT_ADDR(loop + i * 4); >- else for (i = 0; i < 4; i++) >- read_nic_dword(dev, loop + i * 4, &buffer[i]); >- >- if (priv->dump_raw) >- len += sprintf(buf + len, >- "%c%c%c%c" >- "%c%c%c%c" >- "%c%c%c%c" >- "%c%c%c%c", >- ((u8*)buffer)[0x0], >- ((u8*)buffer)[0x1], >- ((u8*)buffer)[0x2], >- ((u8*)buffer)[0x3], >- ((u8*)buffer)[0x4], >- ((u8*)buffer)[0x5], >- ((u8*)buffer)[0x6], >- ((u8*)buffer)[0x7], >- ((u8*)buffer)[0x8], >- ((u8*)buffer)[0x9], >- ((u8*)buffer)[0xa], >- ((u8*)buffer)[0xb], >- ((u8*)buffer)[0xc], >- ((u8*)buffer)[0xd], >- ((u8*)buffer)[0xe], >- ((u8*)buffer)[0xf]); >- else >- len += sprintf(buf + len, "%s\n", >- snprint_line(line, sizeof(line), >- (u8*)buffer, 16, loop)); >- loop += 16; >- } >- >- return len; >-} >- >-static ssize_t store_memory(struct device *d, const char *buf, size_t count) >-{ >- struct ipw2100_priv *priv = dev_get_drvdata(d); >- struct net_device *dev = priv->net_dev; >- const char *p = buf; >- >- if (count < 1) >- return count; >- >- if (p[0] == '1' || >- (count >= 2 && tolower(p[0]) == 'o' && tolower(p[1]) == 'n')) { >- IPW_DEBUG_INFO("%s: Setting memory dump to RAW mode.\n", >- dev->name); >- priv->dump_raw = 1; >- >- } else if (p[0] == '0' || (count >= 2 && tolower(p[0]) == 'o' && >- tolower(p[1]) == 'f')) { >- IPW_DEBUG_INFO("%s: Setting memory dump to HEX mode.\n", >- dev->name); >- priv->dump_raw = 0; >- >- } else if (tolower(p[0]) == 'r') { >- IPW_DEBUG_INFO("%s: Resetting firmware snapshot.\n", >- dev->name); >- ipw2100_snapshot_free(priv); >- >- } else >- IPW_DEBUG_INFO("%s: Usage: 0|on = HEX, 1|off = RAW, " >- "reset = clear memory snapshot\n", >- dev->name); >- >- return count; >-} >-static DEVICE_ATTR(memory, S_IWUSR|S_IRUGO, show_memory, store_memory); >- >- > static ssize_t show_ordinals(struct device *d, char *buf) > { > struct ipw2100_priv *priv = dev_get_drvdata(d); >@@ -3837,11 +3641,9 @@ > > priv->ieee->iw_mode = mode; > >-#ifdef CONFIG_PM > /* Indicate ipw2100_download_firmware download firmware > * from disk instead of memory. */ > ipw2100_firmware.version = 0; >-#endif > > printk(KERN_INFO "%s: Reseting on mode change.\n", > priv->net_dev->name); >@@ -4030,8 +3832,6 @@ > unsigned long val; > char *p = buffer; > >- IPW_DEBUG_INFO("enter\n"); >- > strncpy(buffer, buf, len); > buffer[len] = 0; > >@@ -4049,8 +3849,6 @@ > priv->ieee->scan_age = val; > IPW_DEBUG_INFO("set scan_age = %u\n", priv->ieee->scan_age); > } >- >- IPW_DEBUG_INFO("exit\n"); > return len; > } > static DEVICE_ATTR(scan_age, S_IWUSR | S_IRUGO, show_scan_age, store_scan_age); >@@ -4117,7 +3915,6 @@ > &dev_attr_stats.attr, > &dev_attr_internals.attr, > &dev_attr_bssinfo.attr, >- &dev_attr_memory.attr, > &dev_attr_scan_age.attr, > &dev_attr_fatal_error.attr, > &dev_attr_rf_kill.attr, >@@ -4136,8 +3933,6 @@ > { > struct ipw2100_status_queue *q = &priv->status_queue; > >- IPW_DEBUG_INFO("enter\n"); >- > q->size = entries * sizeof(struct ipw2100_status); > q->drv = (struct ipw2100_status *)pci_alloc_consistent( > priv->pci_dev, q->size, &q->nic); >@@ -4148,31 +3943,22 @@ > } > > memset(q->drv, 0, q->size); >- >- IPW_DEBUG_INFO("exit\n"); >- > return 0; > } > > static void status_queue_free(struct ipw2100_priv *priv) > { >- IPW_DEBUG_INFO("enter\n"); >- > if (priv->status_queue.drv) { > pci_free_consistent( > priv->pci_dev, priv->status_queue.size, > priv->status_queue.drv, priv->status_queue.nic); > priv->status_queue.drv = NULL; > } >- >- IPW_DEBUG_INFO("exit\n"); > } > > static int bd_queue_allocate(struct ipw2100_priv *priv, > struct ipw2100_bd_queue *q, int entries) > { >- IPW_DEBUG_INFO("enter\n"); >- > memset(q, 0, sizeof(struct ipw2100_bd_queue)); > > q->entries = entries; >@@ -4183,17 +3969,12 @@ > return -ENOMEM; > } > memset(q->drv, 0, q->size); >- >- IPW_DEBUG_INFO("exit\n"); >- > return 0; > } > > static void bd_queue_free(struct ipw2100_priv *priv, > struct ipw2100_bd_queue *q) > { >- IPW_DEBUG_INFO("enter\n"); >- > if (!q) > return; > >@@ -4202,24 +3983,18 @@ > q->size, q->drv, q->nic); > q->drv = NULL; > } >- >- IPW_DEBUG_INFO("exit\n"); > } > > static void bd_queue_initialize( > struct ipw2100_priv *priv, struct ipw2100_bd_queue * q, > u32 base, u32 size, u32 r, u32 w) > { >- IPW_DEBUG_INFO("enter\n"); >- > IPW_DEBUG_INFO("initializing bd queue at virt=%p, phys=%08x\n", q->drv, q->nic); > > write_register(priv->net_dev, base, q->nic); > write_register(priv->net_dev, size, q->entries); > write_register(priv->net_dev, r, q->oldest); > write_register(priv->net_dev, w, q->next); >- >- IPW_DEBUG_INFO("exit\n"); > } > > static void ipw2100_kill_workqueue(struct ipw2100_priv *priv) >@@ -4243,8 +4018,6 @@ > void *v; > dma_addr_t p; > >- IPW_DEBUG_INFO("enter\n"); >- > err = bd_queue_allocate(priv, &priv->tx_queue, TX_QUEUE_LENGTH); > if (err) { > IPW_DEBUG_ERROR("%s: failed bd_queue_allocate\n", >@@ -4299,8 +4072,6 @@ > { > int i; > >- IPW_DEBUG_INFO("enter\n"); >- > /* > * reinitialize packet info lists > */ >@@ -4339,17 +4110,12 @@ > IPW_MEM_HOST_SHARED_TX_QUEUE_BD_SIZE, > IPW_MEM_HOST_SHARED_TX_QUEUE_READ_INDEX, > IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX); >- >- IPW_DEBUG_INFO("exit\n"); >- > } > > static void ipw2100_tx_free(struct ipw2100_priv *priv) > { > int i; > >- IPW_DEBUG_INFO("enter\n"); >- > bd_queue_free(priv, &priv->tx_queue); > > if (!priv->tx_buffers) >@@ -4370,8 +4136,6 @@ > > kfree(priv->tx_buffers); > priv->tx_buffers = NULL; >- >- IPW_DEBUG_INFO("exit\n"); > } > > >@@ -4380,8 +4144,6 @@ > { > int i, j, err = -EINVAL; > >- IPW_DEBUG_INFO("enter\n"); >- > err = bd_queue_allocate(priv, &priv->rx_queue, RX_QUEUE_LENGTH); > if (err) { > IPW_DEBUG_INFO("failed bd_queue_allocate\n"); >@@ -4448,8 +4210,6 @@ > > static void ipw2100_rx_initialize(struct ipw2100_priv *priv) > { >- IPW_DEBUG_INFO("enter\n"); >- > priv->rx_queue.oldest = 0; > priv->rx_queue.available = priv->rx_queue.entries - 1; > priv->rx_queue.next = priv->rx_queue.entries - 1; >@@ -4466,16 +4226,12 @@ > /* set up the status queue */ > write_register(priv->net_dev, IPW_MEM_HOST_SHARED_RX_STATUS_BASE, > priv->status_queue.nic); >- >- IPW_DEBUG_INFO("exit\n"); > } > > static void ipw2100_rx_free(struct ipw2100_priv *priv) > { > int i; > >- IPW_DEBUG_INFO("enter\n"); >- > bd_queue_free(priv, &priv->rx_queue); > status_queue_free(priv); > >@@ -4494,8 +4250,6 @@ > > kfree(priv->rx_buffers); > priv->rx_buffers = NULL; >- >- IPW_DEBUG_INFO("exit\n"); > } > > static int ipw2100_read_mac_address(struct ipw2100_priv *priv) >@@ -4536,8 +4290,6 @@ > > IPW_DEBUG_HC("SET_MAC_ADDRESS\n"); > >- IPW_DEBUG_INFO("enter\n"); >- > if (priv->config & CFG_CUSTOM_MAC) { > memcpy(cmd.host_command_parameters, priv->mac_addr, > ETH_ALEN); >@@ -4547,8 +4299,6 @@ > ETH_ALEN); > > err = ipw2100_hw_send_command(priv, &cmd); >- >- IPW_DEBUG_INFO("exit\n"); > return err; > } > >@@ -4805,47 +4555,6 @@ > return 0; > } > >-#if 0 >-int ipw2100_set_fragmentation_threshold(struct ipw2100_priv *priv, >- u32 threshold, int batch_mode) >-{ >- struct host_command cmd = { >- .host_command = FRAG_THRESHOLD, >- .host_command_sequence = 0, >- .host_command_length = 4, >- .host_command_parameters[0] = 0, >- }; >- int err; >- >- if (!batch_mode) { >- err = ipw2100_disable_adapter(priv); >- if (err) >- return err; >- } >- >- if (threshold == 0) >- threshold = DEFAULT_FRAG_THRESHOLD; >- else { >- threshold = max(threshold, MIN_FRAG_THRESHOLD); >- threshold = min(threshold, MAX_FRAG_THRESHOLD); >- } >- >- cmd.host_command_parameters[0] = threshold; >- >- IPW_DEBUG_HC("FRAG_THRESHOLD: %u\n", threshold); >- >- err = ipw2100_hw_send_command(priv, &cmd); >- >- if (!batch_mode) >- ipw2100_enable_adapter(priv); >- >- if (!err) >- priv->frag_threshold = threshold; >- >- return err; >-} >-#endif >- > int ipw2100_set_short_retry(struct ipw2100_priv *priv, u32 retry) > { > struct host_command cmd = { >@@ -4935,8 +4644,6 @@ > int err; > int len; > >- IPW_DEBUG_HC("DISASSOCIATION_BSSID\n"); >- > len = ETH_ALEN; > /* The Firmware currently ignores the BSSID and just disassociates from > * the currently associated AP -- but in the off chance that a future >@@ -4950,37 +4657,6 @@ > } > #endif > >-/* >- * Pseudo code for setting up wpa_frame: >- */ >-#if 0 >-void x(struct ieee80211_assoc_frame *wpa_assoc) >-{ >- struct ipw2100_wpa_assoc_frame frame; >- frame->fixed_ie_mask = IPW_WPA_CAPABILTIES | >- IPW_WPA_LISTENINTERVAL | >- IPW_WPA_AP_ADDRESS; >- frame->capab_info = wpa_assoc->capab_info; >- frame->lisen_interval = wpa_assoc->listent_interval; >- memcpy(frame->current_ap, wpa_assoc->current_ap, ETH_ALEN); >- >- /* UNKNOWN -- I'm not postivive about this part; don't have any WPA >- * setup here to test it with. >- * >- * Walk the IEs in the wpa_assoc and figure out the total size of all >- * that data. Stick that into frame->var_ie_len. Then memcpy() all of >- * the IEs from wpa_frame into frame. >- */ >- frame->var_ie_len = calculate_ie_len(wpa_assoc); >- memcpy(frame->var_ie, wpa_assoc->variable, frame->var_ie_len); >- >- ipw2100_set_wpa_ie(priv, &frame, 0); >-} >-#endif >- >- >- >- > static int ipw2100_set_wpa_ie(struct ipw2100_priv *, > struct ipw2100_wpa_assoc_frame *, int) > __attribute__ ((unused)); >@@ -4996,8 +4672,6 @@ > }; > int err; > >- IPW_DEBUG_HC("SET_WPA_IE\n"); >- > if (!batch_mode) { > err = ipw2100_disable_adapter(priv); > if (err) >@@ -5123,8 +4797,6 @@ > > cmd.host_command_parameters[0] = interval; > >- IPW_DEBUG_INFO("enter\n"); >- > if (priv->ieee->iw_mode == IW_MODE_ADHOC) { > if (!batch_mode) { > err = ipw2100_disable_adapter(priv); >@@ -5140,9 +4812,6 @@ > return err; > } > } >- >- IPW_DEBUG_INFO("exit\n"); >- > return 0; > } > >@@ -5502,8 +5171,6 @@ > int batch_mode = 1; > u8 *bssid; > >- IPW_DEBUG_INFO("enter\n"); >- > err = ipw2100_disable_adapter(priv); > if (err) > return err; >@@ -5512,9 +5179,6 @@ > err = ipw2100_set_channel(priv, priv->channel, batch_mode); > if (err) > return err; >- >- IPW_DEBUG_INFO("exit\n"); >- > return 0; > } > #endif /* CONFIG_IPW2100_MONITOR */ >@@ -5591,9 +5255,6 @@ > if (err) > return err; > */ >- >- IPW_DEBUG_INFO("exit\n"); >- > return 0; > } > >@@ -5656,8 +5317,6 @@ > struct list_head *element; > struct ipw2100_tx_packet *packet; > >- IPW_DEBUG_INFO("enter\n"); >- > spin_lock_irqsave(&priv->low_lock, flags); > > if (priv->status & STATUS_ASSOCIATED) >@@ -5679,9 +5338,6 @@ > INC_STAT(&priv->tx_free_stat); > } > spin_unlock_irqrestore(&priv->low_lock, flags); >- >- IPW_DEBUG_INFO("exit\n"); >- > return 0; > } > >@@ -6440,8 +6096,6 @@ > int registered = 0; > u32 val; > >- IPW_DEBUG_INFO("enter\n"); >- > mem_start = pci_resource_start(pci_dev, 0); > mem_len = pci_resource_len(pci_dev, 0); > mem_flags = pci_resource_flags(pci_dev, 0); >@@ -6589,8 +6243,6 @@ > ipw2100_start_scan(priv); > } > >- IPW_DEBUG_INFO("exit\n"); >- > priv->status |= STATUS_INITIALIZED; > > up(&priv->action_sem); >@@ -6644,10 +6296,9 @@ > dev = priv->net_dev; > sysfs_remove_group(&pci_dev->dev.kobj, &ipw2100_attribute_group); > >-#ifdef CONFIG_PM > if (ipw2100_firmware.version) > ipw2100_release_firmware(priv, &ipw2100_firmware); >-#endif >+ > /* Take down the hardware */ > ipw2100_down(priv); > >@@ -6680,17 +6331,11 @@ > > pci_release_regions(pci_dev); > pci_disable_device(pci_dev); >- >- IPW_DEBUG_INFO("exit\n"); > } > > > #ifdef CONFIG_PM >-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) >-static int ipw2100_suspend(struct pci_dev *pci_dev, u32 state) >-#else > static int ipw2100_suspend(struct pci_dev *pci_dev, pm_message_t state) >-#endif > { > struct ipw2100_priv *priv = pci_get_drvdata(pci_dev); > struct net_device *dev = priv->net_dev; >@@ -6707,17 +6352,9 @@ > /* Remove the PRESENT state of the device */ > netif_device_detach(dev); > >-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) >- pci_save_state(pci_dev, priv->pm_state); >-#else > pci_save_state(pci_dev); >-#endif > pci_disable_device (pci_dev); >-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) >- pci_set_power_state(pci_dev, state); >-#else > pci_set_power_state(pci_dev, PCI_D3hot); >-#endif > > up(&priv->action_sem); > >@@ -6738,17 +6375,9 @@ > IPW_DEBUG_INFO("%s: Coming out of suspend...\n", > dev->name); > >-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) >- pci_set_power_state(pci_dev, 0); >-#else > pci_set_power_state(pci_dev, PCI_D0); >-#endif > pci_enable_device(pci_dev); >-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) >- pci_restore_state(pci_dev, priv->pm_state); >-#else > pci_restore_state(pci_dev); >-#endif > > /* > * Suspend/Resume resets the PCI configuration space, so we have to >@@ -8295,8 +7924,6 @@ > > down(&priv->action_sem); > >- IPW_DEBUG_WX("enter\n"); >- > up(&priv->action_sem); > > wrqu.ap_addr.sa_family = ARPHRD_ETHER; >Only in linux-mm/drivers/net/wireless: ipw2100.c.bad >Only in linux-mm/drivers/net/wireless: ipw2100.c.good >--- clean-mm/drivers/net/wireless/ipw2100.h 2005-05-11 22:00:02.000000000 +0200 >+++ linux-mm/drivers/net/wireless/ipw2100.h 2005-05-13 00:44:39.000000000 +0200 >@@ -44,30 +44,6 @@ > > #include > >-#ifndef IRQ_NONE >-typedef void irqreturn_t; >-#define IRQ_NONE >-#define IRQ_HANDLED >-#define IRQ_RETVAL(x) >-#endif >- >-#if WIRELESS_EXT < 17 >-#define IW_QUAL_QUAL_INVALID 0x10 >-#define IW_QUAL_LEVEL_INVALID 0x20 >-#define IW_QUAL_NOISE_INVALID 0x40 >-#endif >- >-#if ( LINUX_VERSION_CODE < KERNEL_VERSION(2,6,5) ) >-#define pci_dma_sync_single_for_cpu pci_dma_sync_single >-#define pci_dma_sync_single_for_device pci_dma_sync_single >-#endif >- >-#ifndef HAVE_FREE_NETDEV >-#define free_netdev(x) kfree(x) >-#endif >- >- >- > struct ipw2100_priv; > struct ipw2100_tx_packet; > struct ipw2100_rx_packet; >@@ -167,15 +143,6 @@ > #define IPW_DEBUG_STATE(f, a...) IPW_DEBUG(IPW_DL_STATE | IPW_DL_ASSOC | IPW_DL_INFO, f, ## a) > #define IPW_DEBUG_ASSOC(f, a...) IPW_DEBUG(IPW_DL_ASSOC | IPW_DL_INFO, f, ## a) > >- >-#define VERIFY(f) \ >-{ \ >- int status = 0; \ >- status = f; \ >- if(status) \ >- return status; \ >-} >- > enum { > IPW_HW_STATE_DISABLED = 1, > IPW_HW_STATE_ENABLED = 0 >@@ -210,8 +177,6 @@ > } info; > } __attribute__ ((packed)); > >-#define IPW_BUFDESC_LAST_FRAG 0 >- > struct ipw2100_bd { > u32 host_addr; > u32 buf_length; >@@ -355,7 +320,7 @@ > u16 fragment_size; > } __attribute__ ((packed)); > >-// Host command data structure >+/* Host command data structure */ > struct host_command { > u32 host_command; // COMMAND ID > u32 host_command1; // COMMAND ID >@@ -473,13 +438,8 @@ > > /* Power management code: enable or disable? */ > enum { >-#ifdef CONFIG_PM > IPW2100_PM_DISABLED = 0, > PM_STATE_SIZE = 16, >-#else >- IPW2100_PM_DISABLED = 1, >- PM_STATE_SIZE = 0, >-#endif > }; > > #define STATUS_POWERED (1<<0) >@@ -648,9 +608,6 @@ > struct semaphore adapter_sem; > > wait_queue_head_t wait_command_queue; >-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) >- u32 pm_state[PM_STATE_SIZE]; >-#endif > }; > > >@@ -701,7 +658,7 @@ > #define MSDU_TX_RATES 62 > > >-// Rogue AP Detection >+/* Rogue AP Detection */ > #define SET_STATION_STAT_BITS 64 > #define CLEAR_STATIONS_STAT_BITS 65 > #define LEAP_ROGUE_MODE 66 //TODO tbw replaced by CFG_LEAP_ROGUE_AP >@@ -711,25 +668,16 @@ > > > >-// system configuration bit mask: >-//#define IPW_CFG_ANTENNA_SETTING 0x03 >-//#define IPW_CFG_ANTENNA_A 0x01 >-//#define IPW_CFG_ANTENNA_B 0x02 >+/* system configuration bit mask: */ > #define IPW_CFG_MONITOR 0x00004 >-//#define IPW_CFG_TX_STATUS_ENABLE 0x00008 > #define IPW_CFG_PREAMBLE_AUTO 0x00010 > #define IPW_CFG_IBSS_AUTO_START 0x00020 >-//#define IPW_CFG_KERBEROS_ENABLE 0x00040 > #define IPW_CFG_LOOPBACK 0x00100 >-//#define IPW_CFG_WNMP_PING_PASS 0x00200 >-//#define IPW_CFG_DEBUG_ENABLE 0x00400 > #define IPW_CFG_ANSWER_BCSSID_PROBE 0x00800 >-//#define IPW_CFG_BT_PRIORITY 0x01000 > #define IPW_CFG_BT_SIDEBAND_SIGNAL 0x02000 > #define IPW_CFG_802_1x_ENABLE 0x04000 > #define IPW_CFG_BSS_MASK 0x08000 > #define IPW_CFG_IBSS_MASK 0x10000 >-//#define IPW_CFG_DYNAMIC_CW 0x10000 > > #define IPW_SCAN_NOASSOCIATE (1<<0) > #define IPW_SCAN_MIXED_CELL (1<<1) >@@ -761,41 +709,6 @@ > #define IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX \ > (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND) > >- >-#if 0 >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x00) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x04) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x08) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0c) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x10) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x14) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x18) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x1c) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x80) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x84) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x88) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x8c) >- >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_BD_BASE(QueueNum) \ >- (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + (QueueNum<<3)) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_BD_SIZE(QueueNum) \ >- (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0004+(QueueNum<<3)) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_READ_INDEX(QueueNum) \ >- (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0080+(QueueNum<<2)) >- >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_WRITE_INDEX \ >- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x00) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_WRITE_INDEX \ >- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x04) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_WRITE_INDEX \ >- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x08) >-#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_WRITE_INDEX \ >- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x0c) >-#define IPW_MEM_HOST_SHARED_SLAVE_MODE_INT_REGISTER \ >- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x78) >- >-#endif >- > #define IPW_MEM_HOST_SHARED_ORDINALS_TABLE_1 (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x180) > #define IPW_MEM_HOST_SHARED_ORDINALS_TABLE_2 (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x184) > >@@ -913,7 +826,7 @@ > } rx_data; > } __attribute__ ((packed)); > >-// Bit 0-7 are for 802.11b tx rates - . Bit 5-7 are reserved >+/* Bit 0-7 are for 802.11b tx rates - . Bit 5-7 are reserved */ > #define TX_RATE_1_MBIT 0x0001 > #define TX_RATE_2_MBIT 0x0002 > #define TX_RATE_5_5_MBIT 0x0004 >@@ -1193,7 +1106,6 @@ > IPW_ORD_UCODE_VERSION, // Ucode Version > IPW_ORD_HW_RF_SWITCH_STATE = 214, // HW RF Kill Switch State > } ORDINALTABLE1; >-//ENDOF TABLE1 > > // ordinal table 2 > // Variable length data: > > > From apache@mig.airside.co.uk.sgi.com Thu May 12 18:52:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 18:52:35 -0700 (PDT) Received: from mig.airside.co.uk (mig.airside.co.uk [83.138.128.103] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D1qSOv021677 for ; Thu, 12 May 2005 18:52:31 -0700 Received: from mig.airside.co.uk (localhost [127.0.0.1]) by mig.airside.co.uk (8.12.11/8.12.11) with ESMTP id j4D1r7Yh014655 for ; Fri, 13 May 2005 02:54:54 +0100 Received: (from apache@localhost) by mig.airside.co.uk (8.12.11/8.12.11/Submit) id j4D1RLaO006518; Fri, 13 May 2005 02:27:21 +0100 Date: Fri, 13 May 2005 02:27:21 +0100 From: Apache Message-Id: <200505130127.j4D1RLaO006518@mig.airside.co.uk> To: netdev@oss.sgi.com Subject: Lost subscribers to Airside and Lemon Jelly mailing lists Content-type: text/plain; charset=iso-8859-1 X-archive-position: 1074 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: apache@mig.airside.co.uk.sgi.com Precedence: bulk X-list: netdev Content-Length: 2194 Lines: 41 Dear all, We are contacting you from Airside, a design company based in London. Due to the failure of a web server and the host company back up, some subscribers to our mailing lists were lost. Since then, however, the email addresses that were on the lists have been recovered, but annoyingly we have no idea who was subscribing to which list. So we would very much appreciate if you could re-subscribe yourself appropriately from the website mailing lists provided below. If you choose to not re-subscribe, no problem and thanks for your patience. ––––––––––––––––––––––––––––––––––––––––––––––––– Lemon Jelly: http://www.airside.co.uk/redirect.php?mailing_history_id=63&user_id=631178&url=www.lemonjelly.ky Airside: http://www.airside.co.uk/redirect.php?mailing_history_id=63&user_id=631178&url=www.airside.co.uk%2Fjoin%2Fsubscribe.html Airside Shop: http://www.airside.co.uk/redirect.php?mailing_history_id=63&user_id=631178&url=www.airsideshop.com%2Finfo.php%3Fpage%3D12 Stitches: http://www.airside.co.uk/redirect.php?mailing_history_id=63&user_id=631178&url=www.welovestitches.com Airside T-shirt Club: http://www.airside.co.uk/redirect.php?mailing_history_id=63&user_id=631178&url=www.airsideshop.com%2Fproducts.php%3Fpage%3D54%26archived%3Dall MAG Anti Landmines Campaign Promotion: http://www.airside.co.uk/redirect.php?mailing_history_id=63&user_id=631178&url=www.airside.co.uk%2FMAG%2F If you have received mail from any of the lists in the past month, you will not need to resubscribe. ––––––––––––––––––––––––––––––––––––––––––––––––– If you have any questions, please feel free to email us at If you want to check out who we are, visit our website at http://www.airside.co.uk/redirect.php?mailing_history_id=63&user_id=631178&url=www.airside.co.uk Sincere apologies and sorry for the mass mailout, there will be no more emails sent to this list. Yours faithfully Alex Maclean Director ------------------------------------------------------- To unsubscribe from this mailing list, please visit http://www.airside.co.uk/unsubscribe.php From akepner@sgi.com Thu May 12 19:52:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 19:52:31 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D2qPOv023522 for ; Thu, 12 May 2005 19:52:26 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4D2pvxT004420 for ; Thu, 12 May 2005 21:51:57 -0500 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4D2pm5x25019126; Thu, 12 May 2005 19:51:49 -0700 (PDT) Date: Thu, 12 May 2005 19:49:57 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: davem@davemloft.net, mchan@broadcom.com cc: netdev@oss.sgi.com Subject: Perf data with recent tg3 patches Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-1586889132-1115952411=:14917" Content-ID: X-archive-position: 1075 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 13931 Lines: 263 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323584-1586889132-1115952411=:14917 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Several tg3 patches have been recently posted, and I've collected a bit of performance data with them. Mostly I'm concerned about reducing per-interrupt overhead (due to PIOs), and CPU Utilization, so the following data shows how these patches change the number of received packets/interrupt and CPU utilization. (Let me know if I've missed any relevant patches.) The data is labelled as follows: ------------------------------- base : "vanilla" 2.6.12-rc2 kernel base+mchan1-3 : 2.6.12-rc2 kernel + 3 patches from mchan [1] base+mchan1-3+tagged: 2.6.12-rc2 + 3 patches from mchan [1] + tagged status patch from davem [2] base+mchan1-3+coal : 2.6.12-rc2 + 3 patches from mchan [1] + tg3 interrupt coalescence patch [3] [1] http://marc.theaimsgroup.com/?l=linux-netdev&m=111446723510962&w=2 (This is one of a series of 3 patches - the others can't be found in the archive. But they're all in 2.6.12-rc4.) [2] http://marc.theaimsgroup.com/?l=linux-netdev&m=111567944730302&w=2 [3] http://marc.theaimsgroup.com/?l=linux-netdev&m=111586526522981&w=2 The system I used was an Altix with 1300MHz CPUs, and a 5704 Broadcom NIC. The workload was bulk data receive via TCP, with 1500 a byte MTU. The following tables summarize the data in the attached graphs. I had to (grossly) interpolate in some cases, see the graphs for the real data. CPU Util[%] ------------------------------------- base base+ base+ base+ mchan1-3 mchan1-3+ mchan1-3+ Link Util[%] tagged coal ===================================================== 40 36 34 41 27 60 48 45 50 35 80 58 56 58 40 90 59 58 63 42 95 - 57 - 42 Packets/Intr ------------------------------------- base base+ base+ base+ mchan1-3 mchan1-3+ mchan1-3+ Link Util[%] tagged coal ===================================================== 40 2.2 2.3 1.4 3.4 60 2.7 2.9 1.8 4.1 80 3.0 3.2 2.3 5.2 90 3.1 3.4 2.4 6.2 95 - 3.5 - 6.6 "mchan1-3" gets us up to ~.5 more packets/interrupt, and adding the "coal" patch ~3.5 more. The "tagged" patch made things a bit worse, though I haven't pinned down exactly why that is. Processing more packets per interrupt results in lower CPU utilization, largely because we spend less time waiting for PIOs to flush. -- Arthur --8323584-1586889132-1115952411=:14917 Content-Type: IMAGE/PNG; NAME="cpu_vs_link.2.png" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: CPU utilization Content-Disposition: ATTACHMENT; FILENAME="cpu_vs_link.2.png" iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgAQAAAAAdquFJAAAAQ3RFWHRTb2Z0 d2FyZQBnbnVwbG90IHZlcnNpb24gNC4wIHBhdGNobGV2ZWwgMCBvbiBMaW51 eCAyLjYuOC0yNC1kZWZhdWx0nVoNlQAADlNJREFUCJntnd+LJEcdwHvZ4AqB bHyQCGLGB5Vwinm8oJjx/gFfTzFxT5Co4N0iMQ6ymamReREfXF8CguAdCBo4 uNWALGQy03MPEsmDG/HhJJfdGjBw4uW2Jp57PbvdVWXVt/p3T/d0V9fEXW6+ cLM3367+zLe//a2u+lZ1V1vcsFhL4BK4BC6BS+ASuAQuANibNGybE+Jw/kGo RP6HbWPO36wGbDvEBzZpDNgMgB53KgEZcxyzQB4CeRzIo0PWBHYB6DhjpFhv IwkcrmoA4z50HGwDsLlnb2kecniWbQBKngDaGLcAyKpbyBNAHAKfNgMch8AN E0CXwBkG4KYekAVAJIEUcxkpkQ/3qwJFTeEYcQefgIXMttG2ACIBFGcZo7uV gT2HC7dNm5StT8TRohEXFlqddYzbXGxxps2b1YB6sgQugUvgErgEnjXgqNEz C+Sy5TEKPGCGgUPPMLBzYhbI2AOzQMoOxZd6sh4HuuzA70BzohRKH1fRMqoA 6LChWSBhHbNAzJhhIG+bBvbMAjNFHypgFTEOTMipAbqLBJbzoV0emJBTAzwR mdpPvYY54LHIUjtuhcCerhYDXZcfiHzcnIUCiFEa2EJ1gJNGb7KW1L1Wy0KC qW9g4EP6Si0gxix1xOy3RcA5cuyQA5oMRrdvIX2giMPGaiIOnZf+sFrDwrgo H7pXdj5uCKjkj088+TujwHeeWjmPTALHq5/sc3M+ZH/55bkdbggI8h1rZdco 8JplfdkocGRd4NWAMT3sJDznBzb40Fo9VxN4DMOJkYWrq6gI6GYaDRT9gZ0+ 4PELLLv2OcsuAtLMxTgNlAcaK3Rp7c3I+hlARnhKLrD1SbPH0Q2+9n7z5sl6 BJRjqa93H/18IZBvpIHPcoeIXBC90nHvYnbs0GBvYO6OVi8XA+00ECFX9MEn a/0BvUP4lkuZxRrBRnbDeuyQVLNQAIno1KP+gCtg3ELeGD3NC4FZH6LO6qRj AZCQkQKGPpyuvnoeFQJnnOW2y2VeBEA7DgQLLz1abOGMONySbbsEUkIQAMM4 PDy88f4mszLAKerl15RnqYttsbE/dAMLw5ryYH/3xObbGaBjt/OBF9jqWP5g 314DH05QVJdP+v0H+MovMkASpWbVxEP8kNzIAjHz9IBjmSXPBJ5oAfffReK4 X7VwFvhAq02597qNRMWBbD4BHHXkEMH5CqxDkPde+OuV9/9lWV87PBwlhgjw 8EDrkKeHBA34qz/bSFuID4ZawFGDoO6nvvCrb2aBHS0fTvn4IwN27vGLWWAq DuP1D/REzsrwcEALqh47POpY7YH9aUs2AsnATteUDHBPzhulgPzyZZs8Y+Ev dh9BKeAkqstuPwZ0Q+C2P1WWAF5/HpOLb1x75OcfTR9yZIm4ps8EyuIZ4J8R J5u/+eG5z34sAnpWIwlk0PPx8yWXtqbNb7P1t5ECTho32aOTjZ73BBQVPWHy 9xvHP35t1QmBVE6GxYEcfsDPl1zvuoO/xZ09WxZHwkJG75OrbfcOFB2J7KJ/ 7ZHv0wskH6gyKT9f6n5ln5CmaKQwmaxNvBVxyFuuCAn/Antd7PKTd37wjX93 8TwL/XzJpfuEK6BvYQJ4GVHv5D18/ujxZj5Q+dDPlwAoGikFlCdlJIGW48ch Ym73M/b6v59qzj3LKl9SwLYbAW0JFM6g+2qXlvtOZ+/d5+yCRkrFocqXJFC2 SwCUcQhfJJDdVjvtuH8a/J5RXNDQgwT5Et13cGChqCl8w26Ls4zEWb4o2hjR XGH30H2RbpF5wCBfovvTJviwB3WZ26OOH4fb/PYGlhbijuvuOvOABeLCafRW +FtEeK7F7QGF+XbtYRZx/PLvNv+bI64WUDkJiYAM2dWA1CGwx0Xe/RLllIY7 BhbaG9WAav6as9veCk1sCIC4ooWBofv8reTofACMem+VgEJutxJ7BMCoY1YV +OudQXzHABhd7KsCsTrdgQRnOXXvSyTxGRbY05U3Fajv3owfD642ndLA+8I/ eHbZuIW8mQSGQ1Us9gc4/+Tqfp6obKmxr7BLnAHKDUngLAsLgD2vMUZrjD/P 1v+Bev9tKKAM7J4esM0JHrqMn6POLVu0TXIDdmTVo5WA/QDIRNeb0vF6a8vd E1dbx/VWvKYlr7ZMz4cCiCllvLXFFRAsFFevEFjxkJm3NpYtpwBi3FVAAsBu ATDT6sWArsPb3Ad24sBOFWAUh7L1HQBQNcUuxKErvxT4MNvQB8LarmPLetRq O4GFoqbIs1zJwgjY89ZGXPReWvI2oC7cVyXqsozDrp9JzQJmel/aspxPWRzQ zCQXTPqbtDA2lWkIqJvR5wM9sz7UzehzLRx1tDL6fCAfQkbfqiFfTWT0/KDs pD99PqOaWZdLZ/RB73/eIZfP6C+WAmYy+nzZLgWMZfRzfOit2GnVLB9Oikbn UhbaZSyM/VC+yPtJhA/nASeNskAuR4PZ7XnAdKe9wIfX5efXV+OqdCmLR63o fAvViPo8C8sD1VCrQaCmhXN8yFVuaMaHlwu3Vk/NVBzOBY4aZYFzZLHt8iIt /NCBJDM9kgJOQg6K9AU+bOGMKlZKho1dzULXztkQBjauBqSzizFLF5hz52M3 FzjPh22UUUnNcKhr4WwfepY2MBwlSPKsGxpnGY5wZhxSy7I04pBmVX4p+vIz lkZNoflbXv6EYeBzT+kAo0tnBvgjKxeo6UPre1Us3Mfx/WdZWBF4z54D9GJh k5uAx+QIzQHyAuAsH05juHipmOqFAMguNeZbmH96Q7libfrAzZSFs2Sq7Ck4 5AhYwYfMzS3A+aXHQmAoCjjLh3CWKW+lS8V8aF3JA84SPw53Ciw8fKEK0Bdc BLQ0gEUWjteTQFTmXuIiH3KUADJUYoig8Czz6JAlh3ZKpGaFcZiaXHA7mpP+ s4BY/HU6JyV8WEIVWEjMDRF48tZBjjvmhgjkEfPRk3qT/jMs9MO/Y+65AB+o Nek/00IlZeKwErBMTakGXNxzAYYsNAisMOZQDngPJ4G1fbifAta28OwBPwwf 5uWfsy1ktmFgxDEFDAXF9o770B9R8h3WiW7l067LCQtZ3oN4ZwdYNV/uHGZU sVICuJcCzpO5Ft4yDbxtGlhQl91+XFU2Dg/yLVR3G4kNmS1FFsoFJHKAzO8D D8vwIuDVXKC6Y0t4pRoQJ4ExH07VveX8LnyaaJd9C2ctLZFvYQEw8OFdU8Dg LFfzYRo4Iw5vKHy2lO71sFoclgCWkypjDrWAddvlUmMOVSwsNeYAYs3ZXtmH 88515bEvNfhqsI9dycIyE4WtOdsTwMzNyTOkkoWxyVZDPjyYn9FXO8sH8yf9 S8chyNDgpD8W/6ZRRv9dyM9fjCfrSvVSsSqa9MdgobGM3r/FSPM2/hlA/yYo vdv484Fl4rDaWgQlakpJC5VUmPQvBwRZEPAhGHNYOLC+D7FpCw0DF99zOIU+ DOWsAJd1WQMYclCkr+NDzUch8i2sOkc/H2ibBXpRpwpF+lo+DH/CjIVnABgJ ivTLulwLWNeHmcCub6FtGogXDDyF7fLpB9pJoJk4NJ5WGE98KtyPXQ4YGyIw dD0sMURQzUKTQwRSJgYn/RXd9GKAmBkbIgiA8SGCWUtbVQbG4zC+NowuMLEY IMW1fZh8xiea3dS2MPZDyf+ZAZq1MPBht8nr1OWEhXCW7apmFgAhDnWBuT0H fQvDHVGkFz7s21zTh9i0hWcOGPhQPw5zLKwsi+ofLqAHGwqK9EbzFNewhacP 2EgB4dnxGj6MrXXlWwgRrW8hzayWUPOQFw+s68MP4ZB1ZVHAzEPlyzGH+sDa PkShYWYsZKbblPzFDUwB6/pw8RaaAVJuLKNXZ/nY4KLl0HP4wPST/lR37b58 oOGMnkZr95m5Hqrl/Q1m9DTK6E0dsuGMnppe3p8aj0PTa2IsctJ/2S7XBy59 WB+49GF94On24bzb4yoDo96sQaBRHxq3cN5tmpWBD6EPjcdhLTmbdflsAJc+ rA98CH1o/JBPLdD408HmhgiUmH7zGje9GCBn5p7094GGhwi46TcAcjlEYEIi YLln8ioAO0XFdIB5j0bqAmVNMQs0/TZPU7IELoF1gWP4xLAw+U0mr0b+680d UHWb8oVwHqi8FVCN5TrIfiniNcYpIEby8yosOTaEyS8Hw0XoDqhsWI7GVSq1 AD/uuGGpPZcIQAKo7htowJJj8lU74lcJZC63QGXDcjSOSmaoUg1oWGrbcQQg CWyCnWRP/tm6Lz9JR+69CyqbHksNB5WrVANQQSni3BGABHBoK+AOAOEJXgLP 1LVAZdMjAILKUaoBqKAUcW4NUxYOfOAml8v33IYvW6Ioc0DVpfcAKFUCIlW4 fQ/gWwDcHaSAfQWElzndhLXLvaZMeKmj3u/Ulk8Jj0HllxrDyyam6/BGQafV TwF3FfAeuNvdgi+bSMYIqPhgIE0DFbdBhdsDcIxUkQfObgq4o4B34SyfQMtM NsBhdxWwDccKKnRXneV2WIocOTsp4FUFvAPAYwVsAhBU/A0VI1LFOKhsUHEs VeS+czUdNgqo4tCNxaGTCTrKYypuQ+KejUNVUzDUARSvKU6mWlAeVyGpItma ouryGtRSq5Opy/GKS3lcxaWql63LJmQJXAKXwCVwCfw/AB3/w5XvEPRfOhPc jzRm4etoqgDvh8A9ju4rncIQ2o5uWjECZFQHyKND9rP24JCJSPl1gHQNgOOm BMpucFfe8d+TQEfrkD3XsaNDdkUngDfJsC2BRAfoUuogABLRNxEKIuyC5zoI x5rA//AISOJAWxN4FAPi6XoERJrABzGg7UQWMl7LhxiAiBAH+UCqEzaOBNqi i81sCWSin3jCbTIE4FF14GRtTGXCJJI0JPtqIg7XKVufyKUSx9ytXpe1ZAms L/8DP+kMARRS++4AAAAASUVORK5CYII= --8323584-1586889132-1115952411=:14917 Content-Type: IMAGE/PNG; NAME="packets_vs_link.2.png" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Received Packets/Interrupt Content-Disposition: ATTACHMENT; FILENAME="packets_vs_link.2.png" iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgAQAAAAAdquFJAAAAQ3RFWHRTb2Z0 d2FyZQBnbnVwbG90IHZlcnNpb24gNC4wIHBhdGNobGV2ZWwgMCBvbiBMaW51 eCAyLjYuOC0yNC1kZWZhdWx0nVoNlQAADZ5JREFUCJntnU+IZEcdx984SToi 2F70pOmAngTBo2jYzh7EgyAexOSQZcCTIjFikEZmu2vMHPbmQiBHSa5GyXpy A5Pp14uCByGbS1hl2akGibvsuFM9WXeqZ+pVlVW/6j/1/var96pjj9s/SM/+ uqo/+davqt6relXvvUB6tmANXAPXwDVwDVwD10C/QLGpP9R/VHu7UrJ5Gp18 MMaljFBJILeBJAF8OAPelGWBwgJi38AwCZTzIpcHRq2hkOP2jmhIRP7TGnSv qB/3GobFGwActssDuSS4RymmnAlJHhLGt9WPu8wUOWI0dCzypqRhnxBCmVRs Slmkyoe2TWkZ5xQBkJQGqt+FYksBuQqfBkK8ujPgx9IVGDVCEQ6bVDTpHNhr ToGPnIEqSkK1FyopmQH7UMMAPHEGUoihpIhhAO6rb+9IzbViiJ0U6lqWZ0yJ UkCuw3fI6FgBqQaGklMROsVwKNi4zSMVtl1KoS/SqKn+jBpDBcRSNCXajVrl gDVsDVwD18A1cA08b8AR8gwkoWcgxo8d0HsMVS0Pg5rWTCgk8A8x8as6Vgwf N6D3GKpa9guswzjvwJLmHZhlqwJEywE6xJD6VviJAy+K5qi96xF4Qc14cdch hgEqBiI14xXCo0IFJH6Bvc1RL3NIVBXYZbLvtR1uM3mQmVKxp1zgDIfII/Ci 2Bwil3ZYzh6r4+GSgOsYOgGt7zl8hlLu1olhCtiWsuugEKFsIJkCRVs6HQ/7 OQpnQF1kF+CdZL577RuiMULkER7yK+P2RQA6xPAwCbyLBWckJB9fw91tiS9o IHdQmDrAEiIV5yCgnfA9LglC4aD1ZwdgSqECdtWgnihgZIBuClMxJGTQaw5a Gsj5uAlAlxima5mEiKpZBwCpUehSy+l2SJC5mt0J9zkBYIl2OGjl9pS7ONym KpF2cHeqMKOnDJtxhTgXeK89uNxU8xjaGUIM9YpARl8uDyxphMSBYU1gFARx IKoJ5AmgqHtOGSeAqukPn3IRdCdh/3g6fomA1TwFiCChkNYFjp99IgYkNWMo xkEciBNANP8nfK8XVluQzebFFH7FCXiqwkyKgPcSMZwDO8gCoinwGBajihQm G/YM+Cdb4QwIa1IWMCOGecAP4XMyX0LvyMa/2zfOmgYoNsftG73PjNBrKYXi JA/4T/g08yWJ3uixQyxOqQYSrRD3uw9JeDkFDEZ5QDOTMvOlUWNvn99VJynG RSBaO211TFKzAHzgcsQ2CifzJbS3Lw1wqnACdDinmBhO5ksaqE5SBqgrRR1g t9ngGReFk1qG+dIEGM6BFBQ6jW0m7dDMlxRQn5cAqNvhHeIONDadL+312VSh 7imHlOhalpedx4fT+dJe2IAYqpOU7st03MxuhwuBBYZYTkJFoI5u2sabFhA5 Aftcj8+SMWRsDsShE/CGaGZ8GwNiJ2C21VCYA9ybAaPpdZVa55SYQulDYQkg trLDJ5KyMfniqg+gQFKwnLzxdhjPNLtUhed/gBMhyfk0dg59eTYkTgJ1kXkM lLBFwA/QbtQcSnwY3mDNUW93AlQNW02rqgBvhpxRjPBHW/0zKvtdDWQCul7o AuxMgRgL9dP3No4I+pU62qoTzE77ylCfAiQujOEoR6ECMhmGWAFPDRAUIsZg 51a+QoLygDuRPnMqIGOjZ8QkhtppFQITBwcL2NPLLAZIDiwgKVaYAM7boWJQ AzTndtMOtVMcw7zD182wp4YjUh6R/lSh7imqlt0UzuwDtDNuDTXwBsRQn6Qa cIAdtQov93k5wNrA6SpmvXmKBRxseFYY888B0Nci17jubNQCDlpS7w70WGQk 3admhcBQWhMfHzHENtCHwqUAB0jN6I9q2aAZUxh6jGEorSV1D0VWpfULBPMO XN6ivy+F0mM7pLbvA0hs30cMsW+F5w3oIYbxSvGg0HuzgZOUT2DM/59tPimv cBWB8VpexXaIzxlwFY+H5+3gsO7L9YEeYnjsW+ED38A7eKlADzFcssJVBD4I baCHGE73x5+XrucLOFv093U8xD4VIs9AWAvwCsQ20Md5WStUc1xfCierFaG/ SwQY8Nj32AZ7jKFvhYbnGzi7ROALuLz7Anwp9AkctTwD4yPYVRxjnzfgKsbQ +zxlfc1h5YErGEM+bdkrC4yClg2sH8PVL3Lc9w9cwXZ47oAeYoh8Kwx9A7Ej cNhcAHQd28A26aIYul6dI3kZp8DcbUNVgdz2S9jRIqCIAT3E0HEz3uIiG0Oe gaI8cGE7BOO+5ymsvMJcm/UUpP5Sj8CDUAJ1EXA6jlwIhItpePGi//vvl5zR A7Dg7o+pwcWO0gpLtEPvwOl1Rkdgfms7wHkpiXZ4WFJh6SLT0DMw5hdY6XYY Bz4eYxvkGRjfnOxjvoyXqrA+sNr26QLgObjm4B0Y8/0DV6Uv6/GJT+Drr2Of QHY4CNpzYHwps0oMo0eDp9EcWHspE/3iR299Ts6BtZfh+u9++8UN5BF46aXf /HEzzAM6x5Cxt+9/6flN7E0hpx+efPXXG8QbUJDDe59/LZBWLYe1gHLrw7// bfADNAfGlzJdY0hp+Pa7d+cptXsKI1uXXn3VI5AfkL4NqA0U+3R6J4Gn4+E2 83s8FGEcoIG4DpDjFLDSNn4wfdsem/9sNoJFNtAphl3dDpVjZE6BZ/b/wM32 9Aflgm+FFjD7EoEI5GK7pT9OTsWll2xg9kWM7NsaE6Z/sq+BX7SAOddgZ886 TqVYzi1igM8HtkKw1F7iUgp1DPeD54Mg2EwCU0uZ4qgEUD9BYH8YfN08cy4G VMNYd4U6zzj4wql4MV1kiavEUJKMSkkAXRRCCwHgczbQ9JRUDPPaIbcfX6GB gslLz820T/vyuPx9Affj//6D/vtObNEf2woXh61jOYepbDNgMob5dm1WeCl3 2lZCVSC2gLG7ZmPAVDsspzAf6HBfwCyGPCeGUMvl7wuY3Zmpp/iZCh03Qc3b YfJ5KrXPeuWADucU7nue4qvIuU8Ym1VKyzPwAbaBi2NIC7NVGBJnKYQTRlVg 5pPuXq4ENAPBLIX0y7nAohjCUDUzhuw7mcDR9I7sHDPPI8pSGNnTiumQ0Yyk iuwwFygaFnB+7WsRMC9Z/OvnqZHDDFgUw8O8lJ/87GvZwE6xwtQznSZ29LuX vpersMj6Od//5y/feqUSMPVMJzAWPB00OhawFQO6X3PgO0881Z6lBGp6OgMu aofZj8w823n201sWkDssFGYB6S+D72+84g+4t/fjIHiqkw8sDBtKpLC3j253 t4LghXk2J4WpGPPrL98X3wie/W5FYKLI/I649vvj0ZPBk7/1AxS3ZeuvOxe+ GTyBbaDLXhEUT3lh/KngmF9644fIBs4sX2EYZiqUV5XC++ynezagFBCjzK+j DRXD253ZEaU8MG8OdFXV8l4YB5Qa23yUk/KCaofJlFIKUw/LA9lE1XLMygM/ yvryBPPEAbdmDM/C5DflY3gTZaTAa5CqjQ9FkBIjsxbCyxc5MyX9oqYYsHAW kJmyIIbu9y+f4MyU3Bn9QoXpDRnxGBYBS9qSgc4xzHGsWvZ3p/+E7rfIeGlA XzFcnsKFZh3zi4AldmJM7DYqBZSlI3W/OJv79PY4N6UiMHbtxwfQVaGOR5jT saGCq8QwZ+hhKvh2TmIRMG/oAeJKtkMLiOWjnF/kh68AKBSQ5bRDqOCSfXl5 CjWwMIbOwGijuJZdgTqGhe2wSgwr2nkF+jqnWAormwMwd6dqVSAM3SoCM4MD g0ufMUwPf8srzLTcnapVgXUUfjIxrFPLmea9HZaz/6u+vFLApcawXGtZoNC2 cu15AdCWf9bPS3Eosp0Y9TwDh5+tDsxcAauj8NR3DI+zEk8OPBf56MgzsE5P WQbQ7xsAM1+VUcXWQH9A72/z9GZr4BpYD2heY84lPMS4MW5L3dzBoeAMzOON r9iOnY1E+rHIFtBsTTyF7WaCUazzhPD2mrvgYPMqm21wJE5lu8mImrlbQLN2 ewwbvjiHm+gmr3+4ZZzJ3jJze91BKttVStXM3QbCflsuIvhDbsLPwLkODoYU Lk1KPzJASIFshN4N2zHgLQM8M8BrAASnAw6GFAWElN6ZAUIKZCP0Vj+u8LoB npiAvgI6tCMoOIPeiQFqR0A2YbKRgxMAXt+PAzsGCCfjBowNxz3tcGoGin3t RCYllm30DGwVoZ29GPCEGuABhP6BYWgn2jDOgXY4A4eZbMxKISf0egz4aALs Q8EOTU4Y3VDL4RwcKizHpJBH9FoM+HAC7AHwrskJ4y9qOZyDQ4TlyL52yEP6 Zphuh9y0Q2m3Q2o506ZnN1fZExDDRDs0PYVDf+DS7inUciadA9sd6ggckuwp pi+bfhltpPvyxDHdF9td/hic3WRf9mNr4Bq4Bq6Ba+AnD+STDwEv6WjNv1M2 boeZ7wdaAIxmwIcSmzGUhJGSZHILZV92qgwMqwClVWQ8/w6AIudq3gLgRQCO mwAMes1hW51t39JAXgUYyQuczIssJOV64PsmUkBWBahIXQxApsYe6gvGJwMO JmlF4OVwDmQ2kFRViOZAKjbnQFwVaCkk3FIY1ophB4CYMY6nwF4FoH6DTZfo G2+uATDkTIRq0AbArnvD1kM61FWj0F2Jh3rgFvQ2JVKDNgUct4V7X65ma2B9 +y8aqfbN+WH4fAAAAABJRU5ErkJggg== --8323584-1586889132-1115952411=:14917-- From jgarzik@pobox.com Thu May 12 20:09:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 20:09:27 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D39OOv024299 for ; Thu, 12 May 2005 20:09:24 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DWQXi-000111-50; Fri, 13 May 2005 03:08:50 +0000 Message-ID: <42841A3F.7020909@pobox.com> Date: Thu, 12 May 2005 23:08:47 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel , Andrew Morton Subject: git repository for net drivers available Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1076 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 881 Lines: 25 Although I have over 200 net driver patches to go through in my 'Pending' folder, I have fully converted the existing netdev-2.6 repository from BitKeeper to git. This includes the wireless-2.6 repository. rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git The main branch is fairly irrelevant, as you must choose the branch you wish: > [jgarzik@pretzel netdev-2.6]$ ls .git/branches/ > 8139cp e1000 ixgb r8169 skge we18 > 8139too-iomap forcedeth janitor register-netdev smc91x wifi > amd8111 ieee80211 orinoco remove-drivers smc91x-eeprom > e100 iff-running ppp sis900 starfire For folks looking for a consolidated netdev-2.6 repository (hi Andrew), that does not exist yet. I will create an 'ALL' repository for this purpose, sometime soon. Jeff From greg@kroah.com Thu May 12 20:42:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 20:42:40 -0700 (PDT) Received: from perch.kroah.org (mail.kroah.org [69.55.234.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D3gaOv029326 for ; Thu, 12 May 2005 20:42:36 -0700 Received: from [192.168.0.10] (c-24-22-118-199.hsd1.or.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j4D3fvi27314; Thu, 12 May 2005 20:41:57 -0700 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1DWR3q-39m-00; Thu, 12 May 2005 20:42:02 -0700 Date: Thu, 12 May 2005 20:42:01 -0700 From: Greg KH To: James Ketrenos Cc: Pavel Machek , netdev@oss.sgi.com, kernel list , jbohac@suse.cz, jbenc@suse.cz Subject: Re: ipw2100: intrusive cleanups, working this time ;-) Message-ID: <20050513034201.GA11817@kroah.com> References: <20050512225026.GA2822@elf.ucw.cz> <4283FA4D.3010208@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4283FA4D.3010208@linux.intel.com> User-Agent: Mutt/1.5.8i X-archive-position: 1077 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev Content-Length: 646 Lines: 17 On Thu, May 12, 2005 at 07:52:29PM -0500, James Ketrenos wrote: > > Part of the process we have in place is to try and make sure that the > versions that get picked up by distros and the majority of users have a > 'known' level of quality. As part of that, we only want to get changes > pushed to -mm and eventual mainline that have gone through regression > testing. Any chance of making those regression tests public so we can all do this kind of testing on any future changes that might be made to the driver? Remember, once it hits mainline, lots of different people will be touching it for various reasons at times... thanks, greg k-h From bunk@stusta.de Thu May 12 20:53:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 20:53:32 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4D3rROv030207 for ; Thu, 12 May 2005 20:53:28 -0700 Received: (qmail 21287 invoked from network); 13 May 2005 03:52:59 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 13 May 2005 03:52:59 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 84A28BB5F7; Fri, 13 May 2005 05:52:58 +0200 (CEST) Date: Fri, 13 May 2005 05:52:57 +0200 From: Adrian Bunk To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [RFC: 2.6 patch] make MII no longer user visible Message-ID: <20050513035257.GC3603@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 1078 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 710 Lines: 21 MII is a classical example of a helper option no user should ever see. Signed-off-by: Adrian Bunk --- linux-2.6.12-rc4-mm1-full/drivers/net/Kconfig.old 2005-05-13 05:47:58.000000000 +0200 +++ linux-2.6.12-rc4-mm1-full/drivers/net/Kconfig 2005-05-13 05:48:27.000000000 +0200 @@ -165,12 +165,8 @@ the questions about Ethernet network cards. If unsure, say N. config MII - tristate "Generic Media Independent Interface device support" + tristate depends on NET_ETHERNET - help - Most ethernet controllers have MII transceiver either as an external - or internal device. It is safe to say Y or M here even if your - ethernet card lack MII. source "drivers/net/arm/Kconfig" From cranium2003@yahoo.com Thu May 12 21:16:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 21:16:54 -0700 (PDT) Received: from web41425.mail.yahoo.com (web41425.mail.yahoo.com [66.218.94.123]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4D4GpOv031764 for ; Thu, 12 May 2005 21:16:51 -0700 Received: (qmail 95171 invoked by uid 60001); 13 May 2005 04:16:23 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=01fjHDlgYrdnBc8hoMAInmw8kJRrs4zOPI/DWR6PU62uVM2cDPYxCgEPMi6jAH9yQJo4/u2GnMN6aj4YhkpgMxuBonIqmFCWbgsQdTX6Uw4VfiDNAQsOxiOCIuxSMUtEAKz12tDBLET7MlUuxsJh2avzVAOuxgovcXMf1DV50zY= ; Message-ID: <20050513041623.95169.qmail@web41425.mail.yahoo.com> Received: from [203.199.141.99] by web41425.mail.yahoo.com via HTTP; Thu, 12 May 2005 21:16:23 PDT Date: Thu, 12 May 2005 21:16:23 -0700 (PDT) From: cranium2003 Subject: Linux Routers working To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1080 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 442 Lines: 15 Hello, Is there any way on linux routers to know on which interface packet is forwarded before actually packet trasmission begins? Also before packet processed by IP layer can it be possible to know from which adjecent Router'IP packet came to that router? regards, cranium __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From bunk@stusta.de Thu May 12 21:16:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 21:16:55 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4D4GpOv031770 for ; Thu, 12 May 2005 21:16:52 -0700 Received: (qmail 21717 invoked from network); 13 May 2005 04:16:23 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 13 May 2005 04:16:23 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id F0F47BB5F8; Fri, 13 May 2005 06:16:22 +0200 (CEST) Date: Fri, 13 May 2005 06:16:22 +0200 From: Adrian Bunk To: Julian Anastasov , Wensong Zhang Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Status of net/ipv4/ipvs/ip_vs_proto_icmp.c? Message-ID: <20050513041622.GE3603@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 1081 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 475 Lines: 20 Hi, can anyone explain the status of? This file is always included in the kernel if CONFIG_IP_VS=y, but it's completely unused. Will it be made working in the forseeable future or is it a candidate for removal? TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From davem@davemloft.net Thu May 12 21:37:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 21:37:46 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D4beOv000879 for ; Thu, 12 May 2005 21:37:41 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWRuM-0000Nw-LC; Thu, 12 May 2005 21:36:18 -0700 Date: Thu, 12 May 2005 21:36:18 -0700 (PDT) Message-Id: <20050512.213618.14358320.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff From: "David S. Miller" In-Reply-To: <20050512235236.GA22658@gondor.apana.org.au> References: <20050512231038.GA22440@gondor.apana.org.au> <20050512.162426.75782784.davem@davemloft.net> <20050512235236.GA22658@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1082 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 3340 Lines: 73 From: Herbert Xu Subject: Re: issue with new TCP TSO stuff Date: Fri, 13 May 2005 09:52:36 +1000 > > #2 could be handled by down-sizing TSO frames when packet loss occurs. > > Ie. tcp_retransmit_skb() or whatever will segmentize a TSO packet > > which is within the sequence it is trying to retransmit. Implementing > > this is non- trivial mostly due to the fact that it has to work handle > > GFP_ATOMIC memory failures and also get all the pcount crap correct. > > I think most of the code to do that might already be there. Pity > we'll have to keep track of the pcount though. Yes, when we walk the queue to retransmit, we chop up the TSO frame via tcp_trim_head() and tcp_fragment(). It is very loose and would need refinements though. I think we'd be OK, because even if we get a GFP_ATOMIC allocation failure, it's just like any other failure. We're doing retransmits so a timer will be the worst case deadlock breaker should we get an allocation failure while chopping up the TSO frame. This actually makes me worried about sk->sk_send_head advancement. I think we have a deadlock possible here. If sk->sk_send_head is the only packet in the output queue, and the remote system has no reason to send us zero-window probes or any other packets, we could wedge if the skb_clone() fails for the tcp_transmit_skb() call. We won't set any timers if we fail to send that single sk->sk_send_head write queue packet, and we have no pending frames waiting to be ACK'd, so nothing will wake us up to retry the transmit. > > and size appropriately. I think the tcp_snd_test() simplifications > > made by my TSO Reloaded patch would help a lot here. The send test is > > logically now split to it's two tests 1) whether to send anything at > > all, and 2) once #1 passes, how many such packets. > > That was another one of my comments to your patch :) I was going to > suggest that we move the cwnd/in_flight loop from tcp_snd_test to > emit_send_queue. One elegant part of the tcp_snd_test() in the TCP Reloaded patch is that tcp_write_queue() calls it exactly once. That loop in there is bogus and unnecessary. In the changelog for the TCP Reloaded patch I mention that this can be simplified into: new_packets = skb_queue_len(&sk->sk_write_queue) - in_flight; cwnd -= in_flight; return min(new_packets, cwnd); It is a BUG() for this calculation to be larger than the number of packets from sk->sk_send_head to the end of the write queue (which is the invariant we must guarentee for our caller). We could even check for this while debugging the implementation early on. > > This would be a sort of super-TSO that would do less segmenting work > > than even a "perfect" TSO segmenter would. > > > > I'm still not sure which approach is best, just throwing around some > > ideas. > > On paper your new super-TSO approach sounds the best. However, I > suppose we won't know for sure until we try :) Yeah, TCP Reloaded sounded really nice on paper too :-) To handle these super-TSO frames properly, we would need to add sk->sk_send_offset to go along with sk->sk_send_head. So then update_send_head() would advance sk->sk_send_offset, and if that completely consumed sk->sk_send_head then the pointer would be advanced. Tests of sk->sk_send_head would need to be fixed up similarly. From mdomsch@lists.us.dell.com Thu May 12 22:41:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 22:41:58 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D5fqOv003499 for ; Thu, 12 May 2005 22:41:53 -0700 Received: from lists.us.dell.com (143.166.224.162) by ausc60ps301.us.dell.com with ESMTP; 13 May 2005 00:41:24 -0500 X-IronPort-AV: i="3.93,102,1115010000"; d="scan'208"; a="242768438:sNHT33484004" Date: Fri, 13 May 2005 00:41:23 -0500 From: Matt Domsch To: netdev@oss.sgi.com Cc: akpm@osdl.org, pptpclient-devel@lists.sourceforge.net, davem@redhat.com Subject: [PATCH 2.6.12-rc4] ppp_mppe: add PPP MPPE encryption module Message-ID: <20050513054123.GA29458@lists.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 1083 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Matt_Domsch@dell.com Precedence: bulk X-list: netdev Content-Length: 33934 Lines: 1025 The patch below implements the Microsoft Point-to-Point Encryption method as a PPP compressor/decompressor. This is necessary for Linux clients and servers to interoperate with Microsoft Point-to-Point Tunneling Protocol (PPTP) servers (either Microsoft PPTP servers or the poptop project) which use MPPE to encrypt data when creating a VPN. This patch differs from the kernel_ppp_mppe DKMS pacakge at pptpclient.sourceforge.net by utilizing the kernel crypto routines rather than providing its own SHA1 and arcfour implementations. Minor changes to ppp_generic.c try to prevent a link from disabling compression (in our case, the encryption) after it has started using compression (encryption). drivers/net/Kconfig | 6 drivers/net/Makefile | 1 drivers/net/ppp_generic.c | 79 +++-- drivers/net/ppp_mppe.c | 724 ++++++++++++++++++++++++++++++++++++++++++++++ drivers/net/ppp_mppe.h | 87 +++++ include/linux/ppp-comp.h | 14 6 files changed, 888 insertions(+), 23 deletions(-) Signed-off-by: Matt Domsch Feedback to pptpclient-devel@lists.sourceforge.net please. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com diff -urNp --exclude-from=/home/mdomsch/excludes --minimal linux-2.6/drivers/net/Kconfig linux-2.6-mppe.git/drivers/net/Kconfig --- linux-2.6/drivers/net/Kconfig Tue Apr 26 15:14:07 2005 +++ linux-2.6-mppe.git/drivers/net/Kconfig Fri May 13 00:20:04 2005 @@ -2407,6 +2407,16 @@ config PPP_BSDCOMP module; it is called bsd_comp and will show up in the directory modules once you have said "make modules". If unsure, say N. +config PPP_MPPE + tristate "PPP MPPE compression (encryption) (EXPERIMENTAL)" + depends on PPP && EXPERIMENTAL + ---help--- + Support for the MPPE Encryption protocol, as employed by the + Microsoft Point-to-Point Tunneling Protocol. + + See http://pptpclient.sourceforge.net/ for information on + configuring PPTP clients and servers to utilize this method. + config PPPOE tristate "PPP over Ethernet (EXPERIMENTAL)" depends on EXPERIMENTAL && PPP diff -urNp --exclude-from=/home/mdomsch/excludes --minimal linux-2.6/drivers/net/Makefile linux-2.6-mppe.git/drivers/net/Makefile --- linux-2.6/drivers/net/Makefile Tue Apr 26 15:14:07 2005 +++ linux-2.6-mppe.git/drivers/net/Makefile Fri May 13 00:18:01 2005 @@ -104,6 +104,7 @@ obj-$(CONFIG_PPP_ASYNC) += ppp_async.o obj-$(CONFIG_PPP_SYNC_TTY) += ppp_synctty.o obj-$(CONFIG_PPP_DEFLATE) += ppp_deflate.o obj-$(CONFIG_PPP_BSDCOMP) += bsd_comp.o +obj-$(CONFIG_PPP_MPPE) += ppp_mppe.o obj-$(CONFIG_PPPOE) += pppox.o pppoe.o obj-$(CONFIG_SLIP) += slip.o diff -urNp --exclude-from=/home/mdomsch/excludes --minimal linux-2.6/drivers/net/ppp_generic.c linux-2.6-mppe.git/drivers/net/ppp_generic.c --- linux-2.6/drivers/net/ppp_generic.c Tue Apr 26 15:14:09 2005 +++ linux-2.6-mppe.git/drivers/net/ppp_generic.c Fri May 13 00:18:01 2005 @@ -1027,6 +1027,53 @@ ppp_xmit_process(struct ppp *ppp) ppp_xmit_unlock(ppp); } +static inline struct sk_buff * +pad_compress_skb(struct ppp *ppp, struct sk_buff *skb) +{ + struct sk_buff *new_skb; + int len; + int new_skb_size = ppp->dev->mtu + ppp->xcomp->comp_skb_extra_space + ppp->dev->hard_header_len; + int compressor_skb_size = ppp->dev->mtu + ppp->xcomp->comp_skb_extra_space + PPP_HDRLEN; + new_skb = alloc_skb(new_skb_size, GFP_ATOMIC); + if (!new_skb) { + if (net_ratelimit()) + printk(KERN_ERR "PPP: no memory (comp pkt)\n"); + return NULL; + } + if (ppp->dev->hard_header_len > PPP_HDRLEN) + skb_reserve(new_skb, + ppp->dev->hard_header_len - PPP_HDRLEN); + + /* compressor still expects A/C bytes in hdr */ + len = ppp->xcomp->compress(ppp->xc_state, skb->data - 2, + new_skb->data, skb->len + 2, + compressor_skb_size); + if (len > 0 && (ppp->flags & SC_CCP_UP)) { + kfree_skb(skb); + skb = new_skb; + skb_put(skb, len); + skb_pull(skb, 2); /* pull off A/C bytes */ + } else if (len == 0) { + /* didn't compress, or CCP not up yet */ + kfree_skb(new_skb); + new_skb = skb; + } else { + /* + * (len < 0) + * MPPE requires that we do not send unencrypted + * frames. The compressor will return -1 if we + * should drop the frame. We cannot simply test + * the compress_proto because MPPE and MPPC share + * the same number. + */ + if (net_ratelimit()) + printk(KERN_ERR "ppp: compressor dropped pkt\n"); + kfree_skb(new_skb); + new_skb = NULL; + } + return new_skb; +} + /* * Compress and send a frame. * The caller should have locked the xmit path, @@ -1113,29 +1160,14 @@ ppp_send_frame(struct ppp *ppp, struct s /* try to do packet compression */ if ((ppp->xstate & SC_COMP_RUN) && ppp->xc_state != 0 && proto != PPP_LCP && proto != PPP_CCP) { - new_skb = alloc_skb(ppp->dev->mtu + ppp->dev->hard_header_len, - GFP_ATOMIC); - if (new_skb == 0) { - printk(KERN_ERR "PPP: no memory (comp pkt)\n"); + if (!(ppp->flags & SC_CCP_UP) && ppp->xcomp->must_compress) { + if (net_ratelimit()) + printk(KERN_ERR "ppp: compression required but down - pkt dropped.\n"); goto drop; } - if (ppp->dev->hard_header_len > PPP_HDRLEN) - skb_reserve(new_skb, - ppp->dev->hard_header_len - PPP_HDRLEN); - - /* compressor still expects A/C bytes in hdr */ - len = ppp->xcomp->compress(ppp->xc_state, skb->data - 2, - new_skb->data, skb->len + 2, - ppp->dev->mtu + PPP_HDRLEN); - if (len > 0 && (ppp->flags & SC_CCP_UP)) { - kfree_skb(skb); - skb = new_skb; - skb_put(skb, len); - skb_pull(skb, 2); /* pull off A/C bytes */ - } else { - /* didn't compress, or CCP not up yet */ - kfree_skb(new_skb); - } + skb = pad_compress_skb(ppp, skb); + if (!skb) + goto drop; } /* @@ -1155,7 +1187,8 @@ ppp_send_frame(struct ppp *ppp, struct s return; drop: - kfree_skb(skb); + if (skb) + kfree_skb(skb); ++ppp->stats.tx_errors; } @@ -1640,7 +1673,7 @@ ppp_decompress_frame(struct ppp *ppp, st goto err; if (proto == PPP_COMP) { - ns = dev_alloc_skb(ppp->mru + PPP_HDRLEN); + ns = dev_alloc_skb(ppp->mru + ppp->rcomp->decomp_skb_extra_space + PPP_HDRLEN); if (ns == 0) { printk(KERN_ERR "ppp_decompress_frame: no memory\n"); goto err; diff -urNp --exclude-from=/home/mdomsch/excludes --minimal linux-2.6/drivers/net/ppp_mppe.c linux-2.6-mppe.git/drivers/net/ppp_mppe.c --- linux-2.6/drivers/net/ppp_mppe.c Wed Dec 31 18:00:00 1969 +++ linux-2.6-mppe.git/drivers/net/ppp_mppe.c Fri May 13 00:18:01 2005 @@ -0,0 +1,724 @@ +/* + * ppp_mppe_compress.c - interface MPPE to the PPP code. + * This version is for use with Linux kernel 2.2.19+, 2.4.18+ and 2.6.2+. + * + * By Frank Cusack . + * Copyright (c) 2002,2003,2004 Google, Inc. + * All rights reserved. + * + * License: + * Permission to use, copy, modify, and distribute this software and its + * documentation is hereby granted, provided that the above copyright + * notice appears in all copies. This software is provided without any + * warranty, express or implied. + * + * ALTERNATIVELY, provided that this notice is retained in full, this product + * may be distributed under the terms of the GNU General Public License (GPL), + * in which case the provisions of the GPL apply INSTEAD OF those given above. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * + * Changelog: + * 06/18/04 - Matt Domsch , Oleg Makarenko + * Use Linux kernel 2.6 arc4 and sha1 routines rather than + * providing our own. + * 2/15/04 - TS: added #include and testing for Kernel + * version before using + * MOD_DEC_USAGE_COUNT/MOD_INC_USAGE_COUNT which are + * deprecated in 2.6 + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "ppp_mppe.h" + +MODULE_AUTHOR("Frank Cusack "); +MODULE_DESCRIPTION("Point-to-Point Protocol Microsoft Point-to-Point Encryption support"); +MODULE_LICENSE("Dual BSD/GPL"); +MODULE_ALIAS("ppp-compress-" __stringify(CI_MPPE)); +MODULE_VERSION("1.0.2"); + +static void +setup_sg(struct scatterlist *sg, const void *address, unsigned int length) +{ + sg[0].page = virt_to_page(address); + sg[0].offset = offset_in_page(address); + sg[0].length = length; +} + +#define SHA1_PAD_SIZE 40 + +/* + * kernel crypto API needs its arguments to be in kmalloc'd memory, not in the module + * static data area. That means sha_pad needs to be kmalloc'd. + */ + +struct sha_pad { + unsigned char sha_pad1[SHA1_PAD_SIZE]; + unsigned char sha_pad2[SHA1_PAD_SIZE]; +}; +static struct sha_pad *sha_pad; + +static inline void sha_pad_init(struct sha_pad *shapad) +{ + memset(shapad->sha_pad1, 0x00, sizeof(shapad->sha_pad1)); + memset(shapad->sha_pad2, 0xF2, sizeof(shapad->sha_pad2)); +} + +/* + * State for an MPPE (de)compressor. + */ +struct ppp_mppe_state { + struct crypto_tfm *arc4; + struct crypto_tfm *sha1; + unsigned char *sha1_digest; + unsigned char master_key[MPPE_MAX_KEY_LEN]; + unsigned char session_key[MPPE_MAX_KEY_LEN]; + unsigned keylen; /* key length in bytes */ + /* NB: 128-bit == 16, 40-bit == 8! */ + /* If we want to support 56-bit, */ + /* the unit has to change to bits */ + unsigned char bits; /* MPPE control bits */ + unsigned ccount; /* 12-bit coherency count (seqno) */ + unsigned stateful; /* stateful mode flag */ + int discard; /* stateful mode packet loss flag */ + int sanity_errors; /* take down LCP if too many */ + int unit; + int debug; + struct compstat stats; +}; + +/* struct ppp_mppe_state.bits definitions */ +#define MPPE_BIT_A 0x80 /* Encryption table were (re)inititalized */ +#define MPPE_BIT_B 0x40 /* MPPC only (not implemented) */ +#define MPPE_BIT_C 0x20 /* MPPC only (not implemented) */ +#define MPPE_BIT_D 0x10 /* This is an encrypted frame */ + +#define MPPE_BIT_FLUSHED MPPE_BIT_A +#define MPPE_BIT_ENCRYPTED MPPE_BIT_D + +#define MPPE_BITS(p) ((p)[4] & 0xf0) +#define MPPE_CCOUNT(p) ((((p)[4] & 0x0f) << 8) + (p)[5]) +#define MPPE_CCOUNT_SPACE 0x1000 /* The size of the ccount space */ + +#define MPPE_OVHD 2 /* MPPE overhead/packet */ +#define SANITY_MAX 1600 /* Max bogon factor we will tolerate */ + +/* + * Key Derivation, from RFC 3078, RFC 3079. + * Equivalent to Get_Key() for MS-CHAP as described in RFC 3079. + */ +static void get_new_key_from_sha(struct ppp_mppe_state * state, unsigned char *InterimKey) +{ + struct scatterlist sg[4]; + + setup_sg(&sg[0], state->master_key, state->keylen); + setup_sg(&sg[1], sha_pad->sha_pad1, sizeof(sha_pad->sha_pad1)); + setup_sg(&sg[2], state->session_key, state->keylen); + setup_sg(&sg[3], sha_pad->sha_pad2, sizeof(sha_pad->sha_pad2)); + + crypto_digest_digest (state->sha1, sg, 4, state->sha1_digest); + + memcpy(InterimKey, state->sha1_digest, state->keylen); +} + +/* + * Perform the MPPE rekey algorithm, from RFC 3078, sec. 7.3. + * Well, not what's written there, but rather what they meant. + */ +static void mppe_rekey(struct ppp_mppe_state * state, int initial_key) +{ + unsigned char InterimKey[MPPE_MAX_KEY_LEN]; + struct scatterlist sg_in[1], sg_out[1]; + + get_new_key_from_sha(state, InterimKey); + if (!initial_key) { + crypto_cipher_setkey(state->arc4, InterimKey, state->keylen); + setup_sg(sg_in, InterimKey, state->keylen); + setup_sg(sg_out, state->session_key, state->keylen); + if (crypto_cipher_encrypt(state->arc4, sg_out, sg_in, + state->keylen) != 0) { + printk(KERN_WARNING "mppe_rekey: cipher_encrypt failed\n"); + } + } else { + memcpy(state->session_key, InterimKey, state->keylen); + } + if (state->keylen == 8) { + /* See RFC 3078 */ + state->session_key[0] = 0xd1; + state->session_key[1] = 0x26; + state->session_key[2] = 0x9e; + } + crypto_cipher_setkey(state->arc4, state->session_key, state->keylen); +} + +/* + * Allocate space for a (de)compressor. + */ +static void *mppe_alloc(unsigned char *options, int optlen) +{ + struct ppp_mppe_state *state; + unsigned int digestsize; + + if (optlen != CILEN_MPPE + sizeof(state->master_key) + || options[0] != CI_MPPE || options[1] != CILEN_MPPE) + goto out; + + state = (struct ppp_mppe_state *) kmalloc(sizeof(*state), GFP_KERNEL); + if (state == NULL) + goto out; + + memset(state, 0, sizeof(*state)); + + state->arc4 = crypto_alloc_tfm("arc4", 0); + if (!state->arc4) + goto out_free; + + state->sha1 = crypto_alloc_tfm("sha1", 0); + if (!state->sha1) + goto out_free; + + digestsize = crypto_tfm_alg_digestsize(state->sha1); + if (digestsize < MPPE_MAX_KEY_LEN) + goto out_free; + + state->sha1_digest = kmalloc(digestsize, GFP_KERNEL); + if (!state->sha1_digest) + goto out_free; + + /* Save keys. */ + memcpy(state->master_key, &options[CILEN_MPPE], + sizeof(state->master_key)); + memcpy(state->session_key, state->master_key, + sizeof(state->master_key)); + + /* + * We defer initial key generation until mppe_init(), as mppe_alloc() + * is called frequently during negotiation. + */ + + return (void *)state; + + out_free: + if (state->sha1_digest) + kfree(state->sha1_digest); + if (state->sha1) + crypto_free_tfm(state->sha1); + if (state->arc4) + crypto_free_tfm(state->arc4); + kfree(state); + out: + return NULL; +} + +/* + * Deallocate space for a (de)compressor. + */ +static void mppe_free(void *arg) +{ + struct ppp_mppe_state *state = (struct ppp_mppe_state *) arg; + if (state) { + if (state->sha1_digest) + kfree(state->sha1_digest); + if (state->sha1) + crypto_free_tfm(state->sha1); + if (state->arc4) + crypto_free_tfm(state->arc4); + kfree(state); + } +} + +/* + * Initialize (de)compressor state. + */ +static int +mppe_init(void *arg, unsigned char *options, int optlen, int unit, int debug, + const char *debugstr) +{ + struct ppp_mppe_state *state = (struct ppp_mppe_state *) arg; + unsigned char mppe_opts; + + if (optlen != CILEN_MPPE + || options[0] != CI_MPPE || options[1] != CILEN_MPPE) + return 0; + + MPPE_CI_TO_OPTS(&options[2], mppe_opts); + if (mppe_opts & MPPE_OPT_128) + state->keylen = 16; + else if (mppe_opts & MPPE_OPT_40) + state->keylen = 8; + else { + printk(KERN_WARNING "%s[%d]: unknown key length\n", debugstr, + unit); + return 0; + } + if (mppe_opts & MPPE_OPT_STATEFUL) + state->stateful = 1; + + /* Generate the initial session key. */ + mppe_rekey(state, 1); + + if (debug) { + int i; + char mkey[sizeof(state->master_key) * 2 + 1]; + char skey[sizeof(state->session_key) * 2 + 1]; + + printk(KERN_DEBUG "%s[%d]: initialized with %d-bit %s mode\n", + debugstr, unit, (state->keylen == 16) ? 128 : 40, + (state->stateful) ? "stateful" : "stateless"); + + for (i = 0; i < sizeof(state->master_key); i++) + sprintf(mkey + i * 2, "%02x", state->master_key[i]); + for (i = 0; i < sizeof(state->session_key); i++) + sprintf(skey + i * 2, "%02x", state->session_key[i]); + printk(KERN_DEBUG + "%s[%d]: keys: master: %s initial session: %s\n", + debugstr, unit, mkey, skey); + } + + /* + * Initialize the coherency count. The initial value is not specified + * in RFC 3078, but we can make a reasonable assumption that it will + * start at 0. Setting it to the max here makes the comp/decomp code + * do the right thing (determined through experiment). + */ + state->ccount = MPPE_CCOUNT_SPACE - 1; + + /* + * Note that even though we have initialized the key table, we don't + * set the FLUSHED bit. This is contrary to RFC 3078, sec. 3.1. + */ + state->bits = MPPE_BIT_ENCRYPTED; + + state->unit = unit; + state->debug = debug; + + return 1; +} + +static int +mppe_comp_init(void *arg, unsigned char *options, int optlen, int unit, + int hdrlen, int debug) +{ + /* ARGSUSED */ + return mppe_init(arg, options, optlen, unit, debug, "mppe_comp_init"); +} + +/* + * We received a CCP Reset-Request (actually, we are sending a Reset-Ack), + * tell the compressor to rekey. Note that we MUST NOT rekey for + * every CCP Reset-Request; we only rekey on the next xmit packet. + * We might get multiple CCP Reset-Requests if our CCP Reset-Ack is lost. + * So, rekeying for every CCP Reset-Request is broken as the peer will not + * know how many times we've rekeyed. (If we rekey and THEN get another + * CCP Reset-Request, we must rekey again.) + */ +static void mppe_comp_reset(void *arg) +{ + struct ppp_mppe_state *state = (struct ppp_mppe_state *) arg; + + state->bits |= MPPE_BIT_FLUSHED; +} + +/* + * Compress (encrypt) a packet. + * It's strange to call this a compressor, since the output is always + * MPPE_OVHD + 2 bytes larger than the input. + */ +static int +mppe_compress(void *arg, unsigned char *ibuf, unsigned char *obuf, + int isize, int osize) +{ + struct ppp_mppe_state *state = (struct ppp_mppe_state *) arg; + int proto; + struct scatterlist sg_in[1], sg_out[1]; + + /* + * Check that the protocol is in the range we handle. + */ + proto = PPP_PROTOCOL(ibuf); + if (proto < 0x0021 || proto > 0x00fa) + return 0; + + /* Make sure we have enough room to generate an encrypted packet. */ + if (osize < isize + MPPE_OVHD + 2) { + /* Drop the packet if we should encrypt it, but can't. */ + printk(KERN_DEBUG "mppe_compress[%d]: osize too small! " + "(have: %d need: %d)\n", state->unit, + osize, osize + MPPE_OVHD + 2); + return -1; + } + + osize = isize + MPPE_OVHD + 2; + + /* + * Copy over the PPP header and set control bits. + */ + obuf[0] = PPP_ADDRESS(ibuf); + obuf[1] = PPP_CONTROL(ibuf); + obuf[2] = PPP_COMP >> 8; /* isize + MPPE_OVHD + 1 */ + obuf[3] = PPP_COMP; /* isize + MPPE_OVHD + 2 */ + obuf += PPP_HDRLEN; + + state->ccount = (state->ccount + 1) % MPPE_CCOUNT_SPACE; + if (state->debug >= 7) + printk(KERN_DEBUG "mppe_compress[%d]: ccount %d\n", state->unit, + state->ccount); + obuf[0] = state->ccount >> 8; + obuf[1] = state->ccount & 0xff; + + if (!state->stateful || /* stateless mode */ + ((state->ccount & 0xff) == 0xff) || /* "flag" packet */ + (state->bits & MPPE_BIT_FLUSHED)) { /* CCP Reset-Request */ + /* We must rekey */ + if (state->debug && state->stateful) + printk(KERN_DEBUG "mppe_compress[%d]: rekeying\n", + state->unit); + mppe_rekey(state, 0); + state->bits |= MPPE_BIT_FLUSHED; + } + obuf[0] |= state->bits; + state->bits &= ~MPPE_BIT_FLUSHED; /* reset for next xmit */ + + obuf += MPPE_OVHD; + ibuf += 2; /* skip to proto field */ + isize -= 2; + + /* Encrypt packet */ + setup_sg(sg_in, ibuf, isize); + setup_sg(sg_out, obuf, osize); + if (crypto_cipher_encrypt(state->arc4, sg_out, sg_in, isize) != 0) { + printk(KERN_DEBUG "crypto_cypher_encrypt failed\n"); + return -1; + } + + state->stats.unc_bytes += isize; + state->stats.unc_packets++; + state->stats.comp_bytes += osize; + state->stats.comp_packets++; + + return osize; +} + +/* + * Since every frame grows by MPPE_OVHD + 2 bytes, this is always going + * to look bad ... and the longer the link is up the worse it will get. + */ +static void mppe_comp_stats(void *arg, struct compstat *stats) +{ + struct ppp_mppe_state *state = (struct ppp_mppe_state *) arg; + + *stats = state->stats; +} + +static int +mppe_decomp_init(void *arg, unsigned char *options, int optlen, int unit, + int hdrlen, int mru, int debug) +{ + /* ARGSUSED */ + return mppe_init(arg, options, optlen, unit, debug, "mppe_decomp_init"); +} + +/* + * We received a CCP Reset-Ack. Just ignore it. + */ +static void mppe_decomp_reset(void *arg) +{ + /* ARGSUSED */ + return; +} + +/* + * Decompress (decrypt) an MPPE packet. + */ +static int +mppe_decompress(void *arg, unsigned char *ibuf, int isize, unsigned char *obuf, + int osize) +{ + struct ppp_mppe_state *state = (struct ppp_mppe_state *) arg; + unsigned ccount; + int flushed = MPPE_BITS(ibuf) & MPPE_BIT_FLUSHED; + int sanity = 0; + struct scatterlist sg_in[1], sg_out[1]; + + if (isize <= PPP_HDRLEN + MPPE_OVHD) { + if (state->debug) + printk(KERN_DEBUG + "mppe_decompress[%d]: short pkt (%d)\n", + state->unit, isize); + return DECOMP_ERROR; + } + + /* + * Make sure we have enough room to decrypt the packet. + * Note that for our test we only subtract 1 byte whereas in + * mppe_compress() we added 2 bytes (+MPPE_OVHD); + * this is to account for possible PFC. + */ + if (osize < isize - MPPE_OVHD - 1) { + printk(KERN_DEBUG "mppe_decompress[%d]: osize too small! " + "(have: %d need: %d)\n", state->unit, + osize, isize - MPPE_OVHD - 1); + return DECOMP_ERROR; + } + osize = isize - MPPE_OVHD - 2; /* assume no PFC */ + + ccount = MPPE_CCOUNT(ibuf); + if (state->debug >= 7) + printk(KERN_DEBUG "mppe_decompress[%d]: ccount %d\n", + state->unit, ccount); + + /* sanity checks -- terminate with extreme prejudice */ + if (!(MPPE_BITS(ibuf) & MPPE_BIT_ENCRYPTED)) { + printk(KERN_DEBUG + "mppe_decompress[%d]: ENCRYPTED bit not set!\n", + state->unit); + state->sanity_errors += 100; + sanity = 1; + } + if (!state->stateful && !flushed) { + printk(KERN_DEBUG "mppe_decompress[%d]: FLUSHED bit not set in " + "stateless mode!\n", state->unit); + state->sanity_errors += 100; + sanity = 1; + } + if (state->stateful && ((ccount & 0xff) == 0xff) && !flushed) { + printk(KERN_DEBUG "mppe_decompress[%d]: FLUSHED bit not set on " + "flag packet!\n", state->unit); + state->sanity_errors += 100; + sanity = 1; + } + + if (sanity) { + if (state->sanity_errors < SANITY_MAX) + return DECOMP_ERROR; + else + /* + * Take LCP down if the peer is sending too many bogons. + * We don't want to do this for a single or just a few + * instances since it could just be due to packet corruption. + */ + return DECOMP_FATALERROR; + } + + /* + * Check the coherency count. + */ + + if (!state->stateful) { + /* RFC 3078, sec 8.1. Rekey for every packet. */ + while (state->ccount != ccount) { + mppe_rekey(state, 0); + state->ccount = (state->ccount + 1) % MPPE_CCOUNT_SPACE; + } + } else { + /* RFC 3078, sec 8.2. */ + if (!state->discard) { + /* normal state */ + state->ccount = (state->ccount + 1) % MPPE_CCOUNT_SPACE; + if (ccount != state->ccount) { + /* + * (ccount > state->ccount) + * Packet loss detected, enter the discard state. + * Signal the peer to rekey (by sending a CCP Reset-Request). + */ + state->discard = 1; + return DECOMP_ERROR; + } + } else { + /* discard state */ + if (!flushed) { + /* ccp.c will be silent (no additional CCP Reset-Requests). */ + return DECOMP_ERROR; + } else { + /* Rekey for every missed "flag" packet. */ + while ((ccount & ~0xff) != + (state->ccount & ~0xff)) { + mppe_rekey(state, 0); + state->ccount = + (state->ccount + + 256) % MPPE_CCOUNT_SPACE; + } + + /* reset */ + state->discard = 0; + state->ccount = ccount; + /* + * Another problem with RFC 3078 here. It implies that the + * peer need not send a Reset-Ack packet. But RFC 1962 + * requires it. Hopefully, M$ does send a Reset-Ack; even + * though it isn't required for MPPE synchronization, it is + * required to reset CCP state. + */ + } + } + if (flushed) + mppe_rekey(state, 0); + } + + /* + * Fill in the first part of the PPP header. The protocol field + * comes from the decrypted data. + */ + obuf[0] = PPP_ADDRESS(ibuf); /* +1 */ + obuf[1] = PPP_CONTROL(ibuf); /* +1 */ + obuf += 2; + ibuf += PPP_HDRLEN + MPPE_OVHD; + isize -= PPP_HDRLEN + MPPE_OVHD; /* -6 */ + /* net osize: isize-4 */ + + /* + * Decrypt the first byte in order to check if it is + * a compressed or uncompressed protocol field. + */ + setup_sg(sg_in, ibuf, 1); + setup_sg(sg_out, obuf, 1); + if (crypto_cipher_decrypt(state->arc4, sg_out, sg_in, 1) != 0) { + printk(KERN_DEBUG "crypto_cypher_decrypt failed\n"); + return DECOMP_ERROR; + } + + /* + * Do PFC decompression. + * This would be nicer if we were given the actual sk_buff + * instead of a char *. + */ + if ((obuf[0] & 0x01) != 0) { + obuf[1] = obuf[0]; + obuf[0] = 0; + obuf++; + osize++; + } + + /* And finally, decrypt the rest of the packet. */ + setup_sg(sg_in, ibuf + 1, isize - 1); + setup_sg(sg_out, obuf + 1, osize - 1); + if (crypto_cipher_decrypt(state->arc4, sg_out, sg_in, isize - 1) != 0) { + printk(KERN_DEBUG "crypto_cypher_decrypt failed\n"); + return DECOMP_ERROR; + } + + state->stats.unc_bytes += osize; + state->stats.unc_packets++; + state->stats.comp_bytes += isize; + state->stats.comp_packets++; + + /* good packet credit */ + state->sanity_errors >>= 1; + + return osize; +} + +/* + * Incompressible data has arrived (this should never happen!). + * We should probably drop the link if the protocol is in the range + * of what should be encrypted. At the least, we should drop this + * packet. (How to do this?) + */ +static void mppe_incomp(void *arg, unsigned char *ibuf, int icnt) +{ + struct ppp_mppe_state *state = (struct ppp_mppe_state *) arg; + + if (state->debug && + (PPP_PROTOCOL(ibuf) >= 0x0021 && PPP_PROTOCOL(ibuf) <= 0x00fa)) + printk(KERN_DEBUG + "mppe_incomp[%d]: incompressible (unencrypted) data! " + "(proto %04x)\n", state->unit, PPP_PROTOCOL(ibuf)); + + state->stats.inc_bytes += icnt; + state->stats.inc_packets++; + state->stats.unc_bytes += icnt; + state->stats.unc_packets++; +} + +/************************************************************* + * Module interface table + *************************************************************/ + +/* + * Procedures exported to if_ppp.c. + */ +static struct compressor ppp_mppe = { + .compress_proto = CI_MPPE, + .comp_alloc = mppe_alloc, + .comp_free = mppe_free, + .comp_init = mppe_comp_init, + .comp_reset = mppe_comp_reset, + .compress = mppe_compress, + .comp_stat = mppe_comp_stats, + .decomp_alloc = mppe_alloc, + .decomp_free = mppe_free, + .decomp_init = mppe_decomp_init, + .decomp_reset = mppe_decomp_reset, + .decompress = mppe_decompress, + .incomp = mppe_incomp, + .decomp_stat = mppe_comp_stats, + .owner = THIS_MODULE, + .comp_skb_extra_space = MPPE_COMPRESS_PAD, + .decomp_skb_extra_space = MPPE_DECOMPRESS_PAD, + .must_compress = 1, +}; + +/* + * ppp_mppe_init() + * + * Prior to allowing load, try to load the arc4 and sha1 crypto + * libraries. The actual use will be allocated later, but + * this way the module will fail to insmod if they aren't available. + */ + +static int __init ppp_mppe_init(void) +{ + int answer; + if (!(crypto_alg_available("arc4", 0) && + crypto_alg_available("sha1", 0))) + return -ENODEV; + + sha_pad = kmalloc(sizeof(struct sha_pad), GFP_KERNEL); + if (!sha_pad) + return -ENOMEM; + sha_pad_init(sha_pad); + + answer = ppp_register_compressor(&ppp_mppe); + + if (answer == 0) + printk(KERN_INFO "PPP MPPE Compression module registered\n"); + else + kfree(sha_pad); + + return answer; +} + +static void __exit ppp_mppe_cleanup(void) +{ + ppp_unregister_compressor(&ppp_mppe); + kfree(sha_pad); +} + +module_init(ppp_mppe_init); +module_exit(ppp_mppe_cleanup); diff -urNp --exclude-from=/home/mdomsch/excludes --minimal linux-2.6/drivers/net/ppp_mppe.h linux-2.6-mppe.git/drivers/net/ppp_mppe.h --- linux-2.6/drivers/net/ppp_mppe.h Wed Dec 31 18:00:00 1969 +++ linux-2.6-mppe.git/drivers/net/ppp_mppe.h Fri May 13 00:18:01 2005 @@ -0,0 +1,87 @@ +#define MPPE_COMPRESS_PAD 8 /* MPPE growth per frame */ +#define MPPE_DECOMPRESS_PAD 128 +#define MPPE_MAX_KEY_LEN 16 /* largest key length (128-bit) */ + +/* option bits for ccp_options.mppe */ +#define MPPE_OPT_40 0x01 /* 40 bit */ +#define MPPE_OPT_128 0x02 /* 128 bit */ +#define MPPE_OPT_STATEFUL 0x04 /* stateful mode */ +/* unsupported opts */ +#define MPPE_OPT_56 0x08 /* 56 bit */ +#define MPPE_OPT_MPPC 0x10 /* MPPC compression */ +#define MPPE_OPT_D 0x20 /* Unknown */ +#define MPPE_OPT_UNSUPPORTED (MPPE_OPT_56|MPPE_OPT_MPPC|MPPE_OPT_D) +#define MPPE_OPT_UNKNOWN 0x40 /* Bits !defined in RFC 3078 were set */ + +/* + * This is not nice ... the alternative is a bitfield struct though. + * And unfortunately, we cannot share the same bits for the option + * names above since C and H are the same bit. We could do a u_int32 + * but then we have to do a htonl() all the time and/or we still need + * to know which octet is which. + */ +#define MPPE_C_BIT 0x01 /* MPPC */ +#define MPPE_D_BIT 0x10 /* Obsolete, usage unknown */ +#define MPPE_L_BIT 0x20 /* 40-bit */ +#define MPPE_S_BIT 0x40 /* 128-bit */ +#define MPPE_M_BIT 0x80 /* 56-bit, not supported */ +#define MPPE_H_BIT 0x01 /* Stateless (in a different byte) */ + +/* Does not include H bit; used for least significant octet only. */ +#define MPPE_ALL_BITS (MPPE_D_BIT|MPPE_L_BIT|MPPE_S_BIT|MPPE_M_BIT|MPPE_H_BIT) + +/* Build a CI from mppe opts (see RFC 3078) */ +#define MPPE_OPTS_TO_CI(opts, ci) \ + do { \ + u_char *ptr = ci; /* u_char[4] */ \ + \ + /* H bit */ \ + if (opts & MPPE_OPT_STATEFUL) \ + *ptr++ = 0x0; \ + else \ + *ptr++ = MPPE_H_BIT; \ + *ptr++ = 0; \ + *ptr++ = 0; \ + \ + /* S,L bits */ \ + *ptr = 0; \ + if (opts & MPPE_OPT_128) \ + *ptr |= MPPE_S_BIT; \ + if (opts & MPPE_OPT_40) \ + *ptr |= MPPE_L_BIT; \ + /* M,D,C bits not supported */ \ + } while (/* CONSTCOND */ 0) + +/* The reverse of the above */ +#define MPPE_CI_TO_OPTS(ci, opts) \ + do { \ + u_char *ptr = ci; /* u_char[4] */ \ + \ + opts = 0; \ + \ + /* H bit */ \ + if (!(ptr[0] & MPPE_H_BIT)) \ + opts |= MPPE_OPT_STATEFUL; \ + \ + /* S,L bits */ \ + if (ptr[3] & MPPE_S_BIT) \ + opts |= MPPE_OPT_128; \ + if (ptr[3] & MPPE_L_BIT) \ + opts |= MPPE_OPT_40; \ + \ + /* M,D,C bits */ \ + if (ptr[3] & MPPE_M_BIT) \ + opts |= MPPE_OPT_56; \ + if (ptr[3] & MPPE_D_BIT) \ + opts |= MPPE_OPT_D; \ + if (ptr[3] & MPPE_C_BIT) \ + opts |= MPPE_OPT_MPPC; \ + \ + /* Other bits */ \ + if (ptr[0] & ~MPPE_H_BIT) \ + opts |= MPPE_OPT_UNKNOWN; \ + if (ptr[1] || ptr[2]) \ + opts |= MPPE_OPT_UNKNOWN; \ + if (ptr[3] & ~MPPE_ALL_BITS) \ + opts |= MPPE_OPT_UNKNOWN; \ + } while (/* CONSTCOND */ 0) diff -urNp --exclude-from=/home/mdomsch/excludes --minimal linux-2.6/include/linux/ppp-comp.h linux-2.6-mppe.git/include/linux/ppp-comp.h --- linux-2.6/include/linux/ppp-comp.h Tue Apr 26 15:15:06 2005 +++ linux-2.6-mppe.git/include/linux/ppp-comp.h Fri May 13 00:18:01 2005 @@ -111,6 +111,13 @@ struct compressor { /* Used in locking compressor modules */ struct module *owner; + /* Extra skb space needed by the compressor algorithm */ + unsigned int comp_skb_extra_space; + /* Extra skb space needed by the decompressor algorithm */ + unsigned int decomp_skb_extra_space; + /* if must_compress is set, but ppp->flags != SC_CCP_UP + * then drop the packet */ + unsigned int must_compress; }; /* @@ -189,6 +196,13 @@ struct compressor { #define DEFLATE_METHOD(x) ((x) & 0x0F) #define DEFLATE_MAKE_OPT(w) ((((w) - 8) << 4) + DEFLATE_METHOD_VAL) #define DEFLATE_CHK_SEQUENCE 0 + +/* + * Definitions for MPPE. + */ + +#define CI_MPPE 18 /* config option for MPPE */ +#define CILEN_MPPE 6 /* length of config option */ /* * Definitions for other, as yet unsupported, compression methods. From jketreno@linux.intel.com Thu May 12 23:26:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 12 May 2005 23:26:35 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D6QTOv005557 for ; Thu, 12 May 2005 23:26:30 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4D6Q13O022370; Fri, 13 May 2005 06:26:01 GMT Received: from [192.168.1.154] (hdlrvguser-282.hd.intel.com [10.127.53.45]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j4D6Pw8B025627; Fri, 13 May 2005 06:25:59 GMT Message-ID: <42844876.8060907@linux.intel.com> Date: Fri, 13 May 2005 01:25:58 -0500 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg KH CC: Pavel Machek , netdev@oss.sgi.com, kernel list , jbohac@suse.cz, jbenc@suse.cz Subject: Re: ipw2100: intrusive cleanups, working this time ;-) References: <20050512225026.GA2822@elf.ucw.cz> <4283FA4D.3010208@linux.intel.com> <20050513034201.GA11817@kroah.com> In-Reply-To: <20050513034201.GA11817@kroah.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1084 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 2110 Lines: 61 Greg KH wrote: >On Thu, May 12, 2005 at 07:52:29PM -0500, James Ketrenos wrote: > > >>Part of the process we have in place is to try and make sure that the >>versions that get picked up by distros and the majority of users have a >>'known' level of quality. As part of that, we only want to get changes >>pushed to -mm and eventual mainline that have gone through regression >>testing. >> >> > >Any chance of making those regression tests public so we can all do this >kind of testing on any future changes that might be made to the driver? > > I believe all of our test plans are available publically. We just put up test runner on our bugzilla server so that we can better track which tests have been run by users, etc. Some tests are automated, some are manual. The bugzilla site is http://bughost.org and test tracker is toward the bottom of that page. You can also find information at http://ipw2200.sf.net/validation.php >Remember, once it hits mainline, lots of different people will be >touching it for various reasons at times... > > I am hopeful that if we can get a process streamlined enough so that regression passes can occur quickly, we will be able to keep pace w/ any critical fixes or changes that are desired to go into mainline. What is driving the approach is that our customers want to build solutions with drivers that have gone through a known level of interoperability and functionality testing. We ideally want to be able to say "you can either download the driver version X from http://whatever, or any mainline kernel newer than 2.6.13+". However we can only do that if the code that is pulled into mainline /has/ gone through all of that testing. The reality of the community process may require that we can only say "version X from http://whatever or versions 2.6.{x,y,z} of the kernel" if patches are accepted into the tree that haven't been sufficiently tested. We want to have a process that meets the needs of the end users, the ipw* and kernel development communities, the platform manufacturers, and the distros. James >thanks, > >greg k-h > > From SRS0+33aca89faedceed6ea9b+628+infradead.org+hch@pentafluge.srs.infradead.org Fri May 13 01:22:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 01:22:25 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D8MCOv014062 for ; Fri, 13 May 2005 01:22:21 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DWVQV-0000Aw-Lq; Fri, 13 May 2005 09:21:43 +0100 Date: Fri, 13 May 2005 09:21:43 +0100 From: Christoph Hellwig To: James Ketrenos Cc: Pavel Machek , netdev@oss.sgi.com, kernel list , jbohac@suse.cz, jbenc@suse.cz Subject: Re: ipw2100: intrusive cleanups, working this time ;-) Message-ID: <20050513082143.GA553@infradead.org> Mail-Followup-To: Christoph Hellwig , James Ketrenos , Pavel Machek , netdev@oss.sgi.com, kernel list , jbohac@suse.cz, jbenc@suse.cz References: <20050512225026.GA2822@elf.ucw.cz> <4283FA4D.3010208@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4283FA4D.3010208@linux.intel.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 1085 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 676 Lines: 13 On Thu, May 12, 2005 at 07:52:29PM -0500, James Ketrenos wrote: > Part of the process we have in place is to try and make sure that the > versions that get picked up by distros and the majority of users have a > 'known' level of quality. As part of that, we only want to get changes > pushed to -mm and eventual mainline that have gone through regression > testing. The only wait to make that works is to opensource the testsuites and allow the distros to run the QA test themselves. Except for maybe SuSE no one will pick up a driver version just because you say so. p.s. please remove the part of the mail you follow up to that's not relevant yo your posting. thanks. From vda@ilport.com.ua Fri May 13 01:38:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 01:38:24 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (167.imtp.Ilyichevsk.Odessa.UA [195.66.192.167] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4D8boOv015010 for ; Fri, 13 May 2005 01:38:08 -0700 Received: (qmail 30398 invoked by alias); 13 May 2005 08:37:06 -0000 Received: from unknown (172.17.13.22) by 0 (195.66.192.170) with ESMTP; 13 May 2005 08:37:00 -0000 From: Denis Vlasenko To: Pavel Machek , jketreno@linux.intel.com, netdev@oss.sgi.com, kernel list Subject: Re: ipw2100: intrusive cleanups, working this time ;-) Date: Fri, 13 May 2005 11:36:56 +0300 User-Agent: KMail/1.5.4 Cc: jbohac@suse.cz, jbenc@suse.cz References: <20050512225026.GA2822@elf.ucw.cz> In-Reply-To: <20050512225026.GA2822@elf.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505131136.56641.vda@ilport.com.ua> X-archive-position: 1086 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@ilport.com.ua Precedence: bulk X-list: netdev Content-Length: 492 Lines: 18 On Friday 13 May 2005 01:50, Pavel Machek wrote: > Hi! > > There's a lot to clean up in header file, too... And this time it > actually works. Since you apparently have this hardware, I'm going to hijack your attention for a second for the benefit of wireless crowd. How good it it? Signal strength/sensitivity? Does driver/fw/hw survive prolonged packet flood testing? I'm asking because so far I never saw 11g hw which does. I tried prism54 and acx111. Is ipw2000 worth buying? -- vda From pavel@ucw.cz Fri May 13 02:41:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 02:41:45 -0700 (PDT) Received: from amd.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4D9fYOv017455 for ; Fri, 13 May 2005 02:41:37 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 206C58CDE9; Fri, 13 May 2005 11:41:36 +0200 (CEST) Date: Fri, 13 May 2005 11:41:36 +0200 From: Pavel Machek To: Denis Vlasenko Cc: jketreno@linux.intel.com, netdev@oss.sgi.com, kernel list , jbohac@suse.cz, jbenc@suse.cz Subject: Re: ipw2100: intrusive cleanups, working this time ;-) Message-ID: <20050513094135.GD1780@elf.ucw.cz> References: <20050512225026.GA2822@elf.ucw.cz> <200505131136.56641.vda@ilport.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505131136.56641.vda@ilport.com.ua> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.9i X-archive-position: 1087 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: netdev Content-Length: 655 Lines: 22 Hi! > > There's a lot to clean up in header file, too... And this time it > > actually works. > > Since you apparently have this hardware, > I'm going to hijack your attention for a second > for the benefit of wireless crowd. > > How good it it? Signal strength/sensitivity? No idea, flat I live in is so small I can get away with connecting using bluetooth. > Does driver/fw/hw survive prolonged packet flood testing? > I'm asking because so far I never saw 11g hw which does. > I tried prism54 and acx111. Is ipw2000 worth buying? I'm not sure if ipw2100 supports 802.11g.... Pavel -- Boycott Kodak -- for their patent abuse against Java. From glynis@butterfly.hjsoft.com Fri May 13 04:54:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 04:54:53 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DBslOv026544 for ; Fri, 13 May 2005 04:54:47 -0700 Received: from butterfly.hjsoft.com ([68.85.252.133]) by comcast.net (rwcrmhc13) with ESMTP id <2005051311541801500d2f9oe>; Fri, 13 May 2005 11:54:18 +0000 Received: from butterfly.hjsoft.com (glynis@localhost [127.0.0.1]) by butterfly.hjsoft.com (8.13.4/8.13.4/Debian-2) with ESMTP id j4DBsHAT005741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 May 2005 07:54:17 -0400 Received: (from glynis@localhost) by butterfly.hjsoft.com (8.13.4/8.13.4/Submit) id j4DBsGf6005740; Fri, 13 May 2005 07:54:16 -0400 Date: Fri, 13 May 2005 07:54:16 -0400 From: John M Flinchbaugh To: Denis Vlasenko Cc: netdev@oss.sgi.com, kernel list Subject: Re: ipw2100: intrusive cleanups, working this time ;-) Message-ID: <20050513115416.GA4914@butterfly.hjsoft.com> References: <20050512225026.GA2822@elf.ucw.cz> <200505131136.56641.vda@ilport.com.ua> <20050513094135.GD1780@elf.ucw.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <20050513094135.GD1780@elf.ucw.cz> User-Agent: Mutt/1.5.9i X-archive-position: 1089 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: john@hjsoft.com Precedence: bulk X-list: netdev Content-Length: 924 Lines: 32 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 13, 2005 at 11:41:36AM +0200, Pavel Machek wrote: > > Does driver/fw/hw survive prolonged packet flood testing? > > I'm asking because so far I never saw 11g hw which does. > > I tried prism54 and acx111. Is ipw2000 worth buying? > I'm not sure if ipw2100 supports 802.11g.... ipw2200 supports g, and is in a different project at http://ipw2200.sf.net. ipw2100 is only b. --=20 John M Flinchbaugh john@hjsoft.com --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFChJVoCGPRljI8080RAp+vAJsEzleuvSCG6mUAy39w+f3tT8EmkgCeIlGA KjM3cqhHhp8WVMaA9GPEoxo= =nhgv -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From herbert@gondor.apana.org.au Fri May 13 06:25:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 06:25:49 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DDPdOv031002 for ; Fri, 13 May 2005 06:25:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWaA5-0006vC-00; Fri, 13 May 2005 23:25:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWaA2-000630-00; Fri, 13 May 2005 23:25:02 +1000 Date: Fri, 13 May 2005 23:25:02 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: issue with new TCP TSO stuff Message-ID: <20050513132502.GA22568@gondor.apana.org.au> References: <20050512231038.GA22440@gondor.apana.org.au> <20050512.162426.75782784.davem@davemloft.net> <20050512235236.GA22658@gondor.apana.org.au> <20050512.213618.14358320.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512.213618.14358320.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1091 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2788 Lines: 61 On Thu, May 12, 2005 at 09:36:18PM -0700, David S. Miller wrote: > > Yes, when we walk the queue to retransmit, we chop up the > TSO frame via tcp_trim_head() and tcp_fragment(). It is > very loose and would need refinements though. I'm also thinking that we might also want to do segmentation in response to SACKs. So we'd start with a super-frame and keep trimming bits off at the head as normal ACKs stream in. Once we get a SACK, we chop it down the middle to create two SKBs. > I think we'd be OK, because even if we get a GFP_ATOMIC allocation > failure, it's just like any other failure. We're doing retransmits > so a timer will be the worst case deadlock breaker should we get an > allocation failure while chopping up the TSO frame. Yep. > This actually makes me worried about sk->sk_send_head advancement. > I think we have a deadlock possible here. If sk->sk_send_head is > the only packet in the output queue, and the remote system has no > reason to send us zero-window probes or any other packets, we could > wedge if the skb_clone() fails for the tcp_transmit_skb() call. > We won't set any timers if we fail to send that single sk->sk_send_head > write queue packet, and we have no pending frames waiting to be ACK'd, > so nothing will wake us up to retry the transmit. AFAIK all the paths that do the initial send will start a timer if it fails. I've checked the callers of tcp_push_one, tcp_write_xmit and tcp_write_wakeup. I might've easily missed something though. > That loop in there is bogus and unnecessary. In the changelog for > the TCP Reloaded patch I mention that this can be simplified into: > > new_packets = skb_queue_len(&sk->sk_write_queue) - in_flight; > cwnd -= in_flight; > return min(new_packets, cwnd); I think we still need to limit it to snd_wnd which is what the loop was doing. > To handle these super-TSO frames properly, we would need to add > sk->sk_send_offset to go along with sk->sk_send_head. So then > update_send_head() would advance sk->sk_send_offset, and if that > completely consumed sk->sk_send_head then the pointer would be > advanced. We probably shouldn't avoid segmentation altogether. We could just segment lazily. So when we come around to actually transmitting something, we will allocate an skb and cut off the data according to the cwnd. We should then store the segmented skb's on our send queue instead of the super-frame since we've spent that effort anyway and it's pretty unlikely for us to have to retransmit something that crosses the point where we cut off the skb. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bunk@stusta.de Fri May 13 06:50:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 06:51:11 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4DDoZOv032276 for ; Fri, 13 May 2005 06:50:55 -0700 Received: (qmail 3598 invoked from network); 13 May 2005 13:50:06 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 13 May 2005 13:50:06 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 4E18DBB5F7; Fri, 13 May 2005 15:50:05 +0200 (CEST) Date: Fri, 13 May 2005 15:50:04 +0200 From: Adrian Bunk To: Clay Haapala Cc: sri@us.ibm.com, lksctp-developers@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: SCTP: use lib/libcrc32c.c instead of net/sctp/crc32c.c? Message-ID: <20050513135004.GG3603@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 1092 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 409 Lines: 15 As far as I understand it, lib/libcrc32c.c could be used instead of the similar code in net/sctp/crc32c.c . Is there any reason why this isn't done? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From jleu@mindspring.com Fri May 13 07:05:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 07:05:27 -0700 (PDT) Received: from argus.dangermen.com (mdsnwi16-vlan463-209.dsl.tds.net [216.170.241.209]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DE5MOv001106 for ; Fri, 13 May 2005 07:05:23 -0700 Received: from argus.dangermen.com (localhost [127.0.0.1]) by argus.dangermen.com (8.12.10/8.12.4) with ESMTP id j4DE9c37007406; Fri, 13 May 2005 09:09:39 -0500 Received: (from jleu@localhost) by argus.dangermen.com (8.12.10/8.12.4/Submit) id j4DE9ciM007405; Fri, 13 May 2005 09:09:38 -0500 X-Authentication-Warning: argus.dangermen.com: jleu set sender to jleu@mindspring.com using -f Date: Fri, 13 May 2005 09:09:38 -0500 From: "James R. Leu" To: cranium2003 Cc: net dev Subject: Re: Linux Routers working Message-ID: <20050513140938.GB5384@mindspring.com> Reply-To: jleu@mindspring.com References: <20050513041623.95169.qmail@web41425.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline In-Reply-To: <20050513041623.95169.qmail@web41425.mail.yahoo.com> User-Agent: Mutt/1.4.2i X-archive-position: 1093 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jleu@mindspring.com Precedence: bulk X-list: netdev Content-Length: 1300 Lines: 50 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 12, 2005 at 09:16:23PM -0700, cranium2003 wrote: > Hello, > Is there any way on linux routers to know on > which interface packet is forwarded before actually > packet trasmission begins? Also before packet > processed by IP layer can it be possible to know from > which adjecent Router'IP packet came to that router? > regards, > cranium I think the OUTPUT chain in iptables already knows what the outbound interface is, so you could make a decision based on that. I think you can use the mac target in the PREROUTING chain to get access to the source MAC address. I think all of your answers are in iptables. >=20 >=20 > =09 > __________________________________=20 > Yahoo! Mail Mobile=20 > Take Yahoo! Mail with you! Check email on your mobile phone.=20 > http://mobile.yahoo.com/learn/mail=20 --=20 James R. Leu jleu@mindspring.com --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQFChLUiQcSCk6yg8WERAvFKAJ9yGw3aPiUiypfZ63e8DfuOPO5JLACgo3le 2/dFTrNouev2Bpwg+S+q83U= =AmhJ -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- From jketreno@linux.intel.com Fri May 13 08:18:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 08:18:26 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DFINOv003927 for ; Fri, 13 May 2005 08:18:23 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4DFHtcL020513; Fri, 13 May 2005 15:17:55 GMT Received: from [127.0.0.1] (hdlrvguser-282.hd.intel.com [10.127.53.45]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j4DFHpOU019297; Fri, 13 May 2005 15:17:53 GMT Message-ID: <4284C54E.3060907@linux.intel.com> Date: Fri, 13 May 2005 10:18:38 -0500 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Netdev , Linux Kernel Subject: Re: git repository for net drivers available References: <42841A3F.7020909@pobox.com> In-Reply-To: <42841A3F.7020909@pobox.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1094 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 1738 Lines: 54 Jeff Garzik wrote: > > This includes the wireless-2.6 repository. > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git > > The main branch is fairly irrelevant, as you must choose the branch > you wish: > >> [jgarzik@pretzel netdev-2.6]$ ls .git/branches/ >> 8139cp e1000 ixgb r8169 skge >> we18 >> 8139too-iomap forcedeth janitor register-netdev smc91x >> wifi >> amd8111 ieee80211 orinoco remove-drivers smc91x-eeprom >> e100 iff-running ppp sis900 starfire > Ok, I'll bite. Hopefully I'm not the only one tripping on shoe laces... Here is what I did -- what am I doing wrong? Following is using cogito 0.10: REPO=rsync://rsync.kernel.org/pubs/scm/linux/kernel/git/jgarzik/netdev-2.6.git cg-clone ${REPO} .... get coffee, etc. ... come back and I have a netdev-2.6 tree ... cg-branch-add wifi ${REPO}#wifi cg-update wifi .... connects and attempts to download but fails out with: ---------------- receiving file list ... done client: nothing to do: perhaps you need to specify some filenames or the --recursive option? rsync: link_stat "/scm/linux/kernel/git/jgarzik/netdev-2.6.git/heads/wifi" (in pub) failed: No such file or directory (2) rsync error: some files could not be transferred (code 23) at main.c(653) receiving file list ... done client: nothing to do: perhaps you need to specify some filenames or the --recursive option? cg-pull: unable to get the head pointer of branch wifi ---------------- Should it be trying to get 'wifi' from ...netdev-2.6.git/branches (vs. heads)? Tool problem, user problem, complete lack of knowledge re: git and cogito, or a combination of the above? Thanks, James From jgarzik@pobox.com Fri May 13 08:30:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 08:30:07 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DFU4Ov008455 for ; Fri, 13 May 2005 08:30:04 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DWc6Y-0001Zc-6c; Fri, 13 May 2005 15:29:35 +0000 Message-ID: <4284C7DA.1020707@pobox.com> Date: Fri, 13 May 2005 11:29:30 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: Netdev , Linux Kernel Subject: Re: git repository for net drivers available References: <42841A3F.7020909@pobox.com> <4284C54E.3060907@linux.intel.com> In-Reply-To: <4284C54E.3060907@linux.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1095 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1999 Lines: 67 James Ketrenos wrote: > Jeff Garzik wrote: > > >>This includes the wireless-2.6 repository. >> >>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git >> >>The main branch is fairly irrelevant, as you must choose the branch >>you wish: >> >> >>>[jgarzik@pretzel netdev-2.6]$ ls .git/branches/ >>>8139cp e1000 ixgb r8169 skge >>>we18 >>>8139too-iomap forcedeth janitor register-netdev smc91x >>>wifi >>>amd8111 ieee80211 orinoco remove-drivers smc91x-eeprom >>>e100 iff-running ppp sis900 starfire >> > Ok, I'll bite. Hopefully I'm not the only one tripping on shoe laces... > > Here is what I did -- what am I doing wrong? > > Following is using cogito 0.10: > > REPO=rsync://rsync.kernel.org/pubs/scm/linux/kernel/git/jgarzik/netdev-2.6.git > cg-clone ${REPO} > .... get coffee, etc. ... come back and I have a netdev-2.6 tree ... > cg-branch-add wifi ${REPO}#wifi > cg-update wifi > .... connects and attempts to download but fails out with: > > ---------------- > receiving file list ... done > client: nothing to do: perhaps you need to specify some filenames or the > --recursive option? > > rsync: link_stat > "/scm/linux/kernel/git/jgarzik/netdev-2.6.git/heads/wifi" (in pub) > failed: No such file or directory (2) Looks like cogito is using $repo/heads/$branch, whereas my git repo is using $repo/branches/$branch. You can achieve what's necessary with > rsync --verbose --delete --stats --progress \ > -a rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git/ .git and then > ( cd .git ; rm -f HEAD ; ln -s branches/wifi HEAD ) and then > git-read-tree $(cat .git/HEAD) && git-checkout-cache -q -f -a && git-update-cache --refresh For what it's worth, this is only netdev-2.6 as it appeared in BitKeeper. I am only now merging all the emailed patches since BK devel stopped into git, which includes the ipw code you submitted. Jeff From greg@kroah.com Fri May 13 09:48:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 09:48:41 -0700 (PDT) Received: from perch.kroah.org (mail.kroah.org [69.55.234.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DGmZOv016588 for ; Fri, 13 May 2005 09:48:35 -0700 Received: from [192.168.0.10] (c-24-22-118-199.hsd1.or.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j4DGlxi19653; Fri, 13 May 2005 09:47:59 -0700 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1DWdKX-30x-00; Fri, 13 May 2005 09:48:05 -0700 Date: Fri, 13 May 2005 09:48:05 -0700 From: Greg KH To: James Ketrenos Cc: Pavel Machek , netdev@oss.sgi.com, kernel list , jbohac@suse.cz, jbenc@suse.cz Subject: Re: ipw2100: intrusive cleanups, working this time ;-) Message-ID: <20050513164804.GI11089@kroah.com> References: <20050512225026.GA2822@elf.ucw.cz> <4283FA4D.3010208@linux.intel.com> <20050513034201.GA11817@kroah.com> <42844876.8060907@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42844876.8060907@linux.intel.com> User-Agent: Mutt/1.5.8i X-archive-position: 1096 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev Content-Length: 2653 Lines: 64 On Fri, May 13, 2005 at 01:25:58AM -0500, James Ketrenos wrote: > Greg KH wrote: > >On Thu, May 12, 2005 at 07:52:29PM -0500, James Ketrenos wrote: > >>Part of the process we have in place is to try and make sure that the > >>versions that get picked up by distros and the majority of users have a > >>'known' level of quality. As part of that, we only want to get changes > >>pushed to -mm and eventual mainline that have gone through regression > >>testing. > > > >Any chance of making those regression tests public so we can all do this > >kind of testing on any future changes that might be made to the driver? > > I believe all of our test plans are available publically. We just put > up test runner on our bugzilla server so that we can better track which > tests have been run by users, etc. Some tests are automated, some are > manual. > > The bugzilla site is http://bughost.org and test tracker is toward the > bottom of that page. > > You can also find information at http://ipw2200.sf.net/validation.php Nice, thanks for the pointers. > >Remember, once it hits mainline, lots of different people will be > >touching it for various reasons at times... > > > > > I am hopeful that if we can get a process streamlined enough so that > regression passes can occur quickly, we will be able to keep pace w/ any > critical fixes or changes that are desired to go into mainline. > > What is driving the approach is that our customers want to build > solutions with drivers that have gone through a known level of > interoperability and functionality testing. > > We ideally want to be able to say "you can either download the driver > version X from http://whatever, or any mainline kernel newer than > 2.6.13+". However we can only do that if the code that is pulled into > mainline /has/ gone through all of that testing. Of course. > The reality of the community process may require that we can only say > "version X from http://whatever or versions 2.6.{x,y,z} of the kernel" > if patches are accepted into the tree that haven't been sufficiently tested. Good luck testing every kernel release :) Perhaps you might want to automate this with a test against the kernel-of-the-day once the driver makes it into mainline? I know some people who are working on a kernel tinderbox that this kind of effort would tie nicely into. > We want to have a process that meets the needs of the end users, the > ipw* and kernel development communities, the platform manufacturers, and > the distros. That's a good goal, sounds like you are well on your way. Now if only everyone would have test suites for drivers... thanks, greg k-h From jgarzik@pobox.com Fri May 13 10:00:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 10:00:42 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DH0dOv020707 for ; Fri, 13 May 2005 10:00:39 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DWdWC-0001g4-OA; Fri, 13 May 2005 17:00:09 +0000 Message-ID: <4284DD16.8090405@pobox.com> Date: Fri, 13 May 2005 13:00:06 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC: 2.6 patch] make MII no longer user visible References: <20050513035257.GC3603@stusta.de> In-Reply-To: <20050513035257.GC3603@stusta.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1097 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 298 Lines: 13 Adrian Bunk wrote: > MII is a classical example of a helper option no user should ever see. Incorrect. It's the classic example of an option that distributors may want to build as a module, even if no shipped modules need it, to enable net driver development and use in their kernel. Jeff From shemminger@osdl.org Fri May 13 10:58:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 10:58:32 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DHwTOv023568 for ; Fri, 13 May 2005 10:58:30 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4DHvsU3016519 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 May 2005 10:57:55 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4DHvsfp018727; Fri, 13 May 2005 10:57:54 -0700 Date: Fri, 13 May 2005 10:57:54 -0700 From: Stephen Hemminger To: Jamal Hadi Salim , Patrick McHardy Cc: netdev@oss.sgi.com, lartc Subject: Qdisc requeue should be void? Message-ID: <20050513105754.2e7cc243@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1098 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 787 Lines: 24 There is an design problem with the qdisc interface that causes qlen related bugs in netem, tbf, and other qdisc's that peek at the top of the queue. The problem is that requeue needs to be called from the dequeue function but requeue can fail. If requeue fails, then the calling qdisc can not properly handle the error. If it returns NULL, then the parent's expectation about qlen gets messed up. Example: prio (qlen = 1) skb = netem dequeue skb = htb dequeue ... decides not to send this skb now htp requeue(skb) fails ?? what now --netem.qlen // := 0 return NULL skb is NULL at this point prio qlen is 1 but underlying queue's are empty. My proposal is to require requeue to always succeed and change it to be void instead of returning int. From linux-netdev@gmane.org Fri May 13 13:19:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 13:19:20 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DKJEOv031085 for ; Fri, 13 May 2005 13:19:16 -0700 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DWgUE-0003g4-5l for netdev@oss.sgi.com; Fri, 13 May 2005 22:10:18 +0200 Received: from 66.150.84.1 ([66.150.84.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 May 2005 22:10:18 +0200 Received: from dilinger by 66.150.84.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 May 2005 22:10:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Andres Salomon Subject: Re: Status of net/ipv4/ipvs/ip_vs_proto_icmp.c? Date: Fri, 13 May 2005 15:09:01 -0400 Message-ID: References: <20050513041622.GE3603@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 66.150.84.1 User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) Cc: linux-kernel@vger.kernel.org X-archive-position: 1099 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dilinger@athenacr.com Precedence: bulk X-list: netdev Content-Length: 526 Lines: 28 On Fri, 13 May 2005 06:16:22 +0200, Adrian Bunk wrote: > Hi, > > can anyone explain the status of? > > This file is always included in the kernel if CONFIG_IP_VS=y, but it's > completely unused. > > Will it be made working in the forseeable future or is it a candidate > for removal? > > TIA > Adrian The people/places to ask would probably be: IPVS P: Wensong Zhang M: wensong@linux-vs.org P: Julian Anastasov M: ja@ssi.bg S: Maintained or http://www.linuxvirtualserver.org/mailing.html From pavel@ucw.cz Fri May 13 14:42:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 14:42:40 -0700 (PDT) Received: from amd.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4DLeTOv001431 for ; Fri, 13 May 2005 14:40:32 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id B88C68CDF2; Fri, 13 May 2005 23:40:25 +0200 (CEST) Date: Fri, 13 May 2005 23:40:25 +0200 From: Pavel Machek To: jketreno@linux.intel.com, netdev@oss.sgi.com, kernel list Cc: jbohac@suse.cz, jbenc@suse.cz Subject: ipw2100: more cleanups Message-ID: <20050513214025.GA1863@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.9i X-archive-position: 1100 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@ucw.cz Precedence: bulk X-list: netdev Content-Length: 61493 Lines: 2075 Hi! More cleanups (relative to ipw2100-1.1.0 version). Highlights include removing of two printk wrappers. Pavel --- clean-mm/drivers/net/wireless/ipw2100.c 2005-05-11 22:00:02.000000000 +0200 +++ linux-mm/drivers/net/wireless/ipw2100.c 2005-05-13 23:30:47.000000000 +0200 @@ -106,7 +106,7 @@ tx_pend_list : Holds used Tx buffers waiting to go into the TBD ring TAIL modified ipw2100_tx() - HEAD modified by X__ipw2100_tx_send_data() + HEAD modified by ipw2100_tx_send_data() msg_free_list : Holds pre-allocated Msg (Command) buffers TAIL modified in __ipw2100_tx_process() @@ -114,7 +114,7 @@ msg_pend_list : Holds used Msg buffers waiting to go into the TBD ring TAIL modified in ipw2100_hw_send_command() - HEAD modified in X__ipw2100_tx_send_commands() + HEAD modified in ipw2100_tx_send_commands() The flow of data on the TX side is as follows: @@ -150,7 +150,6 @@ #include #include #include -#define __KERNEL_SYSCALLS__ #include #include #include @@ -171,14 +170,9 @@ #define DRV_NAME "ipw2100" #define DRV_VERSION IPW2100_VERSION #define DRV_DESCRIPTION "Intel(R) PRO/Wireless 2100 Network Driver" -#define DRV_COPYRIGHT "Copyright(c) 2003-2004 Intel Corporation" +#define DRV_COPYRIGHT "Copyright(c) 2003-2005 Intel Corporation" -/* Debugging stuff */ -#ifdef CONFIG_IPW_DEBUG -#define CONFIG_IPW2100_RX_DEBUG /* Reception debugging */ -#endif - MODULE_DESCRIPTION(DRV_DESCRIPTION); MODULE_VERSION(DRV_VERSION); MODULE_AUTHOR(DRV_COPYRIGHT); @@ -189,9 +183,7 @@ static int channel = 0; static int associate = 1; static int disable = 0; -#ifdef CONFIG_PM static struct ipw2100_fw ipw2100_firmware; -#endif #include module_param(debug, int, 0444); @@ -286,8 +278,8 @@ /* Pre-decl until we get the code solid and then we can clean it up */ -static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv); -static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv); +static void ipw2100_tx_send_commands(struct ipw2100_priv *priv); +static void ipw2100_tx_send_data(struct ipw2100_priv *priv); static int ipw2100_adapter_setup(struct ipw2100_priv *priv); static void ipw2100_queues_initialize(struct ipw2100_priv *priv); @@ -483,7 +475,7 @@ u32 total_length; if (ordinals->table1_addr == 0) { - IPW_DEBUG_WARNING(DRV_NAME ": attempt to use fw ordinals " + printk(KERN_WARNING DRV_NAME ": attempt to use fw ordinals " "before they have been loaded.\n"); return -EINVAL; } @@ -492,8 +484,7 @@ if (*len < IPW_ORD_TAB_1_ENTRY_SIZE) { *len = IPW_ORD_TAB_1_ENTRY_SIZE; - IPW_DEBUG_WARNING(DRV_NAME - ": ordinal buffer length too small, need %d\n", + printk(KERN_WARNING DRV_NAME ": ordinal buffer length too small, need %d\n", IPW_ORD_TAB_1_ENTRY_SIZE); return -EINVAL; @@ -545,7 +536,7 @@ return 0; } - IPW_DEBUG_WARNING(DRV_NAME ": ordinal %d neither in table 1 nor " + printk(KERN_WARNING DRV_NAME ": ordinal %d neither in table 1 nor " "in table 2\n", ord); return -EINVAL; @@ -735,8 +726,8 @@ list_add_tail(element, &priv->msg_pend_list); INC_STAT(&priv->msg_pend_stat); - X__ipw2100_tx_send_commands(priv); - X__ipw2100_tx_send_data(priv); + ipw2100_tx_send_commands(priv); + ipw2100_tx_send_data(priv); spin_unlock_irqrestore(&priv->low_lock, flags); @@ -760,7 +751,7 @@ } if (priv->fatal_error) { - IPW_DEBUG_WARNING("%s: firmware fatal error\n", + printk(KERN_WARNING DRV_NAME ": %s: firmware fatal error\n", priv->net_dev->name); return -EIO; } @@ -915,12 +906,10 @@ if (i == 10000) return -EIO; /* TODO: better error value */ -//#if CONFIG_IPW2100_D0ENABLED /* set D0 standby bit */ read_register(priv->net_dev, IPW_REG_GP_CNTRL, &r); write_register(priv->net_dev, IPW_REG_GP_CNTRL, r | IPW_AUX_HOST_GP_CNTRL_BIT_HOST_ALLOWS_STANDBY); -//#endif return 0; } @@ -941,50 +930,35 @@ u32 address; int err; -#ifndef CONFIG_PM - /* Fetch the firmware and microcode */ - struct ipw2100_fw ipw2100_firmware; -#endif - if (priv->fatal_error) { - IPW_DEBUG_ERROR("%s: ipw2100_download_firmware called after " + printk(KERN_ERR DRV_NAME ": %s: ipw2100_download_firmware called after " "fatal error %d. Interface must be brought down.\n", priv->net_dev->name, priv->fatal_error); return -EINVAL; } -#ifdef CONFIG_PM if (!ipw2100_firmware.version) { err = ipw2100_get_firmware(priv, &ipw2100_firmware); if (err) { - IPW_DEBUG_ERROR("%s: ipw2100_get_firmware failed: %d\n", + printk(KERN_ERR DRV_NAME ": %s: ipw2100_get_firmware failed: %d\n", priv->net_dev->name, err); priv->fatal_error = IPW2100_ERR_FW_LOAD; goto fail; } } -#else - err = ipw2100_get_firmware(priv, &ipw2100_firmware); - if (err) { - IPW_DEBUG_ERROR("%s: ipw2100_get_firmware failed: %d\n", - priv->net_dev->name, err); - priv->fatal_error = IPW2100_ERR_FW_LOAD; - goto fail; - } -#endif priv->firmware_version = ipw2100_firmware.version; /* s/w reset and clock stabilization */ err = sw_reset_and_clock(priv); if (err) { - IPW_DEBUG_ERROR("%s: sw_reset_and_clock failed: %d\n", + printk(KERN_ERR DRV_NAME ": %s: sw_reset_and_clock failed: %d\n", priv->net_dev->name, err); goto fail; } err = ipw2100_verify(priv); if (err) { - IPW_DEBUG_ERROR("%s: ipw2100_verify failed: %d\n", + printk(KERN_ERR DRV_NAME ": %s: ipw2100_verify failed: %d\n", priv->net_dev->name, err); goto fail; } @@ -1000,7 +974,7 @@ /* load microcode */ err = ipw2100_ucode_download(priv, &ipw2100_firmware); if (err) { - IPW_DEBUG_ERROR("%s: Error loading microcode: %d\n", + printk(KERN_ERR DRV_NAME ": %s: Error loading microcode: %d\n", priv->net_dev->name, err); goto fail; } @@ -1013,7 +987,7 @@ /* s/w reset and clock stabilization (again!!!) */ err = sw_reset_and_clock(priv); if (err) { - IPW_DEBUG_ERROR("%s: sw_reset_and_clock failed: %d\n", + printk(KERN_ERR DRV_NAME ": %s: sw_reset_and_clock failed: %d\n", priv->net_dev->name, err); goto fail; } @@ -1021,23 +995,11 @@ /* load f/w */ err = ipw2100_fw_download(priv, &ipw2100_firmware); if (err) { - IPW_DEBUG_ERROR("%s: Error loading firmware: %d\n", + printk(KERN_ERR DRV_NAME ": %s: Error loading firmware: %d\n", priv->net_dev->name, err); goto fail; } -#ifndef CONFIG_PM - /* - * When the .resume method of the driver is called, the other - * part of the system, i.e. the ide driver could still stay in - * the suspend stage. This prevents us from loading the firmware - * from the disk. --YZ - */ - - /* free any storage allocated for firmware image */ - ipw2100_release_firmware(priv, &ipw2100_firmware); -#endif - /* zero out Domain 1 area indirectly (Si requirement) */ for (address = IPW_HOST_FW_SHARED_AREA0; address < IPW_HOST_FW_SHARED_AREA0_END; address += 4) @@ -1083,8 +1045,6 @@ { struct ipw2100_ordinals *ord = &priv->ordinals; - IPW_DEBUG_INFO("enter\n"); - read_register(priv->net_dev, IPW_MEM_HOST_SHARED_ORDINALS_TABLE_1, &ord->table1_addr); @@ -1095,10 +1055,6 @@ read_nic_dword(priv->net_dev, ord->table2_addr, &ord->table2_size); ord->table2_size &= 0x0000FFFF; - - IPW_DEBUG_INFO("table 1 size: %d\n", ord->table1_size); - IPW_DEBUG_INFO("table 2 size: %d\n", ord->table2_size); - IPW_DEBUG_INFO("exit\n"); } static inline void ipw2100_hw_set_gpio(struct ipw2100_priv *priv) @@ -1117,7 +1073,6 @@ { #define MAX_RF_KILL_CHECKS 5 #define RF_KILL_CHECK_DELAY 40 -#define RF_KILL_CHECK_THRESHOLD 3 unsigned short value = 0; u32 reg = 0; @@ -1198,8 +1153,6 @@ int i; u32 inta, inta_mask, gpio; - IPW_DEBUG_INFO("enter\n"); - if (priv->status & STATUS_RUNNING) return 0; @@ -1209,7 +1162,7 @@ * fw & dino ucode */ if (ipw2100_download_firmware(priv)) { - IPW_DEBUG_ERROR("%s: Failed to power on the adapter.\n", + printk(KERN_ERR DRV_NAME ": %s: Failed to power on the adapter.\n", priv->net_dev->name); return -EIO; } @@ -1269,7 +1222,7 @@ i ? "SUCCESS" : "FAILED"); if (!i) { - IPW_DEBUG_WARNING("%s: Firmware did not initialize.\n", + printk(KERN_WARNING DRV_NAME ": %s: Firmware did not initialize.\n", priv->net_dev->name); return -EIO; } @@ -1286,9 +1239,6 @@ /* The adapter has been reset; we are not associated */ priv->status &= ~(STATUS_ASSOCIATING | STATUS_ASSOCIATED); - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -1465,7 +1415,7 @@ err = ipw2100_hw_phy_off(priv); if (err) - IPW_DEBUG_WARNING("Error disabling radio %d\n", err); + printk(KERN_WARNING DRV_NAME ": Error disabling radio %d\n", err); /* * If in D0-standby mode going directly to D3 may cause a @@ -1491,7 +1441,7 @@ err = ipw2100_hw_send_command(priv, &cmd); if (err) - IPW_DEBUG_WARNING( + printk(KERN_WARNING DRV_NAME ": " "%s: Power down command failed: Error %d\n", priv->net_dev->name, err); else { @@ -1532,7 +1482,7 @@ } if (i == 0) - IPW_DEBUG_WARNING(DRV_NAME + printk(KERN_WARNING DRV_NAME ": %s: Could now power down adapter.\n", priv->net_dev->name); @@ -1572,13 +1522,13 @@ err = ipw2100_hw_send_command(priv, &cmd); if (err) { - IPW_DEBUG_WARNING("exit - failed to send CARD_DISABLE command\n"); + printk(KERN_WARNING DRV_NAME ": exit - failed to send CARD_DISABLE command\n"); goto fail_up; } err = ipw2100_wait_for_card_state(priv, IPW_HW_STATE_DISABLED); if (err) { - IPW_DEBUG_WARNING("exit - card failed to change to DISABLED\n"); + printk(KERN_WARNING DRV_NAME ": exit - card failed to change to DISABLED\n"); goto fail_up; } @@ -1598,8 +1548,6 @@ }; int err; - IPW_DEBUG_INFO("enter\n"); - IPW_DEBUG_SCAN("setting scan options\n"); cmd.host_command_parameters[0] = 0; @@ -1643,8 +1591,6 @@ return 0; } - IPW_DEBUG_INFO("enter\n"); - /* Not clearing here; doing so makes iwlist always return nothing... * * We should modify the table logic to use aging tables vs. clearing @@ -1657,8 +1603,6 @@ if (err) priv->status &= ~STATUS_SCANNING; - IPW_DEBUG_INFO("exit\n"); - return err; } @@ -1688,7 +1632,7 @@ (priv->status & STATUS_RESET_PENDING)) { /* Power cycle the card ... */ if (ipw2100_power_cycle_adapter(priv)) { - IPW_DEBUG_WARNING("%s: Could not cycle adapter.\n", + printk(KERN_WARNING DRV_NAME ": %s: Could not cycle adapter.\n", priv->net_dev->name); rc = 1; goto exit; @@ -1698,7 +1642,7 @@ /* Load the firmeware, start the clocks, etc. */ if (ipw2100_start_adapter(priv)) { - IPW_DEBUG_ERROR("%s: Failed to start the firmware.\n", + printk(KERN_ERR DRV_NAME ": %s: Failed to start the firmware.\n", priv->net_dev->name); rc = 1; goto exit; @@ -1708,7 +1652,7 @@ /* Determine capabilities of this particular HW configuration */ if (ipw2100_get_hw_features(priv)) { - IPW_DEBUG_ERROR("%s: Failed to determine HW features.\n", + printk(KERN_ERR DRV_NAME ": %s: Failed to determine HW features.\n", priv->net_dev->name); rc = 1; goto exit; @@ -1716,7 +1660,7 @@ lock = LOCK_NONE; if (ipw2100_set_ordinal(priv, IPW_ORD_PERS_DB_LOCK, &lock, &ord_len)) { - IPW_DEBUG_ERROR("%s: Failed to clear ordinal lock.\n", + printk(KERN_ERR DRV_NAME ": %s: Failed to clear ordinal lock.\n", priv->net_dev->name); rc = 1; goto exit; @@ -1742,7 +1686,7 @@ /* Send all of the commands that must be sent prior to * HOST_COMPLETE */ if (ipw2100_adapter_setup(priv)) { - IPW_DEBUG_ERROR("%s: Failed to start the card.\n", + printk(KERN_ERR DRV_NAME ": %s: Failed to start the card.\n", priv->net_dev->name); rc = 1; goto exit; @@ -1751,7 +1695,7 @@ if (!deferred) { /* Enable the adapter - sends HOST_COMPLETE */ if (ipw2100_enable_adapter(priv)) { - IPW_DEBUG_ERROR( + printk(KERN_ERR DRV_NAME ": " "%s: failed in call to enable adapter.\n", priv->net_dev->name); ipw2100_hw_stop_adapter(priv); @@ -1809,7 +1753,7 @@ spin_unlock_irqrestore(&priv->low_lock, flags); if (ipw2100_hw_stop_adapter(priv)) - IPW_DEBUG_ERROR("%s: Error stopping adapter.\n", + printk(KERN_ERR DRV_NAME ": %s: Error stopping adapter.\n", priv->net_dev->name); /* Do not disable the interrupt until _after_ we disable @@ -2285,18 +2229,10 @@ * The size of the constructed ethernet * */ -#ifdef CONFIG_IPW2100_RX_DEBUG -u8 packet_data[IPW_RX_NIC_BUFFER_LENGTH]; -#endif static inline void ipw2100_corruption_detected(struct ipw2100_priv *priv, int i) { -#ifdef CONFIG_IPW_DEBUG_C3 - struct ipw2100_status *status = &priv->status_queue.drv[i]; - u32 match, reg; - int j; -#endif #ifdef ACPI_CSTATE_LIMIT_DEFINED int limit; #endif @@ -2314,35 +2250,6 @@ } #endif -#ifdef CONFIG_IPW_DEBUG_C3 - /* Halt the fimrware so we can get a good image */ - write_register(priv->net_dev, IPW_REG_RESET_REG, - IPW_AUX_HOST_RESET_REG_STOP_MASTER); - j = 5; - do { - udelay(IPW_WAIT_RESET_MASTER_ASSERT_COMPLETE_DELAY); - read_register(priv->net_dev, IPW_REG_RESET_REG, ®); - - if (reg & IPW_AUX_HOST_RESET_REG_MASTER_DISABLED) - break; - } while (j--); - - match = ipw2100_match_buf(priv, (u8*)status, - sizeof(struct ipw2100_status), - SEARCH_SNAPSHOT); - if (match < SEARCH_SUCCESS) - IPW_DEBUG_INFO("%s: DMA status match in Firmware at " - "offset 0x%06X, length %d:\n", - priv->net_dev->name, match, - sizeof(struct ipw2100_status)); - else - IPW_DEBUG_INFO("%s: No DMA status match in " - "Firmware.\n", priv->net_dev->name); - - printk_buf((u8*)priv->status_queue.drv, - sizeof(struct ipw2100_status) * RX_QUEUE_LENGTH); -#endif - priv->fatal_error = IPW2100_ERR_C3_CORRUPTION; priv->ieee->stats.rx_errors++; schedule_reset(priv); @@ -2394,19 +2301,7 @@ skb_put(packet->skb, status->frame_size); -#ifdef CONFIG_IPW2100_RX_DEBUG - /* Make a copy of the frame so we can dump it to the logs if - * ieee80211_rx fails */ - memcpy(packet_data, packet->skb->data, - min(status->frame_size, IPW_RX_NIC_BUFFER_LENGTH)); -#endif - if (!ieee80211_rx(priv->ieee, packet->skb, stats)) { -#ifdef CONFIG_IPW2100_RX_DEBUG - IPW_DEBUG_DROP("%s: Non consumed packet:\n", - priv->net_dev->name); - printk_buf(IPW_DL_DROP, packet_data, status->frame_size); -#endif priv->ieee->stats.rx_errors++; /* ieee80211_rx failed, so it didn't free the SKB */ @@ -2416,7 +2311,7 @@ /* We need to allocate a new SKB and attach it to the RDB. */ if (unlikely(ipw2100_alloc_skb(priv, packet))) { - IPW_DEBUG_WARNING( + printk(KERN_WARNING DRV_NAME ": " "%s: Unable to allocate SKB onto RBD ring - disabling " "adapter.\n", priv->net_dev->name); /* TODO: schedule adapter shutdown */ @@ -2678,7 +2573,7 @@ break; default: - IPW_DEBUG_WARNING("%s: Bad fw_pend_list entry!\n", + printk(KERN_WARNING DRV_NAME ": %s: Bad fw_pend_list entry!\n", priv->net_dev->name); return 0; } @@ -2692,7 +2587,7 @@ read_register(priv->net_dev, IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX, &w); if (w != txq->next) - IPW_DEBUG_WARNING("%s: write index mismatch\n", + printk(KERN_WARNING DRV_NAME ": %s: write index mismatch\n", priv->net_dev->name); /* @@ -2753,7 +2648,7 @@ switch (packet->type) { case DATA: if (txq->drv[txq->oldest].status.info.fields.txType != 0) - IPW_DEBUG_WARNING("%s: Queue mismatch. " + printk(KERN_WARNING DRV_NAME ": %s: Queue mismatch. " "Expecting DATA TBD but pulled " "something else: ids %d=%d.\n", priv->net_dev->name, txq->oldest, packet->index); @@ -2800,7 +2695,7 @@ case COMMAND: if (txq->drv[txq->oldest].status.info.fields.txType != 1) - IPW_DEBUG_WARNING("%s: Queue mismatch. " + printk(KERN_WARNING DRV_NAME ": %s: Queue mismatch. " "Expecting COMMAND TBD but pulled " "something else: ids %d=%d.\n", priv->net_dev->name, txq->oldest, packet->index); @@ -2840,14 +2735,14 @@ while (__ipw2100_tx_process(priv) && i < 200) i++; if (i == 200) { - IPW_DEBUG_WARNING( + printk(KERN_WARNING DRV_NAME ": " "%s: Driver is running slow (%d iters).\n", priv->net_dev->name, i); } } -static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv) +static void ipw2100_tx_send_commands(struct ipw2100_priv *priv) { struct list_head *element; struct ipw2100_tx_packet *packet; @@ -2915,10 +2810,10 @@ /* - * X__ipw2100_tx_send_data + * ipw2100_tx_send_data * */ -static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv) +static void ipw2100_tx_send_data(struct ipw2100_priv *priv) { struct list_head *element; struct ipw2100_tx_packet *packet; @@ -3084,7 +2979,7 @@ (unsigned long)inta & IPW_INTERRUPT_MASK); if (inta & IPW2100_INTA_FATAL_ERROR) { - IPW_DEBUG_WARNING(DRV_NAME + printk(KERN_WARNING DRV_NAME ": Fatal interrupt. Scheduling firmware restart.\n"); priv->inta_other++; write_register( @@ -3104,7 +2999,7 @@ } if (inta & IPW2100_INTA_PARITY_ERROR) { - IPW_DEBUG_ERROR("***** PARITY ERROR INTERRUPT !!!! \n"); + printk(KERN_ERR DRV_NAME ": ***** PARITY ERROR INTERRUPT !!!! \n"); priv->inta_other++; write_register( dev, IPW_REG_INTA, @@ -3133,8 +3028,8 @@ IPW2100_INTA_TX_TRANSFER); __ipw2100_tx_complete(priv); - X__ipw2100_tx_send_commands(priv); - X__ipw2100_tx_send_data(priv); + ipw2100_tx_send_commands(priv); + ipw2100_tx_send_data(priv); } if (inta & IPW2100_INTA_TX_COMPLETE) { @@ -3192,8 +3087,6 @@ ipw2100_enable_interrupts(priv); spin_unlock_irqrestore(&priv->low_lock, flags); - - IPW_DEBUG_ISR("exit\n"); } @@ -3222,7 +3115,7 @@ if (inta == 0xFFFFFFFF) { /* Hardware disappeared */ - IPW_DEBUG_WARNING("IRQ INTA == 0xFFFFFFFF\n"); + printk(KERN_WARNING DRV_NAME ": IRQ INTA == 0xFFFFFFFF\n"); goto none; } @@ -3285,7 +3178,7 @@ list_add_tail(element, &priv->tx_pend_list); INC_STAT(&priv->tx_pend_stat); - X__ipw2100_tx_send_data(priv); + ipw2100_tx_send_data(priv); spin_unlock_irqrestore(&priv->low_lock, flags); return 0; @@ -3307,7 +3200,7 @@ IPW_COMMAND_POOL_SIZE * sizeof(struct ipw2100_tx_packet), GFP_KERNEL); if (!priv->msg_buffers) { - IPW_DEBUG_ERROR("%s: PCI alloc failed for msg " + printk(KERN_ERR DRV_NAME ": %s: PCI alloc failed for msg " "buffers.\n", priv->net_dev->name); return -ENOMEM; } @@ -3318,7 +3211,7 @@ sizeof(struct ipw2100_cmd_header), &p); if (!v) { - IPW_DEBUG_ERROR( + printk(KERN_ERR DRV_NAME ": " "%s: PCI alloc failed for msg " "buffers.\n", priv->net_dev->name); @@ -3383,429 +3276,6 @@ priv->msg_buffers = NULL; } -static ssize_t show_pci(struct device *d, char *buf) -{ - struct pci_dev *pci_dev = container_of(d, struct pci_dev, dev); - char *out = buf; - int i, j; - u32 val; - - for (i = 0; i < 16; i++) { - out += sprintf(out, "[%08X] ", i * 16); - for (j = 0; j < 16; j += 4) { - pci_read_config_dword(pci_dev, i * 16 + j, &val); - out += sprintf(out, "%08X ", val); - } - out += sprintf(out, "\n"); - } - - return out - buf; -} -static DEVICE_ATTR(pci, S_IRUGO, show_pci, NULL); - -static ssize_t show_cfg(struct device *d, char *buf) -{ - struct ipw2100_priv *p = (struct ipw2100_priv *)d->driver_data; - return sprintf(buf, "0x%08x\n", (int)p->config); -} -static DEVICE_ATTR(cfg, S_IRUGO, show_cfg, NULL); - -static ssize_t show_status(struct device *d, char *buf) -{ - struct ipw2100_priv *p = (struct ipw2100_priv *)d->driver_data; - return sprintf(buf, "0x%08x\n", (int)p->status); -} -static DEVICE_ATTR(status, S_IRUGO, show_status, NULL); - -static ssize_t show_capability(struct device *d, char *buf) -{ - struct ipw2100_priv *p = (struct ipw2100_priv *)d->driver_data; - return sprintf(buf, "0x%08x\n", (int)p->capability); -} -static DEVICE_ATTR(capability, S_IRUGO, show_capability, NULL); - - -#define IPW2100_REG(x) { IPW_ ##x, #x } -const struct { - u32 addr; - const char *name; -} hw_data[] = { - IPW2100_REG(REG_GP_CNTRL), - IPW2100_REG(REG_GPIO), - IPW2100_REG(REG_INTA), - IPW2100_REG(REG_INTA_MASK), - IPW2100_REG(REG_RESET_REG), -}; -#define IPW2100_NIC(x, s) { x, #x, s } -const struct { - u32 addr; - const char *name; - size_t size; -} nic_data[] = { - IPW2100_NIC(IPW2100_CONTROL_REG, 2), - IPW2100_NIC(0x210014, 1), - IPW2100_NIC(0x210000, 1), -}; -#define IPW2100_ORD(x, d) { IPW_ORD_ ##x, #x, d } -const struct { - u8 index; - const char *name; - const char *desc; -} ord_data[] = { - IPW2100_ORD(STAT_TX_HOST_REQUESTS, "requested Host Tx's (MSDU)"), - IPW2100_ORD(STAT_TX_HOST_COMPLETE, "successful Host Tx's (MSDU)"), - IPW2100_ORD(STAT_TX_DIR_DATA, "successful Directed Tx's (MSDU)"), - IPW2100_ORD(STAT_TX_DIR_DATA1, "successful Directed Tx's (MSDU) @ 1MB"), - IPW2100_ORD(STAT_TX_DIR_DATA2, "successful Directed Tx's (MSDU) @ 2MB"), - IPW2100_ORD(STAT_TX_DIR_DATA5_5, "successful Directed Tx's (MSDU) @ 5_5MB"), - IPW2100_ORD(STAT_TX_DIR_DATA11, "successful Directed Tx's (MSDU) @ 11MB"), - IPW2100_ORD(STAT_TX_NODIR_DATA1, "successful Non_Directed Tx's (MSDU) @ 1MB"), - IPW2100_ORD(STAT_TX_NODIR_DATA2, "successful Non_Directed Tx's (MSDU) @ 2MB"), - IPW2100_ORD(STAT_TX_NODIR_DATA5_5, "successful Non_Directed Tx's (MSDU) @ 5.5MB"), - IPW2100_ORD(STAT_TX_NODIR_DATA11, "successful Non_Directed Tx's (MSDU) @ 11MB"), - IPW2100_ORD(STAT_NULL_DATA, "successful NULL data Tx's"), - IPW2100_ORD(STAT_TX_RTS, "successful Tx RTS"), - IPW2100_ORD(STAT_TX_CTS, "successful Tx CTS"), - IPW2100_ORD(STAT_TX_ACK, "successful Tx ACK"), - IPW2100_ORD(STAT_TX_ASSN, "successful Association Tx's"), - IPW2100_ORD(STAT_TX_ASSN_RESP, "successful Association response Tx's"), - IPW2100_ORD(STAT_TX_REASSN, "successful Reassociation Tx's"), - IPW2100_ORD(STAT_TX_REASSN_RESP, "successful Reassociation response Tx's"), - IPW2100_ORD(STAT_TX_PROBE, "probes successfully transmitted"), - IPW2100_ORD(STAT_TX_PROBE_RESP, "probe responses successfully transmitted"), - IPW2100_ORD(STAT_TX_BEACON, "tx beacon"), - IPW2100_ORD(STAT_TX_ATIM, "Tx ATIM"), - IPW2100_ORD(STAT_TX_DISASSN, "successful Disassociation TX"), - IPW2100_ORD(STAT_TX_AUTH, "successful Authentication Tx"), - IPW2100_ORD(STAT_TX_DEAUTH, "successful Deauthentication TX"), - IPW2100_ORD(STAT_TX_TOTAL_BYTES, "Total successful Tx data bytes"), - IPW2100_ORD(STAT_TX_RETRIES, "Tx retries"), - IPW2100_ORD(STAT_TX_RETRY1, "Tx retries at 1MBPS"), - IPW2100_ORD(STAT_TX_RETRY2, "Tx retries at 2MBPS"), - IPW2100_ORD(STAT_TX_RETRY5_5, "Tx retries at 5.5MBPS"), - IPW2100_ORD(STAT_TX_RETRY11, "Tx retries at 11MBPS"), - IPW2100_ORD(STAT_TX_FAILURES, "Tx Failures"), - IPW2100_ORD(STAT_TX_MAX_TRIES_IN_HOP,"times max tries in a hop failed"), - IPW2100_ORD(STAT_TX_DISASSN_FAIL, "times disassociation failed"), - IPW2100_ORD(STAT_TX_ERR_CTS, "missed/bad CTS frames"), - IPW2100_ORD(STAT_TX_ERR_ACK, "tx err due to acks"), - IPW2100_ORD(STAT_RX_HOST, "packets passed to host"), - IPW2100_ORD(STAT_RX_DIR_DATA, "directed packets"), - IPW2100_ORD(STAT_RX_DIR_DATA1, "directed packets at 1MB"), - IPW2100_ORD(STAT_RX_DIR_DATA2, "directed packets at 2MB"), - IPW2100_ORD(STAT_RX_DIR_DATA5_5, "directed packets at 5.5MB"), - IPW2100_ORD(STAT_RX_DIR_DATA11, "directed packets at 11MB"), - IPW2100_ORD(STAT_RX_NODIR_DATA,"nondirected packets"), - IPW2100_ORD(STAT_RX_NODIR_DATA1, "nondirected packets at 1MB"), - IPW2100_ORD(STAT_RX_NODIR_DATA2, "nondirected packets at 2MB"), - IPW2100_ORD(STAT_RX_NODIR_DATA5_5, "nondirected packets at 5.5MB"), - IPW2100_ORD(STAT_RX_NODIR_DATA11, "nondirected packets at 11MB"), - IPW2100_ORD(STAT_RX_NULL_DATA, "null data rx's"), - IPW2100_ORD(STAT_RX_RTS, "Rx RTS"), - IPW2100_ORD(STAT_RX_CTS, "Rx CTS"), - IPW2100_ORD(STAT_RX_ACK, "Rx ACK"), - IPW2100_ORD(STAT_RX_CFEND, "Rx CF End"), - IPW2100_ORD(STAT_RX_CFEND_ACK, "Rx CF End + CF Ack"), - IPW2100_ORD(STAT_RX_ASSN, "Association Rx's"), - IPW2100_ORD(STAT_RX_ASSN_RESP, "Association response Rx's"), - IPW2100_ORD(STAT_RX_REASSN, "Reassociation Rx's"), - IPW2100_ORD(STAT_RX_REASSN_RESP, "Reassociation response Rx's"), - IPW2100_ORD(STAT_RX_PROBE, "probe Rx's"), - IPW2100_ORD(STAT_RX_PROBE_RESP, "probe response Rx's"), - IPW2100_ORD(STAT_RX_BEACON, "Rx beacon"), - IPW2100_ORD(STAT_RX_ATIM, "Rx ATIM"), - IPW2100_ORD(STAT_RX_DISASSN, "disassociation Rx"), - IPW2100_ORD(STAT_RX_AUTH, "authentication Rx"), - IPW2100_ORD(STAT_RX_DEAUTH, "deauthentication Rx"), - IPW2100_ORD(STAT_RX_TOTAL_BYTES,"Total rx data bytes received"), - IPW2100_ORD(STAT_RX_ERR_CRC, "packets with Rx CRC error"), - IPW2100_ORD(STAT_RX_ERR_CRC1, "Rx CRC errors at 1MB"), - IPW2100_ORD(STAT_RX_ERR_CRC2, "Rx CRC errors at 2MB"), - IPW2100_ORD(STAT_RX_ERR_CRC5_5, "Rx CRC errors at 5.5MB"), - IPW2100_ORD(STAT_RX_ERR_CRC11, "Rx CRC errors at 11MB"), - IPW2100_ORD(STAT_RX_DUPLICATE1, "duplicate rx packets at 1MB"), - IPW2100_ORD(STAT_RX_DUPLICATE2, "duplicate rx packets at 2MB"), - IPW2100_ORD(STAT_RX_DUPLICATE5_5, "duplicate rx packets at 5.5MB"), - IPW2100_ORD(STAT_RX_DUPLICATE11, "duplicate rx packets at 11MB"), - IPW2100_ORD(STAT_RX_DUPLICATE, "duplicate rx packets"), - IPW2100_ORD(PERS_DB_LOCK, "locking fw permanent db"), - IPW2100_ORD(PERS_DB_SIZE, "size of fw permanent db"), - IPW2100_ORD(PERS_DB_ADDR, "address of fw permanent db"), - IPW2100_ORD(STAT_RX_INVALID_PROTOCOL, "rx frames with invalid protocol"), - IPW2100_ORD(SYS_BOOT_TIME, "Boot time"), - IPW2100_ORD(STAT_RX_NO_BUFFER, "rx frames rejected due to no buffer"), - IPW2100_ORD(STAT_RX_MISSING_FRAG, "rx frames dropped due to missing fragment"), - IPW2100_ORD(STAT_RX_ORPHAN_FRAG, "rx frames dropped due to non-sequential fragment"), - IPW2100_ORD(STAT_RX_ORPHAN_FRAME, "rx frames dropped due to unmatched 1st frame"), - IPW2100_ORD(STAT_RX_FRAG_AGEOUT, "rx frames dropped due to uncompleted frame"), - IPW2100_ORD(STAT_RX_ICV_ERRORS, "ICV errors during decryption"), - IPW2100_ORD(STAT_PSP_SUSPENSION,"times adapter suspended"), - IPW2100_ORD(STAT_PSP_BCN_TIMEOUT, "beacon timeout"), - IPW2100_ORD(STAT_PSP_POLL_TIMEOUT, "poll response timeouts"), - IPW2100_ORD(STAT_PSP_NONDIR_TIMEOUT, "timeouts waiting for last {broad,multi}cast pkt"), - IPW2100_ORD(STAT_PSP_RX_DTIMS, "PSP DTIMs received"), - IPW2100_ORD(STAT_PSP_RX_TIMS, "PSP TIMs received"), - IPW2100_ORD(STAT_PSP_STATION_ID,"PSP Station ID"), - IPW2100_ORD(LAST_ASSN_TIME, "RTC time of last association"), - IPW2100_ORD(STAT_PERCENT_MISSED_BCNS,"current calculation of % missed beacons"), - IPW2100_ORD(STAT_PERCENT_RETRIES,"current calculation of % missed tx retries"), - IPW2100_ORD(ASSOCIATED_AP_PTR, "0 if not associated, else pointer to AP table entry"), - IPW2100_ORD(AVAILABLE_AP_CNT, "AP's decsribed in the AP table"), - IPW2100_ORD(AP_LIST_PTR, "Ptr to list of available APs"), - IPW2100_ORD(STAT_AP_ASSNS, "associations"), - IPW2100_ORD(STAT_ASSN_FAIL, "association failures"), - IPW2100_ORD(STAT_ASSN_RESP_FAIL,"failures due to response fail"), - IPW2100_ORD(STAT_FULL_SCANS, "full scans"), - IPW2100_ORD(CARD_DISABLED, "Card Disabled"), - IPW2100_ORD(STAT_ROAM_INHIBIT, "times roaming was inhibited due to activity"), - IPW2100_ORD(RSSI_AT_ASSN, "RSSI of associated AP at time of association"), - IPW2100_ORD(STAT_ASSN_CAUSE1, "reassociation: no probe response or TX on hop"), - IPW2100_ORD(STAT_ASSN_CAUSE2, "reassociation: poor tx/rx quality"), - IPW2100_ORD(STAT_ASSN_CAUSE3, "reassociation: tx/rx quality (excessive AP load"), - IPW2100_ORD(STAT_ASSN_CAUSE4, "reassociation: AP RSSI level"), - IPW2100_ORD(STAT_ASSN_CAUSE5, "reassociations due to load leveling"), - IPW2100_ORD(STAT_AUTH_FAIL, "times authentication failed"), - IPW2100_ORD(STAT_AUTH_RESP_FAIL,"times authentication response failed"), - IPW2100_ORD(STATION_TABLE_CNT, "entries in association table"), - IPW2100_ORD(RSSI_AVG_CURR, "Current avg RSSI"), - IPW2100_ORD(POWER_MGMT_MODE, "Power mode - 0=CAM, 1=PSP"), - IPW2100_ORD(COUNTRY_CODE, "IEEE country code as recv'd from beacon"), - IPW2100_ORD(COUNTRY_CHANNELS, "channels suported by country"), - IPW2100_ORD(RESET_CNT, "adapter resets (warm)"), - IPW2100_ORD(BEACON_INTERVAL, "Beacon interval"), - IPW2100_ORD(ANTENNA_DIVERSITY, "TRUE if antenna diversity is disabled"), - IPW2100_ORD(DTIM_PERIOD, "beacon intervals between DTIMs"), - IPW2100_ORD(OUR_FREQ, "current radio freq lower digits - channel ID"), - IPW2100_ORD(RTC_TIME, "current RTC time"), - IPW2100_ORD(PORT_TYPE, "operating mode"), - IPW2100_ORD(CURRENT_TX_RATE, "current tx rate"), - IPW2100_ORD(SUPPORTED_RATES, "supported tx rates"), - IPW2100_ORD(ATIM_WINDOW, "current ATIM Window"), - IPW2100_ORD(BASIC_RATES, "basic tx rates"), - IPW2100_ORD(NIC_HIGHEST_RATE, "NIC highest tx rate"), - IPW2100_ORD(AP_HIGHEST_RATE, "AP highest tx rate"), - IPW2100_ORD(CAPABILITIES, "Management frame capability field"), - IPW2100_ORD(AUTH_TYPE, "Type of authentication"), - IPW2100_ORD(RADIO_TYPE, "Adapter card platform type"), - IPW2100_ORD(RTS_THRESHOLD, "Min packet length for RTS handshaking"), - IPW2100_ORD(INT_MODE, "International mode"), - IPW2100_ORD(FRAGMENTATION_THRESHOLD, "protocol frag threshold"), - IPW2100_ORD(EEPROM_SRAM_DB_BLOCK_START_ADDRESS, "EEPROM offset in SRAM"), - IPW2100_ORD(EEPROM_SRAM_DB_BLOCK_SIZE, "EEPROM size in SRAM"), - IPW2100_ORD(EEPROM_SKU_CAPABILITY, "EEPROM SKU Capability"), - IPW2100_ORD(EEPROM_IBSS_11B_CHANNELS, "EEPROM IBSS 11b channel set"), - IPW2100_ORD(MAC_VERSION, "MAC Version"), - IPW2100_ORD(MAC_REVISION, "MAC Revision"), - IPW2100_ORD(RADIO_VERSION, "Radio Version"), - IPW2100_ORD(NIC_MANF_DATE_TIME, "MANF Date/Time STAMP"), - IPW2100_ORD(UCODE_VERSION, "Ucode Version"), -}; - - -static ssize_t show_registers(struct device *d, char *buf) -{ - int i; - struct ipw2100_priv *priv = dev_get_drvdata(d); - struct net_device *dev = priv->net_dev; - char * out = buf; - u32 val = 0; - - out += sprintf(out, "%30s [Address ] : Hex\n", "Register"); - - for (i = 0; i < (sizeof(hw_data) / sizeof(*hw_data)); i++) { - read_register(dev, hw_data[i].addr, &val); - out += sprintf(out, "%30s [%08X] : %08X\n", - hw_data[i].name, hw_data[i].addr, val); - } - - return out - buf; -} -static DEVICE_ATTR(registers, S_IRUGO, show_registers, NULL); - - -static ssize_t show_hardware(struct device *d, char *buf) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - struct net_device *dev = priv->net_dev; - char * out = buf; - int i; - - out += sprintf(out, "%30s [Address ] : Hex\n", "NIC entry"); - - for (i = 0; i < (sizeof(nic_data) / sizeof(*nic_data)); i++) { - u8 tmp8; - u16 tmp16; - u32 tmp32; - - switch (nic_data[i].size) { - case 1: - read_nic_byte(dev, nic_data[i].addr, &tmp8); - out += sprintf(out, "%30s [%08X] : %02X\n", - nic_data[i].name, nic_data[i].addr, - tmp8); - break; - case 2: - read_nic_word(dev, nic_data[i].addr, &tmp16); - out += sprintf(out, "%30s [%08X] : %04X\n", - nic_data[i].name, nic_data[i].addr, - tmp16); - break; - case 4: - read_nic_dword(dev, nic_data[i].addr, &tmp32); - out += sprintf(out, "%30s [%08X] : %08X\n", - nic_data[i].name, nic_data[i].addr, - tmp32); - break; - } - } - return out - buf; -} -static DEVICE_ATTR(hardware, S_IRUGO, show_hardware, NULL); - - -static ssize_t show_memory(struct device *d, char *buf) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - struct net_device *dev = priv->net_dev; - static unsigned long loop = 0; - int len = 0; - u32 buffer[4]; - int i; - char line[81]; - - if (loop >= 0x30000) - loop = 0; - - /* sysfs provides us PAGE_SIZE buffer */ - while (len < PAGE_SIZE - 128 && loop < 0x30000) { - - if (priv->snapshot[0]) for (i = 0; i < 4; i++) - buffer[i] = *(u32 *)SNAPSHOT_ADDR(loop + i * 4); - else for (i = 0; i < 4; i++) - read_nic_dword(dev, loop + i * 4, &buffer[i]); - - if (priv->dump_raw) - len += sprintf(buf + len, - "%c%c%c%c" - "%c%c%c%c" - "%c%c%c%c" - "%c%c%c%c", - ((u8*)buffer)[0x0], - ((u8*)buffer)[0x1], - ((u8*)buffer)[0x2], - ((u8*)buffer)[0x3], - ((u8*)buffer)[0x4], - ((u8*)buffer)[0x5], - ((u8*)buffer)[0x6], - ((u8*)buffer)[0x7], - ((u8*)buffer)[0x8], - ((u8*)buffer)[0x9], - ((u8*)buffer)[0xa], - ((u8*)buffer)[0xb], - ((u8*)buffer)[0xc], - ((u8*)buffer)[0xd], - ((u8*)buffer)[0xe], - ((u8*)buffer)[0xf]); - else - len += sprintf(buf + len, "%s\n", - snprint_line(line, sizeof(line), - (u8*)buffer, 16, loop)); - loop += 16; - } - - return len; -} - -static ssize_t store_memory(struct device *d, const char *buf, size_t count) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - struct net_device *dev = priv->net_dev; - const char *p = buf; - - if (count < 1) - return count; - - if (p[0] == '1' || - (count >= 2 && tolower(p[0]) == 'o' && tolower(p[1]) == 'n')) { - IPW_DEBUG_INFO("%s: Setting memory dump to RAW mode.\n", - dev->name); - priv->dump_raw = 1; - - } else if (p[0] == '0' || (count >= 2 && tolower(p[0]) == 'o' && - tolower(p[1]) == 'f')) { - IPW_DEBUG_INFO("%s: Setting memory dump to HEX mode.\n", - dev->name); - priv->dump_raw = 0; - - } else if (tolower(p[0]) == 'r') { - IPW_DEBUG_INFO("%s: Resetting firmware snapshot.\n", - dev->name); - ipw2100_snapshot_free(priv); - - } else - IPW_DEBUG_INFO("%s: Usage: 0|on = HEX, 1|off = RAW, " - "reset = clear memory snapshot\n", - dev->name); - - return count; -} -static DEVICE_ATTR(memory, S_IWUSR|S_IRUGO, show_memory, store_memory); - - -static ssize_t show_ordinals(struct device *d, char *buf) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - u32 val = 0; - int len = 0; - u32 val_len; - static int loop = 0; - - if (loop >= sizeof(ord_data) / sizeof(*ord_data)) - loop = 0; - - /* sysfs provides us PAGE_SIZE buffer */ - while (len < PAGE_SIZE - 128 && - loop < (sizeof(ord_data) / sizeof(*ord_data))) { - - val_len = sizeof(u32); - - if (ipw2100_get_ordinal(priv, ord_data[loop].index, &val, - &val_len)) - len += sprintf(buf + len, "[0x%02X] = ERROR %s\n", - ord_data[loop].index, - ord_data[loop].desc); - else - len += sprintf(buf + len, "[0x%02X] = 0x%08X %s\n", - ord_data[loop].index, val, - ord_data[loop].desc); - loop++; - } - - return len; -} -static DEVICE_ATTR(ordinals, S_IRUGO, show_ordinals, NULL); - - -static ssize_t show_stats(struct device *d, char *buf) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - char * out = buf; - - out += sprintf(out, "interrupts: %d {tx: %d, rx: %d, other: %d}\n", - priv->interrupts, priv->tx_interrupts, - priv->rx_interrupts, priv->inta_other); - out += sprintf(out, "firmware resets: %d\n", priv->resets); - out += sprintf(out, "firmware hangs: %d\n", priv->hangs); -#ifdef CONFIG_IPW_DEBUG - out += sprintf(out, "packet mismatch image: %s\n", - priv->snapshot[0] ? "YES" : "NO"); -#endif - - return out - buf; -} -static DEVICE_ATTR(stats, S_IRUGO, show_stats, NULL); - - int ipw2100_switch_mode(struct ipw2100_priv *priv, u32 mode) { int err; @@ -3815,7 +3285,7 @@ err = ipw2100_disable_adapter(priv); if (err) { - IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n", + printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n", priv->net_dev->name, err); return err; } @@ -3837,11 +3307,9 @@ priv->ieee->iw_mode = mode; -#ifdef CONFIG_PM /* Indicate ipw2100_download_firmware download firmware * from disk instead of memory. */ ipw2100_firmware.version = 0; -#endif printk(KERN_INFO "%s: Reseting on mode change.\n", priv->net_dev->name); @@ -3851,100 +3319,6 @@ return 0; } -static ssize_t show_internals(struct device *d, char *buf) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - int len = 0; - -#define DUMP_VAR(x,y) len += sprintf(buf + len, # x ": %" # y "\n", priv-> x) - - if (priv->status & STATUS_ASSOCIATED) - len += sprintf(buf + len, "connected: %lu\n", - get_seconds() - priv->connect_start); - else - len += sprintf(buf + len, "not connected\n"); - - DUMP_VAR(ieee->crypt[priv->ieee->tx_keyidx], p); - DUMP_VAR(status, 08lx); - DUMP_VAR(config, 08lx); - DUMP_VAR(capability, 08lx); - - len += sprintf(buf + len, "last_rtc: %lu\n", (unsigned long)priv->last_rtc); - - DUMP_VAR(fatal_error, d); - DUMP_VAR(stop_hang_check, d); - DUMP_VAR(stop_rf_kill, d); - DUMP_VAR(messages_sent, d); - - DUMP_VAR(tx_pend_stat.value, d); - DUMP_VAR(tx_pend_stat.hi, d); - - DUMP_VAR(tx_free_stat.value, d); - DUMP_VAR(tx_free_stat.lo, d); - - DUMP_VAR(msg_free_stat.value, d); - DUMP_VAR(msg_free_stat.lo, d); - - DUMP_VAR(msg_pend_stat.value, d); - DUMP_VAR(msg_pend_stat.hi, d); - - DUMP_VAR(fw_pend_stat.value, d); - DUMP_VAR(fw_pend_stat.hi, d); - - DUMP_VAR(txq_stat.value, d); - DUMP_VAR(txq_stat.lo, d); - - DUMP_VAR(ieee->scans, d); - DUMP_VAR(reset_backoff, d); - - return len; -} -static DEVICE_ATTR(internals, S_IRUGO, show_internals, NULL); - - -static ssize_t show_bssinfo(struct device *d, char *buf) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - char essid[IW_ESSID_MAX_SIZE + 1]; - u8 bssid[ETH_ALEN]; - u32 chan = 0; - char * out = buf; - int length; - int ret; - - memset(essid, 0, sizeof(essid)); - memset(bssid, 0, sizeof(bssid)); - - length = IW_ESSID_MAX_SIZE; - ret = ipw2100_get_ordinal(priv, IPW_ORD_STAT_ASSN_SSID, essid, &length); - if (ret) - IPW_DEBUG_INFO("failed querying ordinals at line %d\n", - __LINE__); - - length = sizeof(bssid); - ret = ipw2100_get_ordinal(priv, IPW_ORD_STAT_ASSN_AP_BSSID, - bssid, &length); - if (ret) - IPW_DEBUG_INFO("failed querying ordinals at line %d\n", - __LINE__); - - length = sizeof(u32); - ret = ipw2100_get_ordinal(priv, IPW_ORD_OUR_FREQ, &chan, &length); - if (ret) - IPW_DEBUG_INFO("failed querying ordinals at line %d\n", - __LINE__); - - out += sprintf(out, "ESSID: %s\n", essid); - out += sprintf(out, "BSSID: %02x:%02x:%02x:%02x:%02x:%02x\n", - bssid[0], bssid[1], bssid[2], - bssid[3], bssid[4], bssid[5]); - out += sprintf(out, "Channel: %d\n", chan); - - return out - buf; -} -static DEVICE_ATTR(bssinfo, S_IRUGO, show_bssinfo, NULL); - - #ifdef CONFIG_IPW_DEBUG @@ -4013,49 +3387,6 @@ } static DEVICE_ATTR(fatal_error, S_IWUSR|S_IRUGO, show_fatal_error, store_fatal_error); - -static ssize_t show_scan_age(struct device *d, char *buf) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - return sprintf(buf, "%d\n", priv->ieee->scan_age); -} - -static ssize_t store_scan_age(struct device *d, const char *buf, size_t count) -{ - struct ipw2100_priv *priv = dev_get_drvdata(d); - struct net_device *dev = priv->net_dev; - char buffer[] = "00000000"; - unsigned long len = - (sizeof(buffer) - 1) > count ? count : sizeof(buffer) - 1; - unsigned long val; - char *p = buffer; - - IPW_DEBUG_INFO("enter\n"); - - strncpy(buffer, buf, len); - buffer[len] = 0; - - if (p[1] == 'x' || p[1] == 'X' || p[0] == 'x' || p[0] == 'X') { - p++; - if (p[0] == 'x' || p[0] == 'X') - p++; - val = simple_strtoul(p, &p, 16); - } else - val = simple_strtoul(p, &p, 10); - if (p == buffer) { - IPW_DEBUG_INFO("%s: user supplied invalid value.\n", - dev->name); - } else { - priv->ieee->scan_age = val; - IPW_DEBUG_INFO("set scan_age = %u\n", priv->ieee->scan_age); - } - - IPW_DEBUG_INFO("exit\n"); - return len; -} -static DEVICE_ATTR(scan_age, S_IWUSR | S_IRUGO, show_scan_age, store_scan_age); - - static ssize_t show_rf_kill(struct device *d, char *buf) { /* 0 - RF kill not enabled @@ -4110,20 +3441,8 @@ static struct attribute *ipw2100_sysfs_entries[] = { - &dev_attr_hardware.attr, - &dev_attr_registers.attr, - &dev_attr_ordinals.attr, - &dev_attr_pci.attr, - &dev_attr_stats.attr, - &dev_attr_internals.attr, - &dev_attr_bssinfo.attr, - &dev_attr_memory.attr, - &dev_attr_scan_age.attr, &dev_attr_fatal_error.attr, &dev_attr_rf_kill.attr, - &dev_attr_cfg.attr, - &dev_attr_status.attr, - &dev_attr_capability.attr, NULL, }; @@ -4136,43 +3455,32 @@ { struct ipw2100_status_queue *q = &priv->status_queue; - IPW_DEBUG_INFO("enter\n"); - q->size = entries * sizeof(struct ipw2100_status); q->drv = (struct ipw2100_status *)pci_alloc_consistent( priv->pci_dev, q->size, &q->nic); if (!q->drv) { - IPW_DEBUG_WARNING( + printk(KERN_WARNING DRV_NAME ": " "Can not allocate status queue.\n"); return -ENOMEM; } memset(q->drv, 0, q->size); - - IPW_DEBUG_INFO("exit\n"); - return 0; } static void status_queue_free(struct ipw2100_priv *priv) { - IPW_DEBUG_INFO("enter\n"); - if (priv->status_queue.drv) { pci_free_consistent( priv->pci_dev, priv->status_queue.size, priv->status_queue.drv, priv->status_queue.nic); priv->status_queue.drv = NULL; } - - IPW_DEBUG_INFO("exit\n"); } static int bd_queue_allocate(struct ipw2100_priv *priv, struct ipw2100_bd_queue *q, int entries) { - IPW_DEBUG_INFO("enter\n"); - memset(q, 0, sizeof(struct ipw2100_bd_queue)); q->entries = entries; @@ -4183,17 +3491,12 @@ return -ENOMEM; } memset(q->drv, 0, q->size); - - IPW_DEBUG_INFO("exit\n"); - return 0; } static void bd_queue_free(struct ipw2100_priv *priv, struct ipw2100_bd_queue *q) { - IPW_DEBUG_INFO("enter\n"); - if (!q) return; @@ -4202,24 +3505,18 @@ q->size, q->drv, q->nic); q->drv = NULL; } - - IPW_DEBUG_INFO("exit\n"); } static void bd_queue_initialize( struct ipw2100_priv *priv, struct ipw2100_bd_queue * q, u32 base, u32 size, u32 r, u32 w) { - IPW_DEBUG_INFO("enter\n"); - IPW_DEBUG_INFO("initializing bd queue at virt=%p, phys=%08x\n", q->drv, q->nic); write_register(priv->net_dev, base, q->nic); write_register(priv->net_dev, size, q->entries); write_register(priv->net_dev, r, q->oldest); write_register(priv->net_dev, w, q->next); - - IPW_DEBUG_INFO("exit\n"); } static void ipw2100_kill_workqueue(struct ipw2100_priv *priv) @@ -4243,11 +3540,9 @@ void *v; dma_addr_t p; - IPW_DEBUG_INFO("enter\n"); - err = bd_queue_allocate(priv, &priv->tx_queue, TX_QUEUE_LENGTH); if (err) { - IPW_DEBUG_ERROR("%s: failed bd_queue_allocate\n", + printk(KERN_ERR DRV_NAME ": %s: failed bd_queue_allocate\n", priv->net_dev->name); return err; } @@ -4256,7 +3551,7 @@ TX_PENDED_QUEUE_LENGTH * sizeof(struct ipw2100_tx_packet), GFP_ATOMIC); if (!priv->tx_buffers) { - IPW_DEBUG_ERROR("%s: alloc failed form tx buffers.\n", + printk(KERN_ERR DRV_NAME ": %s: alloc failed form tx buffers.\n", priv->net_dev->name); bd_queue_free(priv, &priv->tx_queue); return -ENOMEM; @@ -4266,7 +3561,7 @@ v = pci_alloc_consistent( priv->pci_dev, sizeof(struct ipw2100_data_header), &p); if (!v) { - IPW_DEBUG_ERROR("%s: PCI alloc failed for tx " + printk(KERN_ERR DRV_NAME ": %s: PCI alloc failed for tx " "buffers.\n", priv->net_dev->name); err = -ENOMEM; break; @@ -4299,8 +3594,6 @@ { int i; - IPW_DEBUG_INFO("enter\n"); - /* * reinitialize packet info lists */ @@ -4339,17 +3632,12 @@ IPW_MEM_HOST_SHARED_TX_QUEUE_BD_SIZE, IPW_MEM_HOST_SHARED_TX_QUEUE_READ_INDEX, IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX); - - IPW_DEBUG_INFO("exit\n"); - } static void ipw2100_tx_free(struct ipw2100_priv *priv) { int i; - IPW_DEBUG_INFO("enter\n"); - bd_queue_free(priv, &priv->tx_queue); if (!priv->tx_buffers) @@ -4370,8 +3658,6 @@ kfree(priv->tx_buffers); priv->tx_buffers = NULL; - - IPW_DEBUG_INFO("exit\n"); } @@ -4380,8 +3666,6 @@ { int i, j, err = -EINVAL; - IPW_DEBUG_INFO("enter\n"); - err = bd_queue_allocate(priv, &priv->rx_queue, RX_QUEUE_LENGTH); if (err) { IPW_DEBUG_INFO("failed bd_queue_allocate\n"); @@ -4403,11 +3687,8 @@ GFP_KERNEL); if (!priv->rx_buffers) { IPW_DEBUG_INFO("can't allocate rx packet buffer table\n"); - bd_queue_free(priv, &priv->rx_queue); - status_queue_free(priv); - return -ENOMEM; } @@ -4448,8 +3729,6 @@ static void ipw2100_rx_initialize(struct ipw2100_priv *priv) { - IPW_DEBUG_INFO("enter\n"); - priv->rx_queue.oldest = 0; priv->rx_queue.available = priv->rx_queue.entries - 1; priv->rx_queue.next = priv->rx_queue.entries - 1; @@ -4466,16 +3745,12 @@ /* set up the status queue */ write_register(priv->net_dev, IPW_MEM_HOST_SHARED_RX_STATUS_BASE, priv->status_queue.nic); - - IPW_DEBUG_INFO("exit\n"); } static void ipw2100_rx_free(struct ipw2100_priv *priv) { int i; - IPW_DEBUG_INFO("enter\n"); - bd_queue_free(priv, &priv->rx_queue); status_queue_free(priv); @@ -4494,8 +3769,6 @@ kfree(priv->rx_buffers); priv->rx_buffers = NULL; - - IPW_DEBUG_INFO("exit\n"); } static int ipw2100_read_mac_address(struct ipw2100_priv *priv) @@ -4536,8 +3809,6 @@ IPW_DEBUG_HC("SET_MAC_ADDRESS\n"); - IPW_DEBUG_INFO("enter\n"); - if (priv->config & CFG_CUSTOM_MAC) { memcpy(cmd.host_command_parameters, priv->mac_addr, ETH_ALEN); @@ -4547,8 +3818,6 @@ ETH_ALEN); err = ipw2100_hw_send_command(priv, &cmd); - - IPW_DEBUG_INFO("exit\n"); return err; } @@ -4577,7 +3846,7 @@ if (!batch_mode) { err = ipw2100_disable_adapter(priv); if (err) { - IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n", + printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n", priv->net_dev->name, err); return err; } @@ -4805,47 +4074,6 @@ return 0; } -#if 0 -int ipw2100_set_fragmentation_threshold(struct ipw2100_priv *priv, - u32 threshold, int batch_mode) -{ - struct host_command cmd = { - .host_command = FRAG_THRESHOLD, - .host_command_sequence = 0, - .host_command_length = 4, - .host_command_parameters[0] = 0, - }; - int err; - - if (!batch_mode) { - err = ipw2100_disable_adapter(priv); - if (err) - return err; - } - - if (threshold == 0) - threshold = DEFAULT_FRAG_THRESHOLD; - else { - threshold = max(threshold, MIN_FRAG_THRESHOLD); - threshold = min(threshold, MAX_FRAG_THRESHOLD); - } - - cmd.host_command_parameters[0] = threshold; - - IPW_DEBUG_HC("FRAG_THRESHOLD: %u\n", threshold); - - err = ipw2100_hw_send_command(priv, &cmd); - - if (!batch_mode) - ipw2100_enable_adapter(priv); - - if (!err) - priv->frag_threshold = threshold; - - return err; -} -#endif - int ipw2100_set_short_retry(struct ipw2100_priv *priv, u32 retry) { struct host_command cmd = { @@ -4935,8 +4163,6 @@ int err; int len; - IPW_DEBUG_HC("DISASSOCIATION_BSSID\n"); - len = ETH_ALEN; /* The Firmware currently ignores the BSSID and just disassociates from * the currently associated AP -- but in the off chance that a future @@ -4950,37 +4176,6 @@ } #endif -/* - * Pseudo code for setting up wpa_frame: - */ -#if 0 -void x(struct ieee80211_assoc_frame *wpa_assoc) -{ - struct ipw2100_wpa_assoc_frame frame; - frame->fixed_ie_mask = IPW_WPA_CAPABILTIES | - IPW_WPA_LISTENINTERVAL | - IPW_WPA_AP_ADDRESS; - frame->capab_info = wpa_assoc->capab_info; - frame->lisen_interval = wpa_assoc->listent_interval; - memcpy(frame->current_ap, wpa_assoc->current_ap, ETH_ALEN); - - /* UNKNOWN -- I'm not postivive about this part; don't have any WPA - * setup here to test it with. - * - * Walk the IEs in the wpa_assoc and figure out the total size of all - * that data. Stick that into frame->var_ie_len. Then memcpy() all of - * the IEs from wpa_frame into frame. - */ - frame->var_ie_len = calculate_ie_len(wpa_assoc); - memcpy(frame->var_ie, wpa_assoc->variable, frame->var_ie_len); - - ipw2100_set_wpa_ie(priv, &frame, 0); -} -#endif - - - - static int ipw2100_set_wpa_ie(struct ipw2100_priv *, struct ipw2100_wpa_assoc_frame *, int) __attribute__ ((unused)); @@ -4996,8 +4191,6 @@ }; int err; - IPW_DEBUG_HC("SET_WPA_IE\n"); - if (!batch_mode) { err = ipw2100_disable_adapter(priv); if (err) @@ -5123,8 +4316,6 @@ cmd.host_command_parameters[0] = interval; - IPW_DEBUG_INFO("enter\n"); - if (priv->ieee->iw_mode == IW_MODE_ADHOC) { if (!batch_mode) { err = ipw2100_disable_adapter(priv); @@ -5140,9 +4331,6 @@ return err; } } - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -5196,7 +4384,7 @@ if (!batch_mode) { err = ipw2100_disable_adapter(priv); if (err) { - IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n", + printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n", priv->net_dev->name, err); return err; } @@ -5284,7 +4472,7 @@ err = ipw2100_disable_adapter(priv); /* FIXME: IPG: shouldn't this prink be in _disable_adapter()? */ if (err) { - IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n", + printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n", priv->net_dev->name, err); return err; } @@ -5320,7 +4508,7 @@ if (!batch_mode) { err = ipw2100_disable_adapter(priv); if (err) { - IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n", + printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n", priv->net_dev->name, err); return err; } @@ -5502,8 +4690,6 @@ int batch_mode = 1; u8 *bssid; - IPW_DEBUG_INFO("enter\n"); - err = ipw2100_disable_adapter(priv); if (err) return err; @@ -5512,9 +4698,6 @@ err = ipw2100_set_channel(priv, priv->channel, batch_mode); if (err) return err; - - IPW_DEBUG_INFO("exit\n"); - return 0; } #endif /* CONFIG_IPW2100_MONITOR */ @@ -5591,9 +4774,6 @@ if (err) return err; */ - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -5656,8 +4836,6 @@ struct list_head *element; struct ipw2100_tx_packet *packet; - IPW_DEBUG_INFO("enter\n"); - spin_lock_irqsave(&priv->low_lock, flags); if (priv->status & STATUS_ASSOCIATED) @@ -5679,9 +4857,6 @@ INC_STAT(&priv->tx_free_stat); } spin_unlock_irqrestore(&priv->low_lock, flags); - - IPW_DEBUG_INFO("exit\n"); - return 0; } @@ -5868,7 +5043,7 @@ break; default: - IPW_DEBUG_ERROR("%s: Unknown WPA param: %d\n", + printk(KERN_ERR DRV_NAME ": %s: Unknown WPA param: %d\n", dev->name, name); ret = -EOPNOTSUPP; } @@ -5891,7 +5066,7 @@ break; default: - IPW_DEBUG_ERROR("%s: Unknown MLME request: %d\n", + printk(KERN_ERR DRV_NAME ": %s: Unknown MLME request: %d\n", dev->name, command); ret = -EOPNOTSUPP; } @@ -6141,7 +5316,7 @@ break; default: - IPW_DEBUG_ERROR("%s: Unknown WPA supplicant request: %d\n", + printk(KERN_ERR DRV_NAME ": %s: Unknown WPA supplicant request: %d\n", dev->name, param->cmd); ret = -EOPNOTSUPP; @@ -6440,8 +5615,6 @@ int registered = 0; u32 val; - IPW_DEBUG_INFO("enter\n"); - mem_start = pci_resource_start(pci_dev, 0); mem_len = pci_resource_len(pci_dev, 0); mem_flags = pci_resource_flags(pci_dev, 0); @@ -6589,8 +5762,6 @@ ipw2100_start_scan(priv); } - IPW_DEBUG_INFO("exit\n"); - priv->status |= STATUS_INITIALIZED; up(&priv->action_sem); @@ -6644,10 +5815,9 @@ dev = priv->net_dev; sysfs_remove_group(&pci_dev->dev.kobj, &ipw2100_attribute_group); -#ifdef CONFIG_PM if (ipw2100_firmware.version) ipw2100_release_firmware(priv, &ipw2100_firmware); -#endif + /* Take down the hardware */ ipw2100_down(priv); @@ -6680,17 +5850,11 @@ pci_release_regions(pci_dev); pci_disable_device(pci_dev); - - IPW_DEBUG_INFO("exit\n"); } #ifdef CONFIG_PM -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) -static int ipw2100_suspend(struct pci_dev *pci_dev, u32 state) -#else static int ipw2100_suspend(struct pci_dev *pci_dev, pm_message_t state) -#endif { struct ipw2100_priv *priv = pci_get_drvdata(pci_dev); struct net_device *dev = priv->net_dev; @@ -6707,17 +5871,9 @@ /* Remove the PRESENT state of the device */ netif_device_detach(dev); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) - pci_save_state(pci_dev, priv->pm_state); -#else pci_save_state(pci_dev); -#endif pci_disable_device (pci_dev); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) - pci_set_power_state(pci_dev, state); -#else pci_set_power_state(pci_dev, PCI_D3hot); -#endif up(&priv->action_sem); @@ -6738,17 +5894,9 @@ IPW_DEBUG_INFO("%s: Coming out of suspend...\n", dev->name); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11) - pci_set_power_state(pci_dev, 0); -#else pci_set_power_state(pci_dev, PCI_D0); -#endif pci_enable_device(pci_dev); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) - pci_restore_state(pci_dev, priv->pm_state); -#else pci_restore_state(pci_dev); -#endif /* * Suspend/Resume resets the PCI configuration space, so we have to @@ -8295,8 +7443,6 @@ down(&priv->action_sem); - IPW_DEBUG_WX("enter\n"); - up(&priv->action_sem); wrqu.ap_addr.sa_family = ARPHRD_ETHER; @@ -8383,7 +7529,7 @@ (struct ipw2100_fw_header *)fw->fw_entry->data; if (IPW2100_FW_MAJOR(h->version) != IPW2100_FW_MAJOR_VERSION) { - IPW_DEBUG_WARNING("Firmware image not compatible " + printk(KERN_WARNING DRV_NAME ": Firmware image not compatible " "(detected version id of %u). " "See Documentation/networking/README.ipw2100\n", h->version); @@ -8426,7 +7572,7 @@ rc = request_firmware(&fw->fw_entry, fw_name, &priv->pci_dev->dev); if (rc < 0) { - IPW_DEBUG_ERROR( + printk(KERN_ERR DRV_NAME ": " "%s: Firmware '%s' not available or load failed.\n", priv->net_dev->name, fw_name); return rc; @@ -8508,7 +7654,7 @@ firmware_data_left -= 2; if (len > 32) { - IPW_DEBUG_ERROR( + printk(KERN_ERR DRV_NAME ": " "Invalid firmware run-length of %d bytes\n", len); return -EINVAL; @@ -8618,7 +7764,7 @@ } if (i == 10) { - IPW_DEBUG_ERROR("%s: Error initializing Symbol\n", + printk(KERN_ERR DRV_NAME ": %s: Error initializing Symbol\n", dev->name); return -EIO; } @@ -8639,7 +7785,7 @@ } if (i == 30) { - IPW_DEBUG_ERROR("%s: No response from Symbol - hw not alive\n", + printk(KERN_ERR DRV_NAME ": %s: No response from Symbol - hw not alive\n", dev->name); printk_buf(IPW_DL_ERROR, (u8*)&response, sizeof(response)); return -EIO; --- clean-mm/drivers/net/wireless/ipw2100.h 2005-05-11 22:00:02.000000000 +0200 +++ linux-mm/drivers/net/wireless/ipw2100.h 2005-05-13 23:16:46.000000000 +0200 @@ -44,30 +44,6 @@ #include -#ifndef IRQ_NONE -typedef void irqreturn_t; -#define IRQ_NONE -#define IRQ_HANDLED -#define IRQ_RETVAL(x) -#endif - -#if WIRELESS_EXT < 17 -#define IW_QUAL_QUAL_INVALID 0x10 -#define IW_QUAL_LEVEL_INVALID 0x20 -#define IW_QUAL_NOISE_INVALID 0x40 -#endif - -#if ( LINUX_VERSION_CODE < KERNEL_VERSION(2,6,5) ) -#define pci_dma_sync_single_for_cpu pci_dma_sync_single -#define pci_dma_sync_single_for_device pci_dma_sync_single -#endif - -#ifndef HAVE_FREE_NETDEV -#define free_netdev(x) kfree(x) -#endif - - - struct ipw2100_priv; struct ipw2100_tx_packet; struct ipw2100_rx_packet; @@ -145,8 +121,6 @@ #define IPW_DL_IO (1<<26) #define IPW_DL_TRACE (1<<28) -#define IPW_DEBUG_ERROR(f, a...) printk(KERN_ERR DRV_NAME ": " f, ## a) -#define IPW_DEBUG_WARNING(f, a...) printk(KERN_WARNING DRV_NAME ": " f, ## a) #define IPW_DEBUG_INFO(f...) IPW_DEBUG(IPW_DL_INFO, ## f) #define IPW_DEBUG_WX(f...) IPW_DEBUG(IPW_DL_WX, ## f) #define IPW_DEBUG_SCAN(f...) IPW_DEBUG(IPW_DL_SCAN, ## f) @@ -167,15 +141,6 @@ #define IPW_DEBUG_STATE(f, a...) IPW_DEBUG(IPW_DL_STATE | IPW_DL_ASSOC | IPW_DL_INFO, f, ## a) #define IPW_DEBUG_ASSOC(f, a...) IPW_DEBUG(IPW_DL_ASSOC | IPW_DL_INFO, f, ## a) - -#define VERIFY(f) \ -{ \ - int status = 0; \ - status = f; \ - if(status) \ - return status; \ -} - enum { IPW_HW_STATE_DISABLED = 1, IPW_HW_STATE_ENABLED = 0 @@ -210,8 +175,6 @@ } info; } __attribute__ ((packed)); -#define IPW_BUFDESC_LAST_FRAG 0 - struct ipw2100_bd { u32 host_addr; u32 buf_length; @@ -355,7 +318,7 @@ u16 fragment_size; } __attribute__ ((packed)); -// Host command data structure +/* Host command data structure */ struct host_command { u32 host_command; // COMMAND ID u32 host_command1; // COMMAND ID @@ -473,13 +436,8 @@ /* Power management code: enable or disable? */ enum { -#ifdef CONFIG_PM IPW2100_PM_DISABLED = 0, PM_STATE_SIZE = 16, -#else - IPW2100_PM_DISABLED = 1, - PM_STATE_SIZE = 0, -#endif }; #define STATUS_POWERED (1<<0) @@ -648,9 +606,6 @@ struct semaphore adapter_sem; wait_queue_head_t wait_command_queue; -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10) - u32 pm_state[PM_STATE_SIZE]; -#endif }; @@ -701,7 +656,7 @@ #define MSDU_TX_RATES 62 -// Rogue AP Detection +/* Rogue AP Detection */ #define SET_STATION_STAT_BITS 64 #define CLEAR_STATIONS_STAT_BITS 65 #define LEAP_ROGUE_MODE 66 //TODO tbw replaced by CFG_LEAP_ROGUE_AP @@ -711,25 +666,16 @@ -// system configuration bit mask: -//#define IPW_CFG_ANTENNA_SETTING 0x03 -//#define IPW_CFG_ANTENNA_A 0x01 -//#define IPW_CFG_ANTENNA_B 0x02 +/* system configuration bit mask: */ #define IPW_CFG_MONITOR 0x00004 -//#define IPW_CFG_TX_STATUS_ENABLE 0x00008 #define IPW_CFG_PREAMBLE_AUTO 0x00010 #define IPW_CFG_IBSS_AUTO_START 0x00020 -//#define IPW_CFG_KERBEROS_ENABLE 0x00040 #define IPW_CFG_LOOPBACK 0x00100 -//#define IPW_CFG_WNMP_PING_PASS 0x00200 -//#define IPW_CFG_DEBUG_ENABLE 0x00400 #define IPW_CFG_ANSWER_BCSSID_PROBE 0x00800 -//#define IPW_CFG_BT_PRIORITY 0x01000 #define IPW_CFG_BT_SIDEBAND_SIGNAL 0x02000 #define IPW_CFG_802_1x_ENABLE 0x04000 #define IPW_CFG_BSS_MASK 0x08000 #define IPW_CFG_IBSS_MASK 0x10000 -//#define IPW_CFG_DYNAMIC_CW 0x10000 #define IPW_SCAN_NOASSOCIATE (1<<0) #define IPW_SCAN_MIXED_CELL (1<<1) @@ -761,41 +707,6 @@ #define IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX \ (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND) - -#if 0 -#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x00) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x04) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x08) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0c) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x10) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x14) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x18) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x1c) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x80) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x84) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x88) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x8c) - -#define IPW_MEM_HOST_SHARED_TX_QUEUE_BD_BASE(QueueNum) \ - (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + (QueueNum<<3)) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_BD_SIZE(QueueNum) \ - (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0004+(QueueNum<<3)) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_READ_INDEX(QueueNum) \ - (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0080+(QueueNum<<2)) - -#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_WRITE_INDEX \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x00) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_WRITE_INDEX \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x04) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_WRITE_INDEX \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x08) -#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_WRITE_INDEX \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x0c) -#define IPW_MEM_HOST_SHARED_SLAVE_MODE_INT_REGISTER \ - (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x78) - -#endif - #define IPW_MEM_HOST_SHARED_ORDINALS_TABLE_1 (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x180) #define IPW_MEM_HOST_SHARED_ORDINALS_TABLE_2 (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x184) @@ -913,7 +824,7 @@ } rx_data; } __attribute__ ((packed)); -// Bit 0-7 are for 802.11b tx rates - . Bit 5-7 are reserved +/* Bit 0-7 are for 802.11b tx rates - . Bit 5-7 are reserved */ #define TX_RATE_1_MBIT 0x0001 #define TX_RATE_2_MBIT 0x0002 #define TX_RATE_5_5_MBIT 0x0004 @@ -1193,7 +1104,6 @@ IPW_ORD_UCODE_VERSION, // Ucode Version IPW_ORD_HW_RF_SWITCH_STATE = 214, // HW RF Kill Switch State } ORDINALTABLE1; -//ENDOF TABLE1 // ordinal table 2 // Variable length data: -- Boycott Kodak -- for their patent abuse against Java. From akepner@sgi.com Fri May 13 17:00:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 17:00:23 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4E00JOv011863 for ; Fri, 13 May 2005 17:00:19 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4DNxoxT023210 for ; Fri, 13 May 2005 18:59:50 -0500 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4DNxj5x25388360; Fri, 13 May 2005 16:59:46 -0700 (PDT) Date: Fri, 13 May 2005 16:57:51 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: "David S.Miller" cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: Perf data with recent tg3 patches In-Reply-To: <20050512.211935.67881321.davem@davemloft.net> Message-ID: References: <20050512.211935.67881321.davem@davemloft.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-317892268-1116028671=:14917" X-archive-position: 1109 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 10396 Lines: 205 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323584-317892268-1116028671=:14917 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 12 May 2005, David S.Miller wrote: > ...... > The tg3_interrupt coalesce patch from me is supposed > to be applied on top of my tagged status patch. > OK, but the "tagged status" patch and the "hw coalescing infrastructure" patch aren't really dependent, right? In any case, I've repeated the measurements with both patches. Same experiment as yesterday. The data is in the attached graphs is labelled as follows: --------------------------------------------------------- base : is a "vanilla" 2.6.12-rc3 kernel base+[1]+...+[i] : "vanilla" 2.6.12-rc3 kernel + patches as labelled below [1] http://marc.theaimsgroup.com/?l=linux-netdev&m=111446723510962&w=2 (This is one of a series of 3 patches - the others can't be found in the archive. But they're all in 2.6.12-rc4.) [2] http://marc.theaimsgroup.com/?l=linux-netdev&m=111567944730302&w=2 ("tagged status" patch) [3] http://marc.theaimsgroup.com/?l=linux-netdev&m=111586526522981&w=2 ("hw coalescing infrastructure" patch) The data I sent yesterday was also with 2.6.12-rc3 (I mistakenly said it was rc2.) Also, I should have said that I only used the default coalescence parameters with [3] - didn't tune them with ethtool. Same is true of today's data. The graphs show that the tagged status patch ([2]) is associated with fewer received packets/interrupt and higher CPU utilization. I found that the reason is that, under high receive load, most of the time (~80%) the tag in the status block changes between the time that it's read (and saved as last_tag) in tg3_poll(), and when it's written back to MAILBOX_INTERRUPT_0 in tg3_restart_ints(). If I understand the way the status tag works, that means that the card will immediately generate another interrupt. That's consistent with what I'm seeing - a much higher interrupt rate when the tagged status patch is used. -- Arthur --8323584-317892268-1116028671=:14917 Content-Type: IMAGE/png; name="cpu_vs_link.3.png" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: CPU utilization Content-Disposition: attachment; filename="cpu_vs_link.3.png" iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgAQAAAAAdquFJAAAAQ3RFWHRTb2Z0 d2FyZQBnbnVwbG90IHZlcnNpb24gNC4wIHBhdGNobGV2ZWwgMCBvbiBMaW51 eCAyLjYuOC0yNC1kZWZhdWx0nVoNlQAACydJREFUCJntnb1vG8kVwCk4gZBK CdIGx+D+gSuvSMF0AQKkuSK4zulycBEVh0BJdOQop/RuUqTTFVekCS6dC584 cpMUAawUQQScYQ47I3Dsoe1II2k58zLzltwvcsnZmScffd5XLMWn3R/fvpnZ 9+btVweIpdMCW2ALbIEtsAW2wBsAHk66nIOUCuBFpmSzBecC4O/NgH0lZ8Ce LgB7c+AUVCOgMUrRAiEDQhEI+S4HAg8QqNSYpax/Mgcc3goAFn2olOAI7J3y /cBdzlqZI9DxLJALsYdA09xCKAFFBnyPBjjOgLcpgInEFkbgbhjQzIHMAbUA 11NyHz5uCrQjBQQDJa7RQsM5u2uBzAJtKwv2tDHwUIF122VPm52J3Vt2AtbC zmBHiD7Y/6jL3oNmwDBpgS2wBbbAFvimAU/eIULPMTbKtsBI4MngFi0Q041O nOyUgG6fGf4lcZmk6qJK+6jeHKAYEQMl79MCJ+yQ2IfVVd8qoJ+QA+t+47UD +exzwuS0C7C9fC4RAFRw6qYpTAld2NrTh7ygmv3NFdwFkQCTUkOdNARKBEIs 8DPrtu4DQuARS5QcFoABPrwsRhfOtZ0o/+YWAg96bNpbbqEQvj7kWrk57YKF ZdHPuDdw67LXYet8aF4xX+BQu2n4IrDsQ/EB+AKPNcgCsKYf/vfPiedIORpo 6SpACCyOlJIkLz9UnsDPYGvihq8NEfVjmR+/fHe3AjzpHoYfD8Xv/vOtH4hK GIV++OHruf7gp9/hFaAx4cDzi8+//X1WBU7DgUnys3c/rWYO5jrch+effPrh SbVRBhcRPpx+96+darcZPrdf3vfZ3Dwvy8OHD+98dOeHvzop54ejUaiFkvMv /zjdqrQyjIZlYDL/Y9vAso6d+1Ax+O2fPvmDqAIHNUA2xZqu7adi+dCzrZnc +dFP6vPDJCkA7fHg0gK5sv205uCA5c+fH9bnh1qVgQaBYOqOh9du8798rz4/ NPiP650J+/20Wwss+ZDBVx+tONrcdosrBXyQyByo60KA5Hbx+f/WHWCtJ0fW NzYuWeClDVKHdUHKxSfYg3UWWqBgSuUWslVByiQrgKkPk2TSPZxsZ0DbCVbE FK1XAGetnEhh/6oFLpE64KwfJkKYRWBQsoRypeRIOzQCAYHLRorKi9mrgbYf dm/lw3cy6Cwfy4nMNqRJibXwtNBXDCcGFjaimaeghYwAOBdyHyaSGOjRD7+m yeMSedOAgw6VD6edrv00AzILtTssgaYGJtRAlQNjfZgCpasfxlkoy7kNc/XD 9/fC5eMfl/LDk25E0o6SlC10sSjOh49qgWEivupURkos8KACZBEzKSdn/7g7 AxrGERhZP/zX1hwI/HZmZbiB063MQsALImKB8O9OBsyjTAyw09maA/MokwLD fHj2MGvlbEYS18p/mwNN5dqXQFEZEA+tBMCTnbmF7hqfIjBwLF9UxnKshdDZ JQaSW3jRqQOG+rAWGCjjbWKgeVKKejcJDPSh6ewSW6iIdxnmwDT7IgQWJAWG 5jYVIGtYkFwiJaCJDaNVoI4N9FVgMpjG+rAMVIOGBcl1FsqYguQyoBg8j0w4 9yoJ5zsjWh/CYEi7yzAYUAOJ+2Eh4STyIfVYLvzQ5gNff81BLbu6NAZYKNUs BU66DYGFYtJSYDVpX+tDLHet8GH+e54W1q0XDCyUDGmA63xYBa71IbYypQ/X 9UOaqVkBeNIlBubCcv1rHctNLXz9wJpjQ35wyDissP4KH8pFVQmI55QmeUEy 2kI8pySHQAsUI2+gqbs4swSEHBjtwypwrXjtMgz9C5LrgNjKlw0Kkr9ckx+m /ZDf3PWHwRIANCuvRS3n2CMvC/veQM8LGu8vqiprLTlhvUrOvC0s/NDabdYC hT/Qz8IKMNaH5hddfwt9WtnsVixcIZ790B+4Wtq4fHPADfRhxiECep9cqElc F4GiDKz14fmianlcJrZw2sk4NED/WUBnzf8bz1O8feg+fWKK7y6nX/KoRwP0 icuNgDAirh/CiLh+CEO6+iHWHC4J64fPBFpIVz98jMDqBY0RuzwD0tUPEeiZ H/oDKW94QaBnfuhlYV6GIQKSB6lcWK7frLi88UDvuOzrw9MKMNrCM2rgI2rg 4wow2ocjagvdAyRogUfUQFEGtmM5Hkjjwyb1Qy8Lm9QP1wIFNKof+gGb1A9X qrKaA52Fs5pDg/rhGmC6y5PoCxor55clUN9uDMT1Q3pgzI1XS4FAlx+iNL55 bZ2FhR/aQKAoA+N9WAHGWkh2idEcSHYRVC2wjcvxwNaH8cCNG8vkwEZnK7yA 1bMVND6krDmkXzzqh42AlHWbVN6q+iHKhPL6Q2eYNHT1QzwXIAxd/TC9LMHQ 1Q9nFpL1w/RsBWV+KNwnZX4oMs2mAnNhub6Ny1HAuQ+Tqsr7nsfMsLKFSbCF vAbYlLgu0F+tOwflC5z78OA9COyHNRYmt4kszICcGng7FJhZwnK99eG1BNp+ qINbOZMyMLwf1gAby80eD7Uhrh9eGaAFvqAG6hxI5UNyCwnrhwgE4vqhpq4f aupyHz2Qun6oqeuH5HO9wg/FAv0v4PEE1saUBdU3puZw88AN9CGnBd5AP8yE 5fp2ntII2K0AY32YPuuK0EJdfVrC5gNjfXhDFmogC1Ip8CrmCY1lYHrG54Wh zm1intBYtnAOJC5IakNckNQmK0im97N8XMwlU9WvV6uyhJMxBAY/obFqocGY oukKkrMHN9EVJOdAsn44A9KNFE19coH83Kghzw9vPHPYfGCb28QDWx/GA1sf xgM31YfUBUlIq3NNC8NeQCIf3qCFVEAsSK67FaoBMC9IRueHcxOJd3nzgZgf YnZMNZZdfjiMMbAKdPnhY0qgFfaUGqgyPdHxkNxCch+StjJQ98NMT2nhGwJs fRgPfAt9SL7LGwskf2sY8Wk4oK4fgqG+oDGvH1IBL6iBrn5I+QZAVz+kkBwY F0KXAAerVgsBrnyoSQBw9WNXQoCH1EAiaYEtMBY4xqW47NnlA+OORrM3xChU HfS27XKKqukWqsawna0lp91xBSiYWx7hq+yHePJLCTwIPUEVx9f/JKlKo0oM kmyt00RaQAnIuVt28dnebN+tKiXm8Weo4vj6HzU7AZOqjnW21l2lLKAM7KGd 8tR97L9ySzlwW99DFddXTgOoSlLVMapwLameWEAJOOQp8AsE4rRK9t3We6ji +hyBqFKp6hhVuJZUZ8OKhccz4C641yU9wi/7DJ9U7VQH+hkCncpCnEr0nyF8 H4H3jivA+ynwufPOg+Q+uCbdY64BUAV9N3Ubo2q21lg71eXOHgL37leA91Lg M3R3so9fdpnrI6iC42NnGqqAo0r0j9ExTiUv1L0K8IsU+BRb+Rojs7yNDnua Avu4r6hiT9NW7mdryXP1RQV4lALx6ePsKgX2EJg+kPzLtI84lQFUcVSBcCr5 Sh1Vu00KTPthUuiHaqHTaSiogDP04UI/TEeKwDHAiiNFLQwLDUUVzovl4khJ x/I2jtLOYGEsFweuhqLKvewNDhfHMoW0wBbYAltgC/wagGq2SBIbiaYs11kZ mzQGNAS+yoCnwF6luhQjdT+/nIEEaHQIEPJdns3a57ss7ZQ/BKi3ETjuOaBL gw/c3Yz4blEVtMvTRPF8lxObBEBPDvsOKEOAidaKIVDa3MS94tjahfesuncd hwFfQg6URSAPBJ4XgOJyJweyQOBFAchVbqGBKB8KBDIpFZsBdUi3UQ7IbYpt uAMamydeA5dDBJ43B062x9pNmOwkzb2Xd2z74Y42OxP3RooxJM3HcpC0wHj5 PzX2XxjA9QfNAAAAAElFTkSuQmCC --8323584-317892268-1116028671=:14917 Content-Type: IMAGE/png; name="packets_vs_link.3.png" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Received Packets/Interrupt Content-Disposition: attachment; filename="packets_vs_link.3.png" iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgAQAAAAAdquFJAAAAQ3RFWHRTb2Z0 d2FyZQBnbnVwbG90IHZlcnNpb24gNC4wIHBhdGNobGV2ZWwgMCBvbiBMaW51 eCAyLjYuOC0yNC1kZWZhdWx0nVoNlQAACbFJREFUCJntnb9vI7kVx7VnJAKS QkGAtFHq9CmzwpYBAiT/wTXpr9xiT+LmXGyZIOmzaXPNXhFgi8WKqlIFt0CA wECQNQWkcBCvTTk+m7I55AvnUaPhjCxrZvi0kOIhsLLfDPXx43f4hj+G3OkA ceq0wBbYAltgC2yBLZAWaA/SD/dPpdYhgM7PqcWH1gYgYRWBJgTKEvByCXwH VYE2AApqIC8DIS9ydWDSn1qYD57bLjD5TX8yfOG+POp6lukicDqoDjQgxUgp oYy2IC+lNs/cl4faFznRitcs8gEoPpZSKg2OrZROXPnYM19abYxiCJSVge57 3H7qgMbJlwJRr+ES+F+oC0y63PJpT9meyoGjXga8qg10KllXXxQouQSO8Qoj 8Lo2UKGGoJgWCHzrjr6HlBtoKGp5mF5luNXOKQc0qXynWs0dUKVADkZZXkvD qdXzgUmcbIdKYSyqpOd+zLpTBxRge8AOk341YERqgS2wBbbAFrhvwBkjBkpO DBTiwQHJNXRXedqJTL2ShxJ/sQu7qRFo+NCA5Bq6q0wLjGHsO3BjIgdu+FMf GagWP60bTxwCTKE7H9AA4SYdg0urcTgOtTRU+ZHsd2XhwgGZNAZ4bQ/vBhoE Qizwm/4UDuYDOuClhJEb1+XAJhp2WH7IjUffgpSdUQqcdSW8iNVQuVG3lAUP I4HTQTedKKDSUCnBtSxe5bh6qDg3AbBRPQzTpRRv00kCD/SREgV09fBxGr62 N2Mksbz2a/+/98OPAmw1rApki59TEKWK3VBDtjz40kWbdb2zxqHHWAB0N5g+ cHdzEKLxzWEceuiAAoEgGt8P3+PnEyfb4PAuYG0NT/HzMSgphgGQRzYBjGlh bdouOaBrpGascSN1mgGltbmHsnkj5TVko4PZqJMDRfM2ZXGVhzr97Q5gbQ8X 9fCZhuMVYI16OOkXI+Wx0YKzNJPASBEbGylb8lAUgU/swTRvl2xv0t8UyxuA 9VMZyGOBx7IIZLHASa8AtNFtyvMi0DjJv30ek76Y9EKgjm0CPnQ6BQ9VLFCW gDJ28PjvElBEe/g7WqDt/Jbaw9//gnYALl+uATb2ED7bcWAG2IFJjLoe7j6w 1bBy4gGQhcCmGgZAwYk9zCbZ6YCcADg/WAKTbF6FTkMg8HC/gFlqY5kKSKDh jNpDyYiBNDeHtUACDbfs4S4Cs6eYZBpOHhF7WLD3AEh1P5wzOg8nfUhXBxIW mXmDDsghGPhQaChCIIWHWwFOWOyI/jwf0aOHnFBDDpA/UicosistLRATOXB7 D/2pPATCeqhCmwIoQ5ukXab2cN+ABBoWLwqBh+TVBhspSmDBbscpjYDFq7yL 9VDsGXAX74f7dnNoYzkeSKDhBbWHZ9TA92KrQAINt+zhLgLPeAikmPtixB4W 7N0FLh/6U90PBaWHjBiIzwJIgSIEUrTLqYdujEvl4eJpBaebIhCIF9R9G0Go IbWHnkcNXE4RUAG3ty+AykNK4KxPDCz2YHexj71vwF3UkHyc0s457DxwBzU0 Wc3eWWDS6YfAeA13v8hFmx64g/Vw74AEGjJqDzk1UNQE2k3Aun0be2+2BrNz d3mov/ozXwKz/64nBnjzt5+xJdDUBE57q8f+OfkkL3L2F5tpmI4ULXzZ+VZQ sVk9D4tF9ssu/v7975YjhTUEqtQd+5+Ch5irKfDWHbDyVz//pAQ0Tccp6SX9 /OT5F09YEaire1hMzkN4c/nr7/0or4e4Zkk1BSrG2NHNd/70k7zIxxyQuglo 7jwq+Rhk8oNf/iMH4mSa2PzQ/8OdR7/++q/nf/nw4y+DET0Cy7s/KnuYbrl5 M/8pOhsCK9TDdUAFw9kfmgCzvviKh9b+69164Pqql6w58x7syUkIPK3o4boi j7NfljdYHgf0m4KgFHqZ3QBYBDzQvg0jBhYXJ1OMl0U9D+26rsPdHlZIw/uB peXTFdKb+4H15xyO7svWZM5hXcbGwKMNwE1/eCVt0rAIrKDh8L5sDTzcWA/r AtemrQGLjzIJYnnfHmWSAwk03P0in/HKQM6rAIuPMu9VyvUiadvl83vPNgBe UQP1vWcb3A+vNmfbioaiMjC9ypuBxWX896Zq9VCxEEgQy7fhH4hJGXDNFEF9 fgZcM4nRGLhuDlZCUw0xra4lbl5kb/ASwXbK+esBXTeW1kMQxBoCoYc+Usoa RgAxlueE+wL8sILXUqrCOGVFw/ppu8DVehgJpNwXgFeZcl/Avi2CehBzDuTr HM5ECHwQfey9GqcwEg8tJwYu575ktq03FpjZKu2gUsay/qpL66FZzqYSAS3R RelnNnoYr6HNIkRqTuKhWT4oVCKKtwqUkdG8AsTPeA0N9c6F3QeSrxUp/gEC D/cO2GoYD3w4GpLvDt7ef/xO5SHlWG9LQGoNZ5Q7/Rf0UpHrN6rFq7wCrN/s 3w1c6qF5XD1c8dAwGg+Xad2jrIrA1ZUYkR4CtYZAfZVXgZH1cBVYPz30NmV7 wFbDeGCrYTyw1TAe2GoYD2w1jAe2GsYDH6CG5EXeWaChBt5QAy92vsh7AaR9 A+DG5eBVUwukA5K/zZMstcAWGAf0rzHHlxHC4gVm+NInAIUGvjUG4EVohNlk 0p8WgBpvkDd+ybrGmSrJcZfCCRrCb1l45uewxEq2d1oKFgIVPj67wCXrxuBM lTjGm/GRN/CMXcxhHa9k+036JrkCELcSGYu7jYx8h19D4zUaAs8Y8GfGiQfi Gcwm1QkfFIBHHnjrga8QiMZTNASecUA8M7r1QDyD2aQ6Ghc9fO2B117Qz9CP 1LAKjcno2gNTw2I267PJ42sEvn5bBD71QFzs2j1PxZmPUsMoNGCcGok/U8g2 ++E5Ap++KQCvlQceo/RnnpEaySNvHKeG0Whon00HZ+S1el0AXi2AYyzYqc85 Rt8Dwxg0lA0Mf0ZeqVcF4OUCOELgic85QmBgGIOGtIEB49SQl+olX62HxtdD COuhCoys6oXVFUYWNSzVQx8pBuPBQBgpKjAWwSHCgDpHQ5Yjxceyj8vk0Wos LwwfviIM+Qs0DsuxTJNaYAtsgS2wBX58oFl8WFwC18+PuTQfcNurD0yWwEsQ vg8F2FMCDZ+yuyeOGgN5EyAERRb5MQTaNVNbG4BPEDjvIbAz6k0HrrX9Ywo0 TYAJPDYyL7IFZdKO70vmgLoJ0JGGAoHa9T3SNxybRYdDg2oI/JznQB0CZVMP WQ5U9iAHiqbAwENpAg95lIZPESi0NiIDjhoATQqU6RbtVwjkRlvuOm0IHNav 2GmXjg1dL/QQBL7HszM6AOY6bQ44H9j6sdwstcD49D9MDu45bwKsXQAAAABJ RU5ErkJggg== --8323584-317892268-1116028671=:14917-- From davem@davemloft.net Fri May 13 17:51:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 17:51:52 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4E0pkOv013544 for ; Fri, 13 May 2005 17:51:46 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWkr7-00032l-Hc; Fri, 13 May 2005 17:50:13 -0700 Date: Fri, 13 May 2005 17:50:13 -0700 (PDT) Message-Id: <20050513.175013.00786860.davem@davemloft.net> To: akepner@sgi.com Cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: Perf data with recent tg3 patches From: "David S. Miller" In-Reply-To: References: <20050512.211935.67881321.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1110 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1215 Lines: 38 From: Arthur Kepner Subject: Re: Perf data with recent tg3 patches Date: Fri, 13 May 2005 16:57:51 -0700 (PDT) > I found that the reason is that, > under high receive load, most of the time (~80%) the > tag in the status block changes between the time that > it's read (and saved as last_tag) in tg3_poll(), and when > it's written back to MAILBOX_INTERRUPT_0 in > tg3_restart_ints(). If I understand the way the status > tag works, that means that the card will immediately > generate another interrupt. That's consistent with > what I'm seeing - a much higher interrupt rate when the > tagged status patch is used. Thanks for tracking this down. Perhaps we can make the logic in tg3_poll() smarter about this. Something like: tg3_process_phy_events(); tg3_tx(); tg3_rx(); if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) tp->last_tag = sblk->status_tag; rmb(); done = !tg3_has_work(tp); if (done) { spin_lock_irqsave(&tp->lock, flags); __netif_rx_complete(netdev); tg3_restart_ints(tp); spin_unlock_irqrestore(&tp->lock, flags); } return (done ? 0 : 1); Basically, move the last_tag sample to after we do the work, then recheck the RX/TX producer/consumer indexes. From sri@us.ibm.com Fri May 13 18:02:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 18:02:20 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4E127Ov014453 for ; Fri, 13 May 2005 18:02:13 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4E11UsE001521 for ; Fri, 13 May 2005 21:01:30 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4E11UaE150088 for ; Fri, 13 May 2005 21:01:30 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4E11Udw018342 for ; Fri, 13 May 2005 21:01:30 -0400 Received: from [127.0.0.1] (IBM-2RI44RCU0TC.beaverton.ibm.com [9.47.18.105]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4E11S67018283; Fri, 13 May 2005 21:01:29 -0400 Message-ID: <42854DE7.5030704@us.ibm.com> Date: Fri, 13 May 2005 18:01:27 -0700 From: Sridhar Samudrala User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: Clay Haapala , lksctp-developers@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: SCTP: use lib/libcrc32c.c instead of net/sctp/crc32c.c? References: <20050513135004.GG3603@stusta.de> In-Reply-To: <20050513135004.GG3603@stusta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1111 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 605 Lines: 26 Adrian Bunk wrote: >As far as I understand it, lib/libcrc32c.c could be used instead of the >similar code in net/sctp/crc32c.c . > >Is there any reason why this isn't done? > > The SCTP RFC3309 says that SCTP uses a tranport-level CRC where the bit ordering is mirrored and different from link-level CRC. The CRC is computed using a procedure similar to ETHERNET CRC [ITU32], modified to reflect transport level usage. So I am not sure if we can use the libcrc32c routines for calculating SCTP crc32 checksum. But if it is possible, we should definitely use the crc32 library. Thanks Sridhar From mchan@broadcom.com Fri May 13 18:37:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 18:37:54 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4E1bpOv016015 for ; Fri, 13 May 2005 18:37:51 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 13 May 2005 18:37:13 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 13 May 2005 18:37:10 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AYI69443; Fri, 13 May 2005 18:37:10 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA09735; Fri, 13 May 2005 18:37:10 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Sat, 14 May 2005 01:37:09 +0000 Received: from rh4 by nt-irva-0741; 13 May 2005 17:39:19 -0700 Subject: Re: Perf data with recent tg3 patches From: "Michael Chan" To: "David S.Miller" cc: akepner@sgi.com, netdev@oss.sgi.com In-Reply-To: <20050513.175013.00786860.davem@davemloft.net> References: <20050512.211935.67881321.davem@davemloft.net> <20050513.175013.00786860.davem@davemloft.net> Date: Fri, 13 May 2005 17:39:19 -0700 Message-ID: <1116031159.6214.8.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E9B89C321S4577226-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1112 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 682 Lines: 27 On Fri, 2005-05-13 at 17:50 -0700, David S.Miller wrote: > Perhaps we can make the logic in tg3_poll() smarter about > this. Something like: > > tg3_process_phy_events(); > tg3_tx(); > tg3_rx(); > > if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) > tp->last_tag = sblk->status_tag; > rmb(); > done = !tg3_has_work(tp); > if (done) { > spin_lock_irqsave(&tp->lock, flags); > __netif_rx_complete(netdev); > tg3_restart_ints(tp); > spin_unlock_irqrestore(&tp->lock, flags); > } > return (done ? 0 : 1); > > Basically, move the last_tag sample to after we do the > work, then recheck the RX/TX producer/consumer indexes. > I like this. I think it will work well. From davem@davemloft.net Fri May 13 22:21:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 13 May 2005 22:21:44 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4E5LeOv025671 for ; Fri, 13 May 2005 22:21:40 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DWp4J-0004eG-O4; Fri, 13 May 2005 22:20:07 -0700 Date: Fri, 13 May 2005 22:20:07 -0700 (PDT) Message-Id: <20050513.222007.78719997.davem@davemloft.net> To: mchan@broadcom.com Cc: akepner@sgi.com, netdev@oss.sgi.com Subject: Re: Perf data with recent tg3 patches From: "David S. Miller" In-Reply-To: <1116031159.6214.8.camel@rh4> References: <20050513.175013.00786860.davem@davemloft.net> <1116031159.6214.8.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1113 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1355 Lines: 47 From: "Michael Chan" Subject: Re: Perf data with recent tg3 patches Date: Fri, 13 May 2005 17:39:19 -0700 > I like this. I think it will work well. Here is a quick patch which implements this. --- 1/drivers/net/tg3.c.~1~ 2005-05-13 22:13:02.000000000 -0700 +++ 2/drivers/net/tg3.c 2005-05-13 22:18:03.000000000 -0700 @@ -2869,9 +2869,6 @@ static int tg3_poll(struct net_device *n spin_lock_irqsave(&tp->lock, flags); - if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) - tp->last_tag = sblk->status_tag; - /* handle link change and other phy events */ if (!(tp->tg3_flags & (TG3_FLAG_USE_LINKCHG_REG | @@ -2896,7 +2893,6 @@ static int tg3_poll(struct net_device *n * All RX "locking" is done by ensuring outside * code synchronizes with dev->poll() */ - done = 1; if (sblk->idx[0].rx_producer != tp->rx_rcb_ptr) { int orig_budget = *budget; int work_done; @@ -2908,12 +2904,14 @@ static int tg3_poll(struct net_device *n *budget -= work_done; netdev->quota -= work_done; - - if (work_done >= orig_budget) - done = 0; } + if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) + tp->last_tag = sblk->status_tag; + rmb(); + /* if no more work, tell net stack and NIC we're done */ + done = !tg3_has_work(tp); if (done) { spin_lock_irqsave(&tp->lock, flags); __netif_rx_complete(netdev); From ja@ssi.bg Sat May 14 00:09:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 00:09:29 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4E79NOv030313 for ; Sat, 14 May 2005 00:09:24 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id j4E7HrP0001599; Sat, 14 May 2005 10:17:53 +0300 Date: Sat, 14 May 2005 10:17:53 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Adrian Bunk cc: Wensong Zhang , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Status of net/ipv4/ipvs/ip_vs_proto_icmp.c? In-Reply-To: <20050513041622.GE3603@stusta.de> Message-ID: References: <20050513041622.GE3603@stusta.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1114 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 259 Lines: 15 Hello, On Fri, 13 May 2005, Adrian Bunk wrote: > Will it be made working in the forseeable future or is it a candidate > for removal? IMO, it can be removed as it was never finished. We can always add it later. Regards -- Julian Anastasov From ja@ssi.bg Sat May 14 00:49:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 00:49:34 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4E7nROv002430 for ; Sat, 14 May 2005 00:49:28 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id j4E7vQP0001718; Sat, 14 May 2005 10:57:26 +0300 Date: Sat, 14 May 2005 10:57:26 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "David S. Miller" cc: netdev@oss.sgi.com, Wensong Zhang Subject: [PATCH] ipvs: remove extra __ip_vs_conn_put for incoming ICMP Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607745702-1685291764-1116057446=:1568" X-archive-position: 1115 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 1435 Lines: 35 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1607745702-1685291764-1116057446=:1568 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, Dave, please apply a patch against 2.6.12-rc4 Remove extra __ip_vs_conn_put for incoming ICMP in direct routing mode. Mark de Vries reports that IPVS connections are not leaked anymore. Signed-off-by: Julian Anastasov --1607745702-1685291764-1116057446=:1568 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="icmp_xmit.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Fix ICMP xmit Content-Disposition: attachment; filename="icmp_xmit.diff" ZGlmZiAtdXIgdjIuNi4xMi1yYzQvbGludXgvbmV0L2lwdjQvaXB2cy9pcF92 c194bWl0LmMgbGludXgvbmV0L2lwdjQvaXB2cy9pcF92c194bWl0LmMNCi0t LSB2Mi42LjEyLXJjNC9saW51eC9uZXQvaXB2NC9pcHZzL2lwX3ZzX3htaXQu YwkyMDA0LTA4LTMxIDA4OjA5OjMxLjAwMDAwMDAwMCArMDMwMA0KKysrIGxp bnV4L25ldC9pcHY0L2lwdnMvaXBfdnNfeG1pdC5jCTIwMDUtMDUtMDkgMDA6 MzE6NDcuODEwODA3MjMyICswMzAwDQpAQCAtNTIwLDcgKzUyMCw2IEBADQog CQkJcmMgPSBORl9BQ0NFUFQ7DQogCQkvKiBkbyBub3QgdG91Y2ggc2tiIGFu eW1vcmUgKi8NCiAJCWF0b21pY19pbmMoJmNwLT5pbl9wa3RzKTsNCi0JCV9f aXBfdnNfY29ubl9wdXQoY3ApOw0KIAkJZ290byBvdXQ7DQogCX0NCiANCg== --1607745702-1685291764-1116057446=:1568-- From khc@pm.waw.pl Sat May 14 03:58:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 03:58:15 -0700 (PDT) Received: from khc.piap.pl (khc.piap.pl [195.187.100.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4EAw8Ov007938 for ; Sat, 14 May 2005 03:58:11 -0700 Received: by khc.piap.pl (Postfix, from userid 500) id 3B1AC3408B; Sat, 14 May 2005 12:57:36 +0200 (CEST) To: Jeff Garzik Cc: Netdev , Linux Kernel Subject: Re: git repository for net drivers available References: <42841A3F.7020909@pobox.com> From: Krzysztof Halasa Date: Sat, 14 May 2005 12:57:35 +0200 In-Reply-To: <42841A3F.7020909@pobox.com> (Jeff Garzik's message of "Thu, 12 May 2005 23:08:47 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1116 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Content-Length: 454 Lines: 14 Hi, Jeff Garzik writes: > Although I have over 200 net driver patches to go through in my > 'Pending' folder, I have fully converted the existing netdev-2.6 > repository from BitKeeper to git. This includes the wireless-2.6 > repository. Do you prefer plain patches or GIT repository on kernel.org to merge for future (and "current") updates? I haven't set a public repo up yet, but it's a matter of seconds. -- Krzysztof Halasa From herbert@gondor.apana.org.au Sat May 14 04:06:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 04:06:52 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4EB6gOv008853 for ; Sat, 14 May 2005 04:06:42 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DWuSP-0006QB-00; Sat, 14 May 2005 21:05:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DWuSK-0000LE-00; Sat, 14 May 2005 21:05:16 +1000 Date: Sat, 14 May 2005 21:05:16 +1000 To: Manfred Schwarb Cc: marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: 2.4.30-hf1 do_IRQ stack overflows Message-ID: <20050514110516.GA1238@gondor.apana.org.au> References: <21780.1115887477@www69.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21780.1115887477@www69.gmx.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1117 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 527 Lines: 13 On Thu, May 12, 2005 at 10:44:37AM +0200, Manfred Schwarb wrote: > > Trace; f8b531fc <[reiserfs]reiserfs_insert_item+14c/150> > Trace; c02387be <__kfree_skb+fe/160> > Trace; c02387be <__kfree_skb+fe/160> > Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180> Do you have any funky netfilter/iptables modules loaded? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From axel@freakout.de Sat May 14 06:01:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 06:01:21 -0700 (PDT) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.20.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ED1AOv015958 for ; Sat, 14 May 2005 06:01:17 -0700 Received: from bongo.freakout.de (freakout.homeip.net [217.173.146.67]) (authenticated bits=0) by postman.arcor.de (8.13.4/8.13.4) with ESMTP id j4ED0V40010102; Sat, 14 May 2005 15:00:31 +0200 (MEST) Received: (from axel@localhost) by bongo.freakout.de (8.13.3/8.13.3) id j4ECx1Gj007395; Sat, 14 May 2005 14:59:01 +0200 From: Axel Reinhold Message-Id: <200505141259.j4ECx1Gj007395@bongo.freakout.de> Subject: Re: sis900 and vlan support In-Reply-To: To: Daniele Venzano Date: Sat, 14 May 2005 14:59:01 +0200 (CEST) CC: romieu@fr.zoreil.com, netdev@oss.sgi.com X-Mailer: ELM [version 2.4ME+ PL121e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Logged: Logged by bongo.freakout.de as j4ECx1Gj007395 at Sat May 14 14:59:01 2005 X-archive-position: 1118 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: axel@freakout.de Precedence: bulk X-list: netdev Content-Length: 6320 Lines: 151 According to romieu@fr.zoreil.com: Please keep netdev@oss.sgi.com in the Cc: : my mailboxes are not indexed by Google nor accessible to the usual contributors. According to Daniele Venzano: > Thanks for the pointers, I'll see if there is something I can do, but > bear in mind that I'm not the 2.4 maintainer. > If you could provde a patch - i'm happy. > On 12/mag/05, at 20:00, Axel Reinhold wrote: > > i tried the actual driver in a 2.4.30 tree: > > > > /lib/modules/2.4.30-ARXc3/kernel/drivers/net/sis900.o: unresolved > > symbol pci_get_device > > /lib/modules/2.4.30-ARXc3/kernel/drivers/net/sis900.o: unresolved > > symbol pci_dev_put > You should try a whole 2.6 kernel, not only the driver, there have been > big core changes and, as you have seen, things are no more compatible. > If I'm sure the problem exists also on 2.6 I can try to do something > about it. > Can not use full 2.6 on my server at the moment. There are still things not working in 2.6 (i need lvm-snapshots, umsdos, iBCS emulation, ...) - so stuck into 2.4 for the next year at least. > If I understand right to reproduce I have to load the vlan module, > create a vlan device (how??) and send packets with a size near to the > MTU. Right ? > my setup: modprobe sis900 modprobe 8021q ifconfig eth0 192.168.207.68 vconfig add eth0 7 vconfig add eth0 8 ifconfig eth0.7 192.168.7.68 ifconfig eth0.8 192.168.8.68 the switchport must be configured as a trunc and allow tagged vlan membership for at least VLAN 7 and 8. You need another device in one of the VLANs to ping to. Here's the output of a little test-script - it pings with sizes from 1466 to 1474 - from 1470 on the ping failes: from dmesg: sis900.c: v1.08.07 11/02/2003 PCI: Found IRQ 12 for device 00:01.1 eth0: SiS 900 Internal MII PHY transceiver found at address 1. eth0: Using transceiver found at address 1 as default eth0: SiS 900 PCI Fast Ethernet at 0xd400, IRQ 12, 00:e0:18:3a:db:1a. 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller eth0.7: add 01:00:5e:00:00:01 mcast address to master interface eth0.8: add 01:00:5e:00:00:01 mcast address to master interface + cat /proc/net/vlan/config VLAN Dev name | VLAN ID Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD eth0.7 | 7 | eth0 eth0.8 | 8 | eth0 + cat /proc/net/vlan/eth0.7 eth0.7 VID: 7 REORDER_HDR: 1 dev->priv_flags: 1 total frames received: 192 total bytes received: 13276 Broadcast/Multicast Rcvd: 0 total frames transmitted: 231 total bytes transmitted: 41025 total headroom inc: 0 total encap on xmit: 231 Device: eth0 INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 EGRESSS priority Mappings: + cat /proc/net/vlan/eth0.8 eth0.8 VID: 8 REORDER_HDR: 1 dev->priv_flags: 1 total frames received: 99 total bytes received: 16978 Broadcast/Multicast Rcvd: 0 total frames transmitted: 137 total bytes transmitted: 14456 total headroom inc: 0 total encap on xmit: 137 Device: eth0 INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 EGRESSS priority Mappings: + /sbin/ifconfig -s -a Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 293 0 0 0 374 0 0 0 BMRU eth0.7 1500 0 194 0 0 0 234 0 0 0 BMRU eth0.8 1500 0 99 0 0 0 137 0 0 0 BMRU ippp2 1500 0 0 0 0 0 0 0 0 0 OPRU ippp6 1500 0 0 0 0 0 0 0 0 0 OPRU lo 16436 0 689 0 0 0 689 0 0 0 LRU + ping -c4 -s1466 joes PING joes.freakout.de (192.168.8.66) from 192.168.8.68 : 1466(1494) bytes of data. 1474 bytes from joes.freakout.de (192.168.8.66): icmp_seq=1 ttl=64 time=2.32 ms 1474 bytes from joes.freakout.de (192.168.8.66): icmp_seq=2 ttl=64 time=2.06 ms 1474 bytes from joes.freakout.de (192.168.8.66): icmp_seq=3 ttl=64 time=2.06 ms 1474 bytes from joes.freakout.de (192.168.8.66): icmp_seq=4 ttl=64 time=0.934 ms --- joes.freakout.de ping statistics --- 4 packets transmitted, 4 received, 0% loss, time 3024ms rtt min/avg/max/mdev = 0.934/1.848/2.326/0.540 ms + ping -c4 -s1468 joes PING joes.freakout.de (192.168.8.66) from 192.168.8.68 : 1468(1496) bytes of data. 1476 bytes from joes.freakout.de (192.168.8.66): icmp_seq=1 ttl=64 time=2.10 ms 1476 bytes from joes.freakout.de (192.168.8.66): icmp_seq=2 ttl=64 time=0.921 ms 1476 bytes from joes.freakout.de (192.168.8.66): icmp_seq=3 ttl=64 time=2.06 ms 1476 bytes from joes.freakout.de (192.168.8.66): icmp_seq=4 ttl=64 time=0.905 ms --- joes.freakout.de ping statistics --- 4 packets transmitted, 4 received, 0% loss, time 3029ms rtt min/avg/max/mdev = 0.905/1.498/2.103/0.587 ms + ping -c4 -s1470 joes PING joes.freakout.de (192.168.8.66) from 192.168.8.68 : 1470(1498) bytes of data. --- joes.freakout.de ping statistics --- 4 packets transmitted, 0 received, 100% loss, time 2999ms + ping -c4 -s1472 joes PING joes.freakout.de (192.168.8.66) from 192.168.8.68 : 1472(1500) bytes of data. --- joes.freakout.de ping statistics --- 2 packets transmitted, 0 received, 100% loss, time 1018ms + ping -c4 -s1474 joes PING joes.freakout.de (192.168.8.66) from 192.168.8.68 : 1474(1502) bytes of data. --- joes.freakout.de ping statistics --- 1 packets transmitted, 0 received, 100% loss, time 0ms -- |------------------------+--------------------------------------| | Axel Reinhold | Fax: +49-9287-8244 | | Franz-Heinrich-Str. 20 | eMail: axel@freakout.de | | 95100 Selb | http://www.freakout.de | | Germany | Please do not send more than 100 kilobytes | |------------------+--------------------------------------------| | Fingerprint: 8D EF 9F 22 DF 9A 9B 68 E5 8C 12 C7 8D 6A 97 4E | |---------------------------------------------------------------| | Legal Warning: Do NOT send unsolicited commercial email to me | From johnpol@2ka.mipt.ru Sat May 14 06:41:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 06:41:11 -0700 (PDT) Received: from localhost.localdomain (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4EDf5Ov017521 for ; Sat, 14 May 2005 06:41:06 -0700 Received: from localhost.localdomain (uganda [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j4EDmZMR002804; Sat, 14 May 2005 17:48:35 +0400 Received: (from s0mbre@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j4EDmZ3K002803; Sat, 14 May 2005 17:48:35 +0400 X-Authentication-Warning: localhost.localdomain: s0mbre set sender to johnpol@2ka.mipt.ru using -f Date: Sat, 14 May 2005 17:48:35 +0400 From: Evgeniy Polyakov To: netdev@oss.sgi.com Cc: "David S. Miller" Subject: [1/1] xfrm: skb_cow_data() does not set proper owner for new skbs. Message-ID: <20050514134834.GA2698@uganda.factory.vocord.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 1119 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1099 Lines: 32 It looks like skb_cow_data() does not set proper owner for newly created skb. If we have several fragments for skb and some of them are shared(?) or cloned (like in async IPsec) there might be a situation when we require recreating skb and thus using skb_copy() for it. Newly created skb has neither a destructor nor a socket assotiated with it, which must be copied from the old skb. As far as I can see, current code sets destructor and socket for the first one skb only and uses truesize of the first skb only to increment sk_wmem_alloc value. If above "analysis" is correct then attached patch fixes that. Signed-off-by: Evgeniy Polyakov --- ./net/xfrm/xfrm_algo.c~ 2005-04-27 12:08:59.000000000 +0400 +++ ./net/xfrm/xfrm_algo.c 2005-05-14 17:36:52.000000000 +0400 @@ -698,7 +698,7 @@ return -ENOMEM; if (skb1->sk) - skb_set_owner_w(skb, skb1->sk); + skb_set_owner_w(skb2, skb1->sk); /* Looking around. Are we still alive? * OK, link new skb, drop old one */ -- Evgeniy Polyakov Crash is better than data corruption. -- Artur Grabowski From jgarzik@pobox.com Sat May 14 07:03:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 07:03:26 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4EE3MOv018615 for ; Sat, 14 May 2005 07:03:23 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DWxE6-0004rx-H7; Sat, 14 May 2005 14:02:47 +0000 Message-ID: <42860502.6090808@pobox.com> Date: Sat, 14 May 2005 10:02:42 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krzysztof Halasa CC: Netdev , Linux Kernel Subject: Re: git repository for net drivers available References: <42841A3F.7020909@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1120 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 559 Lines: 23 Krzysztof Halasa wrote: > Hi, > > Jeff Garzik writes: > > >>Although I have over 200 net driver patches to go through in my >>'Pending' folder, I have fully converted the existing netdev-2.6 >>repository from BitKeeper to git. This includes the wireless-2.6 >>repository. > > > Do you prefer plain patches or GIT repository on kernel.org to merge > for future (and "current") updates? > I haven't set a public repo up yet, but it's a matter of seconds. For now, plain patches. FWIW, I do still have your WAN update patch. Jeff From hch@lst.de Sat May 14 09:08:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 09:08:50 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4EG8lOv027057 for ; Sat, 14 May 2005 09:08:47 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4EFV06t003999 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 14 May 2005 17:31:00 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j4EFV0NI003997; Sat, 14 May 2005 17:31:00 +0200 Date: Sat, 14 May 2005 17:31:00 +0200 From: Christoph Hellwig To: jgarzik@pobox.com, proski@gnu.org, hermes@gibson.dropbear.id.au Cc: netdev@oss.sgi.com Subject: [PATCH 11/12] orinoco: monitor mode support Message-ID: <20050514153100.GL3643@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1130 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 7540 Lines: 274 Patch from Pavel Roskin Index: linux-2.6/drivers/net/wireless/orinoco.c =================================================================== --- linux-2.6.orig/drivers/net/wireless/orinoco.c 2005-05-14 17:07:45.000000000 +0200 +++ linux-2.6/drivers/net/wireless/orinoco.c 2005-05-14 17:08:39.000000000 +0200 @@ -499,6 +499,10 @@ module_param(ignore_disconnect, int, 0644); MODULE_PARM_DESC(ignore_disconnect, "Don't report lost link to the network layer"); +static int force_monitor; /* = 0 */ +module_param(force_monitor, int, 0644); +MODULE_PARM_DESC(force_monitor, "Allow monitor mode for all firmware versions"); + /********************************************************************/ /* Compile time configuration and compatibility stuff */ /********************************************************************/ @@ -670,6 +674,10 @@ priv->createibss = 1; } break; + case IW_MODE_MONITOR: + priv->port_type = 3; + priv->createibss = 0; + break; default: printk(KERN_ERR "%s: Invalid priv->iw_mode in set_port_type()\n", priv->ndev->name); @@ -856,7 +864,7 @@ return 1; } - if (! netif_carrier_ok(dev)) { + if (! netif_carrier_ok(dev) || (priv->iw_mode == IW_MODE_MONITOR)) { /* Oops, the firmware hasn't established a connection, silently drop the packet (this seems to be the safest approach). */ @@ -1118,6 +1126,114 @@ } } +/* + * orinoco_rx_monitor - handle received monitor frames. + * + * Arguments: + * dev network device + * rxfid received FID + * desc rx descriptor of the frame + * + * Call context: interrupt + */ +static void orinoco_rx_monitor(struct net_device *dev, u16 rxfid, + struct hermes_rx_descriptor *desc) +{ + u32 hdrlen = 30; /* return full header by default */ + u32 datalen = 0; + u16 fc; + int err; + int len; + struct sk_buff *skb; + struct orinoco_private *priv = netdev_priv(dev); + struct net_device_stats *stats = &priv->stats; + hermes_t *hw = &priv->hw; + + len = le16_to_cpu(desc->data_len); + + /* Determine the size of the header and the data */ + fc = le16_to_cpu(desc->frame_ctl); + switch (fc & IEEE80211_FCTL_FTYPE) { + case IEEE80211_FTYPE_DATA: + if ((fc & IEEE80211_FCTL_TODS) + && (fc & IEEE80211_FCTL_FROMDS)) + hdrlen = 30; + else + hdrlen = 24; + datalen = len; + break; + case IEEE80211_FTYPE_MGMT: + hdrlen = 24; + datalen = len; + break; + case IEEE80211_FTYPE_CTL: + switch (fc & IEEE80211_FCTL_STYPE) { + case IEEE80211_STYPE_PSPOLL: + case IEEE80211_STYPE_RTS: + case IEEE80211_STYPE_CFEND: + case IEEE80211_STYPE_CFENDACK: + hdrlen = 16; + break; + case IEEE80211_STYPE_CTS: + case IEEE80211_STYPE_ACK: + hdrlen = 10; + break; + } + break; + default: + /* Unknown frame type */ + break; + } + + /* sanity check the length */ + if (datalen > IEEE80211_DATA_LEN + 12) { + printk(KERN_DEBUG "%s: oversized monitor frame, " + "data length = %d\n", dev->name, datalen); + err = -EIO; + goto drop; + } + + skb = dev_alloc_skb(hdrlen + datalen); + if (!skb) { + printk(KERN_WARNING "%s: Cannot allocate skb for monitor frame\n", + dev->name); + err = -ENOMEM; + goto drop; + } + + /* Copy the 802.11 header to the skb */ + memcpy(skb_put(skb, hdrlen), &(desc->frame_ctl), hdrlen); + skb->mac.raw = skb->data; + + /* If any, copy the data from the card to the skb */ + if (datalen > 0) { + err = hermes_bap_pread(hw, IRQ_BAP, skb_put(skb, datalen), + ALIGN(datalen, 2), rxfid, + HERMES_802_2_OFFSET); + if (err) { + printk(KERN_ERR "%s: error %d reading monitor frame\n", + dev->name, err); + goto drop; + } + } + + skb->dev = dev; + skb->ip_summed = CHECKSUM_NONE; + skb->pkt_type = PACKET_OTHERHOST; + skb->protocol = __constant_htons(ETH_P_802_2); + + dev->last_rx = jiffies; + stats->rx_packets++; + stats->rx_bytes += skb->len; + + netif_rx(skb); + return; + + drop: + stats->rx_errors++; + stats->rx_dropped++; +} + static void __orinoco_ev_rx(struct net_device *dev, hermes_t *hw) { struct orinoco_private *priv = netdev_priv(dev); @@ -1143,16 +1259,24 @@ status = le16_to_cpu(desc.status); - if (status & HERMES_RXSTAT_ERR) { - if (status & HERMES_RXSTAT_UNDECRYPTABLE) { - wstats->discard.code++; - DEBUG(1, "%s: Undecryptable frame on Rx. Frame dropped.\n", - dev->name); - } else { - stats->rx_crc_errors++; - DEBUG(1, "%s: Bad CRC on Rx. Frame dropped.\n", dev->name); - } + if (status & HERMES_RXSTAT_BADCRC) { + DEBUG(1, "%s: Bad CRC on Rx. Frame dropped.\n", + dev->name); + stats->rx_crc_errors++; + stats->rx_errors++; + goto drop; + } + /* Handle frames in monitor mode */ + if (priv->iw_mode == IW_MODE_MONITOR) { + orinoco_rx_monitor(dev, rxfid, &desc); + return; + } + + if (status & HERMES_RXSTAT_UNDECRYPTABLE) { + DEBUG(1, "%s: Undecryptable frame on Rx. Frame dropped.\n", + dev->name); + wstats->discard.code++; stats->rx_errors++; goto drop; } @@ -2065,6 +2189,20 @@ } } + if (priv->iw_mode == IW_MODE_MONITOR) { + /* Enable monitor mode */ + dev->type = ARPHRD_IEEE80211; + err = hermes_docmd_wait(hw, HERMES_CMD_TEST | + HERMES_TEST_MONITOR, 0, NULL); + } else { + /* Disable monitor mode */ + dev->type = ARPHRD_ETHER; + err = hermes_docmd_wait(hw, HERMES_CMD_TEST | + HERMES_TEST_STOP, 0, NULL); + } + if (err) + return err; + /* Set promiscuity / multicast*/ priv->promiscuous = 0; priv->mc_count = 0; @@ -2413,6 +2551,7 @@ priv->has_pm = (firmver >= 0x40020); /* Don't work in 7.52 ? */ priv->ibss_port = 1; priv->has_hostscan = (firmver >= 0x8000a); + priv->broken_monitor = (firmver >= 0x80000); /* Tested with Agere firmware : * 1.16 ; 4.08 ; 4.52 ; 6.04 ; 6.16 ; 7.28 => Jean II @@ -2980,6 +3119,15 @@ case IW_MODE_INFRA: break; + case IW_MODE_MONITOR: + if (priv->broken_monitor && !force_monitor) { + printk(KERN_WARNING "%s: Monitor mode support is " + "buggy in this firmware, not enabling\n", + dev->name); + err = -EOPNOTSUPP; + } + break; + default: err = -EOPNOTSUPP; break; @@ -3355,11 +3503,9 @@ unsigned long flags; int err = -EINPROGRESS; /* Call commit handler */ - /* We can only use this in Ad-Hoc demo mode to set the operating - * frequency, or in IBSS mode to set the frequency where the IBSS - * will be created - Jean II */ - if (priv->iw_mode != IW_MODE_ADHOC) - return -EOPNOTSUPP; + /* In infrastructure mode the AP sets the channel */ + if (priv->iw_mode == IW_MODE_INFRA) + return -EBUSY; if ( (frq->e == 0) && (frq->m <= 1000) ) { /* Setting by channel number */ @@ -3383,7 +3529,15 @@ if (orinoco_lock(priv, &flags) != 0) return -EBUSY; + priv->channel = chan; + if (priv->iw_mode == IW_MODE_MONITOR) { + /* Fast channel change - no commit if successful */ + hermes_t *hw = &priv->hw; + err = hermes_docmd_wait(hw, HERMES_CMD_TEST | + HERMES_TEST_SET_CHANNEL, + chan, NULL); + } orinoco_unlock(priv, &flags); return err; Index: linux-2.6/drivers/net/wireless/orinoco.h =================================================================== --- linux-2.6.orig/drivers/net/wireless/orinoco.h 2005-05-14 17:05:42.000000000 +0200 +++ linux-2.6/drivers/net/wireless/orinoco.h 2005-05-14 17:07:57.000000000 +0200 @@ -94,6 +94,7 @@ unsigned int has_sensitivity:1; unsigned int has_hostscan:1; unsigned int broken_disableport:1; + unsigned int broken_monitor:1; /* Configuration paramaters */ u32 iw_mode; From hch@lst.de Sat May 14 09:08:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 09:08:55 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4EG8lOx027057 for ; Sat, 14 May 2005 09:08:51 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4EFV56t004019 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 14 May 2005 17:31:05 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j4EFV5Ca004017; Sat, 14 May 2005 17:31:05 +0200 Date: Sat, 14 May 2005 17:31:04 +0200 From: Christoph Hellwig To: jgarzik@pobox.com, proski@gnu.org, hermes@gibson.dropbear.id.au Cc: netdev@oss.sgi.com Subject: [PATCH 12/12] orinoco: update changelog and version Message-ID: <20050514153104.GM3643@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1131 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 3230 Lines: 70 diff -urp -X /home/hch/dontdiff linux-2.6/drivers/net/wireless/orinoco.c orinoco/orinoco.c --- linux-2.6/drivers/net/wireless/orinoco.c 2005-05-14 13:49:02.000000000 +0200 +++ orinoco/orinoco.c 2005-05-14 13:05:46.000000000 +0200 @@ -416,12 +416,50 @@ * port. This is supposed to allow 802.1x to work sanely, but * doesn't seem to yet. * + * v0.14alpha2 -> v0.15rc1 - 19 Apr 2004 - Pavel Roskin & David Gibson + * o Fix bug which prevented setting 32 character ESSIDs from + * iwconfig (Thomas Schulz). + * o Fix for incorrect CIS access in orinoco_plx (Pavel Roskin). + * o Fix setting WEP key if __orinoco_fastkeychange() is not + * supported (Pavel Roskin). + * o New wireless extensions API and scanning support (patch from + * Moustafa Youssef, updated by Jim Carter and Pavel Roskin). + * o Add minimal ethtool support (Pavel Roskin). + * o Replace CardServices() calls for compatibility with Linux + * 2.6.2 and above (Pavel Roskin). + * o Fix recognition of Intersil x.x.1 firmware (Pavel Roskin). + * o Replace dump_recs with more flexible get_rid ioctl (Pavel + * Roskin). + * o RF monitor mode support (Pavel Roskin). + * o Lots of bugfixes. + * + * v0.15rc1 -> v0.15rc2 - 28 Jul 2004 - Pavel Roskin & David Gibson + * o orinoco_pci saves PCI registers on suspend (Simon Huggins). + * o Monitor mode disabled on Agere 8.xx firmware - it's broken. + * o BAP timeout increased - needed for Intersil firmware. + * o Tx power is no longer reported - it's unreliable. + * o Use 802.11 header in rx path. Hide packets with ToDS flag + * from programs that don't need promiscous mode (John Denker). + * o Manual roaming implemented for Symbol and Intersil firmware. + * o Use netdev_priv() instead of directly dereferencing dev->priv. + * o Some simplification of pcmcia init code in orinoco_cs and + * spectrum_cs. + * o Numerous trivial cleanups, mainly arising from long-overdue + * merge with mainline. + * + * v0.15rc2 -> ???? - ???? - David Gibson + * o Use ssleep() or msleep() instead of hardcoded + * schedule_timeout()s (Nishanth Aravamudan via kernel-janitors + * list). + * o Several cleanups and bugfixes in pci/plx/tmd/nortel drivers. + * o Fix memory leak in orinoco_join_ap(). + * o Change io handling to avoid sparse and gcc warnings. + * o Use C99 array initializers and ARRAY_SIZE() for iw_handler + * tables. + * * TODO - * o New wireless extensions API (patch from Moustafa - * Youssef, updated by Jim Carter and Pavel Roskin). * o Handle de-encapsulation within network layer, provide 802.11 * headers (patch from Thomas 'Dent' Mirlacher) - * o RF monitor mode support * o Fix possible races in SPY handling. * o Disconnect wireless extensions from fundamental configuration. * o (maybe) Software WEP support (patch from Stano Meduna). diff -urp -X /home/hch/dontdiff linux-2.6/drivers/net/wireless/orinoco.h orinoco/orinoco.h --- linux-2.6/drivers/net/wireless/orinoco.h 2005-05-14 13:48:44.000000000 +0200 +++ orinoco/orinoco.h 2005-03-18 16:03:24.000000000 +0100 @@ -7,7 +7,7 @@ #ifndef _ORINOCO_H #define _ORINOCO_H -#define DRIVER_VERSION "0.14alpha2" +#define DRIVER_VERSION "0.15rc2" #include #include From hch@lst.de Sat May 14 09:08:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 09:08:56 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4EG8lP1027057 for ; Sat, 14 May 2005 09:08:53 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4EFUs6t003983 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 14 May 2005 17:30:54 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j4EFUrMd003981; Sat, 14 May 2005 17:30:53 +0200 Date: Sat, 14 May 2005 17:30:53 +0200 From: Christoph Hellwig To: jgarzik@pobox.com, proski@gnu.org, hermes@gibson.dropbear.id.au Cc: netdev@oss.sgi.com Subject: [PATCH 10/12] orinoco: always use 802.11 header for rx processing Message-ID: <20050514153053.GK3643@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1132 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 5678 Lines: 185 If the frame has ToDS flag set, mark it by setting skb->pkt_type to PACKET_OTHERHOST, so that applications unaware of promiscous mode won't get uplink (STA->AP) packets for STA->STA transmissions relayed by the AP. Thanks to John Denker and David Gibson for finding the problem and the solution. Patch from Pavel Roskin Index: linux-2.6/drivers/net/wireless/orinoco.c =================================================================== --- linux-2.6.orig/drivers/net/wireless/orinoco.c 2005-05-14 17:07:00.000000000 +0200 +++ linux-2.6/drivers/net/wireless/orinoco.c 2005-05-14 17:07:45.000000000 +0200 @@ -619,7 +619,9 @@ u16 ethertype; } __attribute__ ((packed)); +/* Rx frame header except compatibility 802.3 header */ struct hermes_rx_descriptor { + /* Control */ u16 status; u32 time; u8 silence; @@ -627,6 +629,18 @@ u8 rate; u8 rxflow; u32 reserved; + + /* 802.11 header */ + u16 frame_ctl; + u16 duration_id; + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + u8 addr3[ETH_ALEN]; + u16 seq_ctl; + u8 addr4[ETH_ALEN]; + + /* Data length */ + u16 data_len; } __attribute__ ((packed)); /********************************************************************/ @@ -1110,12 +1124,10 @@ struct net_device_stats *stats = &priv->stats; struct iw_statistics *wstats = &priv->wstats; struct sk_buff *skb = NULL; - u16 rxfid, status; - int length, data_len, data_off; - char *p; + u16 rxfid, status, fc; + int length; struct hermes_rx_descriptor desc; - struct header_struct hdr; - struct ethhdr *eh; + struct ethhdr *hdr; int err; rxfid = hermes_read_regn(hw, RXFID); @@ -1140,24 +1152,14 @@ stats->rx_crc_errors++; DEBUG(1, "%s: Bad CRC on Rx. Frame dropped.\n", dev->name); } - stats->rx_errors++; - goto drop; - } - - /* For now we ignore the 802.11 header completely, assuming - that the card's firmware has handled anything vital */ - err = hermes_bap_pread(hw, IRQ_BAP, &hdr, sizeof(hdr), - rxfid, HERMES_802_3_OFFSET); - if (err) { - printk(KERN_ERR "%s: error %d reading frame header. " - "Frame dropped.\n", dev->name, err); stats->rx_errors++; goto drop; } - length = ntohs(hdr.len); - + length = le16_to_cpu(desc.data_len); + fc = le16_to_cpu(desc.frame_ctl); + /* Sanity checks */ if (length < 3) { /* No for even an 802.2 LLC header */ /* At least on Symbol firmware with PCF we get quite a @@ -1186,57 +1188,51 @@ goto drop; } - skb_reserve(skb, 2); /* This way the IP header is aligned */ + /* We'll prepend the header, so reserve space for it. The worst + case is no decapsulation, when 802.3 header is prepended and + nothing is removed. 2 is for aligning the IP header. */ + skb_reserve(skb, ETH_HLEN + 2); + + err = hermes_bap_pread(hw, IRQ_BAP, skb_put(skb, length), + ALIGN(length, 2), rxfid, + HERMES_802_2_OFFSET); + if (err) { + printk(KERN_ERR "%s: error %d reading frame. " + "Frame dropped.\n", dev->name, err); + stats->rx_errors++; + goto drop; + } /* Handle decapsulation * In most cases, the firmware tell us about SNAP frames. * For some reason, the SNAP frames sent by LinkSys APs * are not properly recognised by most firmwares. * So, check ourselves */ - if (((status & HERMES_RXSTAT_MSGTYPE) == HERMES_RXSTAT_1042) || - ((status & HERMES_RXSTAT_MSGTYPE) == HERMES_RXSTAT_TUNNEL) || - is_ethersnap(&hdr)) { + if (length >= ENCAPS_OVERHEAD && + (((status & HERMES_RXSTAT_MSGTYPE) == HERMES_RXSTAT_1042) || + ((status & HERMES_RXSTAT_MSGTYPE) == HERMES_RXSTAT_TUNNEL) || + is_ethersnap(skb->data))) { /* These indicate a SNAP within 802.2 LLC within 802.11 frame which we'll need to de-encapsulate to the original EthernetII frame. */ - - if (length < ENCAPS_OVERHEAD) { /* No room for full LLC+SNAP */ - stats->rx_length_errors++; - goto drop; - } - - /* Remove SNAP header, reconstruct EthernetII frame */ - data_len = length - ENCAPS_OVERHEAD; - data_off = HERMES_802_3_OFFSET + sizeof(hdr); - - eh = (struct ethhdr *)skb_put(skb, ETH_HLEN); - - memcpy(eh, &hdr, 2 * ETH_ALEN); - eh->h_proto = hdr.ethertype; + hdr = (struct ethhdr *)skb_push(skb, ETH_HLEN - ENCAPS_OVERHEAD); } else { - /* All other cases indicate a genuine 802.3 frame. No - decapsulation needed. We just throw the whole - thing in, and hope the protocol layer can deal with - it as 802.3 */ - data_len = length; - data_off = HERMES_802_3_OFFSET; - /* FIXME: we re-read from the card data we already read here */ - } - - p = skb_put(skb, data_len); - err = hermes_bap_pread(hw, IRQ_BAP, p, ALIGN(data_len, 2), - rxfid, data_off); - if (err) { - printk(KERN_ERR "%s: error %d reading frame. " - "Frame dropped.\n", dev->name, err); - stats->rx_errors++; - goto drop; - } + /* 802.3 frame - prepend 802.3 header as is */ + hdr = (struct ethhdr *)skb_push(skb, ETH_HLEN); + hdr->h_proto = htons(length); + } + memcpy(hdr->h_dest, desc.addr1, ETH_ALEN); + if (fc & IEEE80211_FCTL_FROMDS) + memcpy(hdr->h_source, desc.addr3, ETH_ALEN); + else + memcpy(hdr->h_source, desc.addr2, ETH_ALEN); dev->last_rx = jiffies; skb->dev = dev; skb->protocol = eth_type_trans(skb, dev); skb->ip_summed = CHECKSUM_NONE; + if (fc & IEEE80211_FCTL_TODS) + skb->pkt_type = PACKET_OTHERHOST; /* Process the wireless stats if needed */ orinoco_stat_gather(dev, skb, &desc); @@ -1457,6 +1453,9 @@ u16 newstatus; int connected; + if (priv->iw_mode == IW_MODE_MONITOR) + break; + if (len != sizeof(linkstatus)) { printk(KERN_WARNING "%s: Unexpected size for linkstatus frame (%d bytes)\n", dev->name, len); From romieu@fr.zoreil.com Sat May 14 10:43:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 14 May 2005 10:43:39 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4EHhZOv031283 for ; Sat, 14 May 2005 10:43:36 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4EHds23032356; Sat, 14 May 2005 19:39:54 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4EHdlRf032355; Sat, 14 May 2005 19:39:47 +0200 Date: Sat, 14 May 2005 19:39:47 +0200 From: Francois Romieu To: Christoph Hellwig Cc: jgarzik@pobox.com, proski@gnu.org, hermes@gibson.dropbear.id.au, netdev@oss.sgi.com Subject: Re: [PATCH 11/12] orinoco: monitor mode support Message-ID: <20050514173947.GA32235@electric-eye.fr.zoreil.com> References: <20050514153100.GL3643@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050514153100.GL3643@lst.de> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1133 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 822 Lines: 33 Christoph Hellwig : [...] > + skb = dev_alloc_skb(hdrlen + datalen); > + if (!skb) { > + printk(KERN_WARNING "%s: Cannot allocate skb for monitor frame\n", > + dev->name); > + err = -ENOMEM; > + goto drop; > + } > + > + /* Copy the 802.11 header to the skb */ > + memcpy(skb_put(skb, hdrlen), &(desc->frame_ctl), hdrlen); > + skb->mac.raw = skb->data; > + > + /* If any, copy the data from the card to the skb */ > + if (datalen > 0) { > + err = hermes_bap_pread(hw, IRQ_BAP, skb_put(skb, datalen), > + ALIGN(datalen, 2), rxfid, > + HERMES_802_2_OFFSET); > + if (err) { > + printk(KERN_ERR "%s: error %d reading monitor frame\n", > + dev->name, err); > + goto drop; [...] > + drop: > + stats->rx_errors++; > + stats->rx_dropped++; > +} -> leak (skb). -- Ueimor From herbert@gondor.apana.org.au Sun May 15 01:02:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 01:02:08 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4F820Ov007501 for ; Sun, 15 May 2005 01:02:01 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXE3q-0003p7-00; Sun, 15 May 2005 18:01:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXE3h-0002jR-00; Sun, 15 May 2005 18:01:09 +1000 From: Herbert Xu To: johnpol@2ka.mipt.ru (Evgeniy Polyakov) Subject: Re: [1/1] xfrm: skb_cow_data() does not set proper owner for new skbs. Cc: netdev@oss.sgi.com, davem@davemloft.net Organization: Core In-Reply-To: <20050514134834.GA2698@uganda.factory.vocord.ru> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sun, 15 May 2005 18:01:09 +1000 X-archive-position: 1134 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 963 Lines: 26 Evgeniy Polyakov wrote: > > As far as I can see, current code sets destructor and socket > for the first one skb only and uses truesize of the first skb > only to increment sk_wmem_alloc value. > > If above "analysis" is correct then attached patch fixes that. Yes you're absolutely right. > Signed-off-by: Evgeniy Polyakov Acked-by: Herbert Xu In fact you've uncovered a couple of bugs elsewhere too. IPv4's ip_push_pending_frames attributes all the data to the first skb which breaks when the packet is sent through ip_fragment since the latter does not undo the truesize attribution. skb_linearize is broken as well since it ignores truesize/owner altogether. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bunk@stusta.de Sun May 15 01:28:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 01:28:10 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4F8RuOv008668 for ; Sun, 15 May 2005 01:28:01 -0700 Received: (qmail 20307 invoked from network); 15 May 2005 08:27:10 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 15 May 2005 08:27:10 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 319F4BBA1B; Sun, 15 May 2005 10:27:07 +0200 (CEST) Date: Sun, 15 May 2005 10:27:06 +0200 From: Adrian Bunk To: Andres Salomon Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Status of net/ipv4/ipvs/ip_vs_proto_icmp.c? Message-ID: <20050515082706.GK16549@stusta.de> References: <20050513041622.GE3603@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-archive-position: 1135 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 932 Lines: 39 On Fri, May 13, 2005 at 03:09:01PM -0400, Andres Salomon wrote: > On Fri, 13 May 2005 06:16:22 +0200, Adrian Bunk wrote: > > > Hi, > > > > can anyone explain the status of? > > > > This file is always included in the kernel if CONFIG_IP_VS=y, but it's > > completely unused. > > > > Will it be made working in the forseeable future or is it a candidate > > for removal? > > > > TIA > > Adrian > > The people/places to ask would probably be: > > IPVS > P: Wensong Zhang > M: wensong@linux-vs.org > P: Julian Anastasov > M: ja@ssi.bg > S: Maintained >... And these are exactly the people in the To-header of the email asking this question. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From herbert@gondor.apana.org.au Sun May 15 03:40:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 03:41:05 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FAevOv012735 for ; Sun, 15 May 2005 03:40:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXGXi-0004VA-00; Sun, 15 May 2005 20:40:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXGXg-0006L0-00; Sun, 15 May 2005 20:40:16 +1000 Date: Sun, 15 May 2005 20:40:16 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames Message-ID: <20050515104016.GA24344@gondor.apana.org.au> References: <20050514134834.GA2698@uganda.factory.vocord.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1136 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2623 Lines: 75 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, May 15, 2005 at 06:01:09PM +1000, Herbert Xu wrote: > > In fact you've uncovered a couple of bugs elsewhere too. IPv4's > ip_push_pending_frames attributes all the data to the first skb > which breaks when the packet is sent through ip_fragment since > the latter does not undo the truesize attribution. skb_linearize > is broken as well since it ignores truesize/owner altogether. Here is a patch that addresses the first issue. Since frag_list skb's constructed by ip*_push_pending_frames are usually going to be fragmented in ip*_fragment and sent separately, it makes no sense to account them all in the head skb. Doing so means that ip*_fragment would have to undo it all in order to keep the correct wmem accounting. In fact as it is IPv4 is attributing all the memory to the head skb in ip_push_pending_frames and not undoing the attribution correctly in ip_fragment. On the fast path it will not undo the work at all which means that as soon as the head skb is transmitted the quota which may still be used by the other skb's can be used by new data. On the slow path it double-charges the skb's which may unnecssarily delay new data from being sent. This patch simply leaves the wmem accounting with each skb. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -1138,10 +1138,6 @@ int ip_push_pending_frames(struct sock * tail_skb = &(tmp_skb->next); skb->len += tmp_skb->len; skb->data_len += tmp_skb->len; - skb->truesize += tmp_skb->truesize; - __sock_put(tmp_skb->sk); - tmp_skb->destructor = NULL; - tmp_skb->sk = NULL; } /* Unless user demanded real pmtu discovery (IP_PMTUDISC_DO), we allow --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1116,12 +1116,6 @@ int ip6_push_pending_frames(struct sock tail_skb = &(tmp_skb->next); skb->len += tmp_skb->len; skb->data_len += tmp_skb->len; -#if 0 /* Logically correct, but useless work, ip_fragment() will have to undo */ - skb->truesize += tmp_skb->truesize; - __sock_put(tmp_skb->sk); - tmp_skb->destructor = NULL; - tmp_skb->sk = NULL; -#endif } ipv6_addr_copy(final_dst, &fl->fl6_dst); --envbJBWh7q8WU6mo-- From herbert@gondor.apana.org.au Sun May 15 04:42:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 04:42:13 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FBg4Ov018977 for ; Sun, 15 May 2005 04:42:05 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXHUq-0004p0-00; Sun, 15 May 2005 21:41:24 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXHUn-0001HD-00; Sun, 15 May 2005 21:41:21 +1000 Date: Sun, 15 May 2005 21:41:21 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames Message-ID: <20050515114121.GA4830@gondor.apana.org.au> References: <20050514134834.GA2698@uganda.factory.vocord.ru> <20050515104016.GA24344@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050515104016.GA24344@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1137 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1656 Lines: 41 On Sun, May 15, 2005 at 08:40:16PM +1000, herbert wrote: Please discard this patch. > Since frag_list skb's constructed by ip*_push_pending_frames are > usually going to be fragmented in ip*_fragment and sent separately, > it makes no sense to account them all in the head skb. Doing so > means that ip*_fragment would have to undo it all in order to keep > the correct wmem accounting. Unfortunately this leads to nightmares with partially cloned frag skb's. The reason is that once you unleash a skb with a frag_list that has individual sk ownerships into the stack you can never undo those ownerships safely as they may have been cloned by things like netfilter. Since we have to undo them in order to make skb_linearize happy this approach leads to a dead-end. So let's go the other way and make this an invariant: For any skb on a frag_list, skb->sk must be NULL. That is, the socket ownership always belongs to the head skb. It turns out that the implementation is actually pretty simple. > On the slow path it double-charges the skb's which may unnecssarily > delay new data from being sent. Especially because I was wrong about this. The slow paths in ip*_fragment is actually correct since it frees the original skb after constructing the new fragments. I'll post a new patch soon. However, since this is a pretty major change and the bugs it fixes aren't that important it should probably be delayed until 2.6.13. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bunk@stusta.de Sun May 15 05:12:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 05:13:01 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4FCCvOv020482 for ; Sun, 15 May 2005 05:12:58 -0700 Received: (qmail 24965 invoked from network); 15 May 2005 12:12:26 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 15 May 2005 12:12:26 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id DD9B1BB5FB; Sun, 15 May 2005 14:12:22 +0200 (CEST) Date: Sun, 15 May 2005 14:12:22 +0200 From: Adrian Bunk To: Jeff Garzik Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC: 2.6 patch] make MII no longer user visible Message-ID: <20050515121222.GR16549@stusta.de> References: <20050513035257.GC3603@stusta.de> <4284DD16.8090405@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4284DD16.8090405@pobox.com> User-Agent: Mutt/1.5.9i X-archive-position: 1138 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 797 Lines: 28 On Fri, May 13, 2005 at 01:00:06PM -0400, Jeff Garzik wrote: > Adrian Bunk wrote: > >MII is a classical example of a helper option no user should ever see. > > Incorrect. > > It's the classic example of an option that distributors may want to > build as a module, even if no shipped modules need it, to enable net > driver development and use in their kernel. Every distibutor will have more than one net driver select'ing MII enabled. And if you are doing net driver development, you can always enable it in your kernel. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From herbert@gondor.apana.org.au Sun May 15 05:23:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 05:23:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FCNbOv021299 for ; Sun, 15 May 2005 05:23:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXI95-00056o-00; Sun, 15 May 2005 22:22:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXI92-0005nA-00; Sun, 15 May 2005 22:22:56 +1000 Date: Sun, 15 May 2005 22:22:56 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: [IPV4/IPV6] Ensure all frag_list members have NULL sk Message-ID: <20050515122256.GA22251@gondor.apana.org.au> References: <20050514134834.GA2698@uganda.factory.vocord.ru> <20050515104016.GA24344@gondor.apana.org.au> <20050515114121.GA4830@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <20050515114121.GA4830@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1139 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3045 Lines: 103 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, May 15, 2005 at 09:41:21PM +1000, herbert wrote: > > I'll post a new patch soon. However, since this is a pretty major change > and the bugs it fixes aren't that important it should probably be delayed > until 2.6.13. Here it is: Having frag_list members which holds wmem of an sk leads to nightmares with partially cloned frag skb's. The reason is that once you unleash a skb with a frag_list that has individual sk ownerships into the stack you can never undo those ownerships safely as they may have been cloned by things like netfilter. Since we have to undo them in order to make skb_linearize happy this approach leads to a dead-end. So let's go the other way and make this an invariant: For any skb on a frag_list, skb->sk must be NULL. That is, the socket ownership always belongs to the head skb. It turns out that the implementation is actually pretty simple. The above invariant is actually violated in the following patch for a short duration inside ip_fragment. This is OK because the offending frag_list member is either destroyed at the end of the slow path without being sent anywhere, or it is detached from the frag_list before being sent. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -490,6 +490,14 @@ int ip_fragment(struct sk_buff *skb, int /* Partially cloned skb? */ if (skb_shared(frag)) goto slow_path; + + BUG_ON(frag->sk); + if (skb->sk) { + sock_hold(skb->sk); + frag->sk = skb->sk; + frag->destructor = sock_wfree; + skb->truesize -= frag->truesize; + } } /* Everything is OK. Generate! */ --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -552,13 +552,17 @@ static int ip6_fragment(struct sk_buff * skb_headroom(frag) < hlen) goto slow_path; - /* Correct socket ownership. */ - if (frag->sk == NULL) - goto slow_path; - /* Partially cloned skb? */ if (skb_shared(frag)) goto slow_path; + + BUG_ON(frag->sk); + if (skb->sk) { + sock_hold(skb->sk); + frag->sk = skb->sk; + frag->destructor = sock_wfree; + skb->truesize -= frag->truesize; + } } err = 0; @@ -1116,12 +1120,10 @@ int ip6_push_pending_frames(struct sock tail_skb = &(tmp_skb->next); skb->len += tmp_skb->len; skb->data_len += tmp_skb->len; -#if 0 /* Logically correct, but useless work, ip_fragment() will have to undo */ skb->truesize += tmp_skb->truesize; __sock_put(tmp_skb->sk); tmp_skb->destructor = NULL; tmp_skb->sk = NULL; -#endif } ipv6_addr_copy(final_dst, &fl->fl6_dst); --h31gzZEtNLTqOjlF-- From bunk@stusta.de Sun May 15 06:29:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 06:29:56 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4FDTiOv024148 for ; Sun, 15 May 2005 06:29:45 -0700 Received: (qmail 26518 invoked from network); 15 May 2005 13:29:10 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 15 May 2005 13:29:10 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id A913DBB792; Sun, 15 May 2005 15:29:06 +0200 (CEST) Date: Sun, 15 May 2005 15:29:06 +0200 From: Adrian Bunk To: Julian Anastasov Cc: Wensong Zhang , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] remove net/ipv4/ipvs/ip_vs_proto_icmp.c? Message-ID: <20050515132906.GW16549@stusta.de> References: <20050513041622.GE3603@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-archive-position: 1140 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 6029 Lines: 246 On Sat, May 14, 2005 at 10:17:53AM +0300, Julian Anastasov wrote: > > Hello, > > On Fri, 13 May 2005, Adrian Bunk wrote: > > > Will it be made working in the forseeable future or is it a candidate > > for removal? > > IMO, it can be removed as it was never finished. We can always > add it later. Thanks for the confirmation. A patch to remove it is below. > Regards > Julian Anastasov cu Adrian <-- snip --> ip_vs_proto_icmp.c was never finished. Signed-off-by: Adrian Bunk --- net/ipv4/ipvs/Makefile | 2 net/ipv4/ipvs/ip_vs_proto.c | 3 net/ipv4/ipvs/ip_vs_proto_icmp.c | 182 ------------------------------- 3 files changed, 1 insertion(+), 186 deletions(-) --- linux-2.6.12-rc4-mm1-full/net/ipv4/ipvs/Makefile.old 2005-05-15 13:14:02.000000000 +0200 +++ linux-2.6.12-rc4-mm1-full/net/ipv4/ipvs/Makefile 2005-05-15 13:14:17.000000000 +0200 @@ -11,7 +11,7 @@ ip_vs-objs := ip_vs_conn.o ip_vs_core.o ip_vs_ctl.o ip_vs_sched.o \ ip_vs_xmit.o ip_vs_app.o ip_vs_sync.o \ - ip_vs_est.o ip_vs_proto.o ip_vs_proto_icmp.o \ + ip_vs_est.o ip_vs_proto.o \ $(ip_vs_proto-objs-y) --- linux-2.6.12-rc4-mm1-full/net/ipv4/ipvs/ip_vs_proto.c.old 2005-05-15 13:18:55.000000000 +0200 +++ linux-2.6.12-rc4-mm1-full/net/ipv4/ipvs/ip_vs_proto.c 2005-05-15 13:15:03.000000000 +0200 @@ -216,9 +216,6 @@ #ifdef CONFIG_IP_VS_PROTO_UDP REGISTER_PROTOCOL(&ip_vs_protocol_udp); #endif -#ifdef CONFIG_IP_VS_PROTO_ICMP - REGISTER_PROTOCOL(&ip_vs_protocol_icmp); -#endif #ifdef CONFIG_IP_VS_PROTO_AH REGISTER_PROTOCOL(&ip_vs_protocol_ah); #endif --- linux-2.6.12-rc4-mm1-full/net/ipv4/ipvs/ip_vs_proto_icmp.c 2005-03-02 08:37:31.000000000 +0100 +++ /dev/null 2005-04-28 03:52:17.000000000 +0200 @@ -1,182 +0,0 @@ -/* - * ip_vs_proto_icmp.c: ICMP load balancing support for IP Virtual Server - * - * Authors: Julian Anastasov , March 2002 - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * version 2 as published by the Free Software Foundation; - * - */ - -#include -#include -#include -#include -#include - -#include - - -static int icmp_timeouts[1] = { 1*60*HZ }; - -static char * icmp_state_name_table[1] = { "ICMP" }; - -static struct ip_vs_conn * -icmp_conn_in_get(const struct sk_buff *skb, - struct ip_vs_protocol *pp, - const struct iphdr *iph, - unsigned int proto_off, - int inverse) -{ -#if 0 - struct ip_vs_conn *cp; - - if (likely(!inverse)) { - cp = ip_vs_conn_in_get(iph->protocol, - iph->saddr, 0, - iph->daddr, 0); - } else { - cp = ip_vs_conn_in_get(iph->protocol, - iph->daddr, 0, - iph->saddr, 0); - } - - return cp; - -#else - return NULL; -#endif -} - -static struct ip_vs_conn * -icmp_conn_out_get(const struct sk_buff *skb, - struct ip_vs_protocol *pp, - const struct iphdr *iph, - unsigned int proto_off, - int inverse) -{ -#if 0 - struct ip_vs_conn *cp; - - if (likely(!inverse)) { - cp = ip_vs_conn_out_get(iph->protocol, - iph->saddr, 0, - iph->daddr, 0); - } else { - cp = ip_vs_conn_out_get(IPPROTO_UDP, - iph->daddr, 0, - iph->saddr, 0); - } - - return cp; -#else - return NULL; -#endif -} - -static int -icmp_conn_schedule(struct sk_buff *skb, struct ip_vs_protocol *pp, - int *verdict, struct ip_vs_conn **cpp) -{ - *verdict = NF_ACCEPT; - return 0; -} - -static int -icmp_csum_check(struct sk_buff *skb, struct ip_vs_protocol *pp) -{ - if (!(skb->nh.iph->frag_off & __constant_htons(IP_OFFSET))) { - if (skb->ip_summed != CHECKSUM_UNNECESSARY) { - if (ip_vs_checksum_complete(skb, skb->nh.iph->ihl * 4)) { - IP_VS_DBG_RL_PKT(0, pp, skb, 0, "Failed checksum for"); - return 0; - } - } - } - return 1; -} - -static void -icmp_debug_packet(struct ip_vs_protocol *pp, - const struct sk_buff *skb, - int offset, - const char *msg) -{ - char buf[256]; - struct iphdr _iph, *ih; - - ih = skb_header_pointer(skb, offset, sizeof(_iph), &_iph); - if (ih == NULL) - sprintf(buf, "%s TRUNCATED", pp->name); - else if (ih->frag_off & __constant_htons(IP_OFFSET)) - sprintf(buf, "%s %u.%u.%u.%u->%u.%u.%u.%u frag", - pp->name, NIPQUAD(ih->saddr), - NIPQUAD(ih->daddr)); - else { - struct icmphdr _icmph, *ic; - - ic = skb_header_pointer(skb, offset + ih->ihl*4, - sizeof(_icmph), &_icmph); - if (ic == NULL) - sprintf(buf, "%s TRUNCATED to %u bytes\n", - pp->name, skb->len - offset); - else - sprintf(buf, "%s %u.%u.%u.%u->%u.%u.%u.%u T:%d C:%d", - pp->name, NIPQUAD(ih->saddr), - NIPQUAD(ih->daddr), - ic->type, ic->code); - } - printk(KERN_DEBUG "IPVS: %s: %s\n", msg, buf); -} - -static int -icmp_state_transition(struct ip_vs_conn *cp, int direction, - const struct sk_buff *skb, - struct ip_vs_protocol *pp) -{ - cp->timeout = pp->timeout_table[IP_VS_ICMP_S_NORMAL]; - return 1; -} - -static int -icmp_set_state_timeout(struct ip_vs_protocol *pp, char *sname, int to) -{ - int num; - char **names; - - num = IP_VS_ICMP_S_LAST; - names = icmp_state_name_table; - return ip_vs_set_state_timeout(pp->timeout_table, num, names, sname, to); -} - - -static void icmp_init(struct ip_vs_protocol *pp) -{ - pp->timeout_table = icmp_timeouts; -} - -static void icmp_exit(struct ip_vs_protocol *pp) -{ -} - -struct ip_vs_protocol ip_vs_protocol_icmp = { - .name = "ICMP", - .protocol = IPPROTO_ICMP, - .dont_defrag = 0, - .init = icmp_init, - .exit = icmp_exit, - .conn_schedule = icmp_conn_schedule, - .conn_in_get = icmp_conn_in_get, - .conn_out_get = icmp_conn_out_get, - .snat_handler = NULL, - .dnat_handler = NULL, - .csum_check = icmp_csum_check, - .state_transition = icmp_state_transition, - .register_app = NULL, - .unregister_app = NULL, - .app_conn_bind = NULL, - .debug_packet = icmp_debug_packet, - .timeout_change = NULL, - .set_state_timeout = icmp_set_state_timeout, -}; From cranium2003@yahoo.com Sun May 15 06:40:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 06:40:12 -0700 (PDT) Received: from web41423.mail.yahoo.com (web41423.mail.yahoo.com [66.218.94.121]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4FDe6Ov024908 for ; Sun, 15 May 2005 06:40:06 -0700 Received: (qmail 77385 invoked by uid 60001); 15 May 2005 13:39:34 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=6U4kASgCUHWSzGcWxJK8gUaZW2UsjNFXdL7ee4aTpe6T/NvWxCpzG7iv+iKOhXO5T1sDhHp4jFCWGCg/TiA0QZrh5b1mXo2yEIPZ0gp5tICmg+2LY0AHmC575gA5Wm4YG05tow9411urXxOlwU89sogvrCq8ODEjWzTtrJBmXtQ= ; Message-ID: <20050515133934.77383.qmail@web41423.mail.yahoo.com> Received: from [203.145.159.37] by web41423.mail.yahoo.com via HTTP; Sun, 15 May 2005 06:39:34 PDT Date: Sun, 15 May 2005 06:39:34 -0700 (PDT) From: cranium2003 Subject: ip_forward difference in kernel 2.4 and 2.6 To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1141 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 568 Lines: 21 hello, I check kernel 2.4.28 and 2.6.11 on lxr and found that there is condition to check fragmnetation required for packet in 2.4.28 ain ip_forward.c as if (skb->len > mtu && (ntohs(iph->frag_off) & IP_DF)) goto frag_needed; But same will not be seen in 2.6.11 why? Then how 2.6 kenrel check this condition? Why its removed? Is it addedd somewhere else? Thanks in advance. regards, cranium __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From johnpol@2ka.mipt.ru Sun May 15 10:32:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 10:32:55 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FHWnOv002171 for ; Sun, 15 May 2005 10:32:50 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with ESMTP id j4FHVxwh022454; Sun, 15 May 2005 21:31:59 +0400 Date: Sun, 15 May 2005 21:33:41 +0400 From: Evgeniy Polyakov To: Herbert Xu Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [IPV4/IPV6] Ensure all frag_list members have NULL sk Message-ID: <20050515213341.4011c00e@zanzibar.2ka.mipt.ru> In-Reply-To: <20050515122256.GA22251@gondor.apana.org.au> References: <20050514134834.GA2698@uganda.factory.vocord.ru> <20050515104016.GA24344@gondor.apana.org.au> <20050515114121.GA4830@gondor.apana.org.au> <20050515122256.GA22251@gondor.apana.org.au> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Sun, 15 May 2005 21:31:59 +0400 (MSD) X-archive-position: 1142 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1861 Lines: 50 On Sun, 15 May 2005 22:22:56 +1000 Herbert Xu wrote: > On Sun, May 15, 2005 at 09:41:21PM +1000, herbert wrote: > > > > I'll post a new patch soon. However, since this is a pretty major change > > and the bugs it fixes aren't that important it should probably be delayed > > until 2.6.13. > > Here it is: > > > Having frag_list members which holds wmem of an sk leads to nightmares > with partially cloned frag skb's. The reason is that once you unleash > a skb with a frag_list that has individual sk ownerships into the stack > you can never undo those ownerships safely as they may have been cloned > by things like netfilter. Since we have to undo them in order to make > skb_linearize happy this approach leads to a dead-end. > > So let's go the other way and make this an invariant: > > For any skb on a frag_list, skb->sk must be NULL. This requires skb_set_owner_* to check if it is called for head skb or one from fragment and does nothing if it is from frag_list. Or to check the whole tree for ownering calls... > That is, the socket ownership always belongs to the head skb. > It turns out that the implementation is actually pretty simple. > > The above invariant is actually violated in the following patch > for a short duration inside ip_fragment. This is OK because the > offending frag_list member is either destroyed at the end of the > slow path without being sent anywhere, or it is detached from > the frag_list before being sent. > > Signed-off-by: Herbert Xu > > Cheers, > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From michaelc@cs.wisc.edu Sun May 15 12:30:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 12:30:49 -0700 (PDT) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FJUjOv009868 for ; Sun, 15 May 2005 12:30:45 -0700 Received: from [192.168.0.2] ([199.108.226.254]) (authenticated bits=0) by sabe.cs.wisc.edu (8.13.1/8.13.1) with ESMTP id j4FJUA83021357 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 15 May 2005 14:30:11 -0500 Subject: [PATCH 2/3] add open iscsi netlink interface to iscsi transport class From: Mike Christie To: open-iscsi@googlegroups.com, netdev@oss.sgi.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, inux-iscsi-devel@lists.sourceforge.netl.sgi.com Content-Type: text/plain Message-Id: <1116185405.17308.12.camel@mina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 15 May 2005 12:30:05 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 1144 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michaelc@cs.wisc.edu Precedence: bulk X-list: netdev Content-Length: 23333 Lines: 871 Common iSCSI header files: - iscsi_if.h (user/kernel #defines); - iscsi_proto.h (RFC3720 #defines and types); - iscsi_ifev.h (user/kernel events). Thanks, Linux-iscsi Team Signed-off-by: Alex Aizman Signed-off-by: Dmitry Yusupov Signed-off-by: Mike Christie diff -Naurp linux-2.6.12-rc4/include/scsi/iscsi_ifev.h linux-2.6.12-rc4.work/include/scsi/iscsi_ifev.h --- linux-2.6.12-rc4/include/scsi/iscsi_ifev.h 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.12-rc4.work/include/scsi/iscsi_ifev.h 2005-05-14 13:19:45.000000000 -0700 @@ -0,0 +1,121 @@ +/* + * iSCSI Kernel/User Interface Events + * + * Copyright (C) 2005 Dmitry Yusupov, Alex Aizman + * maintained by open-iscsi@googlegroups.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published + * by the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * See the file COPYING included with this distribution for more details. + */ + +#ifndef ISCSI_IFEV_H +#define ISCSI_IFEV_H + +enum iscsi_uevent_e { + ISCSI_UEVENT_UNKNOWN = 0, + + /* down events */ + ISCSI_UEVENT_CREATE_SESSION = UEVENT_BASE + 1, + ISCSI_UEVENT_DESTROY_SESSION = UEVENT_BASE + 2, + ISCSI_UEVENT_CREATE_CONN = UEVENT_BASE + 3, + ISCSI_UEVENT_DESTROY_CONN = UEVENT_BASE + 4, + ISCSI_UEVENT_BIND_CONN = UEVENT_BASE + 5, + ISCSI_UEVENT_SET_PARAM = UEVENT_BASE + 6, + ISCSI_UEVENT_START_CONN = UEVENT_BASE + 7, + ISCSI_UEVENT_STOP_CONN = UEVENT_BASE + 8, + ISCSI_UEVENT_SEND_PDU = UEVENT_BASE + 9, + ISCSI_UEVENT_TRANS_LIST = UEVENT_BASE + 10, + ISCSI_UEVENT_GET_STATS = UEVENT_BASE + 11, + ISCSI_UEVENT_GET_PARAM = UEVENT_BASE + 12, + + /* up events */ + ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1, + ISCSI_KEVENT_CONN_ERROR = KEVENT_BASE + 2, + ISCSI_KEVENT_IF_ERROR = KEVENT_BASE + 3, +}; + +struct iscsi_uevent { + uint32_t type; /* k/u events type */ + uint32_t iferror; /* carries interface or resource errors */ + uint64_t transport_handle; + + union { + /* messages u -> k */ + struct msg_create_session { + uint32_t initial_cmdsn; + } c_session; + struct msg_destroy_session { + uint64_t session_handle; + uint32_t sid; + } d_session; + struct msg_create_conn { + uint64_t session_handle; + uint32_t cid; + uint32_t sid; + } c_conn; + struct msg_bind_conn { + uint64_t session_handle; + uint64_t conn_handle; + uint32_t transport_fd; + uint32_t is_leading; + } b_conn; + struct msg_destroy_conn { + uint64_t conn_handle; + uint32_t cid; + } d_conn; + struct msg_send_pdu { + uint32_t hdr_size; + uint32_t data_size; + uint64_t conn_handle; + } send_pdu; + struct msg_set_param { + uint64_t conn_handle; + uint32_t param; /* enum iscsi_param */ + uint32_t value; + } set_param; + struct msg_start_conn { + uint64_t conn_handle; + } start_conn; + struct msg_stop_conn { + uint64_t conn_handle; + uint32_t flag; + } stop_conn; + struct msg_get_stats { + uint64_t conn_handle; + } get_stats; + } u; + union { + /* messages k -> u */ + uint64_t handle; + int retcode; + struct msg_create_session_ret { + uint64_t session_handle; + uint32_t sid; + } c_session_ret; + struct msg_recv_req { + uint64_t recv_handle; + uint64_t conn_handle; + } recv_req; + struct msg_conn_error { + uint64_t conn_handle; + uint32_t error; /* enum iscsi_err */ + } connerror; + struct msg_trans_list { + struct { + uint64_t trans_handle; + char name[ISCSI_TRANSPORT_NAME_MAXLEN]; + } elements[ISCSI_TRANSPORT_MAX]; + } t_list; + } r; +} __attribute__ ((aligned (sizeof(uint64_t)))); + +#endif /* ISCSI_IFEV_H */ diff -Naurp linux-2.6.12-rc4/include/scsi/iscsi_if.h linux-2.6.12-rc4.work/include/scsi/iscsi_if.h --- linux-2.6.12-rc4/include/scsi/iscsi_if.h 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.12-rc4.work/include/scsi/iscsi_if.h 2005-05-14 13:20:22.000000000 -0700 @@ -0,0 +1,156 @@ +/* + * iSCSI User/Kernel Shares (Defines, Constants, Protocol definitions, etc) + * + * Copyright (C) 2005 Dmitry Yusupov, Alex Aizman + * maintained by open-iscsi@googlegroups.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published + * by the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * See the file COPYING included with this distribution for more details. + */ + +#ifndef ISCSI_IF_H +#define ISCSI_IF_H + +#include + +#define ISCSI_TRANSPORT_NAME_MAXLEN 16 +#define ISCSI_TRANSPORT_MAX 1 +#define UEVENT_BASE 10 +#define KEVENT_BASE 100 +#define ISCSI_ERR_BASE 1000 + +/* + * Common error codes + */ +enum iscsi_err { + ISCSI_OK = 0, + + ISCSI_ERR_DATASN = ISCSI_ERR_BASE + 1, + ISCSI_ERR_DATA_OFFSET = ISCSI_ERR_BASE + 2, + ISCSI_ERR_MAX_CMDSN = ISCSI_ERR_BASE + 3, + ISCSI_ERR_EXP_CMDSN = ISCSI_ERR_BASE + 4, + ISCSI_ERR_BAD_OPCODE = ISCSI_ERR_BASE + 5, + ISCSI_ERR_DATALEN = ISCSI_ERR_BASE + 6, + ISCSI_ERR_AHSLEN = ISCSI_ERR_BASE + 7, + ISCSI_ERR_PROTO = ISCSI_ERR_BASE + 8, + ISCSI_ERR_LUN = ISCSI_ERR_BASE + 9, + ISCSI_ERR_BAD_ITT = ISCSI_ERR_BASE + 10, + ISCSI_ERR_CONN_FAILED = ISCSI_ERR_BASE + 11, + ISCSI_ERR_R2TSN = ISCSI_ERR_BASE + 12, + ISCSI_ERR_SESSION_FAILED = ISCSI_ERR_BASE + 13, + ISCSI_ERR_HDR_DGST = ISCSI_ERR_BASE + 14, + ISCSI_ERR_DATA_DGST = ISCSI_ERR_BASE + 15, + ISCSI_ERR_PDU_GATHER_FAILED = ISCSI_ERR_BASE + 16, + ISCSI_ERR_PARAM_NOT_FOUND = ISCSI_ERR_BASE + 17 +}; + +/* + * iSCSI Parameters (RFC3720) + */ +enum iscsi_param { + ISCSI_PARAM_MAX_RECV_DLENGTH = 0, + ISCSI_PARAM_MAX_XMIT_DLENGTH = 1, + ISCSI_PARAM_HDRDGST_EN = 2, + ISCSI_PARAM_DATADGST_EN = 3, + ISCSI_PARAM_INITIAL_R2T_EN = 4, + ISCSI_PARAM_MAX_R2T = 5, + ISCSI_PARAM_IMM_DATA_EN = 6, + ISCSI_PARAM_FIRST_BURST = 7, + ISCSI_PARAM_MAX_BURST = 8, + ISCSI_PARAM_PDU_INORDER_EN = 9, + ISCSI_PARAM_DATASEQ_INORDER_EN = 10, + ISCSI_PARAM_ERL = 11, + ISCSI_PARAM_IFMARKER_EN = 12, + ISCSI_PARAM_OFMARKER_EN = 13, +}; +#define ISCSI_PARAM_MAX 14 + +typedef uint64_t iscsi_sessionh_t; /* iSCSI Data-Path session handle */ +typedef uint64_t iscsi_connh_t; /* iSCSI Data-Path connection handle */ + +#define iscsi_ptr(_handle) ((void*)(unsigned long)_handle) +#define iscsi_handle(_ptr) ((uint64_t)(unsigned long)_ptr) +#define iscsi_hostdata(_hostdata) ((void*)_hostdata + sizeof(unsigned long)) + +/* + * These flags presents iSCSI Data-Path capabilities. + */ +#define CAP_RECOVERY_L0 0x1 +#define CAP_RECOVERY_L1 0x2 +#define CAP_RECOVERY_L2 0x4 +#define CAP_MULTI_R2T 0x8 +#define CAP_HDRDGST 0x10 +#define CAP_DATADGST 0x20 +#define CAP_MULTI_CONN 0x40 +#define CAP_TEXT_NEGO 0x80 +#define CAP_MARKERS 0x100 + +/* + * These flags describes reason of stop_conn() call + */ +#define STOP_CONN_TERM 0x1 +#define STOP_CONN_SUSPEND 0x2 +#define STOP_CONN_RECOVER 0x3 + +#define ISCSI_STATS_CUSTOM_MAX 32 +#define ISCSI_STATS_CUSTOM_DESC_MAX 64 +struct iscsi_stats_custom { + char desc[ISCSI_STATS_CUSTOM_DESC_MAX]; + uint64_t value; +}; + +/* + * struct iscsi_stats - iSCSI Statistics (iSCSI MIB) + * + * Note: this structure contains counters collected on per-connection basis. + */ +struct iscsi_stats { + /* octets */ + uint64_t txdata_octets; + uint64_t rxdata_octets; + + /* xmit pdus */ + uint32_t noptx_pdus; + uint32_t scsicmd_pdus; + uint32_t tmfcmd_pdus; + uint32_t login_pdus; + uint32_t text_pdus; + uint32_t dataout_pdus; + uint32_t logout_pdus; + uint32_t snack_pdus; + + /* recv pdus */ + uint32_t noprx_pdus; + uint32_t scsirsp_pdus; + uint32_t tmfrsp_pdus; + uint32_t textrsp_pdus; + uint32_t datain_pdus; + uint32_t logoutrsp_pdus; + uint32_t r2t_pdus; + uint32_t async_pdus; + uint32_t rjt_pdus; + + /* errors */ + uint32_t digest_err; + uint32_t timeout_err; + + /* + * iSCSI Custom Statistics support, i.e. Transport could + * extend existing MIB statistics with its own specific statistics + * up to ISCSI_STATS_CUSTOM_MAX + */ + uint32_t custom_length; + struct iscsi_stats_custom custom[0] + __attribute__ ((aligned (sizeof(uint64_t)))); +}; + +#endif diff -Naurp linux-2.6.12-rc4/include/scsi/iscsi_proto.h linux-2.6.12-rc4.work/include/scsi/iscsi_proto.h --- linux-2.6.12-rc4/include/scsi/iscsi_proto.h 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.12-rc4.work/include/scsi/iscsi_proto.h 2005-05-14 13:19:45.000000000 -0700 @@ -0,0 +1,565 @@ +/* + * RFC 3720 (iSCSI) protocol data types + * + * Copyright (C) 2005 Dmitry Yusupov, Alex Aizman + * maintained by open-iscsi@googlegroups.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published + * by the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * See the file COPYING included with this distribution for more details. + */ + +#ifndef ISCSI_PROTO_H +#define ISCSI_PROTO_H + +#define ISCSI_VERSION_STR "0.3" +#define ISCSI_DATE_STR "22-Apr-2005" +#define ISCSI_DRAFT20_VERSION 0x00 + +/* default iSCSI listen port for incoming connections */ +#define ISCSI_LISTEN_PORT 3260 + +/* Padding word length */ +#define PAD_WORD_LEN 4 + +/* + * useful common(control and data pathes) macro + */ +#define ntoh24(p) (((p)[0] << 16) | ((p)[1] << 8) | ((p)[2])) +#define hton24(p, v) { \ + p[0] = (((v) >> 16) & 0xFF); \ + p[1] = (((v) >> 8) & 0xFF); \ + p[2] = ((v) & 0xFF); \ +} +#define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;} + +/* + * iSCSI Template Message Header + */ +struct iscsi_hdr { + uint8_t opcode; + uint8_t flags; /* Final bit */ + uint8_t rsvd2[2]; + uint8_t hlength; /* AHSs total length */ + uint8_t dlength[3]; /* Data length */ + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 ttt; /* Target Task Tag */ + __be32 statsn; + __be32 exp_statsn; + uint8_t other[16]; +}; + +/************************* RFC 3720 Begin *****************************/ + +#define ISCSI_RESERVED_TAG 0xffffffff + +/* Opcode encoding bits */ +#define ISCSI_OP_RETRY 0x80 +#define ISCSI_OP_IMMEDIATE 0x40 +#define ISCSI_OPCODE_MASK 0x3F + +/* Initiator Opcode values */ +#define ISCSI_OP_NOOP_OUT 0x00 +#define ISCSI_OP_SCSI_CMD 0x01 +#define ISCSI_OP_SCSI_TMFUNC 0x02 +#define ISCSI_OP_LOGIN 0x03 +#define ISCSI_OP_TEXT 0x04 +#define ISCSI_OP_SCSI_DATA_OUT 0x05 +#define ISCSI_OP_LOGOUT 0x06 +#define ISCSI_OP_SNACK 0x10 + +/* Target Opcode values */ +#define ISCSI_OP_NOOP_IN 0x20 +#define ISCSI_OP_SCSI_CMD_RSP 0x21 +#define ISCSI_OP_SCSI_TMFUNC_RSP 0x22 +#define ISCSI_OP_LOGIN_RSP 0x23 +#define ISCSI_OP_TEXT_RSP 0x24 +#define ISCSI_OP_SCSI_DATA_IN 0x25 +#define ISCSI_OP_LOGOUT_RSP 0x26 +#define ISCSI_OP_R2T 0x31 +#define ISCSI_OP_ASYNC_EVENT 0x32 +#define ISCSI_OP_REJECT 0x3f + +/* SCSI Command Header */ +struct iscsi_cmd { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2; + uint8_t cmdrn; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 data_length; + __be32 cmdsn; + __be32 exp_statsn; + uint8_t cdb[16]; /* SCSI Command Block */ + /* Additional Data (Command Dependent) */ +}; + +/* Command PDU flags */ +#define ISCSI_FLAG_CMD_FINAL 0x80 +#define ISCSI_FLAG_CMD_READ 0x40 +#define ISCSI_FLAG_CMD_WRITE 0x20 +#define ISCSI_FLAG_CMD_ATTR_MASK 0x07 /* 3 bits */ + +/* SCSI Command Attribute values */ +#define ISCSI_ATTR_UNTAGGED 0 +#define ISCSI_ATTR_SIMPLE 1 +#define ISCSI_ATTR_ORDERED 2 +#define ISCSI_ATTR_HEAD_OF_QUEUE 3 +#define ISCSI_ATTR_ACA 4 + +/* SCSI Response Header */ +struct iscsi_cmd_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t response; + uint8_t cmd_status; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 rsvd1; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 exp_datasn; + __be32 bi_residual_count; + __be32 residual_count; + /* Response or Sense Data (optional) */ +}; + +/* Command Response PDU flags */ +#define ISCSI_FLAG_CMD_BIDI_OVERFLOW 0x10 +#define ISCSI_FLAG_CMD_BIDI_UNDERFLOW 0x08 +#define ISCSI_FLAG_CMD_OVERFLOW 0x04 +#define ISCSI_FLAG_CMD_UNDERFLOW 0x02 + +/* iSCSI Status values. Valid if Rsp Selector bit is not set */ +#define ISCSI_STATUS_CMD_COMPLETED 0 +#define ISCSI_STATUS_TARGET_FAILURE 1 +#define ISCSI_STATUS_SUBSYS_FAILURE 2 + +/* Asynchronous Event Header */ +struct iscsi_async { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t lun[8]; + uint8_t rsvd4[8]; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t async_event; + uint8_t async_vcode; + __be16 param1; + __be16 param2; + __be16 param3; + uint8_t rsvd5[4]; +}; + +/* iSCSI Event Codes */ +#define ISCSI_ASYNC_MSG_SCSI_EVENT 0 +#define ISCSI_ASYNC_MSG_REQUEST_LOGOUT 1 +#define ISCSI_ASYNC_MSG_DROPPING_CONNECTION 2 +#define ISCSI_ASYNC_MSG_DROPPING_ALL_CONNECTIONS 3 +#define ISCSI_ASYNC_MSG_PARAM_NEGOTIATION 4 +#define ISCSI_ASYNC_MSG_VENDOR_SPECIFIC 255 + +/* NOP-Out Message */ +struct iscsi_nopout { + uint8_t opcode; + uint8_t flags; + __be16 rsvd2; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 ttt; /* Target Transfer Tag */ + __be32 cmdsn; + __be32 exp_statsn; + uint8_t rsvd4[16]; +}; + +/* NOP-In Message */ +struct iscsi_nopin { + uint8_t opcode; + uint8_t flags; + __be16 rsvd2; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 ttt; /* Target Transfer Tag */ + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t rsvd4[12]; +}; + +/* SCSI Task Management Message Header */ +struct iscsi_tm { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd1[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 rtt; /* Reference Task Tag */ + __be32 cmdsn; + __be32 exp_statsn; + __be32 refcmdsn; + __be32 exp_datasn; + uint8_t rsvd2[8]; +}; + +#define ISCSI_FLAG_TASK_MGMT_FUNCTION_MASK 0x7F + +/* Function values */ +#define ISCSI_TM_FUNC_ABORT_TASK 1 +#define ISCSI_TM_FUNC_ABORT_TASK_SET 2 +#define ISCSI_TM_FUNC_CLEAR_ACA 3 +#define ISCSI_TM_FUNC_CLEAR_TASK_SET 4 +#define ISCSI_TM_FUNC_LOGICAL_UNIT_RESET 5 +#define ISCSI_TM_FUNC_TARGET_WARM_RESET 6 +#define ISCSI_TM_FUNC_TARGET_COLD_RESET 7 +#define ISCSI_TM_FUNC_TASK_REASSIGN 8 + +/* SCSI Task Management Response Header */ +struct iscsi_tm_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t response; /* see Response values below */ + uint8_t qualifier; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd2[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 rtt; /* Reference Task Tag */ + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t rsvd3[12]; +}; + +/* Response values */ +#define SCSI_TCP_TM_RESP_COMPLETE 0x00 +#define SCSI_TCP_TM_RESP_NO_TASK 0x01 +#define SCSI_TCP_TM_RESP_NO_LUN 0x02 +#define SCSI_TCP_TM_RESP_TASK_ALLEGIANT 0x03 +#define SCSI_TCP_TM_RESP_NO_FAILOVER 0x04 +#define SCSI_TCP_TM_RESP_NOT_SUPPORTED 0x05 +#define SCSI_TCP_TM_RESP_AUTH_FAILED 0x06 +#define SCSI_TCP_TM_RESP_REJECTED 0xff + +/* Ready To Transfer Header */ +struct iscsi_r2t_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 ttt; /* Target Transfer Tag */ + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 r2tsn; + __be32 data_offset; + __be32 data_length; +}; + +/* SCSI Data Hdr */ +struct iscsi_data { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; + __be32 ttt; + __be32 rsvd4; + __be32 exp_statsn; + __be32 rsvd5; + __be32 datasn; + __be32 offset; + __be32 rsvd6; + /* Payload */ +}; + +/* SCSI Data Response Hdr */ +struct iscsi_data_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2; + uint8_t cmd_status; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t lun[8]; + __be32 itt; + __be32 ttt; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 datasn; + __be32 offset; + __be32 residual_count; +}; + +/* Data Response PDU flags */ +#define ISCSI_FLAG_DATA_ACK 0x40 +#define ISCSI_FLAG_DATA_OVERFLOW 0x04 +#define ISCSI_FLAG_DATA_UNDERFLOW 0x02 +#define ISCSI_FLAG_DATA_STATUS 0x01 + +/* Text Header */ +struct iscsi_text { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd4[8]; + __be32 itt; + __be32 ttt; + __be32 cmdsn; + __be32 exp_statsn; + uint8_t rsvd5[16]; + /* Text - key=value pairs */ +}; + +#define ISCSI_FLAG_TEXT_CONTINUE 0x40 + +/* Text Response Header */ +struct iscsi_text_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd4[8]; + __be32 itt; + __be32 ttt; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t rsvd5[12]; + /* Text Response - key:value pairs */ +}; + +/* Login Header */ +struct iscsi_login { + uint8_t opcode; + uint8_t flags; + uint8_t max_version; /* Max. version supported */ + uint8_t min_version; /* Min. version supported */ + uint8_t hlength; + uint8_t dlength[3]; + uint8_t isid[6]; /* Initiator Session ID */ + __be16 tsih; /* Target Session Handle */ + __be32 itt; /* Initiator Task Tag */ + __be16 cid; + __be16 rsvd3; + __be32 cmdsn; + __be32 exp_statsn; + uint8_t rsvd5[16]; +}; + +/* Login PDU flags */ +#define ISCSI_FLAG_LOGIN_TRANSIT 0x80 +#define ISCSI_FLAG_LOGIN_CONTINUE 0x40 +#define ISCSI_FLAG_LOGIN_CURRENT_STAGE_MASK 0x0C /* 2 bits */ +#define ISCSI_FLAG_LOGIN_NEXT_STAGE_MASK 0x03 /* 2 bits */ + +#define ISCSI_LOGIN_CURRENT_STAGE(flags) \ + ((flags & ISCSI_FLAG_LOGIN_CURRENT_STAGE_MASK) >> 2) +#define ISCSI_LOGIN_NEXT_STAGE(flags) \ + (flags & ISCSI_FLAG_LOGIN_NEXT_STAGE_MASK) + +/* Login Response Header */ +struct iscsi_login_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t max_version; /* Max. version supported */ + uint8_t active_version; /* Active version */ + uint8_t hlength; + uint8_t dlength[3]; + uint8_t isid[6]; /* Initiator Session ID */ + __be16 tsih; /* Target Session Handle */ + __be32 itt; /* Initiator Task Tag */ + __be32 rsvd3; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + uint8_t status_class; /* see Login RSP ststus classes below */ + uint8_t status_detail; /* see Login RSP Status details below */ + uint8_t rsvd4[10]; +}; + +/* Login stage (phase) codes for CSG, NSG */ +#define ISCSI_INITIAL_LOGIN_STAGE -1 +#define ISCSI_SECURITY_NEGOTIATION_STAGE 0 +#define ISCSI_OP_PARMS_NEGOTIATION_STAGE 1 +#define ISCSI_FULL_FEATURE_PHASE 3 + +/* Login Status response classes */ +#define ISCSI_STATUS_CLS_SUCCESS 0x00 +#define ISCSI_STATUS_CLS_REDIRECT 0x01 +#define ISCSI_STATUS_CLS_INITIATOR_ERR 0x02 +#define ISCSI_STATUS_CLS_TARGET_ERR 0x03 + +/* Login Status response detail codes */ +/* Class-0 (Success) */ +#define ISCSI_LOGIN_STATUS_ACCEPT 0x00 + +/* Class-1 (Redirection) */ +#define ISCSI_LOGIN_STATUS_TGT_MOVED_TEMP 0x01 +#define ISCSI_LOGIN_STATUS_TGT_MOVED_PERM 0x02 + +/* Class-2 (Initiator Error) */ +#define ISCSI_LOGIN_STATUS_INIT_ERR 0x00 +#define ISCSI_LOGIN_STATUS_AUTH_FAILED 0x01 +#define ISCSI_LOGIN_STATUS_TGT_FORBIDDEN 0x02 +#define ISCSI_LOGIN_STATUS_TGT_NOT_FOUND 0x03 +#define ISCSI_LOGIN_STATUS_TGT_REMOVED 0x04 +#define ISCSI_LOGIN_STATUS_NO_VERSION 0x05 +#define ISCSI_LOGIN_STATUS_ISID_ERROR 0x06 +#define ISCSI_LOGIN_STATUS_MISSING_FIELDS 0x07 +#define ISCSI_LOGIN_STATUS_CONN_ADD_FAILED 0x08 +#define ISCSI_LOGIN_STATUS_NO_SESSION_TYPE 0x09 +#define ISCSI_LOGIN_STATUS_NO_SESSION 0x0a +#define ISCSI_LOGIN_STATUS_INVALID_REQUEST 0x0b + +/* Class-3 (Target Error) */ +#define ISCSI_LOGIN_STATUS_TARGET_ERROR 0x00 +#define ISCSI_LOGIN_STATUS_SVC_UNAVAILABLE 0x01 +#define ISCSI_LOGIN_STATUS_NO_RESOURCES 0x02 + +/* Logout Header */ +struct iscsi_logout { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd1[2]; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd2[8]; + __be32 itt; /* Initiator Task Tag */ + __be16 cid; + uint8_t rsvd3[2]; + __be32 cmdsn; + __be32 exp_statsn; + uint8_t rsvd4[16]; +}; + +/* Logout PDU flags */ +#define ISCSI_FLAG_LOGOUT_REASON_MASK 0x7F + +/* logout reason_code values */ + +#define ISCSI_LOGOUT_REASON_CLOSE_SESSION 0 +#define ISCSI_LOGOUT_REASON_CLOSE_CONNECTION 1 +#define ISCSI_LOGOUT_REASON_RECOVERY 2 +#define ISCSI_LOGOUT_REASON_AEN_REQUEST 3 + +/* Logout Response Header */ +struct iscsi_logout_rsp { + uint8_t opcode; + uint8_t flags; + uint8_t response; /* see Logout response values below */ + uint8_t rsvd2; + uint8_t hlength; + uint8_t dlength[3]; + uint8_t rsvd3[8]; + __be32 itt; /* Initiator Task Tag */ + __be32 rsvd4; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 rsvd5; + __be16 t2wait; + __be16 t2retain; + __be32 rsvd6; +}; + +/* logout response status values */ + +#define ISCSI_LOGOUT_SUCCESS 0 +#define ISCSI_LOGOUT_CID_NOT_FOUND 1 +#define ISCSI_LOGOUT_RECOVERY_UNSUPPORTED 2 +#define ISCSI_LOGOUT_CLEANUP_FAILED 3 + +/* SNACK Header */ +struct iscsi_snack { + uint8_t opcode; + uint8_t flags; + uint8_t rsvd2[14]; + __be32 itt; + __be32 begrun; + __be32 runlength; + __be32 exp_statsn; + __be32 rsvd3; + __be32 exp_datasn; + uint8_t rsvd6[8]; +}; + +/* SNACK PDU flags */ +#define ISCSI_FLAG_SNACK_TYPE_MASK 0x0F /* 4 bits */ + +/* Reject Message Header */ +struct iscsi_reject { + uint8_t opcode; + uint8_t flags; + uint8_t reason; + uint8_t rsvd2; + uint8_t rsvd3; + uint8_t dlength[3]; + uint8_t rsvd4[16]; + __be32 statsn; + __be32 exp_cmdsn; + __be32 max_cmdsn; + __be32 datasn; + uint8_t rsvd5[8]; + /* Text - Rejected hdr */ +}; + +/* Reason for Reject */ +#define CMD_BEFORE_LOGIN 1 +#define DATA_DIGEST_ERROR 2 +#define DATA_SNACK_REJECT 3 +#define ISCSI_PROTOCOL_ERROR 4 +#define CMD_NOT_SUPPORTED 5 +#define IMM_CMD_REJECT 6 +#define TASK_IN_PROGRESS 7 +#define INVALID_SNACK 8 +#define BOOKMARK_REJECTED 9 +#define BOOKMARK_NO_RESOURCES 10 +#define NEGOTIATION_RESET 11 + +/* Max. number of Key=Value pairs in a text message */ +#define MAX_KEY_VALUE_PAIRS 8192 + +/* maximum length for text keys/values */ +#define KEY_MAXLEN 64 +#define VALUE_MAXLEN 255 +#define TARGET_NAME_MAXLEN VALUE_MAXLEN + +#define DEFAULT_MAX_RECV_DATA_SEGMENT_LENGTH 8192 + +/************************* RFC 3720 End *****************************/ + +#endif /* ISCSI_PROTO_H */ From michaelc@cs.wisc.edu Sun May 15 12:30:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 12:30:43 -0700 (PDT) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FJUaOv009854 for ; Sun, 15 May 2005 12:30:37 -0700 Received: from [192.168.0.2] ([199.108.226.254]) (authenticated bits=0) by sabe.cs.wisc.edu (8.13.1/8.13.1) with ESMTP id j4FJU2mq021351 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 15 May 2005 14:30:03 -0500 Subject: [PATCH 1/3] add open iscsi netlink interface to iscsi transport class From: Mike Christie To: open-iscsi@googlegroups.com, netdev@oss.sgi.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, inux-iscsi-devel@lists.sourceforge.netl.sgi.com Content-Type: text/plain Message-Id: <1116185397.17312.10.camel@mina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 15 May 2005 12:29:57 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 1143 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michaelc@cs.wisc.edu Precedence: bulk X-list: netdev Content-Length: 766 Lines: 23 include/linux/netlink.h changes (added new protocol NETLINK_ISCSI) Thanks, Linux-iscsi Team Signed-off-by: Alex Aizman Signed-off-by: Dmitry Yusupov Signed-off-by: Mike Christie --- linux-2.6.12-rc3.orig/include/linux/netlink.h 2005-04-20 17:03:16.000000000 -0700 +++ linux-2.6.12-rc3/include/linux/netlink.h 2005-05-04 18:06:44.000000000 -0700 @@ -14,6 +14,7 @@ #define NETLINK_SELINUX 7 /* SELinux event notifications */ #define NETLINK_ARPD 8 #define NETLINK_AUDIT 9 /* auditing */ +#define NETLINK_ISCSI 10 /* iSCSI Open Interface */ #define NETLINK_ROUTE6 11 /* af_inet6 route comm channel */ #define NETLINK_IP6_FW 13 #define NETLINK_DNRTMSG 14 /* DECnet routing messages */ From michaelc@cs.wisc.edu Sun May 15 12:30:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 12:31:00 -0700 (PDT) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FJUrOv009908 for ; Sun, 15 May 2005 12:30:54 -0700 Received: from [192.168.0.2] ([199.108.226.254]) (authenticated bits=0) by sabe.cs.wisc.edu (8.13.1/8.13.1) with ESMTP id j4FJTjNI021348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 15 May 2005 14:29:46 -0500 Message-ID: <4287A323.6010209@cs.wisc.edu> Date: Sun, 15 May 2005 12:29:39 -0700 From: Mike Christie User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: open-iscsi@googlegroups.com, netdev , linux-scsi , linux-kernel@vger.kernel.org, linux-iscsi-devel Subject: [PATCH 0/3] add open iscsi netlink interface to iscsi transport class Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1145 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michaelc@cs.wisc.edu Precedence: bulk X-list: netdev Content-Length: 2541 Lines: 56 The following patches add the linux-iscsi-5.X/open-iscsi project's netlink interface to the iscsi transport class. Last time I messed up and did not inline the patches so the reason for the allignment in some structures was not clear. There was also a bug in that unsigned long was being used instead of u64/unit64_t so that complicated matters. We have been discussing this internally but I am not sure I know the best route - I had hoped to just be able to remove them all like was suggested, so I am reposting the patches inlined with hopefully at least Chris Wright and almost all of Christoph Hellwig's comments addressed. The one suggestion we were not able to complete was the one to move the scsi_remove_host and scsi_host_add calls. It is trivial to do, but seemed odd since every iscsi_transport would need to add these calls. I can understand in the future when HW iSCSI is supported all our scsi_host lifetime code will need to be reworked because they allocate a host per pci device and we allocate a host per session (maybe a common place to meet would be a host per initiator port), but with only software iSCSI supported today maybe a little more info is needed. Is the suggestion to move the add/remove host calls to the iscsi_transport to allow the transport to control when they want to begin queueing comamnds? Maybe the removal of ISCSI_TRANSPORT_MAX is also not completely met too. I am hoping to finish fixing that by exposing the same information through sysfs, but I am still trying to figure out how the layout should be implmented using the driver model transport classes and struct devices or kobjects or whatever makes people happy. We could simply do this using driver model transport classes by just adding a iscsi_transport class that represents the iSCSI transport like iscsi_tcp, iscsi_iser and making that the parent of the session, but maybe that is better done in a seperate patch so we can discuss the abstraction for the parent of the session seperately. More info about the open-iscsi/linux-iscsi-5 project can found here http://open-iscsi.org/. Patches 1. add-iscsi-netlink-def.patch - include/linux/netlink.h changes (added new protocol NETLINK_ISCSI) 2. common-iscsi-headers.patch - Common header files: - iscsi_if.h (user/kernel #defines); - iscsi_proto.h (RFC3720 #defines and types); - iscsi_ifev.h (user/kernel events). 3. integrate-iscsi-netlink.patch - incorporate the open-iscsi/linux-iscsi netlink interface into the iscsi transport class. Thanks, Linux-iscsi Team From pasky@machine.sinus.cz Sun May 15 13:05:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 13:06:03 -0700 (PDT) Received: from machine.sinus.cz (w241.dkm.cz [62.24.88.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4FK5rOv011867 for ; Sun, 15 May 2005 13:05:54 -0700 Received: (qmail 28457 invoked by uid 2001); 15 May 2005 20:05:14 -0000 Date: Sun, 15 May 2005 22:05:14 +0200 From: Petr Baudis To: Jeff Garzik Cc: James Ketrenos , Netdev , Linux Kernel , git@vger.kernel.org Subject: Re: git repository for net drivers available Message-ID: <20050515200514.GA31414@pasky.ji.cz> References: <42841A3F.7020909@pobox.com> <4284C54E.3060907@linux.intel.com> <4284C7DA.1020707@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4284C7DA.1020707@pobox.com> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. X-archive-position: 1146 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pasky@ucw.cz Precedence: bulk X-list: netdev Content-Length: 636 Lines: 16 Dear diary, on Fri, May 13, 2005 at 05:29:30PM CEST, I got a letter where Jeff Garzik told me that... > Looks like cogito is using $repo/heads/$branch, whereas my git repo is > using $repo/branches/$branch. Would it be a big problem to use refs/heads/$branch? That's the currently commonly agreed convention about location for storing branch heads, not just some weird Cogito-specific invention. And it'd be very nice to have those locations consistent across git repositories. Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor From jgarzik@pobox.com Sun May 15 13:21:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 13:21:37 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FKLWOv012752 for ; Sun, 15 May 2005 13:21:33 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXPbY-0004SP-Nm; Sun, 15 May 2005 20:20:53 +0000 Message-ID: <4287AF22.8090300@pobox.com> Date: Sun, 15 May 2005 16:20:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petr Baudis CC: James Ketrenos , Netdev , Linux Kernel , git@vger.kernel.org, Andrew Morton Subject: Re: git repository for net drivers available References: <42841A3F.7020909@pobox.com> <4284C54E.3060907@linux.intel.com> <4284C7DA.1020707@pobox.com> <20050515200514.GA31414@pasky.ji.cz> In-Reply-To: <20050515200514.GA31414@pasky.ji.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1147 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 615 Lines: 21 Petr Baudis wrote: > Dear diary, on Fri, May 13, 2005 at 05:29:30PM CEST, I got a letter > where Jeff Garzik told me that... > >>Looks like cogito is using $repo/heads/$branch, whereas my git repo is >>using $repo/branches/$branch. > > > Would it be a big problem to use refs/heads/$branch? That's the > currently commonly agreed convention about location for storing branch > heads, not just some weird Cogito-specific invention. And it'd be very > nice to have those locations consistent across git repositories. Sure, that's doable. I've pushed out this change to kernel.org. Jeff From herbert@gondor.apana.org.au Sun May 15 14:30:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 14:30:30 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FLUOOv015509 for ; Sun, 15 May 2005 14:30:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXQgD-0008Th-00; Mon, 16 May 2005 07:29:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXQgA-00051S-00; Mon, 16 May 2005 07:29:42 +1000 Date: Mon, 16 May 2005 07:29:42 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [IPV4/IPV6] Ensure all frag_list members have NULL sk Message-ID: <20050515212942.GA19296@gondor.apana.org.au> References: <20050514134834.GA2698@uganda.factory.vocord.ru> <20050515104016.GA24344@gondor.apana.org.au> <20050515114121.GA4830@gondor.apana.org.au> <20050515122256.GA22251@gondor.apana.org.au> <20050515213341.4011c00e@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050515213341.4011c00e@zanzibar.2ka.mipt.ru> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1148 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 720 Lines: 20 On Sun, May 15, 2005 at 09:33:41PM +0400, Evgeniy Polyakov wrote: > > > So let's go the other way and make this an invariant: > > > > For any skb on a frag_list, skb->sk must be NULL. > > This requires skb_set_owner_* to check if it is called > for head skb or one from fragment and does nothing if > it is from frag_list. > Or to check the whole tree for ownering calls... Not really. The frag_list skb's owned by sk's are generated in one place only, and that place is ip*_push_pending_frames. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jgarzik@pobox.com Sun May 15 14:59:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:00:01 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FLxuOv016778 for ; Sun, 15 May 2005 14:59:57 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXR8s-0004UV-Os; Sun, 15 May 2005 21:59:23 +0000 Message-ID: <4287C637.4030206@pobox.com> Date: Sun, 15 May 2005 17:59:19 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] document that 8139TOO supports 8129/8130 References: <20050513040445.GD3603@stusta.de> In-Reply-To: <20050513040445.GD3603@stusta.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1149 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 110 Lines: 5 Adrian Bunk wrote: > + the RTL 8129/81308139 chips. If you have one of those, say Y and typo: "81308139" From jgarzik@pobox.com Sun May 15 15:11:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:11:18 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FMBFOv017613 for ; Sun, 15 May 2005 15:11:15 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXRJm-0004VQ-MZ; Sun, 15 May 2005 22:10:39 +0000 Message-ID: <4287C8DB.3090200@pobox.com> Date: Sun, 15 May 2005 18:10:35 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: AAbdulla@nvidia.com, Netdev , Carl-Daniel Hailfinger , adq@lidskialf.net Subject: Re: [PATCH] forcedeth Update error handling References: <42655935.9050703@colorfullife.com> In-Reply-To: <42655935.9050703@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From jgarzik@pobox.com Sun May 15 15:15:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:15:28 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FMFPOv018184 for ; Sun, 15 May 2005 15:15:26 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXRNo-0004Vm-Lt; Sun, 15 May 2005 22:14:49 +0000 Message-ID: <4287C9D6.1060004@pobox.com> Date: Sun, 15 May 2005 18:14:46 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Andrew Morton , netdev@oss.sgi.com Subject: Re: [patch linux-2.6.12-rc3-mm3 1/7] r8169: de-obfuscate supported PCI ID References: <20050504221057.1e02a402.akpm@osdl.org> <20050505115502.GA4414@electric-eye.fr.zoreil.com> <20050505110052.62c1c2cb.akpm@osdl.org> <20050505225656.GA11200@electric-eye.fr.zoreil.com> In-Reply-To: <20050505225656.GA11200@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1152 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 283 Lines: 9 All seven look OK, but it failed on the first patch: [jgarzik@pretzel netdev-2.6]$ dotest /g/tmp/mbox Applying 'r8169: de-obfuscate supported PCI ID' patching file drivers/net/r8169.c Hunk #1 FAILED at 174. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/r8169.c.rej From davem@davemloft.net Sun May 15 15:19:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:19:36 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FMJWOv018749 for ; Sun, 15 May 2005 15:19:33 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DXRRe-0002mI-O1; Sun, 15 May 2005 15:18:46 -0700 Date: Sun, 15 May 2005 15:18:46 -0700 (PDT) Message-Id: <20050515.151846.85410444.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com Subject: Re: [1/1] xfrm: skb_cow_data() does not set proper owner for new skbs. From: "David S. Miller" In-Reply-To: References: <20050514134834.GA2698@uganda.factory.vocord.ru> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1153 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 483 Lines: 12 From: Herbert Xu Subject: Re: [1/1] xfrm: skb_cow_data() does not set proper owner for new skbs. Date: Sun, 15 May 2005 18:01:09 +1000 > IPv4's ip_push_pending_frames attributes all the data to the first > skb which breaks when the packet is sent through ip_fragment since > the latter does not undo the truesize attribution. I'm %99 sure this one is on purpose. I'll have to dig into the archives and source repo history to get the details though. From jgarzik@pobox.com Sun May 15 15:19:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:19:59 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FMJuOv018780 for ; Sun, 15 May 2005 15:19:57 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXRSC-0004W0-Jr; Sun, 15 May 2005 22:19:20 +0000 Message-ID: <4287CAE6.9020007@pobox.com> Date: Sun, 15 May 2005 18:19:18 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: Andrew Morton , netdev@oss.sgi.com, svallet@gmail.com Subject: Re: Fw: [Bugme-new] [Bug 4482] New: natsemi: incorrect initialization of IPv6 Neighbor-discovery multicast References: <20050413103642.172d3976.akpm@osdl.org> <20050416062416.GA29177@gondor.apana.org.au> In-Reply-To: <20050416062416.GA29177@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From jgarzik@pobox.com Sun May 15 15:21:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:21:53 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FMLoOv019751 for ; Sun, 15 May 2005 15:21:51 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXRU6-0004WC-Dg; Sun, 15 May 2005 22:21:18 +0000 Message-ID: <4287CB5B.7050403@pobox.com> Date: Sun, 15 May 2005 18:21:15 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Williams CC: netdev@oss.sgi.com, davem@davemloft.net, breed@users.sourceforge.net Subject: Re: resend: [PATCH 2.6.11.8] drivers/net/wireless/airo.c: airo WEXT and quality corrections References: <1115732751.16008.8.camel@dcbw.boston.redhat.com> In-Reply-To: <1115732751.16008.8.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1155 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From jgarzik@pobox.com Sun May 15 15:23:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:23:26 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FMNNOv020196 for ; Sun, 15 May 2005 15:23:23 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXRVX-0004WK-Ne; Sun, 15 May 2005 22:22:48 +0000 Message-ID: <4287CBB5.8060005@pobox.com> Date: Sun, 15 May 2005 18:22:45 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc3] pcnet32: fix resource leak with loopback test (with Signed-off-by) References: <20050429215117.GA1082@us.ibm.com> In-Reply-To: <20050429215117.GA1082@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1156 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 18 Lines: 2 applied to 2.6.x From jgarzik@pobox.com Sun May 15 15:25:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:25:02 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FMP0Ov020776 for ; Sun, 15 May 2005 15:25:00 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXRX5-0004WS-Vq; Sun, 15 May 2005 22:24:24 +0000 Message-ID: <4287CC15.4030301@pobox.com> Date: Sun, 15 May 2005 18:24:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: Andrew Morton , venza@brownhat.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [-mm patch] SIS900 must select MII References: <20050429231653.32d2f091.akpm@osdl.org> <20050430115249.GA3654@stusta.de> In-Reply-To: <20050430115249.GA3654@stusta.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1157 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From davem@davemloft.net Sun May 15 15:25:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:25:26 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FMPNOv020820 for ; Sun, 15 May 2005 15:25:23 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DXRXN-0002ns-Ld; Sun, 15 May 2005 15:24:41 -0700 Date: Sun, 15 May 2005 15:24:41 -0700 (PDT) Message-Id: <20050515.152441.106262257.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames From: "David S. Miller" In-Reply-To: <20050515114121.GA4830@gondor.apana.org.au> References: <20050515104016.GA24344@gondor.apana.org.au> <20050515114121.GA4830@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1158 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1849 Lines: 59 From: Herbert Xu Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames Date: Sun, 15 May 2005 21:41:21 +1000 > So let's go the other way and make this an invariant: > > For any skb on a frag_list, skb->sk must be NULL. > > That is, the socket ownership always belongs to the head skb. > It turns out that the implementation is actually pretty simple. Yes, I was just about to inform you that when SKBs are free'd up, only the head SKB's sk gets the destructor run on it. Please refer to this patch from July of 2004: [IPV4]: Fix multicast socket hangs. If a multicast packet gets looped back, the sending socket can hang if a local read just sits and does not empty its receive queue. The problem is that when an SKB clone is freed up, the destructor is only invoked for the head SKB when there is a fraglist (which is created for fragmentation). The solution is to account the fragment list SKB lengths in the top-level head SKB, then it all works out. Signed-off-by: David S. Miller --- 1/net/ipv4/ip_output.c 2005-05-15 15:23:19 -07:00 +++ 2/net/ipv4/ip_output.c 2005-05-15 15:23:19 -07:00 @@ -498,10 +498,6 @@ skb_headroom(frag) < hlen) goto slow_path; - /* Correct socket ownership. */ - if (frag->sk == NULL && skb->sk) - goto slow_path; - /* Partially cloned skb? */ if (skb_shared(frag)) goto slow_path; @@ -1113,12 +1109,10 @@ tail_skb = &(tmp_skb->next); skb->len += tmp_skb->len; skb->data_len += tmp_skb->len; -#if 0 /* Logically correct, but useless work, ip_fragment() will have to undo */ skb->truesize += tmp_skb->truesize; __sock_put(tmp_skb->sk); tmp_skb->destructor = NULL; tmp_skb->sk = NULL; -#endif } /* Unless user demanded real pmtu discovery (IP_PMTUDISC_DO), we allow From jgarzik@pobox.com Sun May 15 15:26:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 15:26:17 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FMQAOv021390 for ; Sun, 15 May 2005 15:26:10 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXRYC-0004Wb-W3; Sun, 15 May 2005 22:25:34 +0000 Message-ID: <4287CC5B.1020608@pobox.com> Date: Sun, 15 May 2005 18:25:31 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Stefaan De Roeck , netdev@oss.sgi.com Subject: Re: [PATCH] tlan: restore deleted module parameters. References: <20050504153311.7d1a0fe9@dxpl.pdx.osdl.net> In-Reply-To: <20050504153311.7d1a0fe9@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From jgarzik@pobox.com Sun May 15 16:16:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 16:16:41 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FNGdOv023524 for ; Sun, 15 May 2005 16:16:39 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXSKv-0004Yh-Na; Sun, 15 May 2005 23:15:56 +0000 Message-ID: <4287D826.3020704@pobox.com> Date: Sun, 15 May 2005 19:15:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akpm@osdl.org CC: davem@davemloft.net, christoph@graphe.net, tinay@chelsio.com, sbardone@chelsio.com, christoph@lameter.com, Netdev Subject: Re: [patch 02/10] A new 10GB Ethernet Driver by Chelsio Communications References: <200503302134.j2ULYLVO028974@shell0.pdx.osdl.net> In-Reply-To: <200503302134.j2ULYLVO028974@shell0.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1160 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From herbert@gondor.apana.org.au Sun May 15 16:21:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 16:21:15 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4FNL8Ov027660 for ; Sun, 15 May 2005 16:21:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXSPG-0000eP-00; Mon, 16 May 2005 09:20:22 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXSPE-0005Bz-00; Mon, 16 May 2005 09:20:20 +1000 Date: Mon, 16 May 2005 09:20:20 +1000 To: "David S. Miller" Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames Message-ID: <20050515232020.GA19859@gondor.apana.org.au> References: <20050515104016.GA24344@gondor.apana.org.au> <20050515114121.GA4830@gondor.apana.org.au> <20050515.152441.106262257.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050515.152441.106262257.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1161 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1901 Lines: 50 On Sun, May 15, 2005 at 03:24:41PM -0700, David S. Miller wrote: > > > So let's go the other way and make this an invariant: > > > > For any skb on a frag_list, skb->sk must be NULL. > > > > That is, the socket ownership always belongs to the head skb. > > It turns out that the implementation is actually pretty simple. > > Yes, I was just about to inform you that when SKBs are > free'd up, only the head SKB's sk gets the destructor run > on it. Dave, I'm actually agreeing with you :) My patch does these two things: 1) Do what you did below for IPv4 to IPv6 as well. 2) Do what the comment (the one that you removed below) said and actually undo the truesize aggregation on the fast path in ip*_fragment. I presume you won't have any problems with 1) since that's exactly the same as your patch below except that it's for IPv6. 2) is needed because on the fast path the frag_list is unraveled so it no longer makes sense to have the wmem all accounted to the head skb. Please note that we only undo the attribution if the frag is not shared. So the problem that your patch is meant fix won't occur here. > @@ -1113,12 +1109,10 @@ > tail_skb = &(tmp_skb->next); > skb->len += tmp_skb->len; > skb->data_len += tmp_skb->len; > -#if 0 /* Logically correct, but useless work, ip_fragment() will have to undo */ > skb->truesize += tmp_skb->truesize; > __sock_put(tmp_skb->sk); > tmp_skb->destructor = NULL; > tmp_skb->sk = NULL; > -#endif All I'm saying is that if we remove the #if 0 then we should do as it suggests and undo this accounting in ip_fragment. BTW, I missed the netfilter defrag code in my patch. I'll send an updated version soon. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun May 15 17:00:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 17:00:09 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G003Ov029117 for ; Sun, 15 May 2005 17:00:04 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXT0t-0000mz-00; Mon, 16 May 2005 09:59:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXT0r-0005H2-00; Mon, 16 May 2005 09:59:13 +1000 Date: Mon, 16 May 2005 09:59:13 +1000 To: "David S. Miller" Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames Message-ID: <20050515235913.GA20242@gondor.apana.org.au> References: <20050515104016.GA24344@gondor.apana.org.au> <20050515114121.GA4830@gondor.apana.org.au> <20050515.152441.106262257.davem@davemloft.net> <20050515232020.GA19859@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050515232020.GA19859@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1162 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 806 Lines: 22 On Mon, May 16, 2005 at 09:20:20AM +1000, herbert wrote: > > BTW, I missed the netfilter defrag code in my patch. I'll send an > updated version soon. Actually that turns out to be OK since ip_ct_gather_frags zeros the skb->sk field before feeding it to ip_defrag. Once the packet has been reassembled it tries to put the sk back which fails unless the head skb comes in last which is never the case on the output path. Although the second part is buggy, it does not violate the invariant I stated before. Please let me know if you still have any questions/problems with my patch. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Sun May 15 17:33:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 17:33:46 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G0XgOv030506 for ; Sun, 15 May 2005 17:33:42 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DXTXH-0003iO-23; Sun, 15 May 2005 17:32:43 -0700 Date: Sun, 15 May 2005 17:32:42 -0700 (PDT) Message-Id: <20050515.173242.125899783.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames From: "David S. Miller" In-Reply-To: <20050515235913.GA20242@gondor.apana.org.au> References: <20050515.152441.106262257.davem@davemloft.net> <20050515232020.GA19859@gondor.apana.org.au> <20050515235913.GA20242@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1163 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 479 Lines: 18 From: Herbert Xu Date: Mon, 16 May 2005 09:59:13 +1000 > Please let me know if you still have any questions/problems with my > patch. No objections, I see what you are doing now. It is basically the inverse of the case where we hold the frag truesizes in the head SKB. Once we rip apart the fraglist, we have to repropagate the truesize and sock ownership down from the head SKB to the frags. I'll apply your patch, and Evgeniy's too. Thanks. From davem@davemloft.net Sun May 15 17:40:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 17:40:33 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G0eUOv031157 for ; Sun, 15 May 2005 17:40:30 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DXTe4-000451-Mz; Sun, 15 May 2005 17:39:44 -0700 Date: Sun, 15 May 2005 17:39:44 -0700 (PDT) Message-Id: <20050515.173944.122590923.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames From: "David S. Miller" In-Reply-To: <20050515235913.GA20242@gondor.apana.org.au> References: <20050515.152441.106262257.davem@davemloft.net> <20050515232020.GA19859@gondor.apana.org.au> <20050515235913.GA20242@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1164 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 530 Lines: 13 From: Herbert Xu Date: Mon, 16 May 2005 09:59:13 +1000 > Actually that turns out to be OK since ip_ct_gather_frags zeros the > skb->sk field before feeding it to ip_defrag. Once the packet has > been reassembled it tries to put the sk back which fails unless the > head skb comes in last which is never the case on the output path. > > Although the second part is buggy, it does not violate the invariant > I stated before. This code should therefore just skb_orphan(), and nothing more. Right? From herbert@gondor.apana.org.au Sun May 15 18:01:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 18:01:52 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G11jOv032177 for ; Sun, 15 May 2005 18:01:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXTye-00011p-00; Mon, 16 May 2005 11:01:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXTyc-0005OT-00; Mon, 16 May 2005 11:00:58 +1000 Date: Mon, 16 May 2005 11:00:58 +1000 To: "David S. Miller" Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames Message-ID: <20050516010058.GA20704@gondor.apana.org.au> References: <20050515.152441.106262257.davem@davemloft.net> <20050515232020.GA19859@gondor.apana.org.au> <20050515235913.GA20242@gondor.apana.org.au> <20050515.173944.122590923.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050515.173944.122590923.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1165 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 585 Lines: 17 On Sun, May 15, 2005 at 05:39:44PM -0700, David S. Miller wrote: > > This code should therefore just skb_orphan(), and nothing > more. Right? Ideally we should move the ownership to the head skb here as well. However, doing this would cause havoc when you have nasty users sending fragments from two different sockets :) So let's stick with just the skb_orphan. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dgibson@ozlabs.org Sun May 15 18:09:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 18:09:57 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G19kOv000378 for ; Sun, 15 May 2005 18:09:47 -0700 Received: by ozlabs.org (Postfix, from userid 1007) id EAF6467A04; Mon, 16 May 2005 11:09:12 +1000 (EST) Date: Mon, 16 May 2005 11:06:59 +1000 From: David Gibson To: Christoph Hellwig Cc: jgarzik@pobox.com, proski@gnu.org, netdev@oss.sgi.com Subject: Re: [PATCH 8/12] orinoco: manual roaming for Symbol and Intersilfirmware Message-ID: <20050516010659.GI6053@localhost.localdomain> References: <20050514153041.GI3643@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050514153041.GI3643@lst.de> User-Agent: Mutt/1.5.6+20040907i X-archive-position: 1167 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 7766 Lines: 255 On Sat, May 14, 2005 at 05:30:41PM +0200, Christoph Hellwig wrote: > Patch from Pavel Roskin Acked-by: David Gibson > Index: linux-2.6/drivers/net/wireless/orinoco.h > =================================================================== > +++ linux-2.6/drivers/net/wireless/orinoco.h 2005-05-14 17:03:00.000000000 +0200 > @@ -22,6 +22,8 @@ > > #define WIRELESS_SPY // enable iwspy support > > +#define MAX_SCAN_LEN 4096 > + > #define ORINOCO_MAX_KEY_SIZE 14 > #define ORINOCO_MAX_KEYS 4 > > @@ -48,6 +50,7 @@ > /* driver state */ > int open; > u16 last_linkstatus; > + struct work_struct join_work; > > /* Net device stuff */ > struct net_device *ndev; > @@ -84,6 +87,8 @@ > int bitratemode; > char nick[IW_ESSID_MAX_SIZE+1]; > char desired_essid[IW_ESSID_MAX_SIZE+1]; > + char desired_bssid[ETH_ALEN]; > + int bssid_fixed; > u16 frag_thresh, mwo_robust; > u16 channel; > u16 ap_density, rts_thresh; > Index: linux-2.6/drivers/net/wireless/orinoco.c > =================================================================== > +++ linux-2.6/drivers/net/wireless/orinoco.c 2005-05-14 17:03:00.000000000 +0200 > @@ -1247,6 +1247,75 @@ > dev->name, s, status); > } > > +/* Search scan results for requested BSSID, join it if found */ > +static void orinoco_join_ap(struct net_device *dev) > +{ > + struct orinoco_private *priv = netdev_priv(dev); > + struct hermes *hw = &priv->hw; > + int err; > + unsigned long flags; > + struct join_req { > + u8 bssid[ETH_ALEN]; > + u16 channel; > + } __attribute__ ((packed)) req; > + const int atom_len = offsetof(struct prism2_scan_apinfo, atim); > + struct prism2_scan_apinfo *atom; > + int offset = 4; > + u8 *buf; > + u16 len; > + > + /* Allocate buffer for scan results */ > + buf = kmalloc(MAX_SCAN_LEN, GFP_KERNEL); > + if (! buf) > + return; > + > + if (orinoco_lock(priv, &flags) != 0) > + goto out; > + > + /* Sanity checks in case user changed something in the meantime */ > + if (! priv->bssid_fixed) > + goto out; > + > + if (strlen(priv->desired_essid) == 0) > + goto out; > + > + /* Read scan results from the firmware */ > + err = hermes_read_ltv(hw, USER_BAP, > + HERMES_RID_SCANRESULTSTABLE, > + MAX_SCAN_LEN, &len, buf); > + if (err) { > + printk(KERN_ERR "%s: Cannot read scan results\n", > + dev->name); > + goto out; > + } > + > + len = HERMES_RECLEN_TO_BYTES(len); > + > + /* Go through the scan results looking for the channel of the AP > + * we were requested to join */ > + for (; offset + atom_len <= len; offset += atom_len) { > + atom = (struct prism2_scan_apinfo *) (buf + offset); > + if (memcmp(&atom->bssid, priv->desired_bssid, ETH_ALEN) == 0) > + goto found; > + } > + > + DEBUG(1, "%s: Requested AP not found in scan results\n", > + dev->name); > + goto out; > + > + found: > + memcpy(req.bssid, priv->desired_bssid, ETH_ALEN); > + req.channel = atom->channel; /* both are little-endian */ > + err = HERMES_WRITE_RECORD(hw, USER_BAP, HERMES_RID_CNFJOINREQUEST, > + &req); > + if (err) > + printk(KERN_ERR "%s: Error issuing join request\n", dev->name); > + > + out: > + kfree(buf); > + orinoco_unlock(priv, &flags); > +} > + > static void __orinoco_ev_info(struct net_device *dev, hermes_t *hw) > { > struct orinoco_private *priv = netdev_priv(dev); > @@ -1477,6 +1546,36 @@ > return err; > } > > +/* Set fixed AP address */ > +static int __orinoco_hw_set_wap(struct orinoco_private *priv) > +{ > + int roaming_flag; > + int err = 0; > + hermes_t *hw = &priv->hw; > + > + switch (priv->firmware_type) { > + case FIRMWARE_TYPE_AGERE: > + /* not supported */ > + break; > + case FIRMWARE_TYPE_INTERSIL: > + if (priv->bssid_fixed) > + roaming_flag = 2; > + else > + roaming_flag = 1; > + > + err = hermes_write_wordrec(hw, USER_BAP, > + HERMES_RID_CNFROAMINGMODE, > + roaming_flag); > + break; > + case FIRMWARE_TYPE_SYMBOL: > + err = HERMES_WRITE_RECORD(hw, USER_BAP, > + HERMES_RID_CNFMANDATORYBSSID_SYMBOL, > + &priv->desired_bssid); > + break; > + } > + return err; > +} > + > /* Change the WEP keys and/or the current keys. Can be called > * either from __orinoco_hw_setup_wep() or directly from > * orinoco_ioctl_setiwencode(). In the later case the association > @@ -1662,6 +1761,13 @@ > } > } > > + /* Set the desired BSSID */ > + err = __orinoco_hw_set_wap(priv); > + if (err) { > + printk(KERN_ERR "%s: Error %d setting AP address\n", > + dev->name, err); > + return err; > + } > /* Set the desired ESSID */ > idbuf.len = cpu_to_le16(strlen(priv->desired_essid)); > memcpy(&idbuf.val, priv->desired_essid, sizeof(idbuf.val)); > @@ -2432,6 +2538,7 @@ > * before anything else touches the > * hardware */ > INIT_WORK(&priv->reset_work, (void (*)(void *))orinoco_reset, dev); > + INIT_WORK(&priv->join_work, (void (*)(void *))orinoco_join_ap, dev); > > netif_carrier_off(dev); > priv->last_linkstatus = 0xffff; > @@ -2593,6 +2700,67 @@ > return 0; > } > > +static int orinoco_ioctl_setwap(struct net_device *dev, > + struct iw_request_info *info, > + struct sockaddr *ap_addr, > + char *extra) > +{ > + struct orinoco_private *priv = netdev_priv(dev); > + int err = -EINPROGRESS; /* Call commit handler */ > + unsigned long flags; > + static const u8 off_addr[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; > + static const u8 any_addr[] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; > + > + if (orinoco_lock(priv, &flags) != 0) > + return -EBUSY; > + > + /* Enable automatic roaming - no sanity checks are needed */ > + if (memcmp(&ap_addr->sa_data, off_addr, ETH_ALEN) == 0 || > + memcmp(&ap_addr->sa_data, any_addr, ETH_ALEN) == 0) { > + priv->bssid_fixed = 0; > + memset(priv->desired_bssid, 0, ETH_ALEN); > + > + /* "off" means keep existing connection */ > + if (ap_addr->sa_data[0] == 0) { > + __orinoco_hw_set_wap(priv); > + err = 0; > + } > + goto out; > + } > + > + if (priv->firmware_type == FIRMWARE_TYPE_AGERE) { > + printk(KERN_WARNING "%s: Lucent/Agere firmware doesn't " > + "support manual roaming\n", > + dev->name); > + err = -EOPNOTSUPP; > + goto out; > + } > + > + if (priv->iw_mode != IW_MODE_INFRA) { > + printk(KERN_WARNING "%s: Manual roaming supported only in " > + "managed mode\n", dev->name); > + err = -EOPNOTSUPP; > + goto out; > + } > + > + /* Intersil firmware hangs without Desired ESSID */ > + if (priv->firmware_type == FIRMWARE_TYPE_INTERSIL && > + strlen(priv->desired_essid) == 0) { > + printk(KERN_WARNING "%s: Desired ESSID must be set for " > + "manual roaming\n", dev->name); > + err = -EOPNOTSUPP; > + goto out; > + } > + > + /* Finally, enable manual roaming */ > + priv->bssid_fixed = 1; > + memcpy(priv->desired_bssid, &ap_addr->sa_data, ETH_ALEN); > + > + out: > + orinoco_unlock(priv, &flags); > + return err; > +} > + > static int orinoco_ioctl_getwap(struct net_device *dev, > struct iw_request_info *info, > struct sockaddr *ap_addr, > @@ -3890,6 +4058,7 @@ > [SIOCGIWRANGE -SIOCIWFIRST] (iw_handler) orinoco_ioctl_getiwrange, > [SIOCSIWSPY -SIOCIWFIRST] (iw_handler) orinoco_ioctl_setspy, > [SIOCGIWSPY -SIOCIWFIRST] (iw_handler) orinoco_ioctl_getspy, > + [SIOCSIWAP -SIOCIWFIRST] (iw_handler) orinoco_ioctl_setwap, > [SIOCGIWAP -SIOCIWFIRST] (iw_handler) orinoco_ioctl_getwap, > [SIOCSIWESSID -SIOCIWFIRST] (iw_handler) orinoco_ioctl_setessid, > [SIOCGIWESSID -SIOCIWFIRST] (iw_handler) orinoco_ioctl_getessid, > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/people/dgibson From dgibson@ozlabs.org Sun May 15 18:09:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 18:09:57 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G19jOv000360 for ; Sun, 15 May 2005 18:09:46 -0700 Received: by ozlabs.org (Postfix, from userid 1007) id C136A679E6; Mon, 16 May 2005 11:09:12 +1000 (EST) Date: Mon, 16 May 2005 11:04:48 +1000 From: David Gibson To: Christoph Hellwig Cc: jgarzik@pobox.com, proski@gnu.org, netdev@oss.sgi.com Subject: Re: [PATCH 3/12] orinoco: Symbol 3.0x firmware needs broken_disableport Message-ID: <20050516010448.GD6053@localhost.localdomain> References: <20050514153010.GD3643@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050514153010.GD3643@lst.de> User-Agent: Mutt/1.5.6+20040907i X-archive-position: 1166 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 935 Lines: 24 On Sat, May 14, 2005 at 05:30:10PM +0200, Christoph Hellwig wrote: > Patch from Pavel Roskin. Acked-by: David Gibson > Index: linux-2.6/drivers/net/wireless/orinoco.c > =================================================================== > +++ linux-2.6/drivers/net/wireless/orinoco.c 2005-05-14 16:57:39.000000000 +0200 > @@ -2223,6 +2223,8 @@ > firmver >= 0x31000; > priv->has_preamble = (firmver >= 0x20000); > priv->ibss_port = 4; > + priv->broken_disableport = (firmver == 0x25013) || > + (firmver >= 0x30000 && firmver <= 0x31000); > /* Tested with Intel firmware : 0x20015 => Jean II */ > /* Tested with 3Com firmware : 0x15012 & 0x22001 => Jean II */ > break; > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/people/dgibson From jgarzik@pobox.com Sun May 15 19:25:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 19:25:08 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G2P3Ov003730 for ; Sun, 15 May 2005 19:25:03 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXVHP-0004bk-3O; Mon, 16 May 2005 02:24:28 +0000 Message-ID: <42880458.5070404@pobox.com> Date: Sun, 15 May 2005 22:24:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krzysztof Halasa CC: netdev@oss.sgi.com Subject: Re: [PATCH][RESENT] Generic HDLC update References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From jgarzik@pobox.com Sun May 15 20:23:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 20:23:12 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G3NAOv009061 for ; Sun, 15 May 2005 20:23:10 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXWBh-0004dp-9X; Mon, 16 May 2005 03:22:37 +0000 Message-ID: <428811FB.1050308@pobox.com> Date: Sun, 15 May 2005 23:22:35 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?J=F6rn_Engel?= CC: netdev@oss.sgi.com Subject: Re: [PATCH] reduce stack usage for arlan References: <20050308153457.GB8703@wohnheim.fh-wedel.de> In-Reply-To: <20050308153457.GB8703@wohnheim.fh-wedel.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 1178 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 390 Lines: 18 Jörn Engel wrote: > Jean Tourrilhes indicated that this driver is currently unmaintained. > Jeff, do you want this patch? > #define SARLSTR(var,nn) {\ > - char tmpStr[400];\ > + char tmpStr[50];\ > int tmpLn = nn;\ > - if (nn > 399 ) tmpLn = 399; \ > + BUG_ON(tmpLn > 49);\ I'm uncomfortable with arbitrarily lowering the string size, even if it does include a BUG_ON()... Jeff From jgarzik@pobox.com Sun May 15 21:07:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 21:07:31 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G47QOv011195 for ; Sun, 15 May 2005 21:07:26 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXWsU-0004mo-R9; Mon, 16 May 2005 04:06:51 +0000 Message-ID: <42881C58.40001@pobox.com> Date: Mon, 16 May 2005 00:06:48 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akpm@osdl.org CC: T-Bone@parisc-linux.org, grundler@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> In-Reply-To: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 592 Lines: 23 akpm@osdl.org wrote: > + > + /* flush posted writes */ > + ioread32(ioaddr + CSR15); > + > + /* Sect 3.10.3 in DP83840A.pdf (p39) */ > + udelay(500); > + > + /* Section 4.2 in DP83840A.pdf (p43) */ > + /* and IEEE 802.3 "22.2.4.1.1 Reset" */ > + while (timeout-- && > + (tulip_mdio_read (dev, phy_num, MII_BMCR) & BMCR_RESET)) > + udelay(100); Note that while the patch creates the correct behavior, the delays above occur inside spin_lock_irqsave() and/or timer context. I have been to get HP to fix this patch's delay problem for -years-. Jeff From grundler@lackof.org Sun May 15 22:06:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 15 May 2005 22:06:15 -0700 (PDT) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G56COv013212 for ; Sun, 15 May 2005 22:06:12 -0700 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id 8197729803C; Sun, 15 May 2005 23:08:43 -0600 (MDT) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21497-10; Sun, 15 May 2005 23:08:43 -0600 (MDT) Received: by colo.lackof.org (Postfix, from userid 27253) id 244F529800A; Sun, 15 May 2005 23:08:43 -0600 (MDT) Date: Sun, 15 May 2005 23:08:43 -0600 From: Grant Grundler To: Jeff Garzik Cc: akpm@osdl.org, T-Bone@parisc-linux.org, grundler@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree Message-ID: <20050516050843.GA20107@colo.lackof.org> References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42881C58.40001@pobox.com> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.9i X-archive-position: 1180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev Content-Length: 1257 Lines: 31 On Mon, May 16, 2005 at 12:06:48AM -0400, Jeff Garzik wrote: > Note that while the patch creates the correct behavior, the delays above > occur inside spin_lock_irqsave() and/or timer context. Yes. Agreed. So what? If tulip phy init code is hit so often *and* seeing the worst case 2ms delay that it's a problem, the delay doesn't matter. Something else is fundamentally wrong. Fixing code that doesn't comply with published specs and has been proven to not work on at least 3 archs seems a bit more important than an occasional < 1ms (normal case) delay. > I have been to get HP to fix this patch's delay problem for -years-. I was "encouraged" to rewrite the tulip phy init sequence in 2002 to use schedule_timeout() and heard a claim it would be trivial. I looked into it and concluded it was NOT trivial. I approached Jeff at OLS2002 (or 2003) and explained why I thought it was NOT trivial. Didn't get a response that resolved any of the concerns I raised. I'd be willing to take another look at fresh ideas once all of the tulip patches I have ouststanding go in. If the original suggestion really were trivial, we wouldn't be having this conversation now. Some high school student would have taken care of it by now, right? thanks, grant From SRS0+6e55e3d2fbbe9ac94b6b+631+infradead.org+hch@pentafluge.srs.infradead.org Mon May 16 00:13:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 00:13:22 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4G7D6Ov024176 for ; Mon, 16 May 2005 00:13:17 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DXZly-0004bi-V9; Mon, 16 May 2005 08:12:18 +0100 Date: Mon, 16 May 2005 08:12:18 +0100 From: Christoph Hellwig To: Jeff Garzik Cc: akpm@osdl.org, davem@davemloft.net, christoph@graphe.net, tinay@chelsio.com, sbardone@chelsio.com, christoph@lameter.com, Netdev Subject: Re: [patch 02/10] A new 10GB Ethernet Driver by Chelsio Communications Message-ID: <20050516071218.GA17589@infradead.org> References: <200503302134.j2ULYLVO028974@shell0.pdx.osdl.net> <4287D826.3020704@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4287D826.3020704@pobox.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 1181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 129 Lines: 5 On Sun, May 15, 2005 at 07:15:50PM -0400, Jeff Garzik wrote: > applied to what tree? the driver is still a rather huge mess.. From akpm@osdl.org Mon May 16 03:00:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 03:00:29 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GA0MOv002573 for ; Mon, 16 May 2005 03:00:23 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4G9xgU3031950 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 16 May 2005 02:59:43 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4G9xdOq027159; Mon, 16 May 2005 02:59:39 -0700 Date: Mon, 16 May 2005 02:59:01 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: hejianj@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, Anton Blanchard Subject: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-Id: <20050516025901.4b26ccf3.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1182 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 3137 Lines: 92 Might be a bug in the e100 driver, might not be. I assume this is the BUG_ON(skb->list != NULL); in __kfree_skb(), although the line number is off-by-one, and the .__kfree_skb+0x188/0x240 would tend to contradict that. Anton, can you help work out where we went splat please? tx timeouts are fairly rare events, so this might not be a recently-added bug. Do we know if it is repeatable? Begin forwarded message: Date: Mon, 16 May 2005 02:44:04 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 http://bugme.osdl.org/show_bug.cgi?id=4628 Summary: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Kernel Version: 2.6.12-rc1 with mm4 patch Status: NEW Severity: normal Owner: anton@samba.org Submitter: hejianj@cn.ibm.com CC: hanwenb@cn.ibm.com,mridge@us.ibm.com,rende@cn.ibm.com,wa ngjs@cn.ibm.com Distribution: RHEL4 with kernel 2.6.12-rc1-mm4 Hardware Environment: IBM OpenPower( CHRP IBM,9124-720 ) Software Environment: RHEL4 RHR: rhr2-rhel4-1.0-14a.noarch.rpm Problem Description: The test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4. Steps to reproduce: 1. Download kernel 2.6.12-rc1 and 2.6.12-rc1-mm4 patch from kernel.org, then build the kernel on OpenPower 720 2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and install it on the test machine. 3. Configure and run the rhr test via invoking redhat-ready. Additional information: Here is the backtrace from xmon. 3:mon> e cpu 0x3: Vector: 700 (Program Check) at [c00000000ffe7920] pc: c00000000029632c: .__kfree_skb+0x188/0x240 lr: c000000000296328: .__kfree_skb+0x184/0x240 sp: c00000000ffe7ba0 msr: 8000000000029032 current = 0xc000000107f94040 paca = 0xc000000000431c00 pid = 0, comm = swapper kernel BUG in __kfree_skb at net/core/skbuff.c:282! 3:mon> t [c00000000ffe7c40] d0000000000ebac4 .e100_rx_clean_list+0xa0/0x144 [e100] [c00000000ffe7ce0] d0000000000ed6dc .e100_tx_timeout+0x7c/0xb0 [e100] [c00000000ffe7d70] c0000000002b87bc .dev_watchdog+0xc8/0x154 [c00000000ffe7e00] c00000000006d6b4 .run_timer_softirq+0x180/0x298 [c00000000ffe7ed0] c0000000000667d8 .__do_softirq+0xdc/0x1b8 [c00000000ffe7f90] c000000000014bf0 .call_do_softirq+0x14/0x24 [c000000086b43860] c0000000000102c4 .do_softirq+0x98/0xac [c000000086b438f0] c0000000000669cc .irq_exit+0x70/0x8c [c000000086b43970] c000000000011fb8 .timer_interrupt+0x398/0x47c [c000000086b43a90] c00000000000a2b4 decrementer_common+0xb4/0x100 --- Exception: 901 (Decrementer) at c000000000010554 .dedicated_idle+0x114/0x280 [c000000086b43e80] c0000000000108c8 .cpu_idle+0x3c/0x54 [c000000086b43f00] c00000000003cc8c .start_secondary+0x108/0x148 [c000000086b43f90] c00000000000bd84 .enable_64b_mode+0x0/0x28 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From hejianj@cn.ibm.com Mon May 16 03:41:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 03:41:03 -0700 (PDT) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.com [202.81.18.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GAetOv004428 for ; Mon, 16 May 2005 03:40:58 -0700 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id j4GAaIOF362204 for ; Mon, 16 May 2005 20:36:18 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.250.244]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4GAh8NM038354 for ; Mon, 16 May 2005 20:43:12 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11/8.13.3) with ESMTP id j4GAeEJ4010243 for ; Mon, 16 May 2005 20:40:14 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av03.au.ibm.com (8.12.11/8.12.11) with ESMTP id j4GAeCZc010173; Mon, 16 May 2005 20:40:12 +1000 In-Reply-To: <20050516025901.4b26ccf3.akpm@osdl.org> Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 To: Andrew Morton Cc: Anton Blanchard , linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com, Dang En Ren , Jia Sen Wang , Lei CDL Wang X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Jian Jun He Date: Mon, 16 May 2005 18:41:43 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 05/16/2005 18:41:46 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D" X-archive-position: 1183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hejianj@cn.ibm.com Precedence: bulk X-list: netdev Content-Length: 15457 Lines: 437 --0__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D Content-type: multipart/alternative; Boundary="1__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D" --1__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable This is a reproducible defect. At first, I can't believe that the server will suspend. But I retested = the rhr and the server hung up again. So I captured the backtrace from xmon= . BTW, the e100 driver version is 3.3.6-k2. To Andrew: Re-send the mail with CC list. Thanks. Best Regards! Jian Jun He CSDL, Beijing Email: hejianj@cn.ibm.com = Andrew Morton = = = To 2005-05-16 17:59 netdev@oss.sgi.com = = cc Jian Jun He/China/Contr/IBM@IBMC= N, linuxppc64-dev@lists.linuxppc.or= g, Anton Blanchard Subj= ect Fw: [Bugme-new] [Bug 4628] New: = Test server hang while running r= hr (network) test on RHEL4 with ker= nel 2.6.12-rc1-mm4 = = = = = = = Might be a bug in the e100 driver, might not be. I assume this is the BUG_ON(skb->list !=3D NULL); in __kfree_skb(), although the line number is off-by-one, and the .__kfree_skb+0x188/0x240 would tend to contradict that. Anton, can you= help work out where we went splat please? tx timeouts are fairly rare events, so this might not be a recently-add= ed bug. Do we know if it is repeatable? Begin forwarded message: Date: Mon, 16 May 2005 02:44:04 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4628] New: Test server hang while running rhr= (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 http://bugme.osdl.org/show_bug.cgi?id=3D4628 Summary: Test server hang while running rhr (network) test o= n RHEL4 with kernel 2.6.12-rc1-mm4 Kernel Version: 2.6.12-rc1 with mm4 patch Status: NEW Severity: normal Owner: anton@samba.org Submitter: hejianj@cn.ibm.com CC: hanwenb@cn.ibm.com,mridge@us.ibm.com,rende@cn.ibm.com,wa ngjs@cn.ibm.com Distribution: RHEL4 with kernel 2.6.12-rc1-mm4 Hardware Environment: IBM OpenPower( CHRP IBM,9124-720 ) Software Environment: RHEL4 RHR: rhr2-rhel4-1.0-14a.noarch.rpm Problem Description: The test server hang while running rhr (network) test on RHEL4 with ker= nel 2.6.12-rc1-mm4. Steps to reproduce: 1. Download kernel 2.6.12-rc1 and 2.6.12-rc1-mm4 patch from kernel.org,= then build the kernel on OpenPower 720 2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and insta= ll it on the test machine. 3. Configure and run the rhr test via invoking redhat-ready. Additional information: Here is the backtrace from xmon. 3:mon> e cpu 0x3: Vector: 700 (Program Check) at [c00000000ffe7920] pc: c00000000029632c: .__kfree_skb+0x188/0x240 lr: c000000000296328: .__kfree_skb+0x184/0x240 sp: c00000000ffe7ba0 msr: 8000000000029032 current =3D 0xc000000107f94040 paca =3D 0xc000000000431c00 pid =3D 0, comm =3D swapper kernel BUG in __kfree_skb at net/core/skbuff.c:282! 3:mon> t [c00000000ffe7c40] d0000000000ebac4 .e100_rx_clean_list+0xa0/0x144 [e10= 0] [c00000000ffe7ce0] d0000000000ed6dc .e100_tx_timeout+0x7c/0xb0 [e100] [c00000000ffe7d70] c0000000002b87bc .dev_watchdog+0xc8/0x154 [c00000000ffe7e00] c00000000006d6b4 .run_timer_softirq+0x180/0x298 [c00000000ffe7ed0] c0000000000667d8 .__do_softirq+0xdc/0x1b8 [c00000000ffe7f90] c000000000014bf0 .call_do_softirq+0x14/0x24 [c000000086b43860] c0000000000102c4 .do_softirq+0x98/0xac [c000000086b438f0] c0000000000669cc .irq_exit+0x70/0x8c [c000000086b43970] c000000000011fb8 .timer_interrupt+0x398/0x47c [c000000086b43a90] c00000000000a2b4 decrementer_common+0xb4/0x100 --- Exception: 901 (Decrementer) at c000000000010554 .dedicated_idle+0x114/0x280 [c000000086b43e80] c0000000000108c8 .cpu_idle+0x3c/0x54 [c000000086b43f00] c00000000003cc8c .start_secondary+0x108/0x148 [c000000086b43f90] c00000000000bd84 .enable_64b_mode+0x0/0x28 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. = --1__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

This is a reproducible defect.
At first, I can't believe that the server will suspend. But I retested = the rhr and the server hung up again. So I captured the backtrace from = xmon.

BTW, the e100 driver version is 3.3.6-k2.


To Andrew:
Re-send the mail with CC list. Thanks.


Best Regards!

Jian Jun He

CSDL, Beijing
Email: hejianj@cn.ibm.com

3D"InactiveAndrew Morton <akpm@osdl.org>
=

=
          Andrew Morton <akpm@osdl.org><= font size=3D"2">

          2005-05-16 17:59

 =
3D""
To
3D""
netdev@oss.sgi.com
3D""
cc
3D""
Jian Jun He/China/Contr/IBM@IBMCN, linuxppc64-dev@list= s.linuxppc.org, Anton Blanchard <anton@samba.org>
3D""
Subject
3D""
Fw: [Bugme-new] [Bug 4628] New: Test server hang while= running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4<= /td>
3D=3D""


Might be a bug in the e100 driver, might not be.

I assume this is the

BUG_ON(skb->list !=3D NULL);

in __kfree_skb(), although the line number is off-by-one, and the
.__kfree_skb+0x188/0x240 would tend to contradict that.  Anton, ca= n you
help work out where we went splat please?

tx timeouts are fairly rare events, so this might not be a recently-add= ed
bug.

Do we know if it is repeatable?



Begin forwarded message:

Date: Mon, 16 May 2005 02:44:04 -0700
From: bugme-daemon@osdl.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 4628] New: Test server hang while running rhr= (network) test on RHEL4 with kernel 2.6.12-rc1-mm4


http:= //bugme.osdl.org/show_bug.cgi?id=3D4628

          Summary: Test server hang while run= ning rhr (network) test on
                   R= HEL4 with kernel 2.6.12-rc1-mm4
   Kernel Version: 2.6.12-rc1 with mm4 patch
           Status: NEW
         Severity: normal
            Owner: anton@samba.org
        Submitter: hejianj@cn.ibm.com
               CC: hanwenb@cn.= ibm.com,mridge@us.ibm.com,rende@cn.ibm.com,wa
                   n= gjs@cn.ibm.com


Distribution:
RHEL4 with kernel 2.6.12-rc1-mm4

Hardware Environment:
IBM OpenPower( CHRP IBM,9124-720 )

Software Environment:
RHEL4
RHR: rhr2-rhel4-1.0-14a.noarch.rpm

Problem Description:
The test server hang while running rhr (network) test on RHEL4 with ker= nel
2.6.12-rc1-mm4.

Steps to reproduce:
1. Download kernel 2.6.12-rc1 and 2.6.12-rc1-mm4 patch from kernel.org,= then
build the kernel on OpenPower 720
2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and insta= ll it on
the test machine.
3. Configure and run the rhr test via invoking redhat-ready.

Additional information:
Here is the backtrace from xmon.

3:mon> e
cpu 0x3: Vector: 700 (Program Check) at [c00000000ffe7920]
   pc: c00000000029632c: .__kfree_skb+0x188/0x240
   lr: c000000000296328: .__kfree_skb+0x184/0x240
   sp: c00000000ffe7ba0
  msr: 8000000000029032
 current =3D 0xc000000107f94040
 paca    =3D 0xc000000000431c00
   pid   =3D 0, comm =3D swapper
kernel BUG in __kfree_skb at net/core/skbuff.c:282!

3:mon> t
[c00000000ffe7c40] d0000000000ebac4 .e100_rx_clean_list+0xa0/0x144 [e10= 0]
[c00000000ffe7ce0] d0000000000ed6dc .e100_tx_timeout+0x7c/0xb0 [e100] [c00000000ffe7d70] c0000000002b87bc .dev_watchdog+0xc8/0x154
[c00000000ffe7e00] c00000000006d6b4 .run_timer_softirq+0x180/0x298
[c00000000ffe7ed0] c0000000000667d8 .__do_softirq+0xdc/0x1b8
[c00000000ffe7f90] c000000000014bf0 .call_do_softirq+0x14/0x24
[c000000086b43860] c0000000000102c4 .do_softirq+0x98/0xac
[c000000086b438f0] c0000000000669cc .irq_exit+0x70/0x8c
[c000000086b43970] c000000000011fb8 .timer_interrupt+0x398/0x47c
[c000000086b43a90] c00000000000a2b4 decrementer_common+0xb4/0x100
--- Exception: 901 (Decrementer) at c000000000010554 .dedicated_idle+0x= 114/0x280
[c000000086b43e80] c0000000000108c8 .cpu_idle+0x3c/0x54
[c000000086b43f00] c00000000003cc8c .start_secondary+0x108/0x148
[c000000086b43f90] c00000000000bd84 .enable_64b_mode+0x0/0x28

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
=
= --1__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D-- --0__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=C7BBFA90DFA9D98D8f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D Content-type: image/gif; name="pic29038.gif" Content-Disposition: inline; filename="pic29038.gif" Content-ID: <2__=C7BBFA90DFA9D98D8f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=C7BBFA90DFA9D98D8f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=C7BBFA90DFA9D98D8f9e8a93df938690918cC7BBFA90DFA9D98D-- From herbert@gondor.apana.org.au Mon May 16 04:02:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 04:02:04 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GB1wOv006645 for ; Mon, 16 May 2005 04:01:59 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXdLM-0004Br-00; Mon, 16 May 2005 21:01:04 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXdL8-0005mE-00; Mon, 16 May 2005 21:00:50 +1000 From: Herbert Xu To: akpm@osdl.org (Andrew Morton) Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Cc: netdev@oss.sgi.com, hejianj@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, anton@samba.org, jgarzik@pobox.com Organization: Core In-Reply-To: <20050516025901.4b26ccf3.akpm@osdl.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 16 May 2005 21:00:50 +1000 X-archive-position: 1184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 780 Lines: 29 Andrew Morton wrote: > > Might be a bug in the e100 driver, might not be. > > I assume this is the > > BUG_ON(skb->list != NULL); It certainly is a bug in e100. e100_tx_timeout -> e100_down -> e100_rx_clean_list is racing against e100_poll -> e100_rx_clean -> e100_rx_indicate e100_rx_clean/e100_rx_indicate takes an skb off the RX ring and while it's being processed e100_rx_clean_list comes along and frees it. From a quick check similar problems may exist in other drivers that have lockless ->poll() functions with RX rings. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From util@deuroconsult.ro Mon May 16 06:01:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 06:01:55 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GD1mOv017398 for ; Mon, 16 May 2005 06:01:52 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4GD1A7S016890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 May 2005 16:01:10 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4GD18KM016879; Mon, 16 May 2005 16:01:08 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Mon, 16 May 2005 16:01:07 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: netdev@oss.sgi.com cc: davem@davemloft.net Subject: [PATCH] [SCHED] Fix unlock spinlock in error path Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1646943047-1586944306-1116248155=:13294" Content-ID: X-archive-position: 1185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1878 Lines: 48 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1646943047-1586944306-1116248155=:13294 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Hello! In act_api.c::tcf_action_copy_stats, in error path (get_stats returns < 0), the spinlock taken in gnet_stats_start_copy_compat or gnet_stats_start_copy is not unlocked. The attached patch fixes this. Please, apply. Thank you very much! Signed-off-by: Catalin(ux aka Dino) BOIE --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ---1646943047-1586944306-1116248155=:13294 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=act_api_missing_unlock.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=act_api_missing_unlock.patch LS0tIGxpbnV4L25ldC9zY2hlZC9hY3RfYXBpLmMJMjAwNS0wMy0wMiAwOToz ODozMy4wMDAwMDAwMDAgKzAyMDANCisrKyB0b3ZidWcvbmV0L3NjaGVkL2Fj dF9hcGkuYwkyMDA1LTA0LTE1IDEzOjI3OjU0LjAwMDAwMDAwMCArMDMwMA0K QEAgLTQwMSw3ICs0MDEsNyBAQCBpbnQgdGNmX2FjdGlvbl9jb3B5X3N0YXRz KHN0cnVjdCBza19idWZmDQogDQogCWlmIChhLT5vcHMgIT0gTlVMTCAmJiBh LT5vcHMtPmdldF9zdGF0cyAhPSBOVUxMKQ0KIAkJaWYgKGEtPm9wcy0+Z2V0 X3N0YXRzKHNrYiwgYSkgPCAwKQ0KLQkJCWdvdG8gZXJyb3V0Ow0KKwkJCWdv dG8gZXJyb3V0X3N0b3Bfc3RhdHM7DQogDQogCWlmIChnbmV0X3N0YXRzX2Nv cHlfYmFzaWMoJmQsICZoLT5ic3RhdHMpIDwgMCB8fA0KICNpZmRlZiBDT05G SUdfTkVUX0VTVElNQVRPUg0KQEAgLTQxNSw2ICs0MTUsOSBAQCBpbnQgdGNm X2FjdGlvbl9jb3B5X3N0YXRzKHN0cnVjdCBza19idWZmDQogDQogCXJldHVy biAwOw0KIA0KK2Vycm91dF9zdG9wX3N0YXRzOg0KKwlnbmV0X3N0YXRzX2Zp bmlzaF9jb3B5KCZkKTsNCisNCiBlcnJvdXQ6DQogCXJldHVybiAtMTsNCiB9 DQo= ---1646943047-1586944306-1116248155=:13294-- From tgraf@suug.ch Mon May 16 06:49:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 06:49:33 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GDnHOv020995 for ; Mon, 16 May 2005 06:49:20 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B0AA91C0EB; Mon, 16 May 2005 15:49:00 +0200 (CEST) Date: Mon, 16 May 2005 15:49:00 +0200 From: Thomas Graf To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [SCHED] Fix unlock spinlock in error path Message-ID: <20050516134900.GC13748@postel.suug.ch> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 1186 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 789 Lines: 13 * Catalin(ux aka Dino) BOIE 2005-05-16 16:01 > In act_api.c::tcf_action_copy_stats, in error path (get_stats > returns < 0), the spinlock taken in gnet_stats_start_copy_compat > or gnet_stats_start_copy is not unlocked. This is on purpose, get_stats() is nothing more than a placeholder at the moment for something that should really be called dump_stats() and have struct gnet_dump as one of its arguments. The unlocking must be done in the internal error handling and if we ever have an operation that could fail between _start() and _stop() for another reason we'll need a gnet_stats_abort() (skb_trim()'ing properly) to avoid double unlocking. But since there is no user of this API yet it doesn't make sense to bloat the code. From jgarzik@pobox.com Mon May 16 09:46:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 09:47:06 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GGkrOv003126 for ; Mon, 16 May 2005 09:46:53 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXijN-0005Ls-K1; Mon, 16 May 2005 16:46:15 +0000 Message-ID: <4288CE51.1050703@pobox.com> Date: Mon, 16 May 2005 12:46:09 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Grant Grundler CC: akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> In-Reply-To: <20050516050843.GA20107@colo.lackof.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 631 Lines: 20 Simply ensure that tulip_select_media() is always called from a process context. Then can you delay all you want. Several of the calls are already this way, so that leaves two cases: 1) called from timer context, from the media poll timer 2) called from spin_lock_irqsave() context, in the ->tx_timeout hook. The first case can be fixed by moved all the timer code to a workqueue. Then when the existing timer fires, kick the workqueue. The second case can be fixed by kicking the workqueue upon tx_timeout (which is the reason why I did not suggest queue_delayed_work() use). See, it's not rocket science :) Jeff From tklauser@access.unizh.ch Mon May 16 10:16:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 10:16:18 -0700 (PDT) Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GHFvOv005136 for ; Mon, 16 May 2005 10:16:01 -0700 Received: from access.unizh.ch (80-218-109-59.dclient.hispeed.ch [80.218.109.59]) (authenticated bits=0) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id j4GHFDEv027345 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 16 May 2005 19:15:14 +0200 Date: Mon, 16 May 2005 19:15:11 +0200 From: Tobias Klauser To: kernel-janitors@lists.osdl.org Cc: jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com Subject: [PATCH] Use pci_set_dma_mask() instead of direct assignment of DMA mask Message-ID: <20050516171511.GA19983@nuerscht.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GPG-Key: 0x3A445520 X-OS: GNU/Linux User-Agent: Mutt/1.5.9i X-DCC-spamcheck-02.tornado.cablecom.ch-Metrics: smtp-05.tornado.cablecom.ch 32701; Body=4 Fuz1=4 Fuz2=4 X-archive-position: 1188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tklauser@nuerscht.ch Precedence: bulk X-list: netdev Content-Length: 1253 Lines: 36 The amd8111e driver directly assigns the DMA mask to the dma_mask member of the struct pci_dev instead of using pci_set_dma_mask(). This makes the call to pci_dma_supported() redundant as pci_set_dma_mask() does this check. I do not own this device so I only compile-tested this patch. Signed-off-by: Tobias Klauser diff -urpN -X dontdiff linux-2.6.12-rc4/drivers/net/amd8111e.c linux-2.6.12-rc4~dma_mask/drivers/net/amd8111e.c --- linux-2.6.12-rc4/drivers/net/amd8111e.c 2005-05-07 21:53:51.000000000 +0200 +++ linux-2.6.12-rc4~dma_mask/drivers/net/amd8111e.c 2005-05-16 19:11:30.349802984 +0200 @@ -87,6 +87,7 @@ Revision History: #include #include #include +#include #include #include @@ -2002,12 +2003,11 @@ static int __devinit amd8111e_probe_one( } /* Initialize DMA */ - if(!pci_dma_supported(pdev, 0xffffffff)){ + if (pci_set_dma_mask(pdev, DMA_32BIT_MASK) < 0) { printk(KERN_ERR "amd8111e: DMA not supported," "exiting.\n"); - goto err_free_reg; - } else - pdev->dma_mask = 0xffffffff; + goto err_free_reg; + } reg_addr = pci_resource_start(pdev, 0); reg_len = pci_resource_len(pdev, 0); From ganesh.venkatesan@gmail.com Mon May 16 10:43:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 10:43:43 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GHhdOv007061 for ; Mon, 16 May 2005 10:43:39 -0700 Received: by zproxy.gmail.com with SMTP id 34so1359520nzf for ; Mon, 16 May 2005 10:43:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rjYC8e9S6cEFjNQwS3tcMPndoRRhL9pV9xnFNPBRneZ9Czay2eX764ESTCXxmD8B2hi+ztXYn/yvX6Ta3qXmLSXTBUTpCUpEyP9ZrGaBR9JcqojA8bFB0+gnoI2D91pVMaITRRCOi/nLopCBQrsNTtGxkk9wQMn1tQ/Q/6+YJbA= Received: by 10.36.157.14 with SMTP id f14mr1763801nze; Mon, 16 May 2005 10:43:03 -0700 (PDT) Received: by 10.36.65.5 with HTTP; Mon, 16 May 2005 10:43:02 -0700 (PDT) Message-ID: <5fc59ff3050516104367a8d5cd@mail.gmail.com> Date: Mon, 16 May 2005 10:43:02 -0700 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: Herbert Xu Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Cc: Andrew Morton , netdev@oss.sgi.com, hejianj@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, anton@samba.org, jgarzik@pobox.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050516025901.4b26ccf3.akpm@osdl.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4GHhdOv007061 X-archive-position: 1189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 2456 Lines: 85 Jian: Could you try the e100 from http://prdownloads.sourceforge.net/e1000/e100-3.4.8.tar.gz?download? This (e100 3.4.8) has a fix for the problem you've encountered. Specifically this driver uses netif_poll_{enable|disable} to avoid the race. static int e100_up(struct nic *nic) { @@ -1688,13 +1753,18 @@ static int e100_up(struct nic *nic) if((err = e100_hw_init(nic))) goto err_clean_cbs; e100_set_multicast_list(nic->netdev); - e100_start_receiver(nic); + e100_start_receiver(nic, 0); mod_timer(&nic->watchdog, jiffies); if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ, nic->netdev->name, nic->netdev))) goto err_no_irq; - e100_enable_irq(nic); netif_wake_queue(nic->netdev); +#ifdef CONFIG_E100_NAPI + netif_poll_enable(nic->netdev); + /* enable ints _after_ enabling poll, preventing a race between + * disable ints+schedule */ +#endif + e100_enable_irq(nic); return 0; err_no_irq: @@ -1708,11 +1778,15 @@ err_rx_clean_list: static void e100_down(struct nic *nic) { +#ifdef CONFIG_E100_NAPI + /* wait here for poll to complete */ + netif_poll_disable(nic->netdev); +#endif + netif_stop_queue(nic->netdev); e100_hw_reset(nic); free_irq(nic->pdev->irq, nic->netdev); del_timer_sync(&nic->watchdog); netif_carrier_off(nic->netdev); - netif_stop_queue(nic->netdev); e100_clean_cbs(nic); e100_rx_clean_list(nic); ganesh. On 5/16/05, Herbert Xu wrote: > Andrew Morton wrote: > > > > Might be a bug in the e100 driver, might not be. > > > > I assume this is the > > > > BUG_ON(skb->list != NULL); > > It certainly is a bug in e100. > > e100_tx_timeout -> e100_down -> e100_rx_clean_list > > is racing against > > e100_poll -> e100_rx_clean -> e100_rx_indicate > > e100_rx_clean/e100_rx_indicate takes an skb off the RX ring and > while it's being processed e100_rx_clean_list comes along and > frees it. > > From a quick check similar problems may exist in other drivers that > have lockless ->poll() functions with RX rings. > > Cheers, > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > > From davem@davemloft.net Mon May 16 11:24:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 11:25:09 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GIOqOv009035 for ; Mon, 16 May 2005 11:24:53 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DXkFk-0001LE-Hc; Mon, 16 May 2005 11:23:44 -0700 Date: Mon, 16 May 2005 11:23:44 -0700 (PDT) Message-Id: <20050516.112344.21928675.davem@davemloft.net> To: hch@infradead.org Cc: jgarzik@pobox.com, akpm@osdl.org, christoph@graphe.net, tinay@chelsio.com, sbardone@chelsio.com, christoph@lameter.com, netdev@oss.sgi.com Subject: Re: [patch 02/10] A new 10GB Ethernet Driver by Chelsio Communications From: "David S. Miller" In-Reply-To: <20050516071218.GA17589@infradead.org> References: <200503302134.j2ULYLVO028974@shell0.pdx.osdl.net> <4287D826.3020704@pobox.com> <20050516071218.GA17589@infradead.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 267 Lines: 9 From: Christoph Hellwig Date: Mon, 16 May 2005 08:12:18 +0100 > On Sun, May 15, 2005 at 07:15:50PM -0400, Jeff Garzik wrote: > > applied > > to what tree? the driver is still a rather huge mess.. I agree, this thing should not be applied yet. From sbardone@chelsio.com Mon May 16 11:28:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 11:28:17 -0700 (PDT) Received: from stargate.chelsio.com (stargate.chelsio.com [64.186.171.138] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GIS8Ov009716 for ; Mon, 16 May 2005 11:28:09 -0700 Received: from maui.asicdesigners.com (maui.asicdesigners.com [10.192.160.15]) by stargate.chelsio.com (8.12.5/8.12.5) with SMTP id j4GIPq6H011600; Mon, 16 May 2005 11:25:52 -0700 Received: from [10.192.162.142] ([10.192.162.142]) by maui.asicdesigners.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 11:25:52 -0700 Message-ID: <4288E6DD.6070205@chelsio.com> Date: Mon, 16 May 2005 11:30:53 -0700 From: Scott Bardone User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: hch@infradead.org, jgarzik@pobox.com, akpm@osdl.org, christoph@graphe.net, tinay@chelsio.com, christoph@graphe.net, netdev@oss.sgi.com Subject: Re: [patch 02/10] A new 10GB Ethernet Driver by Chelsio Communications References: <200503302134.j2ULYLVO028974@shell0.pdx.osdl.net> <4287D826.3020704@pobox.com> <20050516071218.GA17589@infradead.org> <20050516.112344.21928675.davem@davemloft.net> In-Reply-To: <20050516.112344.21928675.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2005 18:25:52.0478 (UTC) FILETIME=[B10F67E0:01C55A44] X-archive-position: 1191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sbardone@chelsio.com Precedence: bulk X-list: netdev Content-Length: 415 Lines: 18 I will have a cleanup patch available this week. Please don't appy the current driver yet. Thanks, Scott David S. Miller wrote: > From: Christoph Hellwig > Date: Mon, 16 May 2005 08:12:18 +0100 > > >>On Sun, May 15, 2005 at 07:15:50PM -0400, Jeff Garzik wrote: >> >>>applied >> >>to what tree? the driver is still a rather huge mess.. > > > I agree, this thing should not be applied yet. From eparis@parisplace.org Mon May 16 11:42:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 11:42:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GIg4Ov010746 for ; Mon, 16 May 2005 11:42:04 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4GIfULV002778; Mon, 16 May 2005 14:41:30 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4GIfPO06325; Mon, 16 May 2005 14:41:25 -0400 Received: from dhcp59-180.rdu.redhat.com (dhcp59-180.rdu.redhat.com [172.16.59.180]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j4GIfPS5031372; Mon, 16 May 2005 14:41:25 -0400 Subject: [PATCH] bonding using arp_ip_target may stay down with active path From: Eric Paris To: netdev@oss.sgi.com Cc: jgarzik@pobox.com Content-Type: text/plain Date: Mon, 16 May 2005 14:41:25 -0400 Message-Id: <1116268885.3738.19.camel@dhcp59-180.rdu.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-archive-position: 1192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eparis@parisplace.org Precedence: bulk X-list: netdev Content-Length: 4461 Lines: 88 The bonding module may get into a state in which an active path to the network exists through at least one slave device but the bond remains down forever. This situation exists using the bonding options mode=1 arp_interval=500 arp_ip_target=10.10.10.5. mode=1 is the active/passive bonding mode. We determine link status using the reachability of other network devices determined by if they respond to arp requests. Reproducer: The reproducer is not simple. Easiest with 3 computers and two crossover cables. Configure one computer with bonding and each of the other computers to have an address in the arp_ip_target entries for the first machine. In this way if both single nic computers are up bonding should believe either of the slave interfaces are valid since each can reach one of the arp_ip_target entries. Shutdown the interface on the single nic computer connected to eth0. The bond should fail over to eth1. Shut down the interface connected to eth1. The bond should decide both the eth1 slave and the bond as a whole is down (it cannot contact either of the arp_ip_target entries). Run tcpdump on both of the single nic machines and see that only the machine connected to eth0 is receiving arp requests. Bring back up the interface connected to eth1. At this point we have a "valid" connection since eth1 can talk to one of the arp targets. But we are only sending arp requests on eth0 (verify with tcpdump) The Problem: The problem is in bond_activebackup_arp_mon where we say (in bond_main.c) if (!slave) { if (!bond->current_arp_slave) { bond->current_arp_slave = bond->first_slave; } if (bond->current_arp_slave) { bond_set_slave_inactive_flags(bond->current_arp_slave); /* search for next candidate */ bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave) { if (IS_UP(slave->dev)) { slave->link = BOND_LINK_BACK; bond_set_slave_active_flags(slave); bond_arp_send_all(bond, slave); slave->jiffies = jiffies; bond->current_arp_slave = slave; break; } What happens is that we set the current_arp_slave to the first interface in the bond, bond->current_arp_slave = bond->first_slave; (in our case eth0) and then if that slave IS_UP we send the arp requests. IS_UP checks only physical device information, so the NIC is up if it has link. We can make it fail over by pulling the cable, in which case we are ! IS_UP(eth0) and so the bond_for_each_slave_from loop continues to IS_UP(eth1) and it finds eth1 is physically up. It then sends the arp requests on eth1, gets a response from the connected single nic machine and marks the bond as a whole as up. The patch below instead just uses bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave->next) which means that each time we enter bond_activebackup_arp_mon without a bond->current_active_slave we will try an interface (actually starting with the second in the list) and if that interface does not get success the next go round bond->current_arp_slave will be the next in the list. This way we will try all interfaces in turn. I unconditionally use current_arp_slave->next since it is a circular list and should always have a next. The patch below has been tested by me and appears to fix the problem. All of the failover tests I performed seem to work including pulling cables and stopping responses from the arp_ip_target entries. --- linux-2.6.11/drivers/net/bonding/bond_main.c.orig 2005-05-12 12:22:52.000000000 -0400 +++ linux-2.6.11/drivers/net/bonding/bond_main.c 2005-05-12 15:13:53.000000000 -0400 @@ -3046,7 +3046,7 @@ static void bond_activebackup_arp_mon(st bond_set_slave_inactive_flags(bond->current_arp_slave); /* search for next candidate */ - bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave) { + bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave->next) { if (IS_UP(slave->dev)) { slave->link = BOND_LINK_BACK; bond_set_slave_active_flags(slave); From jgarzik@pobox.com Mon May 16 12:04:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 12:04:48 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GJ4hOv015271 for ; Mon, 16 May 2005 12:04:44 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXksh-0005OR-LO; Mon, 16 May 2005 19:03:59 +0000 Message-ID: <4288EE9C.4010308@pobox.com> Date: Mon, 16 May 2005 15:03:56 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: akpm@osdl.org, davem@davemloft.net, christoph@graphe.net, tinay@chelsio.com, sbardone@chelsio.com, christoph@lameter.com, Netdev Subject: Re: [patch 02/10] A new 10GB Ethernet Driver by Chelsio Communications References: <200503302134.j2ULYLVO028974@shell0.pdx.osdl.net> <4287D826.3020704@pobox.com> <20050516071218.GA17589@infradead.org> In-Reply-To: <20050516071218.GA17589@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 191 Lines: 11 Christoph Hellwig wrote: > On Sun, May 15, 2005 at 07:15:50PM -0400, Jeff Garzik wrote: > >>applied > > > to what tree? the driver is still a rather huge mess.. to the netdev-2.6 tree From jgarzik@pobox.com Mon May 16 12:06:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 12:06:46 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GJ6hOv015730 for ; Mon, 16 May 2005 12:06:43 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXkui-0005Og-Im; Mon, 16 May 2005 19:06:04 +0000 Message-ID: <4288EF1A.4040705@pobox.com> Date: Mon, 16 May 2005 15:06:02 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Bardone , "David S. Miller" , hch@infradead.org CC: akpm@osdl.org, christoph@graphe.net, tinay@chelsio.com, netdev@oss.sgi.com Subject: Re: [patch 02/10] A new 10GB Ethernet Driver by Chelsio Communications References: <200503302134.j2ULYLVO028974@shell0.pdx.osdl.net> <4287D826.3020704@pobox.com> <20050516071218.GA17589@infradead.org> <20050516.112344.21928675.davem@davemloft.net> <4288E6DD.6070205@chelsio.com> In-Reply-To: <4288E6DD.6070205@chelsio.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1194 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 312 Lines: 12 Scott Bardone wrote: > I will have a cleanup patch available this week. Please don't appy the > current driver yet. The current driver has been applied to the netdev-2.6 development queue. Send _incremental_ patches to me. When everybody's happy, the 'chelsio' queue will then be pushed upstream. Jeff From bunk@stusta.de Mon May 16 12:13:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 12:13:50 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4GJDfOv022046 for ; Mon, 16 May 2005 12:13:43 -0700 Received: (qmail 4704 invoked from network); 16 May 2005 19:13:04 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 16 May 2005 19:13:04 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 19ABABBA25; Mon, 16 May 2005 21:13:03 +0200 (CEST) Date: Mon, 16 May 2005 21:13:03 +0200 From: Adrian Bunk To: Jeff Garzik Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] document that 8139TOO supports 8129/8130 Message-ID: <20050516191303.GF5112@stusta.de> References: <20050513040445.GD3603@stusta.de> <4287C637.4030206@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4287C637.4030206@pobox.com> User-Agent: Mutt/1.5.9i X-archive-position: 1195 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1438 Lines: 45 On Sun, May 15, 2005 at 05:59:19PM -0400, Jeff Garzik wrote: > Adrian Bunk wrote: > >+ the RTL 8129/81308139 chips. If you have one of those, say Y and > > typo: "81308139" It wasn't easy to make a mistake in such a simple patch. ;-) Fixed patch below. cu Adrian <-- snip --> The 8129/8130 support is a sub-option that is not visible if the user hasn't enabled the 8139 support. Let's make it a bit easier for users to find the driver for their nic. Signed-off-by: Adrian Bunk --- linux-2.6.12-rc4-mm1-full/drivers/net/Kconfig.old 2005-05-13 05:54:05.000000000 +0200 +++ linux-2.6.12-rc4-mm1-full/drivers/net/Kconfig 2005-05-13 06:00:21.000000000 +0200 @@ -1484,14 +1484,14 @@ will be called 8139cp. This is recommended. config 8139TOO - tristate "RealTek RTL-8139 PCI Fast Ethernet Adapter support" + tristate "RealTek RTL-8129/8130/8139 PCI Fast Ethernet Adapter support" depends on NET_PCI && PCI select CRC32 select MII ---help--- This is a driver for the Fast Ethernet PCI network cards based on - the RTL8139 chips. If you have one of those, say Y and read - the Ethernet-HOWTO . + the RTL 8129/8130/8139 chips. If you have one of those, say Y and + read the Ethernet-HOWTO . To compile this driver as a module, choose M here: the module will be called 8139too. This is recommended. From util@deuroconsult.ro Mon May 16 12:26:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 12:26:18 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GJQ3Ov026330 for ; Mon, 16 May 2005 12:26:06 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4GJPNOv021605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 May 2005 22:25:23 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4GJPNsl021602; Mon, 16 May 2005 22:25:23 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Mon, 16 May 2005 22:25:23 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Thomas Graf cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [SCHED] Fix unlock spinlock in error path In-Reply-To: <20050516134900.GC13748@postel.suug.ch> Message-ID: References: <20050516134900.GC13748@postel.suug.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 993 Lines: 24 On Mon, 16 May 2005, Thomas Graf wrote: > * Catalin(ux aka Dino) BOIE 2005-05-16 16:01 >> In act_api.c::tcf_action_copy_stats, in error path (get_stats >> returns < 0), the spinlock taken in gnet_stats_start_copy_compat >> or gnet_stats_start_copy is not unlocked. > > This is on purpose, get_stats() is nothing more than a placeholder > at the moment for something that should really be called dump_stats() > and have struct gnet_dump as one of its arguments. The unlocking > must be done in the internal error handling and if we ever have an > operation that could fail between _start() and _stop() for > another reason we'll need a gnet_stats_abort() (skb_trim()'ing > properly) to avoid double unlocking. But since there is no > user of this API yet it doesn't make sense to bloat the code. Thanks Thomas for the explication! Sorry for the noise. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From davem@davemloft.net Mon May 16 13:08:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 13:08:32 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GK8JOv029364 for ; Mon, 16 May 2005 13:08:19 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DXlsH-0001oe-UY; Mon, 16 May 2005 13:07:37 -0700 Date: Mon, 16 May 2005 13:07:37 -0700 (PDT) Message-Id: <20050516.130737.77060495.davem@davemloft.net> To: jdmason@us.ibm.com Cc: netdev@oss.sgi.com, niv@us.ibm.com, habanero@us.ibm.com Subject: Re: Interdomain/interpartition communication without a checksum From: "David S. Miller" In-Reply-To: <20050511183554.GA28298@us.ibm.com> References: <20050511183554.GA28298@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1050 Lines: 27 From: Jon Mason Date: Wed, 11 May 2005 13:35:54 -0500 > I have been working on a Xen project to remove unnecessary TCP/UDP > checksums for local (interdomain) communication, while still having the > checksum for all external network communication. I have no objections to this idea. But let's think about the implementation. > + /* If packet is forwarded to a device that needs a checksum and not > + * checksummed, correct the pointers and enable checksumming in the > + * next function. > + */ > + if (!(dev->features & NETIF_F_FWD_NO_CSUM) && skb->csum) { > + skb->ip_summed = CHECKSUM_HW; > + skb->h.raw = (void *)skb->nh.iph + (skb->nh.iph->ihl * 4); > + } > + This means that every packet which the networking tries to checksum offload will pass this test, superfluously doing these assignments. It also assumes ipv4. ipv6 is possible, and for NETIF_F_CHECKSUM_HW any protocol could be creating the packets as this flag indicates that the card implements a totally generic 16-bit two's complement checksum. From tgraf@suug.ch Mon May 16 13:12:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 13:12:49 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GKCjOv029933 for ; Mon, 16 May 2005 13:12:45 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id AD90D1C0EB; Mon, 16 May 2005 22:12:33 +0200 (CEST) Date: Mon, 16 May 2005 22:12:33 +0200 From: Thomas Graf To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [SCHED] Fix unlock spinlock in error path Message-ID: <20050516201233.GE13748@postel.suug.ch> References: <20050516134900.GC13748@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 1198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 226 Lines: 5 * Catalin(ux aka Dino) BOIE 2005-05-16 22:25 > Thanks Thomas for the explication! > Sorry for the noise. Don't worry, I should have documented this weird code part. ;-> From fubar@us.ibm.com Mon May 16 13:35:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 13:35:38 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GKZROv031140 for ; Mon, 16 May 2005 13:35:34 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4GKYed7004191 for ; Mon, 16 May 2005 16:34:40 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4GKYeXn102988 for ; Mon, 16 May 2005 16:34:40 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4GKYeM7023659 for ; Mon, 16 May 2005 16:34:40 -0400 Received: from death.nxdomain.ibm.com (sig-9-65-37-67.mts.ibm.com [9.65.37.67]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4GKYdqB023626; Mon, 16 May 2005 16:34:40 -0400 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j4GKYbse022998; Mon, 16 May 2005 13:34:37 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j4GKYbch022992; Mon, 16 May 2005 13:34:37 -0700 Message-Id: <200505162034.j4GKYbch022992@death.nxdomain.ibm.com> To: Eric Paris cc: netdev@oss.sgi.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH] bonding using arp_ip_target may stay down with active path In-Reply-To: Message from Eric Paris of "Mon, 16 May 2005 14:41:25 EDT." <1116268885.3738.19.camel@dhcp59-180.rdu.redhat.com> X-Mailer: MH-E 7.83; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 16 May 2005 13:34:37 -0700 From: Jay Vosburgh X-archive-position: 1199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1752 Lines: 45 Eric Paris wrote: >[...] Bring back up the interface connected to >eth1. At this point we have a "valid" connection since eth1 can talk to >one of the arp targets. But we are only sending arp requests on eth0 >(verify with tcpdump) The trick is to have a situation with a partitioned network and a failure such that the device still has link, but does not respond to the ARP queries. That's not an unreasonable failure if there's a switch in each path to the arp_ip_target peers (which is how I set it up locally). >The patch below has been tested by me and appears to fix the problem. >All of the failover tests I performed seem to work including pulling >cables and stopping responses from the arp_ip_target entries. The patch looks good to me, also (although I made the change by hand instead of via patch). -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com Signed-off-by: Jay Vosburgh --- linux-2.6.11/drivers/net/bonding/bond_main.c.orig 2005-05-12 12:22:52.000000000 -0400 +++ linux-2.6.11/drivers/net/bonding/bond_main.c 2005-05-12 15:13:53.000000000 -0400 @@ -3046,7 +3046,7 @@ static void bond_activebackup_arp_mon(st bond_set_slave_inactive_flags(bond->current_arp_slave); /* search for next candidate */ - bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave) { + bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave->next) { if (IS_UP(slave->dev)) { slave->link = BOND_LINK_BACK; bond_set_slave_active_flags(slave); From herbert@gondor.apana.org.au Mon May 16 14:31:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 14:31:14 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GLV8Ov000771 for ; Mon, 16 May 2005 14:31:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DXnAC-0001BI-00; Tue, 17 May 2005 07:30:12 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DXn9x-00050i-00; Tue, 17 May 2005 07:29:57 +1000 Date: Tue, 17 May 2005 07:29:57 +1000 To: Ganesh Venkatesan Cc: Andrew Morton , netdev@oss.sgi.com, hejianj@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, anton@samba.org, jgarzik@pobox.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-ID: <20050516212957.GA19211@gondor.apana.org.au> References: <20050516025901.4b26ccf3.akpm@osdl.org> <5fc59ff3050516104367a8d5cd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fc59ff3050516104367a8d5cd@mail.gmail.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 607 Lines: 20 On Mon, May 16, 2005 at 10:43:02AM -0700, Ganesh Venkatesan wrote: > > @@ -1708,11 +1778,15 @@ err_rx_clean_list: > > static void e100_down(struct nic *nic) > { > +#ifdef CONFIG_E100_NAPI > + /* wait here for poll to complete */ > + netif_poll_disable(nic->netdev); > +#endif Sorry, you can't do that here since you're in softirq context and netif_poll_disable may sleep. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jgarzik@pobox.com Mon May 16 14:59:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 14:59:44 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GLxfOv002100 for ; Mon, 16 May 2005 14:59:42 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXnc0-0005VB-40; Mon, 16 May 2005 21:58:57 +0000 Message-ID: <4289179C.6090900@pobox.com> Date: Mon, 16 May 2005 17:58:52 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: Ganesh Venkatesan , Andrew Morton , netdev@oss.sgi.com, hejianj@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, anton@samba.org Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 References: <20050516025901.4b26ccf3.akpm@osdl.org> <5fc59ff3050516104367a8d5cd@mail.gmail.com> <20050516212957.GA19211@gondor.apana.org.au> In-Reply-To: <20050516212957.GA19211@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 584 Lines: 24 Herbert Xu wrote: > On Mon, May 16, 2005 at 10:43:02AM -0700, Ganesh Venkatesan wrote: > >>@@ -1708,11 +1778,15 @@ err_rx_clean_list: >> >> static void e100_down(struct nic *nic) >> { >>+#ifdef CONFIG_E100_NAPI >>+ /* wait here for poll to complete */ >>+ netif_poll_disable(nic->netdev); >>+#endif > > > Sorry, you can't do that here since you're in softirq context and > netif_poll_disable may sleep. I think the intention is that e100_down() may sleep, from looking at all the callsites. Only e100_tx_timeout() calls it in a context that prevents sleep. Jeff From grundler@lackof.org Mon May 16 15:23:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 15:23:44 -0700 (PDT) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GMNfOv003571 for ; Mon, 16 May 2005 15:23:41 -0700 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id 79457298052; Mon, 16 May 2005 16:26:13 -0600 (MDT) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30516-05; Mon, 16 May 2005 16:26:13 -0600 (MDT) Received: by colo.lackof.org (Postfix, from userid 27253) id 1487B29803C; Mon, 16 May 2005 16:26:13 -0600 (MDT) Date: Mon, 16 May 2005 16:26:12 -0600 From: Grant Grundler To: Jeff Garzik Cc: Grant Grundler , akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree Message-ID: <20050516222612.GD9282@colo.lackof.org> References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4288CE51.1050703@pobox.com> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.9i X-archive-position: 1202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev Content-Length: 1588 Lines: 37 On Mon, May 16, 2005 at 12:46:09PM -0400, Jeff Garzik wrote: > Simply ensure that tulip_select_media() is always called from a process > context. Then can you delay all you want. Several of the calls are > already this way, so that leaves two cases: > > 1) called from timer context, from the media poll timer > > 2) called from spin_lock_irqsave() context, in the ->tx_timeout hook. > > The first case can be fixed by moved all the timer code to a workqueue. > Then when the existing timer fires, kick the workqueue. > > The second case can be fixed by kicking the workqueue upon tx_timeout > (which is the reason why I did not suggest queue_delayed_work() use). Thanks - the above guidance has much more detail than you offered before and is much more useful. Too bad that schedule_timeout() was the only option at the time. :^( And I apologize I don't recall what the issues were with schedule_timeout(). I suspect they will rear their ugly head with the workqueue implementation as well. But if they don't, that will be great. > See, it's not rocket science :) Well, then it's a great opportunity for someone interested in hacking NIC drivers to cut their teeth on. :^) After three years of using/maintaining the (trivial) tulip patch in parisc-linux tree (and shipped with RH/SuSe ia64 releases), I don't recall anyone complaining that udelays in tulip phy reset caused them problems. Sorry, I'm unmotivated to revisit this. Convince someone else to make tulip to use workqueues and I'll resubmit a clean patch on top of that for the phy init sequences. thanks, grant From jgarzik@pobox.com Mon May 16 16:40:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 16:40:08 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4GNe3Ov012112 for ; Mon, 16 May 2005 16:40:03 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DXpBG-0005XK-SL; Mon, 16 May 2005 23:39:29 +0000 Message-ID: <42892F2B.8090908@pobox.com> Date: Mon, 16 May 2005 19:39:23 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linus Torvalds , Andrew Morton CC: Netdev , Linux Kernel Subject: [git patches] 2.6.x net driver fixes Content-Type: multipart/mixed; boundary="------------050705020706030106060808" X-archive-position: 1203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 5280 Lines: 150 This is a multi-part message in MIME format. --------------050705020706030106060808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here's a first experimental git push from me. The git URL is rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git but it should be noted that I would like you to pull the 'misc-fixes' branch. I'm told that branches are supposed to live in .git/refs/heads, so there you will find netdev-2.6.git/refs/heads/misc-fixes. Does that work? Changelog and patch for review attached. Jeff, still afraid of trying a 'tough' merge --------------050705020706030106060808 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" commit c8920ba041c8934b29370f5d62ab9ea8f147966b tree 6e0e12acd812f221906289348bc4e08cd1047df6 parent c4cc26d3310a6614a20e32276228a5d44159fc9b author Daniel Andersen Fri, 06 May 2005 05:14:09 -0700 committer Jeff Garzik Mon, 16 May 2005 08:04:29 -0400 [PATCH] wireless: 3CRWE154G72 Kconfig help fix Version 2 of the 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 is not supported by the prism54 project. To stop confusion, the kernel documentation should state so as 3com made a good job hiding the version. Signed-off-by: Andrew Morton diff -puN drivers/net/wireless/Kconfig~wireless-3crwe154g72-kconfig-help-fix drivers/net/wireless/Kconfig -------------------------- commit c4cc26d3310a6614a20e32276228a5d44159fc9b tree 35246410bf048fb6a0aa455b272f2a2933dbacad parent 99718699f5746cc365f3a9ab4769568a1da97635 author Jiri Benc Wed, 27 Apr 2005 12:48:56 +0200 committer Jeff Garzik Mon, 16 May 2005 07:18:48 -0400 [PATCH] Typo in tulip driver This patch fixes a typo in tulip driver in 2.6.12-rc3. -------------------------- commit 99718699f5746cc365f3a9ab4769568a1da97635 tree 6f8f9ad590b14514ad88c3478328795148c91e46 parent f7a3aae1723e7ffc9c4fcdb489365da7a3d81255 author Geoff Levand Fri, 15 Apr 2005 01:20:32 -0700 committer Jeff Garzik Mon, 16 May 2005 06:44:26 -0400 [PATCH] {PATCH] Fix IBM EMAC driver ioctl bug Fix IBM EMAC driver ioctl bug. I found IBM EMAC driver bug. So mii-tool command print wrong status. # mii-tool eth0: 10 Mbit, half duplex, no link eth1: 10 Mbit, half duplex, no link I can get correct status on fixed kernel. # mii-tool eth0: negotiated 100baseTx-FD, link okZZ eth1: negotiated 100baseTx-FD, link ok Hiroaki Fuse Signed-off-by: Geoff Levand for CELF -------------------------- commit f7a3aae1723e7ffc9c4fcdb489365da7a3d81255 tree 2c0a93d730060f63670d3e7f130ee12e26b3ed8f parent 88d7bd8cb9eb8d64bf7997600b0d64f7834047c5 author Al Viro Sun, 03 Apr 2005 09:15:52 +0100 committer Jeff Garzik Mon, 16 May 2005 06:22:32 -0400 [PATCH] drivers/net/wireless enabled by wrong option NET_WIRELESS is only a subset of the stuff in drivers/net/wireless; NET_RADIO is what covers all of them. Signed-off-by: Al Viro -------------------------- --------------050705020706030106060808 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -187,7 +187,7 @@ obj-$(CONFIG_TR) += tokenring/ obj-$(CONFIG_WAN) += wan/ obj-$(CONFIG_ARCNET) += arcnet/ obj-$(CONFIG_NET_PCMCIA) += pcmcia/ -obj-$(CONFIG_NET_WIRELESS) += wireless/ +obj-$(CONFIG_NET_RADIO) += wireless/ obj-$(CONFIG_NET_TULIP) += tulip/ obj-$(CONFIG_HAMRADIO) += hamradio/ obj-$(CONFIG_IRDA) += irda/ --- a/drivers/net/ibm_emac/ibm_emac_core.c +++ b/drivers/net/ibm_emac/ibm_emac_core.c @@ -1595,7 +1595,7 @@ static struct ethtool_ops emac_ethtool_o static int emac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct ocp_enet_private *fep = dev->priv; - uint *data = (uint *) & rq->ifr_ifru; + uint16_t *data = (uint16_t *) & rq->ifr_ifru; switch (cmd) { case SIOCGMIIPHY: --- a/drivers/net/tulip/tulip_core.c +++ b/drivers/net/tulip/tulip_core.c @@ -1104,7 +1104,7 @@ static void set_rx_mode(struct net_devic if (entry != 0) { /* Avoid a chip errata by prefixing a dummy entry. Don't do this on the ULI526X as it triggers a different problem */ - if (!(tp->chip_id == ULI526X && (tp->revision = 0x40 || tp->revision == 0x50))) { + if (!(tp->chip_id == ULI526X && (tp->revision == 0x40 || tp->revision == 0x50))) { tp->tx_buffers[entry].skb = NULL; tp->tx_buffers[entry].mapping = 0; tp->tx_ring[entry].length = --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -323,7 +323,7 @@ config PRISM54 For a complete list of supported cards visit . Here is the latest confirmed list of supported cards: - 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 + 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 (version 1) Allnet ALL0271 PCI Card Compex WL54G Cardbus Card Corega CG-WLCB54GT Cardbus Card --------------050705020706030106060808-- From jaegert@us.ibm.com Mon May 16 19:56:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 19:57:03 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4H2unOv022801 for ; Mon, 16 May 2005 19:56:58 -0700 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j4H2vIRN020127; Mon, 16 May 2005 22:57:18 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j4H2u4S20174; Mon, 16 May 2005 22:56:04 -0400 Received: from localhost (sig-9-65-126-151.mts.ibm.com [9.65.126.151]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j4H2u3w41714; Mon, 16 May 2005 22:56:03 -0400 Date: Mon, 16 May 2005 22:55:56 -0400 (Eastern Daylight Time) From: Trent Jaeger To: netdev@oss.sgi.com, chrisw@osdl.org cc: jaegert@us.ibm.com, sergeh@us.ibm.com, latten@us.ibm.com, sds@tycho.nsa.gov, jmorris@redhat.com Subject: [PATCH 1/2] LSM-IPSec Networking Hooks Message-ID: X-Warning: UNAuthenticated Sender MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaegert@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 42233 Lines: 1277 Hi, This is a new patch for extending Linux Security Modules interface to leverage IPSec to control socket access to network packets. The SELinux module is extended to use these hooks. Regards, Trent. ------------------------- Trent Jaeger IBM T.J. Watson Research Center 19 Skyline Dr, Hawthorne, NY 10532 (914) 784-7225, (FAX) (914) 784-6209 This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the XFRM subsystem, pfkey interface, ipv4/ipv6, and xfrm_user interface to restrict a socket to use only authorized security associations to access network packets (send and receive). Patch purpose: The patch is designed to enable access control per packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the system can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The overall approach is that policy (xfrm_policy) entries set by user-level programs (e.g., setkey for ipsec-tools) are extended with a security context that is used at policy selection time in the XFRM subsystem to restrict the sockets that can send/receive packets via security associations (xfrm_states) that are built from those policies. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: On output, the policy retrieved (via xfrm_policy_lookup or xfrm_sk_policy_lookup) must be authorized for the security context of the socket and the same security context is required for resultant security association (retrieved or negotiated via racoon in ipsec-tools). This is enforced in xfrm_state_find. On input, the policy retrieved must also be authorized for the socket (at __xfrm_policy_check), and the security context of the policy must also match the security association being used. The patch has virtually no impact on packets that do not use IPSec. The existing Netfilter (outgoing) and LSM rcv_skb hooks are used as before. Also, if IPSec is used without security contexts, the impact is minimal. The LSM must allow such policies to be selected for the combination of socket and remote machine, but subsequent IPSec processing proceeds as in the original case. Testing: The pfkey interface is tested using the ipsec-tools. ipsec-tools have been modified (a separate ipsec-tools patch is available for version 0.5) that supports assignment of xfrm_policy entries and security associations with security contexts via setkey and the negotiation using the security contexts via racoon. The xfrm_user interface is tested via ad hoc programs that set security contexts. These programs are also available from me, and contain programs for setting, getting, and deleting policy for testing this interface. Testing of sa functions was done by tracing kernel behavior. --- include/linux/pfkeyv2.h | 13 +++ include/linux/security.h | 119 +++++++++++++++++++++++++++++++++++ include/linux/xfrm.h | 36 ++++++++++ include/net/flow.h | 5 - include/net/xfrm.h | 21 ++++++ net/core/flow.c | 4 - net/ipv4/xfrm4_policy.c | 2 net/ipv6/xfrm6_policy.c | 2 net/key/af_key.c | 119 +++++++++++++++++++++++++++++++++-- net/xfrm/xfrm_policy.c | 64 +++++++++++------- net/xfrm/xfrm_state.c | 14 +++- net/xfrm/xfrm_user.c | 159 +++++++++++++++++++++++++++++++++++++++++++++-- security/Kconfig | 13 +++ security/dummy.c | 37 ++++++++++ 14 files changed, 568 insertions(+), 40 deletions(-) diff -puN include/linux/pfkeyv2.h~lsm-xfrm-nethooks include/linux/pfkeyv2.h --- linux-2.6.12-rc4-nethooks/include/linux/pfkeyv2.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/linux/pfkeyv2.h 2005-05-10 16:19:20.000000000 -0400 @@ -216,6 +216,16 @@ struct sadb_x_nat_t_port { } __attribute__((packed)); /* sizeof(struct sadb_x_nat_t_port) == 8 */ +/* Generic LSM security context */ +struct sadb_x_sec_ctx { + uint16_t sadb_x_sec_len; + uint16_t sadb_x_sec_exttype; + uint8_t sadb_x_ctx_alg; /* LSMs: e.g., selinux == 1 */ + uint8_t sadb_x_ctx_doi; + uint16_t sadb_x_ctx_len; +} __attribute__((packed)); +/* sizeof(struct sadb_sec_ctx) = 8 */ + /* Message types */ #define SADB_RESERVED 0 #define SADB_GETSPI 1 @@ -324,7 +334,8 @@ struct sadb_x_nat_t_port { #define SADB_X_EXT_NAT_T_SPORT 21 #define SADB_X_EXT_NAT_T_DPORT 22 #define SADB_X_EXT_NAT_T_OA 23 -#define SADB_EXT_MAX 23 +#define SADB_X_EXT_SEC_CTX 24 +#define SADB_EXT_MAX 24 /* Identity Extension values */ #define SADB_IDENTTYPE_RESERVED 0 diff -puN include/linux/security.h~lsm-xfrm-nethooks include/linux/security.h --- linux-2.6.12-rc4-nethooks/include/linux/security.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/linux/security.h 2005-05-16 16:12:29.000000000 -0400 @@ -58,6 +58,12 @@ struct sk_buff; struct sock; struct sockaddr; struct socket; +struct flowi; +struct dst_entry; +struct xfrm_selector; +struct xfrm_policy; +struct xfrm_state; +struct sadb_x_sec_ctx; extern int cap_netlink_send(struct sock *sk, struct sk_buff *skb); extern int cap_netlink_recv(struct sk_buff *skb); @@ -802,6 +808,50 @@ struct swap_info_struct; * @sk_free_security: * Deallocate security structure. * + * Security hooks for XFRM operations. + * + * @xfrm_policy_alloc_security: + * @xp contains the xfrm_policy being added to Security Policy Database + * used by the XFRM system. + * @sec_ctx contains the security context information being provided by + * the user-level policy update program (e.g., setkey). + * Allocate a security structure to the xp->selector.security field. + * The security field is initialized to NULL when the xfrm_policy is + * allocated. + * Return 0 if operation was successful (memory to allocate, legal context) + * @xfrm_policy_clone_security: + * @old contains an existing xfrm_policy in the SPD. + * @new contains a new xfrm_policy being cloned from old. + * Allocate a security structure to the new->selector.security field + * that contains the information from the old->selector.security field. + * Return 0 if operation was successful (memory to allocate). + * @xfrm_policy_free_security: + * @xp contains the xfrm_policy + * Deallocate xp->selector.security. + * @xfrm_state_alloc_security: + * @x contains the xfrm_state being added to the Security Association + * Database by the XFRM system. + * @sec_ctx contains the security context information being provided by + * the user-level SA generation program (e.g., setkey or racoon). + * Allocate a security structure to the x->sel.security field. The + * security field is initialized to NULL when the xfrm_state is + * allocated. + * Return 0 if operation was successful (memory to allocate, legal context). + * @xfrm_state_free_security: + * @x contains the xfrm_state. + * Deallocate x>sel.security. + * @xfrm_policy_lookup: + * @sk contains the sock that is requesting to either send or receive a + * network communication. + * @sel contains the selector that matches the communication end points of + * the network communication (source, destination, and ports). + * @fl contains the flowi that indicates the communication protocol. + * @dir contains the direction of the flow (input or output). + * Check permission when a sock selects a xfrm_policy for processing + * XFRMs on a packet. The hook is called when selecting either a + * per-socket policy or a generic xfrm policy. + * Return 0 if permission is granted. + * * Security hooks affecting all System V IPC operations. * * @ipc_permission: @@ -1243,6 +1293,15 @@ struct security_operations { int (*sk_alloc_security) (struct sock *sk, int family, int priority); void (*sk_free_security) (struct sock *sk); #endif /* CONFIG_SECURITY_NETWORK */ + +#ifdef CONFIG_SECURITY_NETWORK_XFRM + int (*xfrm_policy_alloc_security) (struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx); + int (*xfrm_policy_clone_security) (struct xfrm_policy *old, struct xfrm_policy *new); + void (*xfrm_policy_free_security) (struct xfrm_policy *xp); + int (*xfrm_state_alloc_security) (struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx); + void (*xfrm_state_free_security) (struct xfrm_state *x); + int (*xfrm_policy_lookup)(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir); +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ }; /* global variables */ @@ -2854,5 +2913,65 @@ static inline void security_sk_free(stru } #endif /* CONFIG_SECURITY_NETWORK */ +#ifdef CONFIG_SECURITY_NETWORK_XFRM +static inline int security_xfrm_policy_alloc(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx) +{ + return security_ops->xfrm_policy_alloc_security(xp, sec_ctx); +} + +static inline int security_xfrm_policy_clone(struct xfrm_policy *old, struct xfrm_policy *new) +{ + return security_ops->xfrm_policy_clone_security(old, new); +} + +static inline void security_xfrm_policy_free(struct xfrm_policy *xp) +{ + security_ops->xfrm_policy_free_security(xp); +} + +static inline int security_xfrm_state_alloc(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx) +{ + return security_ops->xfrm_state_alloc_security(x, sec_ctx); +} + +static inline void security_xfrm_state_free(struct xfrm_state *x) +{ + security_ops->xfrm_state_free_security(x); +} + +static inline int security_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir) +{ + return security_ops->xfrm_policy_lookup(sk, sel, fl, dir); +} +#else /* CONFIG_SECURITY_NETWORK_XFRM */ +static inline int security_xfrm_policy_alloc(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx) +{ + return 0; +} + +static inline int security_xfrm_policy_clone(struct xfrm_policy *old, struct xfrm_policy *new) +{ + return 0; +} + +static inline void security_xfrm_policy_free(struct xfrm_policy *xp) +{ +} + +static inline int security_xfrm_state_alloc(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx) +{ + return 0; +} + +static inline void security_xfrm_state_free(struct xfrm_state *x) +{ +} + +static inline int security_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir) +{ + return 0; +} +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ + #endif /* ! __LINUX_SECURITY_H */ diff -puN include/linux/xfrm.h~lsm-xfrm-nethooks include/linux/xfrm.h --- linux-2.6.12-rc4-nethooks/include/linux/xfrm.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/linux/xfrm.h 2005-05-10 16:22:40.000000000 -0400 @@ -27,6 +27,22 @@ struct xfrm_id __u8 proto; }; +struct xfrm_sec_ctx { + __u8 ctx_doi; + __u8 ctx_alg; + __u16 ctx_len; + __u32 ctx_sid; + char ctx_str[0]; +}; + +/* Security Context Domains of Interpretation */ +#define XFRM_SC_DOI_RESERVED 0 +#define XFRM_SC_DOI_LSM 1 + +/* Security Context Algorithms */ +#define XFRM_SC_ALG_RESERVED 0 +#define XFRM_SC_ALG_SELINUX 1 + /* Selector, used as selector both on policy rules (SPD) and SAs. */ struct xfrm_selector @@ -43,8 +59,15 @@ struct xfrm_selector __u8 proto; int ifindex; uid_t user; + struct xfrm_sec_ctx *security; }; +/* All but the security field */ +static inline int xfrm_selector_base_size(void) +{ + return sizeof(struct xfrm_selector) - sizeof(struct xfrm_sec_ctx *); +} + #define XFRM_INF (~(__u64)0) struct xfrm_lifetime_cfg @@ -146,6 +169,18 @@ enum { #define XFRM_NR_MSGTYPES (XFRM_MSG_MAX + 1 - XFRM_MSG_BASE) +/* + * Generic LSM security context for comunicating to user space + * NOTE: Same format as sadb_x_sec_ctx + */ +struct xfrm_user_sec_ctx { + __u16 len; + __u16 exttype; + __u8 ctx_alg; /* LSMs: e.g., selinux == 1 */ + __u8 ctx_doi; + __u16 ctx_len; +}; + struct xfrm_user_tmpl { struct xfrm_id id; __u16 family; @@ -173,6 +208,7 @@ enum xfrm_attr_type_t { XFRMA_ALG_CRYPT, /* struct xfrm_algo */ XFRMA_ALG_COMP, /* struct xfrm_algo */ XFRMA_ENCAP, /* struct xfrm_algo + struct xfrm_encap_tmpl */ + XFRMA_SEC_CTX, /* struct xfrm_sec_ctx */ XFRMA_TMPL, /* 1 or more struct xfrm_user_tmpl */ __XFRMA_MAX diff -puN include/net/flow.h~lsm-xfrm-nethooks include/net/flow.h --- linux-2.6.12-rc4-nethooks/include/net/flow.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/net/flow.h 2005-05-10 15:04:25.000000000 -0400 @@ -84,10 +84,11 @@ struct flowi { #define FLOW_DIR_OUT 1 #define FLOW_DIR_FWD 2 -typedef void (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir, +struct sock; +typedef void (*flow_resolve_t)(struct flowi *key, struct sock *sk, u16 family, u8 dir, void **objp, atomic_t **obj_refp); -extern void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir, +extern void *flow_cache_lookup(struct flowi *key, struct sock *sk, u16 family, u8 dir, flow_resolve_t resolver); extern void flow_cache_flush(void); extern atomic_t flow_cache_genid; diff -puN include/net/xfrm.h~lsm-xfrm-nethooks include/net/xfrm.h --- linux-2.6.12-rc4-nethooks/include/net/xfrm.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/net/xfrm.h 2005-05-12 15:38:22.000000000 -0400 @@ -493,6 +493,27 @@ xfrm_selector_match(struct xfrm_selector return 0; } +/* If neither has a context --> match + Otherwise, both must have a context and the sids, doi, alg must match */ +static inline int xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ctx *s2) +{ + return ((!s1 && !s2) || + (s1 && s2 && + (s1->ctx_sid == s2->ctx_sid) && + (s1->ctx_doi == s2->ctx_doi) && + (s1->ctx_alg == s2->ctx_alg))); +} + +static inline struct xfrm_sec_ctx *xfrm_policy_security(struct xfrm_policy *xp) +{ + return (xp ? xp->selector.security : NULL); +} + +static inline struct xfrm_sec_ctx *xfrm_state_security(struct xfrm_state *x) +{ + return (x ? x->sel.security : NULL); +} + /* A struct encoding bundle of transformations to apply to some set of flow. * * dst->child points to the next element of bundle. diff -puN net/core/flow.c~lsm-xfrm-nethooks net/core/flow.c --- linux-2.6.12-rc4-nethooks/net/core/flow.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/core/flow.c 2005-05-10 15:04:25.000000000 -0400 @@ -162,7 +162,7 @@ static int flow_key_compare(struct flowi return 0; } -void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir, +void *flow_cache_lookup(struct flowi *key, struct sock *sk, u16 family, u8 dir, flow_resolve_t resolver) { struct flow_cache_entry *fle, **head; @@ -221,7 +221,7 @@ nocache: void *obj; atomic_t *obj_ref; - resolver(key, family, dir, &obj, &obj_ref); + resolver(key, sk, family, dir, &obj, &obj_ref); if (fle) { fle->genid = atomic_read(&flow_cache_genid); diff -puN net/ipv4/xfrm4_policy.c~lsm-xfrm-nethooks net/ipv4/xfrm4_policy.c --- linux-2.6.12-rc4-nethooks/net/ipv4/xfrm4_policy.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/ipv4/xfrm4_policy.c 2005-05-16 13:33:47.000000000 -0400 @@ -36,6 +36,8 @@ __xfrm4_find_bundle(struct flowi *fl, st if (xdst->u.rt.fl.oif == fl->oif && /*XXX*/ xdst->u.rt.fl.fl4_dst == fl->fl4_dst && xdst->u.rt.fl.fl4_src == fl->fl4_src && + xfrm_sec_ctx_match(xfrm_policy_security(policy), + xfrm_state_security(dst->xfrm)) && xfrm_bundle_ok(xdst, fl, AF_INET)) { dst_clone(dst); break; diff -puN net/ipv6/xfrm6_policy.c~lsm-xfrm-nethooks net/ipv6/xfrm6_policy.c --- linux-2.6.12-rc4-nethooks/net/ipv6/xfrm6_policy.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/ipv6/xfrm6_policy.c 2005-05-10 15:13:49.000000000 -0400 @@ -54,6 +54,8 @@ __xfrm6_find_bundle(struct flowi *fl, st xdst->u.rt6.rt6i_src.plen); if (ipv6_addr_equal(&xdst->u.rt6.rt6i_dst.addr, &fl_dst_prefix) && ipv6_addr_equal(&xdst->u.rt6.rt6i_src.addr, &fl_src_prefix) && + xfrm_sec_ctx_match(xfrm_policy_security(policy), + xfrm_state_security(dst->xfrm)) && xfrm_bundle_ok(xdst, fl, AF_INET6)) { dst_clone(dst); break; diff -puN net/key/af_key.c~lsm-xfrm-nethooks net/key/af_key.c --- linux-2.6.12-rc4-nethooks/net/key/af_key.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/key/af_key.c 2005-05-16 16:13:56.000000000 -0400 @@ -336,6 +336,7 @@ static u8 sadb_ext_min_len[] = { [SADB_X_EXT_NAT_T_SPORT] = (u8) sizeof(struct sadb_x_nat_t_port), [SADB_X_EXT_NAT_T_DPORT] = (u8) sizeof(struct sadb_x_nat_t_port), [SADB_X_EXT_NAT_T_OA] = (u8) sizeof(struct sadb_address), + [SADB_X_EXT_SEC_CTX] = (u8) sizeof(struct sadb_x_sec_ctx), }; /* Verify sadb_address_{len,prefixlen} against sa_family. */ @@ -383,6 +384,22 @@ static int verify_address_len(void *p) return 0; } +static inline int verify_sec_ctx_len(void *p) +{ + struct sadb_x_sec_ctx *sec_ctx = (struct sadb_x_sec_ctx *)p; + int len = 0; + + len += sizeof(struct sadb_x_sec_ctx); + len += sec_ctx->sadb_x_ctx_len; + len += sizeof(uint64_t) - 1; + len /= sizeof(uint64_t); + + if (sec_ctx->sadb_x_sec_len != len) + return -EINVAL; + + return 0; +} + static int present_and_same_family(struct sadb_address *src, struct sadb_address *dst) { @@ -438,6 +455,10 @@ static int parse_exthdrs(struct sk_buff if (verify_address_len(p)) return -EINVAL; } + if (ext_type == SADB_X_EXT_SEC_CTX) { + if (verify_sec_ctx_len(p)) + return -EINVAL; + } ext_hdrs[ext_type-1] = p; } p += ext_len; @@ -586,6 +607,9 @@ static struct sk_buff * pfkey_xfrm_state struct sadb_key *key; struct sadb_x_sa2 *sa2; struct sockaddr_in *sin; + struct sadb_x_sec_ctx *sec_ctx; + struct xfrm_sec_ctx *xfrm_ctx; + int ctx_size = 0; #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) struct sockaddr_in6 *sin6; #endif @@ -609,6 +633,12 @@ static struct sk_buff * pfkey_xfrm_state sizeof(struct sadb_address)*2 + sockaddr_size*2 + sizeof(struct sadb_x_sa2); + + if ((xfrm_ctx = xfrm_state_security(x))) { + ctx_size = PFKEY_ALIGN8(xfrm_ctx->ctx_len); + size += sizeof(struct sadb_x_sec_ctx) + ctx_size; + } + /* identity & sensitivity */ if ((x->props.family == AF_INET && @@ -892,6 +922,20 @@ static struct sk_buff * pfkey_xfrm_state n_port->sadb_x_nat_t_port_reserved = 0; } + /* security context */ + if (xfrm_ctx) { + sec_ctx = (struct sadb_x_sec_ctx *) skb_put(skb, + sizeof(struct sadb_x_sec_ctx) + ctx_size); + sec_ctx->sadb_x_sec_len = + (sizeof(struct sadb_x_sec_ctx) + ctx_size) / sizeof(uint64_t); + sec_ctx->sadb_x_sec_exttype = SADB_X_EXT_SEC_CTX; + sec_ctx->sadb_x_ctx_doi = xfrm_ctx->ctx_doi; + sec_ctx->sadb_x_ctx_alg = xfrm_ctx->ctx_alg; + sec_ctx->sadb_x_ctx_len = xfrm_ctx->ctx_len; + memcpy(sec_ctx + 1, xfrm_ctx->ctx_str, + xfrm_ctx->ctx_len); + } + return skb; } @@ -902,6 +946,7 @@ static struct xfrm_state * pfkey_msg2xfr struct sadb_lifetime *lifetime; struct sadb_sa *sa; struct sadb_key *key; + struct sadb_x_sec_ctx *sec_ctx; uint16_t proto; int err; @@ -984,6 +1029,13 @@ static struct xfrm_state * pfkey_msg2xfr x->lft.soft_add_expires_seconds = lifetime->sadb_lifetime_addtime; x->lft.soft_use_expires_seconds = lifetime->sadb_lifetime_usetime; } + + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; + if (sec_ctx != NULL) { + if (security_xfrm_state_alloc(x, sec_ctx)) + goto out; + } + key = (struct sadb_key*) ext_hdrs[SADB_EXT_KEY_AUTH-1]; if (sa->sadb_sa_auth) { int keysize = 0; @@ -1634,6 +1686,18 @@ parse_ipsecrequests(struct xfrm_policy * return 0; } +static inline int pfkey_xfrm_policy2sec_ctx_size(struct xfrm_policy *xp) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); + + if (xfrm_ctx) { + int len = sizeof(struct sadb_x_sec_ctx); + len += xfrm_ctx->ctx_len; + return PFKEY_ALIGN8(len); + } + return 0; +} + static int pfkey_xfrm_policy2msg_size(struct xfrm_policy *xp) { int sockaddr_size = pfkey_sockaddr_size(xp->family); @@ -1647,7 +1711,8 @@ static int pfkey_xfrm_policy2msg_size(st (sockaddr_size * 2) + sizeof(struct sadb_x_policy) + (xp->xfrm_nr * (sizeof(struct sadb_x_ipsecrequest) + - (socklen * 2))); + (socklen * 2))) + + pfkey_xfrm_policy2sec_ctx_size(xp); } static struct sk_buff * pfkey_xfrm_policy2msg_prep(struct xfrm_policy *xp) @@ -1671,6 +1736,8 @@ static void pfkey_xfrm_policy2msg(struct struct sadb_lifetime *lifetime; struct sadb_x_policy *pol; struct sockaddr_in *sin; + struct sadb_x_sec_ctx *sec_ctx; + struct xfrm_sec_ctx *xfrm_ctx; #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) struct sockaddr_in6 *sin6; #endif @@ -1855,19 +1922,35 @@ static void pfkey_xfrm_policy2msg(struct } } } + + /* security context */ + if ((xfrm_ctx = xfrm_policy_security(xp))) { + int ctx_size = pfkey_xfrm_policy2sec_ctx_size(xp); + + sec_ctx = (struct sadb_x_sec_ctx *) skb_put(skb, ctx_size); + sec_ctx->sadb_x_sec_len = ctx_size / sizeof(uint64_t); + sec_ctx->sadb_x_sec_exttype = SADB_X_EXT_SEC_CTX; + sec_ctx->sadb_x_ctx_doi = xfrm_ctx->ctx_doi; + sec_ctx->sadb_x_ctx_alg = xfrm_ctx->ctx_alg; + sec_ctx->sadb_x_ctx_len = xfrm_ctx->ctx_len; + memcpy(sec_ctx + 1, xfrm_ctx->ctx_str, + xfrm_ctx->ctx_len); + } + hdr->sadb_msg_len = size / sizeof(uint64_t); hdr->sadb_msg_reserved = atomic_read(&xp->refcnt); } static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { - int err; + int err = 0; struct sadb_lifetime *lifetime; struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; struct sk_buff *out_skb; struct sadb_msg *out_hdr; + struct sadb_x_sec_ctx *sec_ctx; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -1914,6 +1997,12 @@ static int pfkey_spdadd(struct sock *sk, if (xp->selector.dport) xp->selector.dport_mask = ~0; + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; + if (sec_ctx != NULL) { + if (security_xfrm_policy_alloc(xp, sec_ctx)) + goto out; + } + xp->lft.soft_byte_limit = XFRM_INF; xp->lft.hard_byte_limit = XFRM_INF; xp->lft.soft_packet_limit = XFRM_INF; @@ -1963,6 +2052,7 @@ static int pfkey_spdadd(struct sock *sk, return 0; out: + security_xfrm_policy_free(xp); kfree(xp); return err; } @@ -1972,10 +2062,11 @@ static int pfkey_spddelete(struct sock * int err; struct sadb_address *sa; struct sadb_x_policy *pol; - struct xfrm_policy *xp; + struct xfrm_policy *xp, tmp; struct sk_buff *out_skb; struct sadb_msg *out_hdr; struct xfrm_selector sel; + struct sadb_x_sec_ctx *sec_ctx; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -2004,7 +2095,15 @@ static int pfkey_spddelete(struct sock * if (sel.dport) sel.dport_mask = ~0; - xp = xfrm_policy_bysel(pol->sadb_x_policy_dir-1, &sel, 1); + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; + memcpy(&tmp.selector, &sel, sizeof(struct xfrm_selector)); + if (sec_ctx != NULL) { + if (security_xfrm_policy_alloc(&tmp, sec_ctx)) + goto out; + } + + xp = xfrm_policy_bysel(pol->sadb_x_policy_dir-1, &tmp.selector, 1); + security_xfrm_policy_free(&tmp); if (xp == NULL) return -ENOENT; @@ -2482,6 +2581,7 @@ static struct xfrm_policy *pfkey_compile { struct xfrm_policy *xp; struct sadb_x_policy *pol = (struct sadb_x_policy*)data; + struct sadb_x_sec_ctx *sec_ctx; switch (family) { case AF_INET: @@ -2531,10 +2631,21 @@ static struct xfrm_policy *pfkey_compile (*dir = parse_ipsecrequests(xp, pol)) < 0) goto out; + /* security context too */ + if (len >= (pol->sadb_x_policy_len*8 + + sizeof(struct sadb_x_sec_ctx))) { + char *p = (char *) pol; + p += pol->sadb_x_policy_len*8; + sec_ctx = (struct sadb_x_sec_ctx *) p; + if (security_xfrm_policy_alloc(xp, sec_ctx)) + goto out; + } + *dir = pol->sadb_x_policy_dir-1; return xp; out: + security_xfrm_policy_free(xp); kfree(xp); return NULL; } diff -puN net/xfrm/xfrm_policy.c~lsm-xfrm-nethooks net/xfrm/xfrm_policy.c --- linux-2.6.12-rc4-nethooks/net/xfrm/xfrm_policy.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/xfrm/xfrm_policy.c 2005-05-16 16:16:54.000000000 -0400 @@ -257,6 +257,7 @@ void __xfrm_policy_destroy(struct xfrm_p if (del_timer(&policy->timer)) BUG(); + security_xfrm_policy_free(policy); kfree(policy); } EXPORT_SYMBOL(__xfrm_policy_destroy); @@ -396,7 +397,8 @@ struct xfrm_policy *xfrm_policy_bysel(in write_lock_bh(&xfrm_policy_lock); for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL; p = &pol->next) { - if (memcmp(sel, &pol->selector, sizeof(*sel)) == 0) { + if ((memcmp(sel, &pol->selector, xfrm_selector_base_size()) == 0) && + (xfrm_sec_ctx_match(sel->security, xfrm_policy_security(pol)))) { xfrm_pol_hold(pol); if (delete) *p = pol->next; @@ -492,7 +494,7 @@ EXPORT_SYMBOL(xfrm_policy_walk); /* Find policy to apply to this flow. */ -static void xfrm_policy_lookup(struct flowi *fl, u16 family, u8 dir, +static void xfrm_policy_lookup(struct flowi *fl, struct sock *sk, u16 family, u8 dir, void **objp, atomic_t **obj_refp) { struct xfrm_policy *pol; @@ -506,9 +508,12 @@ static void xfrm_policy_lookup(struct fl continue; match = xfrm_selector_match(sel, fl, family); + if (match) { - xfrm_pol_hold(pol); - break; + if (!security_xfrm_policy_lookup(sk, sel, fl, dir)) { + xfrm_pol_hold(pol); + break; + } } } read_unlock_bh(&xfrm_policy_lock); @@ -516,15 +521,38 @@ static void xfrm_policy_lookup(struct fl *obj_refp = &pol->refcnt; } +static inline int policy_to_flow_dir(int dir) +{ + if (XFRM_POLICY_IN == FLOW_DIR_IN && + XFRM_POLICY_OUT == FLOW_DIR_OUT && + XFRM_POLICY_FWD == FLOW_DIR_FWD) + return dir; + switch (dir) { + default: + case XFRM_POLICY_IN: + return FLOW_DIR_IN; + case XFRM_POLICY_OUT: + return FLOW_DIR_OUT; + case XFRM_POLICY_FWD: + return FLOW_DIR_FWD; + }; +} + static struct xfrm_policy *xfrm_sk_policy_lookup(struct sock *sk, int dir, struct flowi *fl) { struct xfrm_policy *pol; read_lock_bh(&xfrm_policy_lock); if ((pol = sk->sk_policy[dir]) != NULL) { - int match = xfrm_selector_match(&pol->selector, fl, + struct xfrm_selector *sel = &pol->selector; + int match = xfrm_selector_match(sel, fl, sk->sk_family); + int err = 0; + if (match) + err = security_xfrm_policy_lookup(sk, sel, fl, policy_to_flow_dir(dir)); + + if (match && !err) xfrm_pol_hold(pol); else pol = NULL; @@ -595,6 +623,10 @@ static struct xfrm_policy *clone_policy( if (newp) { newp->selector = old->selector; + if (security_xfrm_policy_clone(old, newp)) { + kfree(newp); + return (struct xfrm_policy *)NULL; /* ENOMEM */ + } newp->lft = old->lft; newp->curlft = old->curlft; newp->action = old->action; @@ -706,22 +738,6 @@ xfrm_bundle_create(struct xfrm_policy *p return err; } -static inline int policy_to_flow_dir(int dir) -{ - if (XFRM_POLICY_IN == FLOW_DIR_IN && - XFRM_POLICY_OUT == FLOW_DIR_OUT && - XFRM_POLICY_FWD == FLOW_DIR_FWD) - return dir; - switch (dir) { - default: - case XFRM_POLICY_IN: - return FLOW_DIR_IN; - case XFRM_POLICY_OUT: - return FLOW_DIR_OUT; - case XFRM_POLICY_FWD: - return FLOW_DIR_FWD; - }; -} static int stale_bundle(struct dst_entry *dst); @@ -751,7 +767,7 @@ restart: if ((dst_orig->flags & DST_NOXFRM) || !xfrm_policy_list[XFRM_POLICY_OUT]) return 0; - policy = flow_cache_lookup(fl, family, + policy = flow_cache_lookup(fl, sk, family, policy_to_flow_dir(XFRM_POLICY_OUT), xfrm_policy_lookup); } @@ -942,7 +958,7 @@ int __xfrm_policy_check(struct sock *sk, int i; for (i=skb->sp->len-1; i>=0; i--) { - struct sec_decap_state *xvec = &(skb->sp->x[i]); + struct sec_decap_state *xvec = &(skb->sp->x[i]); if (!xfrm_selector_match(&xvec->xvec->sel, &fl, family)) return 0; @@ -960,7 +976,7 @@ int __xfrm_policy_check(struct sock *sk, pol = xfrm_sk_policy_lookup(sk, dir, &fl); if (!pol) - pol = flow_cache_lookup(&fl, family, + pol = flow_cache_lookup(&fl, sk, family, policy_to_flow_dir(dir), xfrm_policy_lookup); diff -puN net/xfrm/xfrm_state.c~lsm-xfrm-nethooks net/xfrm/xfrm_state.c --- linux-2.6.12-rc4-nethooks/net/xfrm/xfrm_state.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/xfrm/xfrm_state.c 2005-05-16 15:49:41.000000000 -0400 @@ -74,6 +74,7 @@ static void xfrm_state_gc_destroy(struct x->type->destructor(x); xfrm_put_type(x->type); } + security_xfrm_state_free(x); kfree(x); } @@ -338,7 +339,8 @@ xfrm_state_find(xfrm_address_t *daddr, x selector. */ if (x->km.state == XFRM_STATE_VALID) { - if (!xfrm_selector_match(&x->sel, fl, family)) + if (!xfrm_selector_match(&x->sel, fl, family) || + !xfrm_sec_ctx_match(xfrm_policy_security(pol), xfrm_state_security(x))) continue; if (!best || best->km.dying > x->km.dying || @@ -349,7 +351,8 @@ xfrm_state_find(xfrm_address_t *daddr, x acquire_in_progress = 1; } else if (x->km.state == XFRM_STATE_ERROR || x->km.state == XFRM_STATE_EXPIRED) { - if (xfrm_selector_match(&x->sel, fl, family)) + if (xfrm_selector_match(&x->sel, fl, family) && + xfrm_sec_ctx_match(xfrm_policy_security(pol), xfrm_state_security(x))) error = -ESRCH; } } @@ -374,6 +377,13 @@ xfrm_state_find(xfrm_address_t *daddr, x xfrm_init_tempsel(x, fl, tmpl, daddr, saddr, family); if (km_query(x, tmpl, pol) == 0) { + if (!xfrm_sec_ctx_match(xfrm_policy_security(pol), xfrm_state_security(x))) { + x->km.state = XFRM_STATE_DEAD; + xfrm_state_put(x); + x = NULL; + error = 1; + goto out; + } x->km.state = XFRM_STATE_ACQ; list_add_tail(&x->bydst, xfrm_state_bydst+h); xfrm_state_hold(x); diff -puN net/xfrm/xfrm_user.c~lsm-xfrm-nethooks net/xfrm/xfrm_user.c --- linux-2.6.12-rc4-nethooks/net/xfrm/xfrm_user.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/xfrm/xfrm_user.c 2005-05-16 16:20:27.000000000 -0400 @@ -200,6 +200,32 @@ static int attach_encap_tmpl(struct xfrm return 0; } + +static inline int xfrm_user_sec_ctx_size(struct xfrm_policy *xp) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); + int len; + + if (xfrm_ctx) { + len = sizeof(struct xfrm_user_sec_ctx); + len += xfrm_ctx->ctx_len; + return len; + } + return 0; +} + +static int attach_sec_ctx(struct xfrm_state *x, struct rtattr *u_arg) +{ + struct xfrm_user_sec_ctx *uxsc = RTA_DATA(u_arg); + + if (uxsc) { + security_xfrm_state_free(x); + return security_xfrm_state_alloc(x, uxsc); + } + + return 0; +} + static void copy_from_user_state(struct xfrm_state *x, struct xfrm_usersa_info *p) { memcpy(&x->id, &p->id, sizeof(x->id)); @@ -249,6 +275,9 @@ static struct xfrm_state *xfrm_state_con if (err) goto error; + if ((err = attach_sec_ctx(x, xfrma[XFRMA_SEC_CTX-1]))) + goto error; + x->curlft.add_time = (unsigned long) xtime.tv_sec; x->km.state = XFRM_STATE_VALID; x->km.seq = p->seq; @@ -335,6 +364,27 @@ struct xfrm_dump_info { int this_idx; }; +static int dump_one_sec_ctx(struct xfrm_sec_ctx *ctx, struct xfrm_user_sec_ctx *uctx, struct sk_buff *skb, int ctx_size) +{ + if (!ctx) + return -1; + + uctx->exttype = XFRMA_SEC_CTX; + uctx->len = ctx_size; + uctx->ctx_doi = ctx->ctx_doi; + uctx->ctx_alg = ctx->ctx_alg; + uctx->ctx_len = ctx->ctx_len; + + memcpy(uctx + 1, ctx->ctx_str, ctx->ctx_len); + + RTA_PUT(skb, XFRMA_SEC_CTX, ctx_size, uctx); + + return 0; + +rtattr_failure: + return -1; +} + static int dump_one_state(struct xfrm_state *x, int count, void *ptr) { struct xfrm_dump_info *sp = ptr; @@ -343,6 +393,7 @@ static int dump_one_state(struct xfrm_st struct xfrm_usersa_info *p; struct nlmsghdr *nlh; unsigned char *b = skb->tail; + struct xfrm_sec_ctx *xfrm_ctx; if (sp->this_idx < sp->start_idx) goto out; @@ -367,6 +418,18 @@ static int dump_one_state(struct xfrm_st if (x->encap) RTA_PUT(skb, XFRMA_ENCAP, sizeof(*x->encap), x->encap); + if ((xfrm_ctx = xfrm_state_security(x))) { + int ctx_size = sizeof(struct xfrm_user_sec_ctx) + + xfrm_ctx->ctx_len + 1; + struct xfrm_user_sec_ctx *uctx = kmalloc(ctx_size, GFP_KERNEL); + int err; + + err = dump_one_sec_ctx(xfrm_ctx, uctx, skb, ctx_size); + kfree(uctx); + + if (err < 0) + goto rtattr_failure; + } nlh->nlmsg_len = skb->tail - b; out: sp->this_idx++; @@ -580,6 +643,27 @@ static int verify_newpolicy_info(struct return verify_policy_dir(p->dir); } +static int copy_sec_ctx(struct xfrm_policy *pol, struct xfrm_user_sec_ctx *uctx) +{ + int err = 0; + + security_xfrm_policy_free(pol); + err = security_xfrm_policy_alloc(pol, uctx); + return err; +} + +static int copy_from_user_sec_ctx(struct xfrm_policy *pol, struct rtattr **xfrma) +{ + struct rtattr *rt = xfrma[XFRMA_SEC_CTX-1]; + struct xfrm_user_sec_ctx *uctx = RTA_DATA(rt); + + if (uctx) { + copy_sec_ctx(pol, uctx); + } + + return 0; +} + static void copy_templates(struct xfrm_policy *xp, struct xfrm_user_tmpl *ut, int nr) { @@ -658,7 +742,10 @@ static struct xfrm_policy *xfrm_policy_c } copy_from_user_policy(xp, p); - err = copy_from_user_tmpl(xp, xfrma); + + if (!(err = copy_from_user_tmpl(xp, xfrma))) + err = copy_from_user_sec_ctx(xp, xfrma); + if (err) { *errp = err; kfree(xp); @@ -728,6 +815,27 @@ rtattr_failure: return -1; } +static int copy_to_user_sec_ctx(struct xfrm_policy *xp, struct sk_buff *skb, int src) +{ + int err = 0; + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); + + if (xfrm_ctx) { + int ctx_size = sizeof(struct xfrm_user_sec_ctx) + + xfrm_ctx->ctx_len; + struct xfrm_user_sec_ctx *uctx = kmalloc(ctx_size, GFP_KERNEL); + + if (!uctx) + return -ENOMEM; + + err = dump_one_sec_ctx(xfrm_ctx, uctx, skb, + ctx_size); + kfree(uctx); + } + + return err; +} + static int dump_one_policy(struct xfrm_policy *xp, int dir, int count, void *ptr) { struct xfrm_dump_info *sp = ptr; @@ -749,6 +857,8 @@ static int dump_one_policy(struct xfrm_p copy_to_user_policy(xp, p, dir); if (copy_to_user_tmpl(xp, skb) < 0) goto nlmsg_failure; + if (copy_to_user_sec_ctx(xp, skb, 0) < 0) + goto nlmsg_failure; nlh->nlmsg_len = skb->tail - b; out: @@ -804,7 +914,7 @@ static struct sk_buff *xfrm_policy_netli static int xfrm_get_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { - struct xfrm_policy *xp; + struct xfrm_policy *xp, tmp; struct xfrm_userpolicy_id *p; int err; int delete; @@ -818,8 +928,20 @@ static int xfrm_get_policy(struct sk_buf if (p->index) xp = xfrm_policy_byid(p->dir, p->index, delete); - else - xp = xfrm_policy_bysel(p->dir, &p->sel, delete); + else { + struct rtattr **rtattrs = (struct rtattr **) xfrma; + struct rtattr *rt = rtattrs[XFRMA_SEC_CTX-1]; + + memcpy(&tmp.selector, &p->sel, sizeof(struct xfrm_selector)); + if (rt) { + struct xfrm_user_sec_ctx *uxsc = RTA_DATA(rt); + + if ((err = security_xfrm_policy_alloc(&tmp, uxsc))) + return err; + } + xp = xfrm_policy_bysel(p->dir, &tmp.selector, delete); + security_xfrm_policy_free(&tmp); + } if (xp == NULL) return -ENOENT; @@ -1101,6 +1223,8 @@ static int build_acquire(struct sk_buff if (copy_to_user_tmpl(xp, skb) < 0) goto nlmsg_failure; + if (copy_to_user_sec_ctx(xp, skb, 1) < 0) + goto nlmsg_failure; nlh->nlmsg_len = skb->tail - b; return skb->len; @@ -1114,10 +1238,12 @@ static int xfrm_send_acquire(struct xfrm struct xfrm_policy *xp, int dir) { struct sk_buff *skb; + struct xfrm_sec_ctx *ctx; size_t len; len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); len += NLMSG_SPACE(sizeof(struct xfrm_user_acquire)); + len += xfrm_user_sec_ctx_size(xp); skb = alloc_skb(len, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; @@ -1138,8 +1264,9 @@ static struct xfrm_policy *xfrm_compile_ { struct xfrm_userpolicy_info *p = (struct xfrm_userpolicy_info *)data; struct xfrm_user_tmpl *ut = (struct xfrm_user_tmpl *) (p + 1); + struct xfrm_user_sec_ctx *uctx; struct xfrm_policy *xp; - int nr; + int nr = 0; switch (family) { case AF_INET: @@ -1167,9 +1294,26 @@ static struct xfrm_policy *xfrm_compile_ verify_newpolicy_info(p)) return NULL; + if (len > (sizeof(*p) + (XFRM_MAX_DEPTH * + sizeof(struct xfrm_user_tmpl)))) { + struct xfrm_user_tmpl *tmpl; + uctx = (struct xfrm_user_sec_ctx *) (ut + XFRM_MAX_DEPTH); + + if (len != sizeof(*p) + + (XFRM_MAX_DEPTH * sizeof(struct xfrm_user_tmpl)) + + uctx->len) + return NULL; + + /* spi must be zero'd unless real tmpl */ + for (tmpl = ut; tmpl->id.spi != 0; tmpl = tmpl + 1) + nr++; + } + else { + uctx = (struct xfrm_user_sec_ctx *) NULL; nr = ((len - sizeof(*p)) / sizeof(*ut)); if (nr > XFRM_MAX_DEPTH) return NULL; + } xp = xfrm_policy_alloc(GFP_KERNEL); if (xp == NULL) { @@ -1179,6 +1323,8 @@ static struct xfrm_policy *xfrm_compile_ copy_from_user_policy(xp, p); copy_templates(xp, ut, nr); + if (uctx) + copy_sec_ctx(xp, uctx); *dir = p->dir; @@ -1199,6 +1345,8 @@ static int build_polexpire(struct sk_buf copy_to_user_policy(xp, &upe->pol, dir); if (copy_to_user_tmpl(xp, skb) < 0) goto nlmsg_failure; + if (copy_to_user_sec_ctx(xp, skb, 2) < 0) + goto nlmsg_failure; upe->hard = !!hard; nlh->nlmsg_len = skb->tail - b; @@ -1216,6 +1364,7 @@ static int xfrm_send_policy_notify(struc len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); len += NLMSG_SPACE(sizeof(struct xfrm_user_polexpire)); + len += xfrm_user_sec_ctx_size(xp); skb = alloc_skb(len, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; diff -puN security/dummy.c~lsm-xfrm-nethooks security/dummy.c --- linux-2.6.12-rc4-nethooks/security/dummy.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/security/dummy.c 2005-05-10 15:40:22.000000000 -0400 @@ -811,6 +811,35 @@ static inline void dummy_sk_free_securit } #endif /* CONFIG_SECURITY_NETWORK */ +#ifdef CONFIG_SECURITY_NETWORK_XFRM +static int dummy_xfrm_policy_alloc_security(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx) +{ + return 0; +} + +static inline int dummy_xfrm_policy_clone_security(struct xfrm_policy *old, struct xfrm_policy *new) +{ + return 0; +} + +static void dummy_xfrm_policy_free_security(struct xfrm_policy *xp) +{ +} + +static int dummy_xfrm_state_alloc_security(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx) +{ + return 0; +} + +static void dummy_xfrm_state_free_security(struct xfrm_state *x) +{ +} + +static int dummy_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir) +{ + return 0; +} +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ static int dummy_register_security (const char *name, struct security_operations *ops) { return -EINVAL; @@ -992,5 +1021,13 @@ void security_fixup_ops (struct security set_to_dummy_if_null(ops, sk_alloc_security); set_to_dummy_if_null(ops, sk_free_security); #endif /* CONFIG_SECURITY_NETWORK */ +#ifdef CONFIG_SECURITY_NETWORK_XFRM + set_to_dummy_if_null(ops, xfrm_policy_alloc_security); + set_to_dummy_if_null(ops, xfrm_policy_clone_security); + set_to_dummy_if_null(ops, xfrm_policy_free_security); + set_to_dummy_if_null(ops, xfrm_state_alloc_security); + set_to_dummy_if_null(ops, xfrm_state_free_security); + set_to_dummy_if_null(ops, xfrm_policy_lookup); +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ } diff -puN security/Kconfig~lsm-xfrm-nethooks security/Kconfig --- linux-2.6.12-rc4-nethooks/security/Kconfig~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/security/Kconfig 2005-05-10 15:28:44.000000000 -0400 @@ -53,6 +53,19 @@ config SECURITY_NETWORK implement socket and networking access controls. If you are unsure how to answer this question, answer N. +config SECURITY_NETWORK_XFRM + bool "XFRM (IPSec) Networking Security Hooks" + depends on XFRM && SECURITY_NETWORK + help + This enables the XFRM (IPSec) networking security hooks. + If enabled, a security module can use these hooks to + implement per-packet access controls based on labels + derived from IPSec policy. Non-IPSec communications are + designated as unlabelled, and only sockets authorized + to communicate unlabelled data can send without using + IPSec. + If you are unsure how to answer this question, answer N. + config SECURITY_CAPABILITIES tristate "Default Linux Capabilities" depends on SECURITY _ From jaegert@us.ibm.com Mon May 16 19:59:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 19:59:31 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4H2xPOv023089 for ; Mon, 16 May 2005 19:59:25 -0700 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j4H2xtC0020344; Mon, 16 May 2005 22:59:55 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j4H2wgS39810; Mon, 16 May 2005 22:58:42 -0400 Received: from localhost (sig-9-65-126-151.mts.ibm.com [9.65.126.151]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j4H2wew36520; Mon, 16 May 2005 22:58:41 -0400 Date: Mon, 16 May 2005 22:58:39 -0400 (Eastern Daylight Time) From: Trent Jaeger To: netdev@oss.sgi.com, chrisw@osdl.org cc: jaegert@us.ibm.com, sergeh@us.ibm.com, latten@us.ibm.com, sds@tycho.nsa.gov, jmorris@redhat.com Subject: [PATCH 2/2] LSM-IPSec Networking Hooks Message-ID: X-Warning: UNAuthenticated Sender MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaegert@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 18051 Lines: 599 This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. --- security/selinux/Makefile | 2 security/selinux/hooks.c | 20 + security/selinux/include/nethooks.h | 8 security/selinux/nethooks.c | 428 ++++++++++++++++++++++++++++++++++++ 4 files changed, 457 insertions(+), 1 deletion(-) diff -puN security/selinux/hooks.c~lsm-selinux-nethooks security/selinux/hooks.c --- linux-2.6.12-rc4-nethooks/security/selinux/hooks.c~lsm-selinux-nethooks 2005-05-13 13:15:47.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/security/selinux/hooks.c 2005-05-13 13:15:47.000000000 -0400 @@ -72,6 +72,7 @@ #include "avc.h" #include "objsec.h" #include "netif.h" +#include "nethooks.h" #define XATTR_SELINUX_SUFFIX "selinux" #define XATTR_NAME_SELINUX XATTR_SECURITY_PREFIX XATTR_SELINUX_SUFFIX @@ -3350,6 +3351,10 @@ static int selinux_socket_sock_rcv_skb(s err = avc_has_perm(sock_sid, port_sid, sock_class, recv_perm, &ad); } + + if (!err) + err = selinux_xfrm_sock_rcv_skb(sock_sid, skb); + out: return err; } @@ -3537,6 +3542,11 @@ static unsigned int selinux_ip_postroute send_perm, &ad) ? NF_DROP : NF_ACCEPT; } + if (err != NF_ACCEPT) + goto out; + + err = selinux_xfrm_postroute_last(isec->sid, skb); + out: return err; } @@ -4389,6 +4399,15 @@ static struct security_operations selinu .sk_alloc_security = selinux_sk_alloc_security, .sk_free_security = selinux_sk_free_security, #endif + +#ifdef CONFIG_SECURITY_NETWORK_XFRM + .xfrm_policy_alloc_security = selinux_xfrm_policy_alloc, + .xfrm_policy_clone_security = selinux_xfrm_policy_clone, + .xfrm_policy_free_security = selinux_xfrm_policy_free, + .xfrm_state_alloc_security = selinux_xfrm_state_alloc, + .xfrm_state_free_security = selinux_xfrm_state_free, + .xfrm_policy_lookup = selinux_xfrm_policy_lookup, +#endif }; static __init int selinux_init(void) @@ -4499,6 +4518,7 @@ static int __init selinux_nf_ip_init(voi panic("SELinux: nf_register_hook for IPv6: error %d\n", err); #endif /* IPV6 */ + out: return err; } diff -puN /dev/null security/selinux/include/nethooks.h --- /dev/null 2004-02-23 16:02:56.000000000 -0500 +++ linux-2.6.12-rc4-nethooks-root/security/selinux/include/nethooks.h 2005-05-13 13:15:47.000000000 -0400 @@ -0,0 +1,8 @@ +int selinux_xfrm_policy_alloc(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx); +int selinux_xfrm_policy_clone(struct xfrm_policy *old, struct xfrm_policy *new); +void selinux_xfrm_policy_free(struct xfrm_policy *xp); +int selinux_xfrm_state_alloc(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx); +void selinux_xfrm_state_free(struct xfrm_state *x); +int selinux_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir); +int selinux_xfrm_sock_rcv_skb(u32 sid, struct sk_buff *skb); +int selinux_xfrm_postroute_last(u32 isec_sid, struct sk_buff *skb); diff -puN security/selinux/Makefile~lsm-selinux-nethooks security/selinux/Makefile --- linux-2.6.12-rc4-nethooks/security/selinux/Makefile~lsm-selinux-nethooks 2005-05-13 13:15:47.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/security/selinux/Makefile 2005-05-13 13:15:47.000000000 -0400 @@ -4,7 +4,7 @@ obj-$(CONFIG_SECURITY_SELINUX) := selinux.o ss/ -selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o +selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o nethooks.o selinux-$(CONFIG_SECURITY_NETWORK) += netif.o diff -puN /dev/null security/selinux/nethooks.c --- /dev/null 2004-02-23 16:02:56.000000000 -0500 +++ linux-2.6.12-rc4-nethooks-root/security/selinux/nethooks.c 2005-05-16 14:28:25.000000000 -0400 @@ -0,0 +1,428 @@ +/* + * USAGE: + * NOTES: + * 1. Make sure to enable the following options in your kernel config: + * CONFIG_SECURITY=y + * CONFIG_SECURITY_NETWORK=y + * CONFIG_SECURITY_NETWORK_XFRM=y + * CONFIG_SECURITY_SELINUX=m/y + * ISSUES: + * 1. Caching packets, so they are not dropped during negotiation + * 2. Emulating a reasonable SO_PEERSEC across machines + * 3. Testing sk_policy setting with context + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "nethooks.h" +#include "avc.h" +#include "objsec.h" + +/************************************************************** + * + * defines + * + **************************************************************/ + +#define DEBUG 0 + +/************************************************************** + * + * structures + * + **************************************************************/ + +/************************************************************** + * + * globals + * + **************************************************************/ + +/************************************************************** + * + * macros/inlines + * + **************************************************************/ + +#define nethooks_debug(fmt, args...) {if (DEBUG) printk(KERN_NOTICE fmt,## args);} + +/* + * Extract the security blob from the sock (it's actually on the socket) + */ +static inline struct inode_security_struct *get_sock_isec(struct sock *sk) +{ + if (!sk->sk_socket) { + nethooks_debug("%s: no socket on this sock (!?)\n", + __FUNCTION__); + return (struct inode_security_struct *) NULL; + } + + return SOCK_INODE(sk->sk_socket)->i_security; +} + +/* + * Returns true if the xfrm contains a security blob for SELinux + */ +static inline int selinux_authorizable_xfrm(struct xfrm_state *x) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_state_security(x); + + return (xfrm_ctx && + (xfrm_ctx->ctx_doi == XFRM_SC_DOI_LSM) && + (xfrm_ctx->ctx_alg == XFRM_SC_ALG_SELINUX)); +} + +/************************************************************** + * + * LSM + * + **************************************************************/ +#ifdef CONFIG_SECURITY_NETWORK_XFRM +/* + * LSM hook implementation that authorizes that a socket can be used + * with the corresponding xfrm_policy selector and direction. + */ + +int selinux_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir) +{ + int rc = 0; + struct inode_security_struct *isec = NULL; + u32 sock_sid, sel_sid = SECINITSID_UNLABELED; + + nethooks_debug("%s: authorize\n", __FUNCTION__); + + if (!sk) { + /* no sock to send -- e.g., icmp reply */ + /* authorize as kernel packet */ + if (fl && fl->proto == IPPROTO_ICMP) { + nethooks_debug("%s: ICMP case\n", + __FUNCTION__); + sock_sid = SECINITSID_KERNEL; + goto authorize; + } + /* + * hooks.c accepts packets with no socket unconditionally + */ + nethooks_debug("%s: no sock on this skbuff: non-ICMP\n", + __FUNCTION__); + goto out; + } + + read_lock_bh(&sk->sk_callback_lock); + isec = get_sock_isec(sk); + + /* No isec: allow if any sock can read target */ + if (!isec) { + nethooks_debug("%s: no isec from sock\n", __FUNCTION__); + sock_sid = SECINITSID_ANY_SOCKET; + } + else { + sock_sid = isec->sid; + } + read_unlock_bh(&sk->sk_callback_lock); + + +authorize: + /* Selector sid is either set to label or ANY_ASSOC */ + if (sel->security) { + sel_sid = sel->security->ctx_sid; + nethooks_debug("%s: %s for context %.50s; sid: %d; sock: %d\n", + __FUNCTION__, + ((dir == FLOW_DIR_IN) ? "input" : + ((dir == FLOW_DIR_OUT) ? "output" : "forward")), + sel->security->ctx_str, + sel_sid, + sock_sid); + } + + rc = avc_has_perm(sock_sid, sel_sid, SECCLASS_ASSOCIATION, + ((dir == FLOW_DIR_IN) ? ASSOCIATION__RECVFROM : + ((dir == FLOW_DIR_OUT) ? ASSOCIATION__SENDTO : + (ASSOCIATION__SENDTO | ASSOCIATION__RECVFROM))), + NULL); + +out: + return rc; +} + +/* + * Security blob allocation for xfrm_policy and xfrm_state + * -- both attached to selectors + */ +static inline int selinux_xfrm_selector_alloc(struct xfrm_selector *sel, struct sadb_x_sec_ctx *sec_ctx) +{ + int rc = 0; + + if (!sec_ctx) + return -EINVAL; + + nethooks_debug(KERN_NOTICE "%s: got a sec_ctx for policy\n", + __FUNCTION__); + + if (sec_ctx->sadb_x_ctx_len >= PAGE_SIZE) + return -ENOMEM; + + sel->security = kmalloc(sizeof(*sel->security) + + sec_ctx->sadb_x_ctx_len + 1, + GFP_KERNEL); + + if (!sel->security) + return -ENOMEM; + + sel->security->ctx_doi = sec_ctx->sadb_x_ctx_doi; + sel->security->ctx_len = sec_ctx->sadb_x_ctx_len; + sel->security->ctx_alg = sec_ctx->sadb_x_ctx_alg; + + nethooks_debug(KERN_NOTICE "%s: doi %u len %u alg %u\n", + __FUNCTION__, + sel->security->ctx_doi, + sel->security->ctx_len, + sel->security->ctx_alg); + + memcpy(sel->security->ctx_str, + sec_ctx+1, + sel->security->ctx_len); + rc = security_context_to_sid(sel->security->ctx_str, + sel->security->ctx_len, + &sel->security->ctx_sid); + sel->security->ctx_str[sel->security->ctx_len] = 0; + + nethooks_debug(KERN_NOTICE "%s: context was %s with sid %d\n", + __FUNCTION__, + sel->security->ctx_str, + sel->security->ctx_sid); + + if (rc) + kfree(sel->security); + + return rc; +} + +/* + * LSM hook implementation that allocs and transfers sec_ctx spec to + * xfrm_policy. + */ +int selinux_xfrm_policy_alloc(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx) +{ + int rc = 0; + + if (!xp) + return -EINVAL; + + nethooks_debug(KERN_NOTICE "%s: start alloc\n", __FUNCTION__); + + rc = selinux_xfrm_selector_alloc(&xp->selector, sec_ctx); + + return rc; +} + + +/* + * LSM hook implementation that copies security data structure from old to + * new for policy cloning. + */ +int selinux_xfrm_policy_clone(struct xfrm_policy *old, struct xfrm_policy *new) +{ + struct xfrm_sec_ctx *old_ctx, *new_ctx; + + old_ctx = xfrm_policy_security(old); + + if (old_ctx) { + new_ctx = new->selector.security = + kmalloc(sizeof(*new_ctx) + + old_ctx->ctx_len + 1, + GFP_KERNEL); + + if (!new_ctx) + return -ENOMEM; + + memcpy(new_ctx, old_ctx, sizeof(*new_ctx)); + memcpy(new_ctx->ctx_str, old_ctx->ctx_str, new_ctx->ctx_len); + } + return 0; +} + +/* + * LSM hook implementation that frees xfrm_policy security information. + */ +void selinux_xfrm_policy_free(struct xfrm_policy *xp) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); + + if (xfrm_ctx) + kfree(xfrm_ctx); +} + +/* + * LSM hook implementation that allocs and transfers sec_ctx spec to + * xfrm_state. + */ +int selinux_xfrm_state_alloc(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx) +{ + int rc = 0; + + if (!x) + return -EINVAL; + + nethooks_debug(KERN_NOTICE "%s: start alloc\n", __FUNCTION__); + + rc = selinux_xfrm_selector_alloc(&x->sel, sec_ctx); + + return rc; +} + +/* + * LSM hook implementation that frees xfrm_state security information. + */ +void selinux_xfrm_state_free(struct xfrm_state *x) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_state_security(x); + + if (xfrm_ctx) + kfree(xfrm_ctx); +} + +/* + * LSM hook that controls access to unlabelled packets. If + * a xfrm_state is authorizable (defined by macro) then it was + * already authorized by selector matching process. If not, then + * we need to check for unlabelled access since this may not have + * gone thru the selector process. + */ +int selinux_xfrm_sock_rcv_skb(u32 isec_sid, struct sk_buff *skb) +{ + int i, rc = 0; + struct sec_path *sp; + struct sock *sk; + + nethooks_debug("%s: starting\n", __FUNCTION__); + + /* regular check for socket with isec */ + sp = skb->sp; + sk = skb->sk; + + if (sp) { + nethooks_debug("%s: sp (0x%x) on skb with length %d\n", + __FUNCTION__, + (unsigned) sp, sp->len); + + /* + * __xfrm_policy_check does not approve unless xfrm_policy_ok + * says that spi's match for policy and the socket. + * + * Only need to verify the existence of an authorizable sp. + */ + for (i = 0; i < sp->len; i++) { + struct xfrm_state *x = sp->x[i].xvec; + + nethooks_debug("%s: sa: 0x%x\n", + __FUNCTION__, + (unsigned) x); + + if (selinux_authorizable_xfrm(x)) { + nethooks_debug("%s: sa 0x%x found\n", + __FUNCTION__, + (unsigned) x); + goto accept; + } + } + } + + /* check SELinux sock for unlabelled access */ + nethooks_debug("%s: before unlabelled sa auth: isec_sid = 0x%x\n", + __FUNCTION__, + (unsigned) isec_sid); + rc = avc_has_perm(isec_sid, SECINITSID_UNLABELED, SECCLASS_ASSOCIATION, + ASSOCIATION__RECVFROM, NULL); + nethooks_debug("%s: after unlabelled sa auth rc: %d\n", + __FUNCTION__, + rc); + + if (rc) + goto drop; + +accept: + nethooks_debug("%s: accept\n", __FUNCTION__); + return 0; + +drop: + nethooks_debug("%s: drop\n", __FUNCTION__); + return rc; +} + +/* + * POSTROUTE_LAST hook's XFRM processing: + * If we have no security association, then we need to determine + * whether the socket is allowed to send to an unlabelled destination. + * If we do have a authorizable security association, then it has already been + * checked in xfrm_policy_lookup hook. + */ +int selinux_xfrm_postroute_last(u32 isec_sid, struct sk_buff *skb) +{ + struct dst_entry *dst; + int rc = 0; + + dst = skb->dst; + + if (dst) { + struct dst_entry *dst_test; + + for (dst_test = dst; dst_test != 0; + dst_test = dst_test->child) { + struct xfrm_state *x = dst_test->xfrm; + + if (selinux_authorizable_xfrm(x)) { + nethooks_debug("%s: sa 0x%x found\n", + __FUNCTION__, + (unsigned) x); + goto accept; + } + } + } + + nethooks_debug("%s: before unlabelled sa auth: isec_sid = 0x%x\n", + __FUNCTION__, + (unsigned) isec_sid); + rc = avc_has_perm(isec_sid, SECINITSID_UNLABELED, SECCLASS_ASSOCIATION, + ASSOCIATION__SENDTO, NULL); + nethooks_debug("%s: after unlabelled sa auth rc: %d\n", __FUNCTION__, rc); + + if (rc) + goto drop; + +accept: + nethooks_debug("%s: accept\n", __FUNCTION__); + return NF_ACCEPT; + +drop: + nethooks_debug("%s: drop\n", __FUNCTION__); + return NF_DROP; +} + +#else /* CONFIG_SECURITY_NETWORK_XFRM */ + +int selinux_xfrm_sock_rcv_skb(u32 isec_sid, struct sk_buff *skb) +{ + return 0; +} + +int selinux_xfrm_postroute_last(u32 isec_sid, struct sk_buff *skb) +{ + return 0; +} +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ _ From torvalds@osdl.org Mon May 16 20:14:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 20:14:26 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4H3EMOv024390 for ; Mon, 16 May 2005 20:14:22 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4H3DkU3011996 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 16 May 2005 20:13:47 -0700 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4H3Diu7010589; Mon, 16 May 2005 20:13:45 -0700 Date: Mon, 16 May 2005 20:15:49 -0700 (PDT) From: Linus Torvalds To: Jeff Garzik cc: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches] 2.6.x net driver fixes In-Reply-To: <42892F2B.8090908@pobox.com> Message-ID: References: <42892F2B.8090908@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev Content-Length: 5292 Lines: 142 On Mon, 16 May 2005, Jeff Garzik wrote: > > Here's a first experimental git push from me. The git URL is > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git > > but it should be noted that I would like you to pull the 'misc-fixes' > branch. I'm told that branches are supposed to live in .git/refs/heads, > so there you will find netdev-2.6.git/refs/heads/misc-fixes. > > Does that work? Yes. Merged and pushed out. > Changelog and patch for review attached. It's wonderful if you also do a "diffstat" on the thing, since my merge scripts will always show that to me, and I can verify at a glance that it matches what you thought you sent me. Also, if you are really nervous, the "git-diff-tree" thing is actually quite good at generating changelogs, so you can do something like this: git-rev-tree HEAD ^ORIG_HEAD | cut -d' ' -f2 | git-diff-tree -v -p --stdin | less -S which means: give me a list of all commits that are in HEAD but not in ORIG_HEAD (replace with whatever markers you have, in this case you'd use "misc-fixes" instead of HEAD and some marker - maybe the SHA1 - for my last base), then take just the SHA1 of that list of commits, and show a verbose diff of each of the commits with the patch. For example, the output of the above command (after I merged from you) is appended, so you can see exactly what I merged. Linus ---- diff-tree 99718699f5746cc365f3a9ab4769568a1da97635 (from f7a3aae1723e7ffc9c4fcdb489365da7a3d81255) Author: Geoff Levand Date: Thu Apr 14 11:20:32 2005 -0700 [PATCH] {PATCH] Fix IBM EMAC driver ioctl bug Fix IBM EMAC driver ioctl bug. I found IBM EMAC driver bug. So mii-tool command print wrong status. # mii-tool eth0: 10 Mbit, half duplex, no link eth1: 10 Mbit, half duplex, no link I can get correct status on fixed kernel. # mii-tool eth0: negotiated 100baseTx-FD, link okZZ eth1: negotiated 100baseTx-FD, link ok Hiroaki Fuse Signed-off-by: Geoff Levand for CELF --- a/drivers/net/ibm_emac/ibm_emac_core.c +++ b/drivers/net/ibm_emac/ibm_emac_core.c @@ -1595,7 +1595,7 @@ static struct ethtool_ops emac_ethtool_o static int emac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct ocp_enet_private *fep = dev->priv; - uint *data = (uint *) & rq->ifr_ifru; + uint16_t *data = (uint16_t *) & rq->ifr_ifru; switch (cmd) { case SIOCGMIIPHY: diff-tree c4cc26d3310a6614a20e32276228a5d44159fc9b (from 99718699f5746cc365f3a9ab4769568a1da97635) Author: Jiri Benc Date: Wed Apr 27 08:48:56 2005 +0200 [PATCH] Typo in tulip driver This patch fixes a typo in tulip driver in 2.6.12-rc3. --- a/drivers/net/tulip/tulip_core.c +++ b/drivers/net/tulip/tulip_core.c @@ -1104,7 +1104,7 @@ static void set_rx_mode(struct net_devic if (entry != 0) { /* Avoid a chip errata by prefixing a dummy entry. Don't do this on the ULI526X as it triggers a different problem */ - if (!(tp->chip_id == ULI526X && (tp->revision = 0x40 || tp->revision == 0x50))) { + if (!(tp->chip_id == ULI526X && (tp->revision == 0x40 || tp->revision == 0x50))) { tp->tx_buffers[entry].skb = NULL; tp->tx_buffers[entry].mapping = 0; tp->tx_ring[entry].length = diff-tree c8920ba041c8934b29370f5d62ab9ea8f147966b (from c4cc26d3310a6614a20e32276228a5d44159fc9b) Author: Daniel Andersen Date: Thu May 5 15:14:09 2005 -0700 [PATCH] wireless: 3CRWE154G72 Kconfig help fix Version 2 of the 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 is not supported by the prism54 project. To stop confusion, the kernel documentation should state so as 3com made a good job hiding the version. Signed-off-by: Andrew Morton diff -puN drivers/net/wireless/Kconfig~wireless-3crwe154g72-kconfig-help-fix drivers/net/wireless/Kconfig --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -323,7 +323,7 @@ config PRISM54 For a complete list of supported cards visit . Here is the latest confirmed list of supported cards: - 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 + 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 (version 1) Allnet ALL0271 PCI Card Compex WL54G Cardbus Card Corega CG-WLCB54GT Cardbus Card diff-tree f7a3aae1723e7ffc9c4fcdb489365da7a3d81255 (from 88d7bd8cb9eb8d64bf7997600b0d64f7834047c5) Author: Al Viro Date: Sun Apr 3 07:15:52 2005 +0100 [PATCH] drivers/net/wireless enabled by wrong option NET_WIRELESS is only a subset of the stuff in drivers/net/wireless; NET_RADIO is what covers all of them. Signed-off-by: Al Viro --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -187,7 +187,7 @@ obj-$(CONFIG_TR) += tokenring/ obj-$(CONFIG_WAN) += wan/ obj-$(CONFIG_ARCNET) += arcnet/ obj-$(CONFIG_NET_PCMCIA) += pcmcia/ -obj-$(CONFIG_NET_WIRELESS) += wireless/ +obj-$(CONFIG_NET_RADIO) += wireless/ obj-$(CONFIG_NET_TULIP) += tulip/ obj-$(CONFIG_HAMRADIO) += hamradio/ obj-$(CONFIG_IRDA) += irda/ From razb@bitband.com Mon May 16 23:42:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 23:42:43 -0700 (PDT) Received: from mail1.bitband.com (fw.bitband.com [213.8.50.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4H6gYOv006227 for ; Mon, 16 May 2005 23:42:37 -0700 Received: from [172.16.1.51] ([172.16.1.51]) by mail1.bitband.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 May 2005 09:42:05 +0200 Subject: tg3 crashes in scatter gather mode From: raz ben jehuda To: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1116311948.3021.7.camel@raz-laptop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 17 May 2005 09:39:08 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2005 07:42:05.0875 (UTC) FILETIME=[EC394830:01C55AB3] X-archive-position: 1208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: razb@bitband.com Precedence: bulk X-list: netdev Content-Length: 287 Lines: 10 hello. I have written a fast udp stack that implements a real scatter gather over user space pages. When i use it over an Intel e1000 card every thing works fine. doing the same thing over the tg3 crashes the system somewhere in tg3_poll area. Anyone ? -- Raz Long Live The Penguin From davem@davemloft.net Mon May 16 23:53:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 16 May 2005 23:54:01 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4H6rvOv007020 for ; Mon, 16 May 2005 23:53:57 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DXvxB-0000g2-Jz; Mon, 16 May 2005 23:53:21 -0700 Date: Mon, 16 May 2005 23:53:21 -0700 (PDT) Message-Id: <20050516.235321.41634951.davem@davemloft.net> To: razb@bitband.com Cc: netdev@oss.sgi.com Subject: Re: tg3 crashes in scatter gather mode From: "David S. Miller" In-Reply-To: <1116311948.3021.7.camel@raz-laptop> References: <1116311948.3021.7.camel@raz-laptop> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 421 Lines: 11 From: raz ben jehuda Date: Tue, 17 May 2005 09:39:08 +0300 > I have written a fast udp stack that implements a real scatter gather > over user space pages. When i use it over an Intel e1000 card every > thing works fine. doing the same thing over the tg3 crashes the system > somewhere in tg3_poll area. > Anyone ? How about posting your code so we can have some hope of analyzing your bug report? From cranium2003@yahoo.com Tue May 17 02:56:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 02:56:09 -0700 (PDT) Received: from web41426.mail.yahoo.com (web41426.mail.yahoo.com [66.218.94.124]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4H9u5Ov030558 for ; Tue, 17 May 2005 02:56:05 -0700 Received: (qmail 1328 invoked by uid 60001); 17 May 2005 09:55:31 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=nB0IGzIaJ4ZiiKCsD4RiZvFp8rjIvQTT6SQdcH1sYBNAmpMiNNGoSCdL5x/sgcOsp3ZM1K1iCY5iuRIyxrqpiiGumse6PslJMdJOC1bJdzmk1v2DAJ5iWQwteeZrM0fmBFumuHZhQyxb85J1kMdouuRbOyvTZRDGQG6ki3W5O3k= ; Message-ID: <20050517095531.1326.qmail@web41426.mail.yahoo.com> Received: from [203.199.141.99] by web41426.mail.yahoo.com via HTTP; Tue, 17 May 2005 02:55:31 PDT Date: Tue, 17 May 2005 02:55:31 -0700 (PDT) From: cranium2003 Subject: net_device structure help To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 518 Lines: 19 hello, Is there any way in linux kernel network stack at IP layer before adding IP header to know that packet is transmitted to eth1 or forwarded to eth1 if linux machine has 2 NIC's eth0 and eth1? I check net_device structre and found that ifindex is the field that gives proper incoming packet network interface at IP layer but same for packet trasmission not works. regards, cranium Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From manfred99@gmx.ch Tue May 17 09:06:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 09:06:40 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4HG6MF3028149 for ; Tue, 17 May 2005 09:06:23 -0700 Received: (qmail 17844 invoked by uid 0); 17 May 2005 16:05:47 -0000 Received: from 212.55.205.40 by www33.gmx.net with HTTP; Tue, 17 May 2005 18:05:47 +0200 (MEST) Date: Tue, 17 May 2005 18:05:47 +0200 (MEST) From: "Manfred Schwarb" To: Herbert Xu Cc: marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org, davem@redhat.com, netdev@oss.sgi.com MIME-Version: 1.0 References: <20050514110516.GA1238@gondor.apana.org.au> Subject: Re: 2.4.30-hf1 do_IRQ stack overflows X-Priority: 3 (Normal) X-Authenticated: #17170890 Message-ID: <23492.1116345947@www33.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 1212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred99@gmx.ch Precedence: bulk X-list: netdev Content-Length: 931 Lines: 29 > > > > Trace; f8b531fc <[reiserfs]reiserfs_insert_item+14c/150> > > Trace; c02387be <__kfree_skb+fe/160> > > Trace; c02387be <__kfree_skb+fe/160> > > Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180> > > Do you have any funky netfilter/iptables modules loaded? I use a iptables based firewall, but no additional netfilter modules are loaded. The network configuration is as it is shipped by SuSE (i.e. no CONFIG_IP_NF_* modules, but most of the "Networking options" are set to y). And as I told in an earlier mail, I had scheduling built in the kernel (CONFIG_NET_SCHED=y, CONFIG_NET_QOS=y, CONFIG_NET_ESTIMATOR=y, CONFIG_NET_CLS=y, CONFIG_NET_CLS_ROUTE=y). I have disabled NET_SCHED now (as Marcelo suggested), and I got no overflows since then (4 days uptime). Seems to work so far. Thanks and regards, Manfred -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl From akepner@sgi.com Tue May 17 09:22:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 09:22:08 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HGM4F3029316 for ; Tue, 17 May 2005 09:22:04 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4HI5xPY008430 for ; Tue, 17 May 2005 11:05:59 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4HGLTbT71587711 for ; Tue, 17 May 2005 09:21:29 -0700 (PDT) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4HGKS5x26835163 for ; Tue, 17 May 2005 09:20:28 -0700 (PDT) Date: Tue, 17 May 2005 09:18:26 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: netdev@oss.sgi.com Subject: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 10001 Lines: 348 The Problem ----------- There's a well-known problem with IPv4 fragmentation/ reassembly - the 16-bit IP ID can uniquely identify only 65535 datagrams, and a gigabit/sec source can emit that many datagrams in seconds. Since fragments can sit on a reassembly queue for a "long time" (30 seconds is the default in Linux), there's a possibility of reassembling fragments from different datagrams. The Bigger Problem ------------------ This is mainly a problem for UDP, where IP fragmentation at the source is not uncommon. The UDP checksum is only 16 bits, so there's a not-insignificant possibility that it won't detect when a datagram has been incorrectly reassembled. The result can be silent data corruption, and much unhappiness. What next? ---------- This is a fundamental problem with IP(v4), which was designed before people dreamed of gigabit/sec network links. There's no simple, completely effective fix that preserves compatability. There has been at least a little discussion here before: http://marc.theaimsgroup.com/?l=linux-netdev&m=108987122412812&w=2 A simple, obvious, partial remedy is to tune "sysctl_ipfrag_time" down. Another simple change which preserves compatability in practice, is "strict ipv4 reassembly". Being "strict" about reassembly means that you don't allow gaps or overlaps in the reassembly queue. Fragments which would introduce gaps or overlaps are dropped. Disallowing gaps and overlaps also implies that: 1) Fragments must arrive in order (or in reverse order) - out of order fragments are dropped. 2) If the first (or last) fragment of a datagram arrives and there's already a reassembly queue for that (proto, ipid, src, dst), then the existing reassembly queue is dropped, and a new one started. Strict reassembly has been very effective in practice at preventing incorrect IP reassembly. (We have tests which attempt to produce and then detect corruption produced by bad IP reassembly.) Following is a patch which implements strict reassembly. Strict reassembly is off by default (so the default behavior is not changed.) Strict reassembly is enabled by doing "echo 1 > /proc/sys/net/ipv4/strict_reassembly". Patch is against 2.6.12-rc4. include/linux/sysctl.h | 1 net/ipv4/ip_fragment.c | 189 ++++++++++++++++++++++++++++++++++++++++++++- net/ipv4/sysctl_net_ipv4.c | 9 ++ 3 files changed, 198 insertions(+), 1 deletion(-) Signed-off-by: Arthur Kepner diff -pur linux.old/include/linux/sysctl.h linux.new/include/linux/sysctl.h --- linux.old/include/linux/sysctl.h 2005-05-16 16:29:55.236056917 -0700 +++ linux.new/include/linux/sysctl.h 2005-05-17 00:57:16.889588271 -0700 @@ -347,6 +347,7 @@ enum NET_TCP_MODERATE_RCVBUF=106, NET_TCP_TSO_WIN_DIVISOR=107, NET_TCP_BIC_BETA=108, + NET_IPV4_STRICT_REASM=109, }; enum { diff -pur linux.old/net/ipv4/ip_fragment.c linux.new/net/ipv4/ip_fragment.c --- linux.old/net/ipv4/ip_fragment.c 2005-05-16 16:30:18.610281655 -0700 +++ linux.new/net/ipv4/ip_fragment.c 2005-05-17 00:53:53.243293277 -0700 @@ -56,6 +56,9 @@ int sysctl_ipfrag_high_thresh = 256*1024; int sysctl_ipfrag_low_thresh = 192*1024; +/* strict reassembly is off by default */ +int sysctl_strict_reassembly = 0; + /* Important NOTE! Fragment queue must be destroyed before MSL expires. * RFC791 is wrong proposing to prolongate timer each fragment arrival by TTL. */ @@ -353,6 +356,24 @@ static struct ipq *ip_frag_create(unsign { struct ipq *qp; + if (sysctl_strict_reassembly) { + /* make a new reassembly queue iff this is the first or + * last fragment */ + int frag_off = ntohs(iph->frag_off); + int offset = (frag_off & IP_OFFSET); + + if ((offset == 0) && !(frag_off & IP_MF)) { + /* first fragment and there aren't anymore coming - + * nonsense, drop the fragment */ + return NULL; + } + if ((offset != 0) && (frag_off & IP_MF)) { + /* if this isn't either the first or last fragment, + * don't make a new reassembly queue */ + return NULL; + } + } + if ((qp = frag_alloc_queue()) == NULL) goto out_nomem; @@ -381,6 +402,35 @@ out_nomem: return NULL; } +/* a reassembly queue match has been found and we're being + * "strict" about reassembly. If this fragment is first (last) + * in a reassembly queue which already has a first (last) + * fragment, then drop the existing reassembly queue. Return + * 1 if the existing queue was dropped, 0 otherwise. + * + * This function is called with (and returns with) a read_lock + * on ipfrag_lock + */ +static int __ip_find_strict_check(const struct iphdr *iph, struct ipq *qp) +{ + int frag_off = ntohs(iph->frag_off); + int offset = (frag_off & IP_OFFSET); + + if (((offset == 0) && (qp->last_in & FIRST_IN)) || + (!(frag_off & IP_MF) && (qp->last_in & LAST_IN))) { + atomic_inc(&qp->refcnt); + read_unlock(&ipfrag_lock); + spin_lock(&qp->lock); + if (!(qp->last_in&COMPLETE)) + ipq_kill(qp); + spin_unlock(&qp->lock); + ipq_put(qp, NULL); + read_lock(&ipfrag_lock); + return 1; + } + return 0; +} + /* Find the correct entry in the "incomplete datagrams" queue for * this IP datagram, and create new one, if nothing is found. */ @@ -400,6 +450,10 @@ static inline struct ipq *ip_find(struct qp->daddr == daddr && qp->protocol == protocol && qp->user == user) { + if (sysctl_strict_reassembly && + __ip_find_strict_check(iph, qp)) { + break; + } atomic_inc(&qp->refcnt); read_unlock(&ipfrag_lock); return qp; @@ -549,6 +603,136 @@ err: kfree_skb(skb); } +/* Add new segment to existing queue using "strict" semantics. + * The segment is rejected if it introduces gaps in the reassembly + * queue or overlaps with any existing fragments in the reassembly + * queue. + */ +static void ip_frag_queue_strict(struct ipq *qp, struct sk_buff *skb) +{ + struct sk_buff *prev, *next; + int flags, offset; + int ihl, end; + + if (qp->last_in & COMPLETE) + goto err; + + offset = ntohs(skb->nh.iph->frag_off); + flags = offset & ~IP_OFFSET; + offset &= IP_OFFSET; + offset <<= 3; /* offset is in 8-byte chunks */ + ihl = skb->nh.iph->ihl * 4; + + /* Determine the position of this fragment. */ + end = offset + skb->len - ihl; + + if ((!(flags & IP_MF) && (qp->last_in & LAST_IN)) || + ((offset == 0) && (qp->last_in & FIRST_IN))) { + /* This can happen only if sysctl_strict_reassembly + * was toggled on after we did ip_find() for this + * fragment. + */ + goto err; + } + + /* Is this the final fragment? */ + if ((flags & IP_MF) == 0) { + /* If we already have some bits beyond end + * drop this fragment. + */ + if (end < qp->len) + goto err; + qp->len = end; + } else { + if (end&7) { + end &= ~7; + if (skb->ip_summed != CHECKSUM_UNNECESSARY) + skb->ip_summed = CHECKSUM_NONE; + } + if (end > qp->len) { + /* Some bits beyond end -> corruption. */ + if (qp->last_in & LAST_IN) + goto err; + qp->len = end; + } + } + if (end == offset) + goto err; + + if (pskb_pull(skb, ihl) == NULL) + goto err; + if (pskb_trim(skb, end-offset)) + goto err; + + /* Find out which fragments are in front and at the back of us + * in the chain of fragments so far. We must know where to put + * this fragment, right? + */ + prev = NULL; + for(next = qp->fragments; next != NULL; next = next->next) { + if (FRAG_CB(next)->offset >= offset) + break; /* bingo! */ + prev = next; + } + + WARN_ON(prev && next); + + /* We found where to put this one. Make sure there are no overlaps */ + + if (prev) { + int i = (FRAG_CB(prev)->offset + prev->len) - offset; + + /* if i > 0, this fragment overlaps with the previous + * fragment. if i < 0, this fragment would introduce a + * "hole" in the reassembly chain. Drop it in either + * case. + */ + + if (i != 0) goto err; + + } + + if (next) { + int i = end - FRAG_CB(next)->offset; + + /* if i > 0, this fragment overlaps with the next. + * if i < 0, this fragment would introduce a + * "hole" in the reassembly chain. Drop it in either + * case. + */ + + if (i != 0) goto err; + } + + FRAG_CB(skb)->offset = offset; + + /* Insert this fragment in the chain of fragments. */ + skb->next = next; + if (prev) + prev->next = skb; + else + qp->fragments = skb; + + if (skb->dev) + qp->iif = skb->dev->ifindex; + skb->dev = NULL; + qp->stamp = skb->stamp; + qp->meat += skb->len; + atomic_add(skb->truesize, &ip_frag_mem); + if (offset == 0) + qp->last_in |= FIRST_IN; + if ((flags & IP_MF) == 0) + qp->last_in |= LAST_IN; + + write_lock(&ipfrag_lock); + list_move_tail(&qp->lru_list, &ipq_lru_list); + write_unlock(&ipfrag_lock); + + return; + +err: + kfree_skb(skb); +} /* Build a new IP datagram from all its fragments. */ @@ -661,7 +845,10 @@ struct sk_buff *ip_defrag(struct sk_buff spin_lock(&qp->lock); - ip_frag_queue(qp, skb); + if (sysctl_strict_reassembly) + ip_frag_queue_strict(qp, skb); + else + ip_frag_queue(qp, skb); if (qp->last_in == (FIRST_IN|LAST_IN) && qp->meat == qp->len) diff -pur linux.old/net/ipv4/sysctl_net_ipv4.c linux.new/net/ipv4/sysctl_net_ipv4.c --- linux.old/net/ipv4/sysctl_net_ipv4.c 2005-05-16 16:30:31.773480692 -0700 +++ linux.new/net/ipv4/sysctl_net_ipv4.c 2005-05-16 17:18:07.125138363 -0700 @@ -29,6 +29,7 @@ extern int sysctl_ipfrag_low_thresh; extern int sysctl_ipfrag_high_thresh; extern int sysctl_ipfrag_time; extern int sysctl_ipfrag_secret_interval; +extern int sysctl_strict_reassembly; /* From ip_output.c */ extern int sysctl_ip_dynaddr; @@ -258,6 +259,14 @@ ctl_table ipv4_table[] = { .strategy = &sysctl_jiffies }, { + .ctl_name = NET_IPV4_STRICT_REASM, + .procname = "strict_reassembly", + .data = &sysctl_strict_reassembly, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec + }, + { .ctl_name = NET_IPV4_TCP_KEEPALIVE_TIME, .procname = "tcp_keepalive_time", .data = &sysctl_tcp_keepalive_time, -- Arthur From jdmason@us.ibm.com Tue May 17 09:35:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 09:35:11 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HGZ1F3030640 for ; Tue, 17 May 2005 09:35:08 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4HGYOdk012870 for ; Tue, 17 May 2005 12:34:24 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4HGYONJ115172 for ; Tue, 17 May 2005 12:34:24 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4HGYNki011801 for ; Tue, 17 May 2005 12:34:24 -0400 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4HGYM0F011632; Tue, 17 May 2005 12:34:22 -0400 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.10) with ESMTP id j4HGYLbR047320; Tue, 17 May 2005 11:34:21 -0500 Received: from dreadnought (dreadnought.austin.ibm.com [9.53.90.32]) by popmail.austin.ibm.com (AIX5.1/8.11.6p2/8.9.3) with SMTP id j4HGYJU91708; Tue, 17 May 2005 11:34:20 -0500 Received: by dreadnought (sSMTP sendmail emulation); Tue, 17 May 2005 11:34:20 -0500 Date: Tue, 17 May 2005 11:34:20 -0500 From: Jon Mason To: "David S. Miller" Cc: jdmason@us.ibm.com, netdev@oss.sgi.com, niv@us.ibm.com, habanero@us.ibm.com Subject: Re: Interdomain/interpartition communication without a checksum Message-ID: <20050517163420.GA19251@us.ibm.com> References: <20050511183554.GA28298@us.ibm.com> <20050516.130737.77060495.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050516.130737.77060495.davem@davemloft.net> User-Agent: Mutt/1.5.8i X-archive-position: 1214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 5799 Lines: 173 On Mon, May 16, 2005 at 01:07:37PM -0700, David S. Miller wrote: > From: Jon Mason > Date: Wed, 11 May 2005 13:35:54 -0500 > > > I have been working on a Xen project to remove unnecessary TCP/UDP > > checksums for local (interdomain) communication, while still having the > > checksum for all external network communication. > > I have no objections to this idea. But let's think about > the implementation. Fantastic! What I am attempting to do is identify the packets that have no checksum, and checksum them (either by hardware or software). There is already an existing infrastructure for checksumming the packets by using HW_CSUM. I've been mostly looking into the bridging case, but I would like an implimentation which works for every packet forwarding case. Here are the problems I see (there might be more): 1. skb->h.raw is set to skb->data in netif_receive_skb() (which prevents the forwarding/backend driver from setting it to the proper value, so it must be set on the output). 2. skb->ip_summed is set to CHECKSUM_NONE in both routing and bridging, thereby preventing the forwarding driver from setting CHECKSUM_HW. I would prefer to set the proper values for skb->h.raw and skb->ip_summed in the forwarding/backend driver. > > + /* If packet is forwarded to a device that needs a checksum and not > > + * checksummed, correct the pointers and enable checksumming in the > > + * next function. > > + */ > > + if (!(dev->features & NETIF_F_FWD_NO_CSUM) && skb->csum) { > > + skb->ip_summed = CHECKSUM_HW; > > + skb->h.raw = (void *)skb->nh.iph + (skb->nh.iph->ihl * 4); > > + } > > + > > This means that every packet which the networking tries to checksum > offload will pass this test, superfluously doing these assignments. Even worse, every packet which comes from the local system and has a checksum already will pass this test. I hit this problem last week, and had to redo the implimentation. Silly mistake on my part, and very obvious once I went looking for the cause of my problem. > It also assumes ipv4. ipv6 is possible, and for NETIF_F_CHECKSUM_HW > any protocol could be creating the packets as this flag indicates > that the card implements a totally generic 16-bit two's complement > checksum. Yes, anything which encapsulates TCP/UDP packets is valid. Good catch. I'll have to look at way to fix that. After fixing the former problem, I came up with the code below (with no fix for the latter problem yet). It was created against the 2.6.11.8 kernel. Let me know what you think. Thanks, Jon --- ../xen-unstable-pristine/linux-2.6.11-xen0/include/linux/skbuff.h 2005-03-02 01:38:38.000000000 -0600 +++ linux-2.6.11-xen0/include/linux/skbuff.h 2005-05-13 10:43:08.000000000 -0500 @@ -37,6 +37,10 @@ #define CHECKSUM_HW 1 #define CHECKSUM_UNNECESSARY 2 +#define SKB_CLONED 1 +#define SKB_NOHDR 2 +#define SKB_FDW_NO_CSUM 4 + #define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \ ~(SMP_CACHE_BYTES - 1)) #define SKB_MAX_ORDER(X, ORDER) (((PAGE_SIZE << (ORDER)) - (X) - \ @@ -238,7 +242,7 @@ struct sk_buff { mac_len, csum; unsigned char local_df, - cloned, + flags, pkt_type, ip_summed; __u32 priority; @@ -370,7 +374,7 @@ static inline void kfree_skb(struct sk_b */ static inline int skb_cloned(const struct sk_buff *skb) { - return skb->cloned && atomic_read(&skb_shinfo(skb)->dataref) != 1; + return (skb->flags & SKB_CLONED) && atomic_read(&skb_shinfo(skb)->dataref) != 1; } /** --- ../xen-unstable-pristine/linux-2.6.11-xen0/net/core/skbuff.c 2005-03-02 01:38:17.000000000 -0600 +++ linux-2.6.11-xen0/net/core/skbuff.c 2005-05-13 11:47:51.000000000 -0500 @@ -240,7 +240,7 @@ static void skb_clone_fraglist(struct sk void skb_release_data(struct sk_buff *skb) { - if (!skb->cloned || + if (!(skb->flags & SKB_CLONED) || atomic_dec_and_test(&(skb_shinfo(skb)->dataref))) { if (skb_shinfo(skb)->nr_frags) { int i; @@ -352,7 +352,7 @@ struct sk_buff *skb_clone(struct sk_buff C(data_len); C(csum); C(local_df); - n->cloned = 1; + n->flags = skb->flags | SKB_CLONED; C(pkt_type); C(ip_summed); C(priority); @@ -395,7 +395,7 @@ struct sk_buff *skb_clone(struct sk_buff C(end); atomic_inc(&(skb_shinfo(skb)->dataref)); - skb->cloned = 1; + skb->flags |= SKB_CLONED; return n; } @@ -603,7 +603,7 @@ int pskb_expand_head(struct sk_buff *skb skb->mac.raw += off; skb->h.raw += off; skb->nh.raw += off; - skb->cloned = 0; + skb->flags &= SKB_CLONED; atomic_set(&skb_shinfo(skb)->dataref, 1); return 0; --- ../xen-unstable-pristine/linux-2.6.11-xen0/net/core/dev.c 2005-03-02 01:38:09.000000000 -0600 +++ linux-2.6.11-xen0/net/core/dev.c 2005-05-13 11:47:01.000000000 -0500 @@ -98,6 +98,7 @@ #include #include #include +#include #include #include #include @@ -1182,7 +1183,7 @@ int __skb_linearize(struct sk_buff *skb, skb->data += offset; /* We are no longer a clone, even if we were. */ - skb->cloned = 0; + skb->flags &= ~SKB_CLONED; skb->tail += skb->data_len; skb->data_len = 0; @@ -1236,6 +1237,15 @@ int dev_queue_xmit(struct sk_buff *skb) __skb_linearize(skb, GFP_ATOMIC)) goto out_kfree_skb; + /* If packet is forwarded to a device that needs a checksum and not + * checksummed, correct the pointers and enable checksumming in the + * next function. + */ + if (skb->flags & SKB_FDW_NO_CSUM) { + skb->ip_summed = CHECKSUM_HW; + skb->h.raw = (void *)skb->nh.iph + (skb->nh.iph->ihl * 4); + } + /* If packet is not checksummed and device does not support * checksumming for this protocol, complete checksumming here. */ From davem@davemloft.net Tue May 17 10:50:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 10:50:37 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HHoRF3004324 for ; Tue, 17 May 2005 10:50:28 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DY6CR-0001JJ-6U; Tue, 17 May 2005 10:49:47 -0700 Date: Tue, 17 May 2005 10:49:47 -0700 (PDT) Message-Id: <20050517.104947.112621738.davem@davemloft.net> To: akepner@sgi.com Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 747 Lines: 21 From: Arthur Kepner Date: Tue, 17 May 2005 09:18:26 -0700 (PDT) > 1) Fragments must arrive in order (or in reverse order) - > out of order fragments are dropped. Even the most simplistic flow over the real internet can get slight packet reordering. Heck, reordering happens on SMP on any network. IP is supposed to be resilient to side effects of network topology, and one such common side effect is packet reordering. It's common, it's fine, and the networking stack deals with it gracefully. Strict reassembly does not. Sure it's off by default, but isn't it a better idea to use NFS over TCP instead? Decreasing ipfrag_time is also not an option, because then you break fragmentation for packet radio folks :-) From akepner@sgi.com Tue May 17 11:30:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 11:30:49 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HIUlF3007274 for ; Tue, 17 May 2005 11:30:47 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4HKEgGk020423 for ; Tue, 17 May 2005 13:14:42 -0700 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4HIU75x26869153; Tue, 17 May 2005 11:30:08 -0700 (PDT) Date: Tue, 17 May 2005 11:28:05 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: "David S.Miller" cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly In-Reply-To: <20050517.104947.112621738.davem@davemloft.net> Message-ID: References: <20050517.104947.112621738.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 952 Lines: 31 On Tue, 17 May 2005, David S.Miller wrote: > .... > IP is supposed to be resilient to side effects of network > topology, and one such common side effect is packet reordering. > It's common, it's fine, and the networking stack deals with it > gracefully. Strict reassembly does not. > IP was designed a looong time ago. I think it's reasonable to make (or at least allow for) some accomodation when networking bandwidths have gone up by several orders of magnitude. (And while we wait for IPv6 to catch on ;-) > > Sure it's off by default, but isn't it a better idea > to use NFS over TCP instead? > This isn't limited to NFS, of course, though that's the application of most concern. I know that we have customers who, for good or bad reasons, _do_ use NFS over UDP. > Decreasing ipfrag_time is also not an option, because then > you break fragmentation for packet radio folks :-) Different sysctls for different folks.... -- Arthur From ak@muc.de Tue May 17 11:39:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 11:39:19 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HId4F3008198 for ; Tue, 17 May 2005 11:39:05 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 92906D033F; Tue, 17 May 2005 20:38:25 +0200 (CEST) To: "David S. Miller" Cc: netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> From: Andi Kleen Date: Tue, 17 May 2005 20:38:25 +0200 In-Reply-To: <20050517.104947.112621738.davem@davemloft.net> (David S. Miller's message of "Tue, 17 May 2005 10:49:47 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 944 Lines: 29 "David S. Miller" writes: > From: Arthur Kepner > Date: Tue, 17 May 2005 09:18:26 -0700 (PDT) > >> 1) Fragments must arrive in order (or in reverse order) - >> out of order fragments are dropped. > > Even the most simplistic flow over the real internet > can get slight packet reordering. > > Heck, reordering happens on SMP on any network. > > IP is supposed to be resilient to side effects of network > topology, and one such common side effect is packet reordering. > It's common, it's fine, and the networking stack deals with it > gracefully. Strict reassembly does not. If anything it would be better as a per route flag. Then you could set it only for your local network where you know Gigabit happens and reordering might be avoidable in some cases. -Andi P.S.: Arthur I think your arguments would have more force if you published the test program that demonstrates the corruption. From pekkas@netcore.fi Tue May 17 11:45:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 11:46:02 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HIjuF3009166 for ; Tue, 17 May 2005 11:45:56 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4HIj0523612; Tue, 17 May 2005 21:45:00 +0300 Date: Tue, 17 May 2005 21:45:00 +0300 (EEST) From: Pekka Savola To: Andi Kleen cc: "David S. Miller" , netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly In-Reply-To: Message-ID: References: <20050517.104947.112621738.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 528 Lines: 13 On Tue, 17 May 2005, Andi Kleen wrote: > P.S.: Arthur I think your arguments would have more > force if you published the test program that demonstrates the > corruption. If more explicit analytical or theoretical background would be convincing, look no further than http://www.watersprings.org/pub/id/draft-mathis-frag-harmful-00.txt -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From davem@davemloft.net Tue May 17 11:49:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 11:49:20 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HIn8F3009757 for ; Tue, 17 May 2005 11:49:08 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DY77F-0002eH-8R; Tue, 17 May 2005 11:48:29 -0700 Date: Tue, 17 May 2005 11:48:29 -0700 (PDT) Message-Id: <20050517.114829.115910656.davem@davemloft.net> To: akepner@sgi.com Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: References: <20050517.104947.112621738.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 789 Lines: 22 From: Arthur Kepner Date: Tue, 17 May 2005 11:28:05 -0700 (PDT) > On Tue, 17 May 2005, David S.Miller wrote: > > > Decreasing ipfrag_time is also not an option, because then > > you break fragmentation for packet radio folks :-) > > Different sysctls for different folks.... Can I tell users to call you when they enable the strict fragmentation and they can no longer talk UDP to remote sites outside of their subnet, or it breaks on their heavily SMP machine due to natural system local packet reordering? Packet reordering happens on the local machine with SMP. There is no way to avoid this. And when it triggers your patch will drop frags on the ground all the time. If you want to fix things, do it without knowingly breaking stuff that does currently work. From davem@davemloft.net Tue May 17 11:51:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 11:51:16 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HIp1F3010350 for ; Tue, 17 May 2005 11:51:01 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DY792-0002ea-Tl; Tue, 17 May 2005 11:50:20 -0700 Date: Tue, 17 May 2005 11:50:20 -0700 (PDT) Message-Id: <20050517.115020.119241057.davem@davemloft.net> To: ak@muc.de Cc: netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: References: <20050517.104947.112621738.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 711 Lines: 19 From: Andi Kleen Date: Tue, 17 May 2005 20:38:25 +0200 > If anything it would be better as a per route flag. > Then you could set it only for your local network > where you know Gigabit happens and reordering might > be avoidable in some cases. This is still bogus, on SMP we get packet reordering all the time. > P.S.: Arthur I think your arguments would have more > force if you published the test program that demonstrates the > corruption. I already know it happens, and that IBM has gotten NFS corruption due to this problem. Using NFS over UDP is stupid. I find it ironic to claim that folks are "stuck with UDP over NFS" but were able to upgrade their networking technology to gigabit. From jheffner@psc.edu Tue May 17 11:58:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 11:58:25 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HIwKF3011373 for ; Tue, 17 May 2005 11:58:20 -0700 Received: from homer.psc.edu (homer.psc.edu [128.182.61.117]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j4HIvKAI023503 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 17 May 2005 14:57:21 -0400 (EDT) From: John Heffner Organization: PSC To: Andi Kleen Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Date: Tue, 17 May 2005 14:57:38 -0400 User-Agent: KMail/1.8 Cc: "David S. Miller" , netdev@oss.sgi.com, akepner@sgi.com References: <20050517.104947.112621738.davem@davemloft.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505171457.38719.jheffner@psc.edu> X-archive-position: 1222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1061 Lines: 27 On Tuesday 17 May 2005 02:38 pm, Andi Kleen wrote: > "David S. Miller" writes: > > From: Arthur Kepner > > Date: Tue, 17 May 2005 09:18:26 -0700 (PDT) > > > >> 1) Fragments must arrive in order (or in reverse order) - > >> out of order fragments are dropped. > > > > Even the most simplistic flow over the real internet > > can get slight packet reordering. > > > > Heck, reordering happens on SMP on any network. > > > > IP is supposed to be resilient to side effects of network > > topology, and one such common side effect is packet reordering. > > It's common, it's fine, and the networking stack deals with it > > gracefully. Strict reassembly does not. > > If anything it would be better as a per route flag. > Then you could set it only for your local network > where you know Gigabit happens and reordering might > be avoidable in some cases. It would be better still to have a per-route packet reassembly timeout in milliseconds. Expecting perfect ordering seems very fragile even for a LAN. -John From rick.jones2@hp.com Tue May 17 11:57:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 11:57:38 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HIvUF3011206 for ; Tue, 17 May 2005 11:57:31 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id DE0343932 for ; Tue, 17 May 2005 11:56:55 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id LAA27818 for ; Tue, 17 May 2005 11:56:55 -0700 (PDT) Message-ID: <428A3E77.6070405@hp.com> Date: Tue, 17 May 2005 11:56:55 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> <20050517.115020.119241057.davem@davemloft.net> In-Reply-To: <20050517.115020.119241057.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 391 Lines: 13 > I already know it happens, and that IBM has gotten NFS corruption due > to this problem. Frankengrams can be fun :) > Using NFS over UDP is stupid. > > I find it ironic to claim that folks are "stuck with UDP over NFS" but > were able to upgrade their networking technology to gigabit. It would seem new NIC drivers ship more easily than new NFS/OS bits in some places. rick jones From niv@us.ibm.com Tue May 17 12:01:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:01:54 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJ1kF3012425 for ; Tue, 17 May 2005 12:01:47 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4HJ1B0c676362 for ; Tue, 17 May 2005 15:01:11 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4HJ1BLN221838 for ; Tue, 17 May 2005 13:01:11 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4HJ1AwP017685 for ; Tue, 17 May 2005 13:01:10 -0600 Received: from [9.65.19.39] (sig-9-65-19-39.mts.ibm.com [9.65.19.39]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4HJ19Ib017224; Tue, 17 May 2005 13:01:09 -0600 Message-ID: <428A3F86.1020000@us.ibm.com> Date: Tue, 17 May 2005 12:01:26 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1995 Lines: 63 Andi Kleen wrote: > "David S. Miller" writes: > > >>From: Arthur Kepner >>Date: Tue, 17 May 2005 09:18:26 -0700 (PDT) >> >> >>> 1) Fragments must arrive in order (or in reverse order) - >>> out of order fragments are dropped. >> >>Even the most simplistic flow over the real internet >>can get slight packet reordering. >> >>Heck, reordering happens on SMP on any network. >> >>IP is supposed to be resilient to side effects of network >>topology, and one such common side effect is packet reordering. >>It's common, it's fine, and the networking stack deals with it >>gracefully. Strict reassembly does not. > > > If anything it would be better as a per route flag. > Then you could set it only for your local network > where you know Gigabit happens and reordering might > be avoidable in some cases. > > -Andi > > P.S.: Arthur I think your arguments would have more > force if you published the test program that demonstrates the > corruption. When we first ran into this, the dropping of out-of-order fragments and overlapped fragments was considered by us, but we finally did not employ it precisely because of the ordering requirement. This is a fast LAN problem - real internet latencies don't allow for the wrapping of the id field that fast. Reordering does happen frequently on an SMP (this was a non-NAPI environment, NAPI reduces it quite a bit) so even local gigabit low latency LANs tend to suffer from it. You really need to be running on a UP to be entirely safe. The problem is exacerbated by NFS mount sizes of at least 4K or 8K - thus running NFS over UDP is just an environment you have to avoid in any case. That doesn't take care of the other apps, of course. So you cannot deploy a solution like this over all interfaces and all routes - perhaps, as Andi says, a per-route flag (turned on by the sysadmin when running on a UP or NAPI case) might help. But you'd have to do this very carefully. thanks, Nivedita From davem@davemloft.net Tue May 17 12:10:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:10:45 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJAUF3013418 for ; Tue, 17 May 2005 12:10:30 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DY7Rv-00015w-5K; Tue, 17 May 2005 12:09:51 -0700 Date: Tue, 17 May 2005 12:09:50 -0700 (PDT) Message-Id: <20050517.120950.74749758.davem@davemloft.net> To: jheffner@psc.edu Cc: ak@muc.de, netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: <200505171457.38719.jheffner@psc.edu> References: <20050517.104947.112621738.davem@davemloft.net> <200505171457.38719.jheffner@psc.edu> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 514 Lines: 14 From: John Heffner Date: Tue, 17 May 2005 14:57:38 -0400 > It would be better still to have a per-route packet reassembly timeout in > milliseconds. I agree. And if we can setup the infrastructure such that the drivers can indicate the speed of the link they are communicating on, then we can set sane default values on the automatically created subnet routes. These would need to be refreshed when link state changes, but we have the mechanics for that kind of device event stuff already. From rick.jones2@hp.com Tue May 17 12:14:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:14:17 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJEBF3014265 for ; Tue, 17 May 2005 12:14:11 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 298DB404B63 for ; Tue, 17 May 2005 12:13:36 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id MAA27986 for ; Tue, 17 May 2005 12:13:35 -0700 (PDT) Message-ID: <428A425F.7000807@hp.com> Date: Tue, 17 May 2005 12:13:35 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> <428A3F86.1020000@us.ibm.com> In-Reply-To: <428A3F86.1020000@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1311 Lines: 26 > This is a fast LAN problem - real internet latencies > don't allow for the wrapping of the id field that fast. What is a "fast" LAN these days? We were seeing IP ID wrap with NFS traffic back in the time of HP-UX 8.07 (early 1990's) over 10 Mbit/s Ethernet. Since I'm waxing historic, part of the problem at that time was giving the IP fragments to the driver one at a time rather than all at once. When the system was as fast or faster than the network, and the driver queue filled, the first couple fragments of a datagram would get into the queue, and the rest would be dropped, setting the stage for those wonderful Frankengrams. Part of the fix was to require a driver to take an entire IP datagram's worth of fragments or none of them. And there was at least one CKO NIC from that era (the HP-PB FDDI NIC) where the first IP datagram fragment was sent last :) If the WAN connected system is (still?) using a global IP ID rather than per-route, it could quite easily be wrapping. And we have WAN links with bandwidths of 10's of Megabits, so it also comes-down to how much other traffic is going and the quantity of request parallelism in NFS right? The larger NFS UDP mount sizes mean more fragments, but intriguingly, they also mean slower wrap of the IP ID space :) rick jones From ak@muc.de Tue May 17 12:18:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:18:20 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJI5F3014934 for ; Tue, 17 May 2005 12:18:06 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 50410D033F; Tue, 17 May 2005 21:17:30 +0200 (CEST) To: John Heffner Cc: "David S. Miller" , netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> <200505171457.38719.jheffner@psc.edu> From: Andi Kleen Date: Tue, 17 May 2005 21:17:30 +0200 In-Reply-To: <200505171457.38719.jheffner@psc.edu> (John Heffner's message of "Tue, 17 May 2005 14:57:38 -0400") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 400 Lines: 12 John Heffner writes: > > It would be better still to have a per-route packet reassembly timeout in > milliseconds. Expecting perfect ordering seems very fragile even for a LAN. In fact I implemented that a long time ago for the SUSE 2.4 kernel. But for some reason nobody liked it very much, so I never submitted it. I can dig out the old patches if there is interest. -Andi From rick.jones2@hp.com Tue May 17 12:22:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:23:06 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJMtF3019286 for ; Tue, 17 May 2005 12:22:55 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id B84D21C9B for ; Tue, 17 May 2005 12:21:49 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id MAA28131 for ; Tue, 17 May 2005 12:21:47 -0700 (PDT) Message-ID: <428A444B.8000608@hp.com> Date: Tue, 17 May 2005 12:21:47 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> <200505171457.38719.jheffner@psc.edu> <20050517.120950.74749758.davem@davemloft.net> In-Reply-To: <20050517.120950.74749758.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 608 Lines: 19 David S. Miller wrote: > From: John Heffner > Date: Tue, 17 May 2005 14:57:38 -0400 > > >>It would be better still to have a per-route packet reassembly timeout in >>milliseconds. > > > I agree. And if we can setup the infrastructure such that the > drivers can indicate the speed of the link they are communicating > on, then we can set sane default values on the automatically > created subnet routes. Does the ingress link really tell us all that much about the path a given datagram's fragments took to get to us? Even if the source IP is ostensibly a local one? rick jones From niv@us.ibm.com Tue May 17 12:25:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:26:05 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJPoF3019920 for ; Tue, 17 May 2005 12:25:50 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4HJPFLK098066 for ; Tue, 17 May 2005 15:25:15 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4HJPELN235958 for ; Tue, 17 May 2005 13:25:14 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4HJPErD000417 for ; Tue, 17 May 2005 13:25:14 -0600 Received: from [9.65.19.39] (sig-9-65-19-39.mts.ibm.com [9.65.19.39]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4HJPDZv032632; Tue, 17 May 2005 13:25:14 -0600 Message-ID: <428A452B.2010008@us.ibm.com> Date: Tue, 17 May 2005 12:25:31 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rick Jones CC: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> <428A3F86.1020000@us.ibm.com> <428A425F.7000807@hp.com> In-Reply-To: <428A425F.7000807@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1978 Lines: 45 Rick Jones wrote: > >> This is a fast LAN problem - real internet latencies >> don't allow for the wrapping of the id field that fast. > > > What is a "fast" LAN these days? We were seeing IP ID wrap with NFS > traffic back in the time of HP-UX 8.07 (early 1990's) over 10 Mbit/s > Ethernet. Since I'm waxing historic, part of the problem at that time > was giving the IP fragments to the driver one at a time rather than all > at once. When the system was as fast or faster than the network, and > the driver queue filled, the first couple fragments of a datagram would > get into the queue, and the rest would be dropped, setting the stage for > those wonderful Frankengrams. Part of the fix was to require a driver > to take an entire IP datagram's worth of fragments or none of them. Yes, a different manifestation of the problem ;). I was talking in the context of current Linux code and the common ethernet drivers and typical current Internet/Intranet latencies. > And there was at least one CKO NIC from that era (the HP-PB FDDI NIC) > where the first IP datagram fragment was sent last :) > > If the WAN connected system is (still?) using a global IP ID rather than > per-route, it could quite easily be wrapping. And we have WAN links > with bandwidths of 10's of Megabits, so it also comes-down to how much > other traffic is going and the quantity of request parallelism in NFS > right? Actually, the problem is much worse now - we have virtual partitions in the Xen environment for instance where some packets are headed for local consumption (virtual network, no actual network latency to speak of) and some going out to the network. Having a global IP id generator just won't be able to keep up - we could wrap in submilliseconds... > The larger NFS UDP mount sizes mean more fragments, but intriguingly, > they also mean slower wrap of the IP ID space :) True, but in a 32 NIC environment, see how they wrap ;)... thanks, Nivedita From greearb@candelatech.com Tue May 17 12:27:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:27:21 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJR6F3020269 for ; Tue, 17 May 2005 12:27:07 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j4HJvpGf009793; Tue, 17 May 2005 12:57:51 -0700 Message-ID: <428A455F.8060700@candelatech.com> Date: Tue, 17 May 2005 12:26:23 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: jheffner@psc.edu, ak@muc.de, netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> <200505171457.38719.jheffner@psc.edu> <20050517.120950.74749758.davem@davemloft.net> In-Reply-To: <20050517.120950.74749758.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 924 Lines: 31 David S. Miller wrote: > From: John Heffner > Date: Tue, 17 May 2005 14:57:38 -0400 > > >>It would be better still to have a per-route packet reassembly timeout in >>milliseconds. > > > I agree. And if we can setup the infrastructure such that the > drivers can indicate the speed of the link they are communicating > on, then we can set sane default values on the automatically > created subnet routes. I assume you mean more than local physical link speed? Imagine: GigE server -- gige-core -- 10bt hub -- gige-core -- gige client Now, this particular setup would be lame, but the 10bt hub could really be a bridged WAN, wireless or other slow and not-so-easily upgraded network link. Local link speed is relatively easy to figure out using ethtool for the NICs that support it at least.... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jheffner@psc.edu Tue May 17 12:32:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:32:10 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJW1F3021766 for ; Tue, 17 May 2005 12:32:01 -0700 Received: from homer.psc.edu (homer.psc.edu [128.182.61.117]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j4HJVJJe006783 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 17 May 2005 15:31:23 -0400 (EDT) From: John Heffner Organization: PSC To: Nivedita Singhvi , netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Date: Tue, 17 May 2005 15:31:36 -0400 User-Agent: KMail/1.8 Cc: Rick Jones References: <428A425F.7000807@hp.com> <428A452B.2010008@us.ibm.com> In-Reply-To: <428A452B.2010008@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505171531.37167.jheffner@psc.edu> X-archive-position: 1230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 291 Lines: 8 On Tuesday 17 May 2005 03:25 pm, Nivedita Singhvi wrote: > Yes, a different manifestation of the problem ;). I was talking > in the context of current Linux code and the common ethernet drivers > and typical current Internet/Intranet latencies. The problem is latency independent. -John From rick.jones2@hp.com Tue May 17 12:34:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:34:18 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJY5F3022399 for ; Tue, 17 May 2005 12:34:06 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id 235991C05061 for ; Tue, 17 May 2005 12:33:31 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id MAA28276 for ; Tue, 17 May 2005 12:33:30 -0700 (PDT) Message-ID: <428A470A.6010703@hp.com> Date: Tue, 17 May 2005 12:33:30 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> <428A3F86.1020000@us.ibm.com> <428A425F.7000807@hp.com> <428A452B.2010008@us.ibm.com> In-Reply-To: <428A452B.2010008@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 745 Lines: 19 > Actually, the problem is much worse now - we have virtual > partitions in the Xen environment for instance where some > packets are headed for local consumption (virtual network, > no actual network latency to speak of) and some going > out to the network. Having a global IP id generator just > won't be able to keep up - we could wrap in submilliseconds... and the classic TCP sequence number isn't _really_ all that far behind :) >> The larger NFS UDP mount sizes mean more fragments, but intriguingly, >> they also mean slower wrap of the IP ID space :) > > > True, but in a 32 NIC environment, see how they wrap ;)... Yep - I'd thought that just about everyone had gone to per-dest or per-route IP ID's by now, but even then rick From proski@gnu.org Tue May 17 12:43:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:44:08 -0700 (PDT) Received: from localhost.localdomain (h-64-105-159-118.phlapafg.covad.net [64.105.159.118]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJhrF3023815 for ; Tue, 17 May 2005 12:43:53 -0700 Received: by localhost.localdomain (Postfix, from userid 500) id BAD09EFE66; Tue, 17 May 2005 15:43:14 -0400 (EDT) Subject: Re: [PATCH 11/12] orinoco: monitor mode support From: Pavel Roskin To: Francois Romieu Cc: Christoph Hellwig , jgarzik@pobox.com, hermes@gibson.dropbear.id.au, netdev@oss.sgi.com In-Reply-To: <20050514173947.GA32235@electric-eye.fr.zoreil.com> References: <20050514153100.GL3643@lst.de> <20050514173947.GA32235@electric-eye.fr.zoreil.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 17 May 2005 15:43:14 -0400 Message-Id: <1116358994.5534.2.camel@dv.roinet.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 1232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: proski@gnu.org Precedence: bulk X-list: netdev Content-Length: 828 Lines: 38 On Sat, 2005-05-14 at 19:39 +0200, Francois Romieu wrote: > > + drop: > > + stats->rx_errors++; > > + stats->rx_dropped++; > > +} > > -> leak (skb). Indeed. Thank you! Please apply this on top of the original patches: Signed-off-by: Pavel Roskin --- orinoco.c +++ orinoco.c @@ -1180,7 +1180,7 @@ static void orinoco_rx_monitor(struct ne u16 fc; int err; int len; - struct sk_buff *skb; + struct sk_buff *skb = NULL; struct orinoco_private *priv = netdev_priv(dev); struct net_device_stats *stats = &priv->stats; hermes_t *hw = &priv->hw; @@ -1268,6 +1268,8 @@ static void orinoco_rx_monitor(struct ne drop: stats->rx_errors++; stats->rx_dropped++; + if (skb) + dev_kfree_skb_irq(skb); } static void __orinoco_ev_rx(struct net_device *dev, hermes_t *hw) -- Regards, Pavel Roskin From niv@us.ibm.com Tue May 17 12:53:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:53:20 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJr2F3024735 for ; Tue, 17 May 2005 12:53:08 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4HJqQLK366358 for ; Tue, 17 May 2005 15:52:26 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4HJqQLN237920 for ; Tue, 17 May 2005 13:52:26 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4HJqPRC013783 for ; Tue, 17 May 2005 13:52:26 -0600 Received: from [127.0.0.1] (sig-9-65-13-25.mts.ibm.com [9.65.13.25]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4HJqOEI013458; Tue, 17 May 2005 13:52:25 -0600 Message-ID: <428A4B74.4050503@us.ibm.com> Date: Tue, 17 May 2005 12:52:20 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Heffner CC: netdev@oss.sgi.com, Rick Jones Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <428A425F.7000807@hp.com> <428A452B.2010008@us.ibm.com> <200505171531.37167.jheffner@psc.edu> In-Reply-To: <200505171531.37167.jheffner@psc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 429 Lines: 16 John Heffner wrote: > On Tuesday 17 May 2005 03:25 pm, Nivedita Singhvi wrote: > >>Yes, a different manifestation of the problem ;). I was talking >>in the context of current Linux code and the common ethernet drivers >>and typical current Internet/Intranet latencies. > > > The problem is latency independent. Not entirely - because our reassembly timeout expires, typically. (If I understand you right). thanks, Nivedita From ak@muc.de Tue May 17 12:53:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:53:58 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJrjF3024780 for ; Tue, 17 May 2005 12:53:48 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 6EBDED033F; Tue, 17 May 2005 21:53:08 +0200 (CEST) To: Rick Jones Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> <428A3F86.1020000@us.ibm.com> <428A425F.7000807@hp.com> <428A452B.2010008@us.ibm.com> <428A470A.6010703@hp.com> From: Andi Kleen Date: Tue, 17 May 2005 21:53:08 +0200 In-Reply-To: <428A470A.6010703@hp.com> (Rick Jones's message of "Tue, 17 May 2005 12:33:30 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 599 Lines: 15 Rick Jones writes: >> Actually, the problem is much worse now - we have virtual >> partitions in the Xen environment for instance where some >> packets are headed for local consumption (virtual network, >> no actual network latency to speak of) and some going >> out to the network. Having a global IP id generator just >> won't be able to keep up - we could wrap in submilliseconds... > > and the classic TCP sequence number isn't _really_ all that far behind :) But it has PAWS at least. But I agree even IPv6 fragmentation with 32bit IDs is not significantly safer. -Andi From dlstevens@us.ibm.com Tue May 17 12:56:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 12:56:55 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HJuhF3025857; Tue, 17 May 2005 12:56:43 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4HJu8LK596898; Tue, 17 May 2005 15:56:08 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4HJu7LN252496; Tue, 17 May 2005 13:56:07 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4HJu7bG032015; Tue, 17 May 2005 13:56:07 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4HJu7oR032008; Tue, 17 May 2005 13:56:07 -0600 In-Reply-To: To: Andi Kleen Cc: akepner@sgi.com, "David S. Miller" , John Heffner , netdev@oss.sgi.com, netdev-bounce@oss.sgi.com MIME-Version: 1.0 Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Tue, 17 May 2005 12:56:05 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 05/17/2005 13:56:06, Serialize complete at 05/17/2005 13:56:06 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 1235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 339 Lines: 11 Dave, Shouldn't that be an estimator on the destination RTT? Or is that what you meant? A fast link locally that traverses a slow path along the way would time out too fast. Of course, getting an RTT estimate if there hasn't been TCP traffic is a complication. :-) +-DLS From jheffner@psc.edu Tue May 17 13:05:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:05:54 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HK5gF3026990 for ; Tue, 17 May 2005 13:05:43 -0700 Received: from homer.psc.edu (homer.psc.edu [128.182.61.117]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j4HK53et017005 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 17 May 2005 16:05:07 -0400 (EDT) From: John Heffner Organization: PSC To: Nivedita Singhvi Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Date: Tue, 17 May 2005 16:05:20 -0400 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <200505171531.37167.jheffner@psc.edu> <428A4B74.4050503@us.ibm.com> In-Reply-To: <428A4B74.4050503@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505171605.21093.jheffner@psc.edu> X-archive-position: 1236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 559 Lines: 15 On Tuesday 17 May 2005 03:52 pm, Nivedita Singhvi wrote: > John Heffner wrote: > > On Tuesday 17 May 2005 03:25 pm, Nivedita Singhvi wrote: > >>Yes, a different manifestation of the problem ;). I was talking > >>in the context of current Linux code and the common ethernet drivers > >>and typical current Internet/Intranet latencies. > > > > The problem is latency independent. > > Not entirely - because our reassembly timeout expires, typically. > (If I understand you right). Timer expiration is not dependent on latency, nor is IP ID wrap time. -John From rick.jones2@hp.com Tue May 17 13:14:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:14:13 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HKEBF3027808 for ; Tue, 17 May 2005 13:14:11 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id 03A76459C7 for ; Tue, 17 May 2005 13:12:18 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id NAA28633 for ; Tue, 17 May 2005 13:12:18 -0700 (PDT) Message-ID: <428A5022.2080606@hp.com> Date: Tue, 17 May 2005 13:12:18 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <200505171531.37167.jheffner@psc.edu> <428A4B74.4050503@us.ibm.com> <200505171605.21093.jheffner@psc.edu> In-Reply-To: <200505171605.21093.jheffner@psc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 554 Lines: 13 > Timer expiration is not dependent on latency, nor is IP ID wrap time. IP ID wrap time depends on the rate at which IP datgrams are generated. That will depend on latency if the stuff sitting above IP is latency sensitive and/or has not increased its "window" (classic TCP, or number of outstanding NFS requests ets) to compensate for latency. So, it is certainly true that one cannot ass-u-me that a high latency path cannot have IP ID wrap, but latency can indeed be a factor in how quickly IP IDs will wrap in a given situation. rick jones From ak@muc.de Tue May 17 13:18:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:18:26 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HKICF3028472; Tue, 17 May 2005 13:18:12 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id D8AD7D033F; Tue, 17 May 2005 22:17:36 +0200 (CEST) To: David Stevens Cc: akepner@sgi.com, "David S. Miller" , John Heffner , netdev@oss.sgi.com, netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: From: Andi Kleen Date: Tue, 17 May 2005 22:17:36 +0200 In-Reply-To: (David Stevens's message of "Tue, 17 May 2005 12:56:05 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 427 Lines: 14 David Stevens writes: > Dave, > Shouldn't that be an estimator on the destination RTT? Or is that > what you meant? A fast link locally that traverses a slow path along the > way > would time out too fast. > Of course, getting an RTT estimate if there hasn't been TCP > traffic > is a complication. :-) At least for a directly connected flat network you could get it from ARP. -Andi From davem@davemloft.net Tue May 17 13:23:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:23:03 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HKMxF3029132; Tue, 17 May 2005 13:23:00 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DY8Zm-0000fH-Qe; Tue, 17 May 2005 13:22:02 -0700 Date: Tue, 17 May 2005 13:22:02 -0700 (PDT) Message-Id: <20050517.132202.59028935.davem@davemloft.net> To: ak@muc.de Cc: dlstevens@us.ibm.com, akepner@sgi.com, jheffner@psc.edu, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 236 Lines: 7 From: Andi Kleen Date: Tue, 17 May 2005 22:17:36 +0200 > At least for a directly connected flat network you could get it from ARP. So we can make this host based, and store that "arp RTT" thing in the inetpeer cache. :-) From akepner@sgi.com Tue May 17 13:23:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:23:56 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HKNrF3029398 for ; Tue, 17 May 2005 13:23:54 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4HM7mAi019954 for ; Tue, 17 May 2005 15:07:48 -0700 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4HKNF3d26900126; Tue, 17 May 2005 13:23:16 -0700 (PDT) Date: Tue, 17 May 2005 13:21:13 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: "David S.Miller" cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly In-Reply-To: <20050517.114829.115910656.davem@davemloft.net> Message-ID: References: <20050517.104947.112621738.davem@davemloft.net> <20050517.114829.115910656.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 410 Lines: 16 On Tue, 17 May 2005, David S.Miller wrote: > .... > Can I tell users to call you when they enable the strict > fragmentation and they can no longer talk UDP to > remote sites outside of their subnet, or it breaks > on their heavily SMP machine due to natural system local > packet reordering? > .... I'd much rather take that call than one from a customer whose data has been quietly corrupted. -- Arthur From ak@muc.de Tue May 17 13:28:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:28:19 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HKSCF3030375 for ; Tue, 17 May 2005 13:28:13 -0700 Received: (qmail 92024 invoked by uid 3709); 17 May 2005 20:27:30 -0000 Date: 17 May 2005 22:27:30 +0200 Date: Tue, 17 May 2005 22:27:30 +0200 From: Andi Kleen To: "David S. Miller" Cc: dlstevens@us.ibm.com, akepner@sgi.com, jheffner@psc.edu, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050517202730.GA79960@muc.de> References: <20050517.132202.59028935.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517.132202.59028935.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 1241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 628 Lines: 17 On Tue, May 17, 2005 at 01:22:02PM -0700, David S. Miller wrote: > From: Andi Kleen > Date: Tue, 17 May 2005 22:17:36 +0200 > > > At least for a directly connected flat network you could get it from ARP. > > So we can make this host based, and store that "arp RTT" thing in the > inetpeer cache. :-) Arghl, you said the "i" word.... Anyways, I think the neighbour cache is fully appropiate, is it not? But it's not clear such a hack would be worth it anyways. If anything it would be probably better to let mountd set the RTTs, e.g. implicitely with MSG_CONFIRM (I hope it is using it these days ...) -Andi From jheffner@psc.edu Tue May 17 13:30:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:30:04 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HKU1F3030986 for ; Tue, 17 May 2005 13:30:01 -0700 Received: from homer.psc.edu (homer.psc.edu [128.182.61.117]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j4HKSoPo026425 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 17 May 2005 16:29:20 -0400 (EDT) From: John Heffner Organization: PSC To: David Stevens Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Date: Tue, 17 May 2005 16:29:08 -0400 User-Agent: KMail/1.8 Cc: Andi Kleen , akepner@sgi.com, "David S. Miller" , netdev@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505171629.08943.jheffner@psc.edu> X-archive-position: 1242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 543 Lines: 14 On Tuesday 17 May 2005 03:56 pm, David Stevens wrote: > Dave, > Shouldn't that be an estimator on the destination RTT? Or is that Unfortunately, it's not the RTT that matters, but link speed. You could probably do some heuristics on this, but I don't know if it's worth the effort. IMO, high-rate applications which rely on IP fragmentation and a 16-bit ones complement for data integrity are broken, and a band-aid style workaround for them is probably good enough. As long as it's not inflicted on the rest of us. :) -John From tgraf@suug.ch Tue May 17 13:48:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:48:46 -0700 (PDT) Received: from postel.suug.ch ([195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HKmUF3032450 for ; Tue, 17 May 2005 13:48:30 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 96B2C1C0EB; Tue, 17 May 2005 22:48:06 +0200 (CEST) Date: Tue, 17 May 2005 22:48:06 +0200 From: Thomas Graf To: "David S. Miller" Cc: jheffner@psc.edu, ak@muc.de, netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050517204806.GF13748@postel.suug.ch> References: <20050517.104947.112621738.davem@davemloft.net> <200505171457.38719.jheffner@psc.edu> <20050517.120950.74749758.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517.120950.74749758.davem@davemloft.net> X-archive-position: 1244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1472 Lines: 30 * David S. Miller <20050517.120950.74749758.davem@davemloft.net> 2005-05-17 12:09 > From: John Heffner > Date: Tue, 17 May 2005 14:57:38 -0400 > > > It would be better still to have a per-route packet reassembly timeout in > > milliseconds. > > I agree. And if we can setup the infrastructure such that the > drivers can indicate the speed of the link they are communicating > on, then we can set sane default values on the automatically > created subnet routes. I think we have two separate issues to resolve, first we need to figure out a way to state the probability of a id wrap, this can be a very simple pps rate estimator on the driver statistics for hardware interfaces and something more tricky for virtual interfaces such as found in xen. I think the link speed is not reliable enough for this. The second issue covers the actual defeat of the wraps, we have to differ between the rare but possible case for long delayed fragments and short delayed reorderings as caused by SMP. A combination of both short and long delayed reorderings rarely happens in practice and if so that's the bigger problem anyway. The above probability can be used to distinguish these cases and be more specific. SMP caused fragments have a very local distribution and thus the window for accepted ids can be smaller than the one for a long delayed fragment session. So maybe we can use the above probability as a factor to calculate a window of accepted ids. From kaber@trash.net Tue May 17 13:48:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:48:43 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HKmPF3032457 for ; Tue, 17 May 2005 13:48:26 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DY8yi-0007zx-VM; Tue, 17 May 2005 22:47:48 +0200 Message-ID: <428A5874.8020806@trash.net> Date: Tue, 17 May 2005 22:47:48 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: Jamal Hadi Salim , netdev@oss.sgi.com, lartc Subject: Re: Qdisc requeue should be void? References: <20050513105754.2e7cc243@dxpl.pdx.osdl.net> In-Reply-To: <20050513105754.2e7cc243@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1556 Lines: 38 Stephen Hemminger wrote: > There is an design problem with the qdisc interface that causes qlen related bugs > in netem, tbf, and other qdisc's that peek at the top of the queue. The problem is > that requeue needs to be called from the dequeue function but requeue can fail. > If requeue fails, then the calling qdisc can not properly handle the error. If it > returns NULL, then the parent's expectation about qlen gets messed up. > > Example: > > prio (qlen = 1) > skb = netem dequeue > skb = htb dequeue > ... decides not to send this skb now > htp requeue(skb) fails > ?? what now > --netem.qlen // := 0 > return NULL > skb is NULL > > at this point prio qlen is 1 but underlying queue's are empty. > > My proposal is to require requeue to always succeed and change it to be > void instead of returning int. Perhaps we should add a ->peek() operation which guarantees that the next dequeued packet is the one peeked at. This would also help with a second problem resulting from requeueing in at least TBF and HFSC. TBF looks at a packet and if it can't be sent immediately calculates the delay from the packet's length. HFSC does the same to calculate the deadline for a class. Both assume the next packet dequeued from the underlying qdisc is the one requeued, which is only true with non-reordering qdiscs. Adding a peek-operation increases the worst-case delay by one maximum sized packet transmission time, but otherwise these qdiscs can't make proper use of reordering qdiscs like SFQ at all. Regards Patrick From romieu@fr.zoreil.com Tue May 17 13:51:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 13:52:00 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HKpjF3000769 for ; Tue, 17 May 2005 13:51:46 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4HKmH3O020852; Tue, 17 May 2005 22:48:17 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4HKmBZ7020851; Tue, 17 May 2005 22:48:12 +0200 Date: Tue, 17 May 2005 22:48:11 +0200 From: Francois Romieu To: Jeff Garzik Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: [patch linux-2.6.12-rc3-mm3 1/7] r8169: de-obfuscate supported PCI ID Message-ID: <20050517204811.GA12936@electric-eye.fr.zoreil.com> References: <20050504221057.1e02a402.akpm@osdl.org> <20050505115502.GA4414@electric-eye.fr.zoreil.com> <20050505110052.62c1c2cb.akpm@osdl.org> <20050505225656.GA11200@electric-eye.fr.zoreil.com> <4287C9D6.1060004@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4287C9D6.1060004@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 548 Lines: 19 Jeff Garzik : > All seven look OK, but it failed on the first patch: > > [jgarzik@pretzel netdev-2.6]$ dotest /g/tmp/mbox > > Applying 'r8169: de-obfuscate supported PCI ID' > > patching file drivers/net/r8169.c > Hunk #1 FAILED at 174. > 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/r8169.c.rej Yes. In the meantime, -mm was applied: [patch 2.6.12-rc2-mm3 1/1] r8169: new PCI id Should I send a serie of patches against 126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c to update it to r8169-mm-latest ? -- Ueimor From davem@davemloft.net Tue May 17 14:03:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 14:03:50 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HL3VF3002649; Tue, 17 May 2005 14:03:31 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DY9DC-0000kU-0e; Tue, 17 May 2005 14:02:46 -0700 Date: Tue, 17 May 2005 14:02:45 -0700 (PDT) Message-Id: <20050517.140245.71090021.davem@davemloft.net> To: ak@muc.de Cc: dlstevens@us.ibm.com, akepner@sgi.com, jheffner@psc.edu, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: <20050517202730.GA79960@muc.de> References: <20050517.132202.59028935.davem@davemloft.net> <20050517202730.GA79960@muc.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 381 Lines: 9 From: Andi Kleen Date: 17 May 2005 22:27:30 +0200,Tue, 17 May 2005 22:27:30 +0200 > But it's not clear such a hack would be worth it anyways. > If anything it would be probably better to let mountd set the RTTs, e.g. > implicitely with MSG_CONFIRM (I hope it is using it these days ...) I think we should implement a solution that goes beyond the confines of NFS. From ak@muc.de Tue May 17 14:13:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 14:13:58 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HLDbF3003826 for ; Tue, 17 May 2005 14:13:38 -0700 Received: (qmail 99875 invoked by uid 3709); 17 May 2005 21:13:01 -0000 Date: 17 May 2005 23:13:01 +0200 Date: Tue, 17 May 2005 23:13:00 +0200 From: Andi Kleen To: "David S. Miller" Cc: dlstevens@us.ibm.com, akepner@sgi.com, jheffner@psc.edu, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050517211300.GB79960@muc.de> References: <20050517.132202.59028935.davem@davemloft.net> <20050517202730.GA79960@muc.de> <20050517.140245.71090021.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517.140245.71090021.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 1247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 512 Lines: 14 On Tue, May 17, 2005 at 02:02:45PM -0700, David S. Miller wrote: > From: Andi Kleen > Date: 17 May 2005 22:27:30 +0200,Tue, 17 May 2005 22:27:30 +0200 > > > But it's not clear such a hack would be worth it anyways. > > If anything it would be probably better to let mountd set the RTTs, e.g. > > implicitely with MSG_CONFIRM (I hope it is using it these days ...) > > I think we should implement a solution that goes beyond > the confines of NFS. Nothing in MSG_CONFIRM is NFS specific. -Andi From romieu@fr.zoreil.com Tue May 17 14:24:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 14:24:24 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HLO8F3004977 for ; Tue, 17 May 2005 14:24:09 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4HLMPRU022346; Tue, 17 May 2005 23:22:25 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4HLMHlL022345; Tue, 17 May 2005 23:22:17 +0200 Date: Tue, 17 May 2005 23:22:17 +0200 From: Francois Romieu To: Pavel Roskin Cc: Christoph Hellwig , jgarzik@pobox.com, hermes@gibson.dropbear.id.au, netdev@oss.sgi.com Subject: Re: [PATCH 11/12] orinoco: monitor mode support Message-ID: <20050517212217.GB12936@electric-eye.fr.zoreil.com> References: <20050514153100.GL3643@lst.de> <20050514173947.GA32235@electric-eye.fr.zoreil.com> <1116358994.5534.2.camel@dv.roinet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116358994.5534.2.camel@dv.roinet.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1644 Lines: 63 Pavel Roskin : > On Sat, 2005-05-14 at 19:39 +0200, Francois Romieu wrote: > > > + drop: > > > + stats->rx_errors++; > > > + stats->rx_dropped++; > > > +} > > > > -> leak (skb). > > Indeed. Thank you! Please apply this on top of the original patches: > > Signed-off-by: Pavel Roskin > > --- orinoco.c > +++ orinoco.c > @@ -1180,7 +1180,7 @@ static void orinoco_rx_monitor(struct ne > u16 fc; > int err; > int len; > - struct sk_buff *skb; > + struct sk_buff *skb = NULL; > struct orinoco_private *priv = netdev_priv(dev); > struct net_device_stats *stats = &priv->stats; > hermes_t *hw = &priv->hw; > @@ -1268,6 +1268,8 @@ static void orinoco_rx_monitor(struct ne > drop: > stats->rx_errors++; > stats->rx_dropped++; > + if (skb) > + dev_kfree_skb_irq(skb); > } > > static void __orinoco_ev_rx(struct net_device *dev, hermes_t *hw) > > I am not fond of unneeded/hidden state variable. What about: + /* sanity check the length */ + if (datalen > IEEE80211_DATA_LEN + 12) { + printk(KERN_DEBUG "%s: oversized monitor frame, " + "data length = %d\n", dev->name, datalen); + err = -EIO; + goto drop; ^^^^^^^^^^ -> let's replace by 'goto update_stats;' And turn: + drop: + stats->rx_errors++; + stats->rx_dropped++; into: + drop: + dev_kfree_skb_irq(skb); + update_stats: + stats->rx_errors++; + stats->rx_dropped++; This way 'goto drop' really drops and the code does not issue a 'goto drop' when it actually want to update the stats. -- Ueimor From davem@davemloft.net Tue May 17 14:24:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 14:25:09 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HLOtF3005029; Tue, 17 May 2005 14:24:55 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DY9Xq-0000wG-H5; Tue, 17 May 2005 14:24:06 -0700 Date: Tue, 17 May 2005 14:24:06 -0700 (PDT) Message-Id: <20050517.142406.11598558.davem@davemloft.net> To: ak@muc.de Cc: dlstevens@us.ibm.com, akepner@sgi.com, jheffner@psc.edu, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: <20050517211300.GB79960@muc.de> References: <20050517202730.GA79960@muc.de> <20050517.140245.71090021.davem@davemloft.net> <20050517211300.GB79960@muc.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 650 Lines: 17 From: Andi Kleen Date: 17 May 2005 23:13:01 +0200,Tue, 17 May 2005 23:13:00 +0200 > On Tue, May 17, 2005 at 02:02:45PM -0700, David S. Miller wrote: > > From: Andi Kleen > > Date: 17 May 2005 22:27:30 +0200,Tue, 17 May 2005 22:27:30 +0200 > > > > > But it's not clear such a hack would be worth it anyways. > > > If anything it would be probably better to let mountd set the RTTs, e.g. > > > implicitely with MSG_CONFIRM (I hope it is using it these days ...) > > > > I think we should implement a solution that goes beyond > > the confines of NFS. > > Nothing in MSG_CONFIRM is NFS specific. I'm referring to mountd. From rick.jones2@hp.com Tue May 17 14:25:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 14:26:10 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HLPtF3005614; Tue, 17 May 2005 14:25:55 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id 704FD3715; Tue, 17 May 2005 14:25:20 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id OAA00846; Tue, 17 May 2005 14:25:19 -0700 (PDT) Message-ID: <428A613F.1020303@hp.com> Date: Tue, 17 May 2005 14:25:19 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.132202.59028935.davem@davemloft.net> <20050517202730.GA79960@muc.de> <20050517.140245.71090021.davem@davemloft.net> In-Reply-To: <20050517.140245.71090021.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1025 Lines: 19 this may be drifting tooo much, but it seems the issue of deciding when to give-up on reassembly of an IP datagram is similar to the issues that neterion are going to be going-through creating their "LRO" (Large Receive Offload) solution, albeit the potential consequences of a bad decision are rather different. both seek to know when it is unlikely that no more frames/fragments will arrive. just how much extra overhead would there be to track the interarrival time of ip datagram fragments and would that allow someone to make a guess as to how long to reasonably wait for all the fragments to arrive? (or did I miss that being shot-down already?) or an added heuristic of "if have reassembled N datagrams for the same source/dest/protocol tuple with ID's "larger" than 'this one' since it has arrived, we are probably going to wrap so might as well drop 'this one'" for some judicious and magical selection of N that may be a decent predictor of wrap on top of some existing reassembly timout. rick jones From jaegert@us.ibm.com Tue May 17 14:29:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 14:29:53 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HLTcF3006700 for ; Tue, 17 May 2005 14:29:38 -0700 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j4HLTw12025899; Tue, 17 May 2005 17:29:59 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j4HLSjs54216; Tue, 17 May 2005 17:28:45 -0400 Received: from [9.2.18.177] (dyn9002018177.watson.ibm.com [9.2.18.177]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j4HLShH23746; Tue, 17 May 2005 17:28:43 -0400 Subject: [PATCH 1/2] Resend: LSM-IPSec Networking Hooks From: jaegert To: netdev@oss.sgi.com, chrisw@osdl.org Cc: jaegert@us.ibm.com, serue@us.ibm.com, latten@austin.ibm.com, sds@tycho.nsa.gov, jmorris@redhat.com Content-Type: text/plain Message-Id: <1116361510.5560.121.camel@dyn9002018177.watson.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 17 May 2005 16:25:11 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4HLTcF3006700 X-archive-position: 1251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaegert@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 41903 Lines: 1278 Hi, I am resending these patches because of format errors in the original mails. I apologize for that inconvenience. Regards, Trent. ----------------------------------- Trent Jaeger IBM T.J. Watson Research Center 19 Skyline Drive, Hawthorne, NY 10532 (914) 784-7225, (FAX) (914) 784-6209 This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the XFRM subsystem, pfkey interface, ipv4/ipv6, and xfrm_user interface to restrict a socket to use only authorized security associations (or no security association) to send/receive network packets. Patch purpose: The patch is designed to enable access control per packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the system can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The overall approach is that policy (xfrm_policy) entries set by user-level programs (e.g., setkey for ipsec-tools) are extended with a security context that is used at policy selection time in the XFRM subsystem to restrict the sockets that can send/receive packets via security associations (xfrm_states) that are built from those policies. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: On output, the policy retrieved (via xfrm_policy_lookup or xfrm_sk_policy_lookup) must be authorized for the security context of the socket and the same security context is required for resultant security association (retrieved or negotiated via racoon in ipsec-tools). This is enforced in xfrm_state_find. On input, the policy retrieved must also be authorized for the socket (at __xfrm_policy_check), and the security context of the policy must also match the security association being used. The patch has virtually no impact on packets that do not use IPSec. The existing Netfilter (outgoing) and LSM rcv_skb hooks are used as before. Also, if IPSec is used without security contexts, the impact is minimal. The LSM must allow such policies to be selected for the combination of socket and remote machine, but subsequent IPSec processing proceeds as in the original case. Testing: The pfkey interface is tested using the ipsec-tools. ipsec-tools have been modified (a separate ipsec-tools patch is available for version 0.5) that supports assignment of xfrm_policy entries and security associations with security contexts via setkey and the negotiation using the security contexts via racoon. The xfrm_user interface is tested via ad hoc programs that set security contexts. These programs are also available from me, and contain programs for setting, getting, and deleting policy for testing this interface. Testing of sa functions was done by tracing kernel behavior. --- include/linux/pfkeyv2.h | 13 +++ include/linux/security.h | 119 +++++++++++++++++++++++++++++++++++ include/linux/xfrm.h | 36 ++++++++++ include/net/flow.h | 5 - include/net/xfrm.h | 21 ++++++ net/core/flow.c | 4 - net/ipv4/xfrm4_policy.c | 2 net/ipv6/xfrm6_policy.c | 2 net/key/af_key.c | 119 +++++++++++++++++++++++++++++++++-- net/xfrm/xfrm_policy.c | 64 +++++++++++------- net/xfrm/xfrm_state.c | 14 +++- net/xfrm/xfrm_user.c | 159 +++++++++++++++++++++++++++++++++++++++++++++-- security/Kconfig | 13 +++ security/dummy.c | 37 ++++++++++ 14 files changed, 568 insertions(+), 40 deletions(-) diff -puN include/linux/pfkeyv2.h~lsm-xfrm-nethooks include/linux/pfkeyv2.h --- linux-2.6.12-rc4-nethooks/include/linux/pfkeyv2.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/linux/pfkeyv2.h 2005-05-10 16:19:20.000000000 -0400 @@ -216,6 +216,16 @@ struct sadb_x_nat_t_port { } __attribute__((packed)); /* sizeof(struct sadb_x_nat_t_port) == 8 */ +/* Generic LSM security context */ +struct sadb_x_sec_ctx { + uint16_t sadb_x_sec_len; + uint16_t sadb_x_sec_exttype; + uint8_t sadb_x_ctx_alg; /* LSMs: e.g., selinux == 1 */ + uint8_t sadb_x_ctx_doi; + uint16_t sadb_x_ctx_len; +} __attribute__((packed)); +/* sizeof(struct sadb_sec_ctx) = 8 */ + /* Message types */ #define SADB_RESERVED 0 #define SADB_GETSPI 1 @@ -324,7 +334,8 @@ struct sadb_x_nat_t_port { #define SADB_X_EXT_NAT_T_SPORT 21 #define SADB_X_EXT_NAT_T_DPORT 22 #define SADB_X_EXT_NAT_T_OA 23 -#define SADB_EXT_MAX 23 +#define SADB_X_EXT_SEC_CTX 24 +#define SADB_EXT_MAX 24 /* Identity Extension values */ #define SADB_IDENTTYPE_RESERVED 0 diff -puN include/linux/security.h~lsm-xfrm-nethooks include/linux/security.h --- linux-2.6.12-rc4-nethooks/include/linux/security.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/linux/security.h 2005-05-16 16:12:29.000000000 -0400 @@ -58,6 +58,12 @@ struct sk_buff; struct sock; struct sockaddr; struct socket; +struct flowi; +struct dst_entry; +struct xfrm_selector; +struct xfrm_policy; +struct xfrm_state; +struct sadb_x_sec_ctx; extern int cap_netlink_send(struct sock *sk, struct sk_buff *skb); extern int cap_netlink_recv(struct sk_buff *skb); @@ -802,6 +808,50 @@ struct swap_info_struct; * @sk_free_security: * Deallocate security structure. * + * Security hooks for XFRM operations. + * + * @xfrm_policy_alloc_security: + * @xp contains the xfrm_policy being added to Security Policy Database + * used by the XFRM system. + * @sec_ctx contains the security context information being provided by + * the user-level policy update program (e.g., setkey). + * Allocate a security structure to the xp->selector.security field. + * The security field is initialized to NULL when the xfrm_policy is + * allocated. + * Return 0 if operation was successful (memory to allocate, legal context) + * @xfrm_policy_clone_security: + * @old contains an existing xfrm_policy in the SPD. + * @new contains a new xfrm_policy being cloned from old. + * Allocate a security structure to the new->selector.security field + * that contains the information from the old->selector.security field. + * Return 0 if operation was successful (memory to allocate). + * @xfrm_policy_free_security: + * @xp contains the xfrm_policy + * Deallocate xp->selector.security. + * @xfrm_state_alloc_security: + * @x contains the xfrm_state being added to the Security Association + * Database by the XFRM system. + * @sec_ctx contains the security context information being provided by + * the user-level SA generation program (e.g., setkey or racoon). + * Allocate a security structure to the x->sel.security field. The + * security field is initialized to NULL when the xfrm_state is + * allocated. + * Return 0 if operation was successful (memory to allocate, legal context). + * @xfrm_state_free_security: + * @x contains the xfrm_state. + * Deallocate x>sel.security. + * @xfrm_policy_lookup: + * @sk contains the sock that is requesting to either send or receive a + * network communication. + * @sel contains the selector that matches the communication end points of + * the network communication (source, destination, and ports). + * @fl contains the flowi that indicates the communication protocol. + * @dir contains the direction of the flow (input or output). + * Check permission when a sock selects a xfrm_policy for processing + * XFRMs on a packet. The hook is called when selecting either a + * per-socket policy or a generic xfrm policy. + * Return 0 if permission is granted. + * * Security hooks affecting all System V IPC operations. * * @ipc_permission: @@ -1243,6 +1293,15 @@ struct security_operations { int (*sk_alloc_security) (struct sock *sk, int family, int priority); void (*sk_free_security) (struct sock *sk); #endif /* CONFIG_SECURITY_NETWORK */ + +#ifdef CONFIG_SECURITY_NETWORK_XFRM + int (*xfrm_policy_alloc_security) (struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx); + int (*xfrm_policy_clone_security) (struct xfrm_policy *old, struct xfrm_policy *new); + void (*xfrm_policy_free_security) (struct xfrm_policy *xp); + int (*xfrm_state_alloc_security) (struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx); + void (*xfrm_state_free_security) (struct xfrm_state *x); + int (*xfrm_policy_lookup)(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir); +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ }; /* global variables */ @@ -2854,5 +2913,65 @@ static inline void security_sk_free(stru } #endif /* CONFIG_SECURITY_NETWORK */ +#ifdef CONFIG_SECURITY_NETWORK_XFRM +static inline int security_xfrm_policy_alloc(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx) +{ + return security_ops->xfrm_policy_alloc_security(xp, sec_ctx); +} + +static inline int security_xfrm_policy_clone(struct xfrm_policy *old, struct xfrm_policy *new) +{ + return security_ops->xfrm_policy_clone_security(old, new); +} + +static inline void security_xfrm_policy_free(struct xfrm_policy *xp) +{ + security_ops->xfrm_policy_free_security(xp); +} + +static inline int security_xfrm_state_alloc(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx) +{ + return security_ops->xfrm_state_alloc_security(x, sec_ctx); +} + +static inline void security_xfrm_state_free(struct xfrm_state *x) +{ + security_ops->xfrm_state_free_security(x); +} + +static inline int security_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir) +{ + return security_ops->xfrm_policy_lookup(sk, sel, fl, dir); +} +#else /* CONFIG_SECURITY_NETWORK_XFRM */ +static inline int security_xfrm_policy_alloc(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx) +{ + return 0; +} + +static inline int security_xfrm_policy_clone(struct xfrm_policy *old, struct xfrm_policy *new) +{ + return 0; +} + +static inline void security_xfrm_policy_free(struct xfrm_policy *xp) +{ +} + +static inline int security_xfrm_state_alloc(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx) +{ + return 0; +} + +static inline void security_xfrm_state_free(struct xfrm_state *x) +{ +} + +static inline int security_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir) +{ + return 0; +} +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ + #endif /* ! __LINUX_SECURITY_H */ diff -puN include/linux/xfrm.h~lsm-xfrm-nethooks include/linux/xfrm.h --- linux-2.6.12-rc4-nethooks/include/linux/xfrm.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/linux/xfrm.h 2005-05-10 16:22:40.000000000 -0400 @@ -27,6 +27,22 @@ struct xfrm_id __u8 proto; }; +struct xfrm_sec_ctx { + __u8 ctx_doi; + __u8 ctx_alg; + __u16 ctx_len; + __u32 ctx_sid; + char ctx_str[0]; +}; + +/* Security Context Domains of Interpretation */ +#define XFRM_SC_DOI_RESERVED 0 +#define XFRM_SC_DOI_LSM 1 + +/* Security Context Algorithms */ +#define XFRM_SC_ALG_RESERVED 0 +#define XFRM_SC_ALG_SELINUX 1 + /* Selector, used as selector both on policy rules (SPD) and SAs. */ struct xfrm_selector @@ -43,8 +59,15 @@ struct xfrm_selector __u8 proto; int ifindex; uid_t user; + struct xfrm_sec_ctx *security; }; +/* All but the security field */ +static inline int xfrm_selector_base_size(void) +{ + return sizeof(struct xfrm_selector) - sizeof(struct xfrm_sec_ctx *); +} + #define XFRM_INF (~(__u64)0) struct xfrm_lifetime_cfg @@ -146,6 +169,18 @@ enum { #define XFRM_NR_MSGTYPES (XFRM_MSG_MAX + 1 - XFRM_MSG_BASE) +/* + * Generic LSM security context for comunicating to user space + * NOTE: Same format as sadb_x_sec_ctx + */ +struct xfrm_user_sec_ctx { + __u16 len; + __u16 exttype; + __u8 ctx_alg; /* LSMs: e.g., selinux == 1 */ + __u8 ctx_doi; + __u16 ctx_len; +}; + struct xfrm_user_tmpl { struct xfrm_id id; __u16 family; @@ -173,6 +208,7 @@ enum xfrm_attr_type_t { XFRMA_ALG_CRYPT, /* struct xfrm_algo */ XFRMA_ALG_COMP, /* struct xfrm_algo */ XFRMA_ENCAP, /* struct xfrm_algo + struct xfrm_encap_tmpl */ + XFRMA_SEC_CTX, /* struct xfrm_sec_ctx */ XFRMA_TMPL, /* 1 or more struct xfrm_user_tmpl */ __XFRMA_MAX diff -puN include/net/flow.h~lsm-xfrm-nethooks include/net/flow.h --- linux-2.6.12-rc4-nethooks/include/net/flow.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/net/flow.h 2005-05-10 15:04:25.000000000 -0400 @@ -84,10 +84,11 @@ struct flowi { #define FLOW_DIR_OUT 1 #define FLOW_DIR_FWD 2 -typedef void (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir, +struct sock; +typedef void (*flow_resolve_t)(struct flowi *key, struct sock *sk, u16 family, u8 dir, void **objp, atomic_t **obj_refp); -extern void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir, +extern void *flow_cache_lookup(struct flowi *key, struct sock *sk, u16 family, u8 dir, flow_resolve_t resolver); extern void flow_cache_flush(void); extern atomic_t flow_cache_genid; diff -puN include/net/xfrm.h~lsm-xfrm-nethooks include/net/xfrm.h --- linux-2.6.12-rc4-nethooks/include/net/xfrm.h~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/include/net/xfrm.h 2005-05-12 15:38:22.000000000 -0400 @@ -493,6 +493,27 @@ xfrm_selector_match(struct xfrm_selector return 0; } +/* If neither has a context --> match + Otherwise, both must have a context and the sids, doi, alg must match */ +static inline int xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ctx *s2) +{ + return ((!s1 && !s2) || + (s1 && s2 && + (s1->ctx_sid == s2->ctx_sid) && + (s1->ctx_doi == s2->ctx_doi) && + (s1->ctx_alg == s2->ctx_alg))); +} + +static inline struct xfrm_sec_ctx *xfrm_policy_security(struct xfrm_policy *xp) +{ + return (xp ? xp->selector.security : NULL); +} + +static inline struct xfrm_sec_ctx *xfrm_state_security(struct xfrm_state *x) +{ + return (x ? x->sel.security : NULL); +} + /* A struct encoding bundle of transformations to apply to some set of flow. * * dst->child points to the next element of bundle. diff -puN net/core/flow.c~lsm-xfrm-nethooks net/core/flow.c --- linux-2.6.12-rc4-nethooks/net/core/flow.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/core/flow.c 2005-05-10 15:04:25.000000000 -0400 @@ -162,7 +162,7 @@ static int flow_key_compare(struct flowi return 0; } -void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir, +void *flow_cache_lookup(struct flowi *key, struct sock *sk, u16 family, u8 dir, flow_resolve_t resolver) { struct flow_cache_entry *fle, **head; @@ -221,7 +221,7 @@ nocache: void *obj; atomic_t *obj_ref; - resolver(key, family, dir, &obj, &obj_ref); + resolver(key, sk, family, dir, &obj, &obj_ref); if (fle) { fle->genid = atomic_read(&flow_cache_genid); diff -puN net/ipv4/xfrm4_policy.c~lsm-xfrm-nethooks net/ipv4/xfrm4_policy.c --- linux-2.6.12-rc4-nethooks/net/ipv4/xfrm4_policy.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/ipv4/xfrm4_policy.c 2005-05-16 13:33:47.000000000 -0400 @@ -36,6 +36,8 @@ __xfrm4_find_bundle(struct flowi *fl, st if (xdst->u.rt.fl.oif == fl->oif && /*XXX*/ xdst->u.rt.fl.fl4_dst == fl->fl4_dst && xdst->u.rt.fl.fl4_src == fl->fl4_src && + xfrm_sec_ctx_match(xfrm_policy_security(policy), + xfrm_state_security(dst->xfrm)) && xfrm_bundle_ok(xdst, fl, AF_INET)) { dst_clone(dst); break; diff -puN net/ipv6/xfrm6_policy.c~lsm-xfrm-nethooks net/ipv6/xfrm6_policy.c --- linux-2.6.12-rc4-nethooks/net/ipv6/xfrm6_policy.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/ipv6/xfrm6_policy.c 2005-05-10 15:13:49.000000000 -0400 @@ -54,6 +54,8 @@ __xfrm6_find_bundle(struct flowi *fl, st xdst->u.rt6.rt6i_src.plen); if (ipv6_addr_equal(&xdst->u.rt6.rt6i_dst.addr, &fl_dst_prefix) && ipv6_addr_equal(&xdst->u.rt6.rt6i_src.addr, &fl_src_prefix) && + xfrm_sec_ctx_match(xfrm_policy_security(policy), + xfrm_state_security(dst->xfrm)) && xfrm_bundle_ok(xdst, fl, AF_INET6)) { dst_clone(dst); break; diff -puN net/key/af_key.c~lsm-xfrm-nethooks net/key/af_key.c --- linux-2.6.12-rc4-nethooks/net/key/af_key.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/key/af_key.c 2005-05-16 16:13:56.000000000 -0400 @@ -336,6 +336,7 @@ static u8 sadb_ext_min_len[] = { [SADB_X_EXT_NAT_T_SPORT] = (u8) sizeof(struct sadb_x_nat_t_port), [SADB_X_EXT_NAT_T_DPORT] = (u8) sizeof(struct sadb_x_nat_t_port), [SADB_X_EXT_NAT_T_OA] = (u8) sizeof(struct sadb_address), + [SADB_X_EXT_SEC_CTX] = (u8) sizeof(struct sadb_x_sec_ctx), }; /* Verify sadb_address_{len,prefixlen} against sa_family. */ @@ -383,6 +384,22 @@ static int verify_address_len(void *p) return 0; } +static inline int verify_sec_ctx_len(void *p) +{ + struct sadb_x_sec_ctx *sec_ctx = (struct sadb_x_sec_ctx *)p; + int len = 0; + + len += sizeof(struct sadb_x_sec_ctx); + len += sec_ctx->sadb_x_ctx_len; + len += sizeof(uint64_t) - 1; + len /= sizeof(uint64_t); + + if (sec_ctx->sadb_x_sec_len != len) + return -EINVAL; + + return 0; +} + static int present_and_same_family(struct sadb_address *src, struct sadb_address *dst) { @@ -438,6 +455,10 @@ static int parse_exthdrs(struct sk_buff if (verify_address_len(p)) return -EINVAL; } + if (ext_type == SADB_X_EXT_SEC_CTX) { + if (verify_sec_ctx_len(p)) + return -EINVAL; + } ext_hdrs[ext_type-1] = p; } p += ext_len; @@ -586,6 +607,9 @@ static struct sk_buff * pfkey_xfrm_state struct sadb_key *key; struct sadb_x_sa2 *sa2; struct sockaddr_in *sin; + struct sadb_x_sec_ctx *sec_ctx; + struct xfrm_sec_ctx *xfrm_ctx; + int ctx_size = 0; #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) struct sockaddr_in6 *sin6; #endif @@ -609,6 +633,12 @@ static struct sk_buff * pfkey_xfrm_state sizeof(struct sadb_address)*2 + sockaddr_size*2 + sizeof(struct sadb_x_sa2); + + if ((xfrm_ctx = xfrm_state_security(x))) { + ctx_size = PFKEY_ALIGN8(xfrm_ctx->ctx_len); + size += sizeof(struct sadb_x_sec_ctx) + ctx_size; + } + /* identity & sensitivity */ if ((x->props.family == AF_INET && @@ -892,6 +922,20 @@ static struct sk_buff * pfkey_xfrm_state n_port->sadb_x_nat_t_port_reserved = 0; } + /* security context */ + if (xfrm_ctx) { + sec_ctx = (struct sadb_x_sec_ctx *) skb_put(skb, + sizeof(struct sadb_x_sec_ctx) + ctx_size); + sec_ctx->sadb_x_sec_len = + (sizeof(struct sadb_x_sec_ctx) + ctx_size) / sizeof(uint64_t); + sec_ctx->sadb_x_sec_exttype = SADB_X_EXT_SEC_CTX; + sec_ctx->sadb_x_ctx_doi = xfrm_ctx->ctx_doi; + sec_ctx->sadb_x_ctx_alg = xfrm_ctx->ctx_alg; + sec_ctx->sadb_x_ctx_len = xfrm_ctx->ctx_len; + memcpy(sec_ctx + 1, xfrm_ctx->ctx_str, + xfrm_ctx->ctx_len); + } + return skb; } @@ -902,6 +946,7 @@ static struct xfrm_state * pfkey_msg2xfr struct sadb_lifetime *lifetime; struct sadb_sa *sa; struct sadb_key *key; + struct sadb_x_sec_ctx *sec_ctx; uint16_t proto; int err; @@ -984,6 +1029,13 @@ static struct xfrm_state * pfkey_msg2xfr x->lft.soft_add_expires_seconds = lifetime->sadb_lifetime_addtime; x->lft.soft_use_expires_seconds = lifetime->sadb_lifetime_usetime; } + + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; + if (sec_ctx != NULL) { + if (security_xfrm_state_alloc(x, sec_ctx)) + goto out; + } + key = (struct sadb_key*) ext_hdrs[SADB_EXT_KEY_AUTH-1]; if (sa->sadb_sa_auth) { int keysize = 0; @@ -1634,6 +1686,18 @@ parse_ipsecrequests(struct xfrm_policy * return 0; } +static inline int pfkey_xfrm_policy2sec_ctx_size(struct xfrm_policy *xp) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); + + if (xfrm_ctx) { + int len = sizeof(struct sadb_x_sec_ctx); + len += xfrm_ctx->ctx_len; + return PFKEY_ALIGN8(len); + } + return 0; +} + static int pfkey_xfrm_policy2msg_size(struct xfrm_policy *xp) { int sockaddr_size = pfkey_sockaddr_size(xp->family); @@ -1647,7 +1711,8 @@ static int pfkey_xfrm_policy2msg_size(st (sockaddr_size * 2) + sizeof(struct sadb_x_policy) + (xp->xfrm_nr * (sizeof(struct sadb_x_ipsecrequest) + - (socklen * 2))); + (socklen * 2))) + + pfkey_xfrm_policy2sec_ctx_size(xp); } static struct sk_buff * pfkey_xfrm_policy2msg_prep(struct xfrm_policy *xp) @@ -1671,6 +1736,8 @@ static void pfkey_xfrm_policy2msg(struct struct sadb_lifetime *lifetime; struct sadb_x_policy *pol; struct sockaddr_in *sin; + struct sadb_x_sec_ctx *sec_ctx; + struct xfrm_sec_ctx *xfrm_ctx; #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) struct sockaddr_in6 *sin6; #endif @@ -1855,19 +1922,35 @@ static void pfkey_xfrm_policy2msg(struct } } } + + /* security context */ + if ((xfrm_ctx = xfrm_policy_security(xp))) { + int ctx_size = pfkey_xfrm_policy2sec_ctx_size(xp); + + sec_ctx = (struct sadb_x_sec_ctx *) skb_put(skb, ctx_size); + sec_ctx->sadb_x_sec_len = ctx_size / sizeof(uint64_t); + sec_ctx->sadb_x_sec_exttype = SADB_X_EXT_SEC_CTX; + sec_ctx->sadb_x_ctx_doi = xfrm_ctx->ctx_doi; + sec_ctx->sadb_x_ctx_alg = xfrm_ctx->ctx_alg; + sec_ctx->sadb_x_ctx_len = xfrm_ctx->ctx_len; + memcpy(sec_ctx + 1, xfrm_ctx->ctx_str, + xfrm_ctx->ctx_len); + } + hdr->sadb_msg_len = size / sizeof(uint64_t); hdr->sadb_msg_reserved = atomic_read(&xp->refcnt); } static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { - int err; + int err = 0; struct sadb_lifetime *lifetime; struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; struct sk_buff *out_skb; struct sadb_msg *out_hdr; + struct sadb_x_sec_ctx *sec_ctx; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -1914,6 +1997,12 @@ static int pfkey_spdadd(struct sock *sk, if (xp->selector.dport) xp->selector.dport_mask = ~0; + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; + if (sec_ctx != NULL) { + if (security_xfrm_policy_alloc(xp, sec_ctx)) + goto out; + } + xp->lft.soft_byte_limit = XFRM_INF; xp->lft.hard_byte_limit = XFRM_INF; xp->lft.soft_packet_limit = XFRM_INF; @@ -1963,6 +2052,7 @@ static int pfkey_spdadd(struct sock *sk, return 0; out: + security_xfrm_policy_free(xp); kfree(xp); return err; } @@ -1972,10 +2062,11 @@ static int pfkey_spddelete(struct sock * int err; struct sadb_address *sa; struct sadb_x_policy *pol; - struct xfrm_policy *xp; + struct xfrm_policy *xp, tmp; struct sk_buff *out_skb; struct sadb_msg *out_hdr; struct xfrm_selector sel; + struct sadb_x_sec_ctx *sec_ctx; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -2004,7 +2095,15 @@ static int pfkey_spddelete(struct sock * if (sel.dport) sel.dport_mask = ~0; - xp = xfrm_policy_bysel(pol->sadb_x_policy_dir-1, &sel, 1); + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; + memcpy(&tmp.selector, &sel, sizeof(struct xfrm_selector)); + if (sec_ctx != NULL) { + if (security_xfrm_policy_alloc(&tmp, sec_ctx)) + goto out; + } + + xp = xfrm_policy_bysel(pol->sadb_x_policy_dir-1, &tmp.selector, 1); + security_xfrm_policy_free(&tmp); if (xp == NULL) return -ENOENT; @@ -2482,6 +2581,7 @@ static struct xfrm_policy *pfkey_compile { struct xfrm_policy *xp; struct sadb_x_policy *pol = (struct sadb_x_policy*)data; + struct sadb_x_sec_ctx *sec_ctx; switch (family) { case AF_INET: @@ -2531,10 +2631,21 @@ static struct xfrm_policy *pfkey_compile (*dir = parse_ipsecrequests(xp, pol)) < 0) goto out; + /* security context too */ + if (len >= (pol->sadb_x_policy_len*8 + + sizeof(struct sadb_x_sec_ctx))) { + char *p = (char *) pol; + p += pol->sadb_x_policy_len*8; + sec_ctx = (struct sadb_x_sec_ctx *) p; + if (security_xfrm_policy_alloc(xp, sec_ctx)) + goto out; + } + *dir = pol->sadb_x_policy_dir-1; return xp; out: + security_xfrm_policy_free(xp); kfree(xp); return NULL; } diff -puN net/xfrm/xfrm_policy.c~lsm-xfrm-nethooks net/xfrm/xfrm_policy.c --- linux-2.6.12-rc4-nethooks/net/xfrm/xfrm_policy.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/xfrm/xfrm_policy.c 2005-05-16 16:16:54.000000000 -0400 @@ -257,6 +257,7 @@ void __xfrm_policy_destroy(struct xfrm_p if (del_timer(&policy->timer)) BUG(); + security_xfrm_policy_free(policy); kfree(policy); } EXPORT_SYMBOL(__xfrm_policy_destroy); @@ -396,7 +397,8 @@ struct xfrm_policy *xfrm_policy_bysel(in write_lock_bh(&xfrm_policy_lock); for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL; p = &pol->next) { - if (memcmp(sel, &pol->selector, sizeof(*sel)) == 0) { + if ((memcmp(sel, &pol->selector, xfrm_selector_base_size()) == 0) && + (xfrm_sec_ctx_match(sel->security, xfrm_policy_security(pol)))) { xfrm_pol_hold(pol); if (delete) *p = pol->next; @@ -492,7 +494,7 @@ EXPORT_SYMBOL(xfrm_policy_walk); /* Find policy to apply to this flow. */ -static void xfrm_policy_lookup(struct flowi *fl, u16 family, u8 dir, +static void xfrm_policy_lookup(struct flowi *fl, struct sock *sk, u16 family, u8 dir, void **objp, atomic_t **obj_refp) { struct xfrm_policy *pol; @@ -506,9 +508,12 @@ static void xfrm_policy_lookup(struct fl continue; match = xfrm_selector_match(sel, fl, family); + if (match) { - xfrm_pol_hold(pol); - break; + if (!security_xfrm_policy_lookup(sk, sel, fl, dir)) { + xfrm_pol_hold(pol); + break; + } } } read_unlock_bh(&xfrm_policy_lock); @@ -516,15 +521,38 @@ static void xfrm_policy_lookup(struct fl *obj_refp = &pol->refcnt; } +static inline int policy_to_flow_dir(int dir) +{ + if (XFRM_POLICY_IN == FLOW_DIR_IN && + XFRM_POLICY_OUT == FLOW_DIR_OUT && + XFRM_POLICY_FWD == FLOW_DIR_FWD) + return dir; + switch (dir) { + default: + case XFRM_POLICY_IN: + return FLOW_DIR_IN; + case XFRM_POLICY_OUT: + return FLOW_DIR_OUT; + case XFRM_POLICY_FWD: + return FLOW_DIR_FWD; + }; +} + static struct xfrm_policy *xfrm_sk_policy_lookup(struct sock *sk, int dir, struct flowi *fl) { struct xfrm_policy *pol; read_lock_bh(&xfrm_policy_lock); if ((pol = sk->sk_policy[dir]) != NULL) { - int match = xfrm_selector_match(&pol->selector, fl, + struct xfrm_selector *sel = &pol->selector; + int match = xfrm_selector_match(sel, fl, sk->sk_family); + int err = 0; + if (match) + err = security_xfrm_policy_lookup(sk, sel, fl, policy_to_flow_dir(dir)); + + if (match && !err) xfrm_pol_hold(pol); else pol = NULL; @@ -595,6 +623,10 @@ static struct xfrm_policy *clone_policy( if (newp) { newp->selector = old->selector; + if (security_xfrm_policy_clone(old, newp)) { + kfree(newp); + return (struct xfrm_policy *)NULL; /* ENOMEM */ + } newp->lft = old->lft; newp->curlft = old->curlft; newp->action = old->action; @@ -706,22 +738,6 @@ xfrm_bundle_create(struct xfrm_policy *p return err; } -static inline int policy_to_flow_dir(int dir) -{ - if (XFRM_POLICY_IN == FLOW_DIR_IN && - XFRM_POLICY_OUT == FLOW_DIR_OUT && - XFRM_POLICY_FWD == FLOW_DIR_FWD) - return dir; - switch (dir) { - default: - case XFRM_POLICY_IN: - return FLOW_DIR_IN; - case XFRM_POLICY_OUT: - return FLOW_DIR_OUT; - case XFRM_POLICY_FWD: - return FLOW_DIR_FWD; - }; -} static int stale_bundle(struct dst_entry *dst); @@ -751,7 +767,7 @@ restart: if ((dst_orig->flags & DST_NOXFRM) || !xfrm_policy_list[XFRM_POLICY_OUT]) return 0; - policy = flow_cache_lookup(fl, family, + policy = flow_cache_lookup(fl, sk, family, policy_to_flow_dir(XFRM_POLICY_OUT), xfrm_policy_lookup); } @@ -942,7 +958,7 @@ int __xfrm_policy_check(struct sock *sk, int i; for (i=skb->sp->len-1; i>=0; i--) { - struct sec_decap_state *xvec = &(skb->sp->x[i]); + struct sec_decap_state *xvec = &(skb->sp->x[i]); if (!xfrm_selector_match(&xvec->xvec->sel, &fl, family)) return 0; @@ -960,7 +976,7 @@ int __xfrm_policy_check(struct sock *sk, pol = xfrm_sk_policy_lookup(sk, dir, &fl); if (!pol) - pol = flow_cache_lookup(&fl, family, + pol = flow_cache_lookup(&fl, sk, family, policy_to_flow_dir(dir), xfrm_policy_lookup); diff -puN net/xfrm/xfrm_state.c~lsm-xfrm-nethooks net/xfrm/xfrm_state.c --- linux-2.6.12-rc4-nethooks/net/xfrm/xfrm_state.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/xfrm/xfrm_state.c 2005-05-16 15:49:41.000000000 -0400 @@ -74,6 +74,7 @@ static void xfrm_state_gc_destroy(struct x->type->destructor(x); xfrm_put_type(x->type); } + security_xfrm_state_free(x); kfree(x); } @@ -338,7 +339,8 @@ xfrm_state_find(xfrm_address_t *daddr, x selector. */ if (x->km.state == XFRM_STATE_VALID) { - if (!xfrm_selector_match(&x->sel, fl, family)) + if (!xfrm_selector_match(&x->sel, fl, family) || + !xfrm_sec_ctx_match(xfrm_policy_security(pol), xfrm_state_security(x))) continue; if (!best || best->km.dying > x->km.dying || @@ -349,7 +351,8 @@ xfrm_state_find(xfrm_address_t *daddr, x acquire_in_progress = 1; } else if (x->km.state == XFRM_STATE_ERROR || x->km.state == XFRM_STATE_EXPIRED) { - if (xfrm_selector_match(&x->sel, fl, family)) + if (xfrm_selector_match(&x->sel, fl, family) && + xfrm_sec_ctx_match(xfrm_policy_security(pol), xfrm_state_security(x))) error = -ESRCH; } } @@ -374,6 +377,13 @@ xfrm_state_find(xfrm_address_t *daddr, x xfrm_init_tempsel(x, fl, tmpl, daddr, saddr, family); if (km_query(x, tmpl, pol) == 0) { + if (!xfrm_sec_ctx_match(xfrm_policy_security(pol), xfrm_state_security(x))) { + x->km.state = XFRM_STATE_DEAD; + xfrm_state_put(x); + x = NULL; + error = 1; + goto out; + } x->km.state = XFRM_STATE_ACQ; list_add_tail(&x->bydst, xfrm_state_bydst+h); xfrm_state_hold(x); diff -puN net/xfrm/xfrm_user.c~lsm-xfrm-nethooks net/xfrm/xfrm_user.c --- linux-2.6.12-rc4-nethooks/net/xfrm/xfrm_user.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/net/xfrm/xfrm_user.c 2005-05-16 16:20:27.000000000 -0400 @@ -200,6 +200,32 @@ static int attach_encap_tmpl(struct xfrm return 0; } + +static inline int xfrm_user_sec_ctx_size(struct xfrm_policy *xp) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); + int len; + + if (xfrm_ctx) { + len = sizeof(struct xfrm_user_sec_ctx); + len += xfrm_ctx->ctx_len; + return len; + } + return 0; +} + +static int attach_sec_ctx(struct xfrm_state *x, struct rtattr *u_arg) +{ + struct xfrm_user_sec_ctx *uxsc = RTA_DATA(u_arg); + + if (uxsc) { + security_xfrm_state_free(x); + return security_xfrm_state_alloc(x, uxsc); + } + + return 0; +} + static void copy_from_user_state(struct xfrm_state *x, struct xfrm_usersa_info *p) { memcpy(&x->id, &p->id, sizeof(x->id)); @@ -249,6 +275,9 @@ static struct xfrm_state *xfrm_state_con if (err) goto error; + if ((err = attach_sec_ctx(x, xfrma[XFRMA_SEC_CTX-1]))) + goto error; + x->curlft.add_time = (unsigned long) xtime.tv_sec; x->km.state = XFRM_STATE_VALID; x->km.seq = p->seq; @@ -335,6 +364,27 @@ struct xfrm_dump_info { int this_idx; }; +static int dump_one_sec_ctx(struct xfrm_sec_ctx *ctx, struct xfrm_user_sec_ctx *uctx, struct sk_buff *skb, int ctx_size) +{ + if (!ctx) + return -1; + + uctx->exttype = XFRMA_SEC_CTX; + uctx->len = ctx_size; + uctx->ctx_doi = ctx->ctx_doi; + uctx->ctx_alg = ctx->ctx_alg; + uctx->ctx_len = ctx->ctx_len; + + memcpy(uctx + 1, ctx->ctx_str, ctx->ctx_len); + + RTA_PUT(skb, XFRMA_SEC_CTX, ctx_size, uctx); + + return 0; + +rtattr_failure: + return -1; +} + static int dump_one_state(struct xfrm_state *x, int count, void *ptr) { struct xfrm_dump_info *sp = ptr; @@ -343,6 +393,7 @@ static int dump_one_state(struct xfrm_st struct xfrm_usersa_info *p; struct nlmsghdr *nlh; unsigned char *b = skb->tail; + struct xfrm_sec_ctx *xfrm_ctx; if (sp->this_idx < sp->start_idx) goto out; @@ -367,6 +418,18 @@ static int dump_one_state(struct xfrm_st if (x->encap) RTA_PUT(skb, XFRMA_ENCAP, sizeof(*x->encap), x->encap); + if ((xfrm_ctx = xfrm_state_security(x))) { + int ctx_size = sizeof(struct xfrm_user_sec_ctx) + + xfrm_ctx->ctx_len + 1; + struct xfrm_user_sec_ctx *uctx = kmalloc(ctx_size, GFP_KERNEL); + int err; + + err = dump_one_sec_ctx(xfrm_ctx, uctx, skb, ctx_size); + kfree(uctx); + + if (err < 0) + goto rtattr_failure; + } nlh->nlmsg_len = skb->tail - b; out: sp->this_idx++; @@ -580,6 +643,27 @@ static int verify_newpolicy_info(struct return verify_policy_dir(p->dir); } +static int copy_sec_ctx(struct xfrm_policy *pol, struct xfrm_user_sec_ctx *uctx) +{ + int err = 0; + + security_xfrm_policy_free(pol); + err = security_xfrm_policy_alloc(pol, uctx); + return err; +} + +static int copy_from_user_sec_ctx(struct xfrm_policy *pol, struct rtattr **xfrma) +{ + struct rtattr *rt = xfrma[XFRMA_SEC_CTX-1]; + struct xfrm_user_sec_ctx *uctx = RTA_DATA(rt); + + if (uctx) { + copy_sec_ctx(pol, uctx); + } + + return 0; +} + static void copy_templates(struct xfrm_policy *xp, struct xfrm_user_tmpl *ut, int nr) { @@ -658,7 +742,10 @@ static struct xfrm_policy *xfrm_policy_c } copy_from_user_policy(xp, p); - err = copy_from_user_tmpl(xp, xfrma); + + if (!(err = copy_from_user_tmpl(xp, xfrma))) + err = copy_from_user_sec_ctx(xp, xfrma); + if (err) { *errp = err; kfree(xp); @@ -728,6 +815,27 @@ rtattr_failure: return -1; } +static int copy_to_user_sec_ctx(struct xfrm_policy *xp, struct sk_buff *skb, int src) +{ + int err = 0; + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); + + if (xfrm_ctx) { + int ctx_size = sizeof(struct xfrm_user_sec_ctx) + + xfrm_ctx->ctx_len; + struct xfrm_user_sec_ctx *uctx = kmalloc(ctx_size, GFP_KERNEL); + + if (!uctx) + return -ENOMEM; + + err = dump_one_sec_ctx(xfrm_ctx, uctx, skb, + ctx_size); + kfree(uctx); + } + + return err; +} + static int dump_one_policy(struct xfrm_policy *xp, int dir, int count, void *ptr) { struct xfrm_dump_info *sp = ptr; @@ -749,6 +857,8 @@ static int dump_one_policy(struct xfrm_p copy_to_user_policy(xp, p, dir); if (copy_to_user_tmpl(xp, skb) < 0) goto nlmsg_failure; + if (copy_to_user_sec_ctx(xp, skb, 0) < 0) + goto nlmsg_failure; nlh->nlmsg_len = skb->tail - b; out: @@ -804,7 +914,7 @@ static struct sk_buff *xfrm_policy_netli static int xfrm_get_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { - struct xfrm_policy *xp; + struct xfrm_policy *xp, tmp; struct xfrm_userpolicy_id *p; int err; int delete; @@ -818,8 +928,20 @@ static int xfrm_get_policy(struct sk_buf if (p->index) xp = xfrm_policy_byid(p->dir, p->index, delete); - else - xp = xfrm_policy_bysel(p->dir, &p->sel, delete); + else { + struct rtattr **rtattrs = (struct rtattr **) xfrma; + struct rtattr *rt = rtattrs[XFRMA_SEC_CTX-1]; + + memcpy(&tmp.selector, &p->sel, sizeof(struct xfrm_selector)); + if (rt) { + struct xfrm_user_sec_ctx *uxsc = RTA_DATA(rt); + + if ((err = security_xfrm_policy_alloc(&tmp, uxsc))) + return err; + } + xp = xfrm_policy_bysel(p->dir, &tmp.selector, delete); + security_xfrm_policy_free(&tmp); + } if (xp == NULL) return -ENOENT; @@ -1101,6 +1223,8 @@ static int build_acquire(struct sk_buff if (copy_to_user_tmpl(xp, skb) < 0) goto nlmsg_failure; + if (copy_to_user_sec_ctx(xp, skb, 1) < 0) + goto nlmsg_failure; nlh->nlmsg_len = skb->tail - b; return skb->len; @@ -1114,10 +1238,12 @@ static int xfrm_send_acquire(struct xfrm struct xfrm_policy *xp, int dir) { struct sk_buff *skb; + struct xfrm_sec_ctx *ctx; size_t len; len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); len += NLMSG_SPACE(sizeof(struct xfrm_user_acquire)); + len += xfrm_user_sec_ctx_size(xp); skb = alloc_skb(len, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; @@ -1138,8 +1264,9 @@ static struct xfrm_policy *xfrm_compile_ { struct xfrm_userpolicy_info *p = (struct xfrm_userpolicy_info *)data; struct xfrm_user_tmpl *ut = (struct xfrm_user_tmpl *) (p + 1); + struct xfrm_user_sec_ctx *uctx; struct xfrm_policy *xp; - int nr; + int nr = 0; switch (family) { case AF_INET: @@ -1167,9 +1294,26 @@ static struct xfrm_policy *xfrm_compile_ verify_newpolicy_info(p)) return NULL; + if (len > (sizeof(*p) + (XFRM_MAX_DEPTH * + sizeof(struct xfrm_user_tmpl)))) { + struct xfrm_user_tmpl *tmpl; + uctx = (struct xfrm_user_sec_ctx *) (ut + XFRM_MAX_DEPTH); + + if (len != sizeof(*p) + + (XFRM_MAX_DEPTH * sizeof(struct xfrm_user_tmpl)) + + uctx->len) + return NULL; + + /* spi must be zero'd unless real tmpl */ + for (tmpl = ut; tmpl->id.spi != 0; tmpl = tmpl + 1) + nr++; + } + else { + uctx = (struct xfrm_user_sec_ctx *) NULL; nr = ((len - sizeof(*p)) / sizeof(*ut)); if (nr > XFRM_MAX_DEPTH) return NULL; + } xp = xfrm_policy_alloc(GFP_KERNEL); if (xp == NULL) { @@ -1179,6 +1323,8 @@ static struct xfrm_policy *xfrm_compile_ copy_from_user_policy(xp, p); copy_templates(xp, ut, nr); + if (uctx) + copy_sec_ctx(xp, uctx); *dir = p->dir; @@ -1199,6 +1345,8 @@ static int build_polexpire(struct sk_buf copy_to_user_policy(xp, &upe->pol, dir); if (copy_to_user_tmpl(xp, skb) < 0) goto nlmsg_failure; + if (copy_to_user_sec_ctx(xp, skb, 2) < 0) + goto nlmsg_failure; upe->hard = !!hard; nlh->nlmsg_len = skb->tail - b; @@ -1216,6 +1364,7 @@ static int xfrm_send_policy_notify(struc len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); len += NLMSG_SPACE(sizeof(struct xfrm_user_polexpire)); + len += xfrm_user_sec_ctx_size(xp); skb = alloc_skb(len, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; diff -puN security/dummy.c~lsm-xfrm-nethooks security/dummy.c --- linux-2.6.12-rc4-nethooks/security/dummy.c~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/security/dummy.c 2005-05-10 15:40:22.000000000 -0400 @@ -811,6 +811,35 @@ static inline void dummy_sk_free_securit } #endif /* CONFIG_SECURITY_NETWORK */ +#ifdef CONFIG_SECURITY_NETWORK_XFRM +static int dummy_xfrm_policy_alloc_security(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx) +{ + return 0; +} + +static inline int dummy_xfrm_policy_clone_security(struct xfrm_policy *old, struct xfrm_policy *new) +{ + return 0; +} + +static void dummy_xfrm_policy_free_security(struct xfrm_policy *xp) +{ +} + +static int dummy_xfrm_state_alloc_security(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx) +{ + return 0; +} + +static void dummy_xfrm_state_free_security(struct xfrm_state *x) +{ +} + +static int dummy_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir) +{ + return 0; +} +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ static int dummy_register_security (const char *name, struct security_operations *ops) { return -EINVAL; @@ -992,5 +1021,13 @@ void security_fixup_ops (struct security set_to_dummy_if_null(ops, sk_alloc_security); set_to_dummy_if_null(ops, sk_free_security); #endif /* CONFIG_SECURITY_NETWORK */ +#ifdef CONFIG_SECURITY_NETWORK_XFRM + set_to_dummy_if_null(ops, xfrm_policy_alloc_security); + set_to_dummy_if_null(ops, xfrm_policy_clone_security); + set_to_dummy_if_null(ops, xfrm_policy_free_security); + set_to_dummy_if_null(ops, xfrm_state_alloc_security); + set_to_dummy_if_null(ops, xfrm_state_free_security); + set_to_dummy_if_null(ops, xfrm_policy_lookup); +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ } diff -puN security/Kconfig~lsm-xfrm-nethooks security/Kconfig --- linux-2.6.12-rc4-nethooks/security/Kconfig~lsm-xfrm-nethooks 2005-05-10 15:04:25.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/security/Kconfig 2005-05-10 15:28:44.000000000 -0400 @@ -53,6 +53,19 @@ config SECURITY_NETWORK implement socket and networking access controls. If you are unsure how to answer this question, answer N. +config SECURITY_NETWORK_XFRM + bool "XFRM (IPSec) Networking Security Hooks" + depends on XFRM && SECURITY_NETWORK + help + This enables the XFRM (IPSec) networking security hooks. + If enabled, a security module can use these hooks to + implement per-packet access controls based on labels + derived from IPSec policy. Non-IPSec communications are + designated as unlabelled, and only sockets authorized + to communicate unlabelled data can send without using + IPSec. + If you are unsure how to answer this question, answer N. + config SECURITY_CAPABILITIES tristate "Default Linux Capabilities" depends on SECURITY _ From jaegert@us.ibm.com Tue May 17 14:32:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 14:32:17 -0700 (PDT) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HLW9F3007442 for ; Tue, 17 May 2005 14:32:10 -0700 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j4HLWdNe026178; Tue, 17 May 2005 17:32:39 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j4HLVPs53030; Tue, 17 May 2005 17:31:25 -0400 Received: from [9.2.18.177] (dyn9002018177.watson.ibm.com [9.2.18.177]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j4HLVNH47210; Tue, 17 May 2005 17:31:24 -0400 Subject: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks From: jaegert To: netdev@oss.sgi.com, chrisw@osdl.org Cc: jaegert@us.ibm.com, serue@us.ibm.com, latten@austin.ibm.com, sds@tycho.nsa.gov, jmorris@redhat.com Content-Type: text/plain Message-Id: <1116361671.5560.125.camel@dyn9002018177.watson.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 17 May 2005 16:27:51 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4HLW9F3007442 X-archive-position: 1252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaegert@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 18034 Lines: 601 This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. --- security/selinux/Makefile | 2 security/selinux/hooks.c | 20 + security/selinux/include/nethooks.h | 8 security/selinux/nethooks.c | 428 ++++++++++++++++++++++++++++++++++++ 4 files changed, 457 insertions(+), 1 deletion(-) diff -puN security/selinux/hooks.c~lsm-selinux-nethooks security/selinux/hooks.c --- linux-2.6.12-rc4-nethooks/security/selinux/hooks.c~lsm-selinux-nethooks 2005-05-13 13:15:47.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/security/selinux/hooks.c 2005-05-13 13:15:47.000000000 -0400 @@ -72,6 +72,7 @@ #include "avc.h" #include "objsec.h" #include "netif.h" +#include "nethooks.h" #define XATTR_SELINUX_SUFFIX "selinux" #define XATTR_NAME_SELINUX XATTR_SECURITY_PREFIX XATTR_SELINUX_SUFFIX @@ -3350,6 +3351,10 @@ static int selinux_socket_sock_rcv_skb(s err = avc_has_perm(sock_sid, port_sid, sock_class, recv_perm, &ad); } + + if (!err) + err = selinux_xfrm_sock_rcv_skb(sock_sid, skb); + out: return err; } @@ -3537,6 +3542,11 @@ static unsigned int selinux_ip_postroute send_perm, &ad) ? NF_DROP : NF_ACCEPT; } + if (err != NF_ACCEPT) + goto out; + + err = selinux_xfrm_postroute_last(isec->sid, skb); + out: return err; } @@ -4389,6 +4399,15 @@ static struct security_operations selinu .sk_alloc_security = selinux_sk_alloc_security, .sk_free_security = selinux_sk_free_security, #endif + +#ifdef CONFIG_SECURITY_NETWORK_XFRM + .xfrm_policy_alloc_security = selinux_xfrm_policy_alloc, + .xfrm_policy_clone_security = selinux_xfrm_policy_clone, + .xfrm_policy_free_security = selinux_xfrm_policy_free, + .xfrm_state_alloc_security = selinux_xfrm_state_alloc, + .xfrm_state_free_security = selinux_xfrm_state_free, + .xfrm_policy_lookup = selinux_xfrm_policy_lookup, +#endif }; static __init int selinux_init(void) @@ -4499,6 +4518,7 @@ static int __init selinux_nf_ip_init(voi panic("SELinux: nf_register_hook for IPv6: error %d\n", err); #endif /* IPV6 */ + out: return err; } diff -puN /dev/null security/selinux/include/nethooks.h --- /dev/null 2004-02-23 16:02:56.000000000 -0500 +++ linux-2.6.12-rc4-nethooks-root/security/selinux/include/nethooks.h 2005-05-13 13:15:47.000000000 -0400 @@ -0,0 +1,8 @@ +int selinux_xfrm_policy_alloc(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx); +int selinux_xfrm_policy_clone(struct xfrm_policy *old, struct xfrm_policy *new); +void selinux_xfrm_policy_free(struct xfrm_policy *xp); +int selinux_xfrm_state_alloc(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx); +void selinux_xfrm_state_free(struct xfrm_state *x); +int selinux_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir); +int selinux_xfrm_sock_rcv_skb(u32 sid, struct sk_buff *skb); +int selinux_xfrm_postroute_last(u32 isec_sid, struct sk_buff *skb); diff -puN security/selinux/Makefile~lsm-selinux-nethooks security/selinux/Makefile --- linux-2.6.12-rc4-nethooks/security/selinux/Makefile~lsm-selinux-nethooks 2005-05-13 13:15:47.000000000 -0400 +++ linux-2.6.12-rc4-nethooks-root/security/selinux/Makefile 2005-05-13 13:15:47.000000000 -0400 @@ -4,7 +4,7 @@ obj-$(CONFIG_SECURITY_SELINUX) := selinux.o ss/ -selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o +selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o nethooks.o selinux-$(CONFIG_SECURITY_NETWORK) += netif.o diff -puN /dev/null security/selinux/nethooks.c --- /dev/null 2004-02-23 16:02:56.000000000 -0500 +++ linux-2.6.12-rc4-nethooks-root/security/selinux/nethooks.c 2005-05-16 14:28:25.000000000 -0400 @@ -0,0 +1,428 @@ +/* + * USAGE: + * NOTES: + * 1. Make sure to enable the following options in your kernel config: + * CONFIG_SECURITY=y + * CONFIG_SECURITY_NETWORK=y + * CONFIG_SECURITY_NETWORK_XFRM=y + * CONFIG_SECURITY_SELINUX=m/y + * ISSUES: + * 1. Caching packets, so they are not dropped during negotiation + * 2. Emulating a reasonable SO_PEERSEC across machines + * 3. Testing sk_policy setting with context + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "nethooks.h" +#include "avc.h" +#include "objsec.h" + +/************************************************************** + * + * defines + * + **************************************************************/ + +#define DEBUG 0 + +/************************************************************** + * + * structures + * + **************************************************************/ + +/************************************************************** + * + * globals + * + **************************************************************/ + +/************************************************************** + * + * macros/inlines + * + **************************************************************/ + +#define nethooks_debug(fmt, args...) {if (DEBUG) printk(KERN_NOTICE fmt,## args);} + +/* + * Extract the security blob from the sock (it's actually on the socket) + */ +static inline struct inode_security_struct *get_sock_isec(struct sock *sk) +{ + if (!sk->sk_socket) { + nethooks_debug("%s: no socket on this sock (!?)\n", + __FUNCTION__); + return (struct inode_security_struct *) NULL; + } + + return SOCK_INODE(sk->sk_socket)->i_security; +} + +/* + * Returns true if the xfrm contains a security blob for SELinux + */ +static inline int selinux_authorizable_xfrm(struct xfrm_state *x) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_state_security(x); + + return (xfrm_ctx && + (xfrm_ctx->ctx_doi == XFRM_SC_DOI_LSM) && + (xfrm_ctx->ctx_alg == XFRM_SC_ALG_SELINUX)); +} + +/************************************************************** + * + * LSM + * + **************************************************************/ +#ifdef CONFIG_SECURITY_NETWORK_XFRM +/* + * LSM hook implementation that authorizes that a socket can be used + * with the corresponding xfrm_policy selector and direction. + */ + +int selinux_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir) +{ + int rc = 0; + struct inode_security_struct *isec = NULL; + u32 sock_sid, sel_sid = SECINITSID_UNLABELED; + + nethooks_debug("%s: authorize\n", __FUNCTION__); + + if (!sk) { + /* no sock to send -- e.g., icmp reply */ + /* authorize as kernel packet */ + if (fl && fl->proto == IPPROTO_ICMP) { + nethooks_debug("%s: ICMP case\n", + __FUNCTION__); + sock_sid = SECINITSID_KERNEL; + goto authorize; + } + /* + * hooks.c accepts packets with no socket unconditionally + */ + nethooks_debug("%s: no sock on this skbuff: non-ICMP\n", + __FUNCTION__); + goto out; + } + + read_lock_bh(&sk->sk_callback_lock); + isec = get_sock_isec(sk); + + /* No isec: allow if any sock can read target */ + if (!isec) { + nethooks_debug("%s: no isec from sock\n", __FUNCTION__); + sock_sid = SECINITSID_ANY_SOCKET; + } + else { + sock_sid = isec->sid; + } + read_unlock_bh(&sk->sk_callback_lock); + + +authorize: + /* Selector sid is either set to label or ANY_ASSOC */ + if (sel->security) { + sel_sid = sel->security->ctx_sid; + nethooks_debug("%s: %s for context %.50s; sid: %d; sock: %d\n", + __FUNCTION__, + ((dir == FLOW_DIR_IN) ? "input" : + ((dir == FLOW_DIR_OUT) ? "output" : "forward")), + sel->security->ctx_str, + sel_sid, + sock_sid); + } + + rc = avc_has_perm(sock_sid, sel_sid, SECCLASS_ASSOCIATION, + ((dir == FLOW_DIR_IN) ? ASSOCIATION__RECVFROM : + ((dir == FLOW_DIR_OUT) ? ASSOCIATION__SENDTO : + (ASSOCIATION__SENDTO | ASSOCIATION__RECVFROM))), + NULL); + +out: + return rc; +} + +/* + * Security blob allocation for xfrm_policy and xfrm_state + * -- both attached to selectors + */ +static inline int selinux_xfrm_selector_alloc(struct xfrm_selector *sel, struct sadb_x_sec_ctx *sec_ctx) +{ + int rc = 0; + + if (!sec_ctx) + return -EINVAL; + + nethooks_debug(KERN_NOTICE "%s: got a sec_ctx for policy\n", + __FUNCTION__); + + if (sec_ctx->sadb_x_ctx_len >= PAGE_SIZE) + return -ENOMEM; + + sel->security = kmalloc(sizeof(*sel->security) + + sec_ctx->sadb_x_ctx_len + 1, + GFP_KERNEL); + + if (!sel->security) + return -ENOMEM; + + sel->security->ctx_doi = sec_ctx->sadb_x_ctx_doi; + sel->security->ctx_len = sec_ctx->sadb_x_ctx_len; + sel->security->ctx_alg = sec_ctx->sadb_x_ctx_alg; + + nethooks_debug(KERN_NOTICE "%s: doi %u len %u alg %u\n", + __FUNCTION__, + sel->security->ctx_doi, + sel->security->ctx_len, + sel->security->ctx_alg); + + memcpy(sel->security->ctx_str, + sec_ctx+1, + sel->security->ctx_len); + rc = security_context_to_sid(sel->security->ctx_str, + sel->security->ctx_len, + &sel->security->ctx_sid); + sel->security->ctx_str[sel->security->ctx_len] = 0; + + nethooks_debug(KERN_NOTICE "%s: context was %s with sid %d\n", + __FUNCTION__, + sel->security->ctx_str, + sel->security->ctx_sid); + + if (rc) + kfree(sel->security); + + return rc; +} + +/* + * LSM hook implementation that allocs and transfers sec_ctx spec to + * xfrm_policy. + */ +int selinux_xfrm_policy_alloc(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx) +{ + int rc = 0; + + if (!xp) + return -EINVAL; + + nethooks_debug(KERN_NOTICE "%s: start alloc\n", __FUNCTION__); + + rc = selinux_xfrm_selector_alloc(&xp->selector, sec_ctx); + + return rc; +} + + +/* + * LSM hook implementation that copies security data structure from old to + * new for policy cloning. + */ +int selinux_xfrm_policy_clone(struct xfrm_policy *old, struct xfrm_policy *new) +{ + struct xfrm_sec_ctx *old_ctx, *new_ctx; + + old_ctx = xfrm_policy_security(old); + + if (old_ctx) { + new_ctx = new->selector.security = + kmalloc(sizeof(*new_ctx) + + old_ctx->ctx_len + 1, + GFP_KERNEL); + + if (!new_ctx) + return -ENOMEM; + + memcpy(new_ctx, old_ctx, sizeof(*new_ctx)); + memcpy(new_ctx->ctx_str, old_ctx->ctx_str, new_ctx->ctx_len); + } + return 0; +} + +/* + * LSM hook implementation that frees xfrm_policy security information. + */ +void selinux_xfrm_policy_free(struct xfrm_policy *xp) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); + + if (xfrm_ctx) + kfree(xfrm_ctx); +} + +/* + * LSM hook implementation that allocs and transfers sec_ctx spec to + * xfrm_state. + */ +int selinux_xfrm_state_alloc(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx) +{ + int rc = 0; + + if (!x) + return -EINVAL; + + nethooks_debug(KERN_NOTICE "%s: start alloc\n", __FUNCTION__); + + rc = selinux_xfrm_selector_alloc(&x->sel, sec_ctx); + + return rc; +} + +/* + * LSM hook implementation that frees xfrm_state security information. + */ +void selinux_xfrm_state_free(struct xfrm_state *x) +{ + struct xfrm_sec_ctx *xfrm_ctx = xfrm_state_security(x); + + if (xfrm_ctx) + kfree(xfrm_ctx); +} + +/* + * LSM hook that controls access to unlabelled packets. If + * a xfrm_state is authorizable (defined by macro) then it was + * already authorized by selector matching process. If not, then + * we need to check for unlabelled access since this may not have + * gone thru the selector process. + */ +int selinux_xfrm_sock_rcv_skb(u32 isec_sid, struct sk_buff *skb) +{ + int i, rc = 0; + struct sec_path *sp; + struct sock *sk; + + nethooks_debug("%s: starting\n", __FUNCTION__); + + /* regular check for socket with isec */ + sp = skb->sp; + sk = skb->sk; + + if (sp) { + nethooks_debug("%s: sp (0x%x) on skb with length %d\n", + __FUNCTION__, + (unsigned) sp, sp->len); + + /* + * __xfrm_policy_check does not approve unless xfrm_policy_ok + * says that spi's match for policy and the socket. + * + * Only need to verify the existence of an authorizable sp. + */ + for (i = 0; i < sp->len; i++) { + struct xfrm_state *x = sp->x[i].xvec; + + nethooks_debug("%s: sa: 0x%x\n", + __FUNCTION__, + (unsigned) x); + + if (selinux_authorizable_xfrm(x)) { + nethooks_debug("%s: sa 0x%x found\n", + __FUNCTION__, + (unsigned) x); + goto accept; + } + } + } + + /* check SELinux sock for unlabelled access */ + nethooks_debug("%s: before unlabelled sa auth: isec_sid = 0x%x\n", + __FUNCTION__, + (unsigned) isec_sid); + rc = avc_has_perm(isec_sid, SECINITSID_UNLABELED, SECCLASS_ASSOCIATION, + ASSOCIATION__RECVFROM, NULL); + nethooks_debug("%s: after unlabelled sa auth rc: %d\n", + __FUNCTION__, + rc); + + if (rc) + goto drop; + +accept: + nethooks_debug("%s: accept\n", __FUNCTION__); + return 0; + +drop: + nethooks_debug("%s: drop\n", __FUNCTION__); + return rc; +} + +/* + * POSTROUTE_LAST hook's XFRM processing: + * If we have no security association, then we need to determine + * whether the socket is allowed to send to an unlabelled destination. + * If we do have a authorizable security association, then it has already been + * checked in xfrm_policy_lookup hook. + */ +int selinux_xfrm_postroute_last(u32 isec_sid, struct sk_buff *skb) +{ + struct dst_entry *dst; + int rc = 0; + + dst = skb->dst; + + if (dst) { + struct dst_entry *dst_test; + + for (dst_test = dst; dst_test != 0; + dst_test = dst_test->child) { + struct xfrm_state *x = dst_test->xfrm; + + if (selinux_authorizable_xfrm(x)) { + nethooks_debug("%s: sa 0x%x found\n", + __FUNCTION__, + (unsigned) x); + goto accept; + } + } + } + + nethooks_debug("%s: before unlabelled sa auth: isec_sid = 0x%x\n", + __FUNCTION__, + (unsigned) isec_sid); + rc = avc_has_perm(isec_sid, SECINITSID_UNLABELED, SECCLASS_ASSOCIATION, + ASSOCIATION__SENDTO, NULL); + nethooks_debug("%s: after unlabelled sa auth rc: %d\n", __FUNCTION__, rc); + + if (rc) + goto drop; + +accept: + nethooks_debug("%s: accept\n", __FUNCTION__); + return NF_ACCEPT; + +drop: + nethooks_debug("%s: drop\n", __FUNCTION__); + return NF_DROP; +} + +#else /* CONFIG_SECURITY_NETWORK_XFRM */ + +int selinux_xfrm_sock_rcv_skb(u32 isec_sid, struct sk_buff *skb) +{ + return 0; +} + +int selinux_xfrm_postroute_last(u32 isec_sid, struct sk_buff *skb) +{ + return 0; +} +#endif /* CONFIG_SECURITY_NETWORK_XFRM */ _ From akepner@sgi.com Tue May 17 15:09:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 15:09:33 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HM9PF3009889; Tue, 17 May 2005 15:09:25 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4HM8nxT016154; Tue, 17 May 2005 17:08:50 -0500 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4HM8m3d26913500; Tue, 17 May 2005 15:08:48 -0700 (PDT) Date: Tue, 17 May 2005 15:06:40 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Rick Jones cc: netdev@oss.sgi.com, netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly In-Reply-To: <428A613F.1020303@hp.com> Message-ID: References: <20050517.132202.59028935.davem@davemloft.net> <20050517202730.GA79960@muc.de> <20050517.140245.71090021.davem@davemloft.net> <428A613F.1020303@hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 552 Lines: 16 On Tue, 17 May 2005, Rick Jones wrote: > .... > or an added heuristic of "if have reassembled N datagrams for the same > source/dest/protocol tuple with ID's "larger" than 'this one' since it has > arrived, we are probably going to wrap so might as well drop 'this one'" for > some judicious and magical selection of N that may be a decent predictor of > wrap on top of some existing reassembly timout. > .... How do you define "larger" in this case? A sender is free to choose any ID - they can't be assumed to be montonic, for sure. -- Arthur From davem@davemloft.net Tue May 17 15:13:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 15:13:26 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HMDFF3010877; Tue, 17 May 2005 15:13:15 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYAIp-0001xI-No; Tue, 17 May 2005 15:12:39 -0700 Date: Tue, 17 May 2005 15:12:39 -0700 (PDT) Message-Id: <20050517.151239.74747463.davem@davemloft.net> To: rick.jones2@hp.com Cc: netdev@oss.sgi.com, netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: <428A613F.1020303@hp.com> References: <20050517202730.GA79960@muc.de> <20050517.140245.71090021.davem@davemloft.net> <428A613F.1020303@hp.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 647 Lines: 15 From: Rick Jones Date: Tue, 17 May 2005 14:25:19 -0700 > just how much extra overhead would there be to track the interarrival time of ip > datagram fragments and would that allow someone to make a guess as to how long > to reasonably wait for all the fragments to arrive? (or did I miss that being > shot-down already?) I spam you with fragments tightly interspaced matching a known shost/dhost/ID tuple, lowering your interarrival estimate. The legitimate fragment source can thus never get his fragments in before the timer expires. Every other one of these IP fragmentation ideas tends to have some DoS hole in it. From herbert@gondor.apana.org.au Tue May 17 15:12:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 15:12:15 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HMC7F3010410 for ; Tue, 17 May 2005 15:12:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYAHH-00047p-00; Wed, 18 May 2005 08:11:03 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYAHF-0006qW-00; Wed, 18 May 2005 08:11:01 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Cc: akepner@sgi.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050517.104947.112621738.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 18 May 2005 08:11:01 +1000 X-archive-position: 1254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 718 Lines: 19 David S. Miller wrote: > > Decreasing ipfrag_time is also not an option, because then Here is a possible solution to this: Instead of measuring the distance using time, let's measure it in terms of packet counts. So every time we receive a fragmented packet, we find all waiting fragments with the same src/dst pair. If the id is identical we perform reassembly, if it isn't we increase a counter in that fragment. If the counter exceeds a threshold, we drop the fragment. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Tue May 17 15:14:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 15:14:39 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HMEaF3011526 for ; Tue, 17 May 2005 15:14:36 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYAK0-0001xi-S9; Tue, 17 May 2005 15:13:52 -0700 Date: Tue, 17 May 2005 15:13:52 -0700 (PDT) Message-Id: <20050517.151352.41634495.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: References: <20050517.104947.112621738.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 519 Lines: 11 From: Herbert Xu Date: Wed, 18 May 2005 08:11:01 +1000 > Instead of measuring the distance using time, let's measure it > in terms of packet counts. So every time we receive a fragmented > packet, we find all waiting fragments with the same src/dst pair. > If the id is identical we perform reassembly, if it isn't we increase > a counter in that fragment. If the counter exceeds a threshold, > we drop the fragment. And you protect against purposefully built malicious fragments how? From rick.jones2@hp.com Tue May 17 15:18:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 15:19:12 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HMIxF3012441; Tue, 17 May 2005 15:18:59 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id D33071C04E19; Tue, 17 May 2005 15:18:23 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA01307; Tue, 17 May 2005 15:18:23 -0700 (PDT) Message-ID: <428A6DAF.7040600@hp.com> Date: Tue, 17 May 2005 15:18:23 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.132202.59028935.davem@davemloft.net> <20050517202730.GA79960@muc.de> <20050517.140245.71090021.davem@davemloft.net> <428A613F.1020303@hp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1671 Lines: 36 Arthur Kepner wrote: > On Tue, 17 May 2005, Rick Jones wrote: > > >>.... >>or an added heuristic of "if have reassembled N datagrams for the same >>source/dest/protocol tuple with ID's "larger" than 'this one' since it has >>arrived, we are probably going to wrap so might as well drop 'this one'" for >>some judicious and magical selection of N that may be a decent predictor of >>wrap on top of some existing reassembly timout. >>.... > > > How do you define "larger" in this case? A sender is free to choose > any ID - they can't be assumed to be montonic, for sure. Actually, I was ass-u-me-ing they would be monotonic, but thinking about it more, that doesn't really matter. If N datagrams from that source/dest/prot tuple have been reassembled since the first/current frag of this datagam has arrived, chances are still good that the rest of the fragments of this datagram are toast and any subsequent fragments with a matching src/dst/prot/id would likely create a frankengram. in broad handwaving terms, those N other datagrams (non-fragmented or fragmented and successfully reassembled or not I suspect) are a measure of just how far "out of order" the rest of the fragments of this datagram happen to be. for some degree of "out of orderness" we can ass-u-me the datagram is toast. chosing a strawman, if we've received 24000 datagrams from that source/dest/prot (perhaps even just that source) since we've started reassembling this datagram from that source/dest/prot, chances seem pretty good indeed that this datagram is toast. a value of N even smaller than 24000 might suffice. the devil seems to be in the accounting. rick jones From rick.jones2@hp.com Tue May 17 15:24:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 15:24:40 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HMOXF3013105; Tue, 17 May 2005 15:24:33 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 24DE33433; Tue, 17 May 2005 15:23:50 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA01357; Tue, 17 May 2005 15:23:49 -0700 (PDT) Message-ID: <428A6EF5.9080509@hp.com> Date: Tue, 17 May 2005 15:23:49 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: netdev-bounce@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517202730.GA79960@muc.de> <20050517.140245.71090021.davem@davemloft.net> <428A613F.1020303@hp.com> <20050517.151239.74747463.davem@davemloft.net> In-Reply-To: <20050517.151239.74747463.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 853 Lines: 23 David S.Miller wrote: > From: Rick Jones > Date: Tue, 17 May 2005 14:25:19 -0700 > > >>just how much extra overhead would there be to track the interarrival time of ip >>datagram fragments and would that allow someone to make a guess as to how long >>to reasonably wait for all the fragments to arrive? (or did I miss that being >>shot-down already?) > > > I spam you with fragments tightly interspaced matching a known > shost/dhost/ID tuple, lowering your interarrival estimate. The > legitimate fragment source can thus never get his fragments in > before the timer expires. > > Every other one of these IP fragmentation ideas tends to have > some DoS hole in it. Are the holes any larger than the existing ones? I've no idea, and perhaps the only answer is indeed to say "Then don't do that (fragment)!" rick jones From dlstevens@us.ibm.com Tue May 17 15:41:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 15:41:11 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HMf1F3014299 for ; Tue, 17 May 2005 15:41:07 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4HMeQua534610 for ; Tue, 17 May 2005 18:40:26 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4HMeQnP169682 for ; Tue, 17 May 2005 16:40:26 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4HMePqW002451 for ; Tue, 17 May 2005 16:40:25 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4HMePn3002448; Tue, 17 May 2005 16:40:25 -0600 In-Reply-To: <428A6DAF.7040600@hp.com> To: Rick Jones Cc: netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Tue, 17 May 2005 15:40:23 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 05/17/2005 16:40:25, Serialize complete at 05/17/2005 16:40:25 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 1259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1860 Lines: 41 > in broad handwaving terms, those N other datagrams (non-fragmented or fragmented > and successfully reassembled or not I suspect) are a measure of just how far > "out of order" the rest of the fragments of this datagram happen to be. for > some degree of "out of orderness" we can ass-u-me the datagram is toast. > chosing a strawman, if we've received 24000 datagrams from that source/dest/prot > (perhaps even just that source) since we've started reassembling this datagram > from that source/dest/prot, chances seem pretty good indeed that this datagram > is toast. a value of N even smaller than 24000 might suffice. > the devil seems to be in the accounting. This assumes that you have a per-destination IP ID. If it's per-route, you can send 1 packet to host A, 65534 to host B through the same route, and 1 to host A-- wrap on the next received packet, as far as host A is concerned. (even sooner, if it's using randomized ID's or a bigger-than-1 increment). Since it's the other side, which need not be Linux, I think assumptions about how ID's are generated open the possibility of breaking something that works now. I think an estimator for the interarrival time of fragments for the same packet, per destination, is what you really want here. The problem is path changes can cause the timeout to change dramatically, and you don't want something too short to cause you to drop packets when there was no wrap. But if it's a conservative estimate, it beats accidental corruption. I can do DoS or intentional corruption if I can generate a fragment as soon as I know the ID (by guessing, or by getting my fragment in after I've seen the the first one sent), so I'm not sure that can be fixed, except by using IPsec, if it concerns you. :-) +-DLS From herbert@gondor.apana.org.au Tue May 17 16:09:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:09:25 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HN9IF3016199 for ; Tue, 17 May 2005 16:09:19 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYBAx-0004i1-00; Wed, 18 May 2005 09:08:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYBAv-0006vT-00; Wed, 18 May 2005 09:08:33 +1000 Date: Wed, 18 May 2005 09:08:33 +1000 To: "David S. Miller" Cc: akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050517230833.GA26604@gondor.apana.org.au> References: <20050517.104947.112621738.davem@davemloft.net> <20050517.151352.41634495.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517.151352.41634495.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 858 Lines: 19 On Tue, May 17, 2005 at 03:13:52PM -0700, David S. Miller wrote: > From: Herbert Xu > Date: Wed, 18 May 2005 08:11:01 +1000 > > > Instead of measuring the distance using time, let's measure it > > in terms of packet counts. So every time we receive a fragmented > > packet, we find all waiting fragments with the same src/dst pair. > > If the id is identical we perform reassembly, if it isn't we increase > > a counter in that fragment. If the counter exceeds a threshold, > > we drop the fragment. > > And you protect against purposefully built malicious fragments how? Is it any worse than what we've got now? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue May 17 16:12:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:12:59 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HNCsF3017013 for ; Tue, 17 May 2005 16:12:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYBEG-0004kw-00; Wed, 18 May 2005 09:12:04 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYBED-0006wa-00; Wed, 18 May 2005 09:11:57 +1000 From: Herbert Xu To: dlstevens@us.ibm.com (David Stevens) Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Cc: rick.jones2@hp.com, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 18 May 2005 09:11:57 +1000 X-archive-position: 1261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1060 Lines: 26 David Stevens wrote: > > This assumes that you have a per-destination IP ID. If it's > per-route, > you can send 1 packet to host A, 65534 to host B through the same route, > and > 1 to host A-- wrap on the next received packet, as far as host A is > concerned. > (even sooner, if it's using randomized ID's or a bigger-than-1 increment). Such systems would be violating the spirit of RFC791 which says: The identification field is used to distinguish the fragments of one datagram from those of another. The originating protocol module of an internet datagram sets the identification field to a value that must be unique for that source-destination pair and protocol for the time the datagram will be active in the internet system. Are you aware of any extant systems that do this? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Tue May 17 16:17:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:17:59 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HNHuF3017818 for ; Tue, 17 May 2005 16:17:56 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYBIo-0000np-5i; Tue, 17 May 2005 16:16:42 -0700 Date: Tue, 17 May 2005 16:16:41 -0700 (PDT) Message-Id: <20050517.161641.74747565.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: <20050517230833.GA26604@gondor.apana.org.au> References: <20050517.151352.41634495.davem@davemloft.net> <20050517230833.GA26604@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 512 Lines: 12 From: Herbert Xu Date: Wed, 18 May 2005 09:08:33 +1000 > On Tue, May 17, 2005 at 03:13:52PM -0700, David S. Miller wrote: > > And you protect against purposefully built malicious fragments how? > > Is it any worse than what we've got now? Good point, in both cases what ends up happening is that the queue is invalidated. In the existing case it's usually because the final UDP or whatever checksum doesn't pass. With your idea it'd be due to the artificially deflated timeout. From akepner@sgi.com Tue May 17 16:22:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:22:50 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HNMlF3022052 for ; Tue, 17 May 2005 16:22:47 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4HNMBxT029256 for ; Tue, 17 May 2005 18:22:11 -0500 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4HNMA3d17912260; Tue, 17 May 2005 16:22:10 -0700 (PDT) Date: Tue, 17 May 2005 16:20:07 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Herbert Xu cc: dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 652 Lines: 20 On Wed, 18 May 2005, Herbert Xu wrote: > .... > Such systems would be violating the spirit of RFC791 which says: > > The identification field is used to distinguish the fragments of one > datagram from those of another. The originating protocol module of > an internet datagram sets the identification field to a value that > must be unique for that source-destination pair and protocol for the > time the datagram will be active in the internet system. > > Are you aware of any extant systems that do this? > .... Are you aware of any (new) systems that _don't_ violate this? I wouldn't want to own one of them! -- Arthur From herbert@gondor.apana.org.au Tue May 17 16:26:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:27:03 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HNQtF3022663 for ; Tue, 17 May 2005 16:26:56 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYBRn-0004tM-00; Wed, 18 May 2005 09:25:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYBRk-0006zP-00; Wed, 18 May 2005 09:25:56 +1000 Date: Wed, 18 May 2005 09:25:56 +1000 To: Arthur Kepner Cc: dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050517232556.GA26846@gondor.apana.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1246 Lines: 31 On Tue, May 17, 2005 at 04:20:07PM -0700, Arthur Kepner wrote: > On Wed, 18 May 2005, Herbert Xu wrote: > > > .... > > Such systems would be violating the spirit of RFC791 which says: > > > > The identification field is used to distinguish the fragments of one > > datagram from those of another. The originating protocol module of > > an internet datagram sets the identification field to a value that > > must be unique for that source-destination pair and protocol for the > > time the datagram will be active in the internet system. > > > > Are you aware of any extant systems that do this? > > .... > > Are you aware of any (new) systems that _don't_ violate this? I > wouldn't want to own one of them! Perhaps you misunderstood what I was saying. I meant are there any extant systems that would transmit 1 set of fragments to host A with id x, then 65535 packets host B, and then wrap around and send a new set of fragments to host A with idx. Linux will never do this thanks to inetpeer.c. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue May 17 16:29:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:29:45 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HNTeF3023310 for ; Tue, 17 May 2005 16:29:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYBUJ-0004ug-00; Wed, 18 May 2005 09:28:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYBUC-000704-00; Wed, 18 May 2005 09:28:28 +1000 Date: Wed, 18 May 2005 09:28:28 +1000 To: "David S. Miller" Cc: akepner@sgi.com, netdev@oss.sgi.com, Alexey Kuznetsov , Patrick McHardy Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050517232828.GA26894@gondor.apana.org.au> References: <20050517.151352.41634495.davem@davemloft.net> <20050517230833.GA26604@gondor.apana.org.au> <20050517.161641.74747565.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517.161641.74747565.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 783 Lines: 19 On Tue, May 17, 2005 at 04:16:41PM -0700, David S. Miller wrote: > > Good point, in both cases what ends up happening is that > the queue is invalidated. In the existing case it's usually > because the final UDP or whatever checksum doesn't pass. > With your idea it'd be due to the artificially deflated timeout. It just occured to me that the optimisation in IPv4/IPv6 that performs fragmentation after tunnel-mode IPsec is fundamentally broken. It makes IPsec vulnerable to fragmentation attacks. We have to perform fragmentation before tunnel-mode IPsec. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Tue May 17 16:37:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:37:58 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HNbsF3024304 for ; Tue, 17 May 2005 16:37:55 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DYBcF-0001cr-Fh; Wed, 18 May 2005 01:36:47 +0200 Message-ID: <428A800F.6040809@trash.net> Date: Wed, 18 May 2005 01:36:47 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , akepner@sgi.com, netdev@oss.sgi.com, Alexey Kuznetsov Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.151352.41634495.davem@davemloft.net> <20050517230833.GA26604@gondor.apana.org.au> <20050517.161641.74747565.davem@davemloft.net> <20050517232828.GA26894@gondor.apana.org.au> In-Reply-To: <20050517232828.GA26894@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 664 Lines: 18 Herbert Xu wrote: > On Tue, May 17, 2005 at 04:16:41PM -0700, David S. Miller wrote: > >>Good point, in both cases what ends up happening is that >>the queue is invalidated. In the existing case it's usually >>because the final UDP or whatever checksum doesn't pass. >>With your idea it'd be due to the artificially deflated timeout. > > > It just occured to me that the optimisation in IPv4/IPv6 that performs > fragmentation after tunnel-mode IPsec is fundamentally broken. It > makes IPsec vulnerable to fragmentation attacks. You mean vulnerable at reassembly time? Isn't that something reassembly and policy checks should take care of? Regards Patrick From herbert@gondor.apana.org.au Tue May 17 16:43:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:43:19 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HNh9F3025087 for ; Tue, 17 May 2005 16:43:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYBhJ-00053W-00; Wed, 18 May 2005 09:42:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYBhG-00071v-00; Wed, 18 May 2005 09:41:58 +1000 Date: Wed, 18 May 2005 09:41:58 +1000 To: Patrick McHardy Cc: "David S. Miller" , akepner@sgi.com, netdev@oss.sgi.com, Alexey Kuznetsov Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050517234158.GA27006@gondor.apana.org.au> References: <20050517.151352.41634495.davem@davemloft.net> <20050517230833.GA26604@gondor.apana.org.au> <20050517.161641.74747565.davem@davemloft.net> <20050517232828.GA26894@gondor.apana.org.au> <428A800F.6040809@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428A800F.6040809@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 784 Lines: 21 On Wed, May 18, 2005 at 01:36:47AM +0200, Patrick McHardy wrote: > > You mean vulnerable at reassembly time? Isn't that something reassembly > and policy checks should take care of? I mean that it's vulnerable to the following simple DoS attack by someone who doesn't otherwise have the capability to drop the packets between the source and the target. If the IPsec packets arrive as fragments, the attacker only needs to guess the identity to cause the entire IPsec packet to be dropped. If it was fragmented prior to IPsec it would not be vulnerable to this. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From rick.jones2@hp.com Tue May 17 16:54:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:54:17 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HNsEF3026030 for ; Tue, 17 May 2005 16:54:15 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id 985EE1C0510C for ; Tue, 17 May 2005 16:53:39 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id QAA02562 for ; Tue, 17 May 2005 16:53:39 -0700 (PDT) Message-ID: <428A8403.7000901@hp.com> Date: Tue, 17 May 2005 16:53:39 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 998 Lines: 20 David Stevens wrote: > > This assumes that you have a per-destination IP ID. If it's per-route, you > can send 1 packet to host A, 65534 to host B through the same route, and 1 to > host A-- wrap on the next received packet, as far as host A is concerned. > (even sooner, if it's using randomized ID's or a bigger-than-1 increment). If we were actually looking at the ID's themselves, rather than the count of datagrams received that would be correct, but someone already pointed-out that ass-u-me-ing monotonic increasing was not a good thing, so simply count datagrams completed/recevied on that source/dest pair instead. Then we don't really care about the sender's IP ID assignment policy. If someone wants to hit that with a DoS attack, I'm still wondering if that is a large DoS hole, (larger than existing ones with spoofing fragments) and the extent to which it depends on whether the attacker is closer to me than the sender or "on the other side" of the sender from me. rick jones From dlstevens@us.ibm.com Tue May 17 16:55:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 16:56:05 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4HNtwF3026393 for ; Tue, 17 May 2005 16:55:58 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4HNtMLK588176 for ; Tue, 17 May 2005 19:55:22 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4HNtMnP136742 for ; Tue, 17 May 2005 17:55:22 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4HNtMm5024804 for ; Tue, 17 May 2005 17:55:22 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4HNtMMB024796; Tue, 17 May 2005 17:55:22 -0600 In-Reply-To: <20050517232556.GA26846@gondor.apana.org.au> To: Herbert Xu Cc: Arthur Kepner , netdev@oss.sgi.com, rick.jones2@hp.com MIME-Version: 1.0 Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Tue, 17 May 2005 16:55:20 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 05/17/2005 17:55:21, Serialize complete at 05/17/2005 17:55:21 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 1269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1010 Lines: 22 BSD systems, and derivatives, at least 20 years ago, had a single, global IP ID for all destinations. The requirement was that at least a single src-dest pair should be unique, which didn't prohibit all IP ID's generated by the system from being unique. And BSD systems generated an ID for every IP packet, not just frags, if memory serves. IP ID wrap wasn't the concern, obviously, since those two pieces make a wrap on any one destination more likely-- a wrap is for all packets sent, not just on one interface or to one destination. Some later systems use randomization of IP ID to make it harder to inject data into fragments by guessing the ID, which means the entire IP ID space isn't necessarily consumed before a "wrap" in the pseudo-random sequence (thus, may happen even sooner than a simple increment). I don't know if any recent, common systems use a per-host global IP ID, but yes, almost every host did 15-20 years ago (and after RFC 791 :-) ). +-DLS From herbert@gondor.apana.org.au Tue May 17 17:01:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 17:01:51 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I01hF3027452 for ; Tue, 17 May 2005 17:01:44 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYBzU-0005Cv-00; Wed, 18 May 2005 10:00:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYBzS-00073u-00; Wed, 18 May 2005 10:00:46 +1000 Date: Wed, 18 May 2005 10:00:46 +1000 To: David Stevens Cc: Arthur Kepner , netdev@oss.sgi.com, rick.jones2@hp.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518000046.GA27123@gondor.apana.org.au> References: <20050517232556.GA26846@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 517 Lines: 13 On Tue, May 17, 2005 at 04:55:20PM -0700, David Stevens wrote: > > I don't know if any recent, common systems use a per-host global > IP ID, but yes, almost every host did 15-20 years ago > (and after RFC 791 :-) ). Unless these dinosaurs have evolved enough to support gigabit then it's not a problem :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ak@muc.de Tue May 17 17:04:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 17:04:59 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I04oF3028085 for ; Tue, 17 May 2005 17:04:51 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id B626FD033F; Wed, 18 May 2005 02:04:14 +0200 (CEST) To: Herbert Xu Cc: dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517232556.GA26846@gondor.apana.org.au> From: Andi Kleen Date: Wed, 18 May 2005 02:04:14 +0200 In-Reply-To: <20050517232556.GA26846@gondor.apana.org.au> (Herbert Xu's message of "Wed, 18 May 2005 09:25:56 +1000") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 475 Lines: 13 Herbert Xu writes: > > Perhaps you misunderstood what I was saying. I meant are there any > extant systems that would transmit 1 set of fragments to host A with > id x, then 65535 packets host B, and then wrap around and send a new > set of fragments to host A with idx. > > Linux will never do this thanks to inetpeer.c. It will, you just need enough other hosts to thrash inetpeer. How many you need depends on your available memory. -Andi From niv@us.ibm.com Tue May 17 17:07:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 17:07:42 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I07dF3028665 for ; Tue, 17 May 2005 17:07:39 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4I06xIk019027 for ; Tue, 17 May 2005 20:06:59 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4I06wNJ118124 for ; Tue, 17 May 2005 20:06:58 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4I06wF0001754 for ; Tue, 17 May 2005 20:06:58 -0400 Received: from [127.0.0.1] (sig-9-65-13-25.mts.ibm.com [9.65.13.25]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4I06tHu001575; Tue, 17 May 2005 20:06:57 -0400 Message-ID: <428A871F.1000308@us.ibm.com> Date: Tue, 17 May 2005 17:06:55 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: Arthur Kepner , dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517232556.GA26846@gondor.apana.org.au> In-Reply-To: <20050517232556.GA26846@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1292 Lines: 38 Herbert Xu wrote: >>>Such systems would be violating the spirit of RFC791 which says: >>> >>> The identification field is used to distinguish the fragments of one >>> datagram from those of another. The originating protocol module of >>> an internet datagram sets the identification field to a value that >>> must be unique for that source-destination pair and protocol for the >>> time the datagram will be active in the internet system. >>> >>>Are you aware of any extant systems that do this? >>>.... >> >>Are you aware of any (new) systems that _don't_ violate this? I >>wouldn't want to own one of them! > > > Perhaps you misunderstood what I was saying. I meant are there any > extant systems that would transmit 1 set of fragments to host A with > id x, then 65535 packets host B, and then wrap around and send a new > set of fragments to host A with idx. > > Linux will never do this thanks to inetpeer.c. Actually, it depends on which Linux you are using. Mainline linux certainly has this (per-inetpeer ip_id) - but at least one distro did not (use inetpeer) :). Not sure what the current situation is. Of course, if all the traffic is on the same connection (which isn't out of the ordinary) would still come down to the same thing... thanks, Nivedita From herbert@gondor.apana.org.au Tue May 17 17:10:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 17:11:04 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I0AuF3029242 for ; Tue, 17 May 2005 17:10:57 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYC8K-0005KX-00; Wed, 18 May 2005 10:09:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYC8J-00075Z-00; Wed, 18 May 2005 10:09:55 +1000 Date: Wed, 18 May 2005 10:09:55 +1000 To: Andi Kleen Cc: dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518000955.GA27212@gondor.apana.org.au> References: <20050517232556.GA26846@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 906 Lines: 22 On Wed, May 18, 2005 at 02:04:14AM +0200, Andi Kleen wrote: > Herbert Xu writes: > > > > Perhaps you misunderstood what I was saying. I meant are there any > > extant systems that would transmit 1 set of fragments to host A with > > id x, then 65535 packets host B, and then wrap around and send a new > > set of fragments to host A with idx. > > > > Linux will never do this thanks to inetpeer.c. > > It will, you just need enough other hosts to thrash inetpeer. How many > you need depends on your available memory. Even when the cache entry is deleted, Linux will allocate an ID randomly so the chance of what was stated above occuring is very small. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue May 17 17:11:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 17:11:50 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I0BjF3029325 for ; Tue, 17 May 2005 17:11:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYC9I-0005Kr-00; Wed, 18 May 2005 10:10:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYC9G-000765-00; Wed, 18 May 2005 10:10:54 +1000 Date: Wed, 18 May 2005 10:10:54 +1000 To: Nivedita Singhvi Cc: Arthur Kepner , dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518001054.GB27212@gondor.apana.org.au> References: <20050517232556.GA26846@gondor.apana.org.au> <428A871F.1000308@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428A871F.1000308@us.ibm.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 748 Lines: 21 On Tue, May 17, 2005 at 05:06:55PM -0700, Nivedita Singhvi wrote: > > Mainline linux certainly has this (per-inetpeer ip_id) - but > at least one distro did not (use inetpeer) :). Not sure > what the current situation is. What was the reason for this? Perhaps we can solve their problems with inetpeer in a better way than disabling it? > Of course, if all the traffic is on the same connection > (which isn't out of the ordinary) would still come down > to the same thing... Please see my proposal elsewhere in this thread. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Tue May 17 17:47:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 17:47:54 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I0loF3031593 for ; Tue, 17 May 2005 17:47:50 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 028A51C0EB; Wed, 18 May 2005 02:47:33 +0200 (CEST) Date: Wed, 18 May 2005 02:47:33 +0200 From: Thomas Graf To: Herbert Xu Cc: "David S. Miller" , akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518004733.GG13748@postel.suug.ch> References: <20050517.104947.112621738.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 1275 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 754 Lines: 14 * Herbert Xu 2005-05-18 08:11 > Instead of measuring the distance using time, let's measure it > in terms of packet counts. So every time we receive a fragmented > packet, we find all waiting fragments with the same src/dst pair. > If the id is identical we perform reassembly, if it isn't we increase > a counter in that fragment. If the counter exceeds a threshold, > we drop the fragment. I like this, although the problem is derived to the definition of the threshold. Any ideas on how to define this? A combination of your idea together with the idea I stated in another post which would additional expire fragments earlier depending on the actual packet (or fragment) rate might give better results. From davem@davemloft.net Tue May 17 17:52:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 17:52:47 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I0qiF3032174 for ; Tue, 17 May 2005 17:52:44 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYCmU-0000fx-Fi; Tue, 17 May 2005 17:51:26 -0700 Date: Tue, 17 May 2005 17:51:26 -0700 (PDT) Message-Id: <20050517.175126.74751342.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: niv@us.ibm.com, akepner@sgi.com, dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: <20050518001054.GB27212@gondor.apana.org.au> References: <20050517232556.GA26846@gondor.apana.org.au> <428A871F.1000308@us.ibm.com> <20050518001054.GB27212@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 781 Lines: 18 From: Herbert Xu Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Date: Wed, 18 May 2005 10:10:54 +1000 > On Tue, May 17, 2005 at 05:06:55PM -0700, Nivedita Singhvi wrote: > > > > Mainline linux certainly has this (per-inetpeer ip_id) - but > > at least one distro did not (use inetpeer) :). Not sure > > what the current situation is. > > What was the reason for this? Perhaps we can solve their problems > with inetpeer in a better way than disabling it? Andi Kleen thought inetpeer was a pig, so he removed it from SUSE's kernel and replaced it with a per-cpu salted IP ID generator. The initial verion he wrote had serious bugs that severely decreased the effective ID space, and thus made the NFS corruption problem happen more frequently. From davem@davemloft.net Tue May 17 17:53:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 17:53:29 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I0rPF3032391 for ; Tue, 17 May 2005 17:53:25 -0700 Received: from localhost ([127.0.0.1]) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYCng-0000gI-ML; Tue, 17 May 2005 17:52:40 -0700 Date: Tue, 17 May 2005 17:52:10 -0700 (PDT) Message-Id: <20050517.175210.41633462.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: ak@muc.de, dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly From: "David S. Miller" In-Reply-To: <20050518000955.GA27212@gondor.apana.org.au> References: <20050517232556.GA26846@gondor.apana.org.au> <20050518000955.GA27212@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 616 Lines: 14 From: Herbert Xu Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Date: Wed, 18 May 2005 10:09:55 +1000 > On Wed, May 18, 2005 at 02:04:14AM +0200, Andi Kleen wrote: > > Herbert Xu writes: > > It will, you just need enough other hosts to thrash inetpeer. How many > > you need depends on your available memory. > > Even when the cache entry is deleted, Linux will allocate an ID randomly > so the chance of what was stated above occuring is very small. Yes, that's right. Andi just doesn't like inetpeer, so let's just move along and accept that. :-) From ak@muc.de Tue May 17 18:05:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 18:05:49 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I15dF3001138 for ; Tue, 17 May 2005 18:05:39 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 6ADE6D033F; Wed, 18 May 2005 03:05:01 +0200 (CEST) To: "David S. Miller" Cc: niv@us.ibm.com, akepner@sgi.com, dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517232556.GA26846@gondor.apana.org.au> <428A871F.1000308@us.ibm.com> <20050518001054.GB27212@gondor.apana.org.au> <20050517.175126.74751342.davem@davemloft.net> From: Andi Kleen Date: Wed, 18 May 2005 03:05:01 +0200 In-Reply-To: <20050517.175126.74751342.davem@davemloft.net> (David S. Miller's message of "Tue, 17 May 2005 17:51:26 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1908 Lines: 43 "David S. Miller" writes: > From: Herbert Xu > Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly > Date: Wed, 18 May 2005 10:10:54 +1000 > >> On Tue, May 17, 2005 at 05:06:55PM -0700, Nivedita Singhvi wrote: >> > >> > Mainline linux certainly has this (per-inetpeer ip_id) - but >> > at least one distro did not (use inetpeer) :). Not sure >> > what the current situation is. >> >> What was the reason for this? Perhaps we can solve their problems >> with inetpeer in a better way than disabling it? > > Andi Kleen thought inetpeer was a pig, so he removed it from SUSE's > kernel and replaced it with a per-cpu salted IP ID generator. The > initial verion he wrote had serious bugs that severely decreased the > effective ID space, and thus made the NFS corruption problem happen > more frequently. That's not true, there were no bugs it in. Or at least none I know about. However any randomized IPID scheme decreases the effective IP-ID space slightly. The only algorithm that uses a bit space perfectly is a counter :) However I admit the constant to regulate the grainness was a bit too aggressive at the beginning, which indeed triggered the NFS corruption problem more frequently. However since the 16bit space is more or less useless (as Artur demonstrated it cannot even handle a single Gigabit link) it did not make that much difference anyways. The eventual workaround for the NFS IP-ID problem that went into the vendor kernel also did work in a different way on top of the algorithm. As for the background (not for you Dave, for other readers ;-) why I consider inetpeer useless please read the archives. As a hint just look what kind of functionality it implements and how much of it is actually enabled by default and think of its relationship to masquerading (which BTW breaks most of the fancy algorithms proposed so far) -Andi From akepner@sgi.com Tue May 17 18:08:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 18:09:06 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I18sF3001711 for ; Tue, 17 May 2005 18:08:54 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4I2qqpp021436 for ; Tue, 17 May 2005 19:52:52 -0700 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4I18H3d26964362; Tue, 17 May 2005 18:08:18 -0700 (PDT) Date: Tue, 17 May 2005 18:06:14 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Rick Jones , Herbert Xu cc: "David S. Miller" , Thomas Graf , netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly In-Reply-To: <20050518004733.GG13748@postel.suug.ch> Message-ID: References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 2267 Lines: 49 It sounds as if Herbert and Rick have much the same idea. And it sounds like a good idea, definitely worth considering... On Wed, 18 May 2005, Thomas Graf wrote: > * Herbert Xu 2005-05-18 08:11 > > Instead of measuring the distance using time, let's measure it > > in terms of packet counts. So every time we receive a fragmented > > packet, we find all waiting fragments with the same src/dst pair. > > If the id is identical we perform reassembly, if it isn't we increase > > a counter in that fragment. If the counter exceeds a threshold, > > we drop the fragment. > > I like this, although the problem is derived to the definition > of the threshold. Any ideas on how to define this? A > combination of your idea together with the idea I stated in > another post which would additional expire fragments earlier > depending on the actual packet (or fragment) rate might give > better results. > ------------------------------ [snip] ------------------------------ > On Tue, 17 May 2005, Rick Jones wrote: > ..... > Actually, I was ass-u-me-ing they would be monotonic, but thinking about > it more, that doesn't really matter. If N datagrams from that > source/dest/prot tuple have been reassembled since the first/current > frag of this datagam has arrived, chances are still good that the rest > of the fragments of this datagram are toast and any subsequent > fragments with a matching src/dst/prot/id would likely create a > frankengram. > > in broad handwaving terms, those N other datagrams (non-fragmented or > fragmented and successfully reassembled or not I suspect) are a measure > of just how far "out of order" the rest of the fragments of this > datagram happen to be. for some degree of "out of orderness" we can > ass-u-me the datagram is toast. > > chosing a strawman, if we've received 24000 datagrams from that > source/dest/prot (perhaps even just that source) since we've started > reassembling this datagram from that source/dest/prot, chances seem > pretty good indeed that this datagram is toast. a value of N even > smaller than 24000 might suffice. > > the devil seems to be in the accounting. ------------------------------ [snip] ------------------------------ From jheffner@psc.edu Tue May 17 18:09:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 18:10:00 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I19nF3001941 for ; Tue, 17 May 2005 18:09:50 -0700 Received: from [192.168.1.4] (ipl-67-013.pppoe.stargate.net [206.210.67.13]) (authenticated bits=0) by mailer1.psc.edu (8.13.3/8.13.3) with ESMTP id j4I191vu002903 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 17 May 2005 21:09:01 -0400 (EDT) In-Reply-To: <20050517232556.GA26846@gondor.apana.org.au> References: <20050517232556.GA26846@gondor.apana.org.au> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6afda9c168e2105c783eec268fc225b4@psc.edu> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, Arthur Kepner , dlstevens@us.ibm.com, rick.jones2@hp.com From: John Heffner Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Date: Tue, 17 May 2005 21:09:00 -0400 To: Herbert Xu X-Mailer: Apple Mail (2.622) X-archive-position: 1280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 586 Lines: 17 On May 17, 2005, at 7:25 PM, Herbert Xu wrote: > > Perhaps you misunderstood what I was saying. I meant are there any > extant systems that would transmit 1 set of fragments to host A with > id x, then 65535 packets host B, and then wrap around and send a new > set of fragments to host A with idx. > > Linux will never do this thanks to inetpeer.c. Of course (as usual) NATs break everything. ;-) There are also the ugly case where fragments could be delayed in the network for a period of time, for example during a path change, and show up at exactly the wrong time. -John From herbert@gondor.apana.org.au Tue May 17 18:14:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 18:14:27 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I1EDF3002901 for ; Tue, 17 May 2005 18:14:14 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYD7X-0005sF-00; Wed, 18 May 2005 11:13:11 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYD7U-0007EI-00; Wed, 18 May 2005 11:13:08 +1000 Date: Wed, 18 May 2005 11:13:08 +1000 To: "David S. Miller" Cc: niv@us.ibm.com, akepner@sgi.com, dlstevens@us.ibm.com, rick.jones2@hp.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518011308.GA27780@gondor.apana.org.au> References: <20050517232556.GA26846@gondor.apana.org.au> <428A871F.1000308@us.ibm.com> <20050518001054.GB27212@gondor.apana.org.au> <20050517.175126.74751342.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517.175126.74751342.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 667 Lines: 15 On Tue, May 17, 2005 at 05:51:26PM -0700, David S. Miller wrote: > > Andi Kleen thought inetpeer was a pig, so he removed it from SUSE's > kernel and replaced it with a per-cpu salted IP ID generator. The > initial verion he wrote had serious bugs that severely decreased the > effective ID space, and thus made the NFS corruption problem happen > more frequently. Is he turning off PMTU by default as well? :) I don't see how it can be a pig otherwise. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue May 17 18:17:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 18:17:31 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I1HKF3003355 for ; Tue, 17 May 2005 18:17:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYDAn-0005sr-00; Wed, 18 May 2005 11:16:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYDAm-0007F2-00; Wed, 18 May 2005 11:16:32 +1000 Date: Wed, 18 May 2005 11:16:32 +1000 To: Thomas Graf Cc: "David S. Miller" , akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518011632.GA27813@gondor.apana.org.au> References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518004733.GG13748@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 669 Lines: 18 On Wed, May 18, 2005 at 02:47:33AM +0200, Thomas Graf wrote: > > I like this, although the problem is derived to the definition > of the threshold. Any ideas on how to define this? A The threshold doesn't need to be very large at all since it is essentially the maximum reordering distance that we allow. However, for an initial estimate we can be conservative and use something like 30000. If we're too conservative the SGI guys will tell us :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Tue May 17 18:37:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 18:37:30 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I1bQF3004431 for ; Tue, 17 May 2005 18:37:26 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 6F4291C0EB; Wed, 18 May 2005 03:37:12 +0200 (CEST) Date: Wed, 18 May 2005 03:37:12 +0200 From: Thomas Graf To: Herbert Xu Cc: "David S. Miller" , akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518013712.GH13748@postel.suug.ch> References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> <20050518011632.GA27813@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518011632.GA27813@gondor.apana.org.au> X-archive-position: 1283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1029 Lines: 22 * Herbert Xu <20050518011632.GA27813@gondor.apana.org.au> 2005-05-18 11:16 > On Wed, May 18, 2005 at 02:47:33AM +0200, Thomas Graf wrote: > > > > I like this, although the problem is derived to the definition > > of the threshold. Any ideas on how to define this? A > > The threshold doesn't need to be very large at all since it is > essentially the maximum reordering distance that we allow. > > However, for an initial estimate we can be conservative and > use something like 30000. If we're too conservative the SGI > guys will tell us :) OK, I initially thought you would head for a much larger threshold. Not sure if 30000 is large enough for a full scale NFS server though ;-> You conviced me that my idea doesn't have any real advantage over yours, it essentialy gets down the same result but yours is probably easier to implement and we can also adopt the threshold dynamicaly depending on the type of system. A big advantage is surely that it is quite easy to tune this parameter for certain more difficult cases. From herbert@gondor.apana.org.au Tue May 17 18:53:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 18:53:20 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I1rCF3006013 for ; Tue, 17 May 2005 18:53:13 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYDjL-00062i-00; Wed, 18 May 2005 11:52:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYDjJ-0007KL-00; Wed, 18 May 2005 11:52:13 +1000 Date: Wed, 18 May 2005 11:52:13 +1000 To: Thomas Graf Cc: "David S. Miller" , akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518015213.GB28070@gondor.apana.org.au> References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> <20050518011632.GA27813@gondor.apana.org.au> <20050518013712.GH13748@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518013712.GH13748@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 579 Lines: 14 On Wed, May 18, 2005 at 03:37:12AM +0200, Thomas Graf wrote: > > OK, I initially thought you would head for a much larger > threshold. Not sure if 30000 is large enough for a full > scale NFS server though ;-> You conviced me that my idea I think it's big enough. If it isn't it means that somebody has reordered the packets by 30000 which I find hard to believe :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From christoph@graphe.net Tue May 17 18:56:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 18:56:47 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I1uhF3006948 for ; Tue, 17 May 2005 18:56:44 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DYDn4-0005Jo-2c; Tue, 17 May 2005 18:56:09 -0700 Date: Tue, 17 May 2005 18:56:06 -0700 (PDT) From: Christoph Lameter To: linux-kernel@vger.kernel.org cc: netdev@oss.sgi.com, akpm@osdl.org Subject: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@graphe.net Precedence: bulk X-list: netdev Content-Length: 4744 Lines: 127 NUMA awareness for the e1000 driver. Allocate transmit and receive buffers on the node of the device. Signed-off-by: Christoph Lameter Signed-off-by: Justin M. Forbes Signed-off-by: Shai Fultheim Index: linux-2.6.11/drivers/net/e1000/e1000_main.c =================================================================== --- linux-2.6.11.orig/drivers/net/e1000/e1000_main.c 2005-05-17 16:44:20.000000000 -0700 +++ linux-2.6.11/drivers/net/e1000/e1000_main.c 2005-05-17 17:47:43.000000000 -0700 @@ -120,8 +120,8 @@ int e1000_up(struct e1000_adapter *adapt void e1000_down(struct e1000_adapter *adapter); void e1000_reset(struct e1000_adapter *adapter); int e1000_set_spd_dplx(struct e1000_adapter *adapter, uint16_t spddplx); -int e1000_setup_tx_resources(struct e1000_adapter *adapter); -int e1000_setup_rx_resources(struct e1000_adapter *adapter); +int e1000_setup_tx_resources(struct e1000_adapter *adapter, int node); +int e1000_setup_rx_resources(struct e1000_adapter *adapter, int node); void e1000_free_tx_resources(struct e1000_adapter *adapter); void e1000_free_rx_resources(struct e1000_adapter *adapter); void e1000_update_stats(struct e1000_adapter *adapter); @@ -513,6 +513,7 @@ e1000_probe(struct pci_dev *pdev, netdev->mem_start = mmio_start; netdev->mem_end = mmio_start + mmio_len; netdev->base_addr = adapter->hw.io_base; + netdev->node = pcibus_to_node(pdev->bus); adapter->bd_number = cards_found; @@ -785,12 +786,12 @@ e1000_open(struct net_device *netdev) /* allocate transmit descriptors */ - if((err = e1000_setup_tx_resources(adapter))) + if((err = e1000_setup_tx_resources(adapter, netdev->node))) goto err_setup_tx; /* allocate receive descriptors */ - if((err = e1000_setup_rx_resources(adapter))) + if((err = e1000_setup_rx_resources(adapter, netdev->node))) goto err_setup_rx; if((err = e1000_up(adapter))) @@ -866,14 +867,14 @@ e1000_check_64k_bound(struct e1000_adapt **/ int -e1000_setup_tx_resources(struct e1000_adapter *adapter) +e1000_setup_tx_resources(struct e1000_adapter *adapter, int node) { struct e1000_desc_ring *txdr = &adapter->tx_ring; struct pci_dev *pdev = adapter->pdev; int size; size = sizeof(struct e1000_buffer) * txdr->count; - txdr->buffer_info = vmalloc(size); + txdr->buffer_info = kmalloc_node(size, GFP_KERNEL, node); if(!txdr->buffer_info) { DPRINTK(PROBE, ERR, "Unable to Allocate Memory for the Transmit descriptor ring\n"); @@ -891,7 +892,7 @@ e1000_setup_tx_resources(struct e1000_ad setup_tx_desc_die: DPRINTK(PROBE, ERR, "Unable to Allocate Memory for the Transmit descriptor ring\n"); - vfree(txdr->buffer_info); + kfree(txdr->buffer_info); return -ENOMEM; } @@ -1018,14 +1019,14 @@ e1000_configure_tx(struct e1000_adapter **/ int -e1000_setup_rx_resources(struct e1000_adapter *adapter) +e1000_setup_rx_resources(struct e1000_adapter *adapter, int node) { struct e1000_desc_ring *rxdr = &adapter->rx_ring; struct pci_dev *pdev = adapter->pdev; int size; size = sizeof(struct e1000_buffer) * rxdr->count; - rxdr->buffer_info = vmalloc(size); + rxdr->buffer_info = kmalloc_node(size, GFP_KERNEL, node); if(!rxdr->buffer_info) { DPRINTK(PROBE, ERR, "Unable to Allocate Memory for the Recieve descriptor ring\n"); @@ -1044,7 +1045,7 @@ e1000_setup_rx_resources(struct e1000_ad setup_rx_desc_die: DPRINTK(PROBE, ERR, "Unble to Allocate Memory for the Recieve descriptor ring\n"); - vfree(rxdr->buffer_info); + kfree(rxdr->buffer_info); return -ENOMEM; } @@ -1197,7 +1198,7 @@ e1000_free_tx_resources(struct e1000_ada e1000_clean_tx_ring(adapter); - vfree(adapter->tx_ring.buffer_info); + kfree(adapter->tx_ring.buffer_info); adapter->tx_ring.buffer_info = NULL; pci_free_consistent(pdev, adapter->tx_ring.size, @@ -1279,7 +1280,7 @@ e1000_free_rx_resources(struct e1000_ada e1000_clean_rx_ring(adapter); - vfree(rx_ring->buffer_info); + kfree(rx_ring->buffer_info); rx_ring->buffer_info = NULL; pci_free_consistent(pdev, rx_ring->size, rx_ring->desc, rx_ring->dma); Index: linux-2.6.11/include/linux/netdevice.h =================================================================== --- linux-2.6.11.orig/include/linux/netdevice.h 2005-05-17 16:44:20.000000000 -0700 +++ linux-2.6.11/include/linux/netdevice.h 2005-05-17 17:03:01.000000000 -0700 @@ -279,6 +279,7 @@ struct net_device unsigned long mem_start; /* shared mem start */ unsigned long base_addr; /* device I/O address */ unsigned int irq; /* device IRQ number */ + unsigned int node; /* device node number */ /* * Some hardware also needs these fields, but they are not From akpm@osdl.org Tue May 17 19:05:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 19:05:18 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I25FF3007644 for ; Tue, 17 May 2005 19:05:15 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4I24NU3021203 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 17 May 2005 19:04:23 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4I24N5i004310; Tue, 17 May 2005 19:04:23 -0700 Date: Tue, 17 May 2005 19:03:43 -0700 From: Andrew Morton To: Christoph Lameter Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 Message-Id: <20050517190343.2e57fdd7.akpm@osdl.org> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 325 Lines: 11 Christoph Lameter wrote: > > NUMA awareness for the e1000 driver. Allocate transmit and receive buffers > on the node of the device. Hast thou any benchmarking results? > - txdr->buffer_info = vmalloc(size); > + txdr->buffer_info = kmalloc_node(size, GFP_KERNEL, node); How come this is safe to do? From ak@muc.de Tue May 17 19:06:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 19:06:20 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I266F3007828 for ; Tue, 17 May 2005 19:06:06 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 0342BD033F; Wed, 18 May 2005 04:05:25 +0200 (CEST) To: Christoph Lameter Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 References: From: Andi Kleen Date: Wed, 18 May 2005 04:05:25 +0200 In-Reply-To: (Christoph Lameter's message of "Tue, 17 May 2005 18:56:06 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 629 Lines: 16 Christoph Lameter writes: > @@ -513,6 +513,7 @@ e1000_probe(struct pci_dev *pdev, > netdev->mem_start = mmio_start; > netdev->mem_end = mmio_start + mmio_len; > netdev->base_addr = adapter->hw.io_base; > + netdev->node = pcibus_to_node(pdev->bus); I think it would be better to define a common helper (pdev_kmalloc ?) for this that just takes the pdev and that can be defined to a nop for !CONFIG_NUMA Kernels. This would avoid the bloat of the ->node argument on non numa kernels and is a cleaner interface too. pcibus_to_node() is just an array lookup and should be cheap enough to redo. -Andi From davem@davemloft.net Tue May 17 19:24:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 19:24:58 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I2OqF3009308 for ; Tue, 17 May 2005 19:24:52 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYEEK-0000hC-PY for netdev@oss.sgi.com; Tue, 17 May 2005 19:24:16 -0700 Date: Tue, 17 May 2005 19:24:16 -0700 (PDT) Message-Id: <20050517.192416.108741581.davem@davemloft.net> To: netdev@oss.sgi.com Subject: [PATCH] Super TSO From: "David S. Miller" X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 37774 Lines: 1226 Ok, this implements the idea Herbert and I kicked around last week. Basically, we build as large TSO segments as humanly possible. Then we slice and dice them to fit the congestion and send windows at transmit time. It works remarkably well. Even application limited cases like "scp" behave nicely. During straight streaming tests like "bw_tcp", I see full "65535 MOD mss" sized frames going out to my onboard tg3 card once the congestion and send window grow large enough. I did some cross-continent (San Francisco --> east coast of US) transfers to make sure TSO stays on when packet drops occur and that performance doesn't suffer compared to TSO being off. It all looks fine so far. There were many bugs discovered along the way. For example, the old code would use the TSO mss to do nagle calculations. It also would mess up the packet sizing for TSO when SACK blocks were being advertised. So we don't have to calculate this "(65535 - headers) % mss" thing all the time, I keep a cache of three pieces of state. MSS, number of SACKS being advertized, and if TSO is enabled or not. If any of these change, we recalculate the packet building goal size. I moved all of the "should we send" logic privately into the file net/ipv4/tcp_output.c, and I am sure there are many simplifications possible. There are several spurious tcp_current_mss() calls scattered about in certain code paths as well. For example, some places would call it in order to decide whether to call tcp_write_xmit() or not, then tcp_write_xmit() does it once more. But there are call sites that do not do this, so tcp_write_xmit() has to do it for those cases. Comments? --- 1/include/linux/tcp.h.~1~ 2005-05-16 22:29:56.000000000 -0700 +++ 2/include/linux/tcp.h 2005-05-17 11:15:46.000000000 -0700 @@ -280,13 +280,15 @@ struct tcp_sock { __u32 snd_wnd; /* The window we expect to receive */ __u32 max_window; /* Maximal window ever seen from peer */ __u32 pmtu_cookie; /* Last pmtu seen by socket */ - __u32 mss_cache; /* Cached effective mss, not including SACKS */ - __u16 mss_cache_std; /* Like mss_cache, but without TSO */ + __u16 mss_cache; /* Cached effective mss, not including SACKS */ + __u16 xmit_size_goal; /* Goal for segmenting output packets */ + __u32 xmit_size_cache;/* Cache for keeping xmit_size_goal uptodate */ __u16 ext_header_len; /* Network protocol overhead (IP/IPv6 options) */ __u8 ca_state; /* State of fast-retransmit machine */ __u8 retransmits; /* Number of unrecovered RTO timeouts. */ __u16 advmss; /* Advertised MSS */ + __u16 __pad0; __u32 window_clamp; /* Maximal window to advertise */ __u32 rcv_ssthresh; /* Current window clamp */ --- 1/include/net/tcp.h.~1~ 2005-05-16 22:29:56.000000000 -0700 +++ 2/include/net/tcp.h 2005-05-17 16:44:32.000000000 -0700 @@ -817,11 +817,18 @@ static inline int tcp_ack_scheduled(stru return tp->ack.pending&TCP_ACK_SCHED; } -static __inline__ void tcp_dec_quickack_mode(struct tcp_sock *tp) +static __inline__ void tcp_dec_quickack_mode(struct tcp_sock *tp, unsigned int pkts) { - if (tp->ack.quick && --tp->ack.quick == 0) { - /* Leaving quickack mode we deflate ATO. */ - tp->ack.ato = TCP_ATO_MIN; + if (tp->ack.quick) { + if (pkts > tp->ack.quick) + tp->ack.quick = 0; + else + tp->ack.quick -= pkts; + + if (!tp->ack.quick) { + /* Leaving quickack mode we deflate ATO. */ + tp->ack.ato = TCP_ATO_MIN; + } } } @@ -939,7 +946,14 @@ extern __u32 cookie_v4_init_sequence(str /* tcp_output.c */ -extern int tcp_write_xmit(struct sock *, int nonagle); +extern void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb); +extern void __tcp_push_pending_frames(struct sock *sk, + struct tcp_sock *tp, + unsigned int cur_mss, + int nonagle); +extern int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp); +extern int tcp_tso_mince(struct sock *sk, struct tcp_sock *tp, + struct sk_buff *skb); extern int tcp_retransmit_skb(struct sock *, struct sk_buff *); extern void tcp_xmit_retransmit_queue(struct sock *); extern void tcp_simple_retransmit(struct sock *); @@ -951,7 +965,7 @@ extern int tcp_write_wakeup(struct sock extern void tcp_send_fin(struct sock *sk); extern void tcp_send_active_reset(struct sock *sk, int priority); extern int tcp_send_synack(struct sock *); -extern void tcp_push_one(struct sock *, unsigned mss_now); +extern void tcp_push_one(struct sock *, unsigned int mss_now); extern void tcp_send_ack(struct sock *sk); extern void tcp_send_delayed_ack(struct sock *sk); @@ -1054,7 +1068,7 @@ static inline void tcp_reset_xmit_timer( static inline void tcp_initialize_rcv_mss(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); - unsigned int hint = min(tp->advmss, tp->mss_cache_std); + unsigned int hint = min(tp->advmss, tp->mss_cache); hint = min(hint, tp->rcv_wnd/2); hint = min(hint, TCP_MIN_RCVMSS); @@ -1353,23 +1367,23 @@ static inline void tcp_cwnd_validate(str } /* Set slow start threshould and cwnd not falling to slow start */ -static inline void __tcp_enter_cwr(struct tcp_sock *tp) +static inline void __tcp_enter_cwr(struct tcp_sock *tp, unsigned int pkts) { tp->undo_marker = 0; tp->snd_ssthresh = tcp_recalc_ssthresh(tp); tp->snd_cwnd = min(tp->snd_cwnd, - tcp_packets_in_flight(tp) + 1U); + tcp_packets_in_flight(tp) + pkts); tp->snd_cwnd_cnt = 0; tp->high_seq = tp->snd_nxt; tp->snd_cwnd_stamp = tcp_time_stamp; TCP_ECN_queue_cwr(tp); } -static inline void tcp_enter_cwr(struct tcp_sock *tp) +static inline void tcp_enter_cwr(struct tcp_sock *tp, unsigned int pkts) { tp->prior_ssthresh = 0; if (tp->ca_state < TCP_CA_CWR) { - __tcp_enter_cwr(tp); + __tcp_enter_cwr(tp, pkts); tcp_set_ca_state(tp, TCP_CA_CWR); } } @@ -1397,74 +1411,6 @@ static __inline__ void tcp_minshall_upda tp->snd_sml = TCP_SKB_CB(skb)->end_seq; } -/* Return 0, if packet can be sent now without violation Nagle's rules: - 1. It is full sized. - 2. Or it contains FIN. - 3. Or TCP_NODELAY was set. - 4. Or TCP_CORK is not set, and all sent packets are ACKed. - With Minshall's modification: all sent small packets are ACKed. - */ - -static __inline__ int -tcp_nagle_check(const struct tcp_sock *tp, const struct sk_buff *skb, - unsigned mss_now, int nonagle) -{ - return (skb->len < mss_now && - !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && - ((nonagle&TCP_NAGLE_CORK) || - (!nonagle && - tp->packets_out && - tcp_minshall_check(tp)))); -} - -extern void tcp_set_skb_tso_segs(struct sock *, struct sk_buff *); - -/* This checks if the data bearing packet SKB (usually sk->sk_send_head) - * should be put on the wire right now. - */ -static __inline__ int tcp_snd_test(struct sock *sk, - struct sk_buff *skb, - unsigned cur_mss, int nonagle) -{ - struct tcp_sock *tp = tcp_sk(sk); - int pkts = tcp_skb_pcount(skb); - - if (!pkts) { - tcp_set_skb_tso_segs(sk, skb); - pkts = tcp_skb_pcount(skb); - } - - /* RFC 1122 - section 4.2.3.4 - * - * We must queue if - * - * a) The right edge of this frame exceeds the window - * b) There are packets in flight and we have a small segment - * [SWS avoidance and Nagle algorithm] - * (part of SWS is done on packetization) - * Minshall version sounds: there are no _small_ - * segments in flight. (tcp_nagle_check) - * c) We have too many packets 'in flight' - * - * Don't use the nagle rule for urgent data (or - * for the final FIN -DaveM). - * - * Also, Nagle rule does not apply to frames, which - * sit in the middle of queue (they have no chances - * to get new data) and if room at tail of skb is - * not enough to save something seriously (<32 for now). - */ - - /* Don't be strict about the congestion window for the - * final FIN frame. -DaveM - */ - return (((nonagle&TCP_NAGLE_PUSH) || tp->urg_mode - || !tcp_nagle_check(tp, skb, cur_mss, nonagle)) && - (((tcp_packets_in_flight(tp) + (pkts-1)) < tp->snd_cwnd) || - (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) && - !after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd)); -} - static __inline__ void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp) { if (!tp->packets_out && !tp->pending) @@ -1477,42 +1423,12 @@ static __inline__ int tcp_skb_is_last(co return skb->next == (struct sk_buff *)&sk->sk_write_queue; } -/* Push out any pending frames which were held back due to - * TCP_CORK or attempt at coalescing tiny packets. - * The socket must be locked by the caller. - */ -static __inline__ void __tcp_push_pending_frames(struct sock *sk, - struct tcp_sock *tp, - unsigned cur_mss, - int nonagle) -{ - struct sk_buff *skb = sk->sk_send_head; - - if (skb) { - if (!tcp_skb_is_last(sk, skb)) - nonagle = TCP_NAGLE_PUSH; - if (!tcp_snd_test(sk, skb, cur_mss, nonagle) || - tcp_write_xmit(sk, nonagle)) - tcp_check_probe_timer(sk, tp); - } - tcp_cwnd_validate(sk, tp); -} - static __inline__ void tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp) { __tcp_push_pending_frames(sk, tp, tcp_current_mss(sk, 1), tp->nonagle); } -static __inline__ int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp) -{ - struct sk_buff *skb = sk->sk_send_head; - - return (skb && - tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), - tcp_skb_is_last(sk, skb) ? TCP_NAGLE_PUSH : tp->nonagle)); -} - static __inline__ void tcp_init_wl(struct tcp_sock *tp, u32 ack, u32 seq) { tp->snd_wl1 = seq; @@ -1986,7 +1902,7 @@ static inline void tcp_westwood_update_r static inline __u32 __tcp_westwood_bw_rttmin(const struct tcp_sock *tp) { return max((tp->westwood.bw_est) * (tp->westwood.rtt_min) / - (__u32) (tp->mss_cache_std), + (__u32) (tp->mss_cache), 2U); } --- 1/include/net/sock.h.~1~ 2005-05-16 22:29:56.000000000 -0700 +++ 2/include/net/sock.h 2005-05-17 12:06:44.000000000 -0700 @@ -1130,13 +1130,16 @@ static inline void sk_stream_moderate_sn static inline struct sk_buff *sk_stream_alloc_pskb(struct sock *sk, int size, int mem, int gfp) { - struct sk_buff *skb = alloc_skb(size + sk->sk_prot->max_header, gfp); + struct sk_buff *skb; + int hdr_len; + hdr_len = SKB_DATA_ALIGN(sk->sk_prot->max_header); + skb = alloc_skb(size + hdr_len, gfp); if (skb) { skb->truesize += mem; if (sk->sk_forward_alloc >= (int)skb->truesize || sk_stream_mem_schedule(sk, skb->truesize, 0)) { - skb_reserve(skb, sk->sk_prot->max_header); + skb_reserve(skb, hdr_len); return skb; } __kfree_skb(skb); --- 1/net/ipv4/tcp_output.c.~1~ 2005-05-16 22:29:56.000000000 -0700 +++ 2/net/ipv4/tcp_output.c 2005-05-17 19:14:23.000000000 -0700 @@ -141,11 +141,11 @@ static inline void tcp_event_data_sent(s tp->ack.pingpong = 1; } -static __inline__ void tcp_event_ack_sent(struct sock *sk) +static __inline__ void tcp_event_ack_sent(struct sock *sk, unsigned int pkts) { struct tcp_sock *tp = tcp_sk(sk); - tcp_dec_quickack_mode(tp); + tcp_dec_quickack_mode(tp, pkts); tcp_clear_xmit_timer(sk, TCP_TIME_DACK); } @@ -361,7 +361,7 @@ static int tcp_transmit_skb(struct sock tp->af_specific->send_check(sk, th, skb->len, skb); if (tcb->flags & TCPCB_FLAG_ACK) - tcp_event_ack_sent(sk); + tcp_event_ack_sent(sk, tcp_skb_pcount(skb)); if (skb->len != tcp_header_size) tcp_event_data_sent(tp, skb, sk); @@ -372,7 +372,7 @@ static int tcp_transmit_skb(struct sock if (err <= 0) return err; - tcp_enter_cwr(tp); + tcp_enter_cwr(tp, tcp_skb_pcount(skb)); /* NET_XMIT_CN is special. It does not guarantee, * that this packet is lost. It tells that device @@ -419,32 +419,11 @@ static inline void tcp_tso_set_push(stru TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; } -/* Send _single_ skb sitting at the send head. This function requires - * true push pending frames to setup probe timer etc. - */ -void tcp_push_one(struct sock *sk, unsigned cur_mss) -{ - struct tcp_sock *tp = tcp_sk(sk); - struct sk_buff *skb = sk->sk_send_head; - - if (tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH)) { - /* Send it out now. */ - TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); - if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { - sk->sk_send_head = NULL; - tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; - tcp_packets_out_inc(sk, tp, skb); - return; - } - } -} - void tcp_set_skb_tso_segs(struct sock *sk, struct sk_buff *skb) { struct tcp_sock *tp = tcp_sk(sk); - if (skb->len <= tp->mss_cache_std || + if (skb->len <= tp->mss_cache || !(sk->sk_route_caps & NETIF_F_TSO)) { /* Avoid the costly divide in the normal * non-TSO case. @@ -454,10 +433,10 @@ void tcp_set_skb_tso_segs(struct sock *s } else { unsigned int factor; - factor = skb->len + (tp->mss_cache_std - 1); - factor /= tp->mss_cache_std; + factor = skb->len + (tp->mss_cache - 1); + factor /= tp->mss_cache; skb_shinfo(skb)->tso_segs = factor; - skb_shinfo(skb)->tso_size = tp->mss_cache_std; + skb_shinfo(skb)->tso_size = tp->mss_cache; } } @@ -662,7 +641,7 @@ unsigned int tcp_sync_mss(struct sock *s /* And store cached results */ tp->pmtu_cookie = pmtu; - tp->mss_cache = tp->mss_cache_std = mss_now; + tp->mss_cache = mss_now; return mss_now; } @@ -674,59 +653,274 @@ unsigned int tcp_sync_mss(struct sock *s * cannot be large. However, taking into account rare use of URG, this * is not a big flaw. */ +static inline u32 compute_xmit_cache(u32 mss, int sacks, int tso_enabled) +{ + u32 ret = (mss << 16) | sacks; + + if (tso_enabled) + ret |= (1 << 8); + + return ret; +} -unsigned int tcp_current_mss(struct sock *sk, int large) +unsigned int tcp_current_mss(struct sock *sk, int large_allowed) { struct tcp_sock *tp = tcp_sk(sk); struct dst_entry *dst = __sk_dst_get(sk); - unsigned int do_large, mss_now; + u32 mss_now; + u32 xmit_cache; + int doing_tso = 0; + + mss_now = tp->mss_cache; + + if (large_allowed && + (sk->sk_route_caps & NETIF_F_TSO) && + !tp->urg_mode) + doing_tso = 1; - mss_now = tp->mss_cache_std; if (dst) { u32 mtu = dst_mtu(dst); if (mtu != tp->pmtu_cookie) mss_now = tcp_sync_mss(sk, mtu); } - do_large = (large && - (sk->sk_route_caps & NETIF_F_TSO) && - !tp->urg_mode); - - if (do_large) { - unsigned int large_mss, factor, limit; - - large_mss = 65535 - tp->af_specific->net_header_len - - tp->ext_header_len - tp->tcp_header_len; - - if (tp->max_window && large_mss > (tp->max_window>>1)) - large_mss = max((tp->max_window>>1), - 68U - tp->tcp_header_len); - - factor = large_mss / mss_now; - - /* Always keep large mss multiple of real mss, but - * do not exceed 1/tso_win_divisor of the congestion window - * so we can keep the ACK clock ticking and minimize - * bursting. - */ - limit = tp->snd_cwnd; - if (sysctl_tcp_tso_win_divisor) - limit /= sysctl_tcp_tso_win_divisor; - limit = max(1U, limit); - if (factor > limit) - factor = limit; - - tp->mss_cache = mss_now * factor; - - mss_now = tp->mss_cache; - } + /* If the MSS, the TSO state, or the number of SACK blocks + * changes, we have to recompute tp->xmit_size_goal. + */ + xmit_cache = compute_xmit_cache(mss_now, tp->rx_opt.eff_sacks, + doing_tso); if (tp->rx_opt.eff_sacks) mss_now -= (TCPOLEN_SACK_BASE_ALIGNED + (tp->rx_opt.eff_sacks * TCPOLEN_SACK_PERBLOCK)); + + if (tp->xmit_size_cache != xmit_cache) { + u16 xmit_size_goal = mss_now; + + if (doing_tso) { + xmit_size_goal = 65535 - + tp->af_specific->net_header_len - + tp->ext_header_len - tp->tcp_header_len; + + if (tp->rx_opt.eff_sacks) + xmit_size_goal -= (TCPOLEN_SACK_BASE_ALIGNED + + (tp->rx_opt.eff_sacks * + TCPOLEN_SACK_PERBLOCK)); + + xmit_size_goal -= (xmit_size_goal % mss_now); + } + tp->xmit_size_goal = xmit_size_goal; + tp->xmit_size_cache = xmit_cache; + } + return mss_now; } +/* This must be invoked the first time we consider transmitting + * SKB onto the wire. + */ +static inline int tcp_init_tso_segs(struct sock *sk, struct sk_buff *skb) +{ + int tso_segs = tcp_skb_pcount(skb); + + if (!tso_segs) { + tcp_set_skb_tso_segs(sk, skb); + tso_segs = tcp_skb_pcount(skb); + } + return tso_segs; +} + +/* Return 0, if packet can be sent now without violation Nagle's rules: + * 1. It is full sized. + * 2. Or it contains FIN. + * 3. Or TCP_NODELAY was set. + * 4. Or TCP_CORK is not set, and all sent packets are ACKed. + * With Minshall's modification: all sent small packets are ACKed. + */ + +static inline int tcp_nagle_check(const struct tcp_sock *tp, + const struct sk_buff *skb, + unsigned mss_now, int nonagle) +{ + return (skb->len < mss_now && + !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && + ((nonagle&TCP_NAGLE_CORK) || + (!nonagle && + tp->packets_out && + tcp_minshall_check(tp)))); +} + +/* Return non-zero if the Nagle test allows this packet to be + * sent now. + */ +static inline int tcp_nagle_test(struct tcp_sock *tp, struct sk_buff *skb, unsigned int cur_mss, int nonagle) +{ + /* Nagle rule does not apply to frames, which + * sit in the middle of queue (they have no chances + * to get new data) and if room at tail of skb is + * not enough to save something seriously (<32 for now). + * + * This is implemented in the callers, where they modify + * the 'nonagle' argument based upon the location of SKB + * in the send queue. + */ + if (nonagle & TCP_NAGLE_PUSH) + return 1; + + /* Don't use the nagle rule for urgent data (or + * for the final FIN -DaveM). + */ + if (tp->urg_mode || + (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) + return 1; + + if (!tcp_nagle_check(tp, skb, cur_mss, nonagle)) + return 1; + + return 0; +} + +/* Can at least one segment of SKB be sent right now, according + * to the congestion window rules? If so, return how many segments + * are allowed. + */ +static inline unsigned int tcp_cwnd_test(struct tcp_sock *tp, struct sk_buff *skb) +{ + u32 in_flight, cwnd; + + /* Don't be strict about the congestion window for the + * final FIN frame. -DaveM + */ + if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) + return 1; + + in_flight = tcp_packets_in_flight(tp); + cwnd = tp->snd_cwnd; + if (in_flight < cwnd) + return (cwnd - in_flight); + + return 0; +} + +/* Does at least the first segment of SKB fit into the congestion + * window? + */ +static inline int tcp_snd_wnd_test(struct tcp_sock *tp, struct sk_buff *skb, unsigned int cur_mss) +{ + u32 end_seq = TCP_SKB_CB(skb)->end_seq; + + if (skb->len > cur_mss) + end_seq = TCP_SKB_CB(skb)->seq + cur_mss; + + return !after(end_seq, tp->snd_una + tp->snd_wnd); +} + +/* This checks if the data bearing packet SKB (usually + * sk->sk_send_head) should be put on the wire right now. If so, it + * returns the number of packets allowed by the congestion window. + */ +static unsigned int tcp_snd_test(struct sock *sk, struct sk_buff *skb, + unsigned cur_mss, int nonagle) +{ + struct tcp_sock *tp = tcp_sk(sk); + unsigned int cwnd_quota; + + if (!tcp_nagle_test(tp, skb, cur_mss, nonagle)) + return 0; + + cwnd_quota = tcp_cwnd_test(tp, skb); + if (cwnd_quota && + !tcp_snd_wnd_test(tp, skb, cur_mss)) + cwnd_quota = 0; + + return cwnd_quota; +} + +int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp) +{ + struct sk_buff *skb = sk->sk_send_head; + + return (skb && + tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), + tcp_skb_is_last(sk, skb) ? TCP_NAGLE_PUSH : tp->nonagle)); +} + +/* Trim TSO SKB to LEN bytes, put the remaining data into a new packet + * which is put after SKB on the list. It is very much like + * tcp_fragment() except that it may make several kinds of assumptions + * in order to speed up the splitting operation. In particular, we + * know that all the data is in scatter-gather pages, and that the + * packet has never been sent out before (and thus is not cloned). + */ +static int tso_fragment(struct sock *sk, struct sk_buff *skb, unsigned int len) +{ + struct sk_buff *buff; + int nlen = skb->len - len; + u16 flags; + + /* All of a TSO frame must be composed of paged data. */ + BUG_ON(skb->len != skb->data_len); + + buff = sk_stream_alloc_pskb(sk, 0, 0, GFP_ATOMIC); + if (unlikely(buff == NULL)) + return -ENOMEM; + sk_charge_skb(sk, buff); + + buff->truesize += nlen; + skb->truesize -= nlen; + + /* Correct the sequence numbers. */ + TCP_SKB_CB(buff)->seq = TCP_SKB_CB(skb)->seq + len; + TCP_SKB_CB(buff)->end_seq = TCP_SKB_CB(skb)->end_seq; + TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(buff)->seq; + + /* PSH and FIN should only be set in the second packet. */ + flags = TCP_SKB_CB(skb)->flags; + TCP_SKB_CB(skb)->flags = flags & ~(TCPCB_FLAG_FIN|TCPCB_FLAG_PSH); + TCP_SKB_CB(buff)->flags = flags; + + /* This packet was never sent out yet, so no SACK bits. */ + TCP_SKB_CB(buff)->sacked = 0; + + buff->ip_summed = skb->ip_summed = CHECKSUM_HW; + skb_split(skb, buff, len); + + /* Fix up tso_factor for both original and new SKB. */ + tcp_set_skb_tso_segs(sk, skb); + tcp_set_skb_tso_segs(sk, buff); + + /* Link BUFF into the send queue. */ + __skb_append(skb, buff); + + return 0; +} + +/* Split TSO frame SKB into one MSS sized packet, then the rest. + * This is called during SACK processing when some SACK information + * hits a TSO packet. + */ +int tcp_tso_mince(struct sock *sk, struct tcp_sock *tp, struct sk_buff *skb) +{ + unsigned int mss_now = tcp_current_mss(sk, 1); + + BUG_ON(tcp_skb_pcount(skb) <= 1); + + /* We cannot use tso_fragment() in this case, because + * the packet has been sent once already and thus may + * be cloned or have other non-trivial details to deal + * with. + */ + return tcp_fragment(sk, skb, mss_now); +} + +static inline unsigned int tso_size_limit(u32 window, unsigned int mss_now, unsigned int cwnd) +{ + u32 cwnd_len; + + cwnd_len = mss_now * cwnd; + return min(window, cwnd_len); +} + /* This routine writes packets to the network. It advances the * send_head. This happens as incoming acks open up the remote * window for us. @@ -734,57 +928,167 @@ unsigned int tcp_current_mss(struct sock * Returns 1, if no segments are in flight and we have queued segments, but * cannot send anything now because of SWS or another problem. */ -int tcp_write_xmit(struct sock *sk, int nonagle) +static int tcp_write_xmit(struct sock *sk, int nonagle) { struct tcp_sock *tp = tcp_sk(sk); - unsigned int mss_now; + unsigned int mss_now, cwnd_quota, sent_pkts, tso_segs; + struct sk_buff *skb; /* If we are closed, the bytes will have to remain here. * In time closedown will finish, we empty the write queue and all * will be happy. */ - if (sk->sk_state != TCP_CLOSE) { - struct sk_buff *skb; - int sent_pkts = 0; + if (unlikely(sk->sk_state == TCP_CLOSE)) + return 0; - /* Account for SACKS, we may need to fragment due to this. - * It is just like the real MSS changing on us midstream. - * We also handle things correctly when the user adds some - * IP options mid-stream. Silly to do, but cover it. - */ - mss_now = tcp_current_mss(sk, 1); + /* Account for SACKS, we may need to fragment due to this. + * It is just like the real MSS changing on us midstream. + * We also handle things correctly when the user adds some + * IP options mid-stream. Silly to do, but cover it. + */ + mss_now = tcp_current_mss(sk, 1); + skb = sk->sk_send_head; + if (unlikely(!skb)) + return 0; + + tso_segs = tcp_init_tso_segs(sk, skb); + cwnd_quota = tcp_cwnd_test(tp, skb); + sent_pkts = 0; + + while (cwnd_quota) { + u32 end_seq, window_seq; + + if (!tcp_nagle_test(tp, skb, mss_now, + (tcp_skb_is_last(sk, skb) ? + nonagle : TCP_NAGLE_PUSH))) + break; + + end_seq = TCP_SKB_CB(skb)->end_seq; + window_seq = tp->snd_una + tp->snd_wnd; + if (skb->len > mss_now) + end_seq = TCP_SKB_CB(skb)->seq + mss_now; + if (after(end_seq, window_seq)) + break; + + BUG_ON(!tso_segs); + + if (tso_segs > 1) { + u32 limit = tso_size_limit(window_seq - + TCP_SKB_CB(skb)->seq, + mss_now, cwnd_quota); - while ((skb = sk->sk_send_head) && - tcp_snd_test(sk, skb, mss_now, - tcp_skb_is_last(sk, skb) ? nonagle : - TCP_NAGLE_PUSH)) { - if (skb->len > mss_now) { - if (tcp_fragment(sk, skb, mss_now)) + if (skb->len > limit) { + if (tso_fragment(sk, skb, limit)) break; } - - TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); - if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) + } else if (skb->len > mss_now) { + if (tcp_fragment(sk, skb, mss_now)) break; + } - /* Advance the send_head. This one is sent out. - * This call will increment packets_out. - */ - update_send_head(sk, tp, skb); + TCP_SKB_CB(skb)->when = tcp_time_stamp; + tcp_tso_set_push(skb); + if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) + break; - tcp_minshall_update(tp, mss_now, skb); - sent_pkts = 1; - } + /* Advance the send_head. This one is sent out. + * This call will increment packets_out. + */ + update_send_head(sk, tp, skb); - if (sent_pkts) { - tcp_cwnd_validate(sk, tp); - return 0; + tcp_minshall_update(tp, mss_now, skb); + sent_pkts++; + + cwnd_quota -= tcp_skb_pcount(skb); + skb = sk->sk_send_head; + if (!skb) + break; + tso_segs = tcp_init_tso_segs(sk, skb); + } + + if (sent_pkts) { + tcp_cwnd_validate(sk, tp); + return 0; + } + + return !tp->packets_out && sk->sk_send_head; +} + +/* Push out any pending frames which were held back due to + * TCP_CORK or attempt at coalescing tiny packets. + * The socket must be locked by the caller. + */ +void __tcp_push_pending_frames(struct sock *sk, + struct tcp_sock *tp, + unsigned int cur_mss, + int nonagle) +{ + struct sk_buff *skb = sk->sk_send_head; + + if (skb) { + if (!tcp_skb_is_last(sk, skb)) + nonagle = TCP_NAGLE_PUSH; + if (tcp_write_xmit(sk, nonagle)) + tcp_check_probe_timer(sk, tp); + } + tcp_cwnd_validate(sk, tp); +} + +/* As ACKs arrive and the send and congestion windows potentially + * open up, we call this to try and make write queue transmit + * progress. + * + * The caller has the socket locked, and has verified that + * sk->sk_send_head is not NULL. + */ +void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb) +{ + struct tcp_sock *tp = tcp_sk(sk); + + if (tcp_write_xmit(sk, tp->nonagle)) + tcp_check_probe_timer(sk, tp); +} + +/* Send _single_ skb sitting at the send head. This function requires + * true push pending frames to setup probe timer etc. Caller makes + * sure that sk->sk_send_head is non-NULL. + */ +void tcp_push_one(struct sock *sk, unsigned int cur_mss) +{ + struct tcp_sock *tp = tcp_sk(sk); + struct sk_buff *skb = sk->sk_send_head; + unsigned int tso_segs, cwnd_quota; + + tso_segs = tcp_init_tso_segs(sk, skb); + cwnd_quota = tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH); + if (cwnd_quota) { + u32 window_seq; + + window_seq = tp->snd_una + tp->snd_wnd; + BUG_ON(!tso_segs); + + if (tso_segs > 1) { + u32 limit = tso_size_limit(window_seq - + TCP_SKB_CB(skb)->seq, + cur_mss, cwnd_quota); + + if (skb->len > limit) { + if (tso_fragment(sk, skb, limit)) + return; + } + } else if (skb->len > cur_mss) { + if (tcp_fragment(sk, skb, cur_mss)) + return; } - return !tp->packets_out && sk->sk_send_head; + /* Send it out now. */ + TCP_SKB_CB(skb)->when = tcp_time_stamp; + tcp_tso_set_push(skb); + if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { + update_send_head(sk, tp, skb); + return; + } } - return 0; } /* This function returns the amount that we can raise the @@ -1041,12 +1345,6 @@ int tcp_retransmit_skb(struct sock *sk, if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una)) BUG(); - if (sk->sk_route_caps & NETIF_F_TSO) { - sk->sk_route_caps &= ~NETIF_F_TSO; - sock_set_flag(sk, SOCK_NO_LARGESEND); - tp->mss_cache = tp->mss_cache_std; - } - if (tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)) return -ENOMEM; } @@ -1671,13 +1969,6 @@ int tcp_write_wakeup(struct sock *sk) TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; if (tcp_fragment(sk, skb, seg_size)) return -1; - /* SWS override triggered forced fragmentation. - * Disable TSO, the connection is too sick. */ - if (sk->sk_route_caps & NETIF_F_TSO) { - sock_set_flag(sk, SOCK_NO_LARGESEND); - sk->sk_route_caps &= ~NETIF_F_TSO; - tp->mss_cache = tp->mss_cache_std; - } } else if (!tcp_skb_pcount(skb)) tcp_set_skb_tso_segs(sk, skb); --- 1/net/ipv4/tcp.c.~1~ 2005-05-16 22:29:56.000000000 -0700 +++ 2/net/ipv4/tcp.c 2005-05-17 12:07:26.000000000 -0700 @@ -634,7 +634,7 @@ static ssize_t do_tcp_sendpages(struct s size_t psize, int flags) { struct tcp_sock *tp = tcp_sk(sk); - int mss_now; + int mss_now, size_goal; int err; ssize_t copied; long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT); @@ -647,6 +647,7 @@ static ssize_t do_tcp_sendpages(struct s clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; copied = 0; err = -EPIPE; @@ -660,7 +661,7 @@ static ssize_t do_tcp_sendpages(struct s int offset = poffset % PAGE_SIZE; int size = min_t(size_t, psize, PAGE_SIZE - offset); - if (!sk->sk_send_head || (copy = mss_now - skb->len) <= 0) { + if (!sk->sk_send_head || (copy = size_goal - skb->len) <= 0) { new_segment: if (!sk_stream_memory_free(sk)) goto wait_for_sndbuf; @@ -671,7 +672,7 @@ new_segment: goto wait_for_memory; skb_entail(sk, tp, skb); - copy = mss_now; + copy = size_goal; } if (copy > size) @@ -712,7 +713,7 @@ new_segment: if (!(psize -= copy)) goto out; - if (skb->len != mss_now || (flags & MSG_OOB)) + if (skb->len != size_goal || (flags & MSG_OOB)) continue; if (forced_push(tp)) { @@ -732,6 +733,7 @@ wait_for_memory: goto do_error; mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; } out: @@ -773,15 +775,11 @@ ssize_t tcp_sendpage(struct socket *sock static inline int select_size(struct sock *sk, struct tcp_sock *tp) { - int tmp = tp->mss_cache_std; + int tmp = tp->mss_cache; - if (sk->sk_route_caps & NETIF_F_SG) { - int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER); + if (sk->sk_route_caps & NETIF_F_SG) + tmp = 0; - if (tmp >= pgbreak && - tmp <= pgbreak + (MAX_SKB_FRAGS - 1) * PAGE_SIZE) - tmp = pgbreak; - } return tmp; } @@ -792,7 +790,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *skb; int iovlen, flags; - int mss_now; + int mss_now, size_goal; int err, copied; long timeo; @@ -811,6 +809,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; /* Ok commence sending. */ iovlen = msg->msg_iovlen; @@ -833,7 +832,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru skb = sk->sk_write_queue.prev; if (!sk->sk_send_head || - (copy = mss_now - skb->len) <= 0) { + (copy = size_goal - skb->len) <= 0) { new_segment: /* Allocate new segment. If the interface is SG, @@ -856,7 +855,7 @@ new_segment: skb->ip_summed = CHECKSUM_HW; skb_entail(sk, tp, skb); - copy = mss_now; + copy = size_goal; } /* Try to append data to the end of skb. */ @@ -891,11 +890,6 @@ new_segment: tcp_mark_push(tp, skb); goto new_segment; } else if (page) { - /* If page is cached, align - * offset to L1 cache boundary - */ - off = (off + L1_CACHE_BYTES - 1) & - ~(L1_CACHE_BYTES - 1); if (off == PAGE_SIZE) { put_page(page); TCP_PAGE(sk) = page = NULL; @@ -956,7 +950,7 @@ new_segment: if ((seglen -= copy) == 0 && iovlen == 0) goto out; - if (skb->len != mss_now || (flags & MSG_OOB)) + if (skb->len != size_goal || (flags & MSG_OOB)) continue; if (forced_push(tp)) { @@ -976,6 +970,7 @@ wait_for_memory: goto do_error; mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; } } @@ -2135,7 +2130,7 @@ void tcp_get_info(struct sock *sk, struc info->tcpi_rto = jiffies_to_usecs(tp->rto); info->tcpi_ato = jiffies_to_usecs(tp->ack.ato); - info->tcpi_snd_mss = tp->mss_cache_std; + info->tcpi_snd_mss = tp->mss_cache; info->tcpi_rcv_mss = tp->ack.rcv_mss; info->tcpi_unacked = tp->packets_out; @@ -2185,7 +2180,7 @@ int tcp_getsockopt(struct sock *sk, int switch (optname) { case TCP_MAXSEG: - val = tp->mss_cache_std; + val = tp->mss_cache; if (!val && ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN))) val = tp->rx_opt.user_mss; break; --- 1/net/ipv4/tcp_input.c.~1~ 2005-05-16 22:29:56.000000000 -0700 +++ 2/net/ipv4/tcp_input.c 2005-05-17 16:49:26.000000000 -0700 @@ -805,10 +805,10 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp, __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0); if (!cwnd) { - if (tp->mss_cache_std > 1460) + if (tp->mss_cache > 1460) cwnd = 2; else - cwnd = (tp->mss_cache_std > 1095) ? 3 : 4; + cwnd = (tp->mss_cache > 1095) ? 3 : 4; } return min_t(__u32, cwnd, tp->snd_cwnd_clamp); } @@ -974,14 +974,6 @@ tcp_sacktag_write_queue(struct sock *sk, int flag = 0; int i; - /* So, SACKs for already sent large segments will be lost. - * Not good, but alternative is to resegment the queue. */ - if (sk->sk_route_caps & NETIF_F_TSO) { - sk->sk_route_caps &= ~NETIF_F_TSO; - sock_set_flag(sk, SOCK_NO_LARGESEND); - tp->mss_cache = tp->mss_cache_std; - } - if (!tp->sacked_out) tp->fackets_out = 0; prior_fackets = tp->fackets_out; @@ -1038,6 +1030,15 @@ tcp_sacktag_write_queue(struct sock *sk, if(!before(TCP_SKB_CB(skb)->seq, end_seq)) break; + /* Even if mincing a TSO frame fails, we + * continue anyways. We will end up with + * more coarse SACK information, but it is + * better than ignoring all the SACK information + * altogether. + */ + if (tcp_skb_pcount(skb) > 1) + tcp_tso_mince(sk, tp, skb); + fack_count += tcp_skb_pcount(skb); in_sack = !after(start_seq, TCP_SKB_CB(skb)->seq) && @@ -1142,7 +1143,7 @@ tcp_sacktag_write_queue(struct sock *sk, (IsFack(tp) || !before(lost_retrans, TCP_SKB_CB(skb)->ack_seq + tp->reordering * - tp->mss_cache_std))) { + tp->mss_cache))) { TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS; tp->retrans_out -= tcp_skb_pcount(skb); @@ -1782,7 +1783,7 @@ static void tcp_try_to_open(struct sock tp->retrans_stamp = 0; if (flag&FLAG_ECE) - tcp_enter_cwr(tp); + tcp_enter_cwr(tp, 1); if (tp->ca_state != TCP_CA_CWR) { int state = TCP_CA_Open; @@ -2170,7 +2171,7 @@ static void vegas_cong_avoid(struct tcp_ * is the cwnd during the previous RTT. */ old_wnd = (tp->vegas.beg_snd_nxt - tp->vegas.beg_snd_una) / - tp->mss_cache_std; + tp->mss_cache; old_snd_cwnd = tp->vegas.beg_snd_cwnd; /* Save the extent of the current window so we can use this @@ -2799,19 +2800,19 @@ static void westwood_dupack_update(struc { struct tcp_sock *tp = tcp_sk(sk); - tp->westwood.accounted += tp->mss_cache_std; - tp->westwood.cumul_ack = tp->mss_cache_std; + tp->westwood.accounted += tp->mss_cache; + tp->westwood.cumul_ack = tp->mss_cache; } static inline int westwood_may_change_cumul(struct tcp_sock *tp) { - return (tp->westwood.cumul_ack > tp->mss_cache_std); + return (tp->westwood.cumul_ack > tp->mss_cache); } static inline void westwood_partial_update(struct tcp_sock *tp) { tp->westwood.accounted -= tp->westwood.cumul_ack; - tp->westwood.cumul_ack = tp->mss_cache_std; + tp->westwood.cumul_ack = tp->mss_cache; } static inline void westwood_complete_update(struct tcp_sock *tp) @@ -3952,7 +3953,7 @@ static void tcp_new_space(struct sock *s !(sk->sk_userlocks & SOCK_SNDBUF_LOCK) && !tcp_memory_pressure && atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0]) { - int sndmem = max_t(u32, tp->rx_opt.mss_clamp, tp->mss_cache_std) + + int sndmem = max_t(u32, tp->rx_opt.mss_clamp, tp->mss_cache) + MAX_TCP_HEADER + 16 + sizeof(struct sk_buff), demanded = max_t(unsigned int, tp->snd_cwnd, tp->reordering + 1); @@ -3975,16 +3976,6 @@ static inline void tcp_check_space(struc } } -static void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb) -{ - struct tcp_sock *tp = tcp_sk(sk); - - if (after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd) || - tcp_packets_in_flight(tp) >= tp->snd_cwnd || - tcp_write_xmit(sk, tp->nonagle)) - tcp_check_probe_timer(sk, tp); -} - static __inline__ void tcp_data_snd_check(struct sock *sk) { struct sk_buff *skb = sk->sk_send_head; --- 1/net/ipv4/tcp_ipv4.c.~1~ 2005-05-16 22:29:56.000000000 -0700 +++ 2/net/ipv4/tcp_ipv4.c 2005-05-17 11:27:14.000000000 -0700 @@ -2060,7 +2060,8 @@ static int tcp_v4_init_sock(struct sock */ tp->snd_ssthresh = 0x7fffffff; /* Infinity */ tp->snd_cwnd_clamp = ~0; - tp->mss_cache_std = tp->mss_cache = 536; + tp->mss_cache = 536; + tp->xmit_size_cache = ~0; tp->reordering = sysctl_tcp_reordering; --- 1/net/ipv6/tcp_ipv6.c.~1~ 2005-05-16 22:29:56.000000000 -0700 +++ 2/net/ipv6/tcp_ipv6.c 2005-05-17 11:27:25.000000000 -0700 @@ -2021,7 +2021,8 @@ static int tcp_v6_init_sock(struct sock */ tp->snd_ssthresh = 0x7fffffff; tp->snd_cwnd_clamp = ~0; - tp->mss_cache_std = tp->mss_cache = 536; + tp->mss_cache = 536; + tp->xmit_size_cache = ~0; tp->reordering = sysctl_tcp_reordering; From jheffner@psc.edu Tue May 17 19:26:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 19:26:51 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I2QmF3009744 for ; Tue, 17 May 2005 19:26:48 -0700 Received: from [192.168.1.4] (ipl-67-013.pppoe.stargate.net [206.210.67.13]) (authenticated bits=0) by mailer1.psc.edu (8.13.3/8.13.3) with ESMTP id j4I2Q9Vi021128 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 17 May 2005 22:26:10 -0400 (EDT) In-Reply-To: <20050504230731.12be1bc3.davem@davemloft.net> References: <20050504230731.12be1bc3.davem@davemloft.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <46332e5aa197db91aaf012cf140282b4@psc.edu> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com From: John Heffner Subject: Re: [PATCH] TSO Reloaded Date: Tue, 17 May 2005 22:26:09 -0400 To: "David S. Miller" X-Mailer: Apple Mail (2.622) X-archive-position: 1289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 378 Lines: 12 Though it may be moot by now, I just ran some tests of my own with this patch. This was on a dual 2.4 GHz Xeon booted with a UP kernel, running iperf over an e1000 at a 1500 byte MTU. I measured idle CPU by running a process which sits in a gettimeofday() loop. Numbers are CPU utilization, all turned out +/- 1%. No TSO: 86.6% Old TSO: 61.0% New TSO: 88.5% -John From davem@davemloft.net Tue May 17 19:29:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 19:29:10 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I2T5F3010471 for ; Tue, 17 May 2005 19:29:05 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYEIP-0000lR-EB; Tue, 17 May 2005 19:28:29 -0700 Date: Tue, 17 May 2005 19:28:29 -0700 (PDT) Message-Id: <20050517.192829.71087792.davem@davemloft.net> To: jheffner@psc.edu Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded From: "David S. Miller" In-Reply-To: <46332e5aa197db91aaf012cf140282b4@psc.edu> References: <20050504230731.12be1bc3.davem@davemloft.net> <46332e5aa197db91aaf012cf140282b4@psc.edu> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 551 Lines: 16 From: John Heffner Date: Tue, 17 May 2005 22:26:09 -0400 > Though it may be moot by now, I just ran some tests of my own with this > patch. This was on a dual 2.4 GHz Xeon booted with a UP kernel, > running iperf over an e1000 at a 1500 byte MTU. I measured idle CPU by > running a process which sits in a gettimeofday() loop. Numbers are CPU > utilization, all turned out +/- 1%. > > No TSO: 86.6% > Old TSO: 61.0% > New TSO: 88.5% Yeah, TSO Reloaded really stinks. :-) Try the "Super TSO" patch I just posted instead. From christoph@graphe.net Tue May 17 19:53:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 19:53:33 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I2rMF3011726 for ; Tue, 17 May 2005 19:53:22 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DYEfn-0005ZH-3H; Tue, 17 May 2005 19:52:44 -0700 Date: Tue, 17 May 2005 19:52:38 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Andrew Morton cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 In-Reply-To: <20050517190343.2e57fdd7.akpm@osdl.org> Message-ID: References: <20050517190343.2e57fdd7.akpm@osdl.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 774 Lines: 25 On Tue, 17 May 2005, Andrew Morton wrote: > Christoph Lameter wrote: > > > > NUMA awareness for the e1000 driver. Allocate transmit and receive buffers > > on the node of the device. > > Hast thou any benchmarking results? Yes, your honor. Just a second .... The patch has been around for a long time. No benchmarks results in my email archive. Would need to talk to some folks tomorrow and maybe we would have to run some new benchmarks. > > - txdr->buffer_info = vmalloc(size); > > + txdr->buffer_info = kmalloc_node(size, GFP_KERNEL, node); > > How come that this is safe to do Because physically contiguous memory is usually better than virtually contiguous memory? Any reason that physically contiguous memory will break the driver? From jheffner@psc.edu Tue May 17 19:52:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 19:52:49 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I2qWF3011682 for ; Tue, 17 May 2005 19:52:32 -0700 Received: from [192.168.1.4] (ipl-67-013.pppoe.stargate.net [206.210.67.13]) (authenticated bits=0) by mailer1.psc.edu (8.13.3/8.13.3) with ESMTP id j4I2psvI013662 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 17 May 2005 22:51:54 -0400 (EDT) In-Reply-To: <20050517.192829.71087792.davem@davemloft.net> References: <20050504230731.12be1bc3.davem@davemloft.net> <46332e5aa197db91aaf012cf140282b4@psc.edu> <20050517.192829.71087792.davem@davemloft.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0dd16bed0ea56242244bab0a7f1cf372@psc.edu> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com From: John Heffner Subject: Re: [PATCH] TSO Reloaded Date: Tue, 17 May 2005 22:51:53 -0400 To: "David S. Miller" X-Mailer: Apple Mail (2.622) X-archive-position: 1291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 705 Lines: 27 On May 17, 2005, at 10:28 PM, David S. Miller wrote: > From: John Heffner > Date: Tue, 17 May 2005 22:26:09 -0400 > >> Though it may be moot by now, I just ran some tests of my own with >> this >> patch. This was on a dual 2.4 GHz Xeon booted with a UP kernel, >> running iperf over an e1000 at a 1500 byte MTU. I measured idle CPU >> by >> running a process which sits in a gettimeofday() loop. Numbers are >> CPU >> utilization, all turned out +/- 1%. >> >> No TSO: 86.6% >> Old TSO: 61.0% >> New TSO: 88.5% > > Yeah, TSO Reloaded really stinks. :-) > > Try the "Super TSO" patch I just posted instead. Interesting timing. :) With the new patch I'm getting 78.0%. -John From davem@davemloft.net Tue May 17 19:57:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 19:57:53 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I2vkF3012772 for ; Tue, 17 May 2005 19:57:46 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYEk3-0000mK-F6; Tue, 17 May 2005 19:57:03 -0700 Date: Tue, 17 May 2005 19:57:03 -0700 (PDT) Message-Id: <20050517.195703.104034854.davem@davemloft.net> To: christoph@lameter.com Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 From: "David S. Miller" In-Reply-To: References: <20050517190343.2e57fdd7.akpm@osdl.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 623 Lines: 16 From: Christoph Lameter Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 Date: Tue, 17 May 2005 19:52:38 -0700 (PDT) > > > - txdr->buffer_info = vmalloc(size); > > > + txdr->buffer_info = kmalloc_node(size, GFP_KERNEL, node); > > > > How come that this is safe to do > > Because physically contiguous memory is usually better than virtually > contiguous memory? Any reason that physically contiguous memory will > break the driver? The issue is whether size can end up being too large for kmalloc() to satisfy, whereas vmalloc() would be able to handle it. From davem@davemloft.net Tue May 17 20:00:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 20:00:57 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I30pF3013332 for ; Tue, 17 May 2005 20:00:51 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYEn9-0000mq-Qp; Tue, 17 May 2005 20:00:15 -0700 Date: Tue, 17 May 2005 20:00:15 -0700 (PDT) Message-Id: <20050517.200015.55506861.davem@davemloft.net> To: jheffner@psc.edu Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded From: "David S. Miller" In-Reply-To: <0dd16bed0ea56242244bab0a7f1cf372@psc.edu> References: <46332e5aa197db91aaf012cf140282b4@psc.edu> <20050517.192829.71087792.davem@davemloft.net> <0dd16bed0ea56242244bab0a7f1cf372@psc.edu> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 748 Lines: 27 From: John Heffner Date: Tue, 17 May 2005 22:51:53 -0400 > On May 17, 2005, at 10:28 PM, David S. Miller wrote: > > > From: John Heffner > > Date: Tue, 17 May 2005 22:26:09 -0400 > > > >> No TSO: 86.6% > >> Old TSO: 61.0% > >> New TSO: 88.5% > > > > Yeah, TSO Reloaded really stinks. :-) > > > > Try the "Super TSO" patch I just posted instead. > > Interesting timing. :) > With the new patch I'm getting 78.0%. Thanks for testing. I actually expected the new code to do better. Splitting could be a little bit expensive, but that only occurs at the beginning of the connection as we ramp up the congestion and send window. Afterwards, we should be able to release full unsplit TSO frames onto the wire. From jheffner@psc.edu Tue May 17 20:48:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 20:48:30 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I3mQF3018908 for ; Tue, 17 May 2005 20:48:26 -0700 Received: from [192.168.1.4] (ipl-67-013.pppoe.stargate.net [206.210.67.13]) (authenticated bits=0) by mailer1.psc.edu (8.13.3/8.13.3) with ESMTP id j4I3lmQL001619 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 17 May 2005 23:47:49 -0400 (EDT) In-Reply-To: <20050517.200015.55506861.davem@davemloft.net> References: <46332e5aa197db91aaf012cf140282b4@psc.edu> <20050517.192829.71087792.davem@davemloft.net> <0dd16bed0ea56242244bab0a7f1cf372@psc.edu> <20050517.200015.55506861.davem@davemloft.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03e7252e3f5541302f25675360330b1e@psc.edu> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com From: John Heffner Subject: Re: [PATCH] TSO Reloaded Date: Tue, 17 May 2005 23:47:48 -0400 To: "David S. Miller" X-Mailer: Apple Mail (2.622) X-archive-position: 1295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 595 Lines: 21 On May 17, 2005, at 11:00 PM, David S. Miller wrote: > From: John Heffner > Date: Tue, 17 May 2005 22:51:53 -0400 > >> With the new patch I'm getting 78.0%. > > Thanks for testing. > > I actually expected the new code to do better. > Splitting could be a little bit expensive, but > that only occurs at the beginning of the connection > as we ramp up the congestion and send window. > Afterwards, we should be able to release full unsplit > TSO frames onto the wire. With different (larger than default) buffer sizes, I'm getting 63.4%. Not surprising I guess. -John From christoph@graphe.net Tue May 17 21:28:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 21:28:38 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I4SZF3020552 for ; Tue, 17 May 2005 21:28:36 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DYG9s-0005y5-UV; Tue, 17 May 2005 21:27:52 -0700 Date: Tue, 17 May 2005 21:27:48 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: "David S. Miller" cc: akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shai@scalex86.org Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 In-Reply-To: <20050517.195703.104034854.davem@davemloft.net> Message-ID: References: <20050517190343.2e57fdd7.akpm@osdl.org> <20050517.195703.104034854.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 398 Lines: 11 On Tue, 17 May 2005, David S. Miller wrote: > > Because physically contiguous memory is usually better than virtually > > contiguous memory? Any reason that physically contiguous memory will > > break the driver? > > The issue is whether size can end up being too large for > kmalloc() to satisfy, whereas vmalloc() would be able to > handle it. Oww.. We need a NUMA aware vmalloc for this? From akpm@osdl.org Tue May 17 22:00:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 22:00:10 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I507F3022332 for ; Tue, 17 May 2005 22:00:07 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4I4xPU3032387 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 17 May 2005 21:59:26 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4I4xO0l010584; Tue, 17 May 2005 21:59:25 -0700 Date: Tue, 17 May 2005 21:58:45 -0700 From: Andrew Morton To: Christoph Lameter Cc: davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shai@scalex86.org Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 Message-Id: <20050517215845.2f87be2f.akpm@osdl.org> In-Reply-To: References: <20050517190343.2e57fdd7.akpm@osdl.org> <20050517.195703.104034854.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 763 Lines: 19 Christoph Lameter wrote: > > On Tue, 17 May 2005, David S. Miller wrote: > > > > Because physically contiguous memory is usually better than virtually > > > contiguous memory? Any reason that physically contiguous memory will > > > break the driver? > > > > The issue is whether size can end up being too large for > > kmalloc() to satisfy, whereas vmalloc() would be able to > > handle it. > > Oww.. We need a NUMA aware vmalloc for this? I think the e1000 driver is being a bit insane there. I figure that sizeof(struct e1000_buffer) is 28 on 64-bit, so even with 4k pagesize we'll always succeed in being able to support a 32k/32 = 1024-entry Tx ring. Is there any real-world reason for wanting larger ring sizes than that? From davem@davemloft.net Tue May 17 23:00:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 17 May 2005 23:00:26 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I60MF3027366 for ; Tue, 17 May 2005 23:00:23 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYHaq-0000jQ-IJ; Tue, 17 May 2005 22:59:44 -0700 Date: Tue, 17 May 2005 22:59:44 -0700 (PDT) Message-Id: <20050517.225944.92583479.davem@davemloft.net> To: jheffner@psc.edu Cc: netdev@oss.sgi.com Subject: Re: [PATCH] TSO Reloaded From: "David S. Miller" In-Reply-To: <03e7252e3f5541302f25675360330b1e@psc.edu> References: <0dd16bed0ea56242244bab0a7f1cf372@psc.edu> <20050517.200015.55506861.davem@davemloft.net> <03e7252e3f5541302f25675360330b1e@psc.edu> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 941 Lines: 26 From: John Heffner Date: Tue, 17 May 2005 23:47:48 -0400 > On May 17, 2005, at 11:00 PM, David S. Miller wrote: > > > I actually expected the new code to do better. > > Splitting could be a little bit expensive, but > > that only occurs at the beginning of the connection > > as we ramp up the congestion and send window. > > Afterwards, we should be able to release full unsplit > > TSO frames onto the wire. > > With different (larger than default) buffer sizes, I'm getting 63.4%. > Not surprising I guess. Thanks for the data. How long are your transfers? Just curious. I think what I need to investigate is some kind of light cwnd prediction. This, plus some TSO packet coalescing logic when we undershoot, should do the trick. But first I'll study the segmenting behavior of the current code. It could be simply a matter of tweaking when we wake up the user when he sleeps on the send buffer filling up. From dada1@cosmosbay.com Wed May 18 00:50:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 00:50:25 -0700 (PDT) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I7oBF3004362 for ; Wed, 18 May 2005 00:50:12 -0700 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j4I7nDXK015002; Wed, 18 May 2005 09:49:13 +0200 Message-ID: <428AF378.5020109@cosmosbay.com> Date: Wed, 18 May 2005 09:49:12 +0200 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Andi Kleen , Christoph Lameter CC: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Wed, 18 May 2005 09:49:13 +0200 (CEST) X-archive-position: 1300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 80 Lines: 4 Related question, is pci_alloc_consistent() already NUMA aware ? Eric Dumazet From razb@bitband.com Wed May 18 00:49:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 00:49:39 -0700 (PDT) Received: from mail1.bitband.com (fw.bitband.com [213.8.50.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I7nIF3004303 for ; Wed, 18 May 2005 00:49:19 -0700 Received: from [172.16.1.51] ([172.16.1.51]) by mail1.bitband.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 May 2005 10:48:47 +0200 Subject: Re: tg3 crashes in scatter gather mode From: raz ben jehuda To: netdev@oss.sgi.com In-Reply-To: <20050517.103853.104033596.davem@davemloft.net> References: <1116311948.3021.7.camel@raz-laptop> <20050516.235321.41634951.davem@davemloft.net> <1116320352.3117.75.camel@raz-laptop> <20050517.103853.104033596.davem@davemloft.net> Content-Type: multipart/mixed; boundary="=-SATGj6SCZ+O1x88muTIc" Message-Id: <1116402526.3018.3.camel@raz-laptop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 18 May 2005 10:48:46 +0300 X-OriginalArrivalTime: 18 May 2005 08:48:47.0304 (UTC) FILETIME=[67ACA480:01C55B86] X-archive-position: 1299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: razb@bitband.com Precedence: bulk X-list: netdev Content-Length: 224160 Lines: 2931 --=-SATGj6SCZ+O1x88muTIc Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-05-17 at 20:38, David S.Miller wrote: > From: raz ben jehuda > Date: Tue, 17 May 2005 11:59:13 +0300 > > > I am sending you my code. It belongs to my firm so please be > > No, that is unfair to force me and only me to be the only > person to work on your bug report. > > If you can't post your code to the mailing lists so that > other networking developers can help with this bug too, > then sorry. -- Raz Long Live The Penguin --=-SATGj6SCZ+O1x88muTIc Content-Disposition: attachment; filename=streamer_sg.tgz Content-Type: application/x-compressed-tar; name=streamer_sg.tgz Content-Transfer-Encoding: base64 H4sIAHbBiUIAA+w9W2wbV3ZDPWyRdiwnzubRZJNr5WFSofkmJUt2YluiY21kSZBke4FNyg7JoTgW OcPOQzaz8a4XjlGrgoqiqNHko0C/inzsr4F8NEAe2zoLLIqg6KL5CFCjSIEY2Y+2KJB2sV31nDt3 hjNDUjRtWc6u59iex733nHvuOfeee84ZzljVFIGvCkpOXYpy9whisVRsJJ2GMwX3mV7HY4lUIpmK pVMJLhZPxDIjHEnfK4bsoKsarxDCKbKsbdauU/3vKKg2/U+cWbgnc+C29R9LZxLpOOo/nUh6+t8O cOt//h4MMxaPxTKpVHv9p936TyYzcY7EtpqRVvCA63+spgrKiqCMKfyb+aPn9JqowU0iFYtHy3JV iBZWVBx54H7z6cG9gab1L9RkVdRkpb51fXRc/0n3+k9l4klv/W8HnBFVUZbS0dcERRIqUXM6eOv9 AQH3+s9KmiIK6pb20WH9x5Ow2F3rP5ZOeOt/OyB6il8WSmJFiMYj8Ugqko4ulnVyiq8TkibxxFgs ORaPkwT4aNHo4sJ8PBBd4jXhPF+PFBjGoeiiLlCMeIzE02OxxFg64cBQZF0TImXWPtmxvSoXlgXN QkjdJkKuwBfKgsXXSHdoXbDHlkxkpXaOIcUZkkISh0jsEEotPdIGSVtqiLpDT3qxJtYszkbd7aGT UWd7FReyU3pu9cRjY0kH1mRUE1RtgfG3QLHVKACrERTbjVHBGDMlHY85+siMxUfHkukWU6DQciTQ fmQsdaidjM+3FBcgpcfSjpl5v5fS7yS47f8iv7TlfXT0/2Jpd/wXT3vx37aAt3IebLCvf2tn3+I+ Oqz/zEimaf2PxGPe+t8OiA7vJ6+j/0cs7QcIwOt5CANKpMxLxYqgEq0sEPQuiCL8sY5+QCQwHA0E nhOlQkUvCuRwRZT0C9GqXNQr4Eu93FRTUluVLtOos1WNKIlaq3KtXhNakiqLS+WqUHVW8Wo1qlXy pYqulrGmUTVkuklDtjKH/+SoMBwxexFzaoeaSJr+5FAAwZCvRJbO584roiYE/EyyWllUCS0iVUEr y0VS5Ws2Qdf4JZC7KGkyMaRE1BpfAHxRI0VZUKUDGinItTrhpTrQkpZIAFWiquKbQk6z+gvCAtcL GqEqHi6FC7KkAmIZ5nwuRzsa1pHvMGGIRb1arYcrcqkEN8NaKPDDgL8iA/nlcXZBpVTkNf5IbBzm it9gj8ltmCzjxThw4xdLQV2qiMtCpR7M5ZZANIgaXA7jpQCBZj1o9L1s4IZt8g8B/BBowFSsKSCF 5eCQOSRS4mEwRQKSAUKGtBiFodA4RVEETVckEjwYx4KL7XmxxtLEU6Pmjrmi6JuxRBo8Bfcvk7fe IvstPNLoqrkvsVIRlvgKWeErsBqN0R95oVK06QbuXpeGwraBhFBbhBJkzByMM1YoAXKEBJ26DKHO KRKIjzFqdHbwZVWQikHzejlvkxcrxOtcRZDCy6EjR2IkRGA4fj/r2dWGsuF3iOiic/GIckGr2C2T KMP0B33JFVwkglKCxUFwUYqSgAsBCi08cxGIkgzrdJiews6FAccw0SVVXJJAiYhcqBbDVgGd+Lyy hMsBeADlQQvgNwcaOIJiDPjV86JWKJMg4IUCfhgrjLbAqwKZmp1YnM4dP76Ym5idmclOLI5BDTYA aLV2QA9qgU5RozgYtM3A4VAQ2cA55KfSpByY0woANEWphOhdo4UChgm2ek3IgdgkoaCJstSWMuJe xEMeUJZxdO6hTE4tNI/GshMGH23WPPTSZsXjfEcw53ur7lqssyE2dOcE8ptjsGQAUlWEigADsSTr mu/BZSbZzQc/NTNlHzbOBUmxyVUFy+j303nSJAlnw3CQyswwxcMhqgBKtEkQtp5bGUBY67cvBdxc XYw0ht1y1AuzE6/lZueMUTdIsTmak2sanTzjbcW2kJ2ZdCEv53N8pSIXctSUuNBRAg2TwHAMq2A3 C4WKrDb21KIiroAsaCHbVSPkPJgFQ+tEgFpjszTcF2YjaPuWNoI0GQm6HzYmUjA0TqLR/dgJr2BH KsgEN2MYGbGJN+C32XDaH1MYdU1y4KPkqtVgQVcUWCMHX+YBa0WAIoJtTIXGms2iXBMka/h4Yw0b fQQiyY3RssFio27GauMbURnbdpYYT8CGjQI2VngcO7G5PILNVsslOnOZD0h9l1boqumYHkHrIJ+X BGUMVtbiyamF3KnZydPT2XDAT3dFLDZ3yDCaaDT9rJBeQ0Mcwhhugmw4YRwK1eSYNRPCgYvj1HdD iRkeba7Kn5MV9HeASWCrQFZksUis4KkAJCS9FsTSEDX9uqQISyJmz3KFslIUVoJ2SuGhvKjlwbce MlQKGgUpgUotirhELcGBnFTCk2Jd4qvQNyVB6NqhIoqQOWN+g7oFkDKvQeOSeIGoZVkHpyAvEJiV aC5QA7UKr5VkpUqNE2BgeRFkQFEFEgVeo4w7KF8RCyBM6I6SxQaKDmwWFLGmmfQVwdhZCLimSJQv wbBJHgImc+4xoaFAHSM0BRbwO+RM3LKLNQQWfpHNB9s0tCMzG8GKaCeOLgGN1QkX7HVMhTifA8a8 yk1mFybmp+YWp2ZngkMlHvxmiAMIWitjz2HNjp1ePDk7HxxS+DdB1BKpC2W9yNsaTE9NZGcWssGh V+emhwwv7P4BCscW/9njfzPy2eoYs0P8n8xAzO+K/9NJ7/nvtkAj/je1b1kdM+yk5Ybh5ksCNc8R WOZgNvI0Vi0SWarUjUO+Tm0EQ63wdUFR0QA8J5Zg1ZQIdSSyi7mTucBzcA++ur0o4Ard1ToYgWpX aQBzFM01UutiUWpd2paIYRPbIW1SW2tVChbFWQw0zAdm7uJCWSgsq3q1uaY17fbZGLD3fJ0mRAIo SdQMtc3oy1FvjG3F6nIur5dKw2Fn4E/C2NoK8Ay3nwYd4+Zexgg4/GuHI0C9VqatgJ9mQ0Qj/YFh nXBBQwcBbw0LFTG8h1quLPBgfrEt7mklvVKphw2CYJudlRCQwQalIXWgisIjID2jdZlXiufRZeOL RfTaGI7hF5oyYYPIOUaRQ68Ix4+AG5swTt1ucAMPm4uFFoOfaOBD7MXn0amCGIxeGSki6jkeNvZU VDgxWtE6dmyQYJogw+A2jxuWnHVJZbRMK2WWVmJcUDb9fivI9tOYxOgVsz3YHvFAYrCYUe+wEWNq aJg0dD1uZAwYUFw6BaA5iF+Rq0yTmJwyBV8WQLARg5eSKICLABfUUpwvwwZprBEjOPI7qVupLVWv 1WQFzuDiADl0AuEEM8Wao8N+PMJ279AO9dxM0/Jadn4mO20amBPz2Sx2F7NEZ5o24FIRBBQCc6qE CJEEGkqUeWlJMEZCky1taM/MWtF9dpIE44cPx0PE3Qk6r+CN6Ro6amZ0ACVtaFr0/JRgItTEdWcS 07MLOGbET7bAR3e3wREVQh3WaUOC4GSfnHr15OSpY0E+BBoK8uRFMpNdnDqRO2HWhNisMLRqKg7z scUqT16x01p4Fcn4/Q4yC6+G/KQlDVWu4r6kUFuAM0GzZgLQjUZtlBcXZoG0izIUhlrRLSl8BfxL J28nz04snD6FRJyDPJvD8taDpOaHlM+TAhgWB7WpuTMpRo84CU7NbUJQrK2kTHrAHigC5rhYcvps WwnN/p+Zv966Pjr9/ife5P+lMqkRz//bDgi4HUBT/dZmfWxuCuyjbG7WpCbLFfbwh/l0Jy1zc2zi ZNbm2bkrjM7YltbIjuRMku5919UkRzBSdKVMjbM63tiTMRenyZo9u+WqZXkWRwuaxmkEzIoAcXIB jWOd8JoMYXcOHAm1JkoV3IA0zAHhFew/Li5xB3Lx6Mrn2pOuRF8w/Cbcqml23u9vzlO66NlwGig0 1G1ORUIzmqtwUTYib4OEn1Ygg05Usw1TBz6RGqZOj9EY73PoAdBhB525crlUUgV0B00Ddr8nugct wW7/HY8/t7CPTvH/SMJu//H9r1R6xHv+vy1gs/8O9dtzj4ojB0CTt4jg3ARs2I7o3lXeHBZjZhZC URIdBp8bzH+RbjYY1eSmZs8SQSvAfoDRDQ0gKjz6gNizI8609dJllIl5zQMsOmFRkBHgtNqQ7IPB vQh4riniCuY+IZbkWdCgyXqhjJ2oAlnS62oE+aUPx4aJnz35YsGfM8di/NqCBGiGEGnr+YpYMEg3 SNiDMxbiyTVt3AxB6VYNOyKQhGJ8Dq9LmIbHx0qNJ5z0FwAImqxaqDY0GuygQPRakcayLXG1Cj6y Iebean+cSx/X0F3Xbys2UVVZVwpCDoPvH8Qzb4xj90YZuMAQkxshuQQkZQ3jm6JQEKt8BcMU46EC aESUlhhBf1FQtQYx07NWNVEyWndDkybv2UjBH8AwBF1zRpUxiSVN7Yq2dvbeaePARdvkMZ4vWOGC 9WDx+DEM1/wHjh8wqByn2jSz8XjNS3UZUM6XZfo0i9AngDCXCziRihF8cthMdj67kF2EbR4WFAk6 ewvHQmZYD/IBWvjgKmKmTqCsKq/g8yzj0VoL2ixKpcTPzjeRj4ftazPUSHmwKc/cDWKYAXKMVMEg kxb92J4At+kq0aGroqi27K1FZ/iY1d9uSMkwdXFYB+h2MelY7GOanRH1N5DnsvMn2hJNtWLeyFnV wObKSpWXcHFYv3qIuNg2n9AaCZXWnaTvupPszKS/7Rgy3ZO36MMEtYbAlkHsAsaGrVsszi5ArN+E RN4igAXuRqgN2uJ0e7REW7Tp7Ex7tBSiNQbS+J2DsWnkapoSrgrVPAhGAk8rjHtKiLxOs1/06f9w KEi9ZU0uBbHS3jr0UpAm5EI2aqGQYT2oY405s9P2FHqX+7/d/zN+4L/1PkY37/8njec/iYT3/v+2 QLP+t/4rAN29/4/+fzKTyXj63w5orf+t/QpAd+//G/FfIuXFf9sB3vv/Dza0Wf9b+hWAzu//Z1zr Pz2S8db/tkCb9/+NueCt+t97aL3+t/YrAJ3WfyKRdq//RDzjrf/tgMnosqIVchif51D/7F3vql7R nK+CY4vFRgNFa8Ix6dheF2/zVrlYFYouenqxllOEwgq9vd9CeYCg9frf2rfAu3v/m/r/ybi3/28L eO9/P9jQvP7tpn9r+rjt/E88ExuJj+D+n8bv/3j5n3sPm+t/a3KBt6//eCIDe0EsnomPePm/bYHO +r/7XGD3+b+RWMr7/su2gJf/e7DhNtb/XecCO6//hHP9J2KJEe/3v9sCm+b/7HPBswC/l9B5/d99 LrDT+o9nEi7/bySd8PJ/2wJ2dds+aJmInhWK5FhNIfEkiY2MpVNjiYzjC412vEKtZn0985QsGR9p zODnQ1NJ15cdJz078q2Czuv/7nOB3eX/khj/ZZLe93+3Bbz834MNm6//SSGv3/3/C9Td77/o+k+P eL//2xa4Hf07XYR8131sbv8TzfpPxDNxz/5vC5xZmDz+RT+3lyMcd/RZcOTyulgpbobRy93cw3G1 3Rx3adc2Mfktgw2Avr3GmevhqDxQFisqFR4pCjX8RpBUqNM3YvK8KtxvltsCHQPCnl7Q7CX/zd21 wCX/fWbKAw888MADDzzw4AEAH/xBQH8MXEpuJ/iXfvg3mz8nFLS7yL4PGKdHhk+IFQFfKezER08P d9RZJr7U3M6kNgWO7oUu2DFjhp3gOO/jGuPdAWPt32vQvd3R9rQo87Hzw8eR0tRkRyJdywcjII4b 5E7JxUle6+jZm/RDk0JtWlQ7xpBW+ynjOwkzm7OE/KBIB3wT1eK0IC1pm3+5w0d5Z+0n5ic6sYPz wXfUWdZuPqjdTgZG313Wjv7UZPcdYJyK0ONaXxi/DcC/k/SLgXe+vi6x8yM9HRRlQh9r7zuDX1jo 2Px25cPG0b2A9nKxDQa/GdzB7eD6Bz8cTA5eHCwNPjPYP9gVLQ888MADDzzwwAMPPPDAAw88+LYD BsCYdHuSs/3cIVcUZfNp73e4Rzk5f25C1iUtjoWYskpy+CMFH8f9cif30k9jX10ahtuP//OW6Pp5 ZI+RzUO0x+0dROR+VjwBVFKY0vrlzr8Y/mmg9pcmY5FIFP46/2tK590AI3GY28cVqkXMMiVGo/Hk aGp0ZDSVyZBUIhofGckcSh5KpUedd93+/kO+A9Fu+vuPZCaZGGn6/Ucy5r3/uy3w4+z0CZ/PZ937 uF7OZ6v/8j3jLkWPQe4Z7inu9Oq/nz2z8JNf/R2UXP7yP97HmtDPbmRv4sWN7JfG6XPj9IVx+mfj 9Klx+gWeLv9q93r2/bmvfgNT9/LP9tLb9xq3Fwd6fnwECmk+s10jJ4kbVxbZzxluDe7EDgagARzX s1fNNrvxei27+/KHfRux9ew7ZvkTeG2n9fVzq1fm4HLtr/FIO7Ia712lhV8/7ir++sUmnKsunFuJ HWzkV22jsPh8x8bnOwafA8jnVRufV+fsImjBp7tPxufVzfh0j+3Wn/YzPt+x83mup3zQpo7V7NuX L77N1amexrrUE8KtpX6cD5f66XzoW89emiv3Hu/7cEN/2+rjylt48QEeWU9H76Sn/+uDnq5coBPk Eg5tjd6sfvzRv/X4Pp5vdKfR7vDI6bS7xTvp7s/66IjWrtFOPvvoZo/vs7lz3MZ1JNxoX2MT9vIH eNX3o/5b3/Oxmdtn62hgbu1ajRHqDeGh/3nAck6hPhsrLRAetSO4a0s3LmWg/mxfiwpc+4di7oob l0wb0VwDGxI32s8E4GIDMebKvuOjHZT8xp1I/YlejlunQt3gbr33W5ji6yj/9z/5q6fy39z66Nf+ 1U8/+p9nQx+vfrZKW4HcNq7jRVm3dUfPN65UmG5uXCmbVy6r5rR4duN240rR0ixe+UGzf+tjXax+ fOPKJJxRFqufvfvNB3izeu2PcEnSIxPX+qN/jxSogfUBx69D1TplZgOEjuf1dSrddUrgszV6fveb Q2y+sYMh+F46sVevfB+Og/HV7M3V01+uXUOSa7Rs9XgfqKuMalujzF/+kJ/buP5923SF+nOjG9cR p0l3SPLz1dNfrJ26ufbGl2vZz9dOf7H6D6v/EvrHJ/919b9W/3c9+6lv78Mn+9apWDc4pusL3127 VqHSbhLIlX/Sz13+ACt9PzoEKt+4jhgb1yuUZTyefBeK5+c29F9s6J8ydp6enytfauiSuNViKhWn 2K9tOl+nY4ZZM/1bnBZ9dNsp92w2TceQxt/cwTT9Wrvdfezr7zVZ6vdcltpW9b6rigptzlTgGqW6 Lvz3D/4w9/NP/hx2cZj9P7m4G3vSD8J+69MP4Iie8NlHZAjiHFfuG2gU//wTA9vdvFE+UEay53xf XTNrWnkfMK0f9u3d8QgceweeGnhhYN8ujuvZ5/Pt6x3YtWts1zjc9j7E9Q7g5dS+0QDH9UWg9pXd vXv+5OjA1L7U7sO7Oa6/n8NLjtuBFxy3k7UZMKoHIr7GjX+Q27ULGwWe57CTl6GLXXtZ2e4XKf5D lIM9Jgd7zC4NCoOUHLvZC87TPsR5eD+gRqH1I0B3j0F33z7oAls9+pg1BggkkAOOewzK9phlj2MD vHgiQrs2R/YkvWWs/0HEZ14+ZeMQFs3TTEb9hoy++5BBmt0+85hVy3HPPg6Y5sjIQza+9j9kMYRY Q99hI3sOLzju+f1UNi887pDNi/ts5A6YwwRPsc+hxFAQaoBLbvgxizWOeylNSYZTDI2q9BUY4NOA crC5FEYaQXxEippKYU1QKjFT7xYalsZdLY3S/2fsS8DbKs61R/KJbFmSZRxFVmzZsROH7MFbHCdx FrLvZHEWQkCRJTlWIkuOljgJEJYACSTsaxu6sJZbCKWFlrI1lAItpZcWCpSS0gu0FArkUqCU0tvl /95vztFZLPH8T57MmXln5pv3nTMzZ2bOHKt1qhiSsk02FBPWbmx+rcRrmqUQJOowYgCmyzZiSNJZ baqQGbpZl8vjcrtQ5TNPpR4xy9D8SXBXUGglz9ZajBBzjJpgfu6Q2hJinkkOkNMtVdHKeefrZCWw oFpttwtVq8NUqzJ6kUGtjJH4YoP1YfkKXGJBgS3NM9PTLdNahhDLjVkQt8KUHshK1NKS4VotrTJS QvxqPQeCZ1Sbkq/xGHrEWl0+kq5rF4amImtyfT6Jzrd7aPukW7jB2Ilw0zZazMmq2jSkTUp885Aq lPiZliqX6BZLaomexS3bamHrkJsG9GwLCuwcGrUq4AlZFEpD2wqg6K9h2W6RpMeoTuaKmLqbxKJD uqvEY6Z2K7Few/2mwrYbs8oUfaY2IrF4I55dxtEQt2SnUbRMmFBMna5fv9+ITebJa3WUMiGyLgcs nQXYLuPAjLLTBXoUai9jvJWSU9bS6CSaK9CeYGC3YnoiDA5pxUi0R0WNFPfmm4s+6O2zNCFg5w7J C4vnDUVpgXv+UJQ47R9u0wle4DE8/i60Ge/nsuGn2Kps86g3XWQblh8m7RS+2NZuCh+wuSgfUgtx Cfml71Kb9tTU7FyWRxqI80EOteRLOUSltLC9y21TVfta3BWGEue6keYwIwjJR/ERCi8ZLmvjSs1P Aq9ivxBXq5gQ12ixZOVa9sOeOHqRTT3KpvBeS4d6BMyyhShOwxbUaYOp9M7T/r//aoNYsnpDw4JJ kxraptI/fIjd3tze0towfl0s2rA0nG1YiR/hkbFTpk8Qin01raASkVRyt+i0TytRfyMlNJCKJ7PC 3olY+xhRgl8HyYST0UwoExsQ9hkSV0q2p1O5gXhyu7DPlVBZSRw/tJZLp0OZvf09qYSwL5Ix7hL5 M2yRvfmYxTKmsqQ/lQxZil4i43wcZyl+qYwLcJxOYZmEgyX8B0ziu2Mh/FyLsC+XeENJMrY9bMBX SLyJKfemw5FQNL49TpVoX9nNMeNLTOgqiU4oGQhFMqGBdCwSi8YIP0PiEwkneqEeEohfRxX2tTJi UknSnGG9xCcTbs6wQUZMgSWiSHWRIZ5bJToVyXX0bImexuwtjLbJuGY1zlxIj4xs4UgLs6iMa1Xj zBl7ZWSbZlXn0i9j2rVsekxSxkxTRtPV1kz9JLRl9TRucOH1i9atWB8SWxFjG9aDi6MPhy1Lu+CX rdIcU2ZBaX6voIRy/GoGJXIpVwpgcF1KkmLc8HpWKTRFcNIYW1JXEsIP+YVx7LRkFHC071Aogp/i CPWIktF7FKlFw7KpRGowlhYlY77CMZ2GmNzAAGKaZEwXxeBIKVkedy8j85Sxiq67ZZpWdkj+vIdW Bc8qXAW/wMXxEo4MVsyGH5TNuNeE0XrkbLqm6f8p8LhF1V4aTZTS4Wox+B5N2JxKVEGt7EeSA+SU yx8wyv+eEfe4UqfyDSS4EwmAKMMqHyP/Y7p1p/JjXFHjLiVTApsZ9r8GGF5fXmFWlIwHSV8+bL/h DYSTiVAknI0KZXQFVcsIBUA8G+sXylgU7cNPFVPqYa9MoWhVjy+O206oox6ZqJRciG956ej1FC43 /VaVsJVxAhYpSsdAMQMQVdo0RTOAH2MRpWNvgAH5g9fG+qBCQ8jRSaWWjn8EiUxlOGBDi5+wXhql cEsHgInvD8tXM9fuMDW5jJ6kciKgrRXA5DtVknlkypS8yY52AK2zHRpRdmC2TDMrk7RtMycxCSqD oF25cBQpZ8EY14KGdG2TSDSGei49pAZzcY69XGWzXQavyJNLIXj4hnxQEjmi5u5PRXEvS69U0ycT 8eROAFepQKq3F8GrR5ZqxGXLk1HS2DUq1wFZ9rWoKn8DNf7S69ZQNs8PyEGwrPQ66oC7wwmKAEYd u3pqqFUgUeAactANny2V3aeUuxS5YuS3yEU6M1xjhKijIeOdWlewUZuHWSe71P7JdcNLNCPyF0NF 6fUjJZBOxPsRvkGtJYSlshvVapLCblLrBH8vGeGb1fy5TIxaPz38CLtFTZMxgl9RE0bxk2gAjqqt KTPYk2Aqt6opdsb2Ivg1NZ6pysK/qUIonG3coQJkQe2RpXerVgiK0EBPyL0mRIq6T71dvRk93XdU 6RomUz6wTUvZG0+oKR/Mp5SYTPmQmjKjUfmByi6hNqBHx0oiu7QqeGynE7dnn8wX0eDHV5dovWog y8hxra6oKhKxJKCnuJIpPhpn68Nu5jSLl61cJMqmPk2Gaz+m2d8SaiU3eMpswVBvIrw9IzxO253y eVL3FWoxngqbOk2qW0ypPV41WFb3J5r+eSrVoLvuNrp6TlGDlXW1NEn0VKlBX92vnbxBpU556h4g QR6fGgzWVdDw6BmhBhvqfoz+UK0Gm+pKEQyowfF1Z6CgkWpwcjDUH07vxGF4T63t9mqeMAQxqsaT wlNnu4eRdhKHDyVSwjNKVdep6m0VnjEq1BUMpRLRkPxZK+EZayvn7jcviJlgKJJK5PrJ5gTbAU69 MBjanQ330DNByzDRhvHVPmZxXR1qapJtdxDBJUH+zV3hOc12GQNLg/ksnbaxXMbKustQBbNs941E sDsYGoxH1Qefp8sW43ybgzwSCc/pKuGtwVAuid+AJBELbEc40TblOZf+rO4MLTsjhDuuPaNvDfLA gWqxOW4P4hn9FtKjFZhxrwnjxiWbzhw0nfrBOLf0YT02NDP/q0Tf2T2S1guez8lBsMy5CnMMnDwQ ztVqmxp1lGIV55qGUGgw0ieca/+DDT0O9AjnOuQN5NxykCv1cPkeXBzDPRjkjrgxyE2zwDVGSAg5 fOZiwrl+upubLg2g7QLkAi+qtuul7SY2MpFtv8e22y1wjRGiARSkMHPgAbSEBk0U4WTXpYykSLfq ZXgk+5sBw+t3ktry+nkU9jxEDoLu8loiTPNMUR6UDU40vonHbt3IPPkOgSyBqzyS/EOS/KPM8kkm f5cH5DsscI0RAhOYcbLrUp4FK3j9d1LS8jGvgtXyCno+ULCyvEFj1TjWyGq0ZFVGrKYLZAk0VUhW yEplrcHFsbECrGZVgNV0C1xjhMDkVWb1KrPaSqAbXjymebrUG8kK19JsBQ+E5I6+r0I+wxzwOKKV 5Ow/hZxL4FwN5ygcTgKH8n2PUnqQEn23y5UlbZm+RLwnJH+8VLhyl/q0OTT1Mf6iyrX7MUWuD9VW THNk1x7ZjssI4x+Rlin3aYtDevKkVOxcbVkYkgrOD1fIpSA9Z7KpwYhE9992ilwEhvinsCV4wcun yCVgKBRLRiV2oa1KLv+IYDwZkj86yxyE6xJJqglx4T3muEtl3HhzvmxKuC6TMZPNuRBzUMY0o5ay 4WysN5cQrisk2N7YgLnykQoe6jqVrkrDyqBVu2eZbGxAG3IO+7hd3McN4Fq8z63oRqYDihX3mjDc tx2U0IObewsNKE0uzIxSuWxPrle4rr/xFO2OSYiqSrhukCjumXycuW7R71g8uZtm8fyb5/kbequM dnM0IUlavNOQKlzflBGVWiUMCNftGAToFnJPcN0hewJuXTYdTlJR39rIjahB2XiKoVKmGyuFh/T8 YCxrBu2SBl2umSRyQqwZ95ow1Awau1O5glw3Zu1O5UYGpH/UMEP/MbS2FY9yoifJHY02hsFX9iLk 07PoTXH1h5zjE+RAC8z3Oz1xvomeEahC2npyx0yoGpKOK0mm3DyfUy4ld/S+qiG9GW1L9uYC/dpq UP1JZGn47KNs+DYYflozrJtj50bNsVralYul90o74T+wnT/Djn24agfDgQMhycOplA2H+5gyxJJe f9HJnKaV3NGLNUPwsDWKqRg2JHe+QmNxzpzC66x9w1UlwoNW9nPQd/VpbU+m3zGhSusSBepm574q rWtYykmsHM5dRHbtftm10SOSlFm4krJZVypTfYZm3WkmbWzXW2W7Rjabo4fb9WL4fy6suNeE8Qg/ HE8B6fYR6IZ3uFZWIhXGIJXi74uxJdDvQ0IM7y7lZiSXXowbLuUeADyELBtBRmjOWeY6BlnoidRf 7x81TKsvFfnOfTxIK7ImHkA2qhelcUShQS6e7E1pkjePYBnn4OKIjoDkGfCjUDPuNWH0pEVWkGzC jIJYH/OhHo6xsB0U54ZXbyLC9V3k9L+Hp/G0w+Qdu8MvBIKTy6fSVCoSFeWnIc+pLj+wlhKJtR6T jzjWVt6GIklb4A8j5OMbRojVAC6O3X48vv9vBB7fLS0WvMaE8fQtkurvidMSXZS330GZaHLQ0izA LTDfL81fJM0fZDNXsvktfjbfbMFrTBhqASad7LqU8wh0S+9hhg+z/3rA8PpCS/L7F+XT3x+WR3g/ orxTrpOW6LsY5TMOGCCZaqa2T5DMRWguGUrgE2j3pL/7tZ26cZhXqytkzzEP1h0vYZvO82CJ7DSe h+RahNpWBo8rz/flSoR6HyZVnkfUp5Kyr9rQtJphVq5ntIZ1fzXX2+08MX+oGg3rOvhfKrHiXhMG pu5quJiuu9jvUh4l1w3v+MYAFUn3LRqL7M6G0rFMLpEViudnE3QwtVMIQ3AgnM7GwwlhM2CxdDqV FnYDkkzx1maJ8NxGS5kXSOUez69L9Hj8xHhaeF7+3sj8nqUWk8KDXHhed9fo0658VC6Z6Yv3UvQb 02q057khGqu9t/fWaAOXISaWpAB21j1/uKpGe6Ib4sOJwfDejMbb80eZyGdOlJDfqHv+9HCN9sw3 xGL6pKV4V+YPcqdjWn8+PEKbuRHCEt+X0Epl70jD3W/B3VfNarf/iRo5IUI6x09qcPuvhf8FxYp7 TRg9MXB1wKE2gLtNj0UKjH6fnOPVapQDMxoHIOkIsuTAxFU6jhrO/ReKcn9GTvkgdg1D2NpyKsjg VFbz/ukPYRk3xmJ5iKkquozuH5rwsfwDFg9VB1JIJyPzfcaFAXEqs2AD1SynDVLhBQAfNoJWw+jT lPCGGnQEVIhLeY78bng902nJ+zTxfNzzUSNve/ylv0aOlrzr8bEMKY286fGJDJU18p7HpzLkbuQt j7/KUGUj73h8JkO+Rt7w+JsMBRp5v+NzGQo28nbHFzLU0Mi7Hf+QoaZG3uz4pwzRHJ4aCE9Gheff cvY5mbFEOJPVIv4jI9rljoKwQZ59TJfck7DbILRkzEM2dYdBbmEIj2Lr5ogf2hRv0NAm22A+vxeh tcqQ3EXAtoTNsZN3EcbB/3SJFfeaMHraLaErbiavn/FkJ/s7cv0DIX6cb6FYN5K4lBf4Xr/Ad2sX YHgrsYOSX34jwb9pTK681Yi2UQY55t2DbLxbQZP7FA1yYZrwUI8M2Z6imNEnyJnh1CaI3Eq5jcjU g+l4NsbJ+2wfI3l5nTG53qRk8kwstpNTD9hGUcLRnXXG2SdC2loUy2mZJ5JIZWQRGVs3MkWMmUR9 JJXaGY+pvHPJCK9caPjYYzsW1KNVoob4vbYThnjJzBC9zwYpWrRKwhB/rm0OxU+chfZzie0k+Wsv rxcC4UrPBbYg+AjPhTaA1EOCTEB4LrJdzYASRInCc7HtRg6XBbkI4TlgO8qAG9ODVgHDgXC9nB7c Vs+t5Fu4OI7VY3qwt56nB60WvMaE8VQpCPcEu1DmVMDfpZxk/0n2P0iJ3ScNsqn6Nc3YffZcykJ9 2sO+bNXb1LB8vfSwptiyzdgn4RDv5Jadw5slV4wiOtjpqhgsydL6LhYRFXvqy9SXzbtpnglk70je P1GUnlGGjTnsUGcGYhGtS8EWiboGF8dNo9Cl9sFfU2bFvSYM4kpGQShcl3IruW54PdUNQiynxqR4 5zZ+j67eeeoenPLRKONTJxPpoyk1Pd3D/RoZZKUC6nBxjGkAmVL4lytW3GvCQOA2JnMbk5lAoBte z93ka2Qy3ZLMBo3M/gbTcBMqQOduSec+LvZ7TOcm+BsVK+41YaAwtQF04LqUH4IOvNhLH8jRczuz U3h7sFfvv4wGdm/idYr0LGwUAsELvTuwWYO35t6dAOWrmJY2gWSBYKNsut2NXOIWXBzbcHZnZHsj N902C15jwqg3IesTDeq4NYoYvs5sX2e2vRTphtenvYup6HoD7wfUNysVK9HUfPrbj4qth8rUaDyj K/qOoik+N1qIbL+YXHFJSbZftlF1T0gA6KcpSoW6FaQA6Evl0qLioLZrgiTR8F5RcUjbKAGSokyX axskBOyNhSmTukXkAzLImQ5LJMBpGDkikSCQeCZKXa3iSgk1ANren0319oqKa2SnaQK2L5WM0bRH 7saNV+4YrTeY1my+kUAnVe0vcXG8Mhov4B+Fn7Sb4TIjxI+JRlQ6XJdygkA3vJ6BMfJAS2XFN0to Nc+bQ3grV3Ebehdqj1C5z1xxu4TKlKVjjLP5ON8KYy+HUSp6Ny6O81BCxbYxQn67ZMa9JgzU3hwN mnBdysUEuuH1ydeJFfd1yDdHmfj2UDib6o9HCK2s5peMv6eoylHfpyye+iYhELywsk59yVhZD0xt 2e0CqQJ/GyNb9tQmZtCOi2MmPt0YWdHELbvdgteYMCoOWdGv8i0bhp3supR5FOmG10d0MzG8Rzil lfl9QDE3Ubayqlp13y2XEVVB2Rh4nT4QT/LblKo6tc0qP2kybbYNZPvkA5PmREipVf0HUszHTPpz kK44AT+KM+NeEwbCG5pAHq5L+RfIw+vLF0VrmkhaVI0JjOX9r7GY1pji1IMSwubZdaoQD9Mkoqlq YgneUmfDkT45cauapPVKdQwcSCXikb2iarLWOTUcQ6OomoKBTNvX7IvRM5hjRdVUfUczE0kNkOXT 9K3M7blwOorXj6KqWe5++GRFU0Xh5SLeSlW1aL3WECOqWuW+UFBDpZU2aaVBWXaq4TZ0hPIVEM5m yax2F6CfanYQF8f5ODlcEYb/YacV95ow1HwHVy9cl3KAQDe8PlM5RL6dUb18vF+mRR4O81DsTLzW 9T9A9qsW/5RseFLjhECwuWoeFmjyVV3V6Rua8svT0GCYOjItIKvm28dqVT5AdcLYQhiQtc2FiKpF Xz+VByp0qGkChQSWjJMd6oJxrOhSXByHx6FDhcZxh5pmwWtMGHUoZM1PcWupBmDYya5LuZYi3fD6 91OdVa26jcIe93ghEFSqVqCp5fr7qTGtVBsZyHUIpAv8USWH9FRgFS6OwHiQ+6ck12HBa0wYP/TH 8UN/HPz14/HQH2e4NfJ9fdUaflP4Kc7DnL2AEnlsE4RAMFC1CS8hsAuBn3WjNrxZ7wv96ivEqjP1 ftAfSg0mY9Qmt+h3pD+0M56krGfpzb9fvZtb5d2shOjpAkUHfjteigYFElKKi8MzAaI/Hs+ip1vw GhMGoTDkZNelDCfQDa8/C33RMRT2XEcOgkpVD9jksrE9kmPEcBc6BdIGdkyQhK6ThG7hgr/OhC6e wIQ6LXiNCQMJGHKy61LuBCF483chlYxg2lDVh8I9L02klRK1p4aqJHFLD6pVldIbPmFp9e/MVQ3o L1EI5gk/1f4uWftuPbHeV9IyrtKQQ4/MyEifjJR1ktUHHcIGMn3hNFpCTp0vKN+eWHCYTw/KyZE2 wEAX1clruDh+jw/bK56Cv63EintNGOrsONffca6/PxLoPm6sP60kUbUbuP9+miJW7XdPoso8RA6C ZVXnyoN5O6Wm89T73DiM7FedrzZg3PUZAhkD2ybJuw4DxOQqXBw34C/ljdwzie/6DAteY8J4Z28S 7/VNgv+rk7C/N8nAWntggveBRyiGHzP+NhA6/BzInzeZWgJe8FddhuluWG0JB/WWQFg6tisX5xty SG8KhA+gz6J3Xq53O4Lzd/oKtRngCFOzQHmB7slSM8olHRfj4jg0GZoTk/kMU7MFrzFhvHHDmp9j zVcR6IbX31VOoq75OoU9w6YIgaBSdZWs/Kv1LtfaIpAm8IZKBGnJuAsXxyn4UnjkZ5JIiwWvMWEo HIac7LqUagLd8OYrn+rlJsyCPCcp6qtEp3L4JWjfqRzVTkwMvzQ+XKvjcHq7GH6ZfMTy1meYumsC BzTF8IN6lVN97xbDD8EeVbbyzBTDXLhNf+YlYuFkbiDUk+vt1beSP5U6T7KeL6Cn4g34QcyMe00Y FE6ZAoXS/Q90wuvTDjL5nsDGiE8eq/M99yiOK8kjd74X7kVAnm/yvYwDDj7tSJzvBB93MpwB8705 FSuY/LEm34cXw65+qMn36Q1OuTNverSMGD9mvAlWx7oRE/5rggnnMRgRE/kBdHM7totIor9zcmh9 qCeVSoQTA31h4Z9FFbo+29KCfZqMfJXc0mpMskggs81mQ8Yorar8XUOzdMg4La0daXvje6gb+WcP Td2pxWrpFaTvi+0R/jmFbVOclrYMabU32MI/twD/FkMKLVslsiVivVnhnzc0y3Q1UkvdgNQpmsj6 Ty9MiOK0tPOQNh3f3kep5xcWy7Fa+gunEJKJxGk0iffGqT4XFJDQZkqjZRU2ztuXGuRfrfAvLCJe S5HPZ9fyyeP6/kVF7no+ST6noufMCP/iAvma9QT5XGWca2d8YJAyLRmaaUY+Op+lEllyyTgfevAv LVKQmiCfq4Fz4Vh3hGtkWRFh+ST5nHzbwtEduUy2Nx5LUEtdXiBvuzmRlvsB7kVkTs26olgv0pJo GZeDb28iFdYKXVnk5utp8p3EJguN9sTpDp5RuFJltKnPxlK9nGNN4Rwy2txzw/EEZ1lb5C6oCUzd NzwwIPzdhXsLxZkoYRno31AkbTZmItMTTwr/xsJpKc7EAUk3DU06jaNMAwjeTvk3F+nbuaxp1KAl bZK66ZmF+zbH5scN/89o2PbPwOtYJdWuP7MsGfMHYzjXsNtxcdyDv+RQcRD+NmHFvSaMnksowqU8 PZXffE6F//52vAUgr6+/h5faNP47Q/yWxDVDCPlGK00TlkwX/HOErXr31P00NXyaMvoXkad6ECsv /zIyXc0HwPx76fFYvbdsGh5O/BkThoHAHtjzJ2kiWL2vSY/DhpZ/IvYw/MeJbPW5D5JhZd80czUY eCyLqOc1m0PioS6W9ygujie7+P0vcu4vGYLfZcXFaW8C+iHVS/UFBYvpCGdwtn7Rusi6FREy9Dxl c7wIa821HZQ1tktUHyiYszW2ixhG1reGxG+Yw4t61o3ImsiK6oOFsyayxbK2fA1Z56KWDhfMOz2S 6h+glcGiNWxgB78usVnf8rW8AjP4eKX66sK65etaWBHYwJAWREvNdPIfwn2+vmC+9l6a1yPXjnXr W0L8UYlNL1eVfw6M9Kd2x0T1zYWtIHLRmgjsiNX8XRC/fdIFNN8OG5HUwF5RfbSwDUR+qY2Wd6Zr N/8bX3rz10R2RIwmWApavGhp6iT0X9R3q+8oaKKlNZsKSYhmqnRX47xJYXP8D9/NHmQ/RA2/+r8K Z2/J4tV9VssdUW+nbAv3IPc49L9jRXLHdhlzx/UWheIlh1YbjeSi+oGCFtoobtFuWWibLZnKhjjx Q4WbnhrPKiVPLkHY0UfxbqiLFvnaEDNHuAMz2kOrcNRbBOZiOMBEH0gmKwLzMAZgpl+NjAIDh089 aMhyRKCLR4k7ZxhHiXYkXoYhM1+OOlJQY5zzAff8hbg4ln+ADfAnkJsLMEc0/wMRct8xgNnSisK2 p7GHaghcbMM2wIKYNmOmnnlJUV5qXoxhWtkYc0XH6pkaqcAKNUZ09Ovg6nxyajgyT/NDiE7RXCWc TaUb9GE1sKY4+cjuBDFHxWvMWz6CmXU0dgfWF+U9sHJRQtalgYZobpllYDBltghsLGqhf1lBC2mj hUkisKU4hQQZQJMwG3jQREEEeooziBcy0PIpDFTasdtUvNp4XEd74p4ka062mpY2IM/TCi2QLJ4/ GSuaPwfkXnzHtKt4fgqtCslvX1NJyw2cLnNniwo3Z06Y9WNe0M7zgnY+/96FeQF75aeA+CqwHAs8 YbO7+CtC+6jTzRME9fwL5giP8xzhnS5tjvAETjXIOcKPcK5WzgOOg76cLjw5fTZ18kHDfOFcni/w nODH3Nuvml18TjCozwnAijr0WFwck07Hs//u2fqz34g/YsXFaX+drT0WnilYTH5OMLhuxSAZ6qBs ji5Yaz5tjjoneK5gTjknGNSH4S4964456pzgvwtn5TlBwawt352jzQleLJjXMCcYNMwJ9FNN8nH4 5znanOCVwrrzc4JBdU6AzKJl6lxtTvDbgvm0OcGgnBO8PzJfOD9Ipfz03Pyc4I3CVuScYBB2BM77 2OT5J11A8w/m5ucEbxW2IecEX2Kj5Yu52s1/50tv/prBHYNGEyzlM66PznnanOC9giaGzAl28IEf m2M+383d87Q5wQeFs1vmBIN8St2mtoXH52lzgo+K5DbPCXboLQrFSw7qnOCTghbUOQEXapgT/K1w 09PnBDtUnlwCjSYYGZzsupQWwtzSi6pw8Yk6l7IUMHL5QqfLd7aDqXRUjGxEA+6sXiAE9lGFUjO/ YVB7GVqzAJGnjphPw0XNohmh0GAoG0v3000TNUtwl5TSkTTR4IhIKh2L5voHRM1SjrEFtJh0LIuD hqJmGUeUVVJE4OTpcj8UBeNEBy6OMfixnZHD5mM/tK3NgteYMPkhFzFmRvEkDclRUbNuP5k99V7m 282FZ7KpAbx6rtkoC8+zQgQL2WRgdWC++jJasmrn0mcyq6OSVbsFrzFhOiuYHwCl0FSwOTlfH2zb kUBbfS6SJa1gi2thsdQBP98Mc0SZGcRNhVwnuy5lAoFu6UWRTnZdyjzA0hvm1GFOsgkwvL5oHAe9 ayNxQuxvkSOBstptJbtyKYoJa+/H0rF+Udujv1homyaQKfDIAllrb0kt7zLlk1xrLy7gWptmwWtM GPjAkJNdl/IpuMHrS6jkdjoWUqEXkJPQ2PWp7OLa+3pmt0M9/wR2HQK5ApsWqu9DFzK7S3FxHF4I dqmFzK7DgteYMDCCISe7LuVact3w+hIavcG7QG/UIqKnQpW1WZVfDi+B8/x2yxC+aGubLpAt8LnK D9nx4FzED9RF4OddxPymW/AaEwZOdzG/u5hfC4FueH3qB//BMQuGcUh+3R9sisogdiGDY3MywF/2 B0+9BCH1+/bgOP4UOP+9e3D8FQj3ZnizPTiBP95WvyYOTl3u5M10fNwebH3OIQO89R6c8RqC8iv5 4JxbEVC/cg8u/bOD/76B/MY9uOoLzsj245XYntc+0A5mN/EBJC2Y24Xy5I588Fz8yQOf8QPv4JXz AeWkrJv5C+mcqv8WPoOfY/lf4cP36t8kCB5/RA3xYf3gk++rQT6oH/wxH+fX/nJA8KnZDq0aOfMz 6/PVKrM/K8vJfw8Q/OmUfApp4mf8jXY6tj2eyfIxquDP+X1pbgkNFOjxdYu1s351Swxn/XKMLJ1f Jg+lrFqiDy7TcQyIBjxtfIEpainn4uK4CF/ZVsTgDwkr7jVhaEkfLUargutSDhLohhcfmkflabb6 6fwtOwVxkqN+9b2Uxl6zlNanErmwfmFJL90OPtVWvxQx8qVYW6dA2sAnS2TTn7iUC27GxdGxFE2/ fCk3/U4LXmPChKhE1iNLDGd/YNjJrkvpokg3vL485Q1I7NO/0A++eV+ZBOTX9MF3j5dxI9eRD96R SP6L++BHXpzzNXyXH7TbXqRE9aaP9YMlti8kaPguP6jYxuBr+MeX0e0lysHaH9mCvQPZtKg9bgOI Q65pDj+phpWgXP/W/lgFyoLpcDIql+61T6nfZ7slGI1tF7U/UbFKieEvANU+rWK+ID7F4gKeUe0F lBuWCcMhTWRK9ZsOYT+1jO/Qz3BxvLAMzeg++MsUK+41YbgX53EDemkp/HBdyssU5Ya39sblQnyb 6iNQ+y9bMBTaI2r/bQOGWgjxF/IE/UeFHARFRK2wH1AVy+9YRa1NRSoICYtau32bQ35E1r/coKs1 CmHtnSZhdy1nsvfi4vjucgi7FP5vO62414RR00NWlMtNz06yfrsMEuG6lIcp0g1vPX+wREuGUC9e Kta+Zn9pOZK9Ru7oD5erZ7DhYQffP9JlZr3MFM+kkmrGE/bHKcKTXiHEV9FRR81Rlq8wLuFm0Pyw L50a1M8nIC0R3oOLY/8KiOuB/6vCintNGAS4VoALXJdyCblueD0fk/MxTgQ3bFGeW2FsNPjQLyf3 k7TiP5bFf87F/IuLfwv+j8usuNeEocjLufjLufiSlVQ8vJ5d5FuH5VLDWcqylcZ7S6NSOJExl4/U ONOFi+P8lXz+C/51w6y414ShzLKV/NHlSj7/hfLhtS9ehQ+Z5F8ykot0LOFphd5w7tQFtAQ/RIn8 51AzaTgPfP1rCWs4n73HMTncz97JQC9g7zfwh1guhFepXyVMZ5MNpSzr0dfjoEBEV+LiWLcKojrg R/Fm3GvCIOQQizrEojYT6IbXXrvaKkp9NdFwgEWdvUoTdYku6lJd1GW6qIO6qEMs6tMvEWV48QAK RLQRF8e41RDlWq2LMuBeEwYhoOdk16VMIdANr/3zIaIMf4oI2g6zttbVmrYjurYrdW1X6dqu1rVd w9p+ubq4trCu7XOp7V+soeQMaHvXoM2Ae00Y9ICek12X4qQkbnjtr5xh1Wb6Y05Qdz2rqzhDU3eD ru5GXd1NurqbdXW3sLpjZxRX16erAxdifAIXx1us7pkzdHUG3GvCoAj0nOy6lHehDl77sTVWdfpG WMNR1vVhXtetuq6v6bq+ruv6hq7rm6zr0jXFdRm2vcCCuD6Ii+ORNdD1tTW6LgPuNWHQ8iHr+pB1 HSfQDa/94NohLVL7W1dQdgcre3qNpuxOXdldurK7dWXf0pXdw8pCa4sry+jKwIPYXomL4/q1UDa4 VldmwL0mjLc01/CW5hr4v7IWW5rkte9YV1iZ8W9pQeK9LPHrazWJ9+kSj+kS79clfkeX+ABLnL+u uMSsLhGEiPYALo7d6yBxyzpdogH3mjA+ZLWWD1mt5e9/1+GQFXntc9ZbJaqaHmRNF63TND2ka/q+ rukHuqaHdU0/ZE3+9cU1xXVNYIAXK7g4lq+HpqnrdU0G3GvCoAP0nOy6lDUEuuG113YXHUZUcY+x uA3rNXGP6+Ke0MX9SBd3XBf3pBz/v0TcDsP43y3H9G4e57t5/O82jP867jVhfF5+PZ+XX8/jfzfO y5PX/tch4rQ/lQZhP5GDf7cm7Gld2DO6sGd1YT/Vhf2Mhf2iu7iwhC7sr1LYP1iA2ABhfzQIM+Be E8aDfzcP/t28AbEBgz957a9uKCjMeuueZ4WuDZrCX+gK/1tX+IKu8Je6wl+xwvs3FFfYrysEH2L9 O1wcb7PCZzfoCg2414TxHHMDzzE3wP8eFMJrf2hjQYXG+/drVncyr+5lXd0rurpXdXW/0dW9xuqO bCyubo/hRMRGZvwoLo4nN0LdnRt1dQbca8L4k0BWd5LVPbsRnwRC3dFNxdVZb+IJlvn8Rk3m73SZ b+gyf6/L/B9d5pssM7OpuMy9ukyQIuq34eL41ibIPLxJl2nAvSYM0kDPya5LOUagG177rs1WmXya Cqr+wKq+t0lT9Udd1Tu6qj/pqt7VVb3HqpZtLq6qV1cFDpjTb+Z5/mae/2/WVRlwrwnjv/Kxif+U 0yae/2/G3/ogr33pmVZV0VSuJxGDrA/kCmCzJutDXdZJXdb/6rI+0mX9hWU1nFlcVlSXBRJEdTUu ju4zIavzTF2WAfeaMF4BbOYVwGb4t5yJFQB57U1bCrZJXdunrC10pqbtr7q2z3Rtf9O1fa5r+ztr ++eXaIvp2sCE+E7ExdG8Bdp8W3RtBtxrwqAH9JzsupQOAt3wznoe2pZl+DDq9lg6v2Bz26bOoZX3 LIqemCR7DR4bE71jizCuavWcxkXY85Lmi0znN0zzMfjnKFbca8JADSU62XUpb4AmvLPSZ5lpahP5 Sknz7TzNUyTN5WcVo2lYVsEo1vS4OPafxev/s3SaBtxrwkDtbab5NtO8hEA3vLMatpppWpYdPsn2 8rM0tiMk278XZWtYKME2MTgVF8fkrWBbuVVna8C9Joy3C87i7YKz+Lm5FdsF5J31KwvbIcukgOQ7 favGd6Tke8/WYnwNS59fSb6vMq/fMd8nDXwNuNeEgSNKdLJLNQ2+8M7ad7aZr2HhE5RM380zrZNM 151djKlhMQO7VPqFuDguw89GVew4W2dqwL0mjBdmzPRdZnqEQDe8s049x9IOjEuZBsn12rM1ro2S 67+LcjUsT2CZyp+Mi6P1HHD1n6NzNeBeE8avZs4GV7gupZNAN7yzThTkan3WNknSs8/RSI+VpB88 pxhpw4LjhCT9FpN7l0k/byBtwL0mDERRopNdmjKANLyzLgqZSassx0uWn+RZTpAszwwVY2lYQsAm lXwQF8eV2O2v2BXSWRpwrwkDs0+Y5SfM8noC3fDOat5WpIOpdCdLureENLpTJN2ybcXoGhYFME4U OnBxdG0D3YZtOl0D7jVhoIgSney6lPkEuuGddcJC1zilbJZUl2zTqLao978oVcM0/4Sk+hZTepep Pm+gasC9Jgz0UKKTXbr/oArvrKvDBahaq7ddbQ15ztMk5+3hYpwNE3eUQDxuxMVxNAzOF4R1zgbc a8K4NTDnT5jzbWG0BnCe21OAs7GOOyXfu8Ma3xmSb3VPMb6GqTisE4dFuDhW9IDvaT06XwPuNWHg iBKd7LqUtQS64Z3196J8rRXdJYlv7NGIz5bEf1WUuGFy/XdJ/N9MUImA+HsG4gbca8JAFiU62XUp 5ZTEDa/nQvJdQPG2xjXK5ohOYX22pTOeHMhl8dfh+eReKBverm2HIxfZvgwXxxHmMQA/WzLhXhOG sr0R8IDrUq4DD3g9zijeuYHHOuUtM48ZqVy2GBFkI+NeXBwjoiDyBXKzKRPuNWEo/GYmcjMTqSXQ Da/nVvJtRNU1dneBmX2MsCnZqJFRa3NvKj0YTkcLUrpVUrqdi76HKR2Bf6Nixb0mDDQaoqAE16Xc D0rweqbFhJiJP77XuLELAFPyxEyUOnri0Xg6xn8YJpwoSAxmqLBZuDhOj4HYWPhnOqy414SBzINM 7EEmtoRAN7yeF8j3Gr64a9zc9aBG7G4LMfUVYDgSiWUyBYm9IIm9zAReZ2I/gv+1civuNWEgszIG YnBdypsgBq/99V4htJK6MtnozJkF2tDk3al41OJQD22MT72GlgPvxP4fbdcCJkVxrWtmhwUExA8I mms0sOPMjcgFdpflIQ9F7szKQ4Osim4WJ8swLDO7sLuzj2ENYETRKNGg+ICAEhXFi0KEqBExIkqi iHy5GI0xGokvPgk3Gq6amOvr1l+vruru6enZj/jhzGz1Of85depUdVX339W4Qy/Fk/W0LzZnu8jQ RmTJpJPp0mXooklP0WoObZ40EF+tk6bSNcrQttCOBXoAxkmMaXlSuZP+Z7Gh4Tmt35/xVXp4AWLx In6vDtrL+xtljLrFYvE+i8X/LAB1K4UdyBcSchZtzm+VTSpJXJDIphaIJ9PLzsMh9hinVswfoy2L PTSC3TAelJg9NUFlzwG1MNTZYPTM0YnZqQVc67z6NnWz7LSFzK8wvkrPxCsNT7wZimeV2ssnb5bl ZdXyACP8VR3CAepXenEyS8oucbU3VhyPdRKhTCqhMz8Fnbl5dXCc6jCypNAjZ32bPYBzbAFCiM8+ oZH0SF/8DPZO0xrX5Opb+N6JfFeMiaNospQ1n4Nn3+QhUtbGrY51iE+bmR4Vi/HH8uShGEGUA4ER Db0IGU3Nhd5eaAQ4H4w6IcAzjGlpNs6l2fgHiIZe9vL+RhnqB4O92Scd/2hhX/zsd2WGkBLaIKeU 3Y284LXaxLOBhJakDf+qEjUXzxRPp+qblgAEM398lV6XgVuroVlS6ii/z15Oqo6kZdunsXMj9uso e9DdIF3/63IsEwRKZYaj1CfZI+CiJnvz4FTZJDWkcwOsfzSlaPoIlAMeKLqkhoLRPc1G9zRb/2Qw utOf/SY2EpKjPTlU9r4V8MMopQGf/AKUcbjsg0CPKY2IG4JLxnyIA8uZA/Ud7c1C76gQ6sG4xGRK pFG0V9mHsjsYGrLBSiR4Nf0k53GLH5mlpC8s00VRBhW4oBGLIvqz3/AmQsB0CYQXhm5rNPKjHHvx 5hL1TXgNjTAFcdrWFfgqHdeEHHgYWrt7Ocp328tJ+Sco+hM9GG5ymhjHDbWnYhlyYg81mIwN3E/z K9ziVCgfNT+ldGZ1ZqgG2/eOqdFKzm5EhfHZJzSZOtAXPyd0tOIa1/zUgvqOpnYOlGhPLWppoigT QV0YjqEhfGFgauK78yjmf+IZy2wqxbdoCzcE+ZlxdD6MaTPnlces4UKpxsiqVnQWBtjWXp9tZ8dI eG4RiJWGbow/QMUh2cbKDPD7RQCWa5oG3MJUPd5TRXtvOFlklZVqjI/SHHAxmH6iuei5k2V8uNY/ dEWFO0iMDEkrI3Rql0whQ0h4b6DIhpKqMXLBFAY4YglNo6lN2FhpJrwNhA4sNmZHPqDVWL+6lXWE O/BVuqEVHeR9oC0hjvLP7OUkNrsZw2ENNnGgjdXRQsKpIqpXrmnSzoVGKRG9K/aEQEYCIE3peDw/ tYSE00Xgj3Xo2630axH+pxakm5pI+Az/7T5eqYlxQYG2C9Dkwo7FjVyfhP9YhN+jTeVYZnaadQFh oXQzmiO+p0UOWtf6x84zmFUPQnuyAW1rEY56DXTnB7LqIAmfX0RfHZU1UKWjCloMpCetpD7jf8Zv 648dcWmfOAvjaJ8Qukdv9tkndG8rtiNiP3ECm/C9LCGqr04UE/Tw48EReHX1Vio87Ex6Zg0/EUSq DMNsPLwzuJnOzYdhSh5+MghPhr1NC8K7guDETcPEPfxUMFSZ1fph/TQ5A08QmKS9ph5fpQ1Z9KYZ +A2LZnl/o4zds2pl+3qyai3KYgv0VixG2vVKiOvFZ5SzOmSzoPVN4Ym3PIiq8yr9UKvS1VqVVrB3 RvIqXRPEU7PDsOwIX8vMDLsF5SuDh/CbVfW6IB4SC5W1GdVNquq+186q8Bd8lf6NfpLpY9tEdcM/ DoojZPpFqvCmoCnehCNDkI+r5REx+4hvxKF1dCoRXhNkT87B8ljwrulSMDZbPL3b43OGhme4Sfx3 SuUON5UZSf7wstBhD9zG+7XL7rUhKOun9Z5ZMzqFIe42S0xGkKyOtcu+9JDSNLtKMqP0rJ12420o uAfx3WZ5OQ77abfxWShfWzAnSfVD+Poc/j2irIxPNi/mM3pqgz3Erlth9ZoRYJuON3eR8HalN1aU US1DBTdL8WDgQfa0DtKqN/vsE/o7lenLC/Az2JTT09G6LyAyMtBRdEbiSSuZkXhmS2YkLMmMbM1Z GYlniUKPdhgZmVMZ2ZljGbkUX6UrckixfR16RrIjZPq7HXpG6uJfdegZyY7IjCzvdGRkTksv8exY j5sYGp4gJPFUpyMjdZUZOf7onNBhj3vFN3baMzJnz0huiLutZeRrnfaMzNkyMpdReuoRNxLvkXNk ZM4lI5mTpHpSzp6ROSMj+SOUuhVWL5eMzGkZaapgo0M8KDaRPSSEtOrNPvuEfkRl+vIC/Jx5Lp2p 5DBjCS8JhD7JFTtBqmJzK3UFBWg0f+L4Kp2JSVDPE/FbzMCMIxdErCPhLnmMXEgXVrzsSlkmEgi3 LHJwHJ90fUAP9cXP7w7oIgQntVD4ksAsuoxTk/YEHkgh4UsDOP/hSLIJ+wDxd6SF57CXrYU+WFJs pUdjaaHqDOvU05VsCnhKF+ocQBFffxgHepmF7AGuJfg8nR7ti5/BY2sJmVfflk7imkN6cQM7Zw1n l9Ecu47wYtvpbchkEjpjXL8BVxKyH5uZRd6ZiAEIlwexxG0hkcPi3cah33RpNccuO2zkSSxMz7c2 AIM/1N9/4Kv0y7U4Jb8Ftf0nOMr/gfIjPa1y0W4XMeHIe1KajbLs/EX6LVtGSAsNRN/I6tk3U6lo JfMFF45a2MRX9SJy7zogz66ho050nE1KPDzYFCN72FXdoWfC4ibxrpahu/HX/fyv0NBP6HgSeQCr hGC41+BT8detCFHowJV6PBi6DMNmZrzHVnyV/mIdm/9DuiXgKP/MXk7Kh/8AAwQMbWHjg/C8AtdP 2hJNqfrG1Hw6TPCn35/mOt+Hzg66/o5sc9HhWx3adEauhk4HjUBkhxYgXKbBjrnKjvRr5LOQ/yMd 8CKPa/JVQh42sNO/plH+MTQSNESRJzWNUfwiJrpVTJ7vhcK3l9KvOlTjaUshjRXG/olKTDysnIQs hWqgZknkWUt+rChEW+BEjAd0NSssmXhGxe8GxnA6Fkc/ClgAWIUk6XwZJwCBQSzLXHXk76H6Clrp gK1u89NtLc1tKWnesEuq+9McDtxG8z7aEbAriuHZVbH8XCh+ROsRec0ZTPZcthnMmsC9eI53TNCS HscGtebFyreMMzB8HXDxYuwfEPkr113MthjjXarX1/Q/iFxyJq1E5FhjF78yfelhWhZlW6q1VWCv KjoQtndR31rwWGy2voF2yr1AoGvt8ZgLdGGbXFSnlW2DhBlHJMu2QRqJnGxDJxuM+UykHX1xMKYz kQ7MZgZj1hLpfIWiDcakJZJ7HT8xx4ksQYUGY4oT6cL8czAuvUeufAsClyB3l075Kf15FLjLtuDn HIAtr1hPyJwNy6l/H6P7/5P3InYN2srTkkCPR9cjtnP2K8kvWY2V4KyklNy9Xs34Yp8t57lKo0Ei gQAHH8MLKDbCr7Avi1xFvxoRg1IhOR7deF6qIY3tKt7ShWMXX8WR03g5XaR3wPIbJXbxy5cLcfRu EukXUM6jgEpLv8llP4fkTQjpIAHKsmdhKtlI00ZHFSv0IwJ6QXMT9eQ0zROUxDIuSlyz9vwf0oIq NMNI7hC79IWUZs+yttGgXjievSspkVyyBK+7W9ycXaTdO5tWk6hpi7GOXiLOGLDFPkjtgwq+spvw 2AoK+KMtfGQR+yC17yr8sfnwqX+WqvogtUOulqoT8qnCdrmlrPahIrWXQ/lTmtPRm7gy0mRRB9sU J0PDrXJQhVrEeyUUd+D8uSwgT+Y8AxLU6Hw9Db4XOIpEjCk5rV9Tuc2sRafvBiA6deQKpTn5D7Iw +rx0hA1kk4+pA8/IA79ejwODVsgDB/QDmuuTJyqRV91FhI2EkntTylmbaHGRZUrkHUOEH/2ZOnrE COPFajoyfRdEtqGHJANCRi5eDq8Qc4PIAh45PjNoI/uZlFbp+EnXSNG0EsWmYboka+/4OCXZpCRN ObalVjwBuUMY4Fq5XJU+dMj2iV+vxJaIvqrkkNdyyKh7GHJsdFnK4SqtgUWC1b2shK4RYEJKh4r/ H6Ruxyh8PYcak5UmK9ZrroWvlXKr5FipBLfovk2HYJbZ/Yk4m2a5XR2vLmuJrRGAUs6A+ynk2HXw yFopZyzKRD2egxw2eomsl/6JrV1sgh9CEGu9yN1yEHUs9Lho9Wkr6dettDmi/Do5rXKKyWWSxJGB pDouxSObAqa4IU3irRDsxBCzWbqQrG+pT6bbu2wuzN24koWJbZFOonvFyUEU2IHn7oU09gHOkshW kWjsTzYDFJH/EEJsxCCRR2Sasb/VbFSE6uTr5NTvMSHH5n0HLRlRoXOU4E5uVZsfav7VLYRcfTuJ PCPwKurb3QDrVkvBFzgel3MAxndBDnt7RQ5ywZaZ+Tr1+0r0FSXq3qn7XS8lX1OSbp16EuQO0blM 9B6RHvUtLUjhPB50KfntTnl6crBraINsfJvS3WPqsq0A7XUQSn+SSnTpZldyqfdJP5I2XjJtZExp LeUnQuUCZPLfxPmupaNtYWJePZ2RJM1wlTdCFrsQRf8u0MWWU+7R2qzESwMO+QLRelPpDjR1vaLV 5wahFPnSoeQSrclKPBA0xPNH606ovI6zxQlCJb2YduT2WKG5DpvqaIMOm0lZwPEDCniACZxxBJdp 8Qj3v1FoRYcHnFq2ECs9Pc7TFcJ4G4Ij0ExLi/ZVUjVyWtCh6q5J4k8opaE2JbegawHqv0oqfqcb kU/qJ1YefA47BbDDAFvOYauoXhumeu7ekPgtSmOcoeHLD4cbJH5E4U0pHg+Tc0fNOG70x7RgC0b0 6UF5zmlpqk+ibu45pSVWs1SOrnFVzhceR35tV0BXBOxA7hlmT7O/qnpc6nDFNdG0bPuPm6RurUM3 b75pSbda6V9h0/fbOo5IqxYSkf5MmUh204QjjJYJLYy1N0s7Dd2342GGxJ+RFqKfdNNCJp8BrUmG /UTWI9dNK3Thh7WfuyVrGRm/TVla2v2IYXXr0TY8cl8pS1d3t07sXx5L2qDQulpaur6bli6sGZVQ S/eqfCathfyc7TA5F+viB63lrnWvJZOUF+Z03oC1IKw7Cn22fWI0VCKWD2IT5UxGn2pruyDzufQ3 bqGlIBtiXcvXMfgrNpt2Seky3Cd150CSXe4nkQNBMaFmf9MJNb/hKhYzDZBk9y4irwrB0eJali4X Xwu5zzED/YMQK69sSLVbzBuqgGtxSuFlKGC7yuggWUu1abVZTWvJzXt2z1uFZuRQUNdk47ShqQZn Ep+glN4N2s25WyPxRVInWma4aNO42LpPfB803scM6y8yqtnCvr0ltaJVJYZW4VgMXCMNHgs6VPPV Ky6VotNMe/krthIqn2Gt+plqXqgkFqSzbe0JtrOkRw33SfVoXYm7uo9mv0268HUeF7zqPFVpl+Tx IH/lr4buCVh/95S6FUyXvc+4UN33Su1oxl27cNUDt0sHTswPka/mE5XyAHfl/BW/Cqq/whWUwVJ1 rBY0bCpaqPbPS4jocg+IwiHofYd05fQCOPniME0iRG/0QMgfjFXQPwEjXETqj7Hi6CcWL0uE6B35 EXz0+TulI8O9YfJFYrYEiG7JD5A3EHU3QL2tYx47e1QKhDG8AOsI3JNxXp+P74IatkeOTBA6akNk NmncFDKDRuL/lBrRp+0aYkqv69in9FPXSu2D7tqZjIe+7nm7QjpsR5ol3wWgRZkuApTCp07TdhXb HL6GK/YKuSnm89hqXNInhHtpvdlnn1AJnZz0xc9TV9Ffg6AcvjE4oifeBk0LTm9uX5jKElrEbkYn sbLSWWNjsql5NDEUf4xOI1fxu9K3sHt9d7K7zz/A75697OX9jTK2M9o6tjPaOvy+C57hZ1/+JAbI A73ZZ5/QThTzAvw8CffoIMXohCUa82mgY+LGCAnDOEvByWkYkofUMMSd1TBkMgm4mcBkbshxN5RN daaybSnLjpqgnn22txNDjpcX3fHj+HvQO/TkerwVkuVxmOUxCvqw38GB+2xsFUFpcxJWJNfNzlmR 5YK28t4Gi7YClpJOWwGxCbSVtRu0njFvWs65xTbjRsXcCC2VCQKfaUf4Jr5Kv70PneYRIApGi16+ D+WC0cLKHYwWLs1YWoz/Rvq9dI8bo8XDTV9cF1/6FgsGe4V3lwXz4V3+wqvxY2hU9/Kovsji8d8s eqV3E0WE0cu/aS8n5Q0o0ggyBavrTp15g6M9BjSNOuMXzUaq4WgjvwaaRaopCOZCt+G1HDljI9Hp NgWRXIk4ImJ3AMsi4hTEMik6nAApoN4ElEXRKQTFbs6AXShblZN3xv2M2Mk7hZB0Wg/NX7qg1/xi /Yl3qvgqYGuknkLANroPPVNannLIkW8A0iL7+IqfRgMqTxh+kurhtNvrJCB/gBY9yA5YngOgRQ7y 28CCNqQ3sEEbKoRjEIrKExlnkzjpRF6YXkSjsg0OopEHlB8K0sH1ioLE3rLCKUjsLSucgoRziicF 6e19ioJ0eJ+iICEIgoIEwrGgIB3dpyhItS8qCtJvX1QUpOR+QuaMv48YFCSPKmrkJFgsCfQ4th8t OGeFwviyQJQs2lJOYnyxX56jSGzffcRBW/JAswhNSADlz2UnbSImockDw6A6HdVhYpdvIk6qU4HK CRKUAXT5XQJIJ0EVwLHoUV/wOn0ADJ0e5QGgE6d0TwRxauL9xEmcKuCPpFQ54ATF55fA1ChVXhMf O+UoV4hsVYkruLFYzRhGS2LTGfjBPkhtxQPEoFsdT9P8/TvU9DjLNDoT+yC1NyjTY4s3jWpVWrDq g9T+WcFOKB4WLldZsOqdQaS2cjMx+FsFeoXJ7PrCbHHR7F2A1Jhd3vNdB+eL57bB+fJGMNlge1ky Tj8AJxQbjGNOPiwLwQbjzrMz1+Sv1YFn5IHgSzhQ9iCx2GDWAZ0NNl2JvOouImwsUnJvSjnr9Ulc ZJUSeccQ4Ue3qaNHjNB/qkSm74OIYoMxGckG6/9fxGCDecSUz5ArEqTXSwDQ4hGvUShpHyh4x5SO wVIufrvCaPKBYSKwdzPFfw8EjVzmgVClD+MyEeKnbCEm7cwPArq3HL7r5gBBI6R5AFRaw790oO5O pX5NQQeEvm4+/jr0NRKb1wlRsdaS+7UQfOshYtLbfEH8Vo/BXEDoxDevWZWguuk+1G20ANYUdEIi GC68DQSDLOeFYFDeRCTPeJiYNDqvONgIdgIiDQidYOd1GnZQ7zhI9Q6AaNQ7z+YQLLsccQwEpPpT CSRIeX6ADBwSP3srMel6XhVyEPl4heau2EocRD6vCYVO8dOcmbsHOAbFz6uzWuQ/kWM9thE7+c9L 36QFigY+fxsxaYEeCGytOXGK0hYhvVFB7CxUB221qsWh7gAQNCqh17qDkQcdTtT1/znRSYYFERxO xC8BgkY/9IDgxETXs8g6hfKKDxT3s8gbCuM1HxhuZ5HoI8RgM3p1FIu36FqhZQpqe1FQdBplB9Pv HLykYPf4hWUvRbRHS8B9Yzsx2JH+4FxiP08CCd6kD6CMiaONVw8CTGNUes1ALa5lzmzM8v8FisW1 9PRIsSpd23LaDmLQMP1CFWjLtQp2oF9Yr7Z8W8IJ7qY/OJe2HPELYrA6fQDlb8t7AabxPb3AfPIR +VpLO9WxVZ5lM/6xsjnAr82Ms+0ZIE+AWY8SgyXqG9CWAQpST4P7Ffh43+COPGB4WjJ8IkEFtdQn qDsmiVc/RgzSqR84t5zQGmmngvzO8U2MnD6v5rnBLfZ4nBhMVc+TvuSwulaBxFsU1jifWP6cd/hO 4u8qU1OOqylcJ3FEipuc8EtiMF+9J2kardWtC2n9aKPEFaTYInDzNYWjO32ubFzhY4Jp8WDdOpS9 V130BDGYtL6xPaBJ/CGFWnCer7Nv84FqfWzYTmKwb/0g+04eZ3OrDBLNvVWZTx5/844Ws6xrLTbs SWKQdo+3Cx4e0IaVxgWf97gaz+SzrbX/qF3EoPoeVwdqqtjdLncnrMuU8ceUE0v/JU2Ai64eecCb 4uyniEEQPr6RYP/yOKENq/uUE9cffycurBmdsC5Ej8/njnVZes7QXxGdV1zokqrGOM7xe3381oz9 kmNdB3ANvrHXFRjx6nZFUTumbvToTOQngakzkT0v6nCOckVC1R+xIHVfMccMkrLnhQNBX+a784jL S+c+TWz0ZS9PxH0wHSG+Cgg6sdnzur2d8ox7fwrqEKB0yrOXL4LFa4+0dcWZj5gjdxOTDF0Qk5+f DVB1UqYLYYX3rk88NrK7uki7kESTDOqCaDasTy2sf3uGmNxqr2TI+qhqswSUtOvCgIXb42nl5TG/ XnoFsM8eYlK1C8Plj2AKYDqJ2zOVHfRuj1A+J5Elv7sI5MIxPfVZYjK/i0TPF9xWhVtStNf5o/wi UHW2uOdIbeeRewT5358jJpHcP3DhGC+X4JJiXhx4vhD/TsEOKBY2f4TL9xKTlu4F6k5Y9wjzGoku GetFoheO9UfK/9O7bSFfwKf9mpgs9yKx80f9ASDr/HcvZFdmvEfQe/6GmNT44sALx3yeNCBJ88Ub yBfyXcr3Ld2Bzhvxur7PEwfR3uu6i0XBP7jeAtSCcDkAdQq+15RWI+fTqRnnnVvtRuI7JJhk5/sB k5cddDj7ZYeTXyAmcb8IYMXpd4M28kEZOezfCFaQOjxfrOxUUP9P27XHOVVf+d/N3AkMCTCro9Ud RCzV3BkSncwLZlEEMShFZVYURbHXTHJnJpDkhiQzE8SCa7ef6tbaqvXjoxb7qW639aPVql2r7kpb y67WB7jrA0Fbd1WqIIjIQ1Zb9pzz+91n7r243U//SPLL+X3P4/c65/zuc///xV63MNdxBud9AJ9b pF/7rfnKIjJeBNdE3xH5ZNhmRLHY+sCzrjsE2p+tu0Pg63gEyv4UT487BB7gl+U+QpfvPU6X334f y+JuABt9soOG1qDKJvqOyBvQMl58hwx+hwx+FcmcQEXzoZMeV+qLK729LtM3rhqvv0LdvGzcfZG6 dd144I0Bf1Glf85NAqZBHlfp/z8t+jNs+gtb0yQffA7vDvkeTpCX6LYBJESoPPGWlxgbgpknx/ri Rb2osdhFOJOrvSgur3UjLcUQJUksnsFXTbLYxXZIDxENjBQvjhS0ci7DYkvtqJmCbOBC8Yyexyd6 stglDpwgGzg5Xs0VAHSpwyqkGYjx8QLYWE2XV7PYMjtqlkE3kM3xglappIe0Cotd5kQKuoGcFof+ ZLHldlAXkIz6M7+yE9dpN14KWSgB8tu3vyTeJINHGvJ4Wgl64GY7f7LDqkoxxEsNEsKH8vpAGmTc akf3mRUm9krk56/hyWkV/mKB2F0OFbPqIeK63wYpjPxaDaZPvZR77FI6u/2AlizVoYjF7nOY0eWo TbH1vAEt5kuEYqej501vfpGxwXRGq/JXRGRUzg+jIzlmGGHo7goDkmLD10hMCkns6FyWSXPeB0kS zuOYKjX+FNWxOaFNBi0taOFHX8LLzlrNiqxRQXeazZljVgzaOWx3k81Jm5BhB4S+CNK7DiFrjaYU BExctZZ8aJMIGLGSvY3GM04fJazN2hbuCdiXTsebfTo+QPZiGpdEjQKhtVKBmBplJL9xA3VBcupm +GkOgbI1DrC2imvj14RssLQl+5HjOZjcsXUODn4tugdHx9eQw5jD19nb1CsmMDFOet5k6ZTMFfJN 59oXq2OUd8PAxs1GZz/QYHQKLgaWwXcW2N6OE/tZ3fxzvBOnQcqeg9z0+gv0vkC2XmkVe8wx/ZOe qNQKhsNrvDlBw0uLMzrgKxnQ/4RDf9JWR62ni/gbfCYMi+JPk7zgBcaaEYHTje7siwAV+y0iPwHk KBabqDj4k9fwkUGMnR775cV4E1HsZX4TEWtAn0TrBVblKwgLTZdtRLHgX+V3II2nGpw5gH7954SO kg/LZVXh7Lc6lqK6EPwdLUUDkWLbXjN9GRBN/7/Ng7HLgUmxnQ5WMyS84c9qxodPHaw8Srzpwddh AVIsssXOZAWO33kwdjtBKdbqZDZjye8DmM3AMsNippFwuM+3PCT0eSBTbAEXMy/0Mvw+jSP/jgcv 3jKQzmbxXhStrBUzfA00UiBh8+Yh7/IG4H3PUy/eblDQRzVv9oErkR3jX2yvQQwv2mLM5oF1ZvXH ZrXlQAfuMav3mdU4TXlWju6FDf0KMWvJHBY7YMCEBx3YZkr4xKGfzWt+xfCtn9Y3zHyNjJMpm0Ym 41YCtQJrQeX+9bBH58yqB4pL68z+WfYbIVCcAnEMdJNUL7Qz6QmGzRVYu8Iyd6nZx8sSr3qqgIkc 9VAghtQJ5eL7F/UvumCJ2pnLplyKZmPnLLvRpYhH69hkLy29bpyhwlvB5tdQwX6hIAd5OSRYhoKj /BQ4cClTdj/88jTBpgY1hB9ENam5r3E1Q7ScYARZbKqXik47Blx+eYs1srzvh+3WClGnHMlaLq4f dqx9qshgOE2FbF/LWSpQXxjnOXp6NL1J/iakNs0boYhPtxFhoRmbhp8cbvrgN4qpVBRRzTvNquhb +P9T6/8e/I8uUPxnUGxutf434/8Z1v9p+B8nAn5Q1bwtqAr1dWyh97/i/40voZlYPNqjcbgBWQ51 533ldZD7Iu401kkrvgPNiH1LEnfFNtDbsnJDw2MwOcss9h1Hf8L48ndiGQDz7VKXHd5iLPhb3Cz2 5Y6qpXAWvtnK47EMOWPsVslZc37CqLlTEhXsXBpsIInLoG3ye6jGvEQYO0XCfqhRx+CYKHe8ju/E 1SvqgkJ1MJ8eqjBZmdmGfEAbFDR8dRi75hqZKc8Y8MUlrVjQsxrAlxpwXdAs+H4DDh+8hQXQIwY6 x0kW+ItbBXiJpq3M5soAvsUAVzjJBE+8aQdjXRMYyyt351cAI+xmi1XguExqowt0VE5gbbnCwIjx T2rDM6HQKvE/xFpf3sbYpnEwhZSrpSmYZ8CmgilrJZQPo46kwSJT1kkPE0E+AWeFco2E8x9ykynG zZT4rk7l7ySe4URleZvtkEt1FjYBJxqE3Pmw1vBaSnrvhDkBfrGDDqmgVin81A48/DIFRWwa56Z/ ea5BV75u1qBxtCTD+J+dc902EXmV66RgCzzDsBDLllAEVm44kgyfcMwPanFRrLXwBmMX4yMslDuo p0tjejnLlDulSY1mV+c47XvS8eOot+X5b3j2Y696CQArZvc9y7tvE3XGK9R9lyPnxePd9ALRlLsM KviNRb9jbCFk4kxSnqQ9nqGF8nOmvOhqfjeCod9cwBRvr3jx32rogqw6lqsOq5VqNqczZZOXGLpX tQ6c4luYBkme96Zn+4nXbP1bvPXbqZUfYCvHXYZ8vFGOivNLZoXylFHFzv8WUtdy8gaDLHKZKza/ yXclqJzfLM2UX3v2SZcDlRoArZQsFQ124800ykZP/m4nDGei7txFweR4zp/Vghn3ErAzB3Q9n86X htNMedXJ2GdWpdhB6sIzs1qGKVucsC4gmoDBXA1t2OqE9BDZBA1rNaa84ZICRBOALw0vF2Evqrzl RM0yakxoXhuEMXnb1WSkmhA9A4h3XeqAaALKEJQA8p7LaCKboEoG33iTG4RdkbLDtd47rEoLP6yP UexUdrnaYNQ4oCU9hx5yj2sIzCoXuMKUvU7oTFFhAVfmSmOA2+dyDZxuwkZgUgyMDDLlgEueqLCA pZJWzlCLDrmsNKtMcDq7YqRSHcxpeZgNn7q6K2mrNTmwRuD/6J6HRpU1zfJ62pB+2D0YVqWBLw2k swO4dptda6OXV6TYZxyn6YOEO8qN4xUmbjCdyxPwWBdwpqgxkUO6zlUf50aKGhOZLpWY0u5CdQE1 BTsljkDPEq9D4EZaIAZyRdwKK8m6dlKFictByO5yYTpzRbNeHwGLe9yagGoiquWRIqyEmS5MD9Et e7QhpqTccoCaYmGOyIyUmXKOGwFUE4EpjbLQjcC7NwQCj65p6QIdFDl2Bj6CYBWGz7KWyVVyOrS0 LE16m0JoCCvGctnqMFMqgigTkad2SlVa8TrlLUTUahmtVCURI9IzVBGlCq4QFofKszZlVFQ3U3VG BH8Q+G2RKLVw1RCU1au0MkS7H0iYWYWmHxcqg2emjJRXUzOUe90pxax6VIrdjQEoJI1fxV+5LCqZ 8o9SZCcKn2Zp5WJ/LPKyK80KpvxE2kQmZomGCsVhT+VBCY9WhaYPh47GaT1Sho1Ai5HzMuVl7Kup Ik1lykTqg6lGkssURcLkeapITZkyX8J0dyqllmYfMSVDqeMVve8yvDFvCPIlrWyrzrl7YmYdKNW/ YBT3jiQ5dSEEulQOwnPrTkfqx5bd8K44SsC3c+Yg3Vynog6UsuSzkCH61K0odauQKh5qYhd8q3uJ dXjhIBYbIllq+naxyS3rYzRAIOZ+t31dDgA0FvM70yze2KXbjU05ep+H3d5H1Nh1L78eWcTgbhGb JVsMxwrA46hLjSdxls02lrfdvoBzLMG8x7GD4hK4sVhmy4/5A5QrWhXC0Mfu9AXJn0vIgCVEDn0u IZgcuuVwYVf8EwobKXJxR7nE9fIKD6scFi14A4V8ERySMjXk6s4+0z9Bl6InMrp0wTHvGUwxl1ob T07w2EZ8+bnIKLxbt1tfD1W4dC1fZ2M5w6VNcHhp2ohsmJU7EvjFLgHJHhcEEl5KOnnSuzz8Pu7V cfvJlMvdyomO+buxXecnH4QZdApi+WwUMKRV8S2fyqC7xb28Bpv8vK3Jo++bR5GIr1Q3MmalcQ5D sOpSjb9cWRlzzwdeYWzplr9KLePudW1dy5AO3Rrf6e7WiZgIiG3f9W62kmDrdLOdfyqyrTWATPmu saLFBqVyNgLwYIByW8hc7RXVpN4VajAkzoJvVqUdlXK3ywTj9Nb9O+h4mo2BNcl4jGE61pBXDN9v et2IjMctmuTbdmAZYRH5N1CO8iJGwSb6jsjbkMyLuBluou+IvBfJWIziqopilIliZIliOGlGM5CH jqqNwytASF1sJ14BQipwrxyRcRcdIXJEjvQhBL8jcj8COQGLLWN0QkStsrb5323k/8vpYgUJz169 E2HXIkdTmLGJW3cxtgkKUvvJCcqBWXuc+izZwaXQyFFNiq2lFyoyKZHXxxCZqEdSjYkMJfi+rP3U eqTYlgmknMjmhsDNt59Wj6QaEzk+URPQjjpob82JbU5USumMxtqT9VKpxkROS5TKuH1p76xHUo2J nJsYKqdLw6y9qx5JNSbymnimWC3nWXt3PZJqDGQoXoKUE5T3eCjHGgMox9P54kiBtfd69SfUGMDx Lapa1VU6ddYeuwNoLYV0ZSVrn/E1KMsP77Ifc7CLMVYIzgtJanwLf8Lbd+Hhlt9imeaKgz7ZQcP5 +A2aY9+gefoBEKNYnHjDbsYuxyf9zehQElAua5WRfJXJM7ra9JWMtZXSZdzaMzy6V9bLLNRW1DN6 cZQ1MDm722FvZways8xo1WExygcrbsaf8O270eKrsXy55KZPdtDQyo92ocX4HZHXAzGKxYk37mXs j+MZ64+fNoKPb4z3CfWqqkFU4FfAuJ7WKPLZaXRNBiSJAGTx2SgJk/duSskF9QxOnRbiWDwkAtS5 3XSsbC5RYbsiyGdx8tmmiAG9wOIpngufGzLUEfVcTj0v1KISN58G8W4UMeeGD8FAbFX8PKlx/V7s gDmPmrSLBM16KwA/5kh+cM4LJk41cPfuxdP1jXvE+MRXeHSRMUIPIoedr7cN+dbasSw+IiDC9feo e2xZYHydh3xbJmg0qeMOwYVbVBa/yYcLa81nUgjO3QanVjVGpZwrVWFGxu/0EEMJcR0WhP58r01o 6iNLqDGohtT1XlKTnmC32NttYmFS0HElPgd+6DVV+zyg5kFcIXLnR/bm20X+KEikHeoWOWevh0ha Avd9LpFQZ77WgIvsqms0ifvp52p0vTjWjL8XGSe2TgRfcM9u9AX3ATnKi/jdJD+JBFxHreo+WGP4 etVES6gELiBd1QsVHC6WiIeEW1XxCgOeSHbaISmunQ4jc2KuyBJJD7akDSG4QpK86mOn+7YYjKWG 1oGD0/AnvHIfOsPrkYksdtLvctPZMgl/8Lw/Xn5SVeloFEuc6WFfjwtF6a6ZbvVnMjnYnFGGxd+K QY8rJ2cybFOAgTcx30N8lwNTJzzjIZzezgLj9cu9OF74HZFXQXuiWGw9Zj9jj+EJl8RcOf/EPjzv XtUgK4VsRk6cJUPIUfk/1pYtrIZYVMiuhki0upBlDW2rswUmM3nXPnvv9+EVHY6+Rx3Ql634Ez5p P/ZxI5YfG+emT3bQ0NLRfWg1fkOiB8QoFls/PsDY0zj2iWca8zqQMVaCwb9tbKOLJVkbT3Oktsrq woCeB4vxeRJg8mg6D3sTGUTsxy6H0J94rnEKP+wIpYNR/hjl5/Y7JxRebLKa77JL6SqtG+NMBNoC Fh/Cn/DhA9i6t5F7WHLTJztoYDQMpvE6dSGVJV5orFNJB4pcwBRrPEgJUP6An6VG908gYGMz/oSP PYgG/j0yUQc66be56Xim1XaLpmXmf9SbSed16qApnJU6DfFFdXMS6U30HZGxPVFejBM5TuUpSMZi 63oohUI46FvDUzPpajqvD7HENlo98uhBRzd0GRf4OHpiPe+Je6nF91GLb8QySXXQJztoaMdJB9Em /I7ID6FNWGyhzAz2EadS4tFCSx7+nnbCf0LthLxeHJqW1UcGYKsblVt4CatPxOr2WISxjvHSn6A8 OvsTxvC/3BGS2tSFqVRKZeva1CVLF56twnRWL13cn7pAhQmt9i9esvBSFWa0unDJ4vkqZIOtB4D5 WsjHpnVMkaZQbtNxgjgqyKbQRTMdUyX+Ynt5Sro8lGQdJ0rIhGdz4X8n65gm/jdPKWtVWCSs4yRB OU5+8ROrb8EBW8dQjX5lh6ivwvgTjh7Cft2OPNdOcNMnO2jQRaJ3xssRGbugib4j8lFQHcWicg+U eLeW9ZFiVq1UVwNeTt7Rxv/nillNPNu7qkGXcWpVH0sbx2WZSVOLWhqybDwp7oDlioOYLqFjc9CL 2pBV18CUg6YtWQ2vRDSN+WGbILitEeT0QIWfmRf/S/gIMjw5zyb2HmYshW4hef+FrdDHyQdoBkO+ Y1yNp+ZzBYjb4jQ0Poq7pGWMc34M+SVp7D0Y3eSDQay9tBOsiIxcYmP/DXlr8qEgllmcJdlhMl24 Ak38WRBTH1oIztYy7sJ/gP1Q8uHAdnXkKpTfDOFmWbDdhWyPBBoIXFotjftB0Q8/RvseDeLpKaez uZrVDc8jxz8HGtcJ4wl6SuDqcN9rcBbRvseCh8vOaevHsTBq/cURtMImql5rP+4vHj+CVhunffS+ ihY/Gax1OF0xJ705FCWcXv8SyNiFjKtGcpBZXpC+wOT8Eczt5L8Gcs5ETpwyMKeLQw7uL0A6kHwq eOYgN19XKTabs/U2AduGQLYei03N65WKqXIEDf7VkWZ4Tsv09PSZTDuwY399xBk+gN7FtjCOxW59 +ki6Cnp2JK+bTBGcABsDpzhk+iWrRQexE/8tuDequeLqIsRMdUCD/FIzeU9DJ/HvgbxJm2NOsbnE J086bI/HPqxG/EgRT+Mi/An/LT4FfdIpWE5JbvpkBw1iBO5Uoxgjol84RLfQHMIgcpDKlwAmisXQ nkaJOfWfjhdCzAGvu417XX7pQrLbiVo4kAr2uG/7sbm8rcS97Tt+cD9P+64fg5+X3e7bDl8P+wdf o7y963t+eKdnDXHPutvXoCCv+qH/cAR61D0B2vy96UcB2oI86cf+2vy96D5fpiAPut+X60je84D/ jPDznAd9Wfy8Zo28ZkgKmq5Ol1kjl9ngy+HlL2vkL+VALU5nWSNn2eTL4fSUNfKUE/xt8nOTNXKT EX9GLx956t/AjF0ORXmWLNk3L/X85mYTHRl4vwP4E/4MvtmkfmRGUS56xk1nnRKsHZb8vZ+WrgI9 eZkO/gE2XWPJ//LHpmsGdrV0GMdyhx92plaq5PJ60cJPx+764Ei9RZsri+kmHMr/8XdWxmozGbJo 1We+k8VaaSbHhzj7/+S/QJ3LTLBdJR2Dk58FTGWxYmz9C+EJh76JviNyKCyxKBZnPxKtC1V44yiG qmapRrHqr3w0ZXyD1RoKVsf58rmi1bg1FK2O98XXhatQjcLVX/ty1MerGsWrVv+2eASsGgWsKf52 uSPWGopYJ/gyuELWGgpZ0/1t8o5ZayhmfSlgWHyC1hoKWicH6fOKWmsoap0SpM87bNUobCkB+rzi Vo3iVps/l3fgqlHgavdn849cNYpcMwLmRn3oqlHoivvzBMeumYFT1yt2zQqeup6xqy9Qi1fsmu0/ dz1i1+kBzQ+MXWf4M/rGrnHgtOR9EwJjV8aKXejZIBY9jj/hDVGMUdGIFaPs9BPddKbz2NXia6YI XnhkUdJ58Do2AEzRi8BX8eh1oi/YFr4EA4Wvk47YY0b8ElwUv04L8F1WABMcFMCS/lPGHsEEC0Ww roCl6g5hgo9CWE/AjHaEMGKCsIUzoIm+I/JGGKcoFmd/9ei6EMZd/zQjkp0lItl8H4XpI0SyL/vy eUeyRb54v0h2ni+HXyQ7378tvpHsAn+7vCPZYl8Gz0h2sb9NQZFsacCwBEayS4L0+Uey/6XszOOj KNI+3p1pxoQZSBDUiCBBTpUohFwm4CKIEEVAA8rrwWSYTEhCMhNmJhdHONcDAzEf47qsJ5pX8VjB dV3v63V1cRd0xc/ri+t9sEo80XVVdM1bT1V1uqZTzzPqH13VT9evn6p6nq7vdBu6l1D+KJJdQvjD SXYprqJIdhkuS0Wyy4ncwEi2FNfQJKshU1dHslo6dbUkW0F60ZGsHs9dDckixPBJkkVxIUqyv7K1 y3pqCEmyoEMyWOAYmTZB4b16KBDrtSEOsVT7IbfdJtk5aDclyR4d4JBsLtGYk4w3liS7AG2skEwK OMnKU86YTTKp4iQLEmuXQzKp4CQL4SmjkkxKOMnCxKXqJpnUcZItJzI6iWRcxOgFGZDBtz6rg8XJ D9XSsuH9SNYYcbEsIVnWiLisTsGyNajOxbJ0wbK1aHuMZW2oAmPZOnwsKMvW4/3Ss2wDKtCy7Eq8 TxTLriLCQrLsasofzrItlD+KZe2EP5xlW3EVxbJtuCwVyzqI3MBYdi2uoVl2I5m6OpbdRKeulmU3 k150LLsVz10Ny24jhk+ybAcuRFnWxVYva0s2ybJqh2WwxDE2LYDCu3g4MOv2bIdZqv0ht91mWQva TcmycoVlq4jGnGXlCss2oY0VlpUrLPt1yhmzWVausOw6Yu1yWFausOx6PGVUlpUrLLuBuFTdLCtX WLadyOgklpVLlkEGZPCtz7qUxckP1dLM0f1YZr+SjlHsTkmxuxBnzSkodj+qc1FslKDYLrR9P4pl CIrtRhUYxR7Ax4JS7A94v/QUexAVaCn2KN4nimKPEWEhKfY45Q+n2BOUP4piTxH+cIo9jasoij2D y1JR7FkiNzCK/Q+uoSm2j0xdHcVeolNXS7GXSS86ir2C566GYvuJ4ZMUexUXohSrYOuWtXAUSbFm h2KwuDEqHQOF94TRQKvqUQ6tVPtqt92m2D1oNyXF4I3HNsXuIxpzivHGkmIPoY0VikkBp9jDKWfM pphUcYo9T6xdDsWkglPsL3jKqBSTEk6xF4lL1U0xqeMU+xuR0UkU4yJGLsiADL71WaNZnPxQLf2/ Cf2fLVZHY4kctpoDxw5Ijr2OuIun4Ni7qM7FsUzBsffQ9v04ZgmOvY8qMI59gI8F5diHeL/0HDuI CrQc+wTvE8WxT4mwkBz7jPKHc+xzyh/FsS8JfzjHDuMqimNf4bJUHPuayA2MY//CNTTHesnU1XHM SCNTV8sxE9VgHPOgCh3HLLxPNMcG4EKUY+PZymVljyc5Fnc4Bssb49JbUHg/mAC8mjze4ZVqn+W2 2xx7E42S5FiPcjf2NtGYc6xHuRv7CG2scKxHuRs7hGeai2M9yt3Yt8Ta5XCsR7kb+x5PTJVjPcrd 2A/EpermWI9yN/Yf4oJL4liPvBuDDMjgW591iMXJD9XSnachHOt7viiBNjBNAM2HJF8iBdCORnUu oGUJoA1F22NAG4YqMKAdg48FBdqxeL/0QDsOFWiBNhLvEwW0E4mwkEAbRfnDgZZD+aOAdhLhDwfa GFxFAW0sLksFtHFEbmBAG49raKBNIVNXB7Q8OnW1QJtKetEBrQDPXQ3QConhk0ArwoUo0D5nS5h1 aBIJtIQDNFjnGKDuh8L7x9MAXGauAy7VPsxtt4E2GO2mBBr8E34baFlEYw403lgC7Xi0sQI0KeBA OyHljNlAkyoOtJOJtcsBmlRwoJ2Kp4wKNCnhQMslLlU30KSOA+10IqOTgMZFDGKQARl867MeY3Hy Q7W0tqAf0CTBpkmCTUcc1aQg2NmoTv9ocTbaHnu0eA6qwAg2Bx8LSrC5eL/0BCtDBVqCLcD7RBFs IREWkmAXUP5wgl1I+aMItojwhxNsMa6iCHYRLktFsIuJ3MAItgTX0AQLkamrI1glnbpagoVJLzqC LcdzV0OwamL4JMFqcCFKsKfZmmXdO5UkWI1DMFjYGJEaoPA2FQCpnpvqkEq1v+a22wSbgXZTEqxb IdhMojEnWLdCsPPQxgrBuhWCnZ9yxmyCdSsEu5RYuxyCdSsEuxxPGZVg3QrBAsSl6iZYt0KwIJHR SQTrlgSDDMjgW5+1hsXJD9XSgmn4H3tIlEUkyqKIx9oUKGtCdS6U5QiUNaPtMZS1oAoMZa34WFCU rcL7pUfZalSgRdkGvE8UyjYSYSFRtonyh6NsM+WPQtkVhD8cZVfiKgplV+GyVCi7msgNDGVbcA2N suvJ1NWh7Dd06mpRdgPpRYey7XjualD2O2L4JMpuxIUoyjawxctqKiFRVuugDFY4hqZSKLxnTQNk bStxkKXad7jtNspiaDclynKVp4sJojFHWa7ydHEt2lhBWa7ydHFdyhmzUZarPF3cSqxdDspylaeL HXjKqCjLVZ4udhKXqhtlucrTxeuIjE5CWa58uggZkMG3PmsOi5MfqqU/zuyHMv4uEomx2yTGdiDe 6lJgbCeq09+R3Y22xzB2D6rAMHYvPhYUY/fh/dJj7PeoQIuxB/E+URj7IxEWEmMPUf5wjP2J8kdh 7BHCH46xR3EVhbHHcFkqjD1O5AaGsSdwDY2xv5Cpq8PYHjp1tRh7kfSiw9jf8NzVYGwvMXwSY/tw IYqxeWzhsqafRWKszsEYrG4MS2mzAFfpswBXi89ycKXaq912G2PdaDclxuANszbG7iQac4zxxhJj u9DGCsakgGPsgZQzZmNMqjjGnibWLgdjUsEx9iyeMirGpIRj7DniUnVjTOo4xp4nMjoJY1zE0AUZ kMG3Pmswi5MfqqV7y/QYc9+W7Zc8exVxW5+CZ/9AdfrbsjfQ9hjP3kQVGM/ewseC8uxtvF96nr2D CrQ8O4j3ieLZP4mwkDz7iPKH8+xjyh/Fsx7CH86zT3AVxbNPcVkqnn1G5AbGs89xDc2z78nU1fHs CJ26Wp79QHrR8ew/eO5qePYTMXySZ724EOXZULaCWYPmkjyrd3gGyxzj034ovAfKgFvj5jrcUu3F brvNs9fQbkqedSm3ZQeIxpxnXcpt2XtoY4VnXcpt2QcpZ8zmWZdyW3aYWLscnnUpt2Vf4ymj8qxL uS37hrhU3TzrUm7LviUyOolnXfK2DDIgg2991tssTn6olv52oZ5n6r2Z5REsG+DRu2xJwTI/qnOx 7FeCZYPQ9v1YdrRg2WBUgbEsEx8LyrIsvF96lg1BBVqWHYf3iWJZNhEWkmXHU/5wlg2n/FEsG0H4 w1k2EldRLDsRl6Vi2SgiNzCW5eAammWnkqmrY9kkOnW1LMslvehYdjqeuxqWTSaGT7JsCi5EWfYB W72s1+eTLGtxWAZLHGPTLVB4uxcCsw7Pd5il2q0FLrvNsnS0m5Jl070OywYSjTnLeGPJsqFoY4Vl UsBZdkzKGbNZJlWcZWOItcthmVRwlo3DU0ZlmZRwlk0gLlU3y6SOs+xkIqOTWMZFjF+QARl867Pu YXHyQ7W0/mKCZe4btEIJtSLEd2sKqJ2J6lxQmyGg9iu0fT+oDRVQm4EqMKidhY8FhdpMvF96qM1C BVqoleF9oqB2LhEWEmrnUf5wqM2j/FFQm0/4w6G2AFdRUFuIy1JB7QIiNzCoXYhraKhdTqauDmpL 6dTVQi1AetFBLYjnrgZqy4jhk1AL4UIUarvYMmbdv5iEWqsDNVjrGKTiUHhbLwZ4vbDYgZdqf91t t6FWgnZTQq1Cgdo0ojGHWoUCtdloYwVqFQrU5qScMRtqFQrUFhNrlwO1CgVqF+Mpo0KtQoHafxGX qhtqFQrULiUyOglqFRJqkAEZfOuz1rE4+aFaWrS0H9T4+96BYdWSYTWIq6oUDGtAdS6GZQuGrUTb 92OYVzAshiowhsXxsaAMS+D90jOsERW4GLaGM2w13ictwzb19vau4RhbQ0RGj7E3mFaQbC3lVUOy 9YJkbZRLLcnGC5JtIPzhJNuEqyiSbcZlqUh2BZEhGMmuxDU0ya4jE1hHsi46gbUku570oiPZDXgG a0j2W2L4JMm240KUZJvZ2mW1XEaSrMohGSxwjEzTofDOWgrEuvYyh1iq/Q633SZZHdpNSbL50FqS LEI05iTjjSXJmtHGCsmkgJOsNeWM2SSTKk6yLcQK5pBMKjjJ2vGUUUkmJZxk24hL1U0yqeMku5bI 6CSScRGjF2RABt/6rDJm80N1oPhElWWVDgr3Q5r45gow7XbJtDsQp5UpmHYPqnMxrUAw7V60fT+m ZQqm3YcqMKb9Hh8LyrT78X7pmbYLFWiZ9hDeJy3TPD/aTPsTERk90/b91Nu7ljPtYcqr7u7MWsuh 9gjlUwu1fFNQ7XHCI061J3EVRbWncFkqqj1D5AhGtWdxTYq3f5AprH37B53C+rd/kF60b//Ac1j3 9g9i+PTbP3AhSrWL2TpmzQ+RVKt0qAZrHKPUUCi8x4eBXlUhh16qvdVtt6l2J9pNSTX4GpZNtZ1E Y0413lhS7QG0sUI1KeBUezDljNlUkypOtT8Ta5hDNangVHsBTxmValLCqbaHuFTdVJM6TrW/Ehmd RDUugm+3LAWqwdZnjWJx8kO19J0V+oeODtHelER7C3EYTkG0D1Gd/knjQbQ99r/P/okqMKJ9hI8F JdrHeL/0RDuECrRE+wLvk55oz9hE+5KIjJ5oT35qE+0w5VVHtBmCaF9RPrVEO3uoINo3hEecaN/i Kopo3+GyVEQ7QuQIRrQfcQ1NtHSLSmEd0TJQBU60gaQXHdH8qEJHtEF4n2iiDcaFKNHGsjXMyqkl iRZ2iAYLHSPUQSi8n6zgf/pR65BLtZ/ntttEexcNryQafITSJtr7RGNONN5YEu0TtLFCNCngRPsM zzQX0aSKE62XWMMcokkFJ5qJp4xKNCnhRPPgwexHNKnjRBtAZHQS0biIUQwyIINvfdZhFic/VINH 6kxjWTDO9NF4IhYO1vOvvUyKJypLSsTbGflHm8U3YHIY4dqOsGsjPW+FOTKTdSOv3oTPycB3PuHr 6HEjL2LCKdPGWNaGOiXbooXwwclYq/3JtQH1PMF8UHiH1EMibYf2R8R3jxX7mX+w7VMn2Qd6mck4 /xU40CbOa+Rdacvkd8rLzWp2leWJt1fa7kNNy+wv4IjGLM5+OJvP+vcK2E6sg1mayC3HsQZ+qAaj EfcsyVdX9p8o+52WP2+u4MQwV/vrk67MqUnOypqZaYripKx59uyk+ZwaMFZF+ISuh8J7RQQmtKfe mVDFfqYnokyoOJCAA+efFHFPKD+qm9Bf0kd10vkJYdLBo88aUQ/bRfUw6Yt4vZ3Z/VAN3hW1J73m F6SmmT8zrRamO78+TU6355Td7ED+7LQ/5xvGKf9gg8k/Jw3OfkrtQFafk9bJfJ7SBW3mpk1oYPU9 7MrML0vjX/adG1VCU+NK44IG8S+aGvi/XGqAWa+IOrOu2M9ss+0FufaBeWzrhU7Kuc2vTVOdqPPG BaxhEPonZkVMyrLGqlTz0jiECafLL7gVuMRlIXfgQrNn8+98NywLhlYw5q9iJLl9uwEfOjeNoSH4 vq/9SSif9VwEQvccD+Yc1jW/qMKMBh9e6Q7gz79qqDAenOaEEXzYYbywwQnj9JgTxl74rnH+St0V VvMLrrD5MR7rRVB4L4lBrOetdGKt2M+sXanEWhwIx7Sx/iU9UfOBnxTyAQbqzoefNc10Vui6kTIr nPf5+qwtDZAYsPVZFayPflGFGKV9FTeNeCKYMJYUjvPE4WvGTUbheLhvgDAHAg3ByilG4QR44Ufa mHRoUROJGoUnv8hb+MHAfn6FjcLcQ9ySNXo7a1p42vd8bxgcb6ypNApPv5cbssGwHAyTH+OGEWCI ca9ThNcc4TXPKMwTXidCExilUZg/8CiwTBr9FgtoYfF96bA3efQW2Ct9mu/lQ+tgoqbeKDzHMwos xbyT3DJHWGaAJcQtc4VlLnPaGGmMhyvzjcLF8KebaWMW9tkKjMKLhG2RtSfuJG8+zJy9/sBMstz7 DgrvT2xrHPUe1PnsJh9ITzbCV99WxCBGsPVZVoLFCKqDVrHf2CabhIrCpX3BCbiDU5E7QAQnELDD s6xfeEJJ4al0hyfsDk9Vv/Asd4enWvhVwlMzTg1PrQhPvghP3SvpfcEQ4UkowRDhabSD0ReeJmFZ 2Jd46w7wXiyx4OO8dhwKYToL8+1I8FljfGvknIXblMG13GQZLntmkg3ikJGAOMCW8Y8Z/VBNK2sy 4WvfoRVGVtEWT12Af1i96JoePgHG6A42tKJ2sZfGDrPuxBJG0TaRrRaz1IUjRlGH2E9n+w1sjou6 Cvm+3xrZ5IylgPuxhwKO4RXrUHgXN0FSFUFddCb5SLrLCsPpbIThwNZnXcqMfqgOGtZsGk+woGQX be8bzO+SBnNjv8HcNC55MDeLfb89mFvEYIZZnyqDKeI9ciIDjln3hkPhzWnmf/oH9SfEuq3YM5Ns MJSKJv4S2Cb+Ir1meAksqw46wGrnMLakF4/0NMcDsWizUXyiWDcMMISidUbxKGFIA0NLQ01LmNly hM0CW6u0jRY2r7W7WRlDc00E0tsewwExhrd5Xz/kY9gDdehFsj0zyQZjOLUZxgBbn9UDY4DqoEdb TOMkNntHF4/3MPpU1QWXG8UT7EGw33XCMtEeRSgQEpaT7TGwWw5hOUWOACw1kbBRfGq5XByYKGQU TwJfaWNYSrQolw//TH3UHuCLLXyAL0Ph/d8WGODdUIcuJtszk2yGkQVScDjkctaNo9ggv+AD/oIP +A120A/VQd+0sg0L78QzbvYEY+FI0Djjlm453Gisclndirhxxq3dcnDxemG4rVtCqFrs7xD7fr5f XWmccbswZHkabckdwjLMU2VbuoUl29PY5+i/hWmEp6rPdKcw5XhWhMMNIfa72jjjLmEaa+1rdWau uD5Yx+a5qm/uYGRsPn6AwsvuD9ncHYT6IJHMij0zyQbJ8W4LzBVsfdZRrIkfqoPWrDaNAPvVVFyS 5VkRZ1dTOGGUDAUrzBajUyxQySBklBwrbJYn2sBaHCcna9Qj7ExWyfE5CXaXUzIcgpOTSNQZJSdA dd06Fr+SEdA2+1rWEIa1cTUfwlVQeLexrXH8TnbotEDBFJd9eJLNMDxNQXbikfNWQT/8o/m5T7Rj Eo82xkLhQLCyMmaUjNrO+zrMUxkGHHBbjrCN9cQbomzBKZEXY76nUuyfJPYLrUWrnQCw30F8CsTE BOww3C3GsIv39SHo6+A6qMNEJtszk2zwFVb4d4g+CwaRwbc+q2s1/CtEVs2C88IH73h+Z7JDft7M z5s9Ds2gOkzpklEyFkzrzbVr2fnrgzURwxwGcwL/PQ9Xz+INZjC2PCTNaZ3pfL+J7XuHw75/oymW YPMY+IultM6KjWY4Utm3u2SjGWoN1YUN81hxgkUbzUQ0EUjUhFgqm8eJVnPZWWLMSfbul1mgOh9Z t9GEue8z7GSGKnbS0XAOT+dmthuKRiJhhuFoJB6IxAxzAsyMp3M9OxRjAzMniqY/tm002c/UcvgF YJ4ubN8xW0OCaSbP98D+v9j+8lgN9LpMtPiyDRw0Rth55gvLp8wSraqKw6kXCNPHbZvMiWzezmUn uY9ZNpo1hllsn8DYbI5lWfC+Fw4w7JWLAx+2bTanMfsbXilYLOzvsvPHOR8vglh4Ot9khkS4vsEw l4heHmgzIAGeYXH8tfkFawM/qNhvFbYmR2oS/P8RBGE6AsFIZQBmL9bIpycw2TBfYHNjpYtwBpz2 4UCDMe71vsCyn06xmmisJtHaZ/UbV5gD2sBXIlQFZ0rzDma9N640xzAr9AJOO4Kf+iqzl+2zMxlX m4E58xbMPGteIFAWKBeZVno+tCrkLbPKmRgGwjPVMraYspE5ZFYbPEfwQP5dwzpUGY8GqtmAWAIN 5k8OzY0wgCgMgZ2y/k3DGODJZldGu/n30+B4u5lxOtxrtJsFUFrtZhjK9HazE8qsdnMPlDnt5r+h nNFunjSZleu3mhdCaZhbzW28krbVfIFXrK2mMQUq6VvNQl7J2mrW8ErOVvNWXmGneR0qu9vNY/NY ee5WcwGUFuvPNXmiX0/miX59kSf6NXaqsC+cKuxrpgr7zqmiv/univ7+BGXONvOCasPoMNniaJgd 5vOiyK7nxXJRPCKKkRFWXMsuaThPL/sPJrPDPHEVP3q2KHat5Y327khu9OVN/Ojkm8Xpb2dFuzlt r+hpxV7R06v2ip7u3it7ulf09EcoczrMwD4uewwKb7t5hJcd5pj9/KSXiOJ6UfxdFANe5cVMUayD YlggwH4mRENBFvtppW9Z0L0bXhLaA7w4721etIhiuyieEsU7ohj4Di9yRTFfFHFR3CGKl0TxgyjG vitOLYqEKHaI4lVRGO+JORLFElGsF8U97/Gh7/sAZqbDXM3y0+w034iahsjpTvPwSrvebu76XEzY gK+5+Ov/Z+1O4KQo7j2A18zswogs7HLJKQORQ3Fnl1MOdw0sCOvC7goISpB2dqZndty5mJ7ZK8oR RDTo4oGKgoAiqPGMmnigEhMViWfEK0+UiAQl+D5oAP0gefj+Vf9fz/T0Yj5+Xh5+9DvVVV3ddXRV 9aEeUxy8zCEZuEBxM7PjCsUxJuTjuJBiJzOhXs4RR+R1Ky5SNw4nunSSl4y8/XeUpI1kSTjmj6Tp hksFIuG6kpDfXywNjx4/rjipB+p9KQrH0s0lo730V+4OCJTU0W1+7hb/iBHmDu0y+nep28cZLT+W WG7Wk0ZJMh5PlTTFkw0l88IGjW9jS6r0ZEyPlPAzCT0pRDQdSfGIYnj9iYSsbO5I3no5izZbAzG+ xTA4ZKQCAT1Iv51ChGmKaeTNZgqXShGO81b1FIN/atNpLR8LhkMcDGV3pfQ0YXKOVNPmvnT/iBMw /PV6AHmHQzTBZH7HfBFOkkjVU9EClrPAFo5Ox8J0FByZIoqpCD6qAtpC3YAqUB1U/sw+pqENNJ4G E3H88qXi0bCfhn5O2STT0OySzpaaTj63MjpkSiET6BGajXlrTG+i5bVKl3M0IxXRwrSap2MltTqf oWdqHpFcKMsGWr/G/WaQZuhQsCnAwcxjKNp4ii0pup3IN1td80d8hmEeKBw31ME51KQeSHHB1E8z TlZXPKD7G1OcEIHsC3k12RqcEscJ+vy6WVg9mYyhraO+VD33KhcHeDO/h5E1hUfjlp9mAcLZmHBu jGwdzjHoj6Ui/DMc96cixZZ+EjVrUHaT7LqPNrhVTWRyp16SuSryVG3z8z0ZR3OsU/7T1d3hnuf+ TfI996v6187iIucDjkL6u8g9I0DBbkn3M2ukG9zvtUnd37gN58hC58gi9zL6q829xllS2Pa1y3AW O1xFr7jfc8+fv2GD85xubsO9z/2Nc1rRsn304zfL3fuWO4cWtTknFL63wXXlYVffV9yvUs7ndHOm CvOGuPaLz/ImuY4u8TvHd/W7B/idPYQa4tKGL6R75LXPhTQ859Oi0iPX77phlHvOl4siFSzvJEoC eqMcfupocSHiCT02kSvPU1lTMVObMmWuVlldOVc0qvrzWCLncmxFTXX1tIq5Qq0by4YEOtEl1Bjy GLT29ZR5hkQCHrV+pBgPLUdVAnsWUyvnIBdP0BeO6AHxww+Os438/+4i3nTkr3eKTxz5XzjEMWf+ n1xipSt/jUv8Km9tJ4p+oqtcgznwt1xXFZJyFqcZ4Cp357y86yjiUpH9I9fyk7u4VzqnFORXrsi/ Nm+VyznFW+gMeTtf6u1dS7+Wmb9cXzi8bs1bOFv90zXE4RWuQgel2OrtX+P11HvlsXojX7mwLBfZ vBdQrBknV4a9LXFVljh5zn0tcbMscY7W2pmyGB04qEqzkH54LGVRtyj/jwXqT9kts5QnJ38qlIzf bClTTnwVx//BUq6ceCrcPiFnZfln03KH2E1LX3WzJdfBWPo2LpWPugMTJ2pzmnwJufBp0HgNf35p udyqGeZ2+X8k5bSnfL/j+bEXPCqX7GN5UfZj2ZivBdrnlH0vYM9MtWqmlHmZnidX/OafsJwvknIE FeozB5GbRTydSqRT2Ski5QsJudg3NPn4yKAhOJrwJXWhVdZoF1bOnCZyv4hRs5G8yceiUauU3xsl aQPdR/CMyBOKJu+rIr6ULsy38yIWp7kn3qSl5EwuZ8VxY+g3Zlk5tQcoKIdcnrMoRzXFy2qh+0/1 iENlLTOlQlH+qRYtqSeoUuNJGpbo3GPcmrRrwqBKpMtdvtxtENl38BQVNMLqSPLeTB3IPIU6XzIZ pvFb7p/7Il9NWJnpSQUSvhTVIeU3W0+IzIcuVNp21Usjo6x5WaPqMPK2uN0HPIJmTwqrCJpeG2n6 03hTlCpeo9FTZSjq9BAVIhmUd9KqvJRnI7W3njmmiNJITNWBkzb3LCujU/U1aXUtKYpSFZlzMPNu ljLQNMuyIieRP55o0TLVTEnpdh2NNYdGXF86Feerx59Ia7TMoqrMnBbmCNkiVF0R3ddAzWNWfbJJ PfNOpVTtz5IPhKhgQT2px/y63BAIG9RjdOFLJOSjj0xlqjJSfCaxwY3HEebDOZH5Rkj2U9mT9MXy Uzmce+5Z0BnwFaji6ECGr1HX1FHlcaJxCmXPLecLLuvqj7qyVifzk2fEy55Mjk1JqhY+RU7MUXhW zknCAZ1PVYaivmQDrbpVlg2qO/EHhSi6bBeBTwX4TYigiyYQj3IOSb2O+gveE2uaWg1rdJnTsgRX VDxT3MwnhMKaLBhPNvmSAdu4QS3J/ZF+ydZGo5oXrpGiS0MmigX0ZnnuMWqMBrnFH6HxRET0GC2l sydkPhiJUmQLWpbKjstOPYvB6Gn2uewgIOQVoQXDSTpMPJgzaolEXBYpKXI/9aTVY871YfuWVGS7 B605I4bZeqq+Va1mPtDM9OJoOqU3oxOrK1QWtV6n6yHTxYI+WnPLK0R9RymWWFfU1KZBdCs+mPUL SDofWlum8ERKl2NomIfH3MPL60deixxQhzLbQ10JSzItLoeuoFpBaVNkTdSFA+EkP+7zRXJbmkea zKWc7e+532gK60eQIvs1qkhyNzE/NqXxODuSUwvLFlXNbWlEmi1kQ2bvF8xOJgd2Xx3NPdlPBWUU lVdmh0/OOFua9dIJ3jn7CaPgdx1qUKFmTETSao7koY3yNkT24k6kjXqVjWg3ypr9xlMXj0eE35fw yTs7IbNUr8doJMz2oFk8vMZVpdTWTM1spjEtLCtczavZLq9GHA5VUE2p6TtCNyey9dX9K7XyEm2y mmjraaBICts3irjkM7UrRy95CLUusHxkJyyfKOJiizeEqZhxLZiO4dEvHXZ+PBkwMmX+xeWi3QpK WP8zDyJz0Ua0pnoewy2Dgjkq0QKBR3d5KWG+1ujOFtOTebhBNHVp0TosDYT5KTWdLy0x5GyVTGeW DHQsc/xVnYnuSlU/ojWLmShBnVw91VDNTldOyto91BeuAm/8KEPcdqKQuTMmr3es86F1NYOBwJyl zT4lhyYeweUQPWY8BvnMCKF2k3NGtvtkZgw9M+ubY1ruIoI6XXbqypYf11I2H7kEoWrHAGzerdsX QiiA2Qwjyvg6yS6ycLuMao0bmUZo9uuJFGo4U95MCf00T8TkhZmWwx2fiK9BoxPnEdO8lnI6OOYz n98ve7l9HlJ1GNKx+OTRjReZVADLNvW/VZO33NrMyinavGmz51TWVGtzL6udlvNsI7u+UNP+HE2N GTG5zLW+bBJiekXFRM/w6dWXnO1RD9A8o0pLx5SOGTnKM3w2XQozfCnPTPmEjmOLzztbCK/REk35 6shUkq03fyX1iJdG7ZTwqvJ466gnegN6XTqk+erqaAjiJLxFjeaWsHrb603GedeQ349moCqSo6U3 FEt75fwbp07oTXr/kw/QfmJeP+mzJVUCee0Y1sIEadGh8wa93hri6ES6LkabcnahWSEW0jMVRqch vNTxdS+1TjGNHTSIe+nuRi6nxU/+M1Dw/T/uk8UY292WeQ/Wj/4+zbLf1084xE1OvltzIJ3cbQjC LqSLWPKy5jcC6c10yyjQx5FN54GlyE9Y0rksJ2LGTbGlW1HEd8n2dOW2ciz7nUNsLuVydLCUY7Yt v8G3OsR32RvSTFy1LT/PAYfavz/yMfNbhH2cSNd/nUP80bKfmXXQlu5TSldsSWcet9mWrvOdDsv9 cja/l23pCn8kXQ9Hbrv1+JF0hY7c8g63lLeLpbwDHbn115vye/kU+fWz5VdK+f0c+RVa8it15JZj D+W35xT5nWvLL0H5lSK/bpb8ym3n98xdDnHAEjbjJtry22wpbw9LfrNt+W1c78j0YWt+1bb8HqD8 CpFfL0t+Plt+L1J+0dPb5xexpRtxvzWUjbvqFOlGnyKd/EzTZdm+6H75prh9OmtbyD9rH3GIWtpx gMg+25LlOs2W3/7HHaKzZcfcsz319jzxzQ/WOJdtL1fOEWQ4zxbOt4U72MJuVe7eDvN5qH3/Trbw 6WrcNJ/zOWmPGpF9rudsd36dbeECMV9kn/O1T9/FFi60hbvZwj1s4V62cG9buI8t3FeE8VvWQRGV P2GJl0dvtYWvx2/5HLUbnX+bLX6dLbzJFn7QFv69LbzLFv7AFv7cFv7SFj5sCx+zhf9lC7scueFu tnAfW3iQLTzcFvbawmNt4Vm28AJbOGQLL0VY9sxB1J+254QLxHe29O1eX2oL5qTGZ7560BaMGfmT P/0IhzOfbrT/JANoWjoQbgyERwvtkliTXJjP1o10VOdH1HL9ZFSMnNZI9ya0rA/yhqlyg/zlo0VY hRmQ6Wqr/LOr1GbexB89GZnEak/5wkUk+C5PvRbBixYR1aPyExtKTPuMVQs2Sk7/9Cda5Bpartiw 3BbqdkGkjYguH+XIZd54825hTCXVC5+W9RMSTfM3++gmRm9W9dhuj0yp/q+Lz/9ksUk3oc3NGlWK IZ9x0D2G1liqxiZnf16DSOOkgwZmuUx00oC9QnqmELdAeS06aYB7S+qhNYh0kBAnEC+vDWmJdLAQ lVD+h1TkfvJLXbnftQ7ebwvSPwc/RPpv4EkHn4/Lqb6PFGc4Odxfhs+iucrJ+02EISktNJcj3bVI dxvi74MfSIfSWhXpjiFdnovju8MK6TC6ZKTDKT/51SINmTfIMN3QbMT2p7H9BWz/EOGvoTuPHQzL 4cw8Pt9gHp9HQx6fR2seH/96+D7i5b9sIttln/QcIcrk9620YF6cz/n9M5/PV77ccp4rxB1SGtLv 6cD7b+vA+78lpcXjgQ6835EOfB4FHTldt458HoM68vFLYRVcAJfDDfBJKU1ce2U+dI77ZdhLY64M lwjxrZTq+oTcTouvLm5O111+Hj+S19kOKoOcFR0debyS6XvAE7K9etIa18UegSPy2AvgIujNZy/s yF4CW+Gu09j98Ah0dmKLoAeWwHI4Cy6EDbAVDjidrYWb4Nvwc9i1M3sm1OB2OK6AnQYvh83wDfgx PAK7dGGfht93ZQsK2SlwHozD/4GDi1A+mIBLu7Pvw+NwTA92BnwC7oX/hMN6spPgcngT3A7fhOf2 QnucgXqHy+BaOLQ3W9UH5wlvhbv7op7gQfgdzO/HdoeDYAksg1XwMhiC98Lfwr2wZ3/2bLhvAOoD Vp3Jugey42E9vApug4/Cl+AxeJqHHQ0nwWp4DVwH34F7YYdBqLfB7N9hv58hH1gHH4LPwb/BBWex a+Au+AmcNITtNZStgX74AnwDjhzG3gG3wbfghOHod/BPsM/Z7HA4F74MG89hH4cvQzmmqv4GvfAi uAO+BcvPRT+EW+BDcCccVcyuhq/DvXCXF/1tDHsBTMPr4V74JTwCT8K+Y9lx8EK4DK6DD8GF43De 8GP4wHnsIXjOePRLGJmA9p/IPjuJPQ4nnM82QVcZ2xmeAQfDYngRXADXwofhDpgoZ5+Gh+HzF7A/ wPKf4zqCH05mo1PQPnBLBTt5KvsZPHohe9Z0dg4MwT3wwxlssJK9Cz4KP4XlF7EGXAULq9gBsBYG YBtcD9+Gn8OCmWh/WAP9cCt8FD4LX4Zvw/+C/4BnzWLHw1a4ArbBO+F98DG4Ax6HBdXsPKjBK2Ea LoOr4Xr4PjwIx9SwZXAGnAMXwTBsgU/CnbBzLdsTeuAIOA5OhhfD1XATPAAPw+9h/sVoZ9gPjoA6 bIG74LvwE/glPAJPwi6zUX64EN4Nt8HfwufhTvgu3Af7z2FLYStcAdvgnfA++BjcAY/DgrloF7gQ hmASXg2vg+vgu/AAHHsJridYCedCDV4JW+FT8DXYfR7KC4fBUbAMzoCXwlvgNvg9dM1He8A+8CxY Ai+ALfBG+A78K9wPD8PvYf6l6K+wBvrh/fBxuB2+Cv8C98Cv4NDL2IlwBbwB3gHvhY/AZ+Br0LmA 7QXnwyvgYvggfAGehB1/wfaGtTAAH4a/g6/Ck7DbQvQzqMNG+Cj8I+xwOdsVeuClMAKfgNvhGzBv Ec4XhmACLofPwjdhgYZ6gsOgBg34PHwFfgC7XMEOhiGYgMvhs/BN2M+HfgnHwihcDl+H78G/wwF1 7Eh4DbwRboQfwH/AHn52EFwEk3ADfBB+AU/AIQF2EmyFbfAZ+BbsrqNe4cUwBB+Gf4BDgux0WA0v gQthPXwGvgG/hRUh9iq4Ft5ez94Hv4An4JAwOxUugbebXol+D4/CYQ24zmAA3gWfgK/Ab2E8xq6E u+Eh2Jpgd5ouZt+Be+CX8CgUSfRvOAHOgqvhFvgY3A53wt1wLzwE/wWHG2wZnA+TcCv8K+yeYqtg CxyQxnUAJ8NZ8DKow8XwatgGn4Nvw4Mwr5E9DzbArfATeHoTuw2ub8b13MLeBt+A++FxeEYrOxBO gw2wBa6Ct8GtcDc8BE/CUb9kg/B2+Bo8DsNXoX/DPbDn1ewUeA98HH4M98PD8HuYv4QthP3gUDgS ng+nw9nwclgPm+G98CS8ZimOD6uXsY/Cg3DoclaDq+Dj8BX4KfwO9v0V6gHqcAXcBl+CX8FeK9hy qMOPoLiG3Qx3waPwZyvZmfAoHHAt2hO+BA/B7qvYCrgUPgU/h72uQ7ngYvgI3AeLrmenwrvhbtjz 12wtXAlfhD1Xo33hHfAwPPcGNg2fhkfg6BtRXngSXtHGvgpL17B3wbyb2CYYvZndCD+CBbewk6EB H4T7YZ9b0R5wNXwbFqxlK+Eq+GfY8TbUN1wJ34Rdb2dr4M3wI9jnDnYNfAn+ACvXsa3wSVhwJ9ob joJheDUctgHlgxvh7+Hr8CD8Bo68G/0HLoU3wvXwIXgUdt7IDoRRuB3mb2Ivhhtg+WbUD/wMjrqH bYGd7kW9wUUwBJPwangdvBVuhA/Cp+AO+Gf4PvwbPARPwAu2oJ/ALfehH2xlX4Djt6F94QE44X72 l/BFuBt+BfMfYIfDWmj8L3t3Hh5FkTdwfI4GJgSBcAiKYERAwpmEREG5BMIlYEQu5QhHAgOGJObg 8EAgRBlidhFB8RUFEQUVl0NxWQU3nAmKGgEFFF4jLzzOiK6+CIQjMm/9qr5DMgO4u++++8c++w5P z2eqqruruqq6ezI8VY3P4Lv4GdZ/w/gAvohH8KU3jd/gd28ZW601puNmvIjhfzAOwvrrjCNxOX6L bdYbc3EfNtpgdOMf8Bzeu5H2wu8w7h3jGjyPw96lP+IFHLiJ9sXw94zT0Id3/9H4Gto3G4fjBoz+ E+chRr9POt7+Af0du2+hXbD3h7QbnsD4P1NP+BlGFhpzcCdGbDM+hHvwlu3G6ViCbXcY5+FhvGOn 8QU8g/fuMq7F63bTXlinyJiEm7FxMevhB9h+D+cDDsF8XI519xr7fGL8+lPjT+j6jOPEXpiHp7BZ Ce2C+z437t3Pfg6QD07EPCzCb/HJQ+wHb/uK8wSXYRFW/9rYFHvjAjyMtY4Y++ForHXU+PZ3xmMY 972xP47Dp0/Sf36kPXAvnsUOfzFOwVm4BtcH4n8yLsL3cT/uOmXs8Qv9DX+Pj542FuIvWO2MMQaz 8Vn8HE9gl7PGTFyALcpof3wMF+Iv6DzHeYgr8AB6sfy80bpg7IaZuBqPYN2L9B+cie/gTxhVbkzB l/EQXv+rcSB68EM8g60uGUfi83gA6/mNLfER3IClGCFTYEi7YQ6+hvsxzG68G6fjOjyONzqMQ/Ap /DP+NzZ3GodjHn6Iv6DdMnbFYbgVf8SmVYz3Yx5uwRZVjWPwd1iIp7BFNcqFT+JWPIttXcaJuAz3 Y80w6hUfxbfxW6xbnXrFR3AdbsULWCec/eFaPIb1ahj74BP4M7a8zjgCF+AW/BlvqWlMxKewEMsw uhb1gC/hIaxR25iA0/EtPIrhEcZeOBOfwp14BBPqGKfhWvxPjKhr7Idb8DQ2q0d/wvm4BX/Em+rT r/Bp3IHlGHu9cTKuwkMY0cDYE6fjG3gQazfk+PB+XIhrMOIG+hfOwDfxKNa/0TgX38fv8aZGxkE4 F9/BY3jDTcbB6MHteA7bNzZOwZfxIIY1MXbBdHwJv8Twm8kXh2EaHkRXpLErZuCr+DX2v4Xjw414 HK9vynr4KL6J3+KNtxrvwwVYiGUY24zzApfj51ilufEOTMGXcT9+i01aGG/H5ViCVW8zdsSH8FVs 1JL+hLm4Cb/DRlHGAfgobsST2LSVcSQ+g8XobM3xYQauxC/R1YbjwnRchRvxJ6zWlv3hK3gQw9oZ O2M2HsX67Tm/cDq+gUexZjT9FLPxbTyOjWOoV1yAu/A8xsYak3EpfoTnMKYD/QazcQPuwdg44wR8 AT/GS3h7vHENlmLt2409MBvX4GF03WHshjNwHXqxSUfjUFyIO/FXbN+JcuMS3IHlGHMn+eJjuBh/ xXZ3Ua/4HO5Be2f6Fa7GgxjWxXgXpuMK/AyrdqU8OA3X4Qm8qZtxOObjTjyLrbobR+EC3IHnsOrd xp44EnfiGWzdwzgaF2IxdutJf8fVeBjDe7EeZuBy/BJrJRh74xO4CX/A23pTXlyMu/ECtuljfBCf xWL8Euv25ThxMe7Ci9i2n3EsLsXw/tQjZuFreBDD7zF2xodwJX6NdQYY78E5uBl/wdsGUh5chLvx HLYYZEzCxbgSv8EyHHuv8RkswvPYJpHzAkux4X3GvvgIrsVSjBhs7I7TcT1+h5H3G4dhARZjOcYP MU7CF/ETvIhxQ42TcTq+i3sxfphxIi7DT9E+3NgJV+ERrDHC2BUzcBV+gdYDrIeP4Ab8HiMf5LzH Rbgb/Rgz0piCz+MuvIQdRhnvxln4HPoxejT1gEvxY3SOMc7A9ViKdZKMvXAGvoGHsM5Y4yB8Egvx LLYdZ3TjMvwCq4033oVT8UU8gGETjA1wCKbiF1g1mfMV0/AVPIz9U4xzcSMex+snsh4+im/icYyc ZByBi7AY/Xinm/LgajyM1002dsOp+Dp+jT5sMYV+iKvxENZ8iPMVs/AtjEo1xuJwfAqX434cOtU4 BnPxEP6MzdKMO/ETPIo+PIP2dI4fm+AgnIiz8QjmZxgX4ypcj1uwGA/gCbzzYeNgTMVT+GGm8dYs zlNciTWzjaNxO5Zgqxz6BabiBjyLKdM4n3EHnsKq0zmv8Sl8Dz/C0zh5hvF5fAtP4KszaVf8DiMe MT6Ej2ARNnvU+CCm4QnRodoVIx431sdW2A57YG98FzdjrVnGutgJu2CK2FCdZ6Kl0ucoY9X3d7GD 6scyroAxiqKMnrNHMNbZYcbNSHgG4YWEFxNeS3g9YRmtZ49Tx09YxvPaq+v/xtXhVbgT9fiIqhUG xkf8/+v/5hWY4zMpa1L77JSs7Kz2lQbLte8lo+srxyQlT07/u/OIjomOviM+3hZtXsF2iIuLjou3 xUTHxsVGx98eG9/BFh0bc0d0nC0y+p9wvFe8cmS27chIm8yC+lvr/bX0f9HXEwkDepsJbc3LwYji tR7LJfMfjHrPpKnmsLlsLW3NbU31uShpcbPVOmoJTJwoI4tlDKaMQFZ/Htvi5qh0tdRV4bqkBeZY 1C/ZVi1T5f5c32wvJ7ikZ6hwxmuWSxZ59sBergWSLqf/fJU+X6XJUqrCsgTmLJBF/bli66vyliXS ZuZQCKQlnshOlnE7cYtV+dTSRsW1qZR+n0q/Wl0F9q8n+k1NNtPxtstKbxdbMcZbyt5n0FDq0ixy XDKmWsZJy2jkwKx+NxIvQ9nlulqnUj71+dzEZuabkHHwjW22kNHdFS/rKnGBeq6GgZHbMtYsMKo6 MBpc2icwclqOo4FarlNLYHR0LVvwWP3A62My8VH+Vwl3JfxApXzqsO82qs7NWN2atg2s/xjpbxJu wb0iMA/BZNL/SHpnwp+S3o9wBOlRhJcRHkd4AOu3JTyR8CDCcazfk3AK4Ui7Ccu40OhK5Zex4eXz Ldfnlkn3sf5PbL+EcCfCeSH1cTHk+H8fcnw7Q8qTTriY8FcqnPysKU+EKk9kpbHPkWo5z+c7WH8/ 6V8R7hqy/nzC0aTLFMtZ2ckTWreWjh7/Dw/mvWL4csVYZzNY+GqDdoOGOv9DQ4KvNaj56mOtrzGa ufJI6qT+05IGp0yanJWdktnTzIpcaYS3Opqp6WnmmTpJSVKXU6Uab5dPMmlPloRirj1gXK02wWzA iG0ztpuB4wzbZsA2o7/NIO6ggdmMAQ+M9mZkuJ56LDt5cprMciRzcUlmFFUPVNdjyvv07JnUoV20 rc+Afj16JsWqTz1HjLi7R7+kGHXV05GJiWqF2MsrxLTTU2k4uJMYLT0vhUO/ywwUdnWNMykO/a8a 862YK6ZsNdxurhXSDxNbzAzXVzGHias9efJ1cga5At9LmTUisP6+dQ9VkatoHdbPjLpRZsqxNa60 /iz2L6+smyeHyRU0Kmj/jsv7d79uuaqqi+8MZTW13WOiSpstqgvyPFHlOF9UF++nRVXchaLKebGo clgqqovwMlEd0QpRXYxXiSrHNaK6MK8V1QV3vahuEO+K6mTcLKoL9RZRXawLRfnbUFQ3lmJRXbj3 iuqGUiKqm8cBUd10DonqhjLUcyL3B5f3c3Uo3jbqOLwNVGH27LD54zPUGv7m2a9beqYif3M5Yrd8 9JXKZMjN5cjdkuYr0WGpAbdUma9Qh6Um3HIr863XYakRt1xWfCt0WGrG3VLCC3VYasgtTeabrcNS UzLSzubL0GGpMXd3CY/VYak5d18JJ+qw1KBbnvPs667DUpNumabZF63DUqPusRKO1GGpWbcckK+2 DksNu+US7tOTPTeXmnbLnzK+ny9JWGrcPVsfvw5Lzbvn6+PXYWkB90J9/DosLeFeqo9fh6VF3Cv0 8euwtIx7jT5+HZYWcq/Xx6/D0lLuzfr4dVhazF2oj1+FY34c4/k29/jPiUMGu48sUimL1dt9w9yj Flgubze1/umFC1Xb3q/n/xg5Z8ezqs0T83PLVUpeYbbDX5I/unzPDr2Oav/ZXWyrVTvnRL1yXOWS XztvX3YDz9ncQutVCfv3XY7OObm7iqxq37PDc9Zs+8o89bVL7fMGKatNfaid+0MNt0T6S3J31i6Y ZiOf4cPun/PDFrWOKrZeN2pnUUKpfChKOG44ZDhiOGAoNuwV1K4LEjYnetuqKlA718E1id4mBB93 OZ7oItm71W3Q2zd4Jd+vFUG1i69MsChvCA/o8NWqJhm41ArqvSBhfqK3hV6nhnzOT6ih6sMfXZCw NNHbVcc3lM96X7PMvk7e6smTzpj/krzrjNTKD5tEj4482SAQ/SDbtLhiG5XxS5W38cVW5chVSm7g KC6XU+1rVjnlXGrK6ZJyqpWfK6ec8xN1FXxZfq1yqpX3lF9ZThW9sfxa5VQZn6m8jW9BFcqpUr4u D5RzisO9RJrjMOsmzMt9fJ5tpm6nlZJQejGone4uD2qn2PJK7SQv36Qq0h9mV9H9wSpImJ3odvaw Cv0587x55JH3mBRyq7yT0xrJaVpwTgcvBuVUfDE0p1/VV6mivBm6g8yWQ8vXAc/2bccc9u2DvcMC 2WXr7OTdlqOz2yLZVQvOzh2c3QNXZPc7Sx9R/hKdScm2Uoe9JHGKzb9Jduz9U2D9DDps7lb5ZM2q 4utvp+daOqPPLsiarsT8JRnsyBklb1V6qVM30bv+YkUXsnRRXr7WBnF6gyfMBqGpE4tmD1Ppw62r JAxRCZ2iQxOKZkeuNveTK1OiVUrHKlRASDFkq0S3vUdH3cgrLlyrkXdJrT9zPqjWT50PqvX/Oh9a 6w3VbbtAV6rf5lujrhn5BVL/m3c832h8mW/bhTBP8bZzN0dt95R49Fqq3vyb5IP7qGR3zOzQ+9U5 v78oL5W2KcpzBz6FXNWCr3iVL25FecmXW1Y+hamWfV1uzLXOS58ryuulIqXXe0peKNsqAc8SuRfm 63eqq6DeLtnDZqkyuyrxKJVUoAvjV5UuFhTo2i3QOyjJ175Q1on+xpupeKfu2J68Eeq9VownodQz 9Hj+Etllvo7z9LBUc7ml2fJ14XMLxyX6N0mSt3qg3q0pHf2bZBtpu+NlldpOdnnIM/RI/sDS/NHH 8xMO5Q894tntORj16Q3feE55zhckFNtrR/S1CnS1+m209YzG+Usk4ioVou5QU3K3SqJ9VifV5P5N soV/U6ousrz3fUFFD0705+z15xR7z+ji3DQ40e2Vtrz+nAQjQ5sl0KjSxS4ovZfO6qMo0Meses0A udOoipBKdzvopufLrtJN75R9uNQfjd7vzwZ103vKgrpp57KQbnoyO7DmLcFr1qm8ppTyZP8rrtRq q5NnK12pKyWpPZRUTtKVJh+8D5RJncleC1JOjxyTpG7j5o4/5/EaklNOW3W/tefcJkfUcY3cbwNH ZLlL1feFKTb3WPWlxHuLid6zw2x9efWwspB4l1t2O8XuXeInJfC9QW0T+CLzkfrS6+19RhXqWUuK li/vUR/FnN12wdHpy6xanoML/YvfkcjenS5lnlZ3RV10tZ9hl78MPan2YTYsyNWbb9t23pG3p+Bh f064905ZZ4x8v2E/nlODVLc6dfKEfJ8a/Eq2+maTe87/gZhdI/ekpb5LOVVEzukRI3U+l7O5WWUz 2Psf6vD1ly39e438vfGv/yyVit/u7I2cd8mXePnNoaU6UvlC/hf1FUW+2LZRZ4WcSL2UUidXPoNE fi0JfgaJfH/VzyDpvsRy/ROeQdJU9cjfegaJ9NjfegbJDJV+tWeQSPDve8KMeaaM7C/w2Raon0rL QOZeHI7yt6r8Znf6Kcslv8n14vce9xzLJXuNnGfpZ7tEz7Vc8htfvMP8pigFDPyOKP0wVZ2g8iet tI/81ie/PcrvfG3UfuVzM6X85iOFq4uqGdMXP2nJE+3SZR8/K4c9aYXMZPu3veS32sDnpqoXxKql h1oGq2W8WjLVMlcti9SyUi0b1bJdLfvUckwtp9Ti8KgyqqWpWmLV0kMtg9UyXi2ZapmrlkVqWemp yGv2a79R3v/FpM7/3puEPpNGzt7KsyT/ezyZ58U59kAt6F9MF6lzWmoidKrJv/50vSv/203+AyGy Z+vWf2uLWA55oGmqzLhv6+iIdyanTJg8dVyqmTbe5ugoqfL04Gx3uroNpSVnJWWlZNgcnUy85ZyU mZ6TIROhO7qZKJdTpqOfkJOZmZQ1c+r49FSbI8Gk1HBKbErahJmXU3qblNpO+aUzJOs+Jq2eTgvJ vq9Ja6jTKorQz0Tf5DRPS5iWop+7YXP0N/GRzrSUSeMqxd9j4pvpIk/MHDchiYelOAYM0SktnUGx A01slDMjaUJWkjweIEXdem2Oe018KxWvipc0Xh1ghjywwHGfSWjtTAve4H4T30bFB28w1CS0lT2p IspjH1Q5R5nYdrJ6RexoE9telz6kRGNNWjRpwZmMN4kxOjGkZMkmLZa04A0nmsQOgb1WlGWqSYkL bFaRkmZS4q2mMvtg4Mn1usMFHsE8yjzderxQ1S13imqd5bPplcEprpBYeQqv5FBd/zxtrxpuFdgk Tt7DrTSVUkM+XjdQXXAGyVydzsbOwLMasmzOmyVe+nfgyTvjbc6mMyxzLJefxpOemj49JdPmvPUF ndKxUkpORoakNDMpnVWKmW/eedtbOqa71dyqOO6Y+JDnRASqYLd+RGiVvULVfXJxrNlFPg8KC42v FRSnbtTy1N5MiwdN17DVmamup1a1umSjJ/m3h1nJltTKLFlFHo5dXT/fIDLoURyOamHWcllBnjZc XWKsKrU/UJ8/qNh7mLVNlBoPt7Kcss8s/fmQRMvHepePMNvmbCmFrHc57FgsT46tl5aaNGFcdrLN avo/lF0JeBvF2R7Jm7UVXcZRbNmWE18hd/CV2MFOyOXcCYnjHIRDkWU5liNbtizFSWjDDYGE+2yh tOH+C6EUaLkbSqGF8peWFiglpQUKhQIp5SrQ/m3/7/1mV7srSzzFz+PZ2Xfm++b9ZmdGM7MzOzhG eLwCIJqM9AtlEpL2yQO3xJgXZ1KwZo9PP8NGnQAhSiXFJ1iI/GqcTj42bYksBwUcgY0U+TWwmAEY lV87U1cQi1OrkT/pKiiA35oflCifrdFCqeZPeQiRLGmo0KGHT90gldJ9/RwA094dk85mzt0xWnQZ PF3jREBjA4AZt2gk08jMmWmVfABafsM8VSfKDtQW6GpllMZt1igWgwpg0FAqhEPN8luhjHNBR9q2 SYQGELjdp92m+BC0/As1Ntvl7UVpcnHc7r8qfSuJHNCk++PdeJb5F2vx+WQnAJdoAB8MJvIvxYnh Y9NmKWNkkFR2mcZ1UKZ9ObKqGG8r869YR2LuH+bLl6wF+VdQBcSpc/lXAKOKXTIr2CAQyX8ZOaiG +No4qk8+Vym83y69nVzEs8JlZogqGgRv0asCTnGHWge7VP7z8T20fKYZ1g4Hy7+yVAKJWLQf91dp uYR7adnVWjZJw67R8oTP+KH7azX51HAE58TgiJL867Q4w2bwG1rEbgwCAVyvlabhka4YU7lBi7Ej shu339LCmapM/DsaxMcCArhZA7SDxADdpmkhKIxDZ0T+nRZEGnWX9rh6ho1439NM1zEZ855tesye aEyLeV86psRkzPu1mMM6lR9q7GJaAXp4kiQypGfBIzsceDx7pFxYhx9dm6fXqkE+tSb/sJ5XlBWx yACgJziTKRwHbaEpupbj8DmHBbOeJMXlH9IoaRmVkqvcBbaAdiai22G7Rf6eVHyDSozbY9O6SRVL Kbbbq90WVPzZjq/KareuioN0dR+j3RZWlNNAzF2k3foqfkPJucdpt/6Ke8ggt0+7DVTgo8Du8dpt ZcWPUR9KtNvaCrxKdPu12ykVJyKhUu12RkA7LY6Il9tuKuEOQwCtKnW53RW2OxhpIuNoDD8QF+6J mnUtmr0Nwl2jQW2BYDzWjRqLt8XuSbaxXP0WBNATDIbjsVQ/6ZxqO4djLwkEd/JhM2mBaTa0r/aa pRX4CLB7um1nALfLArIn7z7Odj4DywNpkRbbJE5jdcX5yIJW212luO0MmE7Ec7fZIiy3JcAtkXAv 1AifEgimBvDymoxYbDvAkbYpzziN3+oW/WRL/Tf6hgA3HMgWm3oTH9TxOuKjFFhxrwXjwiWLznwU nQkjfGCTGNNlQzErfonoOzpLaZTu/owc3BY41qCPgYkW4VirlamJ11Oo4lhXGQzS+EI41v+HUpc3 XcLRAVl/yiUbObwSpvTduKjjeDHOARcaudkZcJkZEkI2n6mIcGxodnHRpQa0SYCc/3lN9wSpu5aV TGPd77Dupgy4zAxRAwpS6DlwA5pHjSaScLDrVEop0KV5GS5lfx1geIsdZO3YCQvo3n0/Obh1jS0n wtTPFGMDssCJqtfws1tRmiY/R0DEf4lbkr9fkn+YWT7O5G91g/ycDLjMDIEJ1DjYdSo/BSt4i7Hm dGzNS2C10iOXoBaOrdRZVU0ys6qWrAqIVbOAiL/WI1lBlNJah4u6CeurSls9YNWcAZeZITB5iVm9 xKxOIdAFr08/Q60nnBTO5UkPN4TkVt/lkb9hKjxqdyE5e48h51w4l8K5Hg5HgUNy91JMN2Ki7rY5 k2TbcG8s2qV/x9+ZOs+n96GpjqH7K5w7H1Hk+FArxdRHdu6S5biAsJ5EvD8oY+7RB4f0yxPXsNP1 YWFQWvD1kEcOBel3JhkfCUt078Fj5CAwyCcvSPCMF46RQ0Cc8NYtsTNtRXL4F8TBrsGBCA11upmD cJ4rSdUiLLTLGnaeDJtilUvGhfN8GTLDKoWQC2RIXZ52/GJPKiacF0mwqaoSfeUDHm7qWpS2QtPI oMF87p3e5Oz3cbm4iwvA5Zh383RC6BwlE/daMDy3PoroxsO9jhqUWid6RvEUH2nmvPLqY/QnJiEc Xua8SqJ4ZvLnzHmd8cSiAztxNBrOsUg/0BtksIuDccYtDd6pSRXO78iAQj0TBoXzJjQC9Ai5Jjhv ljUBj44P7RXO2zdxIapUNh1jypTmUYcBphtjmTMol9Tocs4MQBLGWnGvBUPOoLA7lIvIdaHX7lCu ZkD6J44x1R9TaVv1MEd6nNxqlDE0vrIWQc4QMYri2vdZ4iNIoASm650ROV1ET/QXIe4EcmumFo2K J0825phbFnHM5eRW7ykaVZtRtmRtzlKvMxWSF6fIScWnXs+KD0Lxk7piQx07V+tOpqahVCSxW+oJ /Yn1/AV67OM0PWgOVNxJHg5e2OtQHlFGaTLyr3sGx2kgt3qprgge1kYhnjGjpNMZGomycJzcmj3j NEuEG6Xs56Dv7NXLnozfN7VIrxJZ8mbHniK9amSkE1s9jquIrNr9smqjRgzgeD7ngCzWhcosn6lY t4w+sTo9FyLLNcRsaheX66Xw/1xk4l4Lxi38OPwKSLeXQBe84/S0YvEQGql4V1+EiNscSr8PEdG8 O5VrEV160W44lTsAcBOyYjwpoT5ngfMQzEJNpPp698Qxen5pyPfu4kZakTlxD8QoX5Sq8dkaOZxJ qJu8ZTybcRouajdeOnjmwo9ErbjXgtEvLURBshY9CmJ9yId8OMSG9VGYC16jiAjn9yFZ/A5+jWfv J++kvmIhcDtj7CzqSoW7xdjjIHOssxhYfZ7EGg7Jnzi2bWwjkiTb/H8aL3++oYRYDeKi7sQy7dJ/ jsfPd319Bl5mwbj7Fo73d0VxOPDYpptJiDoH9XUC3PyLiqX6s6T6C1jNxax+azGrr8vAyywYcgEq Hew6la8R6JLe/QzvZ/+VgOH14ahgbYJibPO7Y9IIz0eMbZHjpGXGLMbYueeYIBnreH2eYCAVpr6k PI3WNf3zYn2mbjL61doI2X3IjXHHrzFN574vT1Ya9/1yLEJlaxg/V+4fyJEI1T50qtwPab9Kyp4S U9GqM06/1gvW3SWcbzdxx/x+vK3yXAH/r/Myca8FA1NXCVx0153sdyoPk+uCd0qVH98a1g95T0SG U7GkUNxPTzXA+A4hTLeDoQROhhI2EyaX3NpNyECcpzbzhPsgDWWeU3BiyW/yjHA+TEq4X7i3ND1n qYfE8UMu3K+4yoxuVzooNTDcG+2h4Fdnl+m/56ZgjPbe2F2mN1ymkMgA3WBm3f2nS8r0X3RTeCg2 Eto9rPN2vykj+ayRtLNj3X9+oEz/zTeFovukx3hbyge40jGtv+wfr/fcCGET35XQamV3qenp15vO /9Yf/2NlskOEeOpP8BLWczn8zymZuNeC0S8GriocKgN42vSzSDfV75JzuEQLUtGjUQFJB1syVHRc paOWsfTfKMj1KTljtXdCQhnjUCDgUNby/OmD0IwHk6F5lKoiulT3j474SPoHFj+qKmJIZ1jKfcqJ AXEordCBbJbdBmnhGQAfMIOZilGnKeJVZagIyBCn8gz5XfC6m2nI+2QePlP0QRVPe/ytv0y2ljzr 8aG8U6p40uMjeVdQxXMeH8s7VxVPeXwi7wqreMbjU3nnq+IJj7/LO38Vz3d8Ju8CVTzd8YW8q6zi 2Y5/yLvaKp7s+D95R314XrKOI5zd/5a9zxmM8bnHWsB/ZECTnFEQNphnr2mTcxJ2GwzNq7nfps0w yCkM4VZsnRzwoE3xBkxlspGPUdbnIvRSGZSzCJiWsKk7eBZhMvxP5mXiXgtGv3bL6IqHyeNn/LKT /r5U/2CQf863UqgLUZzKc/ysn+OnNQQY3kLMoKSH34jwb2qTC28wo40kINu8OyDGsxU4604ecdxD NTJoeyKAL+WRM9ehdxC5lHIZkbHl2dGI3mv7ENHHVpijG0VKRh+ORHZw7EHbRIpY3VJh7n3iTh+L YjgtZcKx+LBMYtjWCaGwWUhM0I4nl7y1A8rxg7PLdihgBGtETeG7bUdM4ZKZKXiPDabowRoJU/jp tvkUPq0V5edc21Hyl184QQjcF7rPsAXAR7jPtAGkGhKQOy7cZ9kuZUAJIEXhPtt2Nd8XBDgJ4T7H dj0DLnQPGgQU+0MTZPfg4AQuJbfjoh7Cpq/S3RO4e9CQgZdZMO4qBeAeYReWORTwdypH2X+U/fdR ZNdRk9kZZ767z2NDffqPfcGaN6hg+bQztQu2YJ6E73gmt+A0niy5aCLRwUyXZyQvSeO7SFh4dk0o 0F4276R+JpDdpTx/oihdE00Tc/r59HqVgi4y6jJc1GuwU86zB/6ygkzca8FgXN5EGArXqdxArgte d0mlECupMCneE6rupat3gTYHp3ww0fyrMxzupS41/bqH+nUyEKUEKnBRaypBJh/+lUom7rVgIHCQ yRxkMlMJdMHrvo18VUymU5LZqJPZW2lpboJZ6Nwm6dzFyd7LdK6Bv0rJxL0WDBRmVYIOXKfyIOjA i7n0wRT9bg/vEN4uzNUX49xAb+wVCnQvqZLHCJ7p7cNkDd6ae3cAlK9i6hsFovkDVbLodlZxiltx UbdVoeg2VXHRbczAyywY1SaIPlaptVsTieErzPYVZttDgS54ffq7GE/bq3g/oL1Z8axGUfMZbz88 p+wr0ILxG+3pvR5F8ZlqIZL9Yobn3Lxkvyyj2pyQANBPXRSPNhWkAOiNpxLCc4E+a4Io3aHdwrNP nygBEiehC/UJEgJ2R0IkpE0R+YCMsNB+ifg5DiMHJBIAEh3upqrmuVhClYC29yfjPT3Cc5msNLXA 9sQHItTtkbNxU5Sbq40C05BMFxLYSVn7S1zUF6vxAv5h+Ml2K1xghvhnogqZDtepHCHQBa97sEYu 5yn0fCePRvM8OYS3cp6DqF3IPULlPLPnJgkVKMtrzL35KD8Kcy2HUkp6Jy7q15CCZ1uNkBtVrbjX goHaa9WgCdepnE2gC16ffJ3ouWuOfHM0HN0eDCXj/dEwoYUl/JLxDzhWceIPSMQ9oVYI3J5ZWKG9 ZCycAEwr2U0Csfx/r5Ele1YtM2jCRT2+FiXbU8sluykDL7NglBxEUa/SJRuKHew6lQUU6ILXR3SH I3iPcEwD83uPQq4hsYKicm3eLTUsigKyMPA4fTA6wG9Tiiq0Mqv8pNYy2TaY7JU/mNQnQkw969+T xnzIpD8Dac8R+JGcFfdaMBDeWAvycJ3Kv0AeXl86KRrThBOiqMY/iee/JqFbYwnTFkoIm3voWCEe oE5EbdG0PLylTobCvbLjVjRdr5VaGzgYj0XDu0XRDL1y6jiaRlE0Ew2ZPq/ZG6HfYA4VRbOMGc3h cHyQNB9nTGVuT4US3byIq6hOzn74ZEZTRuHlIt5KFdXrtdYUIooa5LxQQEellkappVJZcazpMcwJ pjMglEySWv0pwH7K2RFc1K8fi6cQgv8BRybutWDI+TmcvXCdyjkEuuD1WdIh8k2MGunj/TIN8rCY h0KPx2vdYuw4K1r6s2PxmZjJ8tscdUULMECTr+qKFm6sTQ9PgyMhqsg0gCxahANTZZYPUp4wtgQK ZG5zIqKo/cZjuaFChZotkIh/2WRZoc6YzBadh4u6fzIqVHAyV6jZGXiZBaMKBdF0F7eccgCKHew6 lcsp0AVv8V4c5brmIN27XVOEwK1StApFLdXfT4VptVbIQG6OQDz/mxo5xKcEi3BR/VjfXPp/ktyc DLzMgvGP/mT+0Z8M/4Qp+NGfbHo08n190Tp+U/gx1sOcupgiuW1ThcCtv2gzXkJgFoLaWJThLUZd 6NdeIRadZNSD/mB8ZCBCZXKr8UT6gzuiAyR6slH8+7WneYp8moUwulkgaf/vpkijQYEMycdFdWPT fOmHU9jo5gy8zILBUChysOtUxhHogrc4Cfu6a6biSAhycKsUdYFNKhnZJTmGTU+hRSCuv2+qJHSF JHQdJ3wjEzp7KhNqycDLLBhIQJGDXadyCwjBm34K8YEwug1FvUjc/etpNFKi8lRZNEDcEiNaVsWN gk8Y5PBqvWjQeIlCMHf4KfeHZO67jMhGXUnIsEKThBE4LAN9MlDmSdJodAgbHO4NJVASUlp/Qfnu tKzNfGJEdo70BgZ2UZ68jIv6h2loYJ6AvzEvE/daMOTZYc6/w5x/bxLoOmzOPz0lUbQTePHd+ELD Xtd0ysx95OC2oOh0uTBvh7Tpa9pzrhqDryd8XSvAeOpzBQT926bLpw4FxOQSXNSrpuOp75rOT31u Bl5mwXhmbzrP9U2H/5vTMb833cRa/8EE73MeohD+mSluBKH9z4D812ZQScAL/qLz0d0NaSXhAqMk EJaIDKWi/ED2GUWB8EHUWdTOC41qR3D6SV+kFQMsYaoTSM/fOUPajHTJjrNxUffh+yOlsRm8hqku Ay+zYDxxwzY/wzZfQqAL3uK2sWTUZTfSvXvMTCFwqxRdIjP/UqPKNdQLxPG/qhFBXFLuxEU9Bh/G KP1UEqnPwMssGBKHIge7TqVkJo4jmWHKfMqXa9ALch+loG8SncJx56J8x1OUOxEx7rzoOD2PQ4nt Ytz58ieWpz5DVF1jWKApxl1gZDnl904xbh/0UWYrT8009YUbjd+8WCQ0kBoMdqV6eoyp5I+lnUfZ ni9gj+dV+EHMinstGCycORMWSvc/sBNen76QyfcYJkZ8clmd75mHsVxJLrnzPXcnbuT6Jt8LWODg 05fE+Y7wcifTGjDfa7Mwgkkva/K9fzb0GouafB9f5ZAz85aflvFTaqZYYK2tGz/1f6ZacG6DETCN f4CubcJ0EZlY3DIjuCHYFY/HQrHB3pAobpVf2ajHPM2wfJVc32CO0i4gbLPZINhNo6rittEic2SY HteOuD3RXVSNiueNjt2ih+rxFcTvjewSxfOz66YwPW4B4upvsEXxCVn415ti6GKFEItFepKieMFo kWYtUI9didhx6sgWL8xOiML0uAsQNxHd3kuxF2U3lkP1+GfOxL6HcJRak2hPlPJzcRYTGi1xdFFh Y9ne+Ag+VSKKl+QwXo+RlrPrcnK5fnF7jqeejpKWVAzJYVG8NItcnREhLVXAUjuigyMktGy00Nx0 cFqkECKpgSgveiheniMhLUJaqpKlsKw7zDmyIodh6ShpSX5soe6+1HCyJxqJUUldmUW2yRpJl76H axGp00RX5apFehRdcCX49sTiIT3R1TkevhEnXUlsMtHurig9wROzZ6oMttTZSLyHJdZll5DB1pob isZYZH2Op6BFsFTf0OCgKO7MXlsozEIJw8DijTniJiMWMl3RAVG8KXtcCrNwQNTNo6PO5iBLA4K3 U8VbctTtVNLSatCQdoCq6UnZ6zaHptuN4qep2S6ei9exSrzJ+M3KEEwvjGGpMTfhot6BT615LoC/ UWTiXgtGv0tIwqk8OYvffM6C/+4mvAUgr6+/i4fa1P47gvyWxDlXiFGbp4StZOesvdQ1fJIEi9vJ UzKCkVfxClJdwgvAinfTz2PJ7oLZ+HHibUxoBvy7oK94wI7TGGuNMExoFU/DHEbxYSJbcvp9pFjZ M9uaDdaPR8mcqAuK+9vYvIdxUR9v4/e/kNybNwq/NRMXx70G6EHKl5IzsiYzJzSMtfXtHeGOVWFS 9CyJqc9DW105DoSPDImSc7JKNkSGiGF4Q0NQ/JY5PG+IboJoLClKLsguGkvmEq3/FkRPQC7tzyrb HI73D9LIAF+qIgV9/LrElvmWr/5FqMHmlZJLs9stX9dCi8AEhtQg6stw6v0+POcrs8o19VC/HlJ9 HRvqg7ypxGakq5l/GpT0x3dGRMm12bUgsH1dGHrEWt4XxG+fDAPqboKOcHxwtyi5PrsOBH6pjvq3 mvWH/+0vffjrwn1hswo2BSVe1Ne2EPovqrslN2dVUd+QjAclRD1VeqpRnqSwqX/kp9kF8X1U8Ev+ J7t4fRKv7pO6dFh7nLIs3AHpyah/h3JIR4bM0lGjRCF5yaHBRi25KLknq4ZGCmvfKRNttA3Ek0GO fH/2oqeFs5WSJ6cg7KijeDfURoN8vYmZL1z+uU3BNVjqLfwnoDlARx/IcFL4F6ANQE+/BIICDYdP W2jI5gh/G7cSt8w1txJNiLwCTWY6Ha2loMI4/z2u+UtwUVe+hwnwxyDNCVgD6v6BADnv6F/CX3TL qns2eyiHwMU2ZiM0iNlzjzeEl+XkpcmiDdPTRpsr5qw9XiflX6WFiDn9Brg2HZ0KjpSpux/Bceqr hJLxRKXRrPrX5SYf3hkj5sh4nXn9B1DTQW23f0NO3oOr22MyL000RF19q4nBzHnCvymnhv4VWTUk zBqmC//W3BRipABFwqrgPgsF4e/KzSCaTUH9x1BQiI8Y9+XONm7XUZ64Jsmck6WmvhHIszRC8w/k lh+I5JRPAbkT+5iGcsvT3Zqg3PsaH8h4gM1SOpnTcKtwzGo/+gVN3C9o4vXvbegXsFduBcSuwLEY 4Amb3cm7CO0TF1o7CPqeaOojPMp9hLfa9D7CY1jVIPsIP8K6WtkPOAz6srvwePM8quQjpv7C6dxf 4D7Bj7m2XzIvd59gxOgTgBVV6Em4qNMX4rf/tnnGb78ZfygTF8d9Mk//WXgqazLpPsFIx6oRUjSH xNQ2aKs7br7WJ3gmq6TsE4wYzXCbIdo3X+sT/CK7KPcJsorWf3++3id4PqusqU8wYuoTGKua5M/h X+brfYIXs9ud7hOMaH0CCIv6WSfofYLfZZXT+wQjsk/wbmk6cf4hleYnTkj3CV7NrkX2CUagR2C9 j02ufzIMqPvhCek+wevZdcg+wZfoqP/iBP3hv/WlD3/dSN+IWQWb8innR8sCvU/wTlYVo/oEfbzg x6Yu4qe5c4HeJ3gvu3hGn2CEV6nbtLLw6AK9T/BBDmlrn6DPKFFIXnLQ+gQfZdWg9Qk4UVOf4O/Z i57RJ+jTeHIK1JqgZXCw61TqCXNJL7LCySvqnMpywJDyBRfKd7Yj8US3KK1CAW4pWSwE5lGFUrao ckR/GVq2GIHHjl9EzUVZ+9xgcCSYjCT66aGJsmV4Skp+KXU0OCAcT0S6U/2Domw5h9j8ekgiksRC Q1G2ggMKCinAf3ShnA9FwljRgYtagw/vlo5ZhPnQxsYMvMyCyY1cxJgZRQeoSe4WZR17Se2xdzLf Tk58OBkfxKvnsk0y8TQrBLAhm02szlmkvYyWrJo49eOZ1fWSVVMGXmbBDFZQPwhKwVlgc3SR0dg2 IYI++myXKa1ijeuhMV+Fnx+GNaDACuKhwlwHu05lKoEu6UWSDnadygLA0hvi2CGOshkwvL7uKBZ6 l4ejhNhfJ0cCBeXb8oZScQoJ6e/HEpF+Ud5lvFhonC0g5H9oscy116UtbzPlo5xrzy/mXJudgZdZ MPCBIge7TuVjcIPXF9PI7VCXUKJnkBPT2fVq7KL6+3pm16etfwK7OQJS/s1LtPehS5jdebio+5eA XXwJs5uTgZdZMDCCIge7TuVycl3w+mI6vZFbQW9iO9HToMLypMYvhZfAaX475R12tDU2C4j5P9P4 QRw/nO38g9oOft525tecgZdZMHC6lfndyvzqCXTB69M2/AdqFo/hO7m7P1DbLW8xCxmYlJI3vLM/ cOy5uNP2twcm81bg9H73wJSLcN8zzJPtgam8eVvbTRyYtdLBk+nY3B5oeEaVNzz1Hpj7Mm7lLvnA /Btwo+1yDyz/i8rfN5B73ANrvmBB1h8txPS8vkE7kNzMC5D029QQ0pMz8oHT8ckDn3mDd+DiRYBS 0qxreYd0SrP/Ol6Dn2Lzv8GL77VvEgQOP6Td8WL9wOPvare8UD/wY17Or385IPDEPFXPRhZ+akM6 W6X4T2U66f0AgZ/NTMeQKp7mPdoJ7YvWQH7O70tTy6ihQI2vWKqv9atYZlrrl2Jk+aICuShlzTKj cWnGMiBq8PT2BaqopJyOi3oWdtl6IvAHRSbutWAoSR8sRamC61QuINAFLzaad8vVbBOaeS873WIl x4S1d1Ice9lyGp9K5MwJS/J66HHwqrYJyxEiX4o1tgjE9X+0TBb9acs54Tpc1Dn4wlnp2OVc9Fsy 8DILJkQhRA8sM639gWIHu06ljQJd8PrSlDciss/YoR947a4CCcjd9IG3DxdwITeQ996SSHrHfeAD L9b5mvblB+y25ynSBMtm/UCe7QsJmvblBxRbDXbDP7qCHq+CI0t/ZAv0DCYTovywDSAWuSb4/nHt XgnI8W/5jzWgIICPkcuhe/kT2v5slwS7I9tF+U80rFBi+AJQ+ZMa5gtgKxYn8JSmz69ctUKYFmnK T51bFmE/sYKf0NO4qM/h+/+eu+AvUDJxrwXDs/gaF6BfL4cfrlN5gYJc8JZfvVKI71J++Mv/ZQsE g7tE+b9twJALQd4hT9B/NEglKCzKhf0czWK5j1WU2zTEQ0hIlNvt21S5iax/pcmuhm4Y1tRiMezW lUz2TlzU76+EYefB/11HJu61YFT0IIp0uejZyazfrYCJcJ3KAxTogncCb1iiIUOwBy8Vy1+2/3ol or1MbvX7K7U12PCwg/2PdDl+ghSKDscHNMEj9kcpwJ1YJcQ3UVEnzldWrjIP4eZS/7A3ER8x1icg LhHehYu6dxWM64L/myIT91owGOBcBS5wncq55LrgdX9IzodYEVy5VXlmlbnQYKNfSs4n6cl/KJP/ jJP5Fyf/OvwfFmTiXguGJC/k5C/k5PNWU/LwuofI14HhUuXJyorV5mdLrVIoNmxNH7GxpgsX9eur ef0X/B1jMnGvBUOaBat50+VqXv+F9OG1L12DjUzyS0ZykI4hPI3QK0+ftZiG4PsoUvFpVEwqvwa+ xesJq/w6ew+jc7iXvfgMfOUZ7P02PsRyJrzKhDXCsjbZlMqKLmM8DgpEdDUuascaGDUHfiRvxb0W DIbsY6P2sVFbCHTBay9fm2mU9mqi8hw26tQ1ulHnGkadZxh1vmHUBYZR+9ioj7/EKNOLB1AgolW4 qJNxPIjHudYwyoR7LRgMAT0Hu05lJoEueO2fjTLK9Cki2LafbWtYq9t2wLDtYsO2SwzbLjVsu4xt ++Xa3LaFDNs+k7b9i23IOxG2vW2yzYR7LRjsAT0Hu07FQVFc8NpfPDHTNsvHnGDdlWyd50TduqsM 6642rLvGsO5aw7rr2LpDJ+a2rtewDlyI8RFc1NfZuqdONKwz4V4LBotAz8GuU3kb1sFrP7Qu0zpj Iqzyerbr/bRdNxh2fcuw60bDrm8bdn2H7TpvXW67TNNeYEFc78NFfQinHni+tc6wy4R7LRhseZ/t ep/tOkygC177BetHlUj9W1ew7Ga27Ml1umW3GJbdalh2m2HZ7YZld7BlwfW5LRs2LAMPYnsxLuqV 62HZyHrDMhPutWA8pbmOpzTXwf+N9ZjSJK+9ryO7ZeZvacHEO9nEG9frJt5lmHjIMPFuw8TvGSbe wyYu6shtYtIwEYSI9iAu6s4OmLi1wzDRhHstGC+yWs+LrNbz/t8OLLIir33+hkwTNZvuY5vO6tBt ut+w6QeGTT80bHrAsOlBtql4Q26booZNYIAXK7ioKzfAplkbDJtMuNeCwQ7Qc7DrVNYR6ILXXt6Z sxnRjHuEjdu4QTfuUcO4xwzjfmQYd9gw7nHZ/n+JcX2m9r9Ttumd3M53cvvfaWr/DdxrwXi9/AZe L7+B2/9OrJcnr/2TUcbpn0qDYT+RjX+nbtiThmFPGYb91DDsZ4ZhT7Nh/9uZ27CYYdgn0rB/sAEC J5V53jQZZsK9Fowb/05u/Dt5AmIjGn/y2l/amNWwzEf3LFvo3Khb+L+Ghb8wLHzOsPCXhoW/Ygvv 3pjbwn7DQvAh1r/HRX2DLfzpRsNCE+61YNzH3Mh9zI3wvwML4bXfvymrhebn9xu27mjauhcM6140 rHvJsO63hnUvs3UHNuW2bpdpRcQmZvwwLurjm2DdLZsM60y414LxlkC27ihb99NN2BII667fnNu6 zId4hM18dpNu5u8NM181zPyDYeYfDTNfYzOHN+c2c7dhJkgR9YO4qLdvhpn7NxtmmnCvBYNpoOdg 16kcItAFr31oS6aZvJoKVv2Jrbp3s27Vm4ZVbxlW/dmw6m3DqnfYqhVbclvVY1gFDujTb+F+/hbu /28xrDLhXgvGX/nYzJ9y2sz9/y341gd57ctPyrSqO57qikVg1ntyBLBFN+t9w6yjhll/Ncz6wDDr b2xW5Um5zeo2zAIJoroWF7UTZ/55Wk4yzDLhXgvGI4AtPALYAv/WkzACIK+9dmvWMmnY9jHbFjxJ t+0Tw7ZPDdv+btj2mWHb52zb/32JbRHDNjAhvtNwUeu2wjbfVsM2E+61YLAH9BzsOpU5BLrgbX0W tq0Y5sWo2yOJ9IDNZZs1n0berRQ8bYD0VbptTPTmrcI8qjUkzYOwZyXN55nOb5nmI/DPVzJxrwUD NaToYNepvAqa8LYmTrbS1DvyhZLmG2max0iaK0/ORdM0rIJSjOlxUfeezOP/kw2aJtxrwUDtDab5 BtM8l0AXvK2Vp1hpZgw7fJLthSfrbMdLtp/nZGsaKEE3MTgWF3UGzivwFJ5isDXhXgvG0wUn83TB yfy7eQqmC8jb+qsMtqOGSX7Jt/kUnW+p5HvHKbn4moY+v5J8X2Jev2e+j5v4mnCvBQNHpOhgl3Ia fOFt3XOqla9p4BOQTN9OM62QTDtOzcXUNJiBXkr9TFzU808F075TDaYm3GvBeGDGTN9mpgcIdMHb euxpGeXAPJSplFwvP1XnWiW5/jsnV9PwBJop/Rm4qA2ngWvxaQZXE+61YPxq5lRwhetUWgh0wdt6 JCvXzN/aWkl63mk66UmS9H2n5SJtGnAckaRfZ3JvM+lnTaRNuNeCgShSdLBLXQaQhrf1rKCVtMZy imT5UZrlVMnypGAulqYhBHRSyhfgol6M2X7PUNBgacK9FgzMPmKWHzHLKwl0wdtaty1HBdPozpB0 rwvqdGdKugXbctE1DQqgnCjMwUVt2wa6ldsMuibca8FAESk62HUqiwh0wdt6JIOuuUtZJ6ku26ZT rdeef06qpm7+EUn1dab0NlN91kTVhHstGOghRQe79PxBFd7WS0NZqGZmb5NWGtKcZ0vO20O5OJs6 7kiBeFyNi3p9CJzPCBmcTbjXgnFpYM4fMeeDIZQGcD6hKwtncx63SL63hXS+cyXfkq5cfE1dcWgn Du24qKu6wPe4LoOvCfdaMHBEig52ncp6Al3wtn6ek29mRrdJ4pu6dOLzJPFf5SRu6lx/Lon/mwkq YRB/x0TchHstGMgiRQe7TmUsRXHB6z6TfGdQuK1qnbIlbFDYkKxviQ4MppL4Ojyv3AsmQ9v16XBI ke7zcVEPMI9B+FmTBfdaMKTtDYMHXKdyBXjA63Z0y3O2bVUdyutWHnPjqWQuIhAj5V5c1PHdIPIF pFmVBfdaMCR+LRO5lomUE+iC130D+TYh66o628DMXiNsCs4VNxg11PXEEyOhRHdWSjdISjdx0ncw pQPwb1Iyca8FA43KblCC61TuBiV43bMjQhyPj+9VbWoDwJTcEQulOV3R7mgiwh+GCcWyEoMaSqwV F3VhBMQmwX+8mol7LRjI3MfE7mNiywh0wet+jnwvY8dd1Za2+3Rit2UQ014BhsLhyPBwVmLPSWIv MIFXmNiP4H95bCbutWAgszoCYnCdymsgBq/9lR4h9JTa+ISYLGVoxs54tDvDoRpaFZ11GQ0H3org Db0ePRyiuhhP7BZVO1BK5pXQ0KWqf96jZGZVfN44XIbmLaYxStWwcm+POQNadB0rchTlnfRnrIYG c7LvNVzUP+OUc8/P4b/Mnol7LRgv3eK8eIvz4v0eLN2K4AvkvUJMp8cZqJ6XF1wTTER6tJ3p1YsQ xNs4TbDcRlvdfucsfmHsC3YsDlLcE7C0UNm53VIzm4IdkR4ptSg0nH5ZVtHLvGpwUafi2F7PJRCc rmbi82/X8eplegAv+Jv9RwQQr+hAOCGqN2ZNr1kLb98pNGHRCJnuCGROzSmDcJLhxZKanJg+kTfg fNiDLITrVI6jEBe8dkeULM5y5pGwVcdPsBx7VD0sU20eFX3F6mhde7vclqcHtQvkss02a3uBEE2U nPJ6ryWDc6lJ/yCAGdq0KLdzUW7/oGJ7QSbutWCwDwk62KX2j0AXvO49fULk0QPxV9+IciGtukWW BqHsilr4zQ5u6Fyt7U41f7QEStDzx0U9vw+0LoNknjoKvzkTF7P/EtWffRRfbsT3OqrvyJ4gjf/N 8bgkaFoa+6SWUJi3gGuWPJlDz+yMmCZNC2xcP2IRKj6all98iRZzTJMWtO5Rbt2jPP7pQ+tOXnfb DiFGqCYr1W8ZGf5noJTh85+GMIKr37GNWbgD+YbMFXP+ioC9TCCUSsY1ufe0SGN4LbFYOGmH9ryq /6pXB4uE/sDydOXLyBWLZIofWFHhQso0KOqDAWt2YFBEXveMmBBY6WKr6VWu2mEpH/X4Fu9IkM87 1JNCdHrWDbioLTGUgbsgdbhgFH44Exf1nwB6lQJrYqOTaJEJJSPtfcIzJt2YNNtupfJVMzhaoL6u O5KWWbezjyT4u3csRkZ27IDBcJ3KfCLggrc1NYQ5ru5ITygVS0pFwWSkfzBGWtqwdGEGmoaatbbF wRO7SOcS7LFMRCLyE2012+3yl7Epl44Vq7vq243mIi3aLvYPobKwwuFkKJHkMFFz6lfQ2GiRbZcb qKRK/rAyK9z2FRTWmyQt6nojoUF58FpN+CuanBZtl620VDiAlX7a46LfTi7xNVv/e9UNDdmVtIvK aDoR6tqFIyghouZJ21d8ULpou1izkBXOwpn0i2P4sNJqsLUpvxiw9I7+C9Xptv6yIa4I1+Ci3jCE CvIWtO0So/DPM3HR3hFHc7gBH3Ggh5UaFDWRr2BevUmSKhceSp5Wu9of1DSjAKCYUnvcHdklaqJf QX/zKPnMVNyDGv9ITzQWEzW1//1zn5sW09qFtNKkpjTcmxrYIeVFzStfgXeTVbi9ryPKVUBLQb0d j2Ppjwf1Ruvc/153jsZsmQ/Pkxu0Q1+B6Jc1dMttiXSgqFn+FepqXcKiVSeaVq01pIXnEWf88/o2 L76IS3ViOtpRp4Lq4WDXqdw0hM8RsRc/YK0nJ4RI19U2rYNe80P7rHFOIQ5R5GlT6Ze15kE7iso0 9MZrHrLfTn3zaeiS1zxsB5NprxNQ84gda+JWoONe86hdaUyY6mFohd4DDwokSbUmhIu6PYHatAp+ pGjFvRaM31kN8Xc92az+BD6BPoTBSNJshDZfXFvPNiQSWNa3UBa8vXaYLk0602TSWSaTzuYzI6VJ 59ixa3Yahh0153Iy0y4Hfp79j/CzqefbsUlMqR62mBtOm/tmkk14Fxf1b+SKlc3Dmrk1B+xaiFi5 Pg1ebLdGjyGkEuXxMj1E630s/TaCvkFdiZor7bxzDik3a2cnt3dou3fH/JO1YQ+3WPqbtMg12URW heXmZU2GN9wudSf16nWDXbfPVHvWrdqpJSRpc8HkBZLL2pN6XbozLWmtKuG+tJzxpd2lwwAOIn/v Nli24Hvaw7IXKscWTFIsuxOXf4LfPelU5objA7JHT2nwJnZzKmzXKht/dDy+W/w/bdcCHlV1rfdJ hkBMkHxAab1cKYozozQWkhAeQqN8/WYQfJSKiOQGxmQyhIS8yGuI8vBRrg+uiuIDxEfru7SgoNaC twKK1QhU8aJAsb7LJ5dbLVWUXh/c/e/X2fucM2cmudEPJ2f2Wetfa6+99j57n/nPPiM2Kr1xooxq GSr4sRQPBu5hT+sgrXLZZ17gCyqTzwtwmFWf1NPR/l1AZKTV3u2MxJNWMiPxzJbMSFiSGbkwaWck niUKPN1uZGRSZWRHkmXkYvzJuTaJFOtq1zOSnSHTPmzXM1IX/7Zdz0h2RmZkUYcrI5Naeolnx/rc zNDwBCGJJjpcGamrXJDkj84JHfa4V/SBDmdGJp0ZyQ1xt7WM3NfhzMikIyOTdUpPPeJGon2SroxM emQkc5JM+UnSmZFJIyP5I5S6FVYvj4xMahlpqmCjQzwoNok9JIS0ymWfeYEbqEw+L8DhhefRmUoS M5YRi6zA58nuTpBK2dxK3UEBGs2fKP7kXIhJUN+TcSxmYMaZi4L2mRGd8hy5mC6seNmVskwkEH6y SMJxfNL1AT2Vj8OfDewkBBe1wIiZ1nS6jFOT9hgeSCEjLrNw/cOZeD32AeLvSBsxi71sLfDxou5W egyWFqrOsE49Xc6mgD/oRJ0tFPH1h3Gin1nIHuBahM9h9Gw+DrOOriZEvW+5trGGv7PZ+5XNvNhx eRteRgJnjO8/8EpCdmIzs+AHkzAA4fYglrjNJHhIvNs48MdOrebYZYeNPLH5tdX2BmDwh/r7Jf7k fLMal+R3oLbzJFf5lyg/3NcuF+32cyYc/EhKs1GWXb9I/yVLCGmmgcgPrrzkFioVKmG+4MZRM5v4 ql5EHlwD5Etm0FEnNN4hJR4erI+Q7eyu7mlnweLD4l0tp23Ft0f4t8Bpn9PxJPgoVglZI/oNGYpv tyNEgd1X6vFg6DIMjzHjfdbjT85Ta9j8H9LNlqv8uLOcFBVehQEChtax8UF4Xoz7J62x+kTlgkQ1 HSb40+/Pc50roLOJrr+DGzx0+FaHDp1RK6HTTiMQ3KQFCLdpsGOusiP9GvUC5P9MB7zg7zT5UiEP G9jpX9Mo+gwaMRqi4BZNYzS/iYluFZHXe6Hww8X0TwWq8bytUIsVxs5JSkw8rByHLIWqoWZJ8AVb fpwoRFvgQowHdDUrLJl4RkXvB0YhHYtDn1o2AFYhcTpfxgVAYBDbMlcd9RZU96KVdjvqVl3b2tzU mpDmDbtkygCaw9YdNO9D7ZZTUQzPnopF50HxU1qP4D53MNlz2WYwZ1gP4jnesVm29Hg2qDU1Kt/q 3IHh64BLG7F/QPBvXLeRbTHGu1S/E/Q/iMw8i1YieHRBJ78zfdkhWhZiW6q1FmOvKjoQtnVS35rx WGxLZQ3tlDuAQNfaEzAX6MQ2uajOQrYNEmYcwRa2DdIo5GQrOtkQzGeCbeiLQzCdCbZjNjMEs5Zg x16KNgSTlmDyAA4xxwkuQoWGYIoT7MT8cwhuvQevfAcCM5G7iyffQw+PAHfJOhzOAtjS4rWEzLp3 KfXvM3T/f/JexO5B23mabfV5ei1iO2unkvyG1VgJTo9Lya1r1Ywvcnwpz1UaDRK0LA4+lhdQbIRf YV8eXEb/LEAMcoTkBHTjqkRNLbareEcXjly6jCPX4uV0wVzL9hslTvHZS4U4ejcJ9reU8yig0tJv cvkTkLwZIR0sQFn2zE/EF9C00VHFCv2wgJ7XVE89OVXzBCWROg8lrll+/tW0oBTNMIo7xG59IaXZ s6ytNKgXT2DvSorFFy3C6+4am1oatN/Ops6IzWiNsI6eLa4YsMU+SPnjCr6kh/DYCgr4Y2x8ZBH7 IOUfKvxxqfCpf7aq+iDlw6+RqhNTqcJ2ka2s9qEi5bOhfIzmdOhmrow0aWhnm+LU0XCrHFShFvFe DsVNuH4useTFnGdAjBqt1tPg36wjSMSIktP6NZV7jLXotK0ARKcOzlWaZftlYehl6QgbyMqOqhPb 5ImX1uLE4Gvlid36Cc31sklK5E1vEWEjpuTelnL2JlpcZIkS+cAQ4Wd/qc4eNsJ4qZqOTHsOIhvQ Q+KWkJGLl0PXirlBcB6PHJ8ZtJKdTEqrdLTgOilaq0SxaZguydo7Ol5J1itJU45tqRWNQe5dDHAL uVypPnTI9oler8QWib6q5JDXcsio+C3k2OiymMOV2AOLBKt4QwldJ8CElA4V/V9I3YlR+HoONbZF mixeq7k24hdSboUcK5XgOt23aRBsYXZvFVfTFm5Xx6toscVWCUApZ8DdAzl2Hzy4WsoZizJRjxch h41egmulf2JrF4fgJxDEWi94vxxEXQs9Ljrl1OX0z+20OUL8PjmtcoLJ1cWJKwPJlKgUDz5smeKG NIkuhGAHhpjHpAvxyubKeG1bp8OFOQ8sZ2FiW6ST0A5xcRAFTuA5OyCNfYBbSHC9SDT2lc0AReQ/ gRAbMUjwSZlm7LuajYpQff/f5dTvGSHH5n17bBlRoXOV4GZuVZsfav5VzIdcZRsJbhN4xZVtXoAV K6XgKxyPy7kAo89BDnt7BfdwweYLU3XqvyrRvUrUu1P3v15K7lOSXp36J5B7l85lQr8S6VHZ3IwU TuFBp5Lf6JanFwenhjbIRjco3e2mLtsK0FkHofQXqUSXbk4lj3oX3CBt7DJt1JnSWspPgspFyOS/ i+tdc3vr/FhVJZ2RxM1wFS2ALHYhCn0h0MWWU97RekyJ51gu+TTRelvpDjJ1/aKVd6NQCn7jUvKI VpkSt7IM8dTRuhsqB3C1OEmo1DbSjtwWSTfXYVMdbdBhMykbOLpbAQ80getcwWVaPMIDbhJaoULL reUIsdLT4zxNIUxwILgCzbS0aC+TqsFTs1yq3pok+nuldJpDySvoWoAGrJCKZ/Yg8nH9wsqDz2En A3YkYIs4bCnVa8VUz9sbEr1NaYw3NDLyw+UGiR5WeJO7j4fJuatmHDf0H7RgHUb0aVnymtNcXxlH 3bxzSkusJqkcWuWpnCo8rvzaqIDmWk4g7wxzptnfVD0uc7nimWhatp19s9Qtd+mmzDct6VYq/bkO /UxbxxVp1UIi0seViXgPTbjCaJvQwlh+i7RT03M7PmZIdJu0EPq8hxbqUhnQmmTkrbIeyR5aoQs/ rP28LdnLyOgdytLinkcMq1uftuGR+1ZZuqandWL/UljSBoWFK6Wl63to6eIZo2Nq6V6ayqS9kJ+1 ESbnYF38uL3ctX9rqYvLG3M6b8BeEFYcgT7bPjEUyBbLB7GJcl2dPtXWdkHmc+nv3UZLQTbEupav Y/AtcgntktJluE8qzoUku91PgruzxISafacTav6Dq1jM1ECS/XYRfFMIjhH3snS56GrIfYUZ6H4h VlRSk2izmTdUAffilMIbUMB2laHBspZq02qzmvaSm/fsvrcLzeC7WbomG6cNTTU4k+hEpfRhltOc tzUSbZA6odMNFx0al9q/Ez8Ejb9ihvXfMqot6X17R2qFSrMNrfSxGLRKGjya5VJNVa+oVApNNe2l rthyqBzHWvW4al6oxObVtrS2xdjOkj417JLqoYpsb/UMmv0O6cKJFC741fmnSjs7hQepK38NdE/C +ruv1C1muux9xunqvkNqh+q8tdNX3bpTOnByaohUNZ+klAd6K6eu+DKo/gF3UIZI1XFa0LCpaLra vywhQkt9INKHIPcu6cqwNDip4jBVIoRu8kFIHYwV0D8JI1xQ6o+145hJLN6QCKG7UiNk0Ofvlo4U +sOkisQlEiC0LjVAykBU3Aj11vYqdvUoEQhjeQHWEfhNxn1/Pvoc1LA9cnCi0FEbIrNJ48MBM2gk +k+pEXreqSGm9LqOc0r/09VSe4+3dl2dj77ueZtCOuREmi7fBaBFmS4ClMIxt2mnimMOP4Mr9gt4 Kaby2G5ckhfAb2m57DMvkE0nJ/k4HLqCHg2G8oibsn7cF2+DpgXDmtrmJ1oILWI/RsexstJZY2Nb ElU0MRR/jE4jV/BfpW9jv/XdzX59vgrHffs5ywcYZWxntDVsZ7Q1OL4PnuEwnz+JAfJALvvMC2xG MS/AYQF+o4MUoxNma8ynQa6JGyMkjOQsBTenYXgKUsNwb1bD8DJieZnAZG54rxtqSXQkWloTth01 QT3nHH8nhveWFz3xo/c9yA1sWYu3QrI8HsHyGAV57DhrUJeDrSIobW7CiuS6OTkrslzQVj6616at gKWk01ZAbAJtZfW9Ws+ompp0b7HNuFERL0JLSYzAZ9oRTsGfnB92odM8CUTBaNHLu1AuGC2s3MVo 4dKMpcX4b6T/rl95MVp83MyI65KRvs2CwV7hPWXBfHJfZuHV+DE0qjt4VF9l8XidRS/nfqKIMHr5 Kc5yUlSDIo0gk7a63tSZgxztGaBp1JlM0RykGo426gTQbFJNWjAPug2v5agLHiA63SYtkicRR0Ts LmDZRJy0WCZFhxMgBdTbgLIpOumg2I8zYBfKVuXknfG/JE7yTjokndZD85cu6DW/WH/inSq6Atga qScdsIPuQ6+UtqccctRBQNpkn4zip9GAimKGn2RKIe32OgkoM0CbHuQELEoC0CYHZdrAgjakN7BB G0qHYxCKimJ17iZx04n8MP2IRqff6yIa+UBlQkHas1ZRkNhbVjgFib1lhVOQcE3xpSC936UoSIe6 FAUJQRAUJBCOBQXpSJeiIJW/qihIr72qKEjxnYTMmvAQMShIPlXUyEmwmG31OboTLTjrWoXxTZoo 2bSlpMT4eqe8RpFI10PERVvyQbMJTUgA5c/lBQ8Tk9Dkg2FQnY7oMJHZDxM31SlN5QQJygCafZ8A 0klQaXBsetTXvE4fA0OnR/kA6MQp3RNBnJr0CHETp9L4IylVLjhB8XkWmBqlym/i46QcJdORrUpw BzcSmTGW0ZLYdAZ+sA9SXvwoMehWvWmav3+Hmh5vm0ZnYh+k/EZlelz3TaNaJTas+iDl7ynYid2H hculNqx6ZxApL3mMGPytNL3CZHZ9bba4aPZOQGrMLv/5rovzxXPb4Hz5I5hssB0sGafthhOKDcYx yw7JQrDBuPPsylV2Qp3YJk9k7cKJ0x8nNhvMPqGzwaYpkTe9RYSNBiX3tpSzX5/ERVYokQ8MEX52 gzp72Aj9MSUyrQsiig3GZCQbbMCvicEG84kpnyEXx0i/XQDQ4hGdoVBqM0DBO6Z0DJZy0TsVRn0G GCYCezdT9C0gaOQyH4RSfRiXiRD9wTpi0s4yQUD3lsN3xSwgaIQ0H4ASe/iXDlTcrdSvS+uA0NfN Rw9AXyOx+V0QFWstvlMLwb/+hpj0towgXtNjMAcQOvHNb1YlqG66DxUP2ACr0johEQwX3geCQZbz QzAobyKSZ/yWmDQ6vzg4CHYCohYQOsHO7zLsot5xkCmbAKJR73ybQ7DsksQ1EJApxySQIOVlAmTg kOg564lJ1/OrkIvIxys059r1xEXk85tQ6BQ/zZk524FjUPz8OqtN/hM51mcDcZL//PRNWqBo4PM3 EJMW6IPA1pqTJittEdKbFMTmdHXQVqtaHCp2A0GjEvqtOxh50OVExYAniE4yTIvgciI6Ewga/dAH ghMTPa8iaxTK3gxQvK8iBxXGvgwwvK4ioSeJwWb06yg2b9GzQksU1MZuQdFplBNM/+Vgl4Ldniks eymiM1oC7nsbicGOzAzOI/ZVEkjwJjMAqjNxtPHqcYBpjEq/GajNtUyajVn0D6DYXEtfjxSr0rMt p24iBg0zU6g0bblawQ7KFNavLd+XcIK7mRmcR1v++ClisDozAErdlg8CTON7+oFlyEfkay3tUsdW ebbN6GfK5sBMbda5254B8gSY/jQxWKIZAzoyQEHqafCIAp+QMbgrDxielgyfS1BBLc0Q1BuTRKc8 QwzSaSZwXjmhNdJmBXlm7yZGUp9X89zgFvv8jhhMVd+LvuSwelaBRJsV1vgMsTJz3uU7iX6oTE3u VVO4T+KKFDc58VliMF/9J2kardWrC2n96AGJK0ix3cBN1RSu7vSVsjE3gwmmzYP16lDOXvXz3xOD SZsxtg80if5Goaad5+vs21SgWh8buZkY7NtMkDNOHndzqwwSzb1emY/3vnlXi9nWtRYbuYUYpN3e dsHHA9qw0rjg8/aq8bpUtrX2H/0cMai+verAjFL2a5e3E/ZtyugzyonF30kT4KarTx7wpjjnP4lB EO7dSLB/KZzQhtUu5cT1ve/ExTPGxOwb0RNSuWPflp512h+IzitOd0tVYxwn+W99/KcZ5y3Hinbg Gnxjvzsw4tXtiqJ2VP3QozORtwBTZyL73tThHOXimKo/YkEqvmWOGSRl3xsHgr7Md+cRt5fOe544 6Mt+nojfwXSE6Aog6MRm3/v2TsozfvtTUO8CSqc8+/kiWLzOSNt3nPmIOWorMcnQaTH59dkAVRdl uhBWeB9miMdGdk8XaReSaJJBnRbNgXXMxvqXbcTkVvslQ0sGVW2SgJJ2nR4wfXs8r7w8mqmXfgHM 205MqnZ6uNQRTABMJ3H7prKL3u0TyhclsuR3dwM5fUyHvkBM5nc30VMFd6HCze6216mj/CpQdba4 70jt5JH7BDn8IjGJ5JkDp4/xUgkuKebdA08V4v9SsAO7C5s6wkU7iElL9wP1Jqz7hHmVRJeM9W6i p4/1p8r/YT22kCrgU18iJsu9m9ipo/4okHX+ux+yJzPeJ+h9/0hManz3wNPHvEoakKT57htIFfLn lO/regKdMuIV+S8TF9He776LTcHfs9YG1IIwG4A6Bd9vSquR8+nUjPPO7XYj0U0STLLzMwGTtx10 OOdth++/QkzifjeAFaffC9rIB2XkUOZGsILU4fliZbOCOtYdf51gjvsM5nMAGUOmqr+dryQvABJc LvvMCwTpMiMfh0PXdzmeEBjZ5XpCYDnuQOm7eHo8IbCe03KfYvS9zYx+ex+OxdMAWvkAowzewGQu +8wLbIVn/PAj5vBHzOG3UMwL2KHadNKDqS+Y3l40fckadzPUFW3cSVK3eeO+DwZ8p0Z78pCAcsiD pf//9KgHPn3H3uQGvtyJp0PWIkH2sMcGUJDHjvuv2kNIDc28QHhCYWNTY4KEL0Umt40FXH1iDMoi BFKWRQrjeNUkCc/URUpZoZSxChvbGxIttXESvkyXGieKpVxWYbypHjt6kvAsQ04US7lAYVttAxW6 3PAKZVKiX2ED9bGtsqWThGfrUuNluZQsKGxItLZW1iRaSbjclBTlUnJ4IY0nCVfoQiW0SJ4/d+4R 9NMxoEI2NFPJW1fvEW+SwZ2GevysRCNwu65fNNo+FSGQt7ItiNfUN1VVUow7dekJ6oSSvQL6/DU8 tYlW/mKB8L2GifFuEcH7zbZyoJ9YRNPHjfKQjlI8JpWgjRUzDJHwOsONEuNshNzPKzBYvUQoPAkj b+XrfyJkXmU80cZfERGPcX3aOpaRYUyGPV0hRSJk/tUWsbIsMqi2mlhlhymShTwOx6w+G2COlGW9 JssqRVnO03tAOxuqTlTLE+xJs7IydWKerqE9TVZWqUTmGyLsg4mMXQaRpbIqDUJMsNaKnnxNXDDC zXod5R6nTzNZzdvBfCQgZ0zCwz6j/wfqjZXoEovYhdDuqbQw0kEYfp+tLARFw16nfwqyqLGrDOHE Qm6Nc0K22taKpkNjJ03u8DJDg3PRPTRGXwcNmcM36HUaKxKYKZ68S6kUW6qHrDD7vugdHTwMVS+9 LoO9PlsGBZ2BxPHOAu3tOOGNrvwz3omTbVVPgTZ7/QVGX1psv9Iq/KyR/kWeUpE6guaVb05IgFoc b6LyrXFqf4thv0g7x2rPSPzZKRKG5ONPbiC6m5ACSCDd2JN9ebQUccsLbKHF+TjMZYfzfr0PWwYR Mim8bSYeIgrv5Q8RkWyMSay/0F75JsSyRgS0QtHh3+JPIPVjZ5A5VPrAM0w6n41htdUxMdj/2eiK sal0vGNdUUpEyMF9aiyjhWr8P+ihWGLIRMgRQ1VdEt5OraquD18Zqvwq8RcPvdG2QITk7deV7AvH Ox6KY0yhCBlqKqtrybs+yurC8iNbmbWEMXy+54EwwUMyQqIcZnLWXvr3RbT8Rx66eGSgsroaz6Ik WhKNcd4H+rALCZk8GboV2VT3Y0+7eNygoakj4a1edQXUcf0L/0MW5lywX2Zz1TJ1+jN12h5Aqx5S pz9Xp5GmfFaO4YXUbIfMUuYOCX8hxcQIWnVQIRw37JPJBW/KsfUrd8XUa2RMpepKKMlHCWKttC/E +Ph6wiM4492Cglqn4jN7hwAUP4EYDZ1ruUGLizyF6eKKeltnu3uZivHss9/yNEETOd/DgGhSU5TD T79g+gUXz4gV11ZHHIYmIjizb3EY4lfr8AAvK2OdctKEt4HX98HAMWGgls7L6QRLGhiYyoAhF1HY 0+lfPk3QzMBCzhMwEzlvHzdTw7oTbUESHuZloliXoUN+y367ZXns5+veCqhQOm853HS6Yp0QEzMY Xhajs/1ErW0C9nKQ5xjp4XpuYAWd2hS8RA+xu424LBSgavi/Fos++jcfU6l8SBUcUafy38P3r+zv f8d3DIHiO6GHBUPt7wX4/iP7+3B8RyLgf5iavB+mYG/0fvb+V3x/aQ/cxOEgj8phAVJBz1049wDF /RNWGsusupW0GuGbLfFUbDZ7W1ZtzfwkTc4WEl5pxJO2L38nlhRQb5cqP7FfdvhVThW9u8O0lVNN P8mCU3BM54zhOy3zzEVnyzP3WOIEOZ81Ni0SNGgNv5SdURRhBMVCHBaxwKBNzlxzAO/EbWqNRRva 5tVX1rSSwJnjzoIeLZsnyvDqMHL11QFy5itS/GfNicaGpv9j7Mzj26quBHyf8qzEkUICOCHgkIUU eDZWYsdxFsySEgSkLAmYrSSMKsuKrWBLQpJjhUDY2mH5sQwFhrIMWzOUYRigLEOBDrQwTAsU0mk7 DGXp0KZsDgkQQtJMadNzzr1v1TtX/OGnq3PPuet557v3Plnqy4L6mbZ6Qclc9S9sdfjDf2EB7WFb OydFrvJBbyrlnmz2vL5cCZRvtJXLUuQoT7hhVIjO8UIMWncNrgFD2M3mK2BxjtFCH9BJSYFoyQ31 DtvvjBZ8Egq9Uu8jovk3bwmxaSy4kHWhMQ3XGbCpENYGA8uHWUfR6rywLjYeJYF5IHqFdYmB/g9r k2n2P1Pib3ValxpyhRM3zbc8Ry6VRdgFdDRA7lK41/CzlPS7E44D/GiUjlSwViP67Cgev0zDIjaN Dcq/scSWW99xcrBxdEtG8b04/sq3FHmtKw19C0IxrIoVPURg65p6ZTA4lodasijRPPS2EGfgV1hY t9JIF0cKpT5h3Wbs1eAMdU7Kbjf2H0ujbS59O3QcF6TOAsWyM3wvyeHbRIPxPzR8K9HyjHFB+RDJ rDtsKcSNE38nxDJYiQvDeob2eHYttD4X1muB7s9HZRi3gGJS9lf98N86GIK+1EiuMpAqV/pyBWFt CiuG/le1RjkptzBjDPPr74T2n2yd3r8re/8+9fJj7OXYc9BOdsqXcXLRybCetbPEydeidIMUP2eL 1Vrm3F++I3clWLn8Z2lhPR86Jp0+rWQv1EqLpbxtbv8yjfViqP18vxp6YsG/iwLneIU3ddXs/yUQ R/cWCoPpweJAWliv+w0XO1lJsYuG8Oi+bEZYb/jVOkHoKKzOVbENb/pVukjsKA1kq8J6O1AKCB0F /NHwUh72ota7fq1Fdo6jOphdDXOyOdBllDoqhQxovBeoDoSOQgmgBCofBhpNYkepnMFfvMmthl2R NRq439vdTFd/oDBC7LS2Bvpg5/hUi4UcRshPA1PgZAWUy8La7lddqDJcxfNyxRHQ2xEIDVLuqA2D U/QOrxbWzkB5KsNVLBazpQz1aHeglU6Wo5zuWzNcrqzOZQfBG/4cGK4OT65jgTlK/y9BP7SzXDcb LKTt0vcEJ8PNtPWLvem+Xrx3JwXujQUyIym+lHrZwmrS2yeoJzMcvdXp3CApTgkoLlQ5jmZ/oSCr nhrUVDmOZrpYFFZrQKsTpEnYKUkNjCxtNRq4kVYavbk8boWtjpp+UoajlwNkdwZ05uXyTn5hGFrc FawJpI5GpTSchzthYUCni+Rue7L9wkoGywFpUkSlRma4JKzjgxogdTRwSWMtC2rgf28oDTxdy6aH 6FBkymH4FQTnIz5L2UyunCtAT0vGXpsJoRHMGMn1VQaEVVZCk4RyaWdVjDW/pXULCbPVTLZYoSKG jZ9TRpwyZIVwc6Tkqs1aq7InUXZGwR8KvF4tlJpk1QDl1AXZEtDubgNXVpHZUyMliMy0IpXZ1A1r Y3BJsahWKynuQgBFjHHny59cVpnC+mcjtgULn+nWKou9X63LvuVkCOtfjE3UxD6SYYXq2NN62MDT qsjsgci+6NbDJdgINNlrXmH9BsdqulqmCmsCjcF0e5ErLMvAxfN0tTQV1lIDl7vTaWnpjJGwMrR0 PHfBewL/Ma8f1kvZkic7FxyJhTVKyRXHrcW9I5WcPA1Al8wBnpu3+JZ+4pvXvKdOCeR2zpmk79ZU UaOUdMsXEbvoOW9iqW+qUtWXmngLvjl4i7WH6QGL7SJFcvb7apNbKozQBEExDwbb1+lTgM7i+s5p luzsme/bm3KMPo8Go4/K8da96io0UZP7htoseRiOGaCPs240zJImv/SYbA7GAmnRg+se3w5KliAb i2mxavIHkC5nK4Chz4PLFxR/pUJ63ULMyFcqBBeHwXJkYef+AAsbzsvi9gkUt0BmhLTK16Lj3sZC DoKAZE2PBIZzsROfYEgxEtlDetzkD22jQwPVemxyysYz46tOQEMV3eYH6+uijEBdqy72mBwZqE1Z hNX0Iprhqty3gF8eKKCjK6ACC15adMpF76roR7hXx+2nsFYGKyc5rt/t7bp8+KCaQY8gVnVjAf3Z Cv7Kp7U62OMFMge7/AtPl9d+5JwikV2xZmacTPsZhjItGFX548rWSNAfZIa9pVv1OvVMhtcNNT1D OQxr25bgsE7AhYDa9l0VNCsqs3lBs5PnoNkGW1FYN9l3tNqglI9FBTwMsG6JOHd7OeVI74iMsUtc BFdRoR2VdVegCfbjrQdH6TzNYyAaTTxjmI05FBWjDzpRN2biuUWjecsoplEtZv4npOMyiRRspGvM fAvFMomb4Ua6xsztKMZkHO+qOFImjmSJI04mYTPQhk7VxuInQKi6Q7fgJ0CoCtwrx0zcRcdIHDNj i1EFrzFzBSpKASabRuiBSKoiWpbe1CDfl9L5MgpeunALql2GFo1RISa8uVWITZAwWg9O0BpYtLbR mHW0y1Jo5ignKTbQDyoKIzFYGEHNRK0m5TiakYTcl7XOqdVU2zKlaSb6cv0Q5lvn1mpSjqM5LlFV qu01qguqft1JiXIxncmK1o7aUinH0ZyZKJZw+9I6r1aTchzNJYn+Uro4IFo7azUpx9G8pC2Tr5QG Rev8Wk3KsTUjbUVYckLlXSGVY46taLalB/PDQ6J1Qdh4Qo6tOK4plaoUUvTorPXQW0HWNJQunyda D7sc0uajW71nDt5i7DsE/cIwGt7Fl+j7W/G45WVMk6/45BN9MvTHK8jHriA//RiEcUxOuGabECvx m/4Oa7cSkC5ly8ODFWEe1tlSOE+IlmK6hFt7gad7pUJJRFryhUwhv1aMEWbfNl9752VgdZZZW/G1 GMuHVnwXX6Lf24YtvhDTK42gfKJPhq38bCu2GK8x804QxjE54brtQvxlnBAr2uYO49c3ti1W1adS WaCC/ARM4Nsa1Xp2Jn0mAxaJoCjaurEkXLzPpyW5kh4ppTMjUhePREC6ZD6dlS0hKWxXlPgYKT7W KaK3MCTaknItfELEro6kJ0jpSZGmFFlLN2ibj0Ucdc0n0EDsVdtJRsOd23EAjnrckZ2uZO6vAsgz R4qDR73q6KVsvY3b8XF9w6dqftrWhAyRPUMPo4XXbkEL2m3w6oq2YaWiQn9X6lPPKrDt4pDyPStB u0vttyor3KKKthsYK8x1vpNCWW6zLbMVe1ZKuWIFPLLttpBiaEFcowuFPrHdU2jyM7dQe1LtUu8M K7UjVDlY7Pc8xYJT0LmS9IF7w1x1cYiqc4iritzymbf73iLv0xXpVQ0WedT2kCLpFnjgKxUJec7P GsgiO2s6TcU99JU6XVucmISvp9sPtmZALPj+NowFD4A4LpN4bTSfQQHeR82pHXCP4c+rJpoiRQgB 6UphqIzTJRJtERVWU/gJA7mQnOdVScra6RhZCnN5kegIMevwaCiriGGe/7k/fLsG9q2GrYMAl8WX 6Hk7MBhehUbUYr/8jqBcfNPAF3zujx8/qaToNEokjg5pX1dAi5a7znJrRSaTg80ZrbDkr2LQ15VT MBnwVIDgTSwNKb7Tp1NTeCakcPp1Fpivn2zH+cJrzDwf+hPHZPPkL4R4Eh+4JJaYg0/vwOfulSys SmE1YyaOMQE5KflOtPQNrQMWDfWtAxKtG+oTY1rW9Q0JU5hbd3hHfzF+osM39lgHjGUzvkRnfYFj 3IDpJ8cG5RN9Mmzp2h3YarzCQg+EcUw2f75TiBdw7hM/bxgsgBhZCQ1+uaGFPiwpWuQyx2gprxvq LQxCi/H7JKDJa9ODsDcxoYgvcMgB/YlXGqbJY0dI7YrLr1F+5Qu/Q+GHTdbJXXYxXaH7xn4SgW2B Fu/Gl+iendi7zWg9YATlE30yaDRMpv1z6qpUkXi1oaZKOigKKCZFwy5aAA3u5FpqD/94UmyYhC/R Kbuwgd9GIxpAv/yWoByftHr+RdNt5q9qm0nPdWpUk+iVBZri02t8EuWNdI2Z2J+4TLaRuI3S01CM yeY7IRWJ4KS/GZ2eSVfSg4V+kXiL7h5z7S7fMHTaH/DxjcSdciQ2Uo8foB5fh2kq1Sef6JNhO2bt wjbhNWY+gm3CZBOtzGAfMYcWHk10y8PbuQf+GnLHDxby/TP7CsO9sNWNm00yhdkzMLv10JgQ7eOM v0J6bfefhMD3ZnvEaEktSyaTKXFxS6rnzGXHpsCdU2cvX5E8JQUOnVqxvGfZ2Snw6NSynuVLU7Aa bN4JxpfBemxm+zRjGq1t2g9Up4JiGn1opn26IX/Y3pyWLvV3iPYZBhrh01x4P0+0z1TvJ00rZStw k4j2WUoy1XztT+7YQgB2z1DtcRW7aayi+BKN78ZxfR9tLhsflE/0yWCI1OiMM2MmDkEjXWPmPpAd x6T1fUjJYS0VhvN9qXJlHeibHbe2yPe5fF9Wfbd3JQtDJqWVwkjaPpcVjiyVz6ZhlY0PxX1qufxq XC5hYPPJ89l+N2+MsHY5benL4icRncbc26IEwdYocbq3LJ/Mq/dF/AoyfDgvJizYI0QSw0LHg6c1 wxh3/Bt5MKx37E/jpQZzQ8Bt9Rgav4q7mM3Yz/wE2hvGyIcwux0P60wX0E6wrFbkhhj5A6xbOx7R mSySJh3tjtFpa7CJP9QZLcYWQrB1G3fa1bAf6nhU26/2XJnWN/24WVZmd6DZY9oGglW2msb9oBqH +7F9j+tsukrpvlzVHYZfoMW/axs3D+YT6ilCqMN9r22Zx/Y9qZ8ur6VnHEeiWOuP6tQKm6jaWlfg /uKpOrV6LL2zdxG2+Bl9rQPpsuP0zlQU0b1+rDXsRMPzh3OwsjwlfYpjeR/4dsd/aC0XoiW6DPh0 vt9nvR8sBzqe1XsOWsv7Kim6pdmCRjB7TmvW5ZqlBgvlslPlMDb4p/U8PJfNdHUtdoxGcWCfr+vh vRhdPDfGFBzWF+rVNVToGx4sOEYxdIAXtS4OK/2i26NdOIj/pR+NSi6/Lg/MTPVmYX2ZdWznYpD4 mda2wxOYk2IJ2Zl77fHymDG1+ZEkm4YT8SV6Kn4L+l6HYDppBOUTfTJgBO5U48iI+H676V9odiNE dlH6LNCJYzLyaYMh/PUfgR+EOAqi7lsy6sqPLnTM92st603qI+5mziwQbQ0Zbf/IqXOR9j3OgIuy 77P9YCPsB2yjwqPrh5y+P7JGZGTdxjZIF1U/4adDG1E/1dTGR9PPNLXpIunnfG18FN3BGuki6Bes Vb3ouZP3CC5y7mJNuKhZpagZMXTu6g+ZVQqZY1iLsHhZpXhpamvxB8sqBctG1sIfKasUKcfzbeLC ZJXCZIw3DIuRcw4Hj10FSXORaXg3L7X2zmYTAxlEv534Ev0SrmKvFWiMRQXkmaBczDPg3hEd/8fV 0jlE37xMh3+gm66Kjt/zuumqrbvO2INzOcrpLswWy7nBQt7Vn43D9XG90aLNlWt0A07l//PByr7b HIM+bNWXrLO4d5pj8Ql6/1/5G9R/mymzC4zJ6PxC48rqjvGML+AJp76RrjEzEjVEHJPdj8VrUIX/ OIqommRUiVV7MzVlWFitJ1hNZe0CtBq7nmi1P6tfg6tIlXB1AGtRy6sq8aqZ70sIsKoErGl8u4LE Wk/EOpA1CCBrPSFrNt+mcGatJ2Z9TTMtDLTWE7QO1tUXRq31RK1DdPWFY6tK2LI09YVxq0rcauGt wsFVJXC18mY8uapErsM0vlGLriqhq4230bNrodZ1w9i1SO+6oexarK0ljF3dvO+GsOsITfe17DqS N2TZNRaClrljvJZdGZddGNmARU/hS/S5ODIqHnMZ5ZXPCMpFQbKriW2mgheeLBoFCa8pGmWiFylf IOk1g1X24EsZEL5m1R0xm1/Kivg1VxO7XIApCwJYB+8yXoIpEyJYp+ZWDSJM2RHCujQe7UMYGQG2 0AMa6RozX4R5imOy+6J9axAmQ/9Mm2THKJItZSpM1yHZN1i7cJKdyOpzJDuJteBIdjLfF5Zkp/Dt CifZctYglGRn8G3SkexMzbRoSXaWrj6eZGfr6tOR7BxNfTzJVvJWOpKt4s3qkexcjW9wJPs73kZP spzWdcNItkbvuqEkO09bSxjJhnjfDSFZXtN9LckKvCFLspchdpnP7q0lWdolGQY4INPl+BK9al8k 1ut7u8Tyyj8Kym2SHcc2U5HsqQaXZCdolIlkpKxIdiqr7CGZMiCS9dQdMZtkyopIltbELpdkyoJI luFdxksyZUIky2pu1SDJlB2RrF/j0T6SkRHQCz2gka4x83qYpzgmu5cdUEOy4XyAZRXFsmGmyoE6 LLuQtQuwbJxk2UWsPseyDawFx7KL+b6wLLuEb1c4yy5lDUJZdgXfJh3LrtRMi5ZlV+nq41l2ta4+ Hcuu0dTHs+xa3krHsut4s3osu17jGxzL/oG30bPsdq3rhrHsDr3rhrLsn7S1hLHsLt53Q1h2t6b7 WpbdwxuyLLsJopd59VQtywZclmGIAzYtx5foGQcgs+6d6jLLK38iKLdZVmWbqVjW42HZBRplYlmP h2WXs8oelvV4WPaduiNms6zHw7IbNbHLZVmPh2U38y7jZVmPh2W3aG7VIMt6PCy7VePRPpb1KJah BzTSNWauhHmKY7J74qwaltlfSQcUu09R7AdMZSN1KPYQaxeg2AxJsYdZ/RqKNUqKPcJacBT7Id8X lmKP8u0Kp9hjrEEoxZ7i26Sj2NOaadFS7BldfTzFfqyrT0exZzX18RR7jrfSUewnvFk9iv1U4xsc xZ7nbfQUe1XrumEUe03vuqEU26StJYxi/837bgjFfqXpvpZiv+YNWYp9C+KWuWKGlmIjLsUwuAGV JuNLtHkW0mpghksrr3x9UG5T7AG2mYpi+I3HNsUe1CgTxUhZUewJVtlDMWVAFHuy7ojZFFNWRLEX NbHLpZiyIIr9jHcZL8WUCVHsJc2tGqSYsiOKvaLxaB/FyAjIhR7QSNeYOQvmKY7J7v89tPZscaBQ qsyEaI4ce0Nx7LdMdeU6HHuXtQtwbKLk2O9Z/RqOmZJjf2AtOI5t5vvCcuyPfLvCOfYeaxDKsS18 m3Qc+1gzLVqObdXVx3Nsm64+Hcc+1dTHc+wz3krHse28WT2Ofa7xDY5jO3gbPcf2aF03jGMionXd UI4ZrA3HsTGsRRjHTL5Neo418IYsxw6ByGVOPUTLsbLLMQxvwKV38CW6+VDkVfshLq+88qVBuc2x t9lZUhwb9ezGfqdRJo6NenZjH7DKHo6NenZjH/GeFuDYqGc3tksTu1yOjXp2Y7t5x/RybNSzG/uz 5lYNcmzUsxv7i+aG83FsVO3G0AMa6RozP4J5imOy+/45DMec80UFtPERCbQY43yVOkDbh7ULAG2S BNq+rD4HtCbWggPaZL4vLNCm8O0KB9p+rEEo0A7k26QD2nTNtGiBNkNXHw+0mbr6dEA7SFMfD7TZ vJUOaF/jzeoB7WCNb3BAO4S30QOtQ+u6YUCbp3fdUKB1amsJA1oX77shQFug6b4WaAt5QxZo2yCE mR+1aYFWcYGGcQ4A9RC+RB+fg+AyEi64vPKmoNwG2l5sMxXQ8F/4baBN0igT0EhZAW1/VtkDNGVA QGuuO2I20JQVAa1FE7tcoCkLAtphvMt4gaZMCGgJza0aBJqyI6DN1Xi0D2hkBBBDD2ika8x8GuYp jsnuNV01QFMEO0IR7Eimolwdgh3L2oUfLSZZfe5o8TjWgiPY8XxfWIKdwLcrnGDLWINQgi3n26Qj 2ArNtGgJdqquPp5gp+nq0xHsdE19PMHO4K10BDuTN6tHsLM0vsER7GzeRk+wjNZ1wwjWp3fdUIJl tbWEEayf990Qgg1ouq8lWI43ZAn2HMQs8187tQTLuQTDwAZEKuJLdG0XkuqFTpdUXvnrQblNsCVs MxXBNnoIdoxGmQi20UOwE1llD8E2egh2ct0Rswm20UOwlZrY5RJso4dg5/Iu4yXYRg/BUppbNUiw jR6CpTUe7SPYRkUw9IBGusbMC2Ge4pjs7jqC/7CHQlleoazA1LimDsrWsnYBlM2UKBth9TmUVVkL DmXr+L6wKLuAb1c4ytazBqEou5Rvkw5ll2mmRYuyy3X18Sj7tq4+Hcr+XlMfj7IreCsdyq7kzeqh 7CqNb3Aou5q30aPsZq3rhqHsH/WuG4qyW7S1hKHsVt53Q1B2m6b7WpTdzhuyKLsUgpe59nAtyta4 KMMIB2jqxpfo149AZF13uIssr/yeoNxGWYltpkJZwnO6WNEoE8oSntPFi1hlD8oSntPFi+uOmI2y hOd08VpN7HJRlvCcLl7Pu4wXZQnP6eINmls1iLKE53TxRo1H+1CWUKeL6AGNdI2Zx8M8xTHZ/eUx NSij7yJRGLtbYeweprbBOhi7/2+UnQt8VNWZwM+ZuRkHZhICQUAESeQpjwRCSEJ4KiJEEVBA8cVk mJkkQ+YRZiYvHgHRqsUApk1/lV21q7KKjxa7XVvqo9qfrcVd7EO7+8P6XrX11Sp1bS26st93vnvn PuaeE62/3nPOd7/vnPM97v3PTcJcqZ37E9kDUn0Zxh6UWsgw9pDcFynGHpbvyx1j35cauGLsR/I9 qTD274q0KDH2qGo9OcZ+rFpPhbGjivXkGPup3EqFscfkZoNh7HFFbcgw9oTcRo2xXylL1w1jx9Sl 64qx55SruGHsP+W164Kx4wr3lRh7Xm4oxdgquHFpi85XYixhYgzvboAlzzLElX8Z4mrD+SaurPJW p9zA2CHpNnWM4TfMGhi7T6EsMCaUdYwdkSpbMKYbCIz9cNCIGRjTrQTGnlLcu0yM6RYCYz+Xl4wV Y7qJwNgzikvViTHdTmDsl4qKtmFMGAG6sAKGiGNAK4E8BbG74HijO8acj2Uv6Dx7UbJschCe/UFq 5/5Y9rJUX8azV6QWMp69KvdFyrPX5Pty59nrUgNXnr0j35OKZ39UpEXJsz+p1pPz7F3Veiqeva9Y T86zD+RWKp59KDcbjGd/VtSGjGd/kduoefYPZem68eyUunRdefa5chU3nv2fvHZdePalwn0lz07L DaU8K4M7mFa8UsmzpMkzvM0Bn17AxneiEbk1eaXJLau83ik3ePbf0m3qPBuwPJadUCgLng1YHsve lCpbeDZgeSx7a9CIGTwbsDyWnVTcu0yeDVgeyz6Rl4yVZwOWx7JPFZeqk2cDlseyvysq2sazAf2x DCtgiDgGtNcgT0HsLrh9rTvPrM9mmpdYVuR1X7J7EJYFpXYOli0hlhVL9QtYNoJYViK1kLFsmNwX KctK5ftyZ9lwqYEry0bL96Ri2RhFWpQsO0u1npxlY1XrqVg2TrGenGXj5VYqlp0jNxuMZRMUtSFj WbncRs2yGcrSdWPZTHXpurJslnIVN5ZVyWvXhWWzFe4rWTZHbihl2Vtw99JeWq1kWbfJMrzFAZvu wsZ3aC0y6+Rqk1lWubbGITdY5pduU2fZIp/JsqEKZcEyoayzrEyqbGGZbiBYduagETNYplsJlk1U 3LtMlukWgmWT5SVjZZluIlg2VXGpOlmm2wmWnaeoaBvLhBHwCytgiDgGtAchT0HsLkheqWCZ8wGt VodanWTtnkGgtlhq54DaUoLaEql+AdTKCGpLpRYyqJ0v90UKtQvk+3KH2jKpgSvUGuV7UkHtYkVa lFC7RLWeHGqrVOupoLZasZ4camvkViqorZWbDQa1yxS1IYPa5XIbNdSuU5auG9Q2qUvXFWoh5Spu UAvLa9cFapsV7iuhFpEbSqF2BG5j2g82KKHWY0IN73UAqSw2vp4rEV7PbjDhZZW/5JQbUGuQblOH WpMFagsVygJqTRaoLZcqW6DWZIHaikEjZkCtyQK1DYp7lwm1JgvUrpSXjBVqTRaoXaW4VJ1Qa7JA 7RpFRdug1qRDDStgiDgGtF2QpyB2F9RtKoCa+L53ZFirzrC4ZKnmQRjWLrVzMGwMMWyrVL+AYT5i WEZqIWNYVu6LlGE5+b7cGdYhNXAwbIdg2Hb5nlwZdsPp06d3CIztUGTGHWMvgy2RbKdqVReS7SaS 9aqWdCXZFCLZ9Yr15CS7QW6lItmNcrPBSHaTokJkJLtZbqMm2beVBexGsgF1AbuS7DvKVdxI9l15 BbuQ7HaF+0qSHZQbSkl2I9y7tO5rlSRrNkmGNzgg0yJsfMs2IbFuu9YkllV+r1NukCwh3aZOstWo rZMspVAWJBPKOsm6pMoWkukGgmQ9g0bMIJluJUi2V3EHM0mmWwiS9clLxkoy3USQbL/iUnWSTLcT JLtNUdE2kgkjoBdWwBBxDGiNIAtidyi9okrTFhTHCpBG71xBpt2jM+1eyaLRQZj2oNTOwbR5xLSH pPoFTBtGTHtYaiFj2vflvkiZ9gP5vtyZdkRq4Mq0R+V7cmWa9wuDaT9WZMadac9/efr0TsG0n6hW dXs603YKqB1VrekKtRpOVHtcsaKcak/KrVRU+5ncbDCqPa2oERnVfi63GeTbP5Ql7PrtH+oSdv/2 D+Uqrt/+Ia9ht2//ULiv/vYPuaGUalfCfUxbHVFSLWpSDe9xQKkybHxnxZBezRGTXlZ5j1NuUO0+ 6TZ1quHbsAyqHVYoC6oJZZ1qP5QqW6imGwiq/WjQiBlU060E1X6huIeZVNMtBNWelZeMlWq6iaDa McWl6qSabieo9h+KirZRTRjhu1s2IdXwGNAmQJ6C2F3wepv7Dx1Nor2iE+1VyYKxQYj2ttTO/SeN 70j1Zb8++6PUQka0P8l9kRLtXfm+3In2ntTAlWgfyffkTrSnDaJ9rMiMO9Ge/NAg2knVqm5EW0pE +6tqTVeiXVhGRPtUsaKcaH+XW6mI9pncbDCinVLUiIxoX8ht1ETza6oSdiPaEKmFnGhDlau4ES0o tXAjWrF8T2qilcgNpUSbBPcwrXyLkmgxk2h4owNCvYON74M28acfW0xyWeWXOOUG0d6QplcnGr6E 0iDa/yiUBdGEsk60D6TKFqLpBoJof5ZXmoNoupUg2mnFPcwkmm4hiMblJWMlmm4iiOaVJ7OAaLqd IFqRoqJtRBNGQDGsgCHiGNBOQp6C2A2fSnC2OZwF+3Q2l4mFk+JtLzOzuWhDA307o3hpM70DphwI 13sKrg1/dRsfPwy2UZ3k+DoZfM8nvh09y6pTHKf0TNS06xOWakvX4gsnMz3GK9eKkqLAAtj4hiex kA6i/il677FFvvjfDPncmcaJ0yBil/4OT/TSvKz6ZsNMf0/5Ot4KV1k1fXulsXykc7PxBhxShjwH cbaA9rc2PE5LYJSmCcloUAhiN5xOOaOkf3VlYaCM77T8arHCiTFWLyRtV+Zc22KNXSCaY1mksWv5 cls854bYtpQI6G5sfDelMKDvJ82AWuSLvSlLQOlEDk9cem7KGVBx1i2gX2eP1qCLCTHouGJAG5fE 4/okBn296PeBPIjd8P1pI+jxr1GavOYCzxYMd03So4fbO/0ROFGz3POLGsam/wGcqbnIg7NP3zIU +is8/bDm9AHUWemZ2g79Y3Bl1jR6xJt9V6YtqYk7ynheO/2LpnbxL5faMepNaTPqFvniXkM+b5Zx YhUcfbhJPbY1WzzWRaxxEwagGMb9UVQoKJs7mgeLS8dwMFykv8FtnsO4MeJMXGT5cvGe7/bN4Ugb MH8bkOSegwxfdM5ZWQTf72u8EiqgPZPC1D0jkrkCthakLkY0/JOtzgR+9atGlcZ3FpppxDWMNF7e bqZxUcZM42l8r3HNVrcrLP41rrDVGZHr9dj4rs5grldtNXNtkS/estWSazoRy7jm+uvsxFoPYlKs B3TUWQ9fKczqqnDbxqBVYX6fb0Db246FgceA1gR7DFIXc+T5a5azbC6cYxtrJ3uz+DbjTlY7BZ8b MM2hUHs4OofVTsUv/PBM9KNGPJVmtec9JzSCKICPXzFWO+s9ISmtOAiqtZX/EKOReL4jHmW1VQ8J wRgUtKBg9mNCMA4FGbHqHFq1nFatZrXVtOo0VEEvWW3N0DNQMrPiVUhobf3DfhzNrtiLowVPiVEN aodz8SSrvcg7ASX1YpNCsoIkS1ESEZKVJFkJi3akOrKxaA2r3YB/uumZuDYvm8dqryDZeu1Y1ize Goyccf/BSELtfYaN70s4sjPexL6Irv2E3y7Et761ZTBHeAxoWg5yhN3ibfAZm0MQmmo35ZMTcian aVYRJScUMtKzuSA9EVt6os70xJzpaS5IT4szPa20riU98cnW9Gyh9NRQehK/8+eTQenJWZJB6ekw kpFPTydJ1uYLb9cJsYuNGr6c18hDLYaztsbIhIga8K1DcBYfU0q2CJHGHPJhNhnmYUgO84BH4B8I g9j1NHZyfNt3pI2V1u31JkLixep1t74vAsAqDoBrdX008sBp2E4mx+r2U7VqIEnEUqzuAI39MG6H GNcN1IpxUBvfafoyT6xjuIIL41esY+Pb0IlFVYd92oz9jN8hRXf6O9AdPAa0a0AYxG7xyC7OnoCk jKk7mHfmn2zO/HOBM3dMtjtzJ42DhjN3kTMjtQ8tztSJHZmZwYVhe2Ox8ZV3iT/9w/4TdN+2yIfZ ZOhKU6f4EthO8UV6XfglsNAtPgG9i4At/vrx3q5sKJPuYvXn0H2DoSCSTrD6CSTwoKC7Pd4dA1k5 yTSU9eiyCpL5tEe6LD50xVNY3oYPJ8iH18Re3xY+HMM+7sIuH2aToQ8zutAHPAa099EH7Bb/tJuz cyF6I+qneIE+zYlwC6ufajgBn+tIMs3wIhKKkOQ8wwd45CDJdN0DlMRTMVY/Y51+cwCjCKufiWt5 JkJJdFsuH/Ga+rTh4HPdwsHfYOP7r2508AHs4xbt8mE2GWOlaIoLDr8OtnEGOPmRcPgj4fDLcDKI 3eJPe+AA6Z02/05vOBNLhdn8uw7p7qYz0c2Jtiyb/71DunPZJAn+5ZAOoVYa303joBi3Rtn8e0hQ 6u0wTO4lyUhvsyE5RJIx3o78Qv9KonHe5rzoPhKVe9tisfYIfK5m8+8n0STt+R4zcvXJcALi3JyP HXoG8fgcGx88H0Ls3sF+MRWzRT7MJsPieKMbY4XHgHYGqASxW7xjO2ch+NRU31DqbcvC1RTLsYYy lGK0gE6ZUBQgxBpGkUzzpttBY7QerAlHYSat4azyHDzlNIzF5JTncgnWcDZ2d+2C/DWMQ90xt4Ei urVnu3DhFmx8++HIzjoMpypD8+Y45GNtMsa8nWGYePyqbbiPYIWY+xwjJ9l0RyYSC4Wj0QxrmHBQ 7HWkNxpDHAhZOckmebPtabjhNOgXY403SuNzaVyrrd9uJgA+B4kQUGBCRhoeIB+OiL0+instSWAf A2mXD7PJ8C2s+O8QAxo6MUQcA9rAdvxXiNAtxXnxhXeivofBqaBQCwq1x1ENuyMtW2INk1C0m+/c CfMnw/EU4yMxJtfu1fwV39L8fMP1PJxpiehiT79fjDth7BuL4+AeTrdgfib+xZKnv2kPj6Wi+eHG PTzSE0nEGB9FE6zfw3PpXCgXj0Ap89GktRJmycAiYx75DSSq/+iuPRxjnxccBkEzTFqBc3j7b4Rh JJ1KxQDD6VQ2lMowPhUj4+3fDacy4BifRqpf9O7h8DF1HX4C4FUk+wxk7Tmwmb3ai+P/hXFLJo67 biSNj3txgY4UzLOaJB+CJN3cnMWp15Do3d4b+DSI2337NL//gObfw+OM1xsTsBv5bhAu7scTgL11 dOLt3hv57SCv69cNNpD8DZg/K/h4BebC2/8KCHKxZDvjG2mXJ3oZFsDTkMdv8I9ABz9QwWcVuCen 4jnxO4IwhiMUTkVDGL1MhwhPaDbcHCGVTXo6Q6Z+LNTOJr+UTyx8dMrE05l4ricvDbKbeFEvrpWL NONMHl8J1Da7mU8EKe4Cp+0WU9/CT8MYZmLf5KEVq9ZccP6qUKgxtI4qbcGlqPUtoVm6DozREVGp GtvLdSU+fFkv/hzBW36/5r8VNhTNpkOt4BAUUIn4ySHfgw6k0QWYMvkKY0Xe+sOav4//thLP9/Eh Vfis0cfnYav18Ri2cL4f29I+fgzb8j7+N2yX9vFzZ0O7ex+/HFvG9/H9ouPZx58VHW0fZ3Ow49/H a0WndB+Pi075Pv490YFpXsLOI318VDW0F+/ja7DVYD+3VtO+nqymfX1UTfuaNJfka+eSfMdckh+e S/t9YS7t90tsy/fzy1oZO8Dh5sj4Af5LasYkRdNCzVFqxqeguQ0uaZznNPwP8gWW52wTZy+k5shO oXT8brvSx3eIs7PvpOnvgaaPLzxOO206Tju95Tjt9JHj+k6P006/wLb8AA89L8wew8bXx0+J9gCf +IKY9GpqvkPNb6kpelE0F1CzC5uRoRB8TEhHwpD7hQte1XB73/012Z4QzSWviaabmoPU/Iya16kZ +rpoZlGzmposNfdS82tqPqdm0hs0NTU5au6m5kVq2JsUI2o2UrObmgffFK4//xZG5gDfDvXJ+/nL aQ5lOnNA8/fzk1uxP3sAS/bIXyhgRZ8I408+Fc17V3FsJlwtmn5qnmoSzafUtITpXItofkXN/FZk BB/OS30j4Oj1n+2f7C8DfnjKOC/z+gOBhsACGHqLmdeP3cay+qFw+VXC2SVBb8nNS/2NZTXBhUG4 pooYdhnzYQc+LOk6fjrtr+TmYAiQJoBKQycxXGQxLBEo1WXBKcK+WOygxNhBibEkzTBMTKcPSuEa L0Ob4RVgWgXaI2DeEpq3rAyWQK2Ro/I+MHYm7oCxUSArMWSjUQE7YyrF0oZnZ4mhvvWxldzonm3Z IdxoxukxKqIYjS+mqfXhOaPyZxmbMBosDc/Kiy37qijObwitzj1T92widhibVCFiM3m0LTZTyizT TTXchE+jmi2J502DM7BLNn1UfmuMzZgnppxZo5uJlC4BB8eByaxCKXhaifZoVGUkRVfBqMw28p43 Q+kchyZJqytZgeZcKhSbrMZaftWwr3mORVCp1ipDQR3ViEWlfrQtIPPNaQOB4kAwgCFvmAJ3tQWW 8geHF45jxsqLjIphbLHVJ5x+SUG0GFtqcwcl5ztCUS1sLzA3S4Jlo/W6vVCftUiflU4vt3hLZ0h+ kWX2onwAVzikKFuZ35mp12hUBmMXW03w3CU2fZSswiitKDOidKl1S3h+tWmBwzWjbepriy1XxGWm +6h6eQ2zlApFcl1exdzv+sL6hBRusF5EmLQrHNNRqK4sqEmSbywIIcmvcoScpFc7tEl6jahs5wzX FiQNpdc5pCjbBHetEuyEHB7SRE0uUrxew1S3qLLZ6h1ZRWyXG8miBZcryWO2uiVZsyXfsFiL1ZQ0 Wm01QrJ4BVxQW6x3Q0xJm9VpUkxotosuaeYbz6bymzdilLZJKJbtjosFZVutN2ZcO+NyRWH0stZU 0p5yjqIjaYdLPeEEnZqNCF0FVYxK3brUusWefLmYN71tjhJC2fYCW5xxR6EUHpF2FkphT71l3Nzg rmIL/nZzaz4by4bzEXwpXE3X86L8bdID4z28xja+gQfADrUZPMAEOPW+wQ1qGvPclJeUB/BpAEdz 8qvcAqvMEfN9k1fq8xvn9lpWXBJEnVuFBEeE4j4YryijaOwz+uDgftHHj4EkY+w24yzM0i/6OB/7 BB9d2MXiZ6eflwzFpwb8DQiv6shmquKpSKIjGmNikIhvrmqJRGZhG59bXzsrE4u2hnMwTnV0V82t hP/sBvqganM8l7VLIjNmGAYFE6m0C89le2TKKI5lslWZdDpX1ZXOtFVdEc/CI968qktimVQsUUW/ loll4ILrSOTooSpbGWlvx0/39Fm6shV/kNBtHaTop6xZGmVz0WisGfoeuNzhKbuTxIaGV2jE0yQV v8ihbmhFCLSb4y00bDFNQT+caaEZIdKGbS6e1DeQjbTGovrc8RZ4xs73U+EEqbTnWsG1qGUXuoRO d6TisIq+MpyYBS6EIQQggTKAAIpFsWv+pgoEUFXN7Wm9F86lk/EIPP2SZhfqwAN2h+k1bN4eDF/e C1SIJWKRHElTsS52BunZVsvmEqF4LpaBtTKhzeFsLB95/SQ5ZRGEE5AqY5iJp1qau6I0zP8mDoQu klwkgjJKdCiSCGezxkLxdFYsTqMu8Ts5ckx0jXMYrnQ0FunMkaI+MP8mUfy8IUua+jrN4UjMcDaW yaT0XCfDuVaqKi8NSEx/ioKR0v86wNI1HIibZ+L2M5gdmrE5ksolqBtPR3KJWZY6SRoRxDIxf/QF Ar+IRH52qJL8VaGJaNOvOPEcPBJ58Gdi3jLuv8L/YOb3/mdjH3tmDfcc5qXw/+H+lVEYjsj4jx7A 9g7/7/dj6z/pz3rmlHrmDPfvhv/2+/+fvWeNceM4b3hHOSStOCfHcmTHaca0Tybvwdfd6UlepOOd LEbSnXA8S37UWC+5S3J1JHe7u7xHLRt26sZq0SZFowBG6yJF29hpmqJAgf4oWhR9OU2B/kgAF2kN o3XdoGn/NDEgwP0RJP2+mdkneTrJkuXUvYWOu9/MN99875mdnV19cSg78oUfDltDk5HhPa/FXo+d P//yy0Njd8as2Nuxd4YW9jz3Nlx8/fnY288P7d/zhaHDI6+/PHzhB8P3vhb7JlAeu3PIHomODn+P /Fv06PCVZ+tDhz5Wj32qPnQXYSluBP7wZh5uAy/Gdkejl6DwUcIPZP81EOX4HbFfHJr76K7KL+z6 fPTF4aG5zMhQM7P70cy+s3D1nHM1/P1IJiZlRpbZ7/AoJvKRCGB8NXPfUoa2MtjXPkEb15dmiUf7 cah16nCBaJ+v7pSvDpeE7vXVnYE6DSPKRB8jbC8cCTxLJnrPNnq2F0S23CS4ImRJ+IzBAiftGLKp EqmyJJ2onF4gwW2TLF5xJVisLEgV3JRqQoEkiZzBQ07Cxbe2bKvE2cJFujpEp74u2ZjrMG8cmIZr kYcw+SkAolPyqAaKLAliAuhafB2ckUaiIBTQtzclUzUgYnVTbqrAe5cv20FTw4JMpSoEdwCtEm+j FlQ1LI31hAt4rCOHhZpsmhp4OLYP7vZiIe0GMAMM2QYdAr1l1SDubkiQtk+9pso0jxpl3eDaad8u TwL5BWBWAQloDRKExIs6oHhJNzhBUlObIITZwOVWJi/QXAN7q26fpKNaFqhDMO20LJWAVXldqm3a UMUUGejMWfIEApLkS7wBpLpubEqumgFVbzSEsaorpyW5Z+sSe0xZN3oSDESgSpctfBAAnKFFQF1t VV4F8ziqN9fZg1HbZto/g08NQLCGaqrduooFimaBx6hENgxcH3eVyWSEehfZ4sbjFc4THOJuJEU/ RU9Sfw73Uwveg1wAB3yYY3XQkSWvqRLrFfvp6AB5vAW2+frHR3BlqYb0kCM+MLgU101QC2eRI/Mq 8UCVo2iKyllFqCObqzAvYSRXmTvxXedCdLQLEfvJ+ONyAkGj6B1OwVRr4C9iM5EksfmCBGEOiVtE lO6K6+4zJ360hm6uy6YSyhtgSe6PcIXWFkZ1AteyITQQqauoG8h7F4yxiiX1NuQT0la7MNnwGHJW zztQuSksC7KLsGML9mJMcXzOSwIEI0JqaCZ0ozcCWYsYOopkkuD7ADC+BuIj9MIB8dwDRuW25ViP 6Ztp1d3F73pxp2erG8KJWYSiqC0V4sF1sYYMsxKMELbZnjzrn3OATRvCrXhn/m3ywA+MvrZ4bKFi DtV4egx2j/GDscgB1pVjDxYJz7oWx9TVYI9ppDnURE1TNJM/E5LbQUvzTOOGsufvwY38xL9Tnniv LBCTu4nzRgLkYy+Tg4XRoszcPiPCaIGG9GZUjpNhYpdrMPZ4+8mxCuRFcmJfMicLo17P4I29fe6E PxBnSQXMaLR7bIzkqQ1oW8QLbqNntRgZ0pdlHb+hNV1vk7psyDj3JUiS7aGATOh50BmeXnWmlLNL 824x5DQNFc7GVc/lWcbhUBk0xYbvNkzf0Ppshg9WflY6zgbaFiQKk4Q2souQd7WL2Qu7YPMC305s 4tvHLoJNX9VATF1q9Lri+SB0e143FcuV+YknQWPrssHcSxJjrv9bQMQN2ra03uI53JcUnKwEEwSe 3TGUxHgtwdxfDE9Od/fD0CV1amJqQJz3bYBfmGLgaGX23CkD9OXkX+ZMMG9nfgRzFgfJACdn933M 7BA5tt892GsQRGwLAYJiYi6EDI6YfL7jHw/9sxmRCJxR2vEpTE08g2OKnj4kkrybIVgzHDM893FH DNUd9Z2cFpxEgNN5Q5cnv4gljw5OQUDtIgE79zPhiZAQwDHDeInHiTfJEjcUQq265Rpho64attCw K68rYR3GiS4GZg/THWdEXpWAcZ4xnVgKOLgYz+R6Hb08PA4xHTZVMfnk2Y1PMkEAXxn7vzfxpkQ6 XZmTzi0sVytLi9LKY2cXAnd/3vyCDftVieWMLk5z/TsSCMlYmx1brsHZNvm55Vwx+xgkA8pXM8fn KpPIagYcqEUyymYXGvIzmCLT7PYymF9QZX5AgjpTbSMevzDaNlLW4BfSO/xiroUqnSkgo7akBgzX qtRSTA8CkvW6MAooDHNnBr3VAgb46ULdZMzIcAcP2LrNfnhvnHINgiIDNwc4G4UytdZrSpCHuzDP dECjVwMCHsyGGwe1VoMM6kBs95K4FhxyAJVxHccncVmK4GoVIdPPR2PTAHzcVx8R5wcIYXehiHcS 8E5CBfXhRcU5jzeqAq8FeC3A+5avPir+DsLf7QIv97loLAcXP4zwthGBg/d3n4G/YYFHX4jGKFTM DPXz9zBh9506Vp37fDR27jZCZn39Dom/Ffj7scC7DHiXAe/XBM/DPvw6/MVFmwdfjMYeBOFjITkQ bvvwJgBv4iOevLf78HqCV+iOXAG8K4D3iQH6M3x4uy9FY7uh8W9Hgnj497QP7xu/FI19A5h4Kd5P 73kf3vyXorH5j3Obh/FeJJ4fPAV4TwHe6wPwvujDm74M/nIXyD0A77f89ADvKcB7awDeqz68Y1+O xo7tJWTSh+eI/qfiGm1kfDUaMwBv9wB6f+nDuwh4F/dy/Yfx/s6H9wLgvbDXq/Pj/QPhukO8S4B3 aS+XY5cPD+n/o49e6xXw+7v76eHfGz68NuC17+Y2D+P9uw/vTcB78+7B8v6X6B/xyKvRGDpV0ecv VJz/m3i6ZAfgFXwFzuW7IbzCvmCcO3W3RYJ4y4D3HwPw7g7hHbqHkK88H+nDS4bwvvsbETLs82en LhfCe+N3I+TdaD9eMYT3+tci5G99sNOkEsJ76fcjpHN7Pz18A2HYh7frTyJkZYD+HF92jgf/PEK+ DQ70IFwfJl5ei4foXfnrCMnv8uCArUIH5mnC2nOsky7Me265MO8B8yuHudSYRznMO8R8yeHbGHzZ hT/CZXjRgXkkTbgwN9AVF04wGPMWh7kiMT9xmHsw5iEOf5TBT7nwHVy+yw78MV7vwiMMxjzB4T0M xnzA4TsZfNGF+Uj2ggvfxeBLLryX6+sVB76bwW0X5hn6TRcWq4avOvA9xH8Mk3tD8CdD8H0h+FMh +GdC8KdDMA3B94fgZAh+IAQ/yDzm28IeQ2CPPb76KHnnJ8iho88I6HOMePqMgD4PEU+fEdDnApy/ 94oD7yMVvAD9sMddoJ9H4HzF198qnHO/vHX/63De8PX/Apyf8/WPb7sWv+zAI+QrIX7+AM70Sx79 vwrR/w6ccbeew9+/Em/tGPHxPS5nvRjhT0S8NWKE0yIwMe+itzm5dlbAiwLeJWCc/+C2K4y8+8G/ fy/i+d8e8L8/FPgXBf5fRHg8RFn9HeQ1Ub9/iNd/V8CawH834tlrZOidn8QA7y1hjz1D+8hegN8E /ucZ/m4yKpJTUbT/jIArAlYEnBbwcwKWBfzrQ1683wnx/pKonxT1fyzgRQH/vYDLAn5ryMsHyM/3 RT2N8PofAZzz6evQcFC+UwBfBnlOivZPAPwjyDffifL2FwH+TyH/CNj70rD33AHxf1Uk3R8Ifr4e ov9nw168U/Dnbwr8wwL/n4a9/HUn5K9/GQ7a+39C9HZHg/a9Lxrk74Gol2/2QL45DHDxa179bDRo r6VoUJ+ygL8l4M1osP9fAVjx+dNvwgVubd0XQfge8jtRT158KvJHvrGUwt/fhOj9s6g/KPr7sYDf EPDIrmD7Tws4J+pJHW4lpWYHbsz4ru26aVs23MVm6nDXW15ZWobbyuqKJAE0H4A+W3YBI5NjT1na qq0qmTwuSOtSs63XcEkBb8ckubdB+G2c0ut0Nh3SC4vzHmUHOLF8/MyCC2E3zrVHte5SDT/Wlh6v 2ofcDcHS49P5a94VrWnurub+3cpwJ47rEMeOPQy32WWpACL3rLaqGv4SfCNSrtQXyvmFNVF+9qw0 lSmQG3mDVpp/bPH4mUqZsJWOQH8NQ2qtE4MtfIUZsYCLs6fqy6cYSyF2JLzLhttdU97kCwL+jdUS 3M7W6lLd6jE0XOzfkCUZbs812+sln5niYh1yVlumK6DhgbKfqlozTO5wHV8DCbAuDAcC8NcjrH5N WvMDFWwN6Jt7tST1FG1N0abCSnqv768GFOj04WqNiyA1NzYksI2Fq8+avSmt5Y4dKz/66PG5ipRn RqhZlmjM3rQQFFiJhCUBbhlVn8nYuixvbZha124EPYMZTvjjAHVJhqmGCOqGGuxR5et4IhaWTpyo LqxIK8fnTi9ANGIL9mjd36SjdizVDhB5pLuOq3bLqtXroPOWy8BASByhQFwmthWtiytSChGBx59u OSifXQNKTc2yVbPMNzD0iSIw+z2zXwtrbB0tqGUvF0LOAa+oG5t+hJ3jQ3s4e6Ukq5m1YWCwsr7B xX+dWTMuvMc+cvlc7sD0NMnxI3TOFwrTOZLPFaYLuZkDhZkpkivkDuSmCL0ljtdDt6eU4G6yq+Ft V/9/9CjeP79UxoVzetbUL6h1m1Yfq64snKHJlm0bR7LZ9fX1jNXWwAcUzcal46xiK9k1S80ezuSy 4BQZgJOziaJon4if44vepSQgJBGE0c5cBCcrJatIaAEIQfl53VzVus15zSwlMwDP9bS2Ut2ELNcp JdesGoLYvFwVlEvJ8rnqEegqXiyzLXaJeJyTncdVZ8CNr2waADa7vTpCrNh58MYxm0oNa1wW8wgt sc00J7Q2IIzWFJ/TS4qmI0YZJnpQbfJ+OanTMsYLFaR4fzAAqVYpiTzGi2fUbg8v4sUV2YSpFF4K hgW9JCtCvLLMHrSUkvvljnE0UD0P0ze9WUpKKJakG/xhXkM3OzSAhyR6psqFOa/ZrVISFIePWebY AxpBTYUJKz47KCVzvIQ3WNiwgfGxjM4Lq/KauiRYwutyzzTVrs0rl3vdE6beYZYbNdeZtCDlwoZa p+WOchqUUHqoOT5OJ+t0dKNn0FFFbSh0skkndYoaHu2O6mqSjmoANZIPZbmWslxNW6gMqK5upS+v rtrS15e6iFFKLuKz3m116LV9rwq8ObpiinJUpINyGnQUZkbWtWlnTkTLQPX4Kt9vZwrrAoPcMuS6 itFlXYdKkqOpc9XTlfKpucpiPu2kA1DNOv6YSTppU1Z2bfpZVmtX01Cg+kOlI1O9Di25eXSQjnyV V9EQMJ71YTLXO4E7QUSuvXlqW9S76nUoa81izyY1nU4apt5kQXZtWkE6PXtQsl5givFX/1Ro5gYc 6lp1oshWa4BCJgew6Ovpmkg/vPgILVMujzWgD17PNC+QMplMf/Y/qSlqpbGoC+Guy6t8LLOruKMh NrXQ/ayJKQeb2EyWk/0SFrPOPKBY4W8yWBxHQJRPgDJZ+MebF7N+xOJpGASwvJjls48B859lEAtu +HZmQD/tM6Cd6c/Vpz87c5+duc/O3Gdn7rMz99mZ+2w192GGZbUn9LaimglXe1X2+SrqWR6ubJic 4KhePzqWKcNfHS/qhsF+8WdjA34Ns4m/sgW/imHCr2x14BfhGiu9IK/JiI7XFtJQEdJr8NuyO204 mVhq1/HS2MSfNtdl8QRdLCVDj+wcabkIA6U5qcoAD5amBfRPYtd40WLStJggWhe5sFpMPORCa4iu wuSXVesq6tLqOpLooSqUdnMLGnOa3ZGNvsa1jrFFgyW7NVikJLeysG0xK5b8ZhMf9Proh/249vV/ 8f70eziuvv6fmykcPMDX//MHcgfzB/j6f35n/f9WHA+I1+tp0XkJeDbhlTkvlPvLrE0rK14sDhfz V5H9peKV5DAie4YaLHZeUJ5NhHA7HbkbQE0G3l9OJhI9S+s2Kdu0jiM/BZaPAhWF3YxSU7Gterud WpPbaSpJkNglCc5relu2Id0AkEoynCQ9QpOl40nKUNMJ+v4fLpNnjj8qlZcWFxfKK5WlxSrNUxTL FZPyIHwihPYkiKl1bYqPzWkKr/ArhRMUH+TTMfxC4RNPphNPJ+LuSz3e//nNnvaWchNqVynljibi 2Jp9o5CWaI4eHdjG/WQha8HfsaCWWZ/ALSVIo0FTyEFxKg2dxuEff0ifApPJTZViOuECWWBbs07F y6SztIgUGDj7s91kGmjFTRUmhF2KPT0DnQF2iVLeZ4qJln8S8VjDUqCigBVMvUwquPEuUXzOn0pm FXUNvzVRk7tKcmJJWp4/v5xmjKcaSjHHuOYbS1JJbHEkwEpqMp/m3ABlppDg5xdLIfMIrUJrYIC5 PPQyUVkqr5yW5uZWpMpiZWVif5CG4AbaMHZ8/DACFFp7jQPcTeY5b7xT8bVH6DiVLxYLufTYIaaT OPrGGDVsE6sYkKZ8S0BKtBkLiZEWlr0fGqWpX0W8HQ1qyWEkEecbI1LQbCK3kctNbE0/EYfbBObA GriWVgwrUhsf58rgexNSIhy0JzPux0mZD2bYnpZUmvHTh+v7vOkE+JMPGbB9JPFbpqU8HEcD5RYv L0xNzwQrxCdfMXCCFc5bhLSUn5o6wLrZ0hmEuHRiv8cxl8PnDvEB7hBsz00R8Al0imcSbjiwb3yi 8YU5ssgbtnJilSGURhUIxAl2jQrKZmlcbAdLITKLL5Yz8M1TN4Pwj4My0EsWPNWIRIN8eOZehaLV Yp7NA46uOlZmjgAsro72R1Q261an+EYqsOAAvLgvfY5RPEOL/a5qmTGyWR4N+JED6sUDOOx4KjU+ zoVJj3IljHEbBlvlQ82mBmIVEIuhH81mfdgOro8LPzVufJqiKUw26RRDGKfYiqbprChlsTxOtwou 4TXCtiLhUuZEQV9hvvsMc5O4M2Yyy3Gs7Bj+gi+ujhbS7PYPdTo5637dGFlHjsbSXFLEUduW+vT2 yAWG/Az+jGUT22EfBWcEHJFdQqgTD8kPja9OOD7tBBzbRYgBh+gTuJ1Nb6R8HsIjzRFb5T4f93x4 vISFk54+mNuPjx91ZwkJyo3FQpVevAh2RJSwZ6ZLJRHIXApQKMObzad5gTAVTErkNRhcVRaro21F BNqoguOJiE6XvSwnAuPTBLuYAJy00FNg0GYlXsgiyHd0pgozubSTLMAFfE7B69nQt2X2mq9UvQTG g6xvJAMlbZW8fM0bMkzKFOaa0CA4tjlspZBVAHfuDm/46L//6ymGZKr1texN6yOXm84dnJnZ6v6P XXv7vwAvP5ObniF05qZxcJXj//n931XsXz5XvTk+8B7sPwNFO/a/Bcc29l++GVJvs/6Ty82E7X8A hu+d9Z9bcRwxYBK0pppHTPnna8cu9Az8JMORwnQun23pHTVbX7NQ8p2R9kN6bBf/Kvu0jW5u3kAf 28b/9MFQ/B88gPl/J/7f/2OLT6eGfGEn/D+sxzbxv9C1TU21bqyP7eK/MNUX/7mpnfc/bsnhmjtT z+Yz+Uwhk8+u9FR6BpRSOExzh4/kDhzJF2gBZmnZ7Ep1OZ/wmnTk1etvtGZcuNZG8zt55/0+ton/ Fbl5431sO/7nZsLz/3xhZ/5/Sw4WZx80EzvHB3ZcJf69keEG+9gm/qfyuam+8T9f2In/W3FkxxJ0 jGpd3EpBJynbwM8+ZWrRhm7SlfJZKncV+sj8WVpva2rXzvL1AoobSU25Y2WgfTaRoM72jHhR/McI s/4y8RH8QFlgI0mo3NndEagAJpHRrMb2g1DslG+fiFcXls9JwKN0dml5Jc4e0YYqTy5V/5e9aw+O o0jvPbsjaZ+SLAn5JcHoYVuyJVmP1QMj44e0tuWn8Os4wAyr3Vlp7dWurN31AyMQ2BiMbPCBOXwV U0UO6s7HOQWVIynnQiWAL2VIUdSlEpJLQlFUJVfB5avKJXX/JAVRvq8fO4+VLcmkdECmVZrt/n1f f/3111/39Mz09OxW1/X27nRXtzQ3dcEfOGW1x8Pqj8/gm8KsJobVJ6IiOpStx8zWw2RrYVzosS24 ayN9iOcRxTOTCgU8HlzPoS/nsK7mEE9eUXo00qDgDrGJJHsSxXb2oCR81KfGElQ4e+aNLUhjd3no I0dlWEsN3s812ifWgMRjcS3BH1iLokY1/REvbgQ6nBrE9Q7NOkcCE4YVIK24UiBnAYgYUnC5zxEF pCiJnAUfYh2DoZxQOhkzrPlghUbr6pgFVjMz163boPZtD+5uUHbt6Nmi9m7cuW5bQ3N9fXezRRV+ w0uhbYkP1+izNJakilgZw6HEsjRdQaLgI0Z0e4WVKVTHTULoEzLUbIwpaJXClNXLY2meZ+BhbTRZ V8eaul5Zamg0/rAyi9TzLFmgKRVLqNHQcCx+FKRzK0zFwyL0BxiH0slEvK5vO3YKdd32704pFpc8 cN5UnamX6e2g1NUxFwRGjNQJx6yzeOP0NatXupVmtvLq2FdvMVRGoRv/ioVGpvZqzbbXVM2VrRIv jKXpY+HDQ9BF6hLduofSJ7rs4Si6d3Q0OZy1AnayBtHvG5TmXLssr18qemaDspR1wHrx8J89P1VM T/FvaIcsR2RQ1cJDyVVZddgTf1F/ZoA28cA3m62JkRP4YBsJAl8SUcTnCBTcVPiQFqluSNgPYb/5 YSbzP7jM/0plTDP/a+3saLXO/9ra7fnfnIQaZW8slYERMrs1hzKoJXBXbi2iRGEkalKU3qSSSKYV 3ABESQ/FUhRX2EbUcPJXIhrdvhxzhMCbYEpYozRiWI+fC1BwmU0jZsaXTygHJXoEVxBG6ZvwbAsd 0BTcshrnoekkstKpaUTDT4hoiXBMS3m2rdsSXD0Ijqphlr4oKKyw73BlRunOZwqoTb8aEY1pMCjz 172Uw7F4XBnQUGjEE4uCvKhS3bNhY7UHDqspkwdKiUVBLAjuMYpcpTB6DWTUDirVtXWQp75ayPbs 2LO7t28nFwIJ/A7P6to6Btfr99YhF5yye1bTyNa+9SyyY/1miOzYtm3HdhrPzdiUVDyMorPVK1QL GvVg9n4sdDAcxjdRIfANJnRhtXXLN9Q3Jat5PtCjHsjd1Z6tfdu30IymPFiHemQ2lAUq16PV+9mn dJTRTBxaRC9iCSi6SlkC01s3VRVVohnoa2CcPRSPr1L0IjwePc5xlKXwklESKij4kLYKpowHIrFR pXHEUMFqLIi/4sicd4TvU8PfDoTJAu5jD+Ur8I/cPZg281IWKGB0WGmMGtXUEWrwqTLT6ycUb3JY USgv/iZOxl/uznWz7Fvf3NEE49fD1WbvZraPzYmPmcf/mZz/b33nLxam2f+rpbMjYD3/B+z9v+Ym 2Pt/5ex+Ifx+htte2DtdLOODPt3Dwd7sawbGsjf7sje8sDe8sDe8sDe8+JZueDGHm3XZ05WvMl2x N+aa0VTFnqfY8xR7nmLPU+x5yrd3nvLN3FhLX6Vm76l1C3tqTb3/U4++J8n/wSugM37/syXQ3tza gut/Ay32+59zEqZvf0v6Fp4GTPf9j5YOy/sfra1t9vsfcxPs+/9T7n5tcHj7unqmMzXjhtf2YwD7 mx/25bV9eW1fXtuX19OL/rZeXt/avtdz/KUPe65jf9xjLuY59iTHnuTYkxx7kmNPcuxJzrfhyYP1 xqj9WQ/7sx7fuDD9/X86tH+lp0Cz3/+zM9BuP/+ZkzDT9s99CjQw4zJu/vynNbf98fGP/f7nnIS9 u3rXf5JHiolCyNo74BRGZ9U3y+EknxUSMuIjZNw7R0p+zcIkBLmY/RIHofZAW/ALFf0lrKN0vwiY bWi/b5VvGGgdMBQ6oWXH3Z/5Rjzj7t+zUnawgx3sYAc72MEO/w+CBH8YcD4GU0pSAPNLN/zvGMAb Jl9hA2YX+ylZjjdh8BuJ0+nhcJC1Ziy2IpdPSOuDie6RWagjrhkKYOJcSvT65kNd84qZ3JnW1jEF JvHfeetRUl/vtEJmbR+8AiKkiGxLRnpD6Wln9kJ+fa82sjWWmvYaMsvP75Vuv7lKqA+a1CXhrVwt MZgemlb/IsHfs7NnOnXQH6S1ZuxG/pCarTNw+VbsRvL7emdfAF6nYnBY+hdev7ngn92OvfX+Nc5/ SxzTNJQIMueX9obimekzzNQ+vB6zN1AxaZ7k4YuifJJPvix8p2hF0VjRQFF50ZeFs5JlBzvYwQ52 sIMd7GAHO9jBDnaww9c14IUv3mxbSCxLHMRT3ttIGUkO7O/Bj2a3IIi3qjpJgNCbKR8X/MOKS8rF EF6Sn/yziz+cYlGYg93Jw6yLrYU0JfM4qQekBfCW1scFzy+/5Bk5JxRkK+gM3ypvGqo2p1xcRDcp JWFc0JdKt3atbGnrCnR1dgU6OpRA28rWztauOzs62tsC5tStrv9IzsLEN13/0YZLPnLWf0DKXv8x F+Gx4NYNkiRl0xJxEslA//xHLBWgxzpyO1lM9pz69a7Hf3MC0sf/9beXEa//xdXg7zBy/De+M8Ff 9X/+Bbjj8V8U0+T7enLM5XhsFYD0HuWNmMwirgbHkfna5TyU7gIqHM8ELwoGH8Yngr7j78iTzWeC lwW+AONGQddrTj35CEQnXsYjLSXLXHyKgtfnW+DrS3PyXLTkufbPMq/2RUMVsnpeNuh5menpQj0v GvS82G+s/xR6Wsvkel68mZ7Wul1rE3peNuq53zHUaGiLU8HXjo+9Ro7SRlo1m0bCAehaKZRxNfiK RD1BPhN8pX/IuV5+ZzLzml7AheNjF3gBa2ddwB87sYDzHuZqk5nzutxzx8fOkQyVu3vWcu9zUo1B 4H4ymTknyBPBc6eCZ68GT6MLXg0+jT9ngk9PksfHnv43yPJo3rU3HEg5QZ1/7AQi9RL3VNlQsKt/ Ys+JU7989zNnPR7yaoHf7C+yQS8rd5mR20SKXh3vAOJ3ZCuKHfbOZhN6dVz0agsM5w/SRfuXWUwe 8vYPSeu7btiE+2Zt6n+X0IYnJsm1D/9ncpLb9vjYaTTdT6lup7kGZ8r+Cml0hJF+eSp4ApSbCJ49 tV4GRYdQ4Yng6ePvhPonM2cNphwiwjtOo4YZSBnHm7J+awQyyfu7JjMnpqhkCYo4aajkdc+Z4GlQ fvOkVfl/+RK7nrX452dUvF5p3eyOqc3eiVIvzdbs148xtfvF+DDdgHt9c86Q8r5lSDGQfmUhYf3/ BCMUngiOT+z74oMrZ+HMARZ6fMyHi84yjXA+kDLLsD5dpvrI1GD7ydCRfB3+4ArLbWXXcdcQit0v ff6ioIDfzJOK80vg6HQtdi1xlXoJcZRKUqnT5fWu8t4FSaefOF0Y7SvtgnFFbgLqGp+z8Km1rr7S gK/bR0heHsEoIfkYIaSA87gY2dUk6Ql3EfF6kclTS7CQu6EIbzHHfEtpfj/VoFBoUCiKZBKKqDie KIaTcynmmVcFWVcCdwnILWRyS0uhCOQqK8/WASasqAEh5YAVCmw+MmBkQRMtWtRsIU1y1Rc1SSK6 2KAhuGMFt1Ees1Gln4nmydvLs1RC7pgPOUXNFL9Bryp/ViHMVX0br1kNRgipraK2WTLfZJulpQZx y0Q1YSYimxqxvg4ooCVZXp5VjZAV7VRkQ4Bno026BipYAVkac1GoaRPmx0wrRaNwFrRKs2j3bDZE WyycDG1tIjmcbcxRTFjA6H6toFe7pRBk6jBiCHQyHzGwdM03GeROXazX6/f6vGjyVUuh39xlcH+o cHcFESWvFh5DyN3GOqH4NTnWImStqTqIrLOYopXmXa8ry4Ce+dxve7nUPC6VkYOG2jIKwzcYpOdl DbjRgiK2KauZztcnPIOQzcYsSNti4kdkK1ppY6mw0jajSkjfrufA5I75JvZ+v6FH3KNXH1l3BojB VZgld2VZdH135/onNOEeYyfCRttrEcdM9Z0cn2T4vTkmZPh3LSZn6H0WbobeTz3bKuGBnEZDdJ8F RexBGLUKMaJaasgEPTQFiv01xPwWWQaMtWO5wqbuxrBITndluGbyW4ZFDe0NhQ0aszKOIZOPMCxW hecp42iITXLAWGnGGJdNnW5Yb2+kJrLKCxslTQiz5YilsyB20DgwY9mjU/QotF7K2JRMp7TF6Ria mcKfUMAh2XRGOJzjxch0hKNGFY9m3UUf9B62uBBix3LyosRHclGYE4zloqDTo6WSruBjfsPpb1wy tmdf6TypRFoLvelxKS87TDog/YQUMKWPS17Ih9yEnIA4iz0pibOmkHMyiyig81M01ZIt5WkopYXK OyU1cfmC9oyhxDU+5JmgCKbYqfg0pDeWMmucEXGo4LM0TshzHCPkrKCClO/ROMojOx+X+FIpmV7L v57PLgKmuFVFVuJtjpWHk6MHVu6N4V4P7Su3aKMJLb5S3Cia+i4RoS+vrlihtDXBH37DPdAcaGlV 6nZqEWVTKI1bEWSOMGpjZz2RHXvh8ikeTiYOkS5HuzOihWPDobg6kowl0sTRhVRHDXGmh5KZVCgR SakpbYQ47mS47BwcTWZGYolB4ljDIJcTMqrhzOiomjo6PJCME0eQUXzOMN20IHw0S9nAKMXO4WRC tRS9kdHKKM1S/CZGW0Bpugp9DK5wjiRTsXTskKbi99CIYzPDFWdCGwwZ8C0Mr6UqR0dDYTUSG4yl U8Sx9QFKqXOa0G0MrXeOqOGUOjKqhbWIBvgOhi8HHNRTB6CC+HI0cdzDCCucCXOGXQxvANycYQ8j NKIkUBFskQI9H2BoE7Lr6D6GrqTaWzR6iNGaOc1cyAAjtlCiRbMIo7VymjljlBHbhFRdl2FGCYhs OiXBKO3ycviVmqG/qPdtb6cOF9oV3Llll0oiSJHy9uNP/ggu6ivoxTjzSjPFZUFhni9jCR78Yisw eeUXCWJ49MqHgOLDqH+PDFMFN4y1zkqnqtJvkUJ1nXcgjv6tqmH8drA6QJzV4zKri8DSyXjysDZK nDV/SCldBkpmZAQptYzSDRRcugiSl/2MImvlRlmvd0u7KFtlnx4VJvhIpib4O/zJ/ydcmlYYxDiq bMaLTBhcl2jw+zD8z8OIj5QcdcH4UlDKi8H3nojkluMyWuUkskzAwZMawg/KZhLYUjAy0B5X4JZ/ jAyXkAEROa/4CsSv6NLd8gf4ixb3ysecKPMYjX+GMEbLsjVME2cdKlmWTTvO/RrTibgaDqUjRK4u B7PcJiMQS2vDRF6CRZfh52iBO+/jdiDz+pTFsNkBzb8dM0EpGZU2eUH1/ZD2ZGvC/MBFGWglSUEN 1pgCWKmC2nYhIJ6EUaNgyQUUgHGzPaBQFXN0QakFde8ik6mMfJQh6PX3M6GQbulAYPl/5mXNTK2b x9kZeQXXCYC2VgQaLnEls0hje1ZkRwCB1mC+UJQeUKxLiGUsbUNmFlOFXFihg5lQBDnvQmHUCgLp HmJIREM7FzzNk5kYpZ7i2gyy5DNZ5ZKYnLiQTTJFTvPcw8kItmXBGc6fiMcSBxB4lgPJaBSTz1UV CMWZ5zESE3aW6zrCyv4emqq8HJy/4Pl7IZv/L+CASVfB89ABD4XiQEAMOvb8JrWVINOC83DAbvhR Aes+BbRLwZEsfAOOyGeGFxkh6GiY8ZLoChL4PIp10yP4Pxx9GAU1w+DwtI4vVDFgNB4bxvQ5biVM s5q9yM3EKvZ9bpN0bJga7SWeP5PSwPvh5AfYec6TMoI/4IwR+q1xAP6Ae1Pq8ECcqnKBcxzQjmLy ZU6nqrLCX+EQFk5lvMoBkMB7ZMGPuBSAwjDQA/JTE8IqdYk3VzSl873Bqy4wxvnmkOCMxuKc82dZ ToYxzrc4Z0qo8qdcuzh3oJ83MkUOChP8ecqNzfMEyxcW8Nt7naJXjaQp8pfCVmCKuJZA6D1qZKBH YlR63kuUBz8DSFxNH4Lgxf8Fs8CN4CXn/C6pQo3GQ4Mp4ndLl9j5pPI58Bh/ocSnSZUbgNtfxJOu yk9gGugv5klf5Uvw65/Hk8WVi2Gy6C/hybLKv3XTG1V8ylP5JlTIX8aTFZWFMDz6b+NJpfJd7A/z ebK2sgCTC3iyrjKIBS3kyYYKdTg0egAXXfsXS6/PpxOGChxVYwnir5TepEgAKocL8pPEfwevXRev byvx13Cou0JNxiPYY1NamviXSCW0+62twJmgGk7GM8Mgs16aoNy9FeohuklKNsNyCcdXR82Gykq0 1Arp0QpMbqzAk8kB4l8pPUuBTRXZLF1SIy1ja+VJNMFd0lsLMbm7Qj0ci/ATn79bGqb57q2gIxHx r+MKP1ChZhL4sVmoRI90jjI9JP+NVz9Xd6l9O1RscXGOfq2CDhxoFin/9Qo8R19DfvQCM15kwqhz Mde5G13n9sMx6ul5AxK6Wfnfg/ru3VVw3eCfhAMmXe5tOMfAJ93EvZ371B2vAlV29yuqejg8RNz3 FECaJQaIeyfmXTDmY4NckZ+Wfxv+5C/24yB3zoeDXLsFXmSECGHDZ0Yj7l1rfNR1YQANEFRuwT9y 2UuZ7AYqpJXK/i2VHbDAi4wQDKCoFM4c6ADqhEETi3DTo1euAqKPRylcReNdCGO03A229ty+CdL+ t+GASZ9nMSgM80ziqWAOR6o+w9NuZVVW+Q6CWRZ838+Uf5sp/x7V8n2q/B/5UfkOC7zICKEmKMZN j175I9QKo+WvAaun5lPUamchIZgs9ihCq6pGo1bVTCsXaNVJMMuChkKmFWaFsu7Fn/wHca3/wp5C 1KrTAi8yQqjJp1SrT6lWEQB9GMXTNJ0uRcNp4t30SCEdCOFY/VYhO4flYyQ/XgyHk/PgcBoPL+Hh VTxQFjxAvp8Dpx85j0K625uGuqWG4rEBdQiux+Ia8WbOlIk5NPQx+uaO99AVmV0fci+GObL3CPNj F2DR0eSwyjgfFheHcOZJcuyYuCxUWQ3GYoXsUhDOM+nk4TBDH/3JPHYRiIN5LM3Axz6Zxy4BVVVL RBg27i5hl3+gYCyhJjS41IlQHYj3BFOqFmmhI2bak4xWZ86XThLvSUZpMOdCylOM0oxWSofSWjQT J95nGBioKse58ulyOtR1yb3FhiuDVtFmqbQ2IoacF8qoX7xFHeAH+PCx8AHMdFS24kUmDNttFBj9 2LjnYUCp9eLMKJlJD2SixPvCy/NEizEITEW85xiKbcZOZ97zeovFEodgFo+3GPQGvcDIPkrGrwHD xTsMqcT7CiMUCyOMEO8PcRCAJqQ9wfsq6wnYdOnRUAKK+vGD1IkU+cF5BqN0Go1Ch/TsYMwsg34J gy61zCHMiZU140UmDC2Dzu6Wn4ejD2ftbvllCrD4sjxD/zF425b3KNP7cKxGH8PBl/UizKdn0V1x ++9ojv/GHOiB2X6nM2dddIdSgrxL4VjTUpLDR43EOO/dTDn74Vj9RElOb0bfYr15in5tFQjRtHaE q7vvVSr4Jyj4QyFYF0cPL4uDVdLBjDZ6lMkJXady/gPleEq5HBwO8jHF9HDLxaV4vCLnSNLtFwlQ nlVwrN4uBGGESgNKeV5O7qxBtYM082F8rPVEKa8J8aOX/TWq7x0Svsf497eUiC4xhW0OPFEiuoal nPjuUtpFWNceZl0be0QCMhNv4n/5uvowp6ozf8Jc4gz5mNkQkhACzMDAMAzgZD4ZHYbhY/hGERS1 xaaZTIbJkJmEfBBGqqKiqNTVll2s1q3dan2KiqWrtFs/qri6Um13H552u4/dx10ra6vVPq641LXW uu/vPffk3hsS/7n3nN973ve85/u97zknkd26Tuvymrr1UqvS5n49JPs12Gz2Ue7XlyD8iijFay0Y z/BTsQrIZ5pAJ4JTVV7JVBSTVIrvscIlkPciIaZ3h/YAkssg5g2HdhwATyGXTSMhZHNWO46hWBiJ NF4fb5qs6ktHvv8kT9KarInjYKN60ZqnlZvkEuPDKVXkL0/jYgzjZU9OQ5FXIIxMrXitBaOVFqxQ shEWBWl9wot6OMEFyxDNiaDRRYTjB+D0vY3VuPMwBedlfEIgumjKEjKlYkNiyoXgmT/VByxcJbG2 E3KJ47JNaUeWVLbAu9Pk8g0hpNVevOzX+7B8V/mwfIfDJXjQgrH5FkuNDSboE11M6XiU5JFxEG4V 0C2wwSfF3y7F38Vi/pbFD0rxrSV40IKhFiCyhp8O7QCBThk8zPBhDn8TMILeyNqi/2JK99nJRYT9 EVOWyu+ktYYXY0rPIRMkU12k/AT4eco90UgSV22dLcKvPHVNsKv1L2TXMRe+O07BTed6okoOGteT 8luE+lYWy5XrhPwSodEHo8r1Y31V0m7ym7pWK8TK7xnVsX7o53p7hA3zZ/zoWPchfKqqFK+1YNDU y/rCXHdw2KG9QE8ngguaA5QltdtQPLYnF8nEs/lkTmiuU80GmNolhCmajmZyiWhS2ExYPJNJZcQk EzKeYtdmlXAdpU+ZF6mUe12/qDLoQ/FsLiNcv3xqetFnqSgpLOTC9Wtv0DC7iqT8eHYkMUzk15cF 1XpuIuNr780bg2riMlHi4xSBZ9115khQregmejRZiE5kld6u/5aJvNZESXkX2vXb54JqzTdRYT6p FL+T/CEedKzWO4enKcuNEC7i7yW0Sbtxuqn1w2h9Xaxq/peC0iBCOvurQTT/vQi/qJXitRaMVgy8 7XhQH0Br07JIkTln6fGyXyfZYdHYAclHNUmyw3CVD3eQuf+PSM5P6TGlAK9hBK6tGg0MNdp29p8+ D8lomBLJ54kK0mtO/vyE/1RcYLGo2pFCPvZJvk85MyA12irIQDVLs0GW8CDA58xgqWCMaUp4fxAD ARXi0E5T2Imgazl98j5VhU+r9xvY7fE/+aCcLdnr8YGMaQ3s9DgrY9UN7PP4UMacDezy+F8Zq2tg j8c5GfM2sMPjjzIWaGB/x0cyFmpgd8fHMlbfwN6OP8lYYwM7O/4sY2TDUwdhY1S4/iKtz0WMJaPZ nCJ8Jgkd0qNAozXAvg3pk5hkQ0Gr5j5p0z0M0oUhXJptBxP+0ab5Q6Y+2Q7xRV+E6pU7pRcBbgmb PctehAsRfqqqFK+1YLTaXUpvNCZ/P2NlJ/mj+bF0hJfzQaI6kcSh/Yrb+lfcWhOAEayDB6X4+Y0E dupHdQ+Z0XZikHPecbCxt4KM+xRNclEyeGhERmyvEGXOGXqsqFEGIvdS7iMydSGTyMU5+YjtYyT3 zDQnN7qUTJ6Nx3dx6rStiRLO6Z9ptj4RU9+i+JyWPLFkKiuzyNp2gGmXmUnMiqVSuxJxXe/8OG+O YsHZazsRMsi6oib6hO2MiS41M5GvtaEoiqwrYaLvs60h+sKL0X8O2M5ReMbXZgmBeJ3rBlsI+gjX fhtAGiEhVkC4brTdw4AWQo7CdZPt7zheHeIshOtm24MMOGEetAkIDiRmSfPg6CzuJd/Hy35iFsyD G2exedBWggctGJtKITzP8BMlq9Ggv0M7x+FzHH6aEjvPmYpN1a/KDO+z6xYuqFct9tWbf08WhXeY FmuiVl8FPwnH2JNb/SV2lnx9NqkDT5e7UJWj77t4TLj3zq/WN5v3kJ0JZKKB/SeaNjrb5JiDhzqb jsfUkIIsKtQ38LJ/azaG1E0IB6tL8VoLhsI5ZqOgeDq0h+jpRNA1u16IfupMWu3yhu/Ru7Zf98Fp H802rzrZ2AiZ1LS6R8eUMmClDObhZW+phzK1CPdrpXitBYMCR1mZo6xMmEAngq7HKeRnZS6Xylyh lLm13jLdRMqo87hU50nO9ilW51sI+7VSvNaCQYWueqiDp0N7HuogCF96Ok/rdnaXqB2Er973FZrY a5NvEtG1qUEIRPfXjsJZg13z2l0A5VZMuF0gWaCxQXbdHQ2c4yBe9hGc4Zne28Bdt70ED1owGk1g falen7dmk4ZvsrZvsrbjRHQi6FV7Me7et7A/oO+suDehq3mN3Q/3jrurdTLWaPfIg+iKp+cIkRsT i9wHqnJjso/qPiEBYIxMFLfuCtIAjKTyGeE+qLwmSDIUnRDu25SjBEiKmG5XDhICJuJRYtJdRF4g BWY6JJEAp2HkqxIJAUlkh2ioue+UUD2gnWO51PCwcN8tB00jsGtT43Hh/pr0xi3QHp1jdJi2XLGT oJxUtf+Ol/31OdiAfwFhKrsVrjZDvEw0oNLxdGhnCHQi6No7Vx5sqXN/u4q+5tk5hF05999jdKH2 CJV+Zvd3JFStbZlrtuYT3BTmUQ6hlPX1eNkPIAf3yFwh78hY8VoLBtXengM18XRodxDoRNArtxPd j/XJnaNsYmckmkuNJWKE1vl5k/E/iVQ3+1licc1vFALR/XUz9U3GulnA9J7dIZAq8Je5smd3NbIG vXjZV+KSwXRfI/fsjhI8aMEoO7BiXBV7NgTX8NOhrSOiE0EvqZuNYx/hr9pYvw+JcoTYqj0zdL9b Pis8IdkZ+Ds9nRjn3RTPTL3Paq82Wpxt6dyIXDDJJkJKVfUfysJ8zEp/BqXdZxBGdla81oJB4Wsa oTyeDm3yPFIeQW8xK/qmiWWEZ279PPZ/zYNZY6HpByWEzTUxX4gfkRHR6FlYhV3qXDQ2Ig03T4sa lfocmE4lE7EJ4VmkBqfCMTUKz2JMZMqvORKnNZipwrPE8GhmY6k0Sb7QcGXuzEczQ9h+FJ5W6f3w yoqmisLmInalPGE1ak0U4WmTfqGQQqWUdimlXrtsvqkZuiLFCojmciRWtQLKTzV7A172W3CC2J1A +Ec1pXitBUPN93H14unQDhHoRNBryYeU72DUyB/7y/SRh8M8RL0I27q+4yTfs+ZfSYar0CQEoq2e fnygya06z4prGoufp5FClAYyfUB6Vk6Zp6o8TXXC2GoIkLXNmQjPwMPzeaLCgOoUyCRwaZMcUAeb uER34mU/3IQBtbOJB1RnCR60YDSgwFo0cWdQDUBwDT8d2r1EdCLou57qzLP5aBO2VxcIgajm2Yiu lh8bo860Se9kUK5LIF3gPV05pKcMg3jZ6xdAOW0BK9dVggctGC/6TbzoNyE8fwEW/SZT08j9es8W 3in8EOdhrtlIiVw1zUIgGvBciU0IeCFojkUfvsoYC2P6FqLnamMcjEVShfE49ckvGC0yFtmVGCfW Lxrdf0xvzR2yNetQ6G6BrAO/WSALDRWoILV42ac1o9Afy0J3l+BBC4aCQlANPx3aDAKdCPpyKN9Q C8Vd99EDUc0zCG3yufheqWPM1ApLBdIGMs1SofukQt/mjB9mhe5oZoWWluBBCwYlIKiGnw7tMSiE YLEVUuMxmA2eEWTu+vVCIZqpP9V7xkm3TEGvqpTR8QnL6L9n5kkbmygEs8FPtb9b1r7TSGyMlYyk 1Zk4DGJWEr2SKOskZ0w6hKWzI9EMekJetxe0f1hYdprPFKRxpCYYlIvq5A287L9diAnmFYSbq0rx WguGOnuZ6+9lrr/3CHS+bK4/lZPw7AHue4hMRM/13haqzLvpgWi1Z588mLdLlukrejs3fIIJ5zq9 A6PVewQYAyMtstUhgDQ5gpf9flz/nr6/hVu9pwQPWjD27LWwr68F4e+0wL/XYtJaLZjQ++aTROFl xodrhZ5Dp6H8gUXUE7DB77kV5m5U7wkHjZ5AWCa+O5/gBrnN6AqEpzFmMTpvN4YdwcWWvkPvBjjC 1CqQX2DHIllm5EvluAMv+92LUObcIj7D1FqCBy0YO264zKe5zEcIdCLo651Chbr7YYq7XIuFQFTz /LWs/LuMIdcWFkgTeEtXBGlJ+FS87NNxgXX6p1KRcAketGDIHIJq+OnQZhPoRLBY+VQvR2AFuc4R 6T5Sp27qAfTvVJ5qJy6m3rJ7qqrjaGanmHqrXGLZ9Rml4ZrEAU0x9aBR5VTfe8TU2yCPKlv7+WKT LdxurHnJeHQ8n44M8h8iqaHxiSznOS6PbQmGxlsIQzErXmvBUMLOxSihfF5ASZwIetVBJu+zcIx4 5bE6709fwHEleeTO+y9PICLPN3l/iQMOXnUkzvsffNzJdAbM+0YXvmCKx5q8790BucahJu+H99dI z7xlaZm2oGWBBdbnumnNP2i24DwHg7CQF6AHOuAuoiL6li6KbIsMplLJaDI9EhW+i6lCt+XCYfhp snIrOdxmTjIgwGyz2cA4RF9Vvt7zWbokTaWdhLTDib00jHzLzk+9VFFVeg3pR+J7ha+vvGyiqbTV SKt2sIVveRn9w6YUiq0ObMn4cE74+s9n6daJKnU9UqfIkPWtKK8Q0VTafqTNJHaOUOqV5QvLVJV+ /2JCsrEEzSaJ4QTV56oyRWi3pFGswsa8I6kC/zuCb3WFwqsURb5Jik8e1/cNVGj1YpIip2ZwZoVv TRm+ViNBkauauXYl0gViWns+U0+RXGSpA0t+PMGHHnzrKmSkJyhy1TMXjnXHuEbWVyhYMUmRk5st OjSaz+aGE/Ek9dQNZXg7rIkU93EeRSROZ91YaRSpJIpxA/QdTqaiKtNNFRrfSFMcJDaZ6dBgglrw 0vKVKsmWMRtPDTPHlvIckmwdudFEklkuq9AKegLL8I2m08J3efnRQjSLSvgM9F1RIW0ublFmMDEu fNvLpyWaRQckvfL8pJ1Mskwg2J3yXVVhbOdzllmDPmnHaZheXX5sM7U4b/hO0bTt68F2rFboMNas EsbiwRjmmvwIXvbj+PEB910It4tSvNaC0bqELBzaz5bwzucShH/YgV0ACnrHBvlTm+b/mgjvkkzt EULuaGXIYMn2ItwnbP49S3JkGv6MGH0XU8BfwJeXbz2J9vMBMN8ELY/+ibpOLE58lQnTQGAv5PmG yBD0X7vIoMGh5VsIH4bvOVLWv+9pEqzd1GmtBpMe62P6ec3WiHiml4v3Al72U728/wvOXNV5+LFS XFz4NqDHqV78N5TNpiuaxdn6ga2xrRtjJOgXxGZ/DdJa53YRa3y38N9clrMtvps0jG1ri4j/Yh1e M1i/BNZkTvgPlmdN5iqxhr8L1uWopUNlebtjqbE0fRkMbGEBo7xdYivd5Qu/DjG4zuK/q3y55XYt pAg4MKQEEZ7TTeHb0M6Hy/J1DJNdD67RrdvCEb5UYjPy1Ys/DCFjqT1x4b+nvBQQB7bEIEds53tB vPtkFKD1EciIpdITwv/N8jJA/FwZ4T90q8Z/4HMbf0tsNGYWwUVBjxfhRUsJ/ZTGrv/BsiLCbblU REJkqVKrJthJYbP/jltzFOy3Ucf3Hy3PHs5h6z6nuGN6c8q+cBzcMzH+jlXgju82cyeMHoXspQ5t NprJhf94WQntRBvYIzNtt42nchFO/GT5rqfTuZRST85BTMIYxd5QL33kqymmTzgDPR2RzTjqLQLL MR3A0AeSzYlAP+YAWPp+MApMHF79oCEXRwR6eZZ4rMc8S3Qg8XpMmcV89JmCOuOad3nkb8LLvvVd OMBfAjdnYCW0TrqIwtLvGIC1tLG87E4OUA1BF9vkayBBdK4wMa+tqJfOizlM5Y05V3Rtv0gpFdio U0RX3gAvKSanjiN5Wp8BOUW2SjSXytQb02pgS2XlY3uSpDkqXmke/ghittLcHdhWUe/0poGkrEuT GqK152KTBouXicD2ihLG1peVcK1ZQosIfKGyCkkSgC5hFfC0RQURGKysQaKcgPAnEGCn5SkwWrna eF5Hf+KRJGtO9prwxUBepS+0wHhl/vF4Rf7rgDyKe0y7K/NTbHNE3n1NjZc0YLfkzlUsuJU5aS0/ 7IIOtgs6+Px7L+wCDsqrgLgVOAUfeMI2ycG3CCc1rbAaCPr5F9gIz7CN8IdeZSM8i1MN0kb4Cc7V SjvgOagvzYXnly+jQV4w2Qv72F5gm+Akj/YjyyrbBAXDJoBWNKAX42VvX4G1//Flxtpvxk+W4uLC Py9Ty8JLZbMp2gSFrRsLJKiP2OyrIa21u0+3CX5allPaBAVjGl5tsGb6dJvg5+VZ2SYoyxr+cZ+y CU6X5TXZBAWTTWCcapLL4Qd9yib4t/LlLtoEBd0mALMIdy1XNsFrZfmUTVCQNsHZ6cXMeSGVxb92 edEmeL28FGkTFCBH4LyPTZ5/MgrQ+pPlRZvgN+VlSJvgc2SEbf2q8d/63MbfUhgtmEVwUT7l+ujv VzbB22VFnGcTjPKBH5t9A7fm9f3KJni3PHuJTVDgU+o2vS+82K9sgvcrcFttglGjRyF7qYNuE5wt K0G3CThTk03wx/Jdz7AJRnU9OQeaTTAz1PDTofUQ5pRBVIWDT9Q5tC2AweWNrJB7toVUZkhMb0AH Xjp7lRDwowotuLK+oDZDg6tAnD9zJU0XwYGeSKQQycUzY9RoIrgWraRdMJ0MDSbEUpn4UH4sLYLr mGILKEomnsNBQxFcz4TqOiIEzq2Q/lBkjBMdeNlbVsEf6loJf2h7ewketGDyIhdpzBolxmlKHhLB rbeS2PlPsL6Xc+bZXCqNrefgdpl5USsQuCBXmrQ6tFLfjJZa9XLuK1mrB6VWHSV40IIZWkF8GipF uqDNuZXGZNuBBOrrc7PMaRtLvBoSL3AjzI1hJVRbQTQqilvDT4cWJtApg8iyhp8ObR1gGUxw6gQn iQBG0DuUwEHvGbHdhEx6hx4SqJ7x5ard+RRRomp/LBMfEzMGjY2F9k4BpsDJVbLW3pFleZ9VPse1 9toqrrXOEjxowaAPBNXw06F9At0Q9CZ15Xa5V1OmB+mRVNqN6Nol1H49azeqn3+Cdl0CXIHIan0/ dDVrdyde9sOroV1hNWvXVYIHLRg0gqAafjq0e+npRNCbVOoVjkG9pgFST4fqZuR0/fLYBC7qt0fG cKOtvVuALfCZrh/YsXAO8II6AP38A6xfdwketGDQ6Rjrd4z16yHQiaBXv/AfmrtxMsfk7f5QY1JG 4YUMzbtORvhmf2j+VxHT77eHmvgqcPG+e2jB1xEfzrKzPdTMl7f128ShJVtr2JmOy+2httN2GWHX e6jnDUTlLflQ30OI6LfcQ+s+sPPvG8g77qHNNsiU8hMBuOfVBe1QLsIHkFQ0P4H8pEc+tO9G0MwX vEN3bgCUl8W6h29I5/Xyf4PP4Oe5+Pfy4Xv9NwlCz53UY3xYP/T8WT3KB/VDJ/k4v/rlgNALA3ZV jcz80heL1SrZ/1nmU7wPEHq5s5hCijjFd7Qz8Z2JbI6PUYVe4f3S69bSRIERP3ONOus3c63prF+e kXUbquWhlCvWGpNLN44B0YSn5heIop5yM17223HL1j2GcESU4rUWDD3pozXoVXg6tLsIdCKIi+ZD 8jTbrG6+y05RnOSYdckTlGbSnHX0fSqR/bNWVw1Tc/CptlnrQJGbYu1LBdIG/rRWdv22dZzxUrzs fevQ9T3ruOsvLcGDFkyIOrD+zVrT2R8Irvl/zq4FPIoiW9cMzSzZmTh61cjdRE0yDouASDA8A/ic YMIr5AEhBIbJZBImhCRM3qjoKqB7FcUrKoqP3Ss+Flfxqri7whVXWXF9XfeyKr4fKIqI6F3cu7qu 7PlPdXdVdzJ+5vJ9dJ2cPnXq/6tPVVd1d9Xw0W9cQCcDEE+wIVfB+AS1Qj/nvUeHSIVcTZ/z8e4h HORKc/CQ1Ngr7nMOn4TvfLV1+Tlez+tkdIpjsX7OII8ng5XauvwcwzMSq+F3lQjxHQ0tcrKf8OQ0 tHWkRPZOD5T4yDXFfz9p/m3kyPlv9u9NxZCcVKylXk7ds58y12cHpLI+0SiynzZ1x0oddgDK3mXq TsjBUiwu4A+mv6HGbSVC+0gTmVqXOz7Cfq6Er9DLSHyvliCMHoX83SC3PujQ4Vqs5gB640LIOPqN t+hUAGL27aVCbKH6GJr9D09ONNojsr/zQIdaiPIKeVIdNVU+UsVFtvBebTKW61hFtsfUHEOamMj2 epf65CKyzlKN19h6ECuc6CD2QCmDfQSJ73elILYO8pYMtz7o0FHoISvK5dDzEq33S0ARR7+xk04G IJ7CC5ZoyhBtwEvF7L3eN0ph9h4d84+Umt9gQ+AD1j9SMvkUmSnZ3tpiZnzTu4tOZK6cIcStaKin TjPKZ+hTuEk0Plyaau1W3yfAlgBfhsS3dgbINUG+Vbj1QYcOBI6fASw4+o1r6BiAmPk1Hb7EF8G5 NcafZuhBg4V+nfJ5klX817L4o1zM4Jko/gDkL4e49UGHDkVez8Vfz8X7ySQAMbOXpHJMl3IXGnNn 6teWeqVYc7uzfFjjmy4kvjVcfhJy+WC3PujQocxjZ/Kiy5n8/RfKh+idPQsLmeRORnKSjik8zdBz Lxo9iabg68koazGFSe7FwJs1nXS5l7C4DYPDVSzmQ3spi3dSB5p7GURj2Czh+DZZK6WkTs3HAYGA ViLx1cwCqWmQUbxTH3ToQGQ9k1rPpJaQMgDRG5rtJmW+msi9gkklZlmkVitSaxSptYrUlYrUVUzq 799DSnvxAAgE9HQkvjNng9TxsxUpTR906EAE8DL46DfGkTIA0Xu0DyltKyJwu5q5TZ5tcbtGcVun uF2ruF2nuK1nbq/NTs8tprgdldwGzwEH/xxwO6xx0/RBhw58AC+Dj37jOFIGIHrfnuPm5tjMCexu YHZZcyx2GxS7GxW7mxS7mxW7jcxu25z07JYqdsBCiPcxiwPM7sU5ip2mDzp0YAR4GXz0G4fBDqJ3 W5mbnXoQlruJeR2xed2meN2ueN2heN2peP2Cea0rS89Le+wFFIR1OxLf78vA6+4yxUvTBx06cDnC vI4wr92kDED0Xje3T0Rae12B2V3M7IUyi9lmxexuxewexexexew+ZtY4Nz2zdsUMOAjtjUh8m+aC 2aVzFTNNH3To+JFmGT/SLIP8y7l4pEmiN1XePzN9Ly1QvJ8p3jPXovhrRfEBRfFBRXGrovgQUywt T0+xQ1EEIILdg8S3qhwU68oVRU0fdOj4I6u5/JHVXF7/W46PrEj0Fle4KZqcHmFOPy+3OD2qOG1T nB5TnH6jOP2WOZ1SkZ5TUnECArxYQeIrrwCn8RWKk6YPOnTgAXgZfPQb1aQMQPSGKtN2Iya57Uxu UYVFboci91+K3BOK3E5F7knZ/38PuSat/6+UfXol9/OV3P9Xav2/0gcdOv5evoK/l6/g/r8S38uT 6P22DzlrqzQQe1p2/pUWsV2K2B8UsWcUsd2K2LNM7M+V6Yk1K2LfSmLeKhAYUgVin2nENH3QoePO v5I7/0p+AFGFzp9E7ztV/RJzX7rnmeHxVRbDFxTDFxXDlxTD/1YMX2aGj1WlZ7hcMQQeQv0hM/mU Gb5UpRhq+qBDx2PMKh5jVkH+AgwhenfM65ehfv32MLuvbHZ/VuxeUexeVexeU+z2MrsN89Kz69G+ iJjHiJ9C4nt2Htj9ep5ip+mDDh0vCWR2XzG7l+ZhSSDY3TU/PTv3RXyTae6ZZ9F8S9F8W9F8R9F8 V9F8j2leND89zV5FE6AI+q+Q+LbOB80b5iuamj7o0IEa4GXw0W9sI2UAore32k2Tv6YCq33M6vH5 FqsPFauPFKv9itXHitUnzGpudXpWDYoVMGBMX83j/Goe/1crVpo+6NDxLh/zeSun+Tz+r8ZeHyR6 yxa4WdW3dtY1J0DroJwBVFu0PlO0DilanytahxWtL5jW8AXpadUrWgBBUOch8dUuAK1zFihamj7o 0PEMoJpnANWQ6xZgBkCid1RNvzGpuP2FuTUusLgdUdy+Utz+qrj9n+L2N+Zm1KTnllDcgITwjkXi m1gDbjk1ipumDzp04AN4GXz0G9NIGYBYtAfcStr5Y9TGRMqesAU8owtp5n0+nR7RQv5yMz0M9H4d aIGWU5+E7ZEwX2c47zLMpyEXGm590KEDNJSYwUe/8RFgQixaudAJ0xrIHythfmrDPE7CLF+YDqY2 rYJTzOmR+NYu5Pn/QgVT0wcdOkD7lGF+yjCvIWUAYtHwWidM17TjBIn2+oUW2hMlWlGbDq02UYJv QjAaia+wFmiH1iq0mj7o0PHjgoX8uGAh3zdr8biAxKK9LrR9pklDJd6zay28/yrxPpQWrzb12Svx vsO4PmS8z2p4NX3QoQNGlJjBR6pp4IVYdPkiJ15t4pMjkR62kZ4skdYsSodUm8zAL5V+FRLftfjh o2NSixRSTR906HhixkgPM9INpAxALBq92BUH+lQmV2K9ZZGFNU9i9S1Oh1WbnsAzlV+IxDd5MbCe slhh1fRBh45fzSwCVhz9xjmkDEAs2tcvVve99jQJOrLYAh2WoLenBa1NOPZJ0AcY3GEGvUcDremD Dh2AosQMPtKQAaAhFv086gRtohwuUX5jozxdooxF06HUphDwSSVfh8R3I572H9MbVSg1fdChA7Jv GOU3jHITKQMQiyYuSdPATLijJNxfRC24Z0i4xy5JB1ebFMA5QZiGxHfBEsAdvkTB1fRBhw4QUWIG H/1GKSkDEIv2ueDqQ8oxEuqcJRbUAvP6p4WqDfP3SagHGNJhhrpHg6rpgw4d4KHEDD7S9QdUiEU3 x/qB6q7eQjMabMzjJObWWDrM2sAdJRCO25H47ooB85UxhVnTBx06jgbG/A1j/lUM0QDM0+v6wazX 8USJ98GYhXeSxHtqXTq82lAc3gnDLCS+ijrgnVCn8Gr6oEMHjCgxg49+YwEpAxCLRDwdXndFT5HA F9dZwKdK4HvTAtcG1yiGwPiQ+AJxAP9CA67pgw4dwKLEDD76jX8hZQBi5lUkddJ5T16ZsSSuIFR0 FExMtrR1dmB3eP5yL9oRa7Qeh18lcVzL5W1gHD2Q2ZNDH3ToUPZJceDA0W/cChwQM4+rxzs34Cg3 DjhxTGrt7EgHBNnI+UlIfCfXA4gHMrty6IMOHQq/k4HcyUBCpAxAzNxM0kxUXV7lFCDzhoTHuLhe RzR2TENrqjuWqu8X0mYJaQsX/RBD2gB5puHWBx06wBheD0g4+o3HAAli5tSEEJOx+V7evClQMKQT Ew5I4+uS9cmU/CGSWHO/wOCGCjsfia8kAWBnQJ7sc+uDDh3AbGdg2xnYHFIGIGa+StJerLjLq56y 3QL2oAuY+QowFo8n2tv7BfaqBPYWA/iAgT0Dee+P3fqgQwcwlQkAw9FvfAJgEL0fNAhhlTSlvaN+ 8uR+YmhUV2uy3nWgFpqXHL2WpgOHEnhDb5nHY9QWW1O9Im8ZomQq3trmLZ+6g2jmtU49HsmKqefT HCWv3Xi8Qa+AiZaPkjSh3EX/1NfQQE78PkHi+7wBdfE/kNd63fqgQ8efbnFdHOK6ONKAT7dIzMxd KsRIupw5+VMHRWdFU4kGc2V6/nk4xcs4NbVcRpsfeWQ0vzA+IVp+fpRsz8anhcaqRkfLLIyWJxpk rvNi7fbLsvBSxjUSia8AP2N4zE3IONLn1k/baunzp1sn+IO/cR/jBOFKtsRTIr+q3/ImmOcjXcLM LM5CnvoE8ixKmwfnKQ9/LGnmEyN/ygtwvm5AFeLoNybQmQBE73FJYlzRHWuTeyfKXTGmjKFgyW89 G2vfrFMiv12WOqGPecnM5JhIRC7Ls05FBGrZ4xndOESIKVSccWCpo4LTubFvCECGPi3J/VyS+z/I jUPc+qBDB34oMIOP1P+RMgAx8/ImIQbRBRmafwfiQrLaLKNBGJclHfjGRSsqZ5qrU/VNS+AEI38k vmubAGsjcg7y9dHf79aLcV8mrWufxM6N2K8j/77+C6T5v27HkWB6KWqSXmJxXgJuMtmVxs84l6Xm 6RwPt4/mBIWP6eXF7/GiW2pe0LsnuXdP8vynCb07iZkXLBNiObVkI/8jVeH7oaUKn/YyMuN0/iee wSXLUG+oXDH+rzixigHEOjtazXwHTaPB/C2xOPeMZeb1yv/cag6OHNYFG2Q5n0NHcZ4s8bBTKwIo mSZFTSBQtQyTIhIzC5uF2InYCi01blvmiI8C7MXbHY0142dozKJgTtd6MhLfOc2IgUeRa+eQPvrd br0o+Baqt+lkqLlvERNlQR2JSJPIGmx3JhM8d1N8hdr6ZigYU5+w85R1NVEO3veOsxHJmmUgjKPf KCYAAYhFl6zAM676REOss7lDOop2JJa3NZOXKfh0YRS6htBsz/nROXXk8wKssUwlEnKLtlCjV94Z C9P5KJlZVxBR3YWdNSJuWIHGwg7xi+0dfE6EFg3A41mOvBG5gEq65I2V2eGSATgs0HI63C1NxPA7 VdR6Q/EBUrazRmQvLR224Es/83LRvZMjPlTzw12PHdu/k4gYnrQLoaFdPIEIEaFdngFeKCtrRFSd yw5H91AYzWjGxkozgdZjvNLiGB39ANd2X79xBTeEO5D4Nq9AAzkEbz2ij160uvQiUgMVFq/TrbA+ 2tkmQokB0CvQclLjwkUZZLauyJOmZwQAwpT64/pEjwglB+B/Qp/87lJObDPxJxqSzc0idNoPv+6T 7Gxmv2A7vdh0Gl/a2bJM5hehNwaAu9CZOdJUnuQmYJbg24rLUfzHNqvTWv3DfafpzKbn4Hpyh/bA AIB+X0d3oSdlnxShCwfQVsekHF4toLZrsyM9dh1hxn/+vi2IHXGpTYxEP+o30Dwy+Og3tqzAdkQs 4gZWROM4YbfVKeYAPfSYdzR+wnobGY84le6sod96ESojMBoP/c67lcbmIzAkDz3uBZIR75MitN2L b+JKMHAP7fAaRSmtHcZKrBF4VKBIajVJJL7WFFpTBWSU6NQHHTp+Z7WC9/VkWp0pbIG+ApORDp2E +bz4tALmsDKFz/rOlYG3ygvqktJlGqWfaZQu59+MlJSu8GLV7AhMO0KruZgR10O/xvsxZKa61otF YsaIdgfduE33sw6m8L9IfH+joyg9u92kG7rGa54RpQts5Tqv07wDZ3IRj+utM+boo/henLqOhhKh G7y8cg4lT8B31zQVjJSbq3cHD+qEN6zhFsVv2llu6i/LjLhcvGzm4QW3xSd2WM3rNq/FT2s9ZTO6 zIIkbA5M/kBy+qwOqy3db+d0NpV4k51P7bRbfBEUv0T9PqhQTsR+2u1yFCrnFgxSTH8E1u8T7NBD dimT4q0tckRPZfAidr0U5jXDw5uOt/aK0H/a+SaYOsrlyIKXpVgY+Dqv1kFYZfDRb3xHNgGpgOjt 6NbDUb0XMCMyo3PAEYmVVlZEYs2WFZEoyYrI3m4VkVhLZOzodERktx2Rq7o5Ilcj8f1bN0LsT516 RPIZUXqwU49I3dzXpUckn7EiclJXn4js1sLLXDs2+Eb2hhWEonh5V5+I1LPM6JZL58w8vNyr+N4u d0R2uyNSFiRhaxH5bpc7IrtdEdndZOezl7iJ4szuPhHZ3U9EMkgxPdLtjshuR0TKJZR6Kcyrn4js 1iLSmQUbHWKh2AW8SAhhlcFHv7GebAJSAXHmhTRSuRQjmVCPx/i2e6ADpHE8trKfoMAbxc9sJL5K DIJ+lAXZHIE5zsw6Q50J9VrnxGyaWEndSktnBhBeWXQDOI40P6BTAYhzftIrBG5qRqjKU0bTOHvQ HsWCFBGa58H9D2fizdgHSP5GWmg+/9ia8UXPQEkXYmphc0bphHQdDwFze8E5Ayo5/3CcGOJU8gKu HhyH0dkARO/XG4Woi7Un43jmkGxp5HvWKH6M1mfXEal23d5ypwnjtImZP1kpxPPYzCz8wRR0QHg8 iClumwjvN3/b2HipV2OOXXa454kuTdarDcCAh/AeReIbfAtuyfuR7fkf99Efhf7Aj5TevG5z2Tj8 oWXNvSzfv0TmmkuEaKCKCITXl19LVsPOYix4cNTGA1+7FYktt8BzeQX1OsMmuqzMxYPNEfFHfqqb dzpK3Gz+VkveTvx1t/zLyPuU+pPwPZgleENDso7DX/+OKjJeWanXB3u3qmErFz54GxLfdqZ7CNYN nj56cZFLLwoKoboZBW3h/sFEPhbPT9qjzYnYskQ9dRNy9fszMs9S5HmY5t/hB/vJI7c6dOU5cyPy LKMaCD+sVRAe02DHXLscC9eZz8H+Derwwo9p9uNMe5SBnf61HAV/R44oVVH4cS3HGPkQE80qYt3v zQw/vZiSWtB4QmVIYoaxZ4ptZi5WXgZbctVIxYrwU8p+gqnEtcCNGAt0tVI4mGREFd8DH6OoLx52 2KMcYBYSp/EybgCmD6FKllnPfAdZn8NVetHFrT7Z3tbanrCKd5Qrpp9EMezZQHE/rNPjzmh2z/1m LLgQGT8iHuHX+lYmr8t2VmaFZyPW8Y73KuuJ3Km1ttjYmvpWjJwHVLZg/4DwIZm3hbcYk01qyFH6 B5Oq04lE+Mv2Xvlket5+0g3jLdXax2KvKuoIO3oJWxuWxaZijdQoX4AHmmtPolY5kvJl3QM6K3gb JIw4wineBimMmGxHI8vCeCbcgbaYheFMuBOjmSyMWsJdb5G3LAxawt3vQ8QYJ9wDQlkY4oR7Mf7M wqP38Mr9MKhC7F5ccisM4PeShyHOh7NVkzcJMX/zKsL3FzT/r2Ur4mfQKk4HeQbv2IS6nb/HtvwH M7YNy+KW5e5N9ogvIi6VsUq1IcIej3Q+XirIN6rf9l19BoxjqAOfaTkJzbgu0ZjEdhX7deNIrek5 iR+nC2d4FG5o3OYL1prmaN0inOmxwUNB1hZuUf0bWK5DlZ5gOuXoWZqIL6Ow0b2aM/QvTdcNrc2E 5GQNCTSRpn4yyZw1ZZeRYhwuw5kSED/6QkjzWtZ2qtTZk/i3kqLxnh783F1La2q59u6spCJa0R7h hj7IvGOgLD6Imods92f9P91jKyj4L1T+EUV8EDUHbf8T0vknfCqrfRA1w39mZS1KlxVlF6jM9j5U oiaGzF9RTA9bJzMjTJZ38qY4TVTddgzaVW3W9zpkfBj3z0s81s1cRkCUCq3Xw2Ch5yACMWLbae2a 7LbyFS3dDYdo1OHFds5p71nKYbstINyRTfvaPvGkdeLFTTiRc7l14kX9hAZ92gW2ySv9m5hlNNp2 b1l2ahMtabLGNvnAYSLP3mefPeCoxlp7OFL6NEweRAuJe0wba/Ly+eXm2CDcIGtOjgzaxR620kgX D73CMk3aptg0TLfk6118jm3ZbFs67XhLreJG2L2CDm6FtBundx3W9Sm+zjbrMduqbYe4trqM2kdh x73LxdLdWapjsZzVvmEbXWE6M610V8Xe1ZTciF74SulqfMoqcvImDdpI2+5qq6+0DR/WsZXDMMXl XmfeTVOyXN1f7UpldoPp0LJzuPsP2PFz8PBGy84xKTN5PA87bPQS3mThM7d2cRn+lQ1xM7rD6kT7 TPSk6fTwGkquossxTD4nJ8oJtmuKiz4RKKbPtszDmz1Oc4e1KO6FYRe6mHstCPFYWyye7Oh1QVh0 7xquJt4iXQzbZd4cTIXb8aIXYI19gFP/pO1aoKOqzvV/JkMgJCgXKLIWFVEkc9BcJQkJoF5aijOI D0RzFaHB6WQySSYmmTiTEOz1oq6uio96fUStFFpwqdXiu/WFb/RWpYCYLpDw0PYWtTysS4t67fWy vPvfr7P3PmfOnOTGtTSc2fv/v//f/36f852zYeqjvKHRn3QFyCP/JQrREQOmPiGaGf0tV6M8VCdc L5Z+T3M5uu7b7cjwAs2XghuZVWV9qPhX34lyiS6Y+irHq0p0eQHW3yME32J4TM4FGHsd5fDbXlP7 mGDn+fk69d+k6A4p6t2pv7NKSO6Skl6dOopyO8lapvxe3jwSnZ3YhPN4cJ2Uf9ItTyYHU0MZZGPP SN1Nui79FKBZBq70oVAiWzdTyaPcE24QNrbqNlp1aaXJn40qF2BL/pTPd53duZZ4Q4KsSJJ6uCpz KItfISr/kqPzT055R+txKV5sueQLROsDqTtW1/WL1tgbudLUoy4lj2jFpLgV0sTzR2sdquzG2WIk V0l3kI7cFS201qFLHWXQoSspBzi2UwKP0YFbXcGlWizCx93EtcorLLeWEWKpp8b5Yokw20BwBZpq KdFeJVSnHh9yqXprQuxVqXSioeQVdCVAx90sFO1BRD6pTqws+Ax2AcKegrCVDLaG6OVwqeftDcRW S41ZmkYgP1xuQOwziTd34Hi4OHeVjOGe9jOSsAFH9HNDYs7pbEsksWzebUppWD1CubzXUzlfeFzt a6MEutwygbxbmNnMvpDluNTlimdDU1pbzS1Cd6lLN297UxrdPVL/ckM/aO24Ii1riEca/kOYSA7S hCuMjgkljA3STvPg7fiYgdhbwkL554O00JrPgFIlVbeKcvQM0grZ+OHez9uSs42MrZWWrh58xHB3 61M3LHLFtwlL1w22TPS/PJaUQeEqaWnVIC0trJsel1v3mnwmnY384o1ochnuix9ytrvOs5bWpLgx p/IGnA1h/RHUp59PLA8X8e0D/4hya6u61Fa+gszW0sffTlKRbIj7WraPwV/Ri0mXFC6j+1A/HyXp 7X6Yui3EF9T0N1lQsweufDOTQUn67GLqTi44g9/LUuVi61Hua1yB9nOxyurmVJfDvCEKeC9OKuxB BfxcZfk4UUr50Wq9mM6Wm/XsY+/gmlP/FFI16TitacrBGWLzpNL+kGnO2xrEuoVO+Umai4ZGvfOc +GHU2IsrrEMiqtnCvn0ktMprijStwrGY2CsMfhZyqeYr10KhVL5At5e/YLegyle4V/1KVi+qxJvS 2VxXnH5Z0qeEfUK9vL7IWz1Atd8pXPgmjwt+ZT5Pahfl8SB/4W9E3ZG4/x4udKuoLj3PuFDZtwrt 8lZv7cJFL7lLOHBMfoh8JT9bKo/xVs5f8FWo+hLeQRkvVGcqQcOPihYq/XYBUb7SB6JwCP7pbuHK pAI4+eJwkUAov8kHIX8welF/JI5wU4V+rRPHILHYIxDK786PEKDP/1w4UuEPky8SSwVA+Yb8AHkD UX87que6G+jsUc0RalkC7iPwmYz7/nzsdVTDzyNPPZPryA8i00XjI2E9aBCz7uEa5S+bGnxJr+qY S/rzpHaft3Zrq4++6vnVEukjE2mROAtAiTLZBEiFL9ymTRVjDV/HFEeEvRTzeexULpSG8VlaCf1b Gi4li5MyvJzYS65GovKUm0KnDcczsknCpExXSyoLJIk+jL4Cd1Yqa6w2m2ogDUPyx8gyspc9lV5N n/Wto0+ff4LXw0eY6cdqafTLaKvpl9FW4/UD6BlelrE3MZA8UEL/loY3YTJLwMvR+IwOpSidsEhh Po11LdwoIeEUxlJwcxom5yE1TPZmNUyeA5aXCVzMTR5yQ9nU8lQ2l3LsyAXqGWf4OzF5qLwYjB9D 70FJ+LU1eCokbcen0naMCaX0OjRxs8FW4ZQ2N2FFcN1MzopI57SVj9c6tBVkKam0FSQ2IW1l/Vql ZzQs6HF/Yptyo6JehJbqOKDPpCOciP8URzZjp3kOETmjRU3vw3TOaKHpLkYLk6YsLcp/g1E77vVi tPi4GYjrEkjfYcHgt8IHy4L58pfBwqvwY0hUt7Ko/pHGo59G75hfgSTCqOknmulQmcEkhSBTsLje 1Jn9DO0lRFOoM0HRDFINQzt9+DpQSTUFwTzoNqyUp9chkkO3KYjkScThEfsVYjlEnIJYOkWHESA5 1AcI5VB0CkHRhzPILhS1ysg7318PJnmnEJJK6yHtl2zoFb9of2KdKtaL2AqppxCwQfchM6XjKYM8 fT9COmSfQPFTaECVcc1PmD+DdHuVBBQM0KEHmYCV1yCgQw4KWsGcNqRWsEYbKoSjEYoq463uKnHT ifww/YhGp6x1EY18oIJQkHavkRQkesoKoyDRU1YYBQnnFF8K0sHNkoL0yWZJQcIgcAoSEo45BenI ZklBaviDpCDt+oOkIF2xBWDx3PtAoyD5FFEhJ6HFImvYP7ZgDS6+SWIcLRAlh7bUIzDCW8UcBdG+ +8BFW/JBcwhN2ACkP5dNuB90QpMPhkZ1OqLCRBP3g5vqVKBwnASlAS15gAOpJKgCOA49isYHLvsU MVR6lA+ASpxSPeHEqbMfADdxqoA/glLlguMUn1cQU6FU+S18TMpRTyGyVTXewY1G62opLYkuZ9AP +geWnvFr0OhWQ2manb9DTM9yTGNnon9g6e3S9MyBm8ZiVTuw8g8sPSBhzxw4LLpc48DKM4Ng6ZkP gsbfKtArdGYX66Yms+s6hFSYXf7rXRfni7VtjfPlj6CzwbbSxnjuTnRCssEY5pxPRCKywZjzdOaa M/whcNhgLGPkVsw4RWZsUzNUNtjFUmSntwi30S3l9gk55/gkJtIrRf6iibDcZ2TuQS30R6XIuX0o ItlgVEawwY77DWhsMJ+YshVyVRxGUwAlHrEfSpR0ABQ8Y0rFoE0u9kuJ0RYAQ0egZzPF3kcEhVzm g1CjDuOiIcQmbxAAKwqOdBIBu7cYvuvjiKAQ0nwAqp3hXzhQv06q/6SgA1xfNR/7L9RXSGx+E6Jk reHcLkNw8sOg09sCQexSY5BCCJX45req4lQ31Yf6Bx2A3oJOCATNhYOIoJHl/BA0yhuPZMUjoNPo /OJgEOw4xJUUQiHY+U3DLuodA5n/PIIo1Dvf6uAsux5wDQQw/6gA4qS8IEAaDsR+8CjodD2/ArmI fKxAy256FFxEPr8FhUrxU5xZthlxNIqfX2d1yH+8jY16DEzyn5++TgvkFbzoMdBpgT4IdK959lyp zUN6h4TYWKgMym5ViUP9TkRQqIR++w5KHnQ5UX/c46CSDAsiuJyILUMEhX7oA8GIiZ6zyL0SZUcA FO9ZZL/E2BUAw2sWOe0J0NiMfh3F4S16FuinEurJAUGRZZQJpj452CFhNwWFpYcimtHicMc/CRo7 MhicR+xbBRDnTQYAatVxlPHqCQRTGJV+K1CHa9mjV2bl/yCKw7X09UiyKj3r8qLfgkbDDApVoC7X S9ixQWH96vKggOPczWBwHnVZ+zvQWJ0BgPLX5QYEU/iefmAB+Yhsr6VMdXSX59iMfS1tjglqs9Vd 9xSQNYDLngKNJRoY0GgBElJtBo9K8NmBwV3tgOIpjeF/BSinlgYE9caE2IVPg0Y6DQLn1SaUStok Ie2hbRg96rqatQ1mcdQzoDFVfSd9wWH1LALEVkisWQGxgjnv8h1ih6WpuUNqCu+TuCLFTM57FjTm q/8iTaG1enUhpR89KHA5KXYAuPmqwtWdip4DjS8bzIZ3hzJ71RKBzZm0gbF9oCH2O4lacJ2vsm/z gSp9rGojaOzbIMiBG4+7umUL4tX9tDSfHHrzrhpzrCs1VvU8aKTdoXbBxwNSscI45/MOqfHWfLaV +p/1AmhU3yF1oK6GPu3ydsK5TRl7STpx9bdSBXjT1acdsKr4wYugEYSHNhL0vzxOKMNqn3Ri1dA7 sbBuRty5ET07nzvObenF014ClVdc6JaqwjjuYc/62KMZ85Zj/b8jrsY39rsDw49ulxQ1tjt1zl5n W/7XEFNlIvve1GEc5aq4LD/GAuqLXwaTpOx744DTl9nXefjtpXMQQ6Mv+3nCn4OpCLFeRFCJzb73 7U3KMz77k1B/RSiV8uznC2fxmpF27jizEXPmK6CToQtisvlZA5WTMtkIS7z9AfHoyO7pIulCAk0w qAuiGVhHHayTXgWdW+3XGLIBitojAAXtujBg4fp4Q3r5WVAv/QI4dhPoVO3CcPkj2I5gKonbtym7 6N0+odwikAW/ewDIhWM65TXQmd8DRM8X3KskbtGAvc4f5T8iqsoW9x2pTR65T5BPfx10Inlw4MIx vl6AC4r5wMDzhXivhB0zUNj8EZ79n6DT0v1AvQnrPmFeI9AFY32A6IVj/d/S/0mDtpAv4Bf9HnSW +wCx80f9MURW+e9+yJ7MeJ+gH/sG6NT4gYEXjnmrMCBI8wM3kC/kr0vfNwwGOm/E68e9CS6ivd99 F4eCv3uNA6gEIYGAKgXfb0mrkPPJ0ozxzp16g9jzAkyw84OAidsOKpx52+GEt0An7g8AWHL6vaC1 9iCNfBTcCO4gVXi2Wdkkob4YiL8mmHGfQX8PIDBkvvI77RVKw0iCK6F/S8P/TLYZZXg58enNxhsC VZtdbwjcgneg1K94erwh8DSj5b5A6XubKP32AbzmbwMo6cdqaegNmiyhf0vDb6Jn7PJj6vDH1OH3 MZkl0Ev50UkPpj5nenvR9AVr3M1Ql7Rxk6Tu8MZ9Xwz4Vo0O5iUB6ZAHS///6dEgfPqWvSkJf7MF 3w5Zgw1kN31tABNK6fWoNX0AzaTlhSOzKzoyHSmI/Cu25K5ahGtLzcC0KKCUZUFFEo+ahMglqkgN TRQyVkVHd3sqm05C5FJVaiZPFnKhimSmDb/oCZHFmhxPFnLhiq50OxG6TPMK04TEiIp24mNXInsV RJaoUrNEupAcXdGeyuUSzakcRJbqkjxdSE6uIPGESL0qVE2SRP73Lj+M/XQGUiHbO4nkrev7+Eky eKehDR8rkQjcoepXTneyooDyVpGF4s1tmYYEwbhLlZ4tM6Tsj1CfHcOTTuXYwQKRtZqJWW4Rzvst sopRP7WCNB83yn0qStWMfIIOVlwzBJENmhvVWm4Ufs0KME4eIhQ5C0feRP/bAE2JZKqLHRGRjDN9 UjuW1sKoDH27QohE4YRrLbBCFoxNN4I15zOCZGE7jsStYc+gOZgzcrtIS/C04hf7kHY2RWY0igz6 ptmcmMxoUjWUt8nmpKVIiyZC/1CR2lUoslIUpZ2LcdZa5XPb+YQR6VTLKL5x+iKVVbwdx0YCOPks fNln+ueo3pHALrGCToROTyWJ0eVA8Ye9SUNQWf4O4oSIsX/ThFNXMmuME/KmY63yMtTYQhp35BpN g3HRPTSm34waog3foJapljdgqjh+q1SpsmQPuVnv+7x3LGdhaNj2jgj2o0UiKNgZIIlnFiin40Se dLU/7UycIqvxQtSmx1/g6EuSnSOtIs9qzb/SUyraCli94uSEFFKLkxkin0sS+89r9iuVPFp6SuIv ytNgoAz/KQkv3AYwGiWwudE3+0pJKsatNPwaSS7DyxJ62fTkLgCUPyvy6iX4ElFkB3uJCIpwTKL9 hfTKnSgWmhJWEnmHf5e9gTSC5mDLIdK7X6LSZXQMSzfG+WC/R+uK8QVkvKNdUUhEYf8uOZaRRDn+ 7/VQrNZkonBEU5VTwr78qnJ+KOpXVdks8Z6H3nRHIApjNSVn4njfQ3GGLhSFKbqynEv+5KMsJ5Zq R5nWhDZ8/tkDYbaHZBQWMpi5I3eQfzdizX/goYuvDCQaG/FdlFQ21ZFkfWAYnUhg7gLUvbiI6B7w tIuvG7Rnlqe81RtaUB3nv8jfRWJxXb9ozQ2rZPYRme0MoA0Py+zPZTY2U7Yqx+EFmjejzErqDkS+ FGJ8BG3YLxG+0uzD3Ak7xdj6tbtg8hgZXakxjUriVYJ4jvSFOBtfv/EIziy3IKfWyfgs2coB+SMQ raJLLDdoVaWnMNlcEW9bHXcvlzFeUvOupwnSkMs8DPAq1UUZ/KLzFp23sC5elW6MGobmYXCW3G0Y YrN15FgvK7WmnDDhbaB/Fxo4yg2kybqcLLCEgTH5DGhyUYm9iPzLlgmKGbRQ/CyaiZ6zi5lppt2J 1CBEJnmZqFJlyJD/436nZlnsW1RvOVR5IW8Z3CKyY50d5ysYlhYnq/1U2jGB9oqxneNIj66XhHvJ 0mb0NnKJX7fh08JoLBr+n8ZNH/m3DJdSZSg1+ojMKjuAv3Gc5L+/wt9jnd8jyOXoKc7vCfi72vlt 429sCPg/mlrQj6bQ3qx+ev4r/t7Wh27i5ViPwuEGpJHknd+0m+C+jTuNa6zW60kxIrdY/K3YInpa Vrq5pYc0zixEbtPiSeqXnYklBOTpUkuH7xYdvtdUUbs7mraK28hfuOJEvCZrxshdlp5zQY3I+YXF M+AcWtkkidOgFfwamiMpwhgUC+NwLQ0M1ol97248EzeTi8fau5raEs05CNszp6EeSWviaXh0GFx7 bRjsd4T4hZ2pjvZMY4qIXyrEMzzNET8qxMn/+AoLke4W0mmW5AifsocL16VSVzSms0S4VwjnWJIU HrX6EED1SIA2e11bliiS3WxHF9FYak2jBJ04S4Bp6faGbvHLmoZPQkmp+O8QTNy3F2D7cNKE7Kut 7+I6g2wqwF5pIT6pdUxq6gD7Gut5mhA+HluFfa2F7Z+sTb4rXqbEszrt6yy2wikLl+1Vbrl0zcIi YEMjU+480teQS0nPnZAN4NVD9JYKWrWK3ziEt19ORojtw830c88R6fZPZQ46R7tkMf6G+bft5TOv fYPl74HnNMxhoY7OwPbPCmHkmY7ZTS0GBRO79wFcQmbEEfZqGunOnky2EexfWOOHyVCnWdoa68Th NNrh8/Z5xrE2vpgI5mT4+lj4dtFgvEfDl0TNS0aY6e00zV4rUgHOrHsfYAFZiYNlv0D3eMIKXZ+D /bZR/BkoTOJmCEZZefnBf1eREDTGe9JdLfFcV2M6A/Z2Lxj6rqpLOMq2MEVWeMF7nuWnurL0B1jp P6Gl/BxLObwB9VihtIwLVsgM+2WRBRfchakrWfIrIpmvZZb1v8d2JWicvSwN9mueManWpKINxCpd LHUIdXEyjf17T/0Zuhi2xIy+iyKNY0t+VUdMvEsA32vIZNoSbZ0tCbDf1RVny6wofEND+L3GVBLs fl2smiRKgab0CvRhjy5SQ5OlUEtqBdj7DBSSKAXw0PBsB9mL2n/WpWaJHCnalmoidbLfKDKmSpFM kkh8aJgjiVIgSyYlInLAcJomS6FcEk+8STeRXZF9yOjv051MR74l00PnTvtvRhlEjibamUnjCPmp UQUyyxDOgf13XXQmz3AEr0h39hC5z42hgaVLsW7SKBq6m8D+0sDjGY5gZ2cqm6Ql+ofhpcySwonG 1u5cV1M61UZaw9dGuCqVXKmBOVz+qNkORZbTzNoyCYH+jVkZTqaQ72xINDZg3x1t9I1alhGF8GEq l8o0UbkxphzLkHJNiXQbFRxvCM7kOVKyOZNhpieYkjxHSiY6O8kcb0hVk9QolHAJHFkqXBK4keYS DekO3Arbla5y0gwplyZTdrUhU5XukPmZbuJxjWmJpEqJrmx3B+kJMw2ZGpru+JNqBjtq4pDUKBzD JJLdWbDnmxIkVUrgksZeYErg2xtcAu+upRLt9KbI+FPxEwRX4vSZTSXTuXSGlDRrjd9Pp9AQZvSk G7tawM7xxDBNZEs7u8vK7qbrFpqYWpFMdXZRiG7rHZpRRjOYQdI54mzVZi/n2aNpdpJP/gTwVr5Q GsdMk0k5/uNUlsx26y1cWYWmTAhlychMV6QsmxbDvt9cUsxyS0XhQZyAQtaIK9mRyzwT7AessYcR fLJjlcE+xNdlP5IZYP/G2kVdbKRpaJDf9rQft/BuVWhKS2gsNuvuLNkIjBNrXrB3YKwm8WUq2KNo DCaJRS7YtoWL50l8aQr2PAuXu5Po0lLGCOwkXToum/Mh4It5zWS9lMoq2WkzEjNdQtFFseW4d6TI 0YvJRBdNk+l5ymFt6QdL7vyQ3yVg2zlZSXe4TLiEog4+hAR07R5E/QtH5R81UYHvMrvYdC85MhcL SIie+hHf5GYzPbSCCMwjpn/VmgApLK7vpFussJd/JDblOPr81hx9eI5qu/52VOGV2883S8ocjhlE HmvdGjaNqfQrKvvNsYBp1OG6R9tBMQTmLF5D/fF/Jde5VBeZho6YyxdMDgTS6oCEQ4FAcHFo4jCw ZY8jWHcHgxtjwNWyDA+vNI9iHyDISWRAsieFjHDOluMTCSmORCKkseMPCKWIYVbRSXMdpcbrF6Ei H91mmPZqaIZhq36VovIvhjWu4WVpG6rhqlxbwF9oAFTWGCJkwUsXnWzRW3/MQdyr4/YT7B+axmk6 rt/Fdp09fOBu0EcQ9fMQoDnVhad82k1miWtZDhZ5q1LklQflXSSq1+mqGZkpnmFw1Yy1gh2ubPeY 7YFliC1d/fu0ZGx4XekqGaaTsM44bIb1O7hY4du+G021Tq52hql2QS2qrRSCYN8pejTfoOTORwG8 GWD/PCR7e65Zpq4NFQnE75O/0EV3VPY6wwXxeOupQ/R+mqIAJWG8xzAFc+ioWPyUHHVLw3jfoiS8 7hBeo1hpeCu5LmOXOAuW0L+l4f2YzC5xM1zyf6SdC3wcVdXA7+xOlqS7aVMasNCWpvJq2iRN2iR9 UkpLoJHSlraUQoFxs7tJluyLfTQJhZaXglgoKCLVqoCKClV5qKCCAn4CfjxE+PRDUeQhD+XZ8igP od85997ZuTM75y7+vvJj7r1nzrnPM+d/Z3ayy49h8wMUYzaCV1UEKRNBskQQJw3YDbThT9X2wzdA eHOzXsE3QHgTeK8cNvEuOszFYXPCfFTBY9jcgIpCgNnGYf6BiFVkzct21ohyPpopoOB3F7+Capeh xfgQY/XPvcbY7yFjzDi8le+B2YwWPmcd7aIWvnL8TA/7PP9BRWa0prLDqNlaqcnPlDUDreK+bEZb paa8LZOaZms8OQBhfsasSk1+pqxZ2zoiVdsrVLtH3LoNrYVcNJZgMzoqa+VnyppNrbk83r7MmF2p yc+UNZe0DuSjuUE2Y06lJj9T1jy/JZYp5lNsRmelJj9jawZacrDlhMa7fBrHM7ai2RJNZUppNqPb bz7hjK1Y22hZxazFPzqbcSR+C0NjOloYYjNmfhHy5i9eU585qNXYVwj6hWHUvIxJ6PXX8HHL45jn vuKSj3PJ0B+3cx/bzv30bRBGMFt/9euMnYTf9DezfXoX5POJQilVZObMOc3ZIcaac9E83tozfLqX z+ZZoDmTjWUzm1iQmanXXf2dHYPdWWxT0dVjrB968TVMQte9jj2+GPMnGV75OJcMe/n+a9hjPIbN G0EYwWz9NXsY+6iWsdUts0r49Y0t82XzlpUAKog3YDzf1ij3s038nQzYJIIia1mINeHmvZNvyaX0 KCFtCghdfCQC0iWL+LOyJVwKtytSvFSIjy1X0ZdNs5YesRdeHrCb49LlQroi0Ghxa+EGLZ1YxeKr 34AO4qhaVhg1N+7BCVh8V1m2TsqcXwUQzxx5HFz8x7KeZevt2oMf19e/Kden5SyfKbJX6A60UO26 O9Bui6rLWkpSRYb+roE3lV1gy1af+pWdoD2k9uulFd6isparCCs8W/5OCmn5rm2ZKNqrkk/miuCR LV/zqYZviCt0odK79yiVnrjbqdReVLvWb/rV2uGr7K32OqVacAr+XEn4wA1+rjrfR7X8EFdW+dZu dfhqlTfqqlRVvVUet8enSn4J3PSJqoRz5Z81EFXOqRg0r+5Hn2jQldWxBkxPtz/Ymgqx4ObXMRbc BuKIyOKxzvwNCvA6mjTwNmPvBcC6tTGQgxAQLWbTBVwu1toSkGHVwjcMxEZytqrSI1rnj5GFMJlh rR0+Zh2KhrQKGOboW+7w7RjYlxr2DgJcGpNQ4W0MhlehEe+xW/4dr5ydWocJfu6Pr58ULf40irUe 7dO/Lo8W3+6Wt1urY7Ek3JzxHZb4VQz+deU8mAwqDSB4W5f5VD/HpVNRecyncv7rLLBeD+7B9cJj 2ByF8UQwO2nKO4zdgR+4tC4xU/eBOA43/rArhd2M2brUBORYosSa4+lRYFE6PgokGk3HWbB5NJ5m JjPfeVud/fn4Rodr7rENmMtDMQk1v4NzXI/5O/bzyse5ZNjTLW9jr/EIGz0QRjA76cN3Gfs5rn3r gzWpYRAjK6HD/13TzF+WZM1im2M0F0bTfdkU9Bi/TwK6vCmagnsTE6oAqzOhCbP1oZrJ4rEj5PZF xNcoP/GO26HwZZNRcZedixb5dWN/EoF9gR4be3EU++3F0b2C1mcaXvk4lww6DYtp/5y6rJW1PlJT 0SR/UORR7GH1e/kGqPgu1VN7+vfnijUTeUcO4R3chkZ8At3yb3nl+Emr8ieaTjcfr+wm/1ynQrUH vXKYL/HpFT6J8jp+DJs4nojIdnJxJ88fhmLMTroRcu/hBLb+JXRILFqMprIDrPUpfvWYW/a6pmGO /YKPayZuFDOxi4/4Nj7iazD/nuGVj3PJsB/Ne7FPeAybd2KfMNvId2ZwH9HGNx6N/JKH4qwpT8HZ MalsZqApni31wa1uxGwUOTw9FU/PODLMWHutEXqPsU3L4IBlsz1gNFu9PT09FtvabK1d33usBe5s bVi1umelBQ5trV61tneDBR5t9a5dtcyC3eCkj8H4QtiPNbVPNibzvU37FPlUkE3mL820H2KIH7Y3 J0fzAx2sfaqBRvhpLpRns/YmWW6YnE8U4SJh7dOkZKL5p/ecuYUA7DxDtee19n0+V2MxCTW+j/P6 OtpcOMYrH+eSwRTJ2ak1wyZOQR0/hs2D4XQEs9NvhpyY1ny2lIlbheIo6JsdO5pFOZmJJ+R3excT MGVCWswOR+3nsqwsszKJKOyy8UNxl1oy04/bJQxsLnkmMeCcC7Lp+8p9iSfwTcRyZ25olgJvb6Q4 2lcQn8zLcg6/ggw/nGf1i/cxthB9rWPXmkkwxx0/5B4M+x37bTwrlUwDt+XH0PhV3LlEzP7Mj6G9 YQw/Davb8WOdaTe/EyzIHbnBhp+DfWvHLTqTecKko71stOYs7OKtOqP52EMItk7n1lwG90Mdt2nH 1Z4s8P3NAN4sS7OdaHa7toNglRiJ4v2gnIfvY/9+orPpykfjyRFnGh5Gi59pOzcb1hPayUGow/te 2zKD/btDv1yqpTKPwyFs9c4qrcJNVGWrq/H+4udVWlUs1dU7D3v8S32rg9FC2enLS9GP7nWX1nAO Gp5dSsLOcmV0pbOI4Nsdd2st56Ilugz4dGbAZf0p2A50/ErvOWgtrqsetkyYddeB2a+1Zl2OmZXK FgrlJoeww/dW8/BkItbVNb9s9C+c2PuqengfRhflwojgtP6mWlvpbLyUypaNwugAv9W6OOz0c86I 9uIk3q+fjWIyM5oBZlp9CdhfJsq2szBIPKC17VACcw9bzu3MA/epPCZMbX6cyG1q1mISOhW/BX1s G+YXGl75OJcMGIF3qhFkRGTq+/xPaN5HiOzjeQt0IpgNvFdjMHf7i/BFiMUQdZ8SUVe8utDR6dbq 7evRR9znKTNPtDVEtP0HpU5F2hcoAyrKvkiOg4ywL5Gd8o+uL1P67sgaEJH1dbJDuqj6Br0c2oj6 pqY1Opru1rSmi6Rv0a3RUfRt0kgXQd8hrapFz3dpj6Ai517ShIqaIzxqBgydu7pD5ggPmUHSwi9e jvB4aWpbcQfLER4s60gLd6Qc4ZFyDN0nKkyO8DAZpg39YmTbAvDYOGTNJaah3rxU2pdvNjGQQfT7 GJOQGYJJH7sBjbEqj3zIK2ezDbh2WMffqVbmpPk3L/OHf6AbHWEdz9K60RFbd9TYh2v5L0p3biJX SKayGUf/UJyuV6vNFr+5coyuwqX8gA5W9tVWNohjr/5NOotzpZUt3kDv/5i+QN2XmTQ7xwij8zON K8srRplfwBMufR0/hs0xsGQRzC78ZaQCVfiHo4iqBmOEs2o80VKMhNVmDquJpJ2HVvtt5rQ6iNSv wFVghOPqYNKiklcjnFeT6LH4AGuEA2sy3S8vsTZzYk0hDTzI2syRdSjdJ39mbebMOkyzLAS0NnNo Ha5rz49amzm1jtC154+tEY6t6Zr2/Lg1wrnVTFv5g2uEg2sGbUaTa4STa6bGNyrRNcLR1ULb6Nk1 V+u6fuyap3ddX3bN17bix66FtO/6sGuRZvhadh1FG5LsGgdBy/z3GC27Yg67MLIBi+7FJPRABBnV GHYYpcqP9MpZVrCrkeymhBc+WTSyAl4HapQ5vbjyOYJeU0llBV/SgONrWtUZs/klrTi/ZmlilwMw acEB1kG7jEowacIJNkdzqXoRJu04wro0Hu1CGDcCbKEH1PFj2HwE1imC2YWfm1CBMBH6m2ySLZUk W0Y0GK1Css+Qdv4kO4HUp0i2grSgSHYiPRaSZCvpfvmTbBVp4Euyk+k+6Ui2XrMsWpKdomuPJtkG XXs6kp2maY8m2UbaSkey02mzaiQ7Q+MbFMnOpG30JEtqXdePZGfpXdeXZEPaVvxIlqZ914dkGc3w tSTL0oYkyR6H2GXeP15LsqhDMgxwQKYvYhK6agIS6+nxDrFU+W6v3CbZcWQ3JcnurXFItlyjzEnG lSXJTiKVFZJJA06ytVVnzCaZtOIki2pil0MyacFJFqNdRiWZNOEkS2guVS/JpB0n2YDGo10k40ZA L/SAOn4Mm1+FdYpgduFJB1eQrJTxsKwoWVYimhyswrJzSTsPy2oFy84j9SmWbSEtKJZtpcdCsux8 ul/+LLuANPBl2SV0n3Qsu1SzLFqWfUHXHs2yy3Tt6Vi2TdMezbLLaSsdy66gzaqxbLvGNyiWXUnb 6Fn2da3r+rFsp951fVn2DW0rfiz7Fu27Piy7TjN8Lcuupw1Jlu2E6GV+aaKWZYMOyzDEAZtOwSR0 xsHIrJsmOsxS5Xd75TbLRshuSpZtVFh2jkaZs2yjwrKLSGWFZRsVln2u6ozZLNuosOzLmtjlsGyj wrKv0C6jsmyjwrKvai5VL8s2KizbofFoF8s2SpahB9TxY9iMwTpFMLvwU9MqWGZ/JR1Q7EZJse8R jQ1XodiPSDsPxaYKiv2Y1K+gWJ2g2C2kBUWxW+mxkBS7je6XP8VuJw18KfZzuk86iv1Csyxaiv1S 1x5Nsbt07eko9itNezTFfk1b6Sh2D21WjWL3anyDoth9tI2eYo9oXdePYo/qXdeXYr/XtuJHsT/Q vutDscc1w9dS7AnakKTYIMQtc8NULcWGHYphcAMqTcEkdOg0pFVuqkMrVX6RV25T7Caym5Ji+I3H NsV2aZQ5xbiypNhPSWWFYtKAU+yOqjNmU0xacYr9VhO7HIpJC06xB2iXUSkmTTjFfqe5VL0Uk3ac Yg9pPNpFMW4E5EIPqOPHsNkM6xTB7MK/H1n5bHEwmy82QTRHjj0pOfZnorlCFY49Q9p5ODZOcOxZ Ur+CY6bg2HOkBcWx5+mxkBz7B90vf469QBr4cuwVuk86jr2qWRYtx17TtUdz7HVdezqOvalpj+bY btpKx7E9tFk1jr2l8Q2KY2/TNnqO7dO6rh/HWEDrur4cM0gbimNB0sKPYybdJz3HamhDkmNtELnM piO0HCs4HMPwBlx6AZPQK0cir+Yd4fBKlZ/gldsc+yu5SpJje5S7sac1ypxje5S7sZdIZYVje5S7 sX/Snubh2B7lbmyvJnY5HNuj3I29TzumyrE9yt3Yh5pL1cuxPcrd2EeaC87FsT3ybgw9oI4fw+Zu WKcIZhfe0kZwrPx8UQJtTEAALUw4X7EK0PYn7TxAaxBAm0DqU0BrJC0ooB1Aj4UE2oF0v/yB9inS wBdoU+g+6YB2iGZZtECbqmuPBlqTrj0d0D6taY8G2qG0lQ5oh9Fm1YB2uMY3KKAdQdvogdahdV0/ oM3Wu64v0OZoW/EDWhftuz5A69YMXwu0ubQhCbR3IYSZu1u0QCs6QMM4B4D6GSahu9oQXHWtDrhU +WSv3AbaWLKbEmj4J/w20Bo0yhxoXFkC7SBSWQGaNOBAm1R1xmygSSsOtGZN7HKAJi040GbSLqMC TZpwoLVqLlUv0KQdB9osjUe7gMaNAGLoAXX8GDbvg3WKYHZhvqsCaJJgiyTBjiIaSlYh2LGknf+j xR5Sn3q0eBxpQRHseHosJMGW0/3yJ1gvaeBLsFV0n3QEW61ZFi3BTtK1RxNsja49HcHWadqjCXYy baUj2HrarBrBTtH4BkWwDbSNnmAxrev6ESyud11fgiW0rfgRbID2XR+CDWqGryVYkjYkCfYAxCzz 9jlagiUdgmFgAyKNYBLa0oWkemiOQypV/rRXbhNsCdlNSbBdCsGWapQ5wXYpBDuBVFYItksh2IlV Z8wm2C6FYBs1scsh2C6FYGfQLqMSbJdCMEtzqXoJtkshWFTj0S6C7ZIEQw+o48eweTGsUwSzC49a RL/sIVGWkSjLEi2eVQVlm0g7D8qaBMqGSX0KZSOkBYWyUXosJMrOofvlj7LNpIEvyi6g+6RD2YWa ZdGi7CJdezTKLta1p0PZ5zXt0Si7hLbSoexS2qwayr6g8Q0KZZfRNnqUfUXrun4ou0bvur4o+6q2 FT+U7aB91wdlX9MMX4uyr9OGJMq+AMHL3LJAi7KzHJRhhAM0LcMk1LsIkXXNAgdZqvwHXrmNsjzZ TYmyLuXpYlGjzFHWpTxdPI9UVlDWpTxd3Fp1xmyUdSlPFy/XxC4HZV3K08XttMuoKOtSni5epblU vSjrUp4uflnj0S6Udcmni+gBdfwYNlfBOkUwu9BcVoEy/l0kEmPXSYxdT7SWqoKx75N2/ndkPyD1 KYzdRFpQGLuZHguJsV10v/wx9kPSwBdjt9N90mHsJ5pl0WLsp7r2aIz9TNeeDmN3atqjMfZz2kqH sV/QZtUw9kuNb1AYu4u20WPsAa3r+mHsQb3r+mLsd9pW/DD2EO27Phh7WDN8LcYeoQ1JjK2DwGX2 HKPFWMrBGEY3wNIYTEINyxBXZxzj4EqV57xyG2PfIbspMYbfMGtj7EaNMscYV5YY+zGprGBMGnCM 3Vp1xmyMSSuOsV9rYpeDMWnBMXYv7TIqxqQJx9hvNJeqF2PSjmPstxqPdmGMGwG60APq+DFsHgjr FMHswv/p9ceY97bsccmzJ4hm01V49hfSzv+27ClSn+LZX0kLimd/o8dC8uxpul/+PPs7aeDLsxfo Pul49qJmWbQ8e0nXHs2zl3Xt6Xj2L017NM9eoa10PHuVNqvGs9c0vkHx7HXaRs+z97Wu68ezD/Su 68uzD7Wt+PHsI9p3fXj2sWb4Wp7tow1Jnk2CCGYesFzLs7TDMwxzwKe/YBJ6phe51brc4ZYqX+KV 2zz7E9lNybOdym3ZkxplzrOdym3Zs6SywrOdym3Z81VnzObZTuW2bLcmdjk826nclr1Fu4zKs53K bdk7mkvVy7Odym3ZXo1Hu3i2U96WoQfU8WPYfBHWKYLZhdet9ueZem9mBgXLaoL+TY5UYVmEtPOw 7GjBsnpSv4Jl+wuWjSUtKJaNo8dCsqyB7pc/y8aTBr4s+xTdJx3LJmqWRcuyg3Tt0Sw7WNeejmWT Ne3RLJtCW+lYdghtVo1lUzW+QbGsibbRs2ym1nX9WNaid11flrVqW/Fj2Szad31Y1q4ZvpZlHbQh ybJXIHqZz67UsmzEYRmGOGDTjZiEdq1GZr2/0mGWKo+s8shtltWS3ZQs6wk5LBujUeYs48qSZRNI ZYVl0oCz7ICqM2azTFpxlh2qiV0Oy6QFZ9nhtMuoLJMmnGVHai5VL8ukHWdZs8ajXSzjRsAv9IA6 fgybt8E6RTC7sHSKhmXeG7RuCbW5RNujVaC2mLTzQG2JgNrRpH4F1CYIqC0hLSioHUOPhYTaUrpf /lBbRhr4Qq2X7pMOap/RLIsWaifo2qOhtkLXng5qKzXt0VBbRVvpoLaaNqsGtZM0vkFBbQ1to4fa GVrX9YPamXrX9YWapW3FD2pR2nd9oNanGb4WajHakITaHRDGzJ+drIXaqAM1jHUAqc2YhC44BeH1 6MkOvFT5s165DbUFZDcl1AYVqC3SKHOoDSpQ6yGVFagNKlA7vuqM2VAbVKB2siZ2OVAbVKB2Cu0y KtQGFaidqrlUvVAbVKC2UePRLqgNSqihB9TxY9i8BNYpgtmFR59ZATX+fe/IsEHJsCTRVH8VhuVI Ow/DJgqGnU3qVzAsJBiWJy0ohhXosZAMK9L98mdYiTTwMOxczrDNdJ98GXbRvn37zuUYO1ezMv4Y ewpsBcnO07XqQ7LzBcm26Jr0JdkRgmQXaNqjSXYRbaUj2cW0WTWSfV7jIRTJLqFt9CT7staB/Uh2 td6BfUn2FW0rfiT7Ku3BPiS7VjN8Lcl20IYkybZB7DLPP11Lsn6HZBjggEw9mIROwJ+jGXvt6Q6x VPnNXrlNshTZTUmy9agtSZbRKHOScWVJsmFSWSGZNOAkG606YzbJpBUn2WWaCOaQTFpwkm2jXUYl mTThJLtCc6l6SSbtOMmu1Hi0i2TcCOiFHlDHj2HzJJBFMDtG/ESVaS48IFGBNPGbK8i0GyTTvk00 Gq/CtJtIOw/TugTTbib1K5g2TjBtF2lBMe2H9FhIpv2I7pc/035MGvgy7ad0n3yZFvy3zbSfaVbG n2mPfLxv33mcaXfoWvW7OzPP41C7U9emL9Q6DUG1X2papKl2N22lo9qvaLNqVLtH4yMU1e6lbap8 +4fWhX2//UPvwv7f/qFtxffbP2gf9vv2D83w9d/+QRuSVLMgjpnrY1qqxR2qYYwDSk3CJDQtgfTK xBx6qfILvHKbajeS3ZRUw1/Dsqn2fY0ypxpXllS7lVRWqCYNONVurzpjNtWkFafaf2limEM1acGp dj/tMirVpAmn2oOaS9VLNWnHqfbfGo92UY0b4W+3nIlUw2PYPBLWKYLZhS8N+T90dIj2V0m0vxEN JqoQ7R+knf+TxhdIferjsxdJC4poL9FjIYn2Mt0vf6L9kzTwJdobdJ/8iXaPTbQ3NSvjT7S7X7WJ tlvXqh/Rlgii7dG16Uu0YycIor2jaZEm2l7aSke092izakT7QOMjFNH+TdvoiVZr6lzYj2h1pAVN tDHaVvyIFiEt/IhWT/dJT7SxtCFJtBaIYeb0s7RESzhEw0AHhHoNk9BbQ/zVj7MccqnytV65TbRn yOWVRMMfobSJ9pxGmRONK0uivUIqK0STBpxor9Ge5iGatOJE26eJYQ7RpAUnmkG7jEo0acKJFqQX s4Jo0o4TrUbj0S6icSOgGHpAHT+GzfdhnSKYjQbSBuuLFsA+WyjmE9E0/7WXlkIxvmCB+HZG/qPN 4jdgmoBwW96Ea6N29pAxpQa6MTtt4M/J4O984q+jF9jsjIFVBg41zS+kFG/LduMPTuZH7Z9cq09z B5uASeigNDrS9aiPtbvli39hy+e02Cf2wxMn/hlPbBH1stmX2Gbyd8rXGoNwlc0W315pNx/b1Gf/ Ao5QhnWOYG1h8+MhPLancJbwGDangjyC2ehwxjtL8qsrKyfK/k7LTzZXWDHO1V/Sritzjqux3mEQ dSiN9A739Ljmc47FLszwCb0Uk9AVGZzQPWlnQhX54nBGmVBx4lw8ceKMjHdC+Vm/Cf1P+qhOOq8Q Jx1bDJuH8ak/PY2TfjrPXw3yCGajP87ak578D1zT6FwaOAunuzMdkNMdnHEjnOjsCTzcydiMx2Aw nccFsPYZZ42B/PGBHdDmjMtQZ3lgVg7yD8KV2dkb4L/suzqrLE3S48ZH5cRfNOX4Xy7lcNYHs86s K/LFn7flXa32iXVwDGEn5dx2nhVQG1HnjRuAYhT7J2ZFTEpfqb/avJTGg+Fi+QtuXR7j3ph34WI9 Pfx3vnN90dgQMP8cIMlNOxj+0LnBJsTw933tn4QKmw9lcOke4ou5CroWEVmc0eivz/Yu4Ce/anTL +NoiZxmxDXsZT8s5y9iTd5Zxvwgs46Kz/a6w5H9wha3P87U+HZNQXx7Xet3Zzlor8sX5s5W1FifS ed+1/k96ovoDrxT9AQfq9YdPNM16r/DrRlWvcL7PN2x+KYeOgcewOQh9jIgsrlHgg4LBCsVokW3o PjxYwF8z3sS6j/hOSCyzZeWi8Q7WfSR+4Ufg0FrUSGayrLv5D1wjggLYfiVYd+tuLmmYth1Uu9uM /bDUiOdLyTjrnnU7Pz0RBQMoaL+PCyajIM9b7RCtNolWZ7Pu2aLV6aiCo2TdnfvzalumPQEL2j3v J7VYap92PpYWPsBLnagdLSbTrPu48FSUzOOd5JLjhWQJSmJcslxIlkOjpUypkIh3su6T8dXNwKGr y7Iu1r1eyNaZjxUc5+3EmbPjD84k+B4roouF4Mj2+yeK+Oy6T9S6hfirb4U8rhEew2YEhBHM1l9Y MtheGNxnu88sL47lXZzPdtWIxbEse3n6KpYn5lqeuHd5Et7l6a9YngHv8gyKdpXlSbaqy3OWWJ5O sTypP9eWF0MsT1FZDLE8JXsxysuzSUhWlx1v6zO8FxvM00rOOnTjdHZ32iuBs4bALHHOljA65DG/ V/LXkY9zyXAdxhdxHfAI/ANhBLOBkzYZ+GvfsSHWMPeyYMriP6w+94t7+ASwadthaHO3iVIATkN3 8kU29wrhrSZIUokMm7tdlGuhnIM5nnv1Yl6OmIdvcsbSxduxh4IN41esYxI6YxM61dGYF51xn6n1 SHE4O0o4HDyGzRgII5itnzxssNtg4BPn7igP5muuwXy9YjA7W92D+YYoR+zBfFMMptF8WxnMXN4j Z2WwYejepzEJTR/mr/5h/jaxCop8nEuGQxncxL8EdhP/Ir1h/BJYyNY/A7njgC2186YEhwtWPjvM 5h0i4gZDQSybYvOmCkEABSO55EgCZE1CZqJsVMqmCVnIvHNYGcNwMoPubY/hGTGGF3lfX+VjeAzz 2Au3fJxLhmOYM4xjwGPY3INjwGz9vSMG+zTM3v7zjggCffpT0QE270h7ELCvE5Lp9ihiVkxImu0x wC2HkMyQI0BJMpNg82ZulMEBjGJsXgu2FTgUXGJEuXz4z9Rn7QH+YYQP8H8xCf1tBAd4K+axi275 OJeMsQY0xQbHJ6Ab+8Eg9/IB7+UDfh5ORjBb/9GowYKwvNPnfyMYzScyUTb/m7vkcLP5eF9qqMDm f2uXHFwhLQTX7ZIQGhTl60U5wsuDcTb/BiFoCJZsk28LSWOw35Z8R0gmBkvlhr4rRJOD/WXRjULU FBxKJHIx2Fez+d8TosPMP446MzcvHU3BPPeX5w5HBvMRPAfnqO4cnLvXUBQUzqzIx7lk6Bwvj+Bc 4TFsjgNhBLP1F282mBVmbN6ChuBQAa6mRJEtmIBSnC2gU96KA4TYggOFzAxmc6DxKTlZU++BmswF BzUV4S5nwcG4OE3FYootmITZrVth/RZMRt2J14IiDuuyzXwIV2ISugaO7KBb4FSb1dXhkR/skjEW 3BSFiqesOwf7EZnG6z7EXpNCtpSPJaxoPJ5nC6Zez/vaGIwnEAdc1iRkhwULuSwEnAXyYuwMxkX5 06LcbZ6+2VkA2AfxKRATY9nLcKsYwx28r3djX8cWMY8T6ZaPc8nwV1jx7xDDJg6ijh/D5s7N+FeI kG3AevEH77h/j4NTjVytkav9BtUw26h0iS04DEXnG/XnQf3paDLDjEacE/w3H99AOvkCI5ofiElx 4KpaXt4E5bEHYzlyoREbjaUSzDhAKBQvNAp50D/wzt9jccOFBs5iubz8QqM/zoypqBy86jtbwTyb ySSAp9lMwcrkmXE4DjF41XVwKg89NI4QqjuhDPvNtYhyo1XIrgVZrgg2beuDWL4aysVEOseMrgNr UHAlCAA53UJ9G5QGB5kxVxQv3XqR8ea5BhsPtitAcqGRZMYCce7irexi40wcUA2eKHBynYizxM/B rD4I8/k5YytIcGMDewaIjZlkkT+rj+JorGgmbuHY8yU+OqsdaocpHZHTajn6CSvHDv9zeYJhC5NP ZvPJ4mhZGmGfN77C2yrG+rGmQAhHyC4xbgcp9gKrvZJXfamxHcpQE/uCYR2/YtXSY1ZYVq+1Vqz4 whNR6yau2fA8KOJAuMfAxWVIJWP8E+gQNUGUfhE6FC9krUEYECz0gfwJntEo7+fZoi/iA5GjY9kS VL7EOm1tsZPnx21BL78Qx5nFkULLpb8yVhOcB3VuM55sw2q2GeNn4a3BNuMoTM1tRhrT2m3GDkwb thmPYdq0zfgY0yXbjBntkJ5/uXEapsy43LiGZwKXG4/yjHm5UduBmdrLjcU803C5cTbPNF1ufI9n oJpnMXPLNuOQ2ZB+5nLjFExN6M+XZ4t+/Xa26Nfe2aJfLXOEfMMcIb94jpDfMkf09y9zRH9Dndjf K4xTBxnbbpybgtJ24xGRNKV5khXJPSI5PAPJlcbnzsN69sE/nPPtxhHn8LMrRHLHeVzpf653K723 k5+d9w1R/Q2QbDOOfVj0dPBh0dMrHxY9vfNh2dOHRU/NR7Cn242BR7jZfZiEthmBRzHdbsx8nFfa J5JviORJkdQ/wZPPiOQSTBotC6iejUXBRY5a+IKJ3fvWo8L2SZ6sfZon54vkepHcL5KXRLL/33nS JZL1ItkskptF8ieRBJ/hSYtI1orkXJH8QCRPiaT2WTFHIvmsSC4VyW3P8qH/8Xmcme3GReCfxlXG 81mDCde/ynj/bDu/zbjjdTFh9W9x4w/f4cnuUw1MjjyNJztE8sBnefKRSLJRcW6AJ78XyTGDGNLf wMubreEf5Xw4dgxeWXi3bswqFfKzkplYqgT3R7yQSvbNGojFWjFNzpnX3ZpPxAejRShnSiOz5rTB f24DWZjVB3flbkls5kzboKIinXblucIopcxm5bPZ4qzhbH5o1vpkAQJg16wTEvlMIjVLBI5EnrF0 KVVc5sT/tlguh1Mt3KhtEJE3ohYy4n6gIEqFYjye6Id8gLEkYGSTENsaQa6RzAopf+QgstbxsPHO 9CcHRHHAMQV9oJuoEebZtoWbPdmBQmwwEZd1JwcKiWI5n4mmhEquOAjDiyu9kBJxupRJQiuyZTjR CkOIwjSABJwApo83ilnnmQoIIOj257IyFy1m08kY8EFoDqMOIKjkjBo6756MUHkUqJBIwYwLaSYx DHthrudqrVBMWUnYekNbeasvWkiUZ16eFINSBLDZzMbsYj6ZGegfjoti+ZkRCH0kRdj719irbsVS 0ULBbiiZLfDGRWmYPz0SA+NZ+xxOVzaeiG0qCkVZcD49jwr/4pqynf5oLGEPNpHPZ+Rap6PFQeFV QVEQYvGhCc6UzT0naw8g6ZxJus/g6oga+2OZYkpkk9lYMdWq+EnankF0E2eTBoJaPhNO7dkCzC3m wF/K14fJ5108lsNzwNoAHoMTjNoF+dr7E28GZowPfN9ogP/H1y6PQ3H/fO0VCZ5+zIu1LfF8vra1 dmqgrSHQNr52PfwXr00EmhvibwYLgRlGcPzXa6fW7ryi9opAV0PtepAOzwzWgwyKQuucwJFGMPz1 wNkN5uHBd9jl5sLg21tigXnjYrVTYoFGCHClQnQg0YSXvhhfoWkR7BibcJ+dKBQWNy3CTRMvLh7D ZsUTmzDu9MHmg2VzicwCMW9NvauWrbCWLl1n9a7sXcc28alrUk6uE2eXrVq5smfZOnD5TBx8ralJ tNnE+qPJVCLehHJ2bLJg70JRZa1UYayiumN718oam0QFbN8+o/n4mpfC7JtGzasG+5FRc6fB7g/U XB1kfwrUPBNgTwR/vh+c3hXB/Zoh/8c9WAOkiHLAwLm1EdO8FE6sYM4/3H8fM7b2c4Gl9TXHXxTc AEsSb4tsaJu4GnLn27ng/xpttae3Nazhx+ASo61xDZxP84RNlHXhxnMxc+o7TTmHO8eJyrkTlHPY z4OVcycq54xzVq/ArodEkY8AX2JoUvrPt5X/z0FMhiqKyhhcdZ4mzl+tjMN1/gRx/ifKWFznYUDP MUQw/lt/gcGegu0wvxHCvbHcDrduxcfQ8QULrLXD0RzucoYssa9f1L4YpVbBlrOXz5e6vp+9NFEf vvBanEfm7G2qGvuRfWVNzjN7b2X4b3J5lGbZw24KOd6WRDzkMWAy/goCc1cBO/pcqegQoRgdYLiz L1j4aKcAETedi+YTzOpdZR3Xu6KHud9W4fDBG3C5Q7R68V2gPAjg3kIAUPDDwvu3VLSYYPYn5yyT BdRkh60ighsh2N0JeQlVJHkcihhhBaKgRk50nBa4peSPH3jVWCkMCuovjlr5RA4mNZuHUAQGuQJM HVzM+HHrEHM+FYdT/YUkrx/v0nj1dsN90Xw+CUEaumW5P1rnVCoziBdy0SLMHNS3JpFj5VdPYIwV kwoxEOcb55E3g/e3Fa/UMEAklPkJYOgmYJwlRGmYbgviJK+Q9SUGYBB5mMg49CeDT8sTm2CVE+U2 WRpiLkyC7LRtedRR0NXosNU3WoRTfPpcjdn3tVCBZSl7B5dSLJsbtXizUjXb3y+XaC3E02ipmBXX TCxXsmAvBVNZ7pakAa4ITFcqER2C5bGnPj/Mn0IXi3z2T8RHNDCw/kQ+kYklUBBPFsBPEiyay2F8 L08mHyOcLysXxOKJE/bjMlZ+awe9E/0ncTa+vCb77u4F9EBcd/wcNFSIbkpYvFVsJ52FktM31ztV 6hYPHNjqw/qwR2JvU65xOA/TIroolMUp+fRaqCTjCdFVLKWj+SHYXvMqh7g7iVf85NBxXZj88F58 NsHgUoln06KGfKIP/EV+cmtZfMtrwcUNew95HWXLwy2/1MdUtf5sfjiaj3uiBayk8EfI4WrLRbUv 10IRLg1UysQTI9j3DCzGEEpiKYgiLJXIwH7Z6ZD9iCQNJ0flysLY5WXHn8rImCk6W3ZEVxBgeG1Y /ck8NJjtd0Utlsvi4PLM/RombBZdV4rnPU/mOApsMVMFex35zPP5Lb88WfbndKmYGJHuzK9VHPRg Aq6MsrP1R2GLjdcKf8eRbVE30LC6/dLBRGPq24nQH9hKFuVTqgTG0KQIj+7m8UrCq1IUeFP2yvBr Ykt57TGIgQ+VYJxLcSb6kvFkXtzBRVPuNRcxp3xRO57vfn+SqS8oMudNUZYXDmO/CAqR2YnksNa4 tnzhlUUEWuBCOrcHtrthiI/2AXuc1/jwFIwXq5Ovg4lqgXqlnDB2Xi9k4nMIHl5gGXOpEmekCHJQ d4E5l3muVBjk1bCKeGv7TVNfNptisWguijdyDKvkH11BTHQ86EQRaLN8UlavOrYshuiWxAnnXHWc n8ceUVoGM8XxnYJ7EVx9frsKq7zFOoaDdhBCRp553h+UF395djGOYRN8X6C8AMeU1wflZZcdSsIw s1Z/KSOf5kKzp2Tz8UJ5zBvPYBU7KKZ+BQMrX74pa3hQRHMlPNjxCTYIIs7jpSTJbcGNrASV3dw0 gJiV7pNbA2a/5gz9hS0GcitfKm8ZoC07EnNngptQ7kewZ7GVcuDk/EEGX3a4coqqe/C3T5n8NA4q lHeZcpBudor9jkpGdTcjA4HNa9unMDSJWI7BunOeDPflCMHNkB6O+5TZkSjz345p7u0EOJ0DMWf8 8lpy6sHNCEy7DMX2zbl3SyQHYC/DzKPEdVIOv/YrLHJas4XyIozEErminOHyeMsjjAExMnhhljDc iY5EhyzouIiY9rXkcnBJtmgshl7uJRKfw4GE3HyK6CY2mTAARcZ/8gzvq60VvUut9T1r1vauWmmt O3V1j+tRhrPT4BuAtRaPGRnc5qofBDF2/LJlC5qmH7/y5OYm/rSsaXZ7e2d7Z8fspulr4FJYHi02 rcDHceJs69xmxtoKo+litA/SYl6kg3Yun0i1QdQusjY+nrY+8MS2eKKvNGBF+/ogBAkVIeHRXCnz T2Lb8llhOhCLyWWAKcJo2TaQKbUhibPghG35tv/Py2GfsK5P9EoRHwFeOwV1MP2w/UgIQWJQLYnT uVJfBkQuE6BCZiBRnjDoBmsDx0+0weq0QuyAIN4Gdze4sWaf+N9UJu7z7RusTs/dln0PNgn+r1Ps zr/VYPcExN2aIfVq4f/DZTko9Z5R6lLrmyn1Vb35il6TTNtlfUzRCyodsc8t9eg9P07cJXv1FnvG seQnBruyXYwjpIxjjae++VcZ7C3nhrR8bqWnvsf+YXD7ybIeu74zpU1A6rVcY7BHFTu76n6P3geg 16ro2e2OePSmf9VQ7ped+v7L2y6h12i4162d0Gsw3ON9UhnvWGW8Uw33/HVCfXf61DfJU98zUN8S WV+DUl+74R7Hq1DfYz71tXjqa3rB4D6E9e2v1LfY07+7rjXYi0rZPrfAU9/qF5zxNir1rfHUd8MO o+zDan0rPfVtgPoaZH0HKvVFPfXdB/Wlw5X1pTx6s76rlpxz5/rozfHRw1cog4q877v46XGlnroW +O/amw32WTCcwpxnWziuOk997/3IYJcqhu7e+stNtnufei7osQq6WsCy6SnXeMohT7mWHQDpPGY/ 9/Taj/GUw+xQ5jznC+Cr5Mx5rheo6F/EU65nG5nznK9Sf6yn3OAp7+8pN3rKB3rKEz3lgzzlg1la 5nEOxsP4VYRg6xfJPD4r3R/6e6nn/Jc85R2e8rc95Vs85d94yo95yn/zlJ/zlP/pKb/hKb/rKX/k KUcMd3mCp7zSU97gKV/pKX/NU77ZU77VU/6dp/wnT/l5T/lDWUZPnQb+NTeglutZIeDW9/0EE9+B mFd+7cE6rbPjE78ikkyWX/GofHVDJtbJmWHcoq9JFErphHhYjTupwrKOnk1wlwIb/H4hOBYFmIvC dmyZXUC91SfE1pzAxUIkXk0qlJW5JX7cwnLifo9/ECI/ZmHpRLqAHTltJdh08a0bqMMxlhvlo++E 7W/Kd0+4pvIPQtZZ69qtnrXdFnNeHsFcqtD7ySqIrQPzLgvGJP6CKFXo+T/q7gOqimtd4PgcBOyF ICgiiGJBRUAEEeyiIPbeFQuIRooKKlaKGHuIGmuMJSr2FixYkliwRRSIKEYs+JRYgrEm5orlzub7 n0S93nvXu3lvrffOWrN+7rP3zOzZ5Zw5rvk2I//4Vxe/bt0juge20Qp/wchD/Y2Mv1w8AvT+kIZ5 +xGXwMBh0UP0H1TB0YX99w97/NGu/+mN8F+58dV/EEdHB+rdEqn+v0X/vRM43q3wc9NEv5l0R19d g/4l0Val9S/B3ko7uQ9SzlTaa9pqpX6zulPpoGlp5N9C9RFqUlX/PEVXg+znb5D91FJiaj/13Lgq Pxc3Uf4YphukPlkqXU3T7pJ+YCh8rlJ7yX4lTURPZXVNCzCRcp1MpNxA8kNxvlK/OV5LuSTK7SU/ FW8pa+o/ovSvNJNamtZaPd2of3y3U2knrfCxOfX+WN6P5v1E0hvwIGbiffy9iNS3lKnUw0KeF9Uc TOX8rjjaVMovNpX6rFFp/cfdDvZLVtbRtBSVr9/MH1U6a9r3Sv2G9ZrSRdMeU/43zlPFTI5Tz0ze dzeT43iZyXFamMlxAszkOEPMpB4RZlLv6ew3Sx6z1paaSX2T8DRmYwFam4v1lPrXX3f1XJlepz4q 7appw1Rav1H8WKn3QYR6v76mxVNupkq7y28Eg35M9Y2unv5Xn62qfHksfBpVv5mIxQJsYCr643Bs aCZ2KioOxHjMLC7mYwGWKCHaoBN6oR/2xCCMxHisUVLsgxsxG3/GCqXEmhiCx7FZabEjBmMsZuEt LEDrMuJ3aFJOtMJ2OAgnoJmFWAeDMBpnWorX0FBebIJd8CDewRfoaiX64mxchsfxInpY0x8VaHec hSvRpaLY3YZ64heYU4l2wsf4BkvbirZYG72wDXbHIRiBW/AA3kG7ymJ9vG9He2B3e7FcFbEFjsYE 3IH78Ay+QgsHsTH6Yi+ch2vwMt7BMlVpt2riA3R05Dj4MSbjMbyLQ6uLSzET89C3hmhfU+yNo/AE ZqF3LXE17sBL2NKJcYdnsWpt0Q0HYBpOqyOmYBqWqMt4w4bYDU/hJfRzZhziVkzGdPSpJy7CC3gH M10Ybx6iP07FBXgHH2EBmnuK1bAZdsJZuAaTMagh9cZbuMtLfIrujRiXGOVN//uIRxuLhib0C8Zg yaZieayCddATu+FQXIl78BRGNxO/w+eY2lws2oL+wQS80VIc14r+wa2+YkBr8R6+9BOd/cX+GIG3 8UZbMTxA/Ar34U/o106cjIlYsb1YA/tgKC7BdZiNP6NVB/ofe+Mo3I778CimYTb+Fz5B545iC4zH ubgE1+I23I+n0NCJeuIgDMGxOBVn4SJch9fwMTbpLLbBLtgfh+MYjMNDmI7lu4h26IQNsBkGYF9c hBvxF3yOJl3F0lgRHbEBhmEcZuIVzMNHWIDm3URr7IJBuAF34AFMxXS8gvexenexEcbjXFyCa3Eb 7sdTaOhBv2N/DMIInIQz8DNcg1fwF2zak/mEXXEAhuBYjMfDmIG2vbhedEUfbINdcDCuwB1o0lss idZYFZ3RC/0xDhfjZbyJ+fgcTfowntAOe+Mo3IkpeBzP4494G5+hS1+xFc7Fz3E1bsG9eAQzsEQ/ 0R4DcQROxN14As37i2XRAftgKO7Bb/A8mg8QK2EQhuE03IffY5mBYgV0wsEYhQfxOGZhqUHUFyMw GmfjUbyIVoG0E7piCE7GVDyH19F6sFgHIzAaZ+NRvIiOQxiX2BTH4Wy8gFfxAdYYKnrjPFyMSXgd n2DlYWJtHI6TcD3uxodYJEish74Yj0vwCF5C22DaFftiBO7B01hvuNgZe+FADMLReASz8DW2DxET cCWuGiFuw4dYZCTnxw74Ca4y+jHjHl+i6yjmGYbiV3gQz+FrnBAuzsccfIrxo8V0o2PEy3gbH+FL LDaW8Y0tsScuwq24H49jOubgHXyKppGiG7bBQJyE2/Em2kaJ3TEOa4xjHmAA9sQhGIYTcQYuwWOY jY+x1HixOUbidsxDywniDlwXzXyeKH6JWZiPhkliFayFHTES4zARv8TtmINP0Xyy6IPhuAoz0DBF HIPb8DbaTRXb4WZMwVuYj8/RZJpYGiuiI7qgN7bGztgPg3E0xuIWNI8R5+Fz7BUr7sPH6BInhmAi puA5/AnfYLV42gHDcC7uwDP4DO2ni34YhrlYLEHchJn4EuvOEHvgS6zxCf2JZ/Ap2s4U2+NMPIw/ o/0srgsn4l68jzazxQ64AXPQbo7YB+fjSbSbS//ianyOHvPEqfgdFmDj+Vwvmn8qjsDz2ChR/ApL fSbG4LgFYhLmotVCMQAn427Mx6qL6A9chNlo9bnYFRPxByy7mPbG+XgRKywRe+NyzMWqS8WleAaL LuO8GI+H0Go5/Y0+OAZnoOtKrg+T8Fu8gI/xb+j9JeMHZ+JiXIfJ+BLLrxJr4Tg8jqVXi31xPfqt oX3wHvqsFePwo69oNxyOETgJZ+Bn+AUm4W48jKfwB7yGd/EpFlkn+mM2bl3PONggnsAWSfQv/oIt N4rT8STm4DMsvUl0wz44GZfjYcxGu83iEFyHt3HDFvEOPtwqum8TJ+ARLLJdtNwh9kK7neIw3Ij3 0GOXOBevoONucTTuQ+1r5gsm4UNskizuQsMecRAmo8lesSeeQst94jR8jAH7xe1YPEUMxAPY6ADz EBsdJB+bHWK8Y9vD9At2+pZ+wwfY9DvaCbPR6Yg4FdPQ5qgYiZlY+5gYg5fR87g4D29i81RxLb7C 3ifEPWh1kv7CSqfEEDyCNU5TDo+j1xnmAw7ARbgRbdPEzufEW+fF51gunevEDjgfX6BzBv2CVzLF rAscJ4vzYDjOx3S8h59e5jjoeoV5gusxHT/KEetgJ1yIN7HCVbErBmOFa+LeO+J9bHJf7IYj8fOf GT8P6A/MwtfY+BdxLH6CuzDF+P5DcQUewxw890Rs95Txhktx+jPxNBZg2V9Fb5yCX+CP+ADb/CZO woXo8pz+xwRchgVY8nfmIW7Cq/gITV+IpdAfJ+FOvI22BYwfjMND+BzrvxTDMAlz0f6V2BMX4El8 he6vxWG4Gq9i5TeiG8bjAbyLNmqtDtVvOBW3Yw5aGMQAjMH9mI/VTMQBmIin8G9Yr4gYiPPxJBZg cVPRDwfhCfwV65iJ/XE+pqKLuTgcl+BpfIEuRakXfoon8DV6FhPDcT3moHVx2hWn4168h7YlaFeM x/14Ak1KipVwOu7B+1i5lNgZZ+Lv6FZaHIwLMRV/x9plxD6YiKfxDTYqSzvgBszF8uXEjhiDyZiH lhZiB4zDREzD29jxI3Ea7sGf0MZS7Iqp+BKdyzOe8DNMxV+xuhXjCj/Hs2hqLfrgGNyGuWhTQWyP Mbgbb2DFilwf9sdluAttbBhfGItfYx7aVRLn4DF8gtVtxV44Bw/hfaxaWeyHC/B71OxELxyLSXgD LezFNjgBN+B1tKzCeXEQjscbWM5B9MNo3Iq3sFtVrg8PYj7aV6McTsev8R5WcxT74kI8jW/Qpzrz Ajfij1i6htgcwzAJc/Ae1qwpNsONeBnL1BJbYCRuRUcnxhPOxW/wITrWFnvgdDyIT7FOHXEYLscM LFmX68No3ILXsZwz14UTcBsexOdYth7Hw814Ay1cxNY4BfPQzpX5hTG4G/PQ2o1xilNwL+Zjjfq0 Ky7Ec2hwZzxgKK7BH1BrIHpjOE7BA5iJPh7iKFyLF9Dck3bFXXgXKzYU2+EU3IU3sZyX6I+xuB8f Yc1G4kBchmlo5i164Sj8Es+iqQ/tgP6YgCvRrLHYEENxFWZi8SaMK9yJN9CiqeiLE3ATZmOZZtQH p+F+fIDVm4uBuAjT8DW6txCDcCGeRa0l58X2OAzT8BU2aCUG4zLMQH9fxjvuxJto2ZpyGI0b8TpW aCN2wpn4DT5DVz/qiyvxPJr4ix44FL/ADLyOtm25TlyJ57BIgOiJI3ANWrajHXEybscbaNlebI2R uAVvYaUOYnecjUewAF07Uh9cgedRPWivdMEQXIlb8A6+wRGdxeWYjoYutCuG4l106Cp2wXjcg3fR ppvYFmMwBR+iU3dxEC7GDDTtITbFCFyHF7FIT7EJjsEYPIxZ2LSXGI7r8RIW7y22xG14G8v3Ef0w GrfhNSzVl3IYjwfwCTr1Y97jCjyPRfuL3hiGq/Ecmg8QG2MAfoKrsOhAsRGG4xq8gCUHibGYgnex UqDYAWNxN+ZipcFiL/wUT+Nr9Bwijsb1eA3LDhV9cRyuw6toMUysggMwCq9hmSDmK47HzXgTuwWL c/Ag5qP9cMrhdPwa89EpRByMKzADi44QW+F43Ik30Wqk6I/jcAfewsfo8jHjEHdiLlqPYr7iZEzG +qGiDwZiIm7EHBwYJg7HuZiLv6NzuJiGFzEPH+MrLB7B9WNN7IXhOAtv46LR4krchimYihl4FR9g qzFiP4zCF3hyrFg3knmKW9A6SgzG7/Eyuo9jXGAUHsDXGDae+Yxn8QWWmcC8xkT8Fn/AlzgmWlyN yfgAt06kX/Eh2kwSIzEe09F5sjgUx+MDpYner/jjFPEaPsHfsPVUsS2uxnV4Bs/hr8qK+ueeWqTW VL+/jNVtoF+v0kMftyqOgFgvpYr0M1gQl62nR5AOJZ1AehbpNaTXk1aRhQZP/b6NtIo9NpQg3lhP L8MULIyHMP9TYzzE/9WXcUnPwMgQ16jgyKhI1/cC41xbq+j699/9b53Drb6bm5enp+Ymr3dt4NHA 09Ndq+/m7uHu5tnQ3bOh5ubu7unloTm4/S9d8zuvceoPETg4aGrR039V7t/l/z99xbTp4Ccr18rL hGhijzmmxdTaB9peydO7QyumOWk1tGqFY1vlecTqZfTNuDiiiipW8ZYq+lj/mal5xOn5+mappy3J M66jWPhS++rbyPKaprbCqORykh+qp0PXmxZTm/qbAKOZWypfTacEPT9Bz1Nbrp5Wm3G9ArXpt/1a W/3canPQZP0EY16XvKigJnqFmiwyLaY2Z/0957fyu+r5H2or4/ELV/QNDZJ1d10iI1zc/4zvVnX3 79STtpRNXZcFdVCRyCo8r4Ima0gYI5ltKGM8jzGCWa1HYVw7wV7frD5Qr3/28aLOW/SttIraViHz xmhqY199RL1VH5Umr6wmn50qrqvSW8d4O1bf+Frw1vnUsVTsooferhJ7W0ZbrQ6eZFpsXuE12mj1 qfAUym9if0vSdcivyeevNwNmJPnG2N4mpKuSH0B6M+napBM4fj3Sq0h3Im3sg6UGSaexvy/5efrW 6K3rOaAbNNu0WKap5A+hPg8p70jam7RxXQtj+0S+d/36Lai2Rz9eD9J2711fDvt3Jt3a5N36vaK+ p0l30/MHL5T6Wuj1TXkrVtpB3zqQ9qJ8e453hfSl98pbk+9GvlphOTIqaFjdumrwe/6lmN+/Eoj7 D8HPf0ZK/xHo+04k8QcjcN+JnH43DPk/jvT9Z7HKHw7i/nCQ8v9IMPY7cd6B7cYHdgsOGRkZFTzW VxZrfiv+XG+csIhw+bs8gYGqj8NU9zZU/1KLC0WqVP33g9j1zGFSjChyiTcnmJ0YdCK4/07etUZH VWXpe6tu6pGqm4QQQggVkvAOLwkvI9IjShcorRgRbFaLlHlhJVRSMZUCImIHAkgMUYQo2A02DoyC ojBL6MUgawShh8e4XGg7jm07DuOjuwLO0mYAAdGa/e1zbtW9Fbp7etb8mtZ1zzn72/vss8/73FPh bvM/zpb/El3+u3T+BFpzdW0DvraEb4JBrTSF/5k8/4v2GdOmBcaPGavMuPOO26YFxo0pHTM+kR6r TJs379bb7giU0mrMYHk5CeOfVfP3JLCviUejJ/m/SrPSnuCJxyG/5oG1EY+Kz72rYp3AfCgf2uLB Kr3UOGeSrNcm+JgjkcJaN1bXVoll1dbq0LTOJK+a1p339ixKw+rwrJRvKsmHUyv+t9H4r/rvNJcD iz+tofikfTPRTlKwFDFN8kcRk4ZWxLR5rEJMC/9axKRpHWKyaD1i2gS6EFMNNiOmBX4LYrJwG2La HHYgJkN2IqZNaTdimvh7EdMivQ8xbVAHENOGdAgxbWyHEdPGdgwxbR4nENPG9jZi2sROI6bN733E tLHNbf+i7UtX7F2qSmwU1TXWQUaePKrEJ4ZIIj6kkULUPz4ENcbJXek+gw8vD0HNg+B1n2YaLRDk z14cZhotEcT21b2XabRIEF3XvY1ptExwOOj1TKOFgui67lam0VJBfPqju5FptFhwKugHmUbLBbHN dZczjRYM4hPK3VOZRksG54EeyzRaNPgg6CKm0bJBVKg7i2m0cBBf0O/mD0sPQUsH8YrR/fX3oNHi wVauP9No+eBarj/T6IHgeq4/0+iJ4GauP9PokeA2rj/T6JngTq4/0+ih4F6uP9PoqeABrj/T6LHg Ya4/0aX/uaD9P9o+/7p8zuzgh0+jZAruuS/4OZ0ZY4Ukf2H9eurbe2PosftXHHXSQae8o+0acVYf brbFT3c8cO3kUZah/m/9wToa10q05IUzVEpH1ur3mvu2X2o7rG0HHX8vAUfP/VMaRNWTR9svibwv tNLxj3T2408pUSKr7UtvEGD8dNuxrM7Fiizn3hVf4hRARrNkybHj/gtIkHin/8Py2B1ULcrA5Iny 2GRJLnfZfjoZKqtpO43NsQpd/C5JkorfCfK4v5UH6oE0aHcRl8JO/87y2EQW8CLd4fdSBeNjO/0H ymMPMJ6HNCvqFIrODWpf/Sg1WcdWhFwKCbcKZjuD5/oacK3MM7RHHip4tzlP9281WW3ibDCqkLCT dHVek3YeEHa6YCcJ778m7dxZzvX/4tofs5OEP7zW006Cj1z7Y3ZSwZrFzvGGncQ5e82ws84WfBp9 EZP6/Tvalu9QWriTngcj/q2lk8qvWTrp1mtGJ2GedfemMo77t6k8ErRO/7byoP027XA8uiP2klHA lrblW2QBO1DA89YCvvrWUsCZby0FwNvccf/mdDHU4tHNsV8YervalncpUdZ7AHqnW/Vusupda9X7 EztbTArrlHi0K9ZPaO3wd7X71x/346RN5fJHiTr9a+PKiuVrf09ZHkvr3mMDh4/EbctXASlR5UjV uODvr0KVq7xj7qr200fO2EsQpB2jiVceO/9tcrxobNfp60rvY+ljQtrCWni89QNi/lhLRd8n9Kax FvR467YXxQ6QAu8luIznl1VNGuTLg+ptZdyFn1/t2YVH0NS/vWJp6lFXLU1dcNXS1Nj5O/2r4kr3 2zT/Zdu2LV+HpnuFbVsnLejM+RV4B2CFerrdv4qM6/Cvb79NI0ODMLjDv67tcEV5PLo+9pBRqCuI sz+PjnWw8DcbsNeRitgONjOnPDbyqkxkG4ZrdWXx6CpU8qvLlkpmQ8VZVPKSYJxL7/SvI+NnxlON /wzTrUfxlxLFDzGK320kNl42ik9WOtnsNtns9VcsFt0IrVn0+hSrvmxp9v2XLc3+4mVzs59bJswu N9YHyrDKmiGayIBKnZvZY0mhLPdcNi0pJhZln2Rmof77kYj9O8Ed/laxRYldZsVyL/w2RUfTfqBG h6E+H6KBjn1jNEfwY9qj6pTgfNoIY1sFfPKoyJ0Qf+ZyCu4KQm2dGnsmLjm8V/34vnspj7F5nqID V+y9S/F450aNxDo7EJacKr105Krtpg8ime3/uj7e9TrA6Td933SBFu77FwS4jPsSG/Aa0iEydrZx 9iNHrthWn+x8OB71xCZDZgH2VKmn/fws2mzPn/sC++bsFxppN227HH8DcbO37ZxG+7edgOiFefdz OYliCqmY2bGhaEC0njw725T/X35DkndYan/7zThE4j17J3U6DoSf0qTagvcEWisOUVxG8ceKch3f G7hBsPrewPmJfW9M6dJc/0e+NwbQiPxTvjcwYv+U741m4l/P9wafy/8iDyrCZwr0GWnFaBPT84X8 LuNXMsZ7Fe6gHl2ruXA3NVXeawRX0LsQxRNWaezHZMJKzYVd9lWbuOOCgcZdGcZhkCYoXqdwR4K7 Ndy14Q5u3+OaC+kdFBt3QbiHgpHUdeHBhJOpYej4muJP1wj7/9L/cE9ppF+muhyk5xQ9H9Fzlp6r 9KTTiMinZwQ9k+mZSc9P6Kmj5xF6nqDnZ/S8TM9Bek7R8xE9Z+m5Sk86jZ98ekY8kSzr0R1/xt7/ xQeN/7qzpPpjwaw1fyH4r8MrzewVqtEKfFv4JM1rtMT1Pqv45x3KXf+nJ1ykF00bOfJ/2jOaDd5E Q/jqvFJmm2ivrqmqra8IiU+nK7YycOHdtjkYpi2poToSiNQ0KrabBK7ZH2oKRxvxMXDbLQJy2fFJ 9qpoU1Mg0lJfGQ4pNr/geO1AaxqqWhKc6YKTZcctWkrRMwQvh3kpxd8ueHnMS5pwh4B9duExYHEN +55QbDMFXmRvqHmowoT/SOCD2eSFTRVVAek6xHYnfyNv0HC7Bb1LoCX2xkBVJIBP5NfQNqzY7hb4 CMLJvEAlVbARH+233SMYI+0N1gz3CnwU4dYMcwVjNDSRiXB9QHbOF+gYiCfRBwR6A1ufYtGDgjdW 8qyFVApmKTNTLKsWvHGSZ824UDDHG1qTttQLzgQjW5LTIDgTtRH4ip3hWZ0HnOEiuFp4X65D5GjE ruHkTxaKUWnluFJQ/GsGlJCOmUdCHu0ZBRhCj7aYOF4k9bm08Mxy095sL7Ab/goiir1wrvimoN3w Q1Op2Ae2aqIuCd804VB4SU2TYh/0AnPKTJxoYyM4gwVnCnHEN9ftw15nZKo2WkvWu3Riiq8Eowne YZ+Yae8jcnyERTLDj/QsdyqeacFo84U320c06QjZq2S30N6lOXvLYvhD96pbC2lolTUQgfPmdP7G f5HFHYXN6dZeggC88KYD0dKyjlL6aFK7WzuJGC3u0ZbZoXMZp88ARjInUcNmxT4cRuYkaFsXXKXm NIQCVRXN1Yo2EO51+2gAaptr6hVtCIrOEe6nlLR/mUhsWZ8cw4+LYwAyUSlR9uKgOAfCe3Z6oiZi HLhYgCupOAehxgygUs7BEw0FoTCtGs4hW6AAaWt7UKHsX6KMSnUOPwIhSxkO6DD4JfcLpUSXTgIw 4nxaopm5ddOkuGCPlDYRMH4cgFG7pZEJZPTEhEp2AuYc53cYhnIAtS5DrRAZH7SKWCrkQoUejlbA xZfzZijjVjCQKUGB0MsEyLWSjLJLMGe7tOYhQT6RMC4MsmNLghSGrJO568PV6Etnp5RnP0cAnpQA u8lSnE/BEXZ6olpammAJZeulrY2i7KfRVLm5NPidG+ZRNv0fKQDpcm6gCQjPa84NwGhi9x0TGKdA KG8zBZiG7zjF9HHylMJvvf32UAg5K5xvhmiiIeNuYyrAyzjUujmk8U+hF0m4BpauspwbiwXQFKqt B90lWwm0qNkzsplExZ6VbcJ+bojeJPNHIzXwlQI3Hc7NUiZiBp+TgtV4IQTwczmaIksqQ2zKFimx qKYF5FbJZ1NF4dskxK7xAGyXgHSrBehFqYWgKjheUZyvWBBRqd2yuxZGknJ7ZNUNTEjuDRqSC2tD UvL1hKTAhOQ+KRkxTPmltC4kB9DB0cKQh40meCPiRvesFPmqDPjQfXZjVjWy5xbnm0ZbUVOEahoA vcWNTHw4m8JStIll2Nefa8zbpLj/FXpjmkGjpEt3qT7pF1B3q7vFflLwFI0YPUOVx6SC6SStZ0rS VfAxHQP1LEl6CzZRrPeSZFZBf3op07MlmVPwaypO7y3JvIK9VCE9R5K+ggxaHvU+kiwqOIL50FeS gwvwk5aeJ8nhBX4U1E+So3zSdxoZ3l99uS8fGHxYVenorReoexmZQJWjd/iGsKIXytqVyfqOU/RB EpriC4RD1Zix+IVSH6Jm8/Sb6sNJMFAVDkXrSWeJ2sHSP/QFFrPDlUSGEeoR/hjv9IICtNRI9TEf yBk+caLXb1CfZOB2XyJLmTqay7izYA2a4GZ1Xz+Qc3wm/3D6FLWe883z8Uqk6LdKg+f7AtEG/HBK lZimdrHQg9q7nuReXWZ4dzT26B0+XjjQLKrjZXZW0Q15jAIrnmnBeHCJofM3GDoDlrDTIiWtUsUw y/2AzHfPKaY3dj1OAUiX+y6cMeB2THHPkmOqcDtxNXd5USBA7xmK+x78DimISsU9G3nzlnvFIpep c/l9EDn64xKgX5cXi9zEFDjfDCmKWD6jNYr73lu8PHRpAZ2gwLi830jdQ4XuUaxkHOv+mnVPSIHz zRAtoDAKJwdeQO20aKIIN4cerZiYXplkuJjTZYCRzHVTW6cPuJ1o/RAFIL3p/clgOmcq6T4x4JTi M9h2C4oTxk9SkCXvWV0Yf0gY/xZbeYKNf1WH8ZNS4HwzBEugxs2hR3sHViGZi795TB/0CayanSH+ BDIrvciwqni02aqBwioXWXWjgix5ozKEVchKZc1D5FiAvzXqNy0DVt2YAuebIVjyCVv1CVtVTaAX yRzDj9jCqmbFc/ujGbwQUjhwX4bYwxxIOEJZFKzpRcE6BJsQbEfAIggo30GS1CHZQvQUTzPVLRIM 1VYa34/3RDtzjDM0zTEcfxXP4qOaeD+Uo5jOyJ6lYhy7CFvYFK4PCMlHjJdD2nnCEltmvBYGRA2W 12aIV0HaZ5rDS6oE+tiuXuIlMMCeBgT40497iVdAeDmrFlirO1u8/gXg5jTQUEOvOtVsg+JZJYwa DF7FUitvteANt+ZrDiueNYIzypoLnMcFZ6xduiBcGA0pnicEOKE4F2fldbm81JVpP8wyvRmMM/t+ M5acjTk8LvbxAHgOd3AZ85GpRUvFMy0Y+q2JBHV07mZaUAZ7cDIKR9mtl2fj1l5GjwkI97ueLoGi z8R25tmc7LHahsVwDwa/DYkO3SLYXmbD4yu9vNOSqni2CUaW0QiNiudvsQhQF/JM8GwXMwFdx45r Fc9LC3gQFWkLepka5cYeDvESi7FoGYxLWnS5ZRYjJyprxTMtGFoGg92tbaDQi1O7W9vKgEgPSzPN H9No+9FbLHSCwoEYY1h8xSxCvmSW5FCcdYFzXEUOjMDEvEsKJ4bo3UXZkB1K4aDS7B5ywrsvS86b yZLl2fi+VnaP2YyxJWbzdeZ1qkJKwpOaUPzAdla8C4rfNhQn1XGw1QhSNT0crWlqEXoqzrGeP0BP em+pB8uBA5Sww61l9UZ4VOuhKdl+1RNYZjKFA2cZipBgbcTJTeuRO9GgNQ9z5iUUDlrZW9ZE0THK TsF8T9AYe0K+rjTbmBLXaZtFK7ONqZFSTmhOb54iYmrXi6mNGdEAF3WeBjGss7RJOaZhXdbTa3Pi LkSMa2RTHXU8rmchfUpJxTMtGK/wvbELiLCRQC+SvY2yQuEKLFLhyroaMlx1a9EcCGJ592i/gLhI Yt3waHsB8BJyTx9SQmdOl+dVVAszkebra8PSjPaSyJ59vEhroiX2Ihu1i1bS53qLHPzyGVV+sA9X YyEiRwg/QGTcijQKteKZFox2WmSFkYNxoiCr9+egHfZzxZqI50UyOUQUz98jZ24Mu/HEjZQc0pSr KCBHpY+ho1RVtZJ+A/IM7Z0LrNQusHH7xRbHdUsfjyKpbnnn+ojtG0rIqqWIHI/hz5X72XOxfZeW puD5FoyPb1Xh+spaOMhNn/AK6aPDQelYBbblzcwV6tuF+qdYzTOsvlKoH5uC51swtAJUujn0aKsI 9IrkRoY3cvrngJHMgbtceUGRfuP5tATC9xHpZeI9aUbyFiP9pg4TJKQmG/cEDdEqOksKj6zekfjh SNzUDcO5Wr4h66/qeO84gWs6/XW7mDT6PvEuQmMrgu1K3y/eRGj24VCl/4PclbSVfU1Da2zSF7Qx sH7Zl9vtZT6YH8IvVxk/Q/qEPRXPtGCwNIftxXHdw2mP9haFXiSHl+Qp+MNM6fK8qSYSDTUrmn6i JAmGFymKiWysaIInJEU1YeLPPG0mpCHMV5t2Rd9FrzLHqJZL9V/bk3x2nqTo7x/sl7izNDhhbOSK /lFOfvLYlWBFGyLB2oXE/rcf5Bv7uYmNt71PV+QbC5eJU9NABG7W9c+ezTd2dBO/IrSkoiVi2K1/ LoRyrELSf6r+uzfzjT3fxMXxyZD4vcjv40nHZnVv7GOc3AjhKp4V0J3ain6m3i81ecM2uv9X+eJA BDnHP+MH2YznkD6mpeKZFox2DMQOBDQG0Nu0LRIx8DwFx/tKlgMnGgcgEeAnXwcOriLIyOfcl4nl /Y6CdPnbkKKluTVkcGv38f3pYWhGx6Ro7qEqn6KB0Z6CRxMbLDZVByREsEzk+44LA+LWpkEHmlkc G0QNHwf4phlMVYw5TYJb8jER0CAe7V1Ke5HUb/EJV0GH9K+K+drj62i+WC351uMPgtKK+dLjvKBc xXzn8V+C8hbzlccFQWUV843HRUHlFPOFxyVB5RXzfcc3gvIV83XHFUEVFfNtx1VBDS7my45rgqIz PP+5NNwY69+L0+coxtj3r2TEBWOCuFGg2ZrHdxviTsKmoqL2QftUecMgrjAUXVPnM+OAqvX1mcbk eIuvemNUPiRuEXAtoToifItwA9IH7al4pgWj3e5uitGZ/P6MnZ3010XrGwO8nVcS1wsRj/YB9/UH 3FstgJHMwg1K4vUbAg4aR1k7zOh4yiDWvL3IxrcV8O0m3PwupBkZUE8RZ+BnFNzqNg6IPEp5jAhp 4T8Z4kH1CsSzC8ziySElxCM1NYtYulEdRoIDpxaYT5+gjHdRvE6LPFWhcEQUEVHnI9MicyZlgHTR LeyWTrqx4SxV9/uSbGmoid+ifmbiC8tM7EdUVMVgSyNM/GXqdOKPuBnjZ5V6kdL9nx6gKKCz9J+q Ptij6K0qQJohPvFX/voKdRMDmg8lKvpKdSvTLh8Xoeht6nYGvDgejFOgOK92gDge7BrAo2QPIsd+ /M17vxUD+HgwLgXPt2B8VPIh/IxD1MytwX6PdpHTFzn9Bgl7L5qqneL3XF/NFc0xNnvXXWfpRJEj /Uq75uGehCm+yXUt4MuSDYVkDm66MpbYm+n9rqZKyVg61CV/bF5M50wgLcV8f6JpdYWmiznDR7sx paCLKrUZkeN5/OuvjJVI57tS8UwLhsp5ClFRhB5tB4VeJPXCIkWZSoNJy7yleCfFmVPlHZz2TaF5 14lUBelITbt7Rb1hDLJSAUMQOUYWwZhMpKdqqXimBYMBu9iYXWxMKYFeJPXXKNWXjZkjjJlrGLOm yLLcBK5jzmvCnH1c7EE253mk+2qpeKYFgwmTimAOQo92GOYgibv0xijt25FF/83XlcdHVd37M8Nl TJzJTDqMk2EyYFgkQAATskA0hC1hSVhCCAFcOp0kEzIxyYRkhgGpSp8oKFLwabEufdq6vOeC9T23 1+eCUCnWreWjrVWrRa1Vn/qoC68fnwvv9/2de+fcO8zwz73nfs/5nfP7nm1+95zfuSM8HVir9/+Q JnZP37sUWbBsnBB43ObpxWINds09lwCUWzEVlQLJAhPHya570TgusQM3R884dN26cdx1KzPwoAWj 0QTRwyX6vHU2afgua/suaztAkS4EfcZejLvufewP6Dsr7mXoaj61++G+aG+eHo3faHfPneiKR8cL kegX09zbRyT6ZR/V14QEgH4yUdz6UpAGoCeeHBLuHcaqCZJ0RbYI905joQRInISuMRZICNgSjZCQ vkTkA5JioV0SCXAaRq6TSAhIbLiLhpp7t4RKAG3oT8S7u4V7rxw0E4FdGh+ICvf1cjVusnb/eNVh ZibSnQQ8qWpfw83x1nhswB9CmLhb4TwzxD8T41DpuDq19wh0IViweYJ06yl03zGC3uZ5cQi7cu6f Y3Sh9giV68zuX0goT2uZYLbmY9wU5lGOTKnoy3FzbEcJ7p4JQh6MteIeCwbVPhwPNXF1atcS6ELQ J7cT3Q/Uy52j4diGcCQR7491ElpYxJuMb+Pv+c5+ikQKJk0UAo/bCsfom4yFY4HpPbtKIFXguwmy Z9dMZA3qcHMsmIie7Z/IPbsqAw9aMCoOohhX6Z6NjPP56tSWUKQLQR+pOxzFPsL3ZrJ+X1DMPhLL 8xbr627JYeENyc7A7+mDsQHeTfGO0fus9sJEy2LbYKJH/mCSTYSURtV/Icl8xUqfhNLu9xBGcVbc Y8Gg8MUToTyuTm3kOaQ8gr50UfRO0zkkvBNKzuH1r3Ng1ljidEcJYSvYMkmIx8mImOidOgK71IlI Z4803LxlxqjU58DBeF+sc4vwTjMGp4FjahTe6ZjIjHXNnij9BnOs8M5QK5rDnfFByvlctZS5IRkZ 6mJnLm+5XP3wyYqmisLmInalvBXGqDXFCO9MuS4UMlCZS6XMpURbNcnUDDXhdAVEEgnK1mgF8Kea vQI3x1WT0AoxhB/Pz8Q9Fgw1X8/Vi6tT20WgC0GfpRxSvopRVT72l+klD848FHsetnX9OPHkXfQ7 yqMgVSr/g7ncOw8vaHKrzjv/4onp19NwKhKDu7DwLjjzHKPKB6lOGGtABrK2uRDhbbxnEk9UGFDV AoUEVpbKAbWjlBntxs1xQykG1IZSHlDVGXjQgtGAgmjaxC2mGkDG+Xx1ajdTpAtB/+VUZ97l95Zi e3WyEHjUvM3oasn+fupMy/ROBuVqBNIFPtGVQ3oqMIibowT+zaO1yaxcTQYetGD8o1/KP/qlCE+a jB/9UlPTyP16bwvvFH4Bf5iLmylRQf4UIfAY8K7FJgRWIWiORR9ep8ZCv76F6F2vxkF/OJ4aiFKf vEC1SH/4ktgAiV6oun+/3poXydYsBOlZAkUH3pksSUMFIuLBzXEWDo6P/kqSnpWBBy0YiCKjfL46 tWICXQj6E+DXVUbPBbfQBY+atwPaJBPRzVLHTlMrzBZIGxiaIhW6RSp0Bxd8Dyt07RRWaHYGHrRg UAIZ5fPVqT0AhRBMt0J8oBNmg7cHhRe8MVWIKdSfSrwDpNtQSq+quOr4hEEOW+veQbWJQjAb/FT7 G2Xtu1RiNVaGZFyhSUJFDstIn4yUdZJQkw5hg8M9kSH0hKRuL2j/MTXrND+UksaRMcGAF9XJMdwc f5uKCeZ5hKeMyMQ9Fgx1doTr7wjX3ycEuo6Y688oSXg3Afffha8UXO4ro8rcSxc85nm3Sse8SySn H+rtPO5rTDiX6R0YrV4rIBjoKZOtjgxIk324OW4rQ6tvK+NWr83AgxaMV/bKeK2vDOFflGF9r8yk tfGDCb2vPEgx/DPjx9kv766jUH77NOoJ2OD3Xg1zN6L3hB2qJxA2FN2YjHGD7FRdgfBBjFmMzmvU sCM43dLX6t0ALkzlAuUFLpomOaNc4nEtbo69+A7H6MQ09mEqz8CDFowXbpjzUea8j0AXgv66M4nU 3nvouaBguhB41Lw/lpW/Rw25mRUCaQLv64ogLWU+CjfHaHwsYvS3UpGKDDxowVA4Msrnq1M7m0AX gunKp3rZByuo4ARF3ULqFI7ajv4dT1LtRMWoqzaOMuo4MrRBjLpa/sTy0meEhmsfHDTFqB2qyqm+ N4lRO5EfVbb20nSTLVypfvP6opGB5GC4I9ndrZaSv5Y8TzAf2wwMjfcRhmJW3GPBwLB6OhjK6xmU xIWgz3Bk8j2FhRGfdKvz/fYQ3JWky53v5YfxIP2bfK/CwcFnuMT53mR3J5MPmO9YDd5g0m5Nvk+u Rb7Kqcn3xW35cmXe8tNy1uSyyRZYn+vOmvLvUyw4z8GImMo/QLdXYbmIKPpnTwuvDnfE432RvsGe iPCfLz8DUYF1mmG5lVwx05ykUUDYZrNBsIveqvx1p4rUyDgjrR1pu2ObaRj555yaerYRa6TXkL4n uln467PnTXFG2jykNXawhX9uFv0rTCkMsUKI9UW7E8I/71SRWXqkkboEqeNkyPrnZ1eI4oy085B2 KLahh1IvyE6WY43026bj/ENnjGaTWHeM6nNhFgqVljSGqLCxbE88hW9pCH9DDvJGirSc3ZCT7vr+ xhytnk6SltSU5LDwL8oiV64SpKXyWOqS2GCKhBafKlSbjk6LFEIkORBjpwf/khwF6QnSUiUsBbfu Tq6RpTmIpZOkJbnZIl29yeFEdyzaRz21KYtslTWRIf0QjyLKThdtzjWKjCSGYBP07e6LR4xCl+Vo fJUmPUhsstCujhi14MrslSqjLWM2Gu9miZbsEjLaOnIjsT4WWZWjFfQEluEbGRwU/rbso4XiLCrh NdC/JkfaRNSiTEdsQPjbs6elOIsOSLr21KTVHGWZQLA75V+XY2wnE5ZZg15pB2iYrs8+tjk2PW/4 n6Np21+L7VgtVaV+szIE044xLDXyPtwcD+GTY+49CFeKTNxjweh3CUU4tRdn8M7nDIQfq8IuAAV9 /R38qk3zf36Yd0lG1QpxyiEqYSvaNCNBpuGLJOg/nwJFKbx5+ZdS1kXsAObfQj+PRVsKq/HjxEeZ MA0ENiM/fxcZgkWXTlNxWNDyT8Uahv8AKVu09QnKWPunams1WL/0I2uiPCyerGN6h3BzPFfH+7+Q TIw4Bd+fiYtzPwT0INVL0RVZi6mJDMO3vrG1s7W5kzJ6hcQcryO38gn4Y/HoRlF0ZVbJmdGNpGHn 6plh8RfW4XUl+n2I9iVE0Y7son2JXKIVd0N0LmppV1bZWZ3x/kF6M8CnlCiDXt4usWXu8lW8hWxw nKVoT3becrsWuQgsYMgcRMV4/Hv6TrTzDVnlqrrJrodUb+vqijAfKrGpcnX63cikP74pKopuyp4L IhtbOpGPaOdzQbz7pAiU34c8OuODW0TRrdnzQORp86j4dJbR+LeftvFbOns7zVkwFfR4UTEN/x7/ LY3dojuzZlExMxEPS4gsVWrVGC9S2BwfcGv2Qnwndfyie7OLVySwdZ8wpDv15pR94SFIj8H4259D OrrRLB1TPQrFSx1m2mgmF0UPZc2hkuIaN8lCK20D8USYEz+Svevp8cxS6sklCDvGKPaG6ugl35hi 6oUrUFsVXg5XbxGYi+kAhj6Q4YQIzMMcAEu/CIICE4dPdzRkOiJQx7PEA7XmWaIKiZdiykyXo88U 1BkXfcwjfxlujtaPsQB+GNJcgDWi3H4eheW6Y6CBvxaWNe9qDlANQRfbyIuRg6iebxJenFMvXRZz mFE25lxR036eoVSgWY8RNUkFrkgnp44jZcqfRHScbJVIIj5UoqbVQEtu5Ts39ZHmqHhD84p/IJtW mrsDq3PqPbissU/WpUkNUV57vkmD6XNEoD1nDv1Ls+ZwqTmHMhG4ILcKfZQBuoQ1gycsKohAR24N YtkyqPgaGTjwcdze3NXG8zr6E48kWXOy11ScD+QFekMLDOSWH4jmlL8MyP04x7Qxtzw9LQ/Ls6/x gYwGnCWlEzmJW4X7rPxhF1SxXVDF/u91sAs4KI8C4lTgmXjBEza7k08R2kvnWw0E42w02QhPso3w aZ1hIzwFrwZpIzwNv1ppBxyA+tJceGbuHBrkKZO9sJXtBbYJDvJo3zcnt02QUjYBtKIBPR03R+V8 /PY/OEf99pvxg5m4OPebOcbPwuGsxaRtglRrc4oyqicxRwNyK59Vr9sEv80qKW2ClJqGG5ToUL1u E7yUXZRtgqyiFb+qN2yCo1llTTZBymQTKK8m+XP4Wb1hE/whO++0TZDSbQIIi4qauYZN8HpWOcMm SEmb4PPR6cL5h1TSv3Ru2iZ4K3su0iZIIR8Bfx+b9H9SBMqfnpu2Cd7Jnoe0CU6TR4VtntH475+2 8VtSvSlzFkzlW66PefMMm+DDrFmcYhP0ssOPzdHErXn5PMMm+Di7eIZNkGIvdZveF56dZ9gEx3NI W22CXtWjULzUQbcJPs+ag24TcKEmm+B/s3c9ZRP06npyCTSbYGbI56tTqyXMJYOoCid71Dm1FsCQ 8oXnyz3bVHyoS4wehw48++yFQmAdVWjBBSUpYzM0uBCRk8YsoOki2FgbDqfCiehQPzWaCC5GK2ln jCZDgyM640PRrmT/oAgu4RhbwIgZiibgaCiCSzkir5AiAifmy/VQFAyPDtwcZQuxHlqwAOuhlZUZ eNCCyYNcpDFrFBugKblLBFuvpmwnPcz6tnHhw4n4ILaeg+2y8LRWiGAia01a7Vqgb0ZLreq49AWs 1Z1Sq6oMPGjBlFbIfhAqhWugzYkFarKtQgLj7XO5LGk157geOZ7hRpgbwxqRZwXRqKCbz1enVkGg SwZRZD5fndoSwDIY49QxThIGjKCvKwZH7+LOjYTYP6KLBPKKfzBiYzJOMRFjf2wo2i+KO9TGQmW1 gFDg4EJZax9JLsdZ5RNca68v5FqrzsCDFgz6IKN8vjq1r6Ebgr4+XblL3A1U6A669Bna9ejaxYz9 etauV/d/gnY1AlKBcIO+H9rA2u3GzXFDA7RLNbB2NRl40IJBI2SUz1endjNdXQj6+gz1UvuhXmkj qadDhcUJXb8kNoHT+m2STzjRVjlLQCxwUtcP4vjhbOQf1EboV9TI+s3KwIMWDDrtZ/32s361BLoQ 9OkH/kMTmkfykzzdH5rYJx+xChk65zL5wCf7Q5Ouw5N+vj1UykeB0+fdQ5P/Gc/dw7zYHprCh7f1 08ShGa35vJiOw+2hmUcd8oGX3kO1x/AoT8mH6u/Cg37KPbTkMwd/30CecQ8ttyFPmX8sgOV544B2 KBFmByTjMbkF5ckV+dDWHyHOfMA7tLsJUFLSuolPSCd1/j9lH/wk07+Zne/1bxKEDhzUn9hZP/TM 5/ojO+qHDrI7v/HlgNChRodRjSx8+MJ0tUrx38hy0ucBQkeq0ylkFs/xGe0h/WvJQJ7n/dLLFtNE gRE/ZpHh6zdmscnXL8nIkqY86ZSyZrGaXGbBDYgmPGN+QVbUU67EzXENTtm6+xEOi0zcY8HQk/6x CL0KV6e2h0AXgjho3iW92cbO4rPs9AhPjrErHqY09vFL6P1UItvGNozopuZgr7axSxAjN8UqZwuk DfzfYtn1Zy7hgmfj5qjHF85Ge5dw15+dgQctmBCFEL1xscn3Bxnn89WpNVCkC0FfWuU1SOxTJ/RD xx7Jk4A8TR/64Eged3KFfPypRNIn7kPHi+DnazqXH7LbXs/D//eYD+uHRths+QyazuWHNFsZTsM/ u1SI78i0CBU/bQt1DyaGRPEBG0A4uQ7x8zP6sxaS77/FB3UgLzQUGeiSr+7Fh/Tz2S4JdkU3iOJf 61ihxPAFoOJndcwXwlEsLuCwnl9Au22pMDlpQijeb3HCfn4pt9DvcXP8Ed/Adz+C8HcjMnGPBUNb bOcO9MYShHF1an+mKBeCxT9rEuI+qo9A8be2UDi8WRR/ZwOGWgjzCXmCTuqQg6BOUSzsu3TG8hyr KLbpiJuQiCi223sc8hBZssnEa2YXiFXNthDb38TKPoyb41dNILYb4fvyM3GPBaOuB1GUy13PTrTe WQqKuDq1AxTpQnAsH1iiV4ZwNzYVi/9kf6MJyY7RdfyXTboPNgJ8wflHup03VgrFhuMDuuCb9mcp ouDSZiFuwUA9u15rbTa/wtWSfdgzFE8p/wSkJYW34ea4uhnkehG+RWTiHgsGAqOaoQuuTu06uroQ LPiKLp/BI7jkAu1os7nT4KBfUq4nGcV/JYs/ycWMXIbiP0L4s7xM3GPBUOT1XPz1XLyTkrgQLNhC oVa8LpVcqK1aZm5bmpUifcPW8pEaPl24Oa7i8mMIt47MxD0WDGUWLuNDl8vY/wvlI2hfsRwHmeSX jORLOl7h6Q29ZOuMWnoF30uJ/N+nblLyQ+jrX0xYyWUcxF+clFzOwfFAr+Dg7TSBlmxDUJu0XFh8 k02lLO1Q7+NQgRRtw81xwXKQqkcYxVtxjwUDkb1Mai+T+gGBLgTtE1ZkktK3JkquZFLR5Qap7YrU VYrU1YrUDkVqJ5P6+jSkTBsPUIEUnYKb41z8ZYZ71ApFyoR7LBiIQL18vjq1agJdCNpPnkLK9Cki cNvF3M5bYXC7TnHbrbj9WHHbo7jtZW6vrcjNLaK4nZTcRq4EByf+XsN93MTNhHssGPhAvXy+OrXv EehC0P7Wykxulo85gd0NzM6/0mB3o2L3E8Vun2J3k2L3U2b36Mrc7HoUO+hCGr/HLD5idi+tVOxM uMeCgRHUy+erUzsOdgjaH23JZKcWwkpuZV5fpnndpnj9TPH6F8XrdsXrDua1uyU3L9OyF7QgXZ/A zXEQH091392ieJlwjwUDly+Z15fM6wiBLgTte1ad0iONb12B2Z3M7MUWg9lditnditk9itm/Kmb/ xsw2rMrNbFgxgx6k7U9wc9y6CsyuWKWYmXCPBeMlzRZe0mxB+OersKRJQftQa3Zm5m9pgeL9TPGe VQbFBxTF/Yrig4riLxXFh5hiU2tuiglFEQqR2ptxc1zeCoodrYqiCfdYMHayWsVOVqv4/G8rnKwo aF+0OpOizulh5nRNq8HpEcXpUcXpMcXpccXpP5nT2NW5OcUUJ2iAjRXcHK2rwalmteJkwj0WDDyg Xj5fndo6Al0I2ie05ZxGdHJPMLmLVxvknlTknlLknlbkDihyz8j5/zTkek3zf5uc09t4nm/j+b/N NP8r3GPB2F9+NfvLr+b5vw3+8hS0f3MKOeNTaSD2azn5txnEnlXEDitiv1HEjihizzGxV9tyE+tT xL6RxOxrQCAP/9jl/sREzIR7LBhP/m08+bfxAsQaTP4UtL+9JiuxzKZ7gRmOWmMwfFExfEkxfFkx /J1i+Htm+Nia3Az7FUPoQ1r/lZn8NzN8eY1iaMI9FoxtzDVsY65B+O9giKD9yfasDM3t9wqzO5Fm 96pi9wfF7o+K3WuK3Z+Y3Y3tudltNnlEtLPGh3BzPNcOdg+0K3Ym3GPB+EggszvB7F5ux5FAsLtz bW52mY34JtN8pd2g+WdF8y1F821F8y+K5jGmuXVtbppbFE0oRarfi5vjl2tB84a1iqYJ91gwUIN6 +Xx1ao8S6ELQvmVdJk32pgKr95jVf601WP1VsXpfsfqbYvWBYvUhs1q1LjerbsUKOsCmX8d2/jq2 /9cpVibcY8H4Kx9r+VNOa9n+X4dvfVDQ3rI+k1VXPNnRFwWtj+UbwDqD1ieK1qeK1v8oWscVrb8z rcnrc9PqUrSgBKnajpvjovWgNW+9omXCPRaM3wDW8RvAOoQ71uMNgIL2aRdk7ZOK2xfMbcN6g9uX /8/atcBHVZ35M5NhICRxfCJbXyTjjAgIBBICBPABMzGASImIhsAwmUzCTEISJo8hFPENasVH8QGF +ljxsbgVa6tbxVZb/VVR3F1KqWjduopS0SK6VldtXff8v/O4596ZyYOf/PTek+9+j//57nfOPefO d8616va5VbcvrLr9r1W3L6luntrcdYtbdQMSjncCTt7JtajbqbVW3Qy6z0ZDfQAvn44FnhmcWIhi 5V7UrbqDklGb4ik9YSt0jS3jM++Z/PKoVq5vRJGLgD5qAi01JM1J2F4B8w2C8zbBfAHlMo+T7rPR AA0W8+lY4HkfMFGsXL3YDlMN5I8VMD/UMI8TMBcszgXTmFZBKeb0OHnXLab5/2ILpkH32WiA9iHB /JBg3syJhShWjqyzw3RMO04UaG9frNCeJNCyulxojYkSdHMEY3HyltUB7fA6C61B99lo9LpgMb0u WEzPzTq8LuDFyv0OtBnTpOEC77l1Cu8/CbyP58RrTH32C7x/JlzvEd6XDbwG3WejASMs5tORexp4 Uay8ZokdrzHxOVUgPaKRniaQ1i7JhdSYzEAvt34DTt5blgBpaomF1KD7bDSamBHSI4T0Dk4sRLFy 7FJHHJhTmREC6+YlCmuxwOpdmgurMT2BZm6/DCfv1KXAevpSC6tB99lo9NPMEmDFscBzHicWolh5 ICtW57P2TAE6tFSBDgjQO3OCNiYcBwToQwTuCIHea4A26D4bDUBhMZ+OfMgA0ChW3hixg5YoRwqU X2uUZwuU0UgulMYUAjq55Vtx8t6Jt/3H9EQslAbdZ6MB2deE8mtCuYUTC1GsnLwsRwOTcMcIuPdF FNxzBNxjl+WCa0wKoJxDmIGTd9YywB25zIJr0H02GiDCYj4dCzyzObEQxcoDDrjmkHK8gHrxMgW1 VN7/nFCNYf4BAfUQQTpCUPcaUA26z0YDPFjMpyO//4CKYuXd0SxQne4tk9GgMZcLzG3RXJiNgTss cBw/wcn7QBSY10ctzAbdZ6NRNBDmrwnzv0QRDcBcVZ8Fs+njyQLvY1GFd4rAe0Z9LrzGUBzaOYaL cPLW1ANvRb2F16D7bDRghMV8OhZ4LufEQhQrWSwXXqejpwngS+sV8OkC+P6cwI3BNcxwMF6cvIUx AP/EAG7QfTYawMJiPh0LPMdzYiGKRTfwUhe/7iqe71kWsyDUdJZOTrS2d3Vid3jK3It0RpvU6/Ab BI5byN4dhGMVyqTJRvfZaLB9cgw4cCzw/Bg4UCw6rkF8O9pVvMBzyI5jSltXZy4gEOPKT8bJe1oD gLhQJlU2us9Gg/F7Cci9BMTPiYUoFm3jpblwXfEl04DM7Wcuz5oGE9GE8Y1tqXQ01ZAV0jYBaTuZ fpwg3YHyXI+T7rPRAGNkAyDhWOB5CpBQLJoeZ2wqNt8rvnQaCATppLgN0qT6REMiJT5EEm3JCgxq uLGZOHmr4wB2DspTvU66z0YDmJ0EbCcBu5gTC1Es+iMv7ceKu+LLpu1UwB5zAJM/AUZjsXhHR1Zg fxTA3iIA7xKw36G8f6iT7rPRAOaSOIDhWOD5AMBQdL/byJiyNI2+FJMlhsZ0tyUaHAfeQosTY9fx 6cDhOH6hV+yxKG+LbakeVtyMKJmOX22LV0x/llezuG36CTitnD6Tz1GKOzzPNJoOmKx0VOcI5W7+ z8qGBnJevw9w8n7cCF/8HuV1bifdZ6NR6hb54jD54m+NSN3ixaIRyxkbzW/nqSXT8yIXRVLxRrky veQCXKJlnAZZLKMtCf18LP1gfGJkwcwI5z0XqYWetU22llkWWRBvFFIXRDv0j2WB5YRrNE7eUnw2 9pi7IDja66TP2KHoJVXqAiX8lf8FFziuRGssxUoWZrVXIa+HupkUZhMh0xCHzJKcMrjOZShZUsqx 0WfRApyvGuFCHAs8FfxKIYru4xK8xlm+fcRcJW3n2j5/VNIhrFZksFfPTYwPhcSyPHUpxOBll2ts 0xDGpnFznkPLbQ7OpUY/EIAMfVqC+rkE9X8oNw1x0n02GuoHg/l05P0fJxaiWHRNkrE8fkOGl9yD uBC12iaigXmuStjwlUdqLpkrV6eam5ZACUb+OHlvSQLWJkjmeTPojzrprPzThLr3CezciP06Sh7J bpDP/00+igSppTIptERjtARc1uTFHHrKHZyGpvNc1D5a4jx8pJbXetFichpa0LsnqHdP0Pwnid6d F4tmNTO2grdkT8n7lsMPgsodPuM/IYzLJR+4BlU3w29wLpv0BS6sJQDRrs42KfeRZBpEucTs/HOa 5f0q+Vg1B5uEumF5SvnF/MguEBaP2KmsEJb5pCiJCixsxqSIF4vKWhh7DrHlX+7Z2myLj1LsxZuO 0LcPlSmw83s9FSfveS2IgV9A6rkhGfSXnHRW+g+Q/otf9LdkmpgsDHXGQ0k2bJDuTCpcD/L48rdn CpSOb4hrmfndSS5B+96RGK9kbTMqjGOBJ8wBFKJYecVKvONqiDdGu1o6haJIZ3xFewvXMg2pC2PQ NfjnuWZGLq7nOmdhjWUqHhdbtPmb3OLJWJZLR/Xc+tKQ1V1o0RDbuBKNhRSKj83jGvMvGYDGiTbZ kFhAJVTSxsqkcNkAFJYakjZ1y+PRdvEBNn9sgFXWoiHRSwuFrcj0k7eLPzsp4v21/Vc9YUJ2JSE2 MqGN8KFdLI4IYf4XXQO8UUo0xBaeTwrH4pvoc1qwsdJcoHV59rXaRkf9UK37+k0rqSHcg5N320o0 kMPQtopl0Fmbg85CtSBh8Tp/FDZEutqZPz6A6pUakrxx4abkydYVel5qRgAgTHl/3BBfxfyJAeiv yJB3WjmpXeKPNyZaWpj/zP7f9ylaTPYLWukaqTS2vKu1Wcgz/5sDwF1mFw4lFySoCUgL3h24HeFd 7arTuq7/unN0ZlWn4n5Sh/bTAQDtraO70JXSF5n/wgG01fEpm1YFVKuWHemxGzhm/E/5bT7siMvb xGj0owUeNI98OhZ4tq/EdkRUxAOsko/jmG6r0+QA3f+Ue+wJBYw9yZlHncGfrP5fuhEqozAa9z/t 3sHH5qMwJPc/4waSUe9wgn+nGzlx1Ri4+591eypTRjuMVqsReITBJG81CZy8bSm0phqUYdFO99lo 9JvVStrXk6rVlcIW6CsxGek0KyHfF59ZSnVYnUJa3/ki8Na6UXVRpauMKl1tVOka+makqNK1bqya HYVph/86MjPqdtCvd/8FZarqOjcWiXlGddiqG9PV/WsnVeF/cPJ+iS/wzj63Q1bXf7NbXmGzL9fE DW47eyeujEA83qauyNFH+GFcupUPJfwb3bRyDpYr5HeUQwvk6t1BeV3QhjXcLPwnLXJXNpE5MbF4 WcrQgtvwSZ2qeW11q/oZrWf+nG5pSMCmwKQEyaqLOlVbelRL2ptKLKnlrJ12wz8A4X749zEL5WTs p90hRqFibkEgWdXPwf0Oh+1/XFuZEmtrFSN6boMWsZtWqF5zXLTpeFsP8/9My1VIGpeyieDHUiwM fINW6yCs8ulY4Pk/zlMoCCi6O9NmOFq/C8iIzO8acERipZWKSKzZUhEJSyoie9JWRGItkefZLltE pnVErk1TRF6Hk/emNEJsT5cZkXSFzf6oy4xIk93bbUYkXVEROaU7IyLTRnjJtWOD7iRtWEHIwiu6 MyLSFJmTFkvnpAwt9wo/3O2MyLQzIoUhAduIyLe7nRGZdkRkOqnl9BI3Fi5KZ0RkOktEEkhWFUo7 IzJti0ixhNK0QvXKEpFpIyLtItjoEAvFZtEiIYRVPh0LPLdxnkJBQHHuhXykciVGMv5VLs8/0gMd IJXT2Eq/QYE2Hj/zcPJegkHQ4GEoyxGY7cpF51hX/D3qGpvHJ1aCtlrRZADhJ4s0gOPI5wf8UiGK F3+vhzE81Dz+ha75fBqnB+0RLEhh/ktdeP7hSqwF+wCJb6T5F9HH1jyfrBpopcswtdB1hnWOdAMN AUf0oM75IIn5h+3CEDuRFnCtwjHIrxai6P5qE2P6u8uJ1ibx7ebsn24WZMfjbcQM5jlzctH3VjP2 KjYzC7w7DR0QXg9iitvOAgflt409/95j1By77FDPE1meaLA2AAMejvdbnLyDNuORfBBirw7NoH8L +qHBFl3et+8Tc+A9xU29LD2/WNH1VzDWyB1RGLhtwS2cKziRsODFUTsNfHUrYts3Q/OCGt7rBCc7 uOTiwZYQ20VvdYvPhsVt8lstxc/hrwfFX57iD3l/EngIswS3f8iw4/DXj+Aiz77Vpj9Iu3LDDjI+ 6EmcvDupuofB3ejKoLMfOOistAyku2FoO/UPEvkEvD/piLTEo83xBt5NiNXvvxMyyyHzBJ9/Bx7L IiO2OnTIjNsEmWbugcAThoPwmgY75mo7Cte4V8D/Ju/wAk8Z/OWSHzaw078hUfp3SES4iwLPGBLj xUtMNKuQet5LgbPW8FMdqvFrSyCBGcbeaZpNLlZuBi9X1cTNssBvLf4KScS9wIMYC3QNKxRMIqLC D0HHGN4XB4+4LAWYhcT4eBkPAKmDWZaF6Lg/Q/QV3KXXHHVrSHS0t3XElXmbXVZ1Mo9h1x087oNd Lqeg7J6zCpZeCMH3eT0Cr2c6k9Zl251Z49qEdbyT3Bb3ZOrU2lo1tmSmY8Q84JJW7B8QOCxkW2mL MdGkhnzL/4Fl4dm8EoFPO3rEm+lLD3JakLZU65iAvap4R9jZw7G1Y1lsKtrEG+VuaOBz7Sm8VY7m csMeQnVW0jZIGHEEUrQNUgAx2YFGNgzjmUAn2uIwDGcCXRjNDMOoJdD9Ftc2DIOWQPodFDHGCaxC hYZhiBPowfhzGF69B1YfBMNCxO6a6h+DAXqveALFRVC2duoWxhZtW8vxfYbm/5VoRfQO2orTPNeg Z7fAt4v2as5vqMaacX5Mcb60RY/4QuxKEavcGyzgcgnlkwSB64b7te7LzgFzFD7wSs4paMb18aYE tqs4aDKH6qTmBD5OF8h3WbhBcbJfvk6yo3WzQJFLgweBcyvc7LJ/A+cGuPREqZSiZ3k81szDxtQq Z+ifStWNbS0cyWkGElBCySxCQrJ2/lWcUI7bME4AoldfCGlay9rBnTpvCn0rKRJbtQqfu2ttS60w fjurronUdISooefJJwZs0YHVPq7VTzxK9dgKCvrLLP2IIjqw2o+0/opc+jk+S1QfWO3Iq5VoZS5R 2C61hPU+VKw2CuHPeUwHNwhhhMmKLtoUJ8ndrWNQu1r6ewMEn8Dz8wqXepiLCIhwow1mGCx2fYRA DGk+o11zvh10R2e/BIVo1IGlWnLGfyti8CUFhDqyGV/pC8+rC69twYVTr1EXXjMvGNBnzNIs+7Kz SBtNmu8txWdtoiVYrtcs79pYxNVH9NVDNjfW6eHI7BfA8hhaSMwledTk5eNr5Ngg0Cg8J0YGHWwv cRmVDg+/VrEmNCs2DTM56X6Hz9OcLZrTzkdbaoWbwLcPHdxKwVdudh3q/oRv1WyrZFvVfIhr1WXU /QJ81LusEeomWh2LUlb3pma6ViqTXKaqsPs6froTvfB6oWpSSpmcusWANlrz/VD1lZrxCRPbAjCm yO6t8mmaEnZNfXWrLbaNUqHis6n7Z/DRe/DAJsVnm5TJerwKPmz0Etii8MmtXRyMXxAjHkb3qE40 Y6InWKsC1/PTDfx2BMV7cl7lOPElYywjAlnVPMUe2Oays9u4WbgHjN3oYh5WEGLR9mgs0dnjgLDk 4evJTbRFOgu+KB8OkuBUvGQ3uLEPcIoFfioDjf6kEaD0/Bdgoh6DBR5XYUZ/69GodNUZ69TQ70nJ R+O+NyweWaEqzfi0sGqMDw18de3gi3aywPNS34RoZzaFdZsU48tCn+DLUBh+AXzY2yuwRzC2z83V qA9r1j9o1uyN+qT1ivN1zZmtUYfAt4+PZYL3y/CItrcjhHMguFrz/yyTnz8cnBJGJxt+Ssv+xi5L WwE66yCF3ldCfOrmFMpS7+E3KBu77TaSdm4j5GdB5CJE8ifyedfe1bE8Uh/lI5KY3V2lHeDFLkTB L6R2ueVUdm/t0OxeVwZ/H956T8ueYJftzVsn3CiFAt9kCGXxVlizu9w29tzeuhcib+BpMVSKJFp5 Q+4M9TXWoaGO0enQSMpSHN6nFR9vV5zMcC5JCQ+ffJOUCo5xZUo5XKzlTD8v0BqmODRkOJqkDG+v V6KB09wZotklWfh5LVTsEMrmdMNBJ/9QCY48Cs/HzAercL5QWw21o6C2VKgt53IdGOplR8PCm7XE ZJtEv3BkwGDhT7W+8weuD4PzjJoJvWNv5oTt6NFnu9Uzp70lGkPdsseUEVhpJRzcmFU4l3sy4utp rWipy6koe4Q5w+xzXY9LM6BkDTQj2so3KNnaDNmc8WYE3SYtv9Qh39+7k+FpfYekp9ktykTsKE1k uNEyYbixXttpOno7vZhh4ZeVheDfjtJCMpcB45ZMuFXVI32UVvjED3O/7JasaWR4q7a05ug9htlt L/dGeM57m7J09dHWif7LYcnoFHq0pfVHaWlezfiInrqX5zJpTeQXPQ2TSzAvfsSa7lq/tSRj6sWc mTdgTQjrPoM8bZ8Y9OTJ6YPcRDmZNIfaxi7IYix92u2cimRDzGvFPAZ/hRbwJqkgAz6rqwInve5n gdfcckBNf/MBtfjBVU5m2sBJv10E9knGMvkuy+QL3we+v2MEul+ylU5sindamTdcAO/itMCbEMB2 lcETVS31ptX2alpTbtGyfT+SkoG33aYk9dM2Sd05s/BMLXTA7TSX3RoLdymZYIkNokOizvqd+FFI /AkjrA+VV1N9YzuopILleTapvn1xykZl8FN3hmiues1TQsFqu73cFdsAkS8xV/1S316IRBoTqY7O CO0s2UsN9yjxYF1edvF+3PY7FIRvc0Dorc5ztHReDgS5K38jZIdi/j1YyU4gWfqecV91362kg8ns 0n1XPf9OBeCY3Cpy1XyWFj4+u3Duiq+H6K/wBmWYEq0wnIZNRfuq/X8oFcG1vajo2wXH3aWgnN6H nlx++L7SELypFw25nbER8kPRwwWU/CTLj/3xxZtKQ/Cu3Br60ebvVkDG9K4mlydqlYLg9twKcjqi 7naId3TV09NjotQwSRAwj8BvMpnv58MvQAzbIwcqpYzeEJkGjf/qsTuNhV2bpETw104JOaQ3ZZxD +jlaek926WSyF3kT+Rqt6aBT03z1LQDDy3wSoAU+zzTtFHGM4WuE4BBPNsFciK2bywo8+C0tn44F ngI+OClE8ZSNvDQUwv6b3GMH4xvZnHB6W+fyeIpxEv0Y3YyZlZk1NikVr+eBofPH+DByo/hVejP9 1ncv/fp8LcqDhzjpPhuNdkbbTDujbUb5QSBDsVCsxEDyQD4dCzy/AVkQUDwWv9GBi9IJ84zMpxMy Bm6UkDBKZClk5jSMyJHUMCJ7VsOIGcyVzQQGcyO+c0OpeHc81RG37OgB6tSpvYMY8V2hOBoc3z2C fM9vt+CrkBTHoymOQSigsvuUXY5sFZnSlpmwonLdnDkrii7TVv661UpbQZaSmbaCxCakrdy31WgZ 9dXpzC22KTcqlC2hZWKEATNvCMU4ec/ahUbzS2iUGS0mfQ/oMqOF6BkZLYKbsrQo/40V/eH+bBkt vcDsV65Lv+StLBjsFX60WTBf/KR/7jXyY7hXdwuv/p78sZ+8d8w9TCfCmPRiJ52VtoFkJMj0Wd3s qTMHhLZfQZuROtNfbY6kGqFt3OB7mZlU06eyLOk2opbjaqDJSrfpU1PWRBzpsXugy0rE6VOXPUVH JEBKVe9BlZWi05cq+nEG2YXqrorknfPuY87knb40mWk9PH75hN7ARe1JNKrwRug2knr6UuxI9+FP SgupUDnuAFRayT798p+RBlQaseFkVWW82ZtJQP1TaKUHORWWXgmFVnJQf2+wTBsyb7AtbagvPbaE otJIMvOWZKYT9aazt0SjUVszEo16UdWfFKQ3tugUJPrKikhBoq+siBQkPFN6TUE6tEunIH28S6cg wQkyBQkJxzIF6bNdOgWp/hWdgvT6KzoFqflVxhad/wCzpSD1UkUjOQkW81yDvnoVd3DRTVrHN314 yUpbSisdnt3qGcVCex5gGWlLvWizEpoQABrPZcO3MXtCUy86bKlOn5lqQtFtLDPVqY/KySQom6LL H5SKzCSoPvRY6VHkH3bZJ9Bhpkf1osBMnDKRyMSpWQ+yzMSpPvColKoMdTLF5znoNFKqehv4OFOO 0n0lW03EG9xQqGYSpSXRcAY46MBqpz7EbOlW36Vp8f0dbnqyZRqNiQ6s9nZtumLgplGtiZZafWC1 H2i1lQNXC8jlllr9zSBWW/kws+Vv9dEq/p+2awGTorrSp3pqhhmmCbMwa/iWhxjcdM3Yo/OG2Rh8 YI/gC5SoYAY7Pd09M4093W13D8Nks0iyiWZj8hlF3c/HrrqbYOIzGhVFTXxsfKwg4oqAoJuVaBAi q4CCcVn3nvuqe6uqa3pc/D7oqT73P/8999z3rVNdemQX66bOyK7vIqUS2eW/3nXFfLG2rcV8+TPo 0WAbaGM8awsaIaPBGOfcfUKI0WDMeDpzzR33C7CjwVjC+A2Y0CgTNqoJajTYBRKyxRvC8xiSuJ0C Z78+iUHWSMjbGoSlPiJT39Ncf0RCztqMEBkNRjEiGuzLvwQtGszHp2yF3BqFOkqg+KP7m5IlVQYL vmNK5aBNrvufJEe6DA6dgb6bqfstZFCCy3wYOtRhXDSE7pl3CYKVo450kgG7txi+e6LIoASk+RC0 2cO/MKDnNqn+96MawPXV7Lv/C/WVIDa/CVFGreHcLl1w/N2gh7eVRbFV9UESKdTAN79VFQ91U23o udMmWDOqEYJBM+E9ZNCC5fwYtJA37snwPaCH0fn5wRFgxykupxRKgJ3fNOwKvWMkZ65HEiX0zrc6 eJTdMLgGAjjziCDiQXnlEGk80H36vaCH6/kVyBXIxwq07Ef3giuQz29BoYb4KcYsexF5tBA/v85q B//xNjbhPnAG//np62GBvIIX3Qd6WKAPA91rnnGa1OYuvU5SPDZaGZTdquKHni3IoIQS+u07aPCg y4ieL98PapDhqAwuI7qXIYMSfuhDwQITPWeROyTLa2WweM8iuyTH1jI4vGaRE38FWjSjX0ex4xY9 C/QDSfXAmKjIMspJpt45eE3SPl0uLX0potNbnG76A6BFR5ZH5+H75YKIx02WQbRc51HGq18hmRJR 6bcCtWMth/XKbPkzstixlr4WyahKz7o8/0HQwjDLpRqlLm+XtJPLpfWry/cEHY/dLI/Ooy47fw1a VGcZRKXr8i4kU+I9/cjKjEdkey1lqqO7PDvP7k9lnpPKzXO5u+4pIWsASx4CLUq0bEJHC5CUajO4 V5J3lU3uageUT2kM/yNIeWhpmaTenNC98GHQgk7LofNqE0olPS0praPbMIbVdTVrGyzHCY+AFqnq O+mLGFbPIkD3Ssk1p0yu8ox32Q7de2VWpx3VrPCcxOUpluW8daBFvvov0pSwVq8upPSjOwUvD4od A2+pqnB1p4pHQYuXLS8P7w7l7FVLBTePpC2b24caun8tWUdd56vRt6VIlT7W+hho0bflMJfdeNzV LVsQr+6HZfbxo5+9q8bs3JUaa10PWtDu0TbBxwJSsSJzHs97VDNfXipvpf7nPA5aqO9RNWBxB73b 5W2EfUzZ/aQ04jtfSBXgoatPO2BVcfoToAUIH11P0H8ljFCG1c3SiKuOvhHnLW6P2gfRXaXMsY+l L254EtS44tGOVJWI42F2r4/dmnEeOfb8HfJq8cZ+JzD81e0yRI3tTu13r7Mt/zPIqUYi+x7qsBjl 1qgsP/oCeqp+A84gZd+DAx6+zH6dhx8vzUcOLXzZzxJ+H0xl6F6DDGpgs++5vTPkGe/9Sao/IpUa 8uxnC4/idXraPnFmI+bs34IeDD0qJ5ufNVI5KZONsOTbVSYfHdk9TSRdSLCJCOpR2RxcR2yurzwF emy1X2PIl1HUYUEowq5HJxy9Pp6TVn5YrpV+Dpz8NOih2qPTlfbgIJKpQdy+TdkV3u3jypcEs4jv HgPz6D6d9Qzokd9jZC/l3BHJWzFmq0t7+VVkVaPFfUdqZxy5j5NPehb0QPLyiUf38ZWCXISYj428 lIt3SNpJY6Ut7eGufwM9LN2P1Dtg3cfNtwh2EbE+RvbRfX1I2j/jc+dQyuHn/w70KPcxcpf2+n3I rMa/+zF7Rsb7OH3ic6CHxo+NfHSfLxcZiKD5sWdQyuXPStvv+jzUJT3eU/88uALt/c5d7BD87bfY hIoTYkiohuD7LWmV4HyyNGNx53a9Qfd6QSai88shE8cOKp3z2OHYF0AP3B8DsYzp96LW2oPM5N3y M8EdpErPNitPS6qPxmKvk8xxzqA/B1A2Zany2+0Vak0Mgquhn7VmE9lmBPFy6sMvOp4QaH3R9YTA T/AESv0VT48nBB5mYbmP0/C9p2n47c/xmj8NoMgnajK0BrOsoZ+15vNoGbv8EzX4T9Tgt1DMBPRS /uikR6Q+j/T2CtMXUePuCHUZNu4MUrfjxn0fDPhCM/08DwlIgzyi9P+fFn0Om75ga2rMz17Cp0Nu wQaynT42gIJaej3hls0A/aTlmaGucCabSULoG9iSi51Il062oywCiDIMCMfxVZMQulCFdFChwBjh zNBgMp+KQ+giFTWbiwUuEI5n0/iLnhC6WMNxscCZ4WJqkICWaFahTCCqw4PExmIsPwKhpSpqjpAL ZF14MFkoxPqTBQhdoiO5XCBnhok/IdSjgtqISKSfcule7KftGAo5mCPIa27fzN8kgycNabytRDxw narf0mwnRQDxRoWB8P50tjdGOG5Q0V0yQWK/hfrsNTypZIG9WCB0q5bFHDeEx/1WGFWon1xJmo+b 5V9Vltb2UkCbK6plBKG7NDPatNQIrGUFqJcvEQqdjCNvbNvLAH2xeLLIXhERjzJ9UjuG1sIohj5d ISAROHa1AUbAgMmpBBhzPyRMBrbjUNSofASzg7njNwlZjMuqntiMYWezZEJCJNAnzeZ2y4Q+VUN5 mmxuSkIGNAj9oJDOqxCyShRlkMN41FrLo5v4hBHKqWUUv3H6BMUq1tazkQCOPxkf9mk+iOqZGHaJ lXQitHsqEUZWAOWvfJ66oOWrryBPgGT2txo4eTnLjcWEPG/n1rIENV4ijTt0habBYtE9NJqvRg3R hn+olqmTN2CqeMwGqdJqyB5ytd73ee9YwdzQu/EV4ex7K4RTsDNAHN9ZoLwdJ/SAq/1p78SpMBIL UZu+/gJHXyK2X2kVWqc1/xZPVGQ5YPWKNyckMbQ4niX4Qpzkv17Lv0VJo6WnQfwVJRoMBPFPjXne RoA6RGBzo0/21RIp+q3WfIaIg3hZQy/7HtgKgPiTQ09diA8RhV5jDxFBBY5JtL+QXrkFYYFZpiLk Hf519gRSNU3BlkPQ25+k6CAdw1KJKB/s39C6YnQBGe9oVxSICOzaKscyIpTj/w4PxTYNE4EDmqqc EnaWVpXzQ8U2VZXNEm966DXbgAhM1pTsieMtD8V2HRSBWbqynEv+00dZTixttjKtCW34/L0HQ5cH MgLnMZrTxr9G/j6GNf8HD118ZCCWSOCzKMl8MhNnfaCSTiRw2gLUvaCC6O72zBcfNxjMrkh6q/cO oDrOf6H9Qli1eJtozb1XyeQDMtkeQHvvlskHZTI2U7Yqx+EF+l9EzCpqDoQ+FjA+gvbukgyHtfzh tClbxNj6qbtg8jUyulIihUriUYJogfSFKBtfP/Nwzhw3kIfWSf8s3cAJ+S0QraJrDDdpa4snmGyu iLXLbXMvlT5e2vG6ZxakIQc9MuBVqkMZ/aKzF5193uJoayoRcWQ0D52z9EZHRmy2Dk30yqXTiRNZ eGewbStmcIRnkCLrcrLAEhlMKpWBhotI7kXkL1smKNlgDlXrMJvI/K0sm37anUgNQmiGVxatKoYM +d/eZtcs8/2Aai2n+upo1jK6RWTH2hXlKxgmi5LVfjJlZ4H5VWE7x5EeTa8x15ClTd1Gcom/bsOn hTosGv5P4aaP/A3iUiqIqLoDMim4G7/jOMm/H8bvk+3v1eSybpb9fQp+b7O/W/gdGwL+x6wWbMOs ML852+j7X/H7xs1oJl5O9igcbkASJO2cvu2E92XcaVxhLL+SFCP0E4M/FVtB35aV6h8YJo0zD6Gf av4k9cveiSUA8u1Sl4zbLjr8GqeK2t0xa6MqTT7hsuPwmqwZQzcYesq5HSLlZoMnwHxa2UTEw6AV /g6aIkOE0SkG+mE1dQzWiXXHdnwnbrYQ7R4s9qVj/QUwrdkNqEdkfVyGrw6D1atNsF4R8IW5ZGYw m0gS+EUCnuUyG35EwMl/fISFoIcEOsVENrjxDQ5enExelkjlCXiNABeYSIIn3LQHoG08QNq6LZ0n imQ3mykSjUuMBhqgE2UCaEgN9g6Jb0YD3gklpeLfAzB15w6ATeNIE7K+Y0zDdQbZVIC1ykB+Uuso 6suAdYWxngrM6dgqrNUGtn+yNpkmHqbEd3Va3zXYCidoBncoRy7FOVgEbGhkyp1H+hrGUtL3TsgG 8NQeeqSCuRpVz+3B45fjkWLTOKf8rPlCbv1ApqBxtEtW4Xc486c7+Mxr/dDwt8BzGua0sJjOwNaP R+MoMR2zQy1GBVOHdgJcSGbEausm6unccDafAOtm45hK6eoUk91iHDeOets8e6enHzujFxNgQbpv M3PfVuqMN6n74qh5YbVTPkhl1q1CCvC1xW8BLCArcTCsx+keT+RC1+dgvewofjuCid8cwAgrL3/x 3whxQSI6nCoORAvFRCoL1iYvGvqsqgscYVuYCsNc8KZn+amuLP1uVvp9tJQHsZTjelGPFUpLOHel TLB+I5Lg3BtQuoqJfyvEfC2zbNubbFeCmbOHpcF6xtMnbRoq0ktypYuljFAXb6axfuep367DsCVm 9V0UaRwvlVa1YeJZAjilN5tNx9K5gRhYr+uKXTIpAp9RF56SSMbB2qbD2ohQAvpSK9GGN3RIBxVL 0EByJVg7HSxEKAH40vB8huxFrd/rqDkiRULTyT5SJ7scRUaphGTjBPGOIzsilIA8mZQIZLfDaCqW oEIc33iT6iO7ImuPo78324k2fiA7TOdO631HGUSKBs1lUzhCfuCoApnkABfA2q9DZ/MEG3hZKjdM cAcdQwOTS9gQaRS9Q31gfezg4wk2MJdL5uO0RJ84rJRJEhxLLB8qFPtSyTRpDZ863NWipEoNTOH4 I852KJLsZpbOxgT7Z87KsBMFPtcbS/Ri361z9I1OlhABcy/FJbN9FDfJiWMJEtcXS6Up8BgHcDZP kcj+bJZlPcWJ5CkSGcvlyBzvQLURaQRqOAJHlrALgRtpjuhNZXArbLW4ykkTJC5Fpuw2B6Y1lZHp 2SFicYczJyKViGJ+KEN6wmwHpoPKbXuS/WBFnDxEGoEvMUR8KA/WmU4EkUoELmmsBU4EPr3BEXi6 lowN0kORY07AnyC4HKfPfDKeKqSypKR545hddAoNYMJwKlEcAKvAhSYVsqWdVTTy2+m6hQqTK+PJ XJFSDBmv0IQgTWAZks4RZas2awVPrqPJcT75E8Jr+EKpnmVNJuXot5N5MtvdbuDKKjBrSiBPRma6 ImXJtBjWz5xLijluVATuxAkoYFRfzl65zBPB+rkxeS+Sz7RzZbS/4Ouyb8kEsH5pbKUmJqgMM+TH ntb9Bp5WBWYNBCZjsx7Kk41AvVjzgvUa+moGX6aCNYH6YIZY5IJlGbh4nsGXpmDNM3C5O4MuLaWP wIrTpeOyue8APpjXT9ZLybySnHJ6YrYLFFnUvQL3jpQ5cgGZ6CIpMj3P2qst/WDp9e/wUwK2nZOV dJ0rCxcoYvNDQFB3voGsb3NW/qMmKvENzi7W7IUjc7GghMgJ7/JNbj47TCuI0NzjtK9NA5DC4vpO msUKe+m7YlOOo8+DztGHp6h591yLKrxyt/HNkjKHYwLBY60blQ1MZZuisss5FjCNxbju0XZQjIEZ i9fQM/2P5LqQLJJp6IBz+YLiskiW2yRmoCwSXBw6eRjZsvuRbCjD6CY56DpZgodVmkXdf0CSr5AB yZoRcLizS45PxKU4EgmXdk/fLZRCjmwVnRTXUWq8ZxEq8tGt3ZlfB01w5NVzlaLydUduXMMrp42o hqtybQG/0EHQ0uGAkAUvXXSyRW/Pl97DvTpuP8H6pjNzKsf1u9ius5sP3Ax6C6JnHhL0J4v4lk+r z1niTpaCRd6gFHnVe/IUierlXDUjE8U9DK6aNVaylytbw872wBLElq7nLVoyNryucpUM5cSt7Xud bv1LXKzwbd8/ONVyXO1vnGrndqLaKgEE63rRo/kGpXAOAvAwwPrHgOzthX4pvTVQIRhPJZ9QpDsq 6zaHCeL21kN76HmaogA1Jp4xzMIUOipWPSRH3VoTzy1qzNv24DXCas0N5DrILnEWrKGfteYuFLNL 3AzX0M9a888oxssg9qogzjJBnFmCOJ3UoRmoQ0/VxmEECM3upL0YAUKzwL1yrYm76FoqrjUndyEE P2vNJQhkArysH6Y3RKJFaJh3ayX7no9lCih48ft7EfYj1PiLKoAJb78PsIlcGI1/3UTXwNAYpj5r aWYstOZoSgSupC9UBKMpnR1GZJMbSVMkMtDE9mWNJ7qRfFvGkWZTItVPhvnGk9xImiKR1U0rObTZ Be1cqWPrmgq5WDwJjS1uVpoikTObcnncvjS2upE0RSJPberPx3ID0NjmRtIUiVwdjmeK+TQ0truR NEUgA+EcWXKSzDs8MscUATTDsXRmaBAaO738SVIEsLo+Gi1mo/TWWWMIf4WhfjBWuAwaT7iaXJvr 31fPHFQa0UOwXRhG5W78U7XvfTxueRWvaVvR5BM1GbbHa2gbu4a204NEGMTLCdfvAzgff+nvhGar g1znk4WhdBHME9oaspcBNORiedzaA57u5bN5CDRksvFsZgVUgJnep9nbGiers/iKomYx8hMrbsY/ VbfvQ4u/j9fnG075RE2GVn7yPlqMn7XmWiIM4uWEG/cDHKkGWBQ+aQh/vjHcxbOPRpNkVmARMI5f a+Tr2Zk0JoMsEgkQwl9DJly8t9MlOZd+nUlnBhgWj0SI9NST6VnZqVRKtitcfDoTnyEperODEI6w tfD8gMiOSucz6TmB+ijVZs0g3I4Uc6//b2Iglip8jlG5dj86YO4TUvYNLrPfCsDOHOk4OHeLxEUF 7p79eLt+wge8fsLLPVwkamgdaqh6nS2ot0rFQniIQ/jQ39H/gbIKDF/hwa+sBEWRmu/gWrhFhfC1 JbQwVf4mBdf8WGgmi6JW8qlckbTI8M0eNHRB7MIS0if3K6TnfmiTikoVrP/sxdriCXbS3q7QkkZB z5VYG/gXr6ba5QGVh7ic8sCHavFVyrV+lCrUSdm934OSdoG7yqIkafK1BoyyzVVoSndfWYV200Ed /u0RN7aOJWPB3ftwLHiQiIPsEj9rzGdRgP1oav9BgMMBot1UH8iRISBWzA4WsLqgKRzgw2oUIwzY QrJVhURY7vQYmQlTGWhq8VBrURBcK2CYIwf04dtWEF0NrSMD3CD+qSocxMHwWlSiFuvynznlsLQG /+B9fww/KUbpaRQ0neJhX4cDRZe7crm1KB5Pkc0ZXWGxt2LQnyung8mAkgFOvE3zPOjbNIyLPO5B Tt/OQurrhf1YX/hZa46Q8gTxcur0jwDW4Q2XplPN9DNEnCAbf7IqJasZs+l0k0w5UfYNGhKDI2Qu GkyMkJloZDABFQ0jiUEwwfzooOr9Lozo0HyPeRBfzsI/VQ0foY8n4PW6cU75RE2Glq46iFbjJ1no EWEQL6d++jHAY1j3TS9UpoeJGOdKYvC/VzbQYEloYMsco6EwMtibTROL8fckiMkrYmmyNzEJBdG6 lGRhNr1UOY0dO5Krz4LsZ5T/4yO9QWGwyQjbZediRdpvxJ0ItIVYbBzCUow7hKXbi9qXGk75RE1G jCaVKV6nzlmhaWOlK0t6UOQARmDCIboAKn5cylLh/kkUWDmFGjKDGvhjVKIO1OW3OeV4p1V5RNM2 81W3mfS+jgsawVY5TKu4x9UmUV5DP2tNLE+QXbZTcTu9Ph7FeDl1Lbk6jA5seqNqRjxWjKWz/dC0 g/Yec9UhzQ1tIsBH88Ra5ol7aIkfpCW+Ea8PG075RE2GdjQcQpvws9Z8FG3Cy3q6MiP7iBPpwqOe dnny9aTpO0jq+HQ20z8zkR3qJVvdoFnPrjD5WExuDNUCNFcbVYcBVswjH/jdbA4YDdEFkUgkClc0 RBdftOCMKGnO0SULF0XOi5IGHV20cPGCJVHSoqMLFi+cFyWrwan/S5S/R9ZjM5unGdPo2qZ5Oj8V hGk0aKZ5hsFebG9Oi+X7W6D5WAOV8G4u+d4KzTP597pp+WSRdBJoPo5LppivH7Z9SwZg+wxV+LX6 E+qrL+GfqvpP0K/7UOd7453yiZqMuIh7p9qsNdEFNfSz1vwrkhzES+tucsXcms8OZRLRQnGE4M2W mxrY91QmkeS/7V1MEpcxaTE7HBPnsiBl0cz/UXcmYFJUV8O+1V2MPXQPDAwCKsggiIowMCsDg8ji CKOyCIgoaNnT3TPd0Ju9MDOCiIprQDSaxQS/aGKMSUjilmh2NX+i+dXs+T5jjNEYNYkxUUw+Yxb5 z7n3Vtet6jq34/M9z//8//DQVffUOXc599zzVlVXdyeicJaNb4q71FLZATxdwsTmkmcTg86xIDv5 SKUv8QQ+iVjpzCdPkQJvb6Q42l8U78zLch6/ggzfnGcNS44w1oOx1npo/XHg49Yv8AiG8x37aTwr ncoAt+Xb0PhV3PlEzH7Pj6G9YQy9ALPb+iWdaRe/EizKM3KDDf0Gzltb79OZdAuT1vkVo/XbsIv3 64wWYg8h2TqdW38jXA+1PqAd1/xUkZ/fDOLFsjQ7iGYPajsIVonhKF4PSj/ci/17SGfTWYjGU8OO G55Gi69oO9cG8wnt5CHV4XWvbZnF/j2sny7VUvHjUB22+kiNVuEiqrrVdXh98dUarSqW6uxdjj3+ ur7VZLRYCfrKVAxgeH1Da9iOhpeWU3BmuSa6xplEiO3Wb2otF6AlhgzEdHbQZT0JTgdav6WPHLQW 66qXrRBmXfVg9m2tWadjZqVzxWKlye3Y4cdqRXgqEevsXFgx+gM69vGaEd6P2UVZGBF063dqtZXJ xcvpXMUojAHwXW2Iw5l+3hnRO+jE7+m9UUplR7LATKs/AeeXiYrtPEwST2htW5XE3MtWcTtz4hGV x4SpzY/V3GbUBtzUXYDfgj6mBfd7DK98rEsGjMAr1QgyIjLtXf4RmncRIkf4vgU6EdwN/G2Uwdzt L8YHIZZA1v2lyLri0YXWDrdWX3+vPuO+TJl5sq0hsu1vKXUq075CGVBZ9lVyHGSGfY3slH92/R2l 786sAZFZ/0R2SJdV/0xPhzajvqlpjc6mb2la02XSt+nW6Cz6F9JIl0H/SlrVyp7/TUcElTnfIU2o rDnMs2bA0IWrO2UO85QZJC388uUwz5emthV3shzmybKetHBnymGeKUfTfaLS5DBPk2Ha0C9HtiyC iI3DrrnUNNSLl2r7ysUmJjLIfu/hps6sA6eP2YzGWJVHvt0rZ20GrB3W+muqlfYM/+ZlfvMPdKPD rPUlWjc6bOuOGEdwLv9A6S5I5IupdC7r6M9Ad/2xlrf4xZVjdAtO5d/pZGWvtopBHHv1TzJYnJVW sfgzRv979AJ1LzNpdpkRxuBnmlCWK0bxL+AJp76ev4bN0TBlEdzt+XqkClX4wVFEVaMxzFk1jmgp RsJqJ4fVZNLOQ6ujdnJaHUPqV+EqMMxxdSxpUc2rYc6r4+ix+ABrmANrCt0vL7F2cmJNJQ08yNrJ kTWD7pM/s3ZyZs3UTAsBrZ0cWifq2vOj1k5OrVm69vyxNcyxdbKmPT9uDXNunUJb+YNrmINrNm1G k2uYk+tUTWxUo2uYo2sObaNn1wJt6Pqxq1sfur7sWqhtxY9dPXTs+rBrsWb4WnadRhuS7BoLScv8 52gtu2IOuzCzAYsew03dExFk1ISwwyhVfpJXznKCXRPIbkp44Z1FIyfgNVGjzOnFlS8T9JpGKiv4 kgYcX9Nreszml7Ti/JqnyV0OwKQFB1grHTIqwaQJJ1i7Zql6ESbtOMI6NRHtQhg3AmxhBNTz17D5 DMxTBHd7rmmqQphI/c02yZZLkq0gGozWINlZpJ0/yc4m9SmSnUNaUCRbTY+FJNkaul/+JFtLGviS 7Dy6TzqSbdJMi5Zk5+vao0m2WdeejmQXatqjSbaFttKRbCttVotkF2ligyLZxbSNnmQpbej6kWyb PnR9SbZd24ofyTJ07PqQLKsZvpZkOdqQJNlPIHeZ3xunJVnUIRkmOCDTB3BTd0sTEuuFcQ6xVPlb XrlNsjPJbkqSPTbKIdkqjTInGVeWJDuXVFZIJg04yTbU9JhNMmnFSRbV5C6HZNKCkyxGh4xKMmnC SZbQLFUvyaQdJ9mgJqJdJONGQC+MgHr+GjY/AvMUwd2ec4+tIlk562FZSbKsTDSZrMGyXaSdh2Uh wbLLSX2KZbtJC4plV9BjIVm2h+6XP8uuJA18WXYd3Scdy67XTIuWZTfo2qNZdqOuPR3L9mnao1m2 n7bSsewm2qwWyw5oYoNi2c20jZ5lH9eGrh/LDupD15dld2hb8WPZJ+jY9WHZnZrha1l2F21Isuwg ZC/zg5O1LEs6LMMUB2w6Hzd1Fx2LzPrcZIdZqvybXrnNsmGym5JlWxSWXaZR5izborDsalJZYdkW hWXX1PSYzbItCstu1eQuh2VbFJZ9iA4ZlWVbFJZ9RLNUvSzborDsdk1Eu1i2RbIMI6Cev4bNGMxT BHd7Jk2vYpn9lXRAsXskxT5DNDZUg2JfJO08FJsmKPYlUr+KYvWCYveRFhTF7qfHQlLsAbpf/hR7 kDTwpdhX6T7pKPY1zbRoKfZ1XXs0xb6ha09HsW9p2qMp9m3aSkexR2mzWhR7TBMbFMUep230FHtG G7p+FPuBPnR9KfZDbSt+FPsxHbs+FPuJZvhaiv2UNiQploS8ZW6epqXYkEMxTG5Apam4qZsxHWmV n+bQSpVf7ZXbFPsc2U1JMfzGY5tihzTKnGJcWVLsy6SyQjFpwCn2cE2P2RSTVpxi39XkLodi0oJT 7Ak6ZFSKSRNOse9rlqqXYtKOU+wpTUS7KMaNgFwYAfX8NWyeAvMUwd2eX59UfW8xmSuUmiGbI8ee lRz7BdFcsQbHXiTtPBwbKzj2EqlfxTFTcOw3pAXFsZfpsZAc+y3dL3+OvUIa+HLsdbpPOo79UTMt Wo69oWuP5tifdO3pOPampj2aY2/RVjqOHabNanHsbU1sUBz7C22j59gRbej6cYwFtKHryzGDtKE4 FiQt/Dhm0n3Sc2wUbUhyrAUyl9k8S8uxosMxTG/ApVdwU/f6Scir7lkOr1T52V65zbHnyVmSHDus XI29oFHmHDusXI29RiorHDusXI39no40D8cOK1dj72hyl8Oxw8rV2Lt0YKocO6xcjf1Ds1S9HDus XI39S7PgXBw7LK/GMALq+WvYfAvmKYK7Pfe1EByr3F+UQBsdEEALE8FXqgG08aSdB2iNAmhNpD4F tAmkBQW0o+mxkECbSPfLH2iTSANfoE2l+6QD2vGaadECbZquPRpozbr2dEA7QdMeDbQZtJUOaDNp s1pAO1ETGxTQZtE2eqC1akPXD2ht+tD1BVq7thU/oHXSsesDtC7N8LVAW0AbkkD7b0hh5ltztEAr OUDDPAeA+gpu6r7RguCqn+uAS5VP8cptoI0huymBhh/ht4HWqFHmQOPKEmjHkMoK0KQBB9pxNT1m A01acaCdosldDtCkBQfaqXTIqECTJhxoczVL1Qs0aceBNk8T0S6gcSOAGEZAPX8Nm4/DPEVwt6fQ WQU0SbDFkmCnEQ2lahDsDNLO/9ZiL6lP3Vo8k7SgCLaSHgtJsFV0v/wJ1kca+BJsLd0nHcHWaaZF S7Bzde3RBFuva09HsI2a9miCnUdb6Qi2iTarRbDzNbFBEWwzbaMnWEwbun4Ei+tD15dgCW0rfgQb pGPXh2BJzfC1BEvRhiTBnoCcZT7YriVYyiEYJjYg0jBu6nZ3IqmeandIpcpf8Mptgi0luykJdkgh 2HKNMifYIYVgZ5PKCsEOKQRbXdNjNsEOKQTbosldDsEOKQS7iA4ZlWCHFIJZmqXqJdghhWBRTUS7 CHZIEgwjoJ6/hs29ME8R3O05bTH9sIdEWVaiLEe0uK0GynaQdh6UNQuUDZH6FMqGSQsKZSP0WEiU XUb3yx9lO0kDX5RdSfdJh7KrNNOiRdnVuvZolO3VtadD2bWa9miUXUdb6VB2PW1WC2U3aGKDQtmN tI0eZR/Shq4fyj6sD11flH1E24ofym6nY9cHZR/TDF+Lso/ThiTKboDkZe5epEXZNgdlmOEATStw U9e3GJH14UUOslT5Z71yG2UFspsSZZ3K3cWSRpmjrFO5u3g5qaygrFO5u3hFTY/ZKOtU7i7u1+Qu B2Wdyt3FA3TIqCjrVO4u3qJZql6UdSp3F2/VRLQLZZ3y7iJGQD1/DZtrYZ4iuNtjrqhCGf8uEomx OyXG7iJaS9fA2L2knf8V2WdJfQpjnyMtKIx9nh4LibFDdL/8MfYF0sAXYw/SfdJh7CHNtGgx9mVd ezTGvqJrT4exRzTt0Rj7Km2lw9jXaLNaGPu6JjYojH2DttFj7Alt6Pph7El96Ppi7PvaVvww9hQd uz4Ye1ozfC3GnqENSYxthMRl9i7TYiztYAyzG2BpNG7qGlcgri5a5uBKlee9chtjd5PdlBjDb5i1 MXaPRpljjCtLjH2JVFYwJg04xu6v6TEbY9KKY+zbmtzlYExacIw9RoeMijFpwjH2Hc1S9WJM2nGM fVcT0S6McSNAF0ZAPX8NmxNhniK42/OzPn+MeS/LfiJ59lOi2UwNnj1H2vlflv2S1Kd49jxpQfHs V/RYSJ69QPfLn2e/Jg18efYK3Scdz17VTIuWZ6/p2qN59jtdezqe/UHTHs2z12krHc/+SJvV4tkb mtigePYn2kbPs3e1oevHs7/rQ9eXZ//QtuLHs3/RsevDs/c0w9fy7AhtSPLsOMhg5tGrtDzLODzD NAd8eg43dS/2IbfmrnK4pcqXeuU2z/6T7Kbk2UHlsuxZjTLn2UHlsuwlUlnh2UHlsuzlmh6zeXZQ uSx7S5O7HJ4dVC7L3qZDRuXZQeWy7K+aperl2UHlsuwdTUS7eHZQXpZhBNTz17D5KsxTBHd77lzn zzP12swMCpaNCvo3OVyDZRHSzsOy0wXLGkj9KpaNFywbQ1pQLBtLj4VkWSPdL3+WjSMNfFk2ie6T jmWTNdOiZdkxuvZolh2ra0/Hsima9miWTaWtdCw7njarxbJpmtigWNZM2+hZdqo2dP1YNkcfur4s m6ttxY9l8+jY9WHZfM3wtSxrpQ1Jlr0O2ct8aY2WZcMOyzDFAZvuwU3doXXIrHfXOMxS5ZG1HrnN shDZTcmy3jqHZaM1ypxlXFmyrIlUVlgmDTjLjq7pMZtl0oqzbIYmdzkskxacZSfSIaOyTJpwlp2k Wapelkk7zrJTNBHtYhk3An5hBNTz17D5AMxTBHd7yudrWOa9QOuSUFtAtD1SA2pLSDsP1JYKqJ1O 6ldBrUlAbSlpQUFtGT0WEmrL6X75Q20FaeALtT66TzqonaWZFi3Uzta1R0PtHF17Oqit0bRHQ20t baWD2jrarBbUztXEBgW19bSNHmoXaUPXD2oX60PXF2qWthU/qEXp2PWBWr9m+FqoxWhDEmoPQxoz v3KeFmojDtQw1wGkduKm7srzEV4/OM+Blyp/ySu3obaI7KaEWlKB2mKNModaUoFaL6msQC2pQG1l TY/ZUEsqUDtPk7scqCUVqJ1Ph4wKtaQCtQs0S9ULtaQCtS2aiHZBLSmhhhFQz1/D5nUwTxHc7Tn9 4iqo8e97R4YlJcNSRFMDNRiWJ+08DJssGHYpqV/FsDrBsAJpQTGsSI+FZFiJ7pc/w8qkgYdhuzjD dtJ98mXY1UeOHNnFMbZLMzP+GPsl2AqSXa5r1YdkewTJduua9CXZLEGyKzXt0SS7mrbSkWwvbVaL ZNdqIoQi2XW0jZ5kt2oD2I9kt+kD2JdkH9K24keyj9AR7EOyj2qGryXZ7bQhSbJ9kLvMPVu1JBtw SIYJDsjUi5u6s/HnaMZ8dKtDLFX+ea/cJlma7KYk2SbUliTLapQ5ybiyJNkQqayQTBpwko3U9JhN MmnFSXajJoM5JJMWnGT76JBRSSZNOMlu0ixVL8mkHSfZzZqIdpGMGwG9MALq+WvYPBdkEdwdLX6i yjR7jk5UIU385goy7ZOSaZ8iGo3XYNrnSDsP0zoF0z5P6lcxbaxg2iHSgmLaF+ixkEz7It0vf6Z9 iTTwZdqX6T75Mi34T5tpX9HMjD/TnnnvyJHLOdMe1rXqd3VmXs6h9oiuTV+odRiCal/XtEhT7Zu0 lY5q36LNalHtUU2MUFR7jLap8e0f2hD2/fYPfQj7f/uHthXfb/+gY9jv2z80w9d/+wdtSFLNgjxm boppqRZ3qIY5Dih1HG7qpieQXtmYQy9VfqVXblPtHrKbkmr4a1g21e7VKHOqcWVJtftJZYVq0oBT 7cGaHrOpJq041f6XJoc5VJMWnGrfo0NGpZo04VR7UrNUvVSTdpxq/1sT0S6qcSP87ZaLkWr4GjZP gnmK4G7Pa9v9bzo6RHteEu1XRIOJGkT7LWnnf6fxFVKfevvsVdKCItpr9FhIov2O7pc/0X5PGvgS 7c90n/yJ9qhNtDc1M+NPtG/+0SbaW7pW/Yi2VBDtsK5NX6Kd0SSI9ldNizTR3qGtdET7G21Wi2h/ 18QIRbR/0jZ6ooVMXQj7Ea2etKCJNlrbih/RIqSFH9Ea6D7piTaGNiSJNgdymHnyNi3REg7RMNEB od7ATd3b2/mjH9sccqnyDV65TbQXyemVRMMfobSJ9huNMicaV5ZEe51UVogmDTjR3qAjzUM0acWJ dkSTwxyiSQtONIMOGZVo0oQTLUhPZhXRpB0n2ihNRLuIxo2AYhgB9fw1bL4L8xTB3WggY7D+aBHs c8VSIRHN8F97mVMsxRctEt/OyH+0WfwGTDMQbvebsDZCbduNqaOgG20ZA39OBn/nE38dvcjasgZW GZhhmjeklWjLdeEPThZG7J9ca8jwAGvCTd0xGQyku1Afa3fLl3zNlrfPsQ8chQdW/wIP7Bb1srbr bDP5O+UbjCSssjbx7ZV287Ed/fYv4AhlmOcI1hY239uOr/PT6CV8DZvTQB7B3ehQ1usl+dWV1Y6y v9Py3/MVVoy+ei7jWpntrsb6hkDUqjTSN9Tb6/Jnu8WuynKHXo+bupuy6NDDGcehinxJOKs4VBzY hQdWz856HcqP+jn0/fRRdTqvEJ2OLYbNmdz1WzPo9K18/zaQR3A3+qWc7fTU+whNo2N5YBu6uyMT kO4Ozr4HDnT0Bp7uYGz2j2AwHWcGsPbZ20bD/srA7dDm7BtRZ1VgXh72n4SV2dEX4L/suy6nTE3K E8an5cUnmvL8k0t59Hoy53hdkS+51pZ3zrUPbITXOuyk9G3HtoDaiOo3bgCKUeyf8IpwSn95oJZf yuPAcIn8BbdOj3FfzDtxsd5e/jvf+f5obDsw/zIgyeduZ/hD5wZriuHv+9o/CRU2n8ri1D3FJ3Mt dC0idtGj0W9f6p3Af3/V6KbxjcXONGIb9jRemHemsbfgTONREZjGxZf6rbDU+1hhmwp8rrfipq6/ gHO98VJnrhX5ksKlylyLA5mC71y/n56o8cArxXjAgXrj4d9ysz4q/LpRMyqc7/MNmx/MY2Dga9hM Qh8jYhfnKPD3osGKpWiJbe46MVjEXzPewbpm3V0nptmy8tF4K+s6Cb/wIzAjhBqpbI51nfJjrhFB AZx+JVjX3Le4pHH6AVDtajGOwtIEPF5OxVnXvAf54ckoGETB/Me5YAoKCrzVVtFqs2i1jXW1iVZP RhUcJevqGM+rnTP9pzChXd0PhbA0f/oeLPU8wUsdqB0tpTKs68zwNJR0805yyUohWYqSGJesEpJV 0Gg5Wy4m4h2s6zx8dDMwY11F1sm6NgnZRvNHRSd4O9Bzdv5BT0LssRKGWB28sqN+jyLuXfeBkFuI v/pWLOAc4WvYjIAwgrsNV5UN9g4M7pKuiyuTY3kn55LOUWJyLMuenv6q6Ym5pifunZ6Ed3oGqqZn 0Ds9SdGuMj2puer0bBPT0yGmJ/2LUGUyxPSUlMkQ01O2J6MyPTuEZF0l8K54kfdis3lh2ZmHLnRn V4c9E+g1BGaZc7aM2aGA++9I/jrysS4ZzsO4Es4DvgL/QBjB3cC5Owz8te/Ydta44MZg2uI/rL7g A4e5A9j0AzC0BftEKQCHoTuFEltwk4hWEyTpRJYtOCDKISjnwccLblvCyxHzxB3OWDp5O/ZQsGH8 inXc1F20A4PqdNwXnXEfCXmkOJzbyzgcfA2bMRBGcLdhypDBHoCBT15we2UwH3MN5uNVgzk41z2Y O0Q5Yg/mP8RgJph/UQazgPfImRlsGLp3Am7qTh7ij/7h/gNiFhT5WJcMh5Lcwb8Edgf/Ir0h/BJY 2G14EfbOBLaEuqcGh4pWITfEuo8XeYOhIJZLs+5pQhBAwXA+NZwAWbOQmSgbkbLpQlZnPjKkjGEo lcXwtsfwohjDq7yvf+Rj+BHuYy/c8rEuGY6hfQjHgK9h8zCOAXcbHhs22AngvfHds4JAn4F0dJB1 n2QPAs7rhORkexQxKyYkp9hjgEsOIZktR4CSVDbBuk/dIpMDGMVY9xxsKzADQmJYWT78Z+pz9gB/ PMwH+F+4qfvVMA7wftzHLrrlY10yxhrRFBscl4BuHAWDfIcP+B0+4JfhYAR3G/41YrAgTO/JC+8I RguJbJQt/I9Dcri5Qrw/vb3IFn7ikBxcMSMEdx6SEEqK8l2iHOHlZJwt/KQQNAbLtsmnhGRCcMCW 3C0kk4PlSkOfFqIpwYGK6B4hag5uTyTyMTivZgs/I0QzzZ+POJ7rzkTT4OeBiu9wZOCP4GXoo/rL 0HdvoCgoglmRj3XJMDh+N4y+wtewORaEEdxt2LvTYFaYse5FjcHtRVhNiRJb1IRS9BbQqWDFAUJs 0UQhM4O5PGhMks6a9ijUZC46prkEVzmLjsXJaS6V0mzRcbh7xRUwf4umoO7kj4IiDuvGnXwIN+Om 7sPwyo65Dw61WJ2tHvmxLhljwR1RqHjqxsuwH5HpvO7j7Tkp5sqFWMKKxuMFtmjaXbyvE4LxBOKA y5qFbGawmM9BwlkkF2NHMC7KJ4hyl7l1pzMBcB7EXSAcY9nTcL8Yw8O8r9/Evo4p4T460i0f65Lh r7Di5xDDJg6inr+GzYM78VOIsNuI9eIP3vH4HguHJnC1CVztO6iGuxOULrFFM1G0x2i4HOrPRFNZ ZkxAn/z2RjM09RYzZJx3pREtDMakOHBLiJd3QHnMsViOXGXERmLpBDOOFgqlq4xiAfQnPvJDLG6+ ykAvVsqrrjIG4syYhsrBW+6+Asxz2WwCeJrLFq1sgRkn4hCDt9wJhwrQQ2OWUD0IZTjf3IAoN+YK 2UdBli+BTcumIJZvg3Ipkckzo3PiKBTcDAJATpdQ3welZJIZC0Tx+iuuNt7cZbC/7jdD8w+YoauM FDMWiWN7r2B7jeUgfJUfKHJyrUYv8WPg1SfBn9cYV4AET2zgnAFyYzZV4vfqozgaK5qNWzj2QpmP zprPjOPBpVulWy1HP2Hl2Ym/qDgYTmEKqVwhVRqpSCPsWuNDvK1SbABrCtThCNl1xoMgxV5gtSVe 9fXGAShDTewGw1p5ztrly86xrD5rg5jxntWodRPXbHwZFHEgPGJgcRlSyRj3UwyIUcE77zFDH4AO xYs5KwkDgomeyO/gGRPk9Txb/AG8IXJ6LFeGypdaF24odfD9sbsxyq/CceZwpNBy+XnGRgWfhTr3 Gc+2YDX7jHHz8NJgn3Eabs19Rga3cPx23DbuM36E2+Z9xnu4XbrPmD0ftnv2Gxfilhn7jQ/zncB+ 4wd8x9xvhFpxJ7TfWMJ3Gvcbl/Kd5v3GZ/gOVPMS7ty3zzi+DbZn7TfOx60J/bm1TfTru22iX++0 iX7NaRfyze1CvrddyO9rF/19rl30t64D+3uTcUGSsQPGrjSUDhjPiE1zhm9yYvOo2JyYhc3NxjWX Yz1H4A9n4oAx6zJ+9ByxefhyrvSzu9xKfzvIj3bfIar/JGz2GWc8LXqafFr09OanRU8feVr29GnR U/MZ7OkBY/AZbvY4bur2GYEf4PaAcepPeKX9YnOH2DwrNg0/5ZuzxOY63EywLKB6LhaFEDmt5xUT u/eJHwjbZ/lmwwt8s0ds7hKb74nNa2Iz/td80yk2m8Rmp9h8Xmz+U2yCL/LNHLHZIDa7xOazYvNL sQm9JHwkNpeIzfVi88BLfOg/fxk9c8C4GuLTuMV4OWdAmHbcaoZuMd69FPe7b8WQffhPwmENb3Pj f/yVb966wMDNSRfyze1i88QlfPMvsclFxbFBvvmh2CxLYko3xhmNdePhNRg6LnRiqAnSfaDJMJqC oXB4UbgHisEGFgzhbl9T92jGzBY4enokOOa6paG+po7I4gisqVEMdxmrwx04t5E6IXE41GI4hXoA QxiVRs9k2MgSaCLcKGWRWdy+gfdgjN2DMXaTooaxvDpZaIRU0IQ246aD6TzQHg/1jhH1NjVBE6g1 YWJlDIwdjT1gbCLIxtiySaiAO5NbeNP2yI7hRdn1Y1sMe/c4pYeQj6ZIH40SPpraIKqWxeMnVo4y Nm0SWNoja25Q+jW9odIhtDrhaDmyGbjD2Mzp3DcnTnL5ZlaTUt1J9jDh5NF0TeIpJ8MR6CWbPbHS NcZO7eRVzumQZnxKT4cBTgGTudVSGGkL2qPRPHtSpAp6Zb497xUzlLZ6NIW0rYVVabaLQHHJOtTw a4N+dXoaQaUuVYaCBSJGFJXuSS6HLHSqDYcbwpEwunzRLMhqPUr4w4AXT2F2y6fZEcPYEnVMWP3p Vd5ibKlrOChZ5nFFG7dd7nRWCFZMknF7hqx1lKxVHO5VRiuOCPmZSu2jKg5c6ZGibFWlZ45enx0Z jJ2lmuCxs136KDkHvbSyyfbSarVLeHyNY4HFtZNc6usalBVxrjN8VF3fwZRQEZ7cUFFx+ruxOj5h Cs9TFxFO2iZPdcJV51fFpJBvrnKhkF/gcbmQXujRFtItPLK9NWytmjSUXuSRouxiyFpjcMfyjFBU dImPFNdrVMQtqvSroxNWMddyE7J41XIV8oQrboVsQJlvaGxQNRUaSVeMCFlqOiyobWo2xCnZrg5a KKZN16LLOPONR7OVzts+yrkkwpd5z2JB2aVqYsa2Cz4rCr1XVKdS9KnkCTohLfvEE1aww3QRYagq ilFpWErVLo5UwsVJepd5QghlO6tsscZd1dI6xi6vlkKfdjcZTgevaFDwt8dQ57OvaZwx3lgKq+lK Y1QlTQagfJXR4SpfbYTBDrUZXK+EDbF3jWFT067n2oqkOYwXDVhqrbRyPbTSyuu7wWiR9dvHblRa PD2COh/gEiwJFO+D8som4Y399j4M8Ca+j6eBQsbYzfZRqOUWvo/1sT/jFQ5bz59m+ceY0XhxgW9Y GPPKxcK8VDaWLscTjBfSqf55g7HYXNym2ru75hYS8WS0BOVseXheewv8cxvIwrz+VKnolsROPdU2 qKpIp119rDhCKbN5hVyuNG8oV9g+b1OqCNeAnfPOThSyifQ8ce2UKMBSK6dLK5xL4JZYPo/n9uJM uiWJV/3DaiErbokWRalYiscTA7AfgMUOV9I7hNjWCHKNVE5I+bsuYtdaaYH2QGpQFAcdU9CHC3xR I/jZti2lMrIDxVgyEZd1pwaLiVJlPxtNC5V8KQnDiyu9kBJxuJxNQSuyZTgwF4YQBTeABIIA3Mcb xV3nbSUQQEwN5HNyL1rKZVIxuEQWmkOoA1fhZWfU0Hm3M+oqo0CFRBo8LqTZxBA7Sui5WiuW0laq lChAWwWrP1pMVDwvD4pBKYJoGqbKLhZS2cGBobgoVt42A6GPpBSLoUxMtBVLR4tFu6FUrsgbF6Uh /gaaGBjftY+hu3LxRGxHSSjKgvMAYVTEF9eU7QxEYwl7sIlCISvnOhMtJUVUBUVBiMVzI+gp+9Lf 2bUHkHKOpNxHcHZEjQOxbCktdlO5WCk9V4mTjO1BDBPnPhUIQtwTTu25IvgW9yBeKuvD5H4X70zi Mbg0CuCtrGCTEVpUCH0v8WZg9rjAvUYj/B8XWhWH4vhC6KYE377Hi6E58UIhNDc0LdDSGGgZF9oE /+KhROCUxvibwWJgthEc9/HQtNDBm0I3BTobQ5tAOnRqsAFkUBRalwVOMoLhjwcubTRPDP6V7Td7 gn/ZHQt0j42FpsYCEyDBNULP8Coerv92hSKmeT0M9xwm/rC/CyEql40JXRNY3jBq5dXBzdCVeEtk c8vkdbC3x94L/pfREtra0rievwaXGi0T1sPxDN+wybI+vOe0hDn1Xagcw5tGk5VjZyvH8DbRscqx 1XAshQuogCHF+HNqzPU+L8uVS/lyyVkzpeggw9s/RQvv/xchJjP5aCHBrL611pl95/Qy9yONfHni XVp5G8HqwwdGCyCwLJkixAqz8CZfOlpKMPvxKpbNwWLMDVklTG2YJro6YF+mHcx1cShiDIpFDDXy nIfrPVsU96h51VgpDArqL41YhUQeFmiuEB1Eg3wR0lEizvCZnO3MeXQKDg0UU7x+vJXHq7cb7o8W CikIY+iW5X7+iq/byirlhXy0BJ6D+tYn8qzyfCKMscqphQT3N/qRN4M3Qaueu2SQRKDMD0CW2QFZ wBKiDLjbyuVFhaw/MQiDKIAj49CfLL6lmtgBs5yotMkyiWIRnCA7bVuedhp0NTpk9Y+U4BB3n6sx ++YnVGBZSnZ1KcVy+RGLNytVcwMDcoo2bDzHipZLOYu/cRjLly2gDbiy0i28NQ89wxkBd6UT0e0w PbbrC0P8rcpSiXt/Nd7Hh4ENJAqJbCyBgniqCHGSYNF8PgFDrziTjxGOV5SLYvLEAfs9FVZ5tBOj E+MncSk+4Sz77u4F9ECwjB+DhorRHQmLt4rtZHJQcvrmevBWhSAEsNWP9WGPRPav1DhUALeILgpl cUi+xSlUUvGE6CqWMtHCdjgB4VVu5+EkngOXQ8d5YfIJL/EGNoOlEs9lRA2FRD/Ei3y8x7L4SYEF ixuys1xHucpwK09+M1VtIFcYihbinmwBMyniEfZwtuWk2su1WIKlgUrZeGIY+56FydiOklgasghL J7JwRuF0yL6PnoGDI3JmYexy2fFb9xIXorOVQHQlAYZrwxpIFaDB3IAra7F8DgdXYO5n9QGnrpXi +TAAcwIFIJwu2vPIPc/9W3nCvhLPmXIpMSzDma9VHHQyASujEmwDUTgJwbXCH4Rnu9VTDJjdARlg ojH1EXboD8C2JN/KSGAOTYn06G4eVxKuSlHgTdkzw9fE7srcYxKDGCrDOJejJ/pT8VRBnONG0+45 FzmnsqidyHc/ZM/Up9iZ83ECVhABY39aADKzk8lhrnFu+cQrkwi0wIl0TqDscMMUH+0H9jjPeuMh GC9WJ58ZFtUC9cp5Yew8g87Em9U8vcA05tNlzkiR5KDuInOWeb5cTPJqWFW+teOmuT+XS7NYNB/F U12GVfLnGyAnOhG0WiTaHHfKurVnVMSQ3VLocM5VJ/h57hGlFeApju80nK3h7PMTepjl3dYyDtok pIwC8zxkLhd/xbuYx7AJfl6gPCXNlGfM5bLLbU/BMHPWQDkr3/KDZs/PFeLFypi3XAQeG4rmeXhZ cjWq39PDKss3bQ0lRTZX0oOdn+AEQeR5XEqS3Bac6ktQ2c1NB4hZmX55asDsz8JAf+EUA7lVKFdO GaAtOxPzYILTdB5HcM5iK+UhyPmlHp92WDklNTz4RxSYfGQDKpTn4XKQbnaK8x2VjOrZjEwENq/t mMLUJHI5JuuObpnuKxmCmyE9nPCpsCNR4b+d09ynExB0DsSc8cu15NSDJyPgdpmK7csX7ymRHIA9 DaeeJtZJJf3azzlKt+aKlUkYjiXyJenhyngrI4wBMbK4MMuY7kRHotst6LjImPZacgW4JFs0FsMo 9xKJ+3AwIU8+RXYTJ5kwAEXGfxcTrzysc/qWW5t612/oW7vG2njBul7XxZ5zpsFPADZYPGdk8TRX fVqAsZbiSKYU7YdtqSC2SXuPz0+etYDzEy3LlvfNxa62QAAlWUt8JAuGYgtT0TKYLbdgfkGXqQUL jhUSadQTO/l0CWtOwSukd3jFXAuHctwBLYmkNQDgTljJeMEpQZWxmJwUcBjmzhaM1iJ0QGy2xQq8 M1G4YAftXIm/iNZEzf2wKFrg4gDPS0GW6C8PWpCHs3DGaRfz5X6owClz3Niq/f2QQe0Sf7JI7sse igI64338HYf3oBjemmKs40oz1AGFJuW4IbczGOOXmqi3CvRWwYFmRc+U21a8GpV6SdBLgt7TynFT /l8A/8N2u1dBuwFRGCXbRB28fjwd/gdtvb2gBwe+EKju30rGrzVzeOg315qh38C15VKlXVk92wj/ 35N6M68zQzNhUHtkn4OKfgz+10ubu0Hv7qNEf9RxwMU6Syt6D4HeQ6D3pDweVvTKsq/QLbbrejO0 C4STfPyXV/RuA73bQO9Ow62H/3cqeh1wLd0xmrFIqLq+KxW9pR80Q0vHizn36l3HnDjYCnpbQe9F H70Dit7iW83QYnxnz0fvDkUvCXpJ0PuZj95n1Ppug/omMDZX0bOH/lW5j3OUvtsMpUEv4lPfo4re MOgNTxD+9+o9oejtAb09E5xjqh7Gbp3U2wt6eycIv4xS9LD+nyv1xT9thuJHV9eH/59T9JKglzxa zLlX72VF71nQe/Zo//H+XraPeuweM8QmMva8otcst39iji/5H+i1KQJ79x2PXtsk9zq3j9UZbr31 oPeqj95Ej173ZMY2XWlU6Z3g0bvpdoMF66vrm+/Ru+WTBnvbrNZb7NHb+xmDPaKUbZM+j97iew2W CVfXh58OCCp6n33QYBt9/GfHsv335NcMho9Lz4T9hczJa/We+u59zGCPj3LKrrny/GGeZtxeaK2q lEXLyUpZtID5VZTFqDGPirJoEPOlKNfxMuZFUeY3F3n+E2Wxkh6qlMUEYT4T5dG8fFulLByJ+UmU RQRjHhLlBl7eWimP4WXMK6I8VoynUm4Ux2+zy+N4GfOBKI/n5eFKWZBsT6U8gZf3VspH8zKuV1Ge KNqrlEWGfrZSlncN77HLxzD1L8iO9ZSP85SneMpTPeXjPeVpnnKzpzzdUz7BU57hKc/kEbNZzkcA 5mOcctxkbx3BHtr+NMCfs5njTwP82c0cfxrgz17YvvhpuzyZ9cF2H/iHv7cF/jkPtruU9rbD9hFN +0OwLSnt70V7pX38JGr3bXa5kX3C05/Pw3bKB536H/PUj3n6WaV/mGfte8eo32Q494uxfJzh3CPG 8ly5MHHlYLStxM9kQXziypoO8Xu14cTXOIivfaiPjwLy8jHsU9J+l7R/SJabZPknhlgPJtcfw34h j88KiOOvy3JK6ocDznw1BmD+oPy8nI9xgcnsFCg/C/0/g+tH2EKZnBZL+w2y3CfLw7J8iizfFnDW 93hY3x+Tx+fa/ZflNbL8lCx/xBDlRpnkVsjjJwWdfID9aYFyt+K/bUH3eC6H8s3Q/1VSfz+U4zeY oR+bor4vQvm3cryNML9fCzrvLaD+t2X7f5btP++p/42gs76bIX7/JvUXSv3RppOvxkO+ajTd8z/b dNe3xHTP7xooPwT93SjLHzbd/b3DdPLNOMg3D0L5+Xuc44+Y7vn6viyvleUXTbd/D8vyk3b/R7n7 NxXKlyjxNQfK+PhrNxPx2T7K8Qe+S7JUYVIz/N/oqW+bPL5AtndAlp+T5bs89vfJ8nx5nMXg0tIa zMCFmviQS6xQKpbgqrYlBlfBKzauXQ+XmRs2WhaUznCVzlpRKeRb5vN3XdKJUiLe0oq3qnPWYDrX j7cY8PLMipaHmbisi5czmRG76t41Zzg124Uz1y9b3VspYTP2vlNrrFKr3zvb+Hhwd+WJYOvCjtZ/ ++npVKry9HP1U8344cRoX6x3RWvvjqVLV8L194p166z2ljb2P/kwq3XGBWuWre5bwSpPNbvr5vc7 pMhqA1fzT5Cni73rzly/IbfB6vV0ZSBvJYdYnt8c85oVoevrzo6tP5uPw2No4ZU4XBIXoiPipoH6 QLYFl7z9MStWLHM1fGtgOGpF4RI+VXJaaW1pF77otu/IdPSBx30ddvaGYid3VtUxOW3QXfFhhmK1 s4tn+FS5oZQu9vm4fH3158NjG63eDZ0W+MKnbp/uisXxP/l0qsu9sjrHp2LI1uDwsAUzV8T716nS iLVj/tKlKzZvXra8z2rlU9RfLEpj/jkKWQOXWChxTTivVZlQfmdXWOcLqWxpwKUtplWGuI97rXwh 4akwl0+4W8QIhgNp38j3mYaN1sb5MBFdlqethLijKFfg2jPP3NALqsuWn9MLeQBb5u/p+y2KlLum TCJTTJRciudlh/C24vpEsZzBdbViBWh6vCXnB+9jl+KpLN4yizM7C1iKH62zdkBNg6liKVFYIR6o qPKUEjvuZVHt5B38Rp97Ep3kDEkQ/BbLj6gK/2/+2Y8eWcXBeSVIsMV5nkTtLduPJL2Pv/mt8+d3 dXSw+eLPu23v6GxjrfPbOtpa2xcsaG9j89va2lvbWfP/FZ+Vccaamxk+nKXTq3X8/9O/GfI5tebF 9vM0S0Y7MvvZLFVWHCnOk8/oeMXiqR5VKp/u8SryrOAW28/6LPk/7T1rdxrJcvkKv6Ls3ZUHBBgs WU6MRjdaCdvKypKOhK832eszB8EgJiCG8LBWx+v97alHd0/3zADyrq+T3DDHFkx3dXd19aueTTEF e3vbGTugjx1XoMfF4mIWjW+AFcKTTjcERLlZxGp6IW6VIbw9/Dk4Oj87ax21T87PrgBnI1AhUwnI hvFLCvADVoKbL9B2DR59o9i3CtBuCWWKe/vlQ6n4qVigLA57Ax/q0CwWRLMPs2m3QkwLpkR98Lj4 /g6U4FOxWCjIzu5hbzo3IdAqE2xm2O1pF5Q3wwHsUxX8evC38eMSVlaYhvPFdAx1/P4ZW0NoH0Aa 9RivxgeC44K+k/GMMgTjfg/z6GDwHj/thR/Jl/EaWYjHlfPg8vj9ZUlj3e/t1xlnRJl5Fe8xlXpp o+JVGyVGpljgi+3cKD4/RdimIIBFEQOeCl6/Vzk5P2qfBj/+2A5Ozk7alS23DoMOllL4WAhxJYA1 JBU4lKo2FHbUroob9BtEPxrMMkzmU0TF45cSyObuKbhyCnuDySMq5RJGSoJDG0hal0POw3KV+q/1 emVFCx/jqFcG8mwC8LGAotkQ/Lr6Ohio6VYs9OMp4kOJEWZH+2l6R9vbimAFOZc8NeOjDzUT1cpT tcbskldi/LPAVmBsBaedBU3gVqUUBus38Gm6GTPJeIZ7fipHxQtTn1I52s4NfmNnZ0+aWjp3VLeh spWgrXqTmj6Ykp0/bi0yjO4sKtCSo8G8G0S44j3Y3saR2KddBestAj5UtwzJEIdjmBmO4fa2glTA BWszKgN9Yue2FP7DDzIW+FY9MDHUNF1pqZVLNEcYQs0ueq886TypELWkA0Itlk+IWlRVhZjduO9Z La8nU7+DXe7BDBk7TZprPDKGmixMl3Vd1zNx6RAen1wlo2iI8MVjaFUjeC8dTfxPI0HIz0ZhOPF4 M1M7Wx2/Y06x+D99Uv99Hpv/e9sZ4omJMuRXftbwf/UXe3Xh/3Z267svdhB+5zmygRv+7xs87cPL 1622r6dB8fzHf7vybzrz8K5zX4thGi/mIX4qL4Rupzug10VvEk3ws/jd2+OTS783jciL4OltNOsW i62f25eHwdGr08PXV7jCq8etny/OL9vB1b+/RcmwePTu8rJ11va/92aDcDSCBTFuUJ2Wij9hXViA AzvYmTKcPf3eU/Clp9eLaNQrXrw/RhhdeHLXKwGnbftQqz1FjI5bV+0VtQwl5OJ7jzAvFYvx9X9W b2Urfkn1CkFKtbhovlcRZqbziUClonLIeYlnOi4aqB5hDqFfgqt3P+LnFXYPsSqBwqBYtGp+aaop fO+dIhD9DS6JYCUkBFRj+P5fDQy7sGBD1ektVPtQRrKXa8MYauVa97ZHH+xOjYnYVg3p/11Vc8oK p6eXhEKNMM3sYvb6dwa5+/Xm2Jr1/3z3hVr/jd3GzjOEa+zu7e5t1v+3eJ6WHxULf6Nd313jOI8K 84FOBE6ESRyPiuWnloAmIVIyyV15TnL6s7xUWYN5OaSNyUvPETglg1wVXaHxcSIZLhUZrQzeyZwk 2fOcJIc0JHIWE+kkIKpo4tF35FCRqvC3/hhm3WAa4vqdhUjk62kU9uEuBEkClBU0eVHuAqI2snDx 9J7pXCNCF0kMsGrx6J1kThFBrEZrSngsMXOlRQHDjYlcYMOPp8E8Zo9CLWWRmABSviAjZFjSoeJJ PTe9lIcBbEOkxAeDtyrgcT2cSWzXanQE/RRMdzGdUrhCBm7Yn4ZhLkHStah0nyQwEaCnc0NfxexZ 40cz0gyediUGa2lwpTCO51bijEePRkHVwOoDwj/BOxnGVMa+T4KEK1ovHW/47TeoP/JXk9LWOAy9 x7MuKTWxM+R2eG861XPVC4lMX7RKcm90EVJy/NCzpX2sopLqJulDcvD2h6Lx8VzwspJLnIlWqrx+ dREcts/fnhxp8fvR0smfRlZJLfPY9HRZR7UIlVO1COwPwTXd4exw4EJyK8qWWDLPEW4SjcUXmqfV loMqX7ky5OkynQsAvkBalLFmN/mxShV/cI6nNgqnSg8cuTZgh1ZMIxy13kx2qVQtiK9anlaHl/c1 vTSW0G/NIoHM7El6gl1HTm5qug6djzipyL1VT6WbGOeXUybAY0RNK96DH7oFCxoiHX/Rfktk+Kl1 edY6Da7Oj35qtYNXl62W72NV1QP2aFebexBQCBkNhsc6hJI3pTVGqHOEj8dDVFEamUpWRbCe2Nvb WvGgmvZdzM7OjZKldcygokiAp08f7SOVhep9ihioAWcBkhPiPozieFI0SpgMxV/qKbMYr5o0WgmA H7wmsgd2elmoZBx6NQnMFp8t5OUdn2bK0+wm5cOD53beoA5FH6SHtUDyizV1XXwAotEovOkYfkNl O5PXLWLNXt5tdXvD69Ind5WkmsKVgkAPqfkB06haRUhm0ZJmhteGjaBO24Tws5SSodaK+Swmf3C+ /MNog2z5T/HCX72Ndfa/xotdbf/bfUbpjZ2d5xv73zd5vov64x5ub8G744uTi+BNYMxmSYqYwUTp o6KYZBnm7HIV8dGB/ii+i8r4gYuHhZicVZy3STalLdrUja47iPv92bJdVVU/oehsbGPQm3oKBXkr V6hCbUNYih6Xj+zi/FKG3OIw5dgWKE9VlIuIhrqybmfUJWQkInO2uPXEnEPVVFZ1e6bOsiCezD0T 5cYmtc70xkANr1XkO2nic+HUkM1uBEShPRtyIFSZaqjIL95rGrvd5DyDFcUrdrEXX6uuwd2frC2p bj6L/2w9FkMsc5TtJObcJ4Z3siDWD5shgec2nA/iXq1YOME5MmOmeNbph3CNktT4HrM7Y2SNC/fx Am4794CcDuEAJIhM41vQgbdzEpsosAo6iqsmNShfSYJHLlfdC7sjilSEiOKaQyA28jqkWwFgEk7x 7bYz7obAjIi4zWlI6qrVmTzqEDsCoPiRAlvdijy1qge98GP14NfbaC6CRnw3Dsk8OrudBJNpTEFx 8TSIeixbIMPGf2jqAoGDgCPXhvzaXYjzMYTFODIFEV1ViPiKcTiP+sF/LcIFxT3Gk0mIQ6lwKDG7 CspOXG2dtdrH5+/PmpTGfAUzEmy3YQx6MbU3DknWGyD5ODQe4jEhjkPRHRBl/oKwclsMykddPO6p MZojJKgSAYx8dT1QuS45Sk1mUakZbCgej+6RiNBbIHPVnSxYkzOKi6p7SXmKOFTOQVQV5VRMR0n0 KDA3U1C44dC7uGGey+RZwwtUoxJzFeNFkJrPVBSyuJzlfYOHdY4ZJ1gzX6RtsDgnYNbpO1pI/X8g Hur/8mPzf0rx+dXbWGf/e7b3wuj/n+08Z/7vxUb//00ew/9dnr9rtxz+z6TwUYsbl2L9EvnMc/Q7 C4uTYZUqX2RiQac4nxQ8q6tYv21VYWm9m9bOsdk6vtaTXf9f0fCnntXrv9HYefE8Wf8vGrL+N/Lf N3mE9SXznxp9w/jSLST3yEghy4u8FjFX0XzAUJSE/NUA2VixUv1Z25vmXhWbOunchGWwLWyYQHpi JalFoiTqa7YWmUj6uaGoi6WInUoMcMIxdaaz8GRyKA6VzGapLkoWSnra2xJuoo/hGDoz5TTJHI9i YBY7z4oF5F/rxBJ1cVsibST7HgEZDkgoIKrMO0OsgVn9IRGUzKiYrABmg3gx6iEXD7I99hQk74wg 7qtIbZIHOpPJKOpy+AuMOvfhVGitSBUEiI/gj2JroPD3+MoM5aE6S5TsyBFKAYJTLnaUwbeiGA/C iHMggn3YxQ9x1RK9cqS8reh7eQaPfHhSe6I9sCx31ELhM4QjpI3kaD3wZ2XxU8X34Un9CVmu8PsB PPkXXZNd0Wdtu2QcBTMC97ns1ha97PtUuAkzjWpBA3uNepm/l2CbIKtUqmlhIYD7OJqIhrwcwLPn z5dgoujm8ef+PvxzCX7T1DNKUiFMXapwfHSN/nAwR6aaaxFbjBHbUDSNeVL7Ddt+jAde8DHqBLw4 +Y6jKV3TaBYpAUAH6EY2diOma+8WNwOeQFwGTBlexaHcLhLilKW1kYA5k8uSItWZb2oxM+1hyh8W Ml3pE4cDy9OyRuGBHJcT1XIzAU7WNJTxk8TPpBSLHE0lvnbIfga0IBp7IM6Q2SatzURaJR0KXxLm WfVWwLEzKiHukVuYhzeRw7LWRd6/jBxmeRuSIAagaxXRd7oYj8k7m+Vd+FS0RTzeXF6CIgMpBFC0 eglSNUCmbrfmrrpsMB4+oPJBhzQZoMpkWhATqWnDU3O1lNQoG7LafV0R2yVfIm2LImuyGI08F6QC icg8CDs97MQoHKNwqkXOYDagG19SxUrVg/GULnm5YVupQOLRNuLzg8IHu+mG6pXUKYMp7jxT+iLp VbonuPHOFre3Yc8/etM6+unq3dvg7PysRYiK67afKTKoLQbVA9YLNnNqtLKV7N5he7FaI666EUlZ 683mNbloM02Npp4OHXEAKKy0lVjGOBxm2sKphJ4s0oKjYlCTYUUHwNerkZ0zWOebg6OaYryMPxcf esbTxlJMZvOJ2eV8+IG8EGh/e3zWap+8Cl4FV6/B/6EH6eSTi+AIxyw37+x8ed6b9yoP8jJPXr85 fnuYW/DV5eFrCsVdVutfTw/PgvbPK7MvV2e/Ojltty5zQTj/6M3h6Wnr7HXrOBemfXWem356mqBV 4bODlyi5bvKrx699PCsWeDrAFiSkL60GUIOwBkoNxxooNTDroGSE1kDpsVrfpBq1BwJePhRQRnIN cGpM10Dj6JYqhZUgNNAlYNut4Ujq2kROnoLjXE2AYUgkJ81YfIkCgZjWXPczMgVbQVvmuwRcGb4D /2rDOV+0SAy2ODtsmSKVxdIYCHDs23lIv2QjhqtvzboSMc5+mk0qmbZ0wIuJJpJOlj7Bmua1DR+P a1VFKiwsjURyiuGOlbSvE5n9H9XGo2BRiya7+HemuN2MdJEUtgKBjENWTiUpx7N8akpdRgQTkYo3 8crSBrP0dlvvqS6s6oOJfFrSg96De2Ai9Jbj7zSWwR6A8I8RCWbL+Y+IPKT2d9Gax7OC2GsoYzKN 5zGJWj6cXFxcnrfPyW4reYtRhPAUcTWTwCsEIgHEGUhKL2Xhe0vgewqeEWPJcKKEE3Xd9zC897Zy 2ZUKbKFEoALmVtJT8aZjFX+wZH6D9k3JGqZ5dXNrVhjeclHGgGO1WKDotqSZkrRCkmw2SUckRxD2 f5gA33aLJ+bjDItJ8qXij8kB02GQCaB6EHBhdrYiklKilwIqsUjPfFV+NtmTCqlUmlLkVicuLNwp V/NKc11M1R+JOLwuMlUnJG3mtyG2aUbL9dskq/6yznCD5BQ6yctVjpkMVHny45PKxeHrVnB18h8t yh0uxkvKrWjx80aL/E95/j/fXP/7Yqeh9b97jZ3ne6z/3dvd6H+/xWPFf5DDCo2/4/ogiYBEQuYk oquD6FrWjvB8TixIvu43G16xVB2cCbJIYj1Q+ns6Gc4D9Wsz2TCQQXQzwD2CI0ES5dk8GNzRrS23 5OSHLBNpFO7IIUH75QBfPk9KsRn1RaItkmK5XiWiSKXYfvmGEjjvm65GgHgPoxR4876p8qlWCrtn h6a477oqVQSvkga2lQH1nESs6Hf2pJl3JzROt52bqOvxrQOzeWU8jwczzypDaoyKxSRUlD+4Ta/5 r4Foqi0No7in8E9j3EasG1Ha7FkxiaUFunsbaBh6tx1Wm4uXD3+d3bAbCLvKLCbEQeAomggJu9mH qxUL+YoBS6GYryxhzaFcgKClHx8caUhLD/Do5AqHjiRKT+eVSPNM6ScXf91N5VgHo7j34tlJNYi4 6VYBmHH1OkljoUOrZ0in62vfLYvxYRfWzxbRlUPFagc2+vwyL7biJ1ZSTnDOqMuhiRndVc4hndFd 536mAaLBCJBNfK4ycasQjR3Ihd+ktcR/z8u7wL8Lwj5quixyssCcrJS1hp4XklRE/G4zKTFnOcYw prpL20qUs7teSiXKImPhltjXgKQC+eGnIOrhpoas7AB51NxpU4G6UggTGqRjJKdEKBhETi6C41el BNE5koW58r1dk8i8ejceQYZbVwAieHGxNBb4jgvbQPZWQvZmcwMpO0VBiQzZRCQC/VCE7HeJL6GY kEpMEj3QOhJ+tcNlobwYrPG5pO2SdiQl+SEW/RESOi2uNAWKpascmJ4FQ5OCBKf0vIBtWDYJQMfC iFYjLUSkNRq8jw2v2QkvRErjxnNnaT+xR+/DxATQGbvAtvgekdNeREE1uJnS+pvHeDJ91IWKheuY Fs6Yt91x1OWmY3nVhsIkAqGY+Pp9sWvun91GZR9lhTwSmTaJvGW4bAyaoC8yUboJb12LGZsAVt14 Xtr6vcH7j9qa+C4dMs429gpqK0/pQfb9Om+4liCapiDPXmqBZdGUBKoudFEScP0gdYQxsUn4tCVd JDD99B9IrLz2HOWojPzajfZGDFbK4RfHVtN7Wwi33dhzw+P44FkWsJHpp9xYw5M1R6GVo0zS9jc5 NptuerLF+bjBsjW6M0Z+ihdlq/0muMCTs5QpJL/LQ4We8UDqaU6jGRmmYSZ+nSlMaHPAgvk6BzV5 0g0O5ecuqMGLQ7Z/vDm/ajdB2DgUy5FH/Rh6SZmKmqU8ae2qbjvd2rRzx+oaMWfNBk65FNXyzVpO leNBjY5srtJZSbgfSxNzp4W8NZcmMXGAcslBUqfyj39AnWrB8tyya+UVaIxTiULRHSB9RPsZOFKf GK4lhwSVdNWV3EFmPYl1HGU7nq2IlT0sFRhm3+o/HTX90S4dueY78fnNxJKfXAzjeo9bEQ62q4nW D6mDAXenDnRH8Yyu05HNHIwE8sBQCd69E2OoteAdQyitpzE58xgcOAxTfE1IF8IryljorGrcua4i MrHL4a/0w3SOg86KEHgrpCHttiC/ykLnH/sWfexgZk9xjkiNgpEPVsREEC+RR56MtUDSdABeXe2T WRMBbd6OXaKEzeSaClIBoxaeVswx2wqE4nnKenezzwn5XOQYC2RzV+7xq9onG4HdquMyIAGU60IQ iUiO3TgnyI4wYbX1QyLpDMF0TKL86A+xRsa4kSVSQaGLE6U7kADVGnaUacDOWHTxKKEUnF+0g9PW GQX25do/qOTHzsiyfxQyW6VmKDU7md4+VrCVdNtA/qaS3eAUx5+b0zPGArYI5ch0BR+yBTkQ2BGV DE+c6sMXikyqWpEcQDHbdTe9oJK/TKYQDyt1kZgaTXc42+dX8JIoQVbJL6FEImcqaSwZfhYrNUTS K21asTMKOuOL+oVVpLuWN1Xb7VPTty8a5YIRNKGg8LN6Nx8lMDm9Sw3an+4cKDOWE2ay4naCJdHX ovKARPaKRySfSxAWH1XsLkmvKlqYhSOjSsoPd4sfFqIG6kYOqojuh6y7x4W+rgDUVzxiGSVRzdme q5z8yzO6t8/+pTql9WN4J501I3Y1tr7R8VXjnrjMPhP9IaFUsmjz3b+4FPQXo1HmoLDCrj5jctJe yoEtaQp0Ww93ZEv7sinnomX+bA9va5lfW9a1Te7/04NKBzEugoCvR0guXdyC39nw9Pbw6ieSa63z wM44OACxT705edVmmyIeorgmomE4uvfA060cPCPvU/1GUimkmQq1IgxeP/TUFSv8mstJEHG1ZVEW CYopt/S/QwqvWxXO7psYW67KU7BsnkRqWEV1kst9JWSpEIvJLI6yqCp4jWUFVMJl6/C4gruNeq1X ClAg7jQmRQl5tXKylFEvZ+9OTwnhxWRNl4QzMkTGDj7yDZnyieoSgNe5kJeuw8ijrCxgmhsrZwYt ZNKH+ACOk4V1E5PGTO5cAuGf+GGnRdIvzqFMn03lsMx7kr4ayL54U/SqPhiLKFTVTmOKMsgB4ySl ZcehhGbSMrVG945aMoUIEyxJ/BJ9aDqgKEaTuVc/vtr28sFUCDcY20caSBRIpi5GsCkqGsqq+pJC M0lto558bnNGyR0AsM6jdG+0aCS38MgoMOSXhJCuDiL9XxT8yWRIvAhkjOoftMuL2YkaoiVy4eQa 6c/LD2wR1Xg1ubIdy3MdK9hZmQNQ7lVCH90szaEPKc66ZA7zdVHulvbSPjCbf0Qe/OrSIHZFjc/f TRRk6d9n5gArtiWNvNuylOP6egSt21vSiEkktmWm4pnsqa2QkEvOhIXjZKaA9GUHtsJB/IDljEw2 b58PQ57LOv4m5bVmY8d6mI0/x+bZPJtn82yezbN5Ns/m2TybZ/Nsns2zeTbP5tk8m2fzbJ7Ns3k2 z+b5f//8N4h8qogAEAkA --=-SATGj6SCZ+O1x88muTIc-- From herbert@gondor.apana.org.au Wed May 18 01:31:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 01:31:36 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4I8VJF3006612 for ; Wed, 18 May 2005 01:31:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYJwL-0007xb-00; Wed, 18 May 2005 18:30:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYJwI-0007zt-00; Wed, 18 May 2005 18:30:02 +1000 Date: Wed, 18 May 2005 18:30:02 +1000 To: "David S. Miller" Cc: Linux Audit Discussion , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Chris Wright Subject: Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502 Message-ID: <20050518083002.GA30689@gondor.apana.org.au> References: <200505171624.j4HGOQwo017312@turing-police.cc.vt.edu> <20050517165528.GB27549@shell0.pdx.osdl.net> <1116349464.23972.118.camel@hades.cambridge.redhat.com> <20050517174300.GE27549@shell0.pdx.osdl.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <20050517174300.GE27549@shell0.pdx.osdl.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1301 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1349 Lines: 44 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Guys, please CC netdev on issues like this. On Tue, May 17, 2005 at 05:43:00PM +0000, Chris Wright wrote: > > This has some issues w.r.t. truesize and socket buffer space. The trim > is done to keep accounting sane, so we'd either have to trim ourselves > or take into account the change in size. And ultimately, we'd still get > trimmed by netlink, so the GFP issue is still there. Ideally, gfp_any() > would really be _any_ The trimming is completely optional. That is, if the allocation fails nothing bad will happen. So the solution is to simply use GFP_ATOMIC. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -673,7 +673,7 @@ int netlink_unicast(struct sock *ssk, st int err; long timeo; - skb = netlink_trim(skb, gfp_any()); + skb = netlink_trim(skb, GFP_ATOMIC); timeo = sock_sndtimeo(ssk, nonblock); retry: --vtzGhvizbBRQ85DL-- From tgraf@suug.ch Wed May 18 04:30:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 04:30:52 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IBUjF3017721 for ; Wed, 18 May 2005 04:30:46 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 420641C0EB; Wed, 18 May 2005 13:30:30 +0200 (CEST) Date: Wed, 18 May 2005 13:30:30 +0200 From: Thomas Graf To: Herbert Xu Cc: "David S. Miller" , akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518113030.GA15391@postel.suug.ch> References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> <20050518011632.GA27813@gondor.apana.org.au> <20050518013712.GH13748@postel.suug.ch> <20050518015213.GB28070@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518015213.GB28070@gondor.apana.org.au> X-archive-position: 1302 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 667 Lines: 15 * Herbert Xu <20050518015213.GB28070@gondor.apana.org.au> 2005-05-18 11:52 > On Wed, May 18, 2005 at 03:37:12AM +0200, Thomas Graf wrote: > > > > OK, I initially thought you would head for a much larger > > threshold. Not sure if 30000 is large enough for a full > > scale NFS server though ;-> You conviced me that my idea > > I think it's big enough. If it isn't it means that somebody > has reordered the packets by 30000 which I find hard to > believe :) I was thinking about some kind of nfs server with huge recv buffers and increased limits receiving at 50kpps experiencing a delayed fragment once in a while. Definitely a rare case but not impossible ;-> From herbert@gondor.apana.org.au Wed May 18 04:41:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 04:41:59 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IBfhF3018626 for ; Wed, 18 May 2005 04:41:44 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYMuf-0001AR-00; Wed, 18 May 2005 21:40:33 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYMuc-0004Qs-00; Wed, 18 May 2005 21:40:30 +1000 Date: Wed, 18 May 2005 21:40:30 +1000 To: Thomas Graf Cc: "David S. Miller" , akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518114030.GA16993@gondor.apana.org.au> References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> <20050518011632.GA27813@gondor.apana.org.au> <20050518013712.GH13748@postel.suug.ch> <20050518015213.GB28070@gondor.apana.org.au> <20050518113030.GA15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518113030.GA15391@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1096 Lines: 27 On Wed, May 18, 2005 at 01:30:30PM +0200, Thomas Graf wrote: > > > I think it's big enough. If it isn't it means that somebody > > has reordered the packets by 30000 which I find hard to > > believe :) > > I was thinking about some kind of nfs server with huge recv > buffers and increased limits receiving at 50kpps experiencing > a delayed fragment once in a while. Definitely a rare case > but not impossible ;-> The worst that can happen if 30000 is too low is that we drop a packet when we shouldn't. IMHO if a single host sends us an incomplete packet, followed by 30000 unrelated fragments, and finally a fragment of the original packet, then it is only fair for us to drop that packet. OTOH if you're arguing that 30000 is too high then you might have a point. However, in that respect it cannot be any worse than what we have now which is essentially unlimited. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From joern@wohnheim.fh-wedel.de Wed May 18 05:21:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 05:21:40 -0700 (PDT) Received: from moskovskaya.fh-wedel.de (mail.fh-wedel.de [213.39.232.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ICLZF3020825 for ; Wed, 18 May 2005 05:21:36 -0700 Received: from wohnheim.fh-wedel.de ([213.39.233.138]:57770) by moskovskaya.fh-wedel.de with esmtp (Exim 4.34) id 1DYNXa-0004et-DD; Wed, 18 May 2005 14:20:49 +0200 Received: from joern by wohnheim.fh-wedel.de with local (Exim 3.35 #1 (Debian)) id 1DYNXX-0007Uv-00; Wed, 18 May 2005 14:20:43 +0200 Date: Wed, 18 May 2005 14:20:43 +0200 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: [PATCH] reduce stack usage for arlan Message-ID: <20050518122043.GA28800@wohnheim.fh-wedel.de> References: <20050308153457.GB8703@wohnheim.fh-wedel.de> <428811FB.1050308@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <428811FB.1050308@pobox.com> User-Agent: Mutt/1.3.28i X-archive-position: 1304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joern@wohnheim.fh-wedel.de Precedence: bulk X-list: netdev Content-Length: 669 Lines: 26 On Sun, 15 May 2005 23:22:35 -0400, Jeff Garzik wrote: > Jörn Engel wrote: > >Jean Tourrilhes indicated that this driver is currently unmaintained. > >Jeff, do you want this patch? > > > #define SARLSTR(var,nn) {\ > >- char tmpStr[400];\ > >+ char tmpStr[50];\ > > int tmpLn = nn;\ > >- if (nn > 399 ) tmpLn = 399; \ > >+ BUG_ON(tmpLn > 49);\ > > I'm uncomfortable with arbitrarily lowering the string size, even if it > does include a BUG_ON()... Here are all invocations of the macro in question: SARLSTR(textRegion, 48); SARLSTR(name, 16); Still uncomfortable? Jörn -- Those who come seeking peace without a treaty are plotting. -- Sun Tzu From tgraf@suug.ch Wed May 18 05:24:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 05:24:51 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ICOZF3021454 for ; Wed, 18 May 2005 05:24:38 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 6608E1C0EB; Wed, 18 May 2005 14:24:21 +0200 (CEST) Date: Wed, 18 May 2005 14:24:21 +0200 From: Thomas Graf To: Herbert Xu Cc: "David S. Miller" , akepner@sgi.com, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518122421.GB15391@postel.suug.ch> References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> <20050518011632.GA27813@gondor.apana.org.au> <20050518013712.GH13748@postel.suug.ch> <20050518015213.GB28070@gondor.apana.org.au> <20050518113030.GA15391@postel.suug.ch> <20050518114030.GA16993@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518114030.GA16993@gondor.apana.org.au> X-archive-position: 1305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1467 Lines: 33 * Herbert Xu <20050518114030.GA16993@gondor.apana.org.au> 2005-05-18 21:40 > On Wed, May 18, 2005 at 01:30:30PM +0200, Thomas Graf wrote: > > > > > I think it's big enough. If it isn't it means that somebody > > > has reordered the packets by 30000 which I find hard to > > > believe :) > > > > I was thinking about some kind of nfs server with huge recv > > buffers and increased limits receiving at 50kpps experiencing > > a delayed fragment once in a while. Definitely a rare case > > but not impossible ;-> > > The worst that can happen if 30000 is too low is that we drop > a packet when we shouldn't. IMHO if a single host sends us an > incomplete packet, followed by 30000 unrelated fragments, and > finally a fragment of the original packet, then it is only > fair for us to drop that packet. Argueable but I generally agree. > OTOH if you're arguing that 30000 is too high then you might have > a point. However, in that respect it cannot be any worse than > what we have now which is essentially unlimited. It's definitely better than what we have now, if the sender uses a per route or even per interface counter we're on the losing side anyway but if there are any gbit capable oses present which do that then it's really their problem. Not sure if it is small enough for randomly generated ids though. Anyways, I think that the assumption that at least 50% of the id space is actually used by the sender and seen by the receiver is fair enough. From ak@muc.de Wed May 18 06:20:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 06:20:29 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IDKDF3024293 for ; Wed, 18 May 2005 06:20:15 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 6AE9CD033F; Wed, 18 May 2005 15:19:34 +0200 (CEST) To: Christoph Lameter Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shai@scalex86.org Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 References: <20050517190343.2e57fdd7.akpm@osdl.org> <20050517.195703.104034854.davem@davemloft.net> From: Andi Kleen Date: Wed, 18 May 2005 15:19:34 +0200 In-Reply-To: (Christoph Lameter's message of "Tue, 17 May 2005 21:27:48 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 566 Lines: 18 Christoph Lameter writes: > On Tue, 17 May 2005, David S. Miller wrote: > >> > Because physically contiguous memory is usually better than virtually >> > contiguous memory? Any reason that physically contiguous memory will >> > break the driver? >> >> The issue is whether size can end up being too large for >> kmalloc() to satisfy, whereas vmalloc() would be able to >> handle it. > > Oww.. We need a NUMA aware vmalloc for this? You can do that already by just changing process NUMA policy temporarily while calling vmalloc. -Andi From ak@muc.de Wed May 18 06:28:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 06:29:06 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IDSpF3025075 for ; Wed, 18 May 2005 06:28:52 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 24215D033F; Wed, 18 May 2005 15:28:15 +0200 (CEST) To: Eric Dumazet Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 References: <428AF378.5020109@cosmosbay.com> From: Andi Kleen Date: Wed, 18 May 2005 15:28:15 +0200 In-Reply-To: <428AF378.5020109@cosmosbay.com> (Eric Dumazet's message of "Wed, 18 May 2005 09:49:12 +0200") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 227 Lines: 8 Eric Dumazet writes: > Related question, is pci_alloc_consistent() already NUMA aware ? It depends on the architecture. On x86-64 it has been for a long time. I believe IA64 also got it recently. -Andi From ak@muc.de Wed May 18 06:43:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 06:44:12 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IDhvF3026303 for ; Wed, 18 May 2005 06:43:58 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 76406D0340; Wed, 18 May 2005 15:43:21 +0200 (CEST) To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO References: <20050517.192416.108741581.davem@davemloft.net> From: Andi Kleen Date: Wed, 18 May 2005 15:43:21 +0200 In-Reply-To: <20050517.192416.108741581.davem@davemloft.net> (David S. Miller's message of "Tue, 17 May 2005 19:24:16 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1780 Lines: 46 "David S. Miller" writes: > I did some cross-continent (San Francisco --> east coast of US) > transfers to make sure TSO stays on when packet drops occur and that > performance doesn't suffer compared to TSO being off. It all looks > fine so far. It would be interesting to see what happens with moderate packet loss (= e.g. conditions handled by fast retransmit). That would lead to occasional "bubbles" in the pipeline. How long would your algorithm need to refill it then? I suppose this is a common case on internet servers. > > There were many bugs discovered along the way. For example, the > I moved all of the "should we send" logic privately into the file > net/ipv4/tcp_output.c, and I am sure there are many simplifications Thanks that was long overdue, thanks. tcp.h still has too much inline code though :/ And congratulations for getting rid of the "if() from hell" in the send check. > possible. There are several spurious tcp_current_mss() calls scattered It does far too much work for the common cases too. Similar is true for the ACK logic in the input path. I think quite a few cycles could be saved here (although it probably doesn't matter much anymore on modern boxes because they don't result in cache misses, so any improvements might end up in the noise) > @@ -674,59 +653,274 @@ unsigned int tcp_sync_mss(struct sock *s > * cannot be large. However, taking into account rare use of URG, this > * is not a big flaw. > */ > +static inline u32 compute_xmit_cache(u32 mss, int sacks, int tso_enabled) > +{ > + u32 ret = (mss << 16) | sacks; 16bit MSS? How does that deal with jumbopackets on IPv6? While the MSS option is also 16bit it is legal to construct bigger datagrams when no MSS option was exchanged. -Andi From jheffner@psc.edu Wed May 18 06:49:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 06:49:27 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IDnEF3026965 for ; Wed, 18 May 2005 06:49:14 -0700 Received: from [192.168.1.4] (ipl-67-013.pppoe.stargate.net [206.210.67.13]) (authenticated bits=0) by mailer1.psc.edu (8.13.3/8.13.3) with ESMTP id j4IDmZKV028117 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 18 May 2005 09:48:36 -0400 (EDT) In-Reply-To: <20050517.225944.92583479.davem@davemloft.net> References: <0dd16bed0ea56242244bab0a7f1cf372@psc.edu> <20050517.200015.55506861.davem@davemloft.net> <03e7252e3f5541302f25675360330b1e@psc.edu> <20050517.225944.92583479.davem@davemloft.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <733fac6ee56461369398a1165357d6de@psc.edu> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com From: John Heffner Subject: Re: [PATCH] TSO Reloaded Date: Wed, 18 May 2005 09:48:35 -0400 To: "David S. Miller" X-Mailer: Apple Mail (2.622) X-archive-position: 1309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 221 Lines: 11 On May 18, 2005, at 1:59 AM, David S. Miller wrote: > > Thanks for the data. > > How long are your transfers? Just curious. I was actually measuring 10 second intervals in the middle of a long running flow. -John From ganesh.venkatesan@gmail.com Wed May 18 08:56:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 08:56:34 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IFuIF3009410 for ; Wed, 18 May 2005 08:56:18 -0700 Received: by zproxy.gmail.com with SMTP id 8so211618nzo for ; Wed, 18 May 2005 08:55:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uOfq1AobFJDdj3khrryaBkIxBRIX87TVGVHOpjve9PwXOIo8rRxUR/8SjTjdETF9+TwgfH2OV4MrEOmL3JE0HLs/gNsUpD7MNEfXHzx7Oyv1/e3sU2Srft4vqEePydr8AVtYEK+l4REdCfqx7qYG+zr5FrM4qVZVDbRwGS7TN9U= Received: by 10.36.23.8 with SMTP id 8mr168376nzw; Wed, 18 May 2005 08:55:40 -0700 (PDT) Received: by 10.36.65.5 with HTTP; Wed, 18 May 2005 08:55:39 -0700 (PDT) Message-ID: <5fc59ff305051808558f1ce59@mail.gmail.com> Date: Wed, 18 May 2005 08:55:39 -0700 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: Andrew Morton Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 Cc: Christoph Lameter , davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shai@scalex86.org In-Reply-To: <20050517215845.2f87be2f.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050517190343.2e57fdd7.akpm@osdl.org> <20050517.195703.104034854.davem@davemloft.net> <20050517215845.2f87be2f.akpm@osdl.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4IFuIF3009410 X-archive-position: 1310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 474 Lines: 14 On 5/17/05, Andrew Morton wrote: > I think the e1000 driver is being a bit insane there. I figure that Do you mean insane to use vmalloc? > sizeof(struct e1000_buffer) is 28 on 64-bit, so even with 4k pagesize we'll > always succeed in being able to support a 32k/32 = 1024-entry Tx ring. > > Is there any real-world reason for wanting larger ring sizes than that? > > We have had cases where allocation of 32K of memory (via kmalloc) fails. ganesh. From rick.jones2@hp.com Wed May 18 09:21:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 09:22:02 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IGLnF3012769 for ; Wed, 18 May 2005 09:21:49 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id 706F3C9DC for ; Wed, 18 May 2005 09:21:07 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id JAA14205 for ; Wed, 18 May 2005 09:21:06 -0700 (PDT) Message-ID: <428B6B72.5010407@hp.com> Date: Wed, 18 May 2005 09:21:06 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> <20050518011632.GA27813@gondor.apana.org.au> <20050518013712.GH13748@postel.suug.ch> In-Reply-To: <20050518013712.GH13748@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 857 Lines: 17 If we ass-u-me that the sender is indeed using a random IP ID assignment mechanism, 30000 is probably too many. There are only 65536 possible ID's, and if we "choose" 30000 of them there will undoubtedly be many duplicated. Someone who didn't fall asleep too often in ProbStats (unlike myself) can probably tell us just how many. Also, I think the count has to be _any_ IP datagram on that src/dst pair, fragmented or not. Someone else pointed-out the possiblity of sending use one fragmetned datagram, then 64K to someone else - well, those 64K to someone else could just as easily be 64K non-fragmented IP datagrams to us, so it seems for a measure of "out of orderness liklihood" we need to include non-fragmented IP datagrams. The thought of having to do added accounting on a non-fragmented datagram seems unpleasant though. rick jones From chrisw@osdl.org Wed May 18 10:01:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 10:01:37 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IH1XF3015212 for ; Wed, 18 May 2005 10:01:33 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4IH0aU3022700 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 May 2005 10:00:41 -0700 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4IH0XXh007177; Wed, 18 May 2005 10:00:33 -0700 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j4IH0Xj9007176; Wed, 18 May 2005 10:00:33 -0700 Date: Wed, 18 May 2005 10:00:33 -0700 From: Chris Wright To: Herbert Xu Cc: "David S. Miller" , Linux Audit Discussion , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Chris Wright Subject: Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502 Message-ID: <20050518170033.GT27549@shell0.pdx.osdl.net> References: <200505171624.j4HGOQwo017312@turing-police.cc.vt.edu> <20050517165528.GB27549@shell0.pdx.osdl.net> <1116349464.23972.118.camel@hades.cambridge.redhat.com> <20050517174300.GE27549@shell0.pdx.osdl.net> <20050518083002.GA30689@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518083002.GA30689@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 862 Lines: 22 * Herbert Xu (herbert@gondor.apana.org.au) wrote: > Guys, please CC netdev on issues like this. Sorry Herbert, we hadn't yet concluded that it's not an issue that we need to resolve within audit. > On Tue, May 17, 2005 at 05:43:00PM +0000, Chris Wright wrote: > > > > This has some issues w.r.t. truesize and socket buffer space. The trim > > is done to keep accounting sane, so we'd either have to trim ourselves > > or take into account the change in size. And ultimately, we'd still get > > trimmed by netlink, so the GFP issue is still there. Ideally, gfp_any() > > would really be _any_ > > The trimming is completely optional. That is, if the allocation fails > nothing bad will happen. So the solution is to simply use GFP_ATOMIC. Well, it does more pressure on atomic pool (for those cases that GFP_KERNEL would have sufficed). thanks, -chris From tgraf@suug.ch Wed May 18 10:40:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 10:40:44 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IHeTF3017713 for ; Wed, 18 May 2005 10:40:29 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 613F41C0EB; Wed, 18 May 2005 19:40:10 +0200 (CEST) Date: Wed, 18 May 2005 19:40:10 +0200 From: Thomas Graf To: Rick Jones Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518174010.GC15391@postel.suug.ch> References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> <20050518011632.GA27813@gondor.apana.org.au> <20050518013712.GH13748@postel.suug.ch> <428B6B72.5010407@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428B6B72.5010407@hp.com> X-archive-position: 1313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2522 Lines: 45 * Rick Jones <428B6B72.5010407@hp.com> 2005-05-18 09:21 > If we ass-u-me that the sender is indeed using a random IP ID assignment > mechanism, 30000 is probably too many. There are only 65536 possible ID's, > and if we "choose" 30000 of them there will undoubtedly be many duplicated. > Someone who didn't fall asleep too often in ProbStats (unlike myself) can > probably tell us just how many. I can't come up with a specific number but some thoughts, the upper limit of the number can be described as a probability of the complete id space := P_id_space * P_visible ...where P_id_space := size of effective id space, 1.0 for counters, 0.9-1.0 for good random schemes. P_visible := how many fragments do we actually see of the effective id space, can be described as P_loss + P_scope P_loss := probability of lost fragment-ids P_scope := probability of complete view over P_visible, 1.0 if we're the only receiver, decreases with every additional host we share the sender's id space with. Also depends on the ration every receiver sees. P_id_space and P_loss can be disregarded but P_scope is hard to determine, the value can range from nearly zero to 1.0 so we can be optimistic and chose 0.5 or be paranoid and define it as a very small value. But what is small? F.e. 0.1 would give us a value around 6K which is nothing on a gbit link at 40kpps on average. I think there isn't even a big difference between 3K and 30K, both border cases we're worrying about can happen with both limits. In a perfect world without any randomly generated ids we could measure the absolute distance even without being aware of all ids, it might even be possible to try and differ between random and serial id sequences and optimize a bit there but in the end we have to find a good compromise for the random case anyway. Worth some experimentation I guess. > Also, I think the count has to be _any_ IP datagram on that src/dst pair, > fragmented or not. Someone else pointed-out the possiblity of sending use > one fragmetned datagram, then 64K to someone else - well, those 64K to > someone else could just as easily be 64K non-fragmented IP datagrams to us, > so it seems for a measure of "out of orderness liklihood" we need to > include non-fragmented IP datagrams. Sure, I took herbert's "fragments" as "fragment ids", i.e. the per fragment counter being the distance of different ids between the arrival of the fragment and the current position. From linville@bilbo.tuxdriver.com Wed May 18 10:42:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 10:42:34 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IHgJF3018076 for ; Wed, 18 May 2005 10:42:20 -0700 Received: from bilbo.tuxdriver.com (azure.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j4IHYbl29181; Wed, 18 May 2005 13:34:37 -0400 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j4IHfcsO021652; Wed, 18 May 2005 13:41:38 -0400 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j4IHfXiw021651; Wed, 18 May 2005 13:41:33 -0400 Date: Wed, 18 May 2005 13:41:33 -0400 From: "John W. Linville" To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, Clear.Zhang@uli.com.tw Subject: [patch 2.6.12-rc4 1/1] tulip: add return to ULI526X clause in tulip_mdio_write Message-ID: <20050518174132.GB16148@tuxdriver.com> Mail-Followup-To: netdev@oss.sgi.com, jgarzik@pobox.com, Clear.Zhang@uli.com.tw Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 1314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 944 Lines: 27 The 'if' clause for ULI526X in tulip_mdio_write allows for spin_unlock_irqrestore to be called twice for tp->mii_lock. I believe this is caused by the unintentional omission of a return at the end of that clause. This patch adds that return. Signed-off-by: John W. Linville --- I'm copying Clear Zhang on this. As the author of the patch that added this code, he should know whether or not my intuitive fix is actually correct... :-) drivers/net/tulip/media.c | 1 + 1 files changed, 1 insertion(+) --- linux-2.6.12-rc4/drivers/net/tulip/media.c.orig 2005-05-18 09:19:07.392564077 -0400 +++ linux-2.6.12-rc4/drivers/net/tulip/media.c 2005-05-18 09:22:47.107779100 -0400 @@ -174,6 +174,7 @@ void tulip_mdio_write(struct net_device break; } spin_unlock_irqrestore(&tp->mii_lock, flags); + return; } /* Establish sync by sending 32 logic ones. */ -- John W. Linville linville@tuxdriver.com From tgraf@suug.ch Wed May 18 10:45:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 10:45:24 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IHj9F3018946 for ; Wed, 18 May 2005 10:45:09 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 1207C1C0EB; Wed, 18 May 2005 19:44:55 +0200 (CEST) Date: Wed, 18 May 2005 19:44:54 +0200 From: Thomas Graf To: Rick Jones Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518174454.GD15391@postel.suug.ch> References: <20050517.104947.112621738.davem@davemloft.net> <20050518004733.GG13748@postel.suug.ch> <20050518011632.GA27813@gondor.apana.org.au> <20050518013712.GH13748@postel.suug.ch> <428B6B72.5010407@hp.com> <20050518174010.GC15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518174010.GC15391@postel.suug.ch> X-archive-position: 1315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 691 Lines: 11 * Thomas Graf <20050518174010.GC15391@postel.suug.ch> 2005-05-18 19:40 > In a perfect world without any randomly generated ids we could measure > the absolute distance even without being aware of all ids, it might even > be possible to try and differ between random and serial id sequences > and optimize a bit there but in the end we have to find a good > compromise for the random case anyway. Worth some experimentation I guess. Wild thought: We could introduce a new ip option stating that the id generator uses a serial approach which would give us the possibility to measure the absolute distance and resolve this issue in a perfect matter for everyone supporting this extension. ;-> From SRS0+224abbb4b9fa37477667+633+infradead.org+dwmw2@pentafluge.srs.infradead.org Wed May 18 10:55:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 10:55:46 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IHtUF3019730 for ; Wed, 18 May 2005 10:55:31 -0700 Received: from mobileweb08.london.02.net ([193.113.235.174] helo=[10.249.174.60]) by pentafluge.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1DYSkj-0007O1-Bj; Wed, 18 May 2005 18:54:44 +0100 Subject: Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502 From: David Woodhouse To: Linux Audit Discussion Cc: Herbert Xu , netdev@oss.sgi.com, "David S. Miller" , linux-kernel@vger.kernel.org In-Reply-To: <20050518170033.GT27549@shell0.pdx.osdl.net> References: <200505171624.j4HGOQwo017312@turing-police.cc.vt.edu> <20050517165528.GB27549@shell0.pdx.osdl.net> <1116349464.23972.118.camel@hades.cambridge.redhat.com> <20050517174300.GE27549@shell0.pdx.osdl.net> <20050518083002.GA30689@gondor.apana.org.au> <20050518170033.GT27549@shell0.pdx.osdl.net> Content-Type: text/plain Date: Wed, 18 May 2005 18:52:35 +0100 Message-Id: <1116438756.25594.76.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 1316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 911 Lines: 22 On Wed, 2005-05-18 at 10:00 -0700, Chris Wright wrote: > * Herbert Xu (herbert@gondor.apana.org.au) wrote: > > Guys, please CC netdev on issues like this. > > Sorry Herbert, we hadn't yet concluded that it's not an issue that we > need to resolve within audit. I suspect that it _is_ an issue we can resolve entirely within audit code. See the patch I posted half an hour or so ago to the linux-audit list. If we agree on that approach, I'll do the equivalent for the git tree either later this evening or tomorrow. I've reverted your recent change to put audit messages directly into skbs "in order to eliminate the extra copy", on the basis that it blatantly wasn't having that effect anyway. Now we copy from the audit_buffer into an optimally-sized skb which netlink_trim() won't have to mangle. I've also removed the skb_get() immediately before netlink_send() which always made me unhappy. -- dwmw2 From davem@davemloft.net Wed May 18 12:57:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 12:58:03 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IJvqF3029263 for ; Wed, 18 May 2005 12:57:53 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYUfF-000292-Kg; Wed, 18 May 2005 12:57:09 -0700 Date: Wed, 18 May 2005 12:57:09 -0700 (PDT) Message-Id: <20050518.125709.112621421.davem@davemloft.net> To: ak@muc.de Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO From: "David S. Miller" In-Reply-To: References: <20050517.192416.108741581.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 652 Lines: 17 From: Andi Kleen Date: Wed, 18 May 2005 15:43:21 +0200 > > @@ -674,59 +653,274 @@ unsigned int tcp_sync_mss(struct sock *s > > * cannot be large. However, taking into account rare use of URG, this > > * is not a big flaw. > > */ > > +static inline u32 compute_xmit_cache(u32 mss, int sacks, int tso_enabled) > > +{ > > + u32 ret = (mss << 16) | sacks; > > 16bit MSS? How does that deal with jumbopackets on IPv6? > While the MSS option is also 16bit it is legal to construct bigger > datagrams when no MSS option was exchanged. It doesn't, and neither does the existing code. I know it needs to be fixed, thanks for reminding me. From akpm@osdl.org Wed May 18 13:43:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 13:43:52 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IKhjF3032423 for ; Wed, 18 May 2005 13:43:45 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4IKg3U3008288 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 May 2005 13:42:04 -0700 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4IKg3Wu017668; Wed, 18 May 2005 13:42:03 -0700 Date: Wed, 18 May 2005 13:42:50 -0700 From: Andrew Morton To: Ganesh Venkatesan Cc: christoph@lameter.com, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shai@scalex86.org Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 Message-Id: <20050518134250.3ee2703f.akpm@osdl.org> In-Reply-To: <5fc59ff305051808558f1ce59@mail.gmail.com> References: <20050517190343.2e57fdd7.akpm@osdl.org> <20050517.195703.104034854.davem@davemloft.net> <20050517215845.2f87be2f.akpm@osdl.org> <5fc59ff305051808558f1ce59@mail.gmail.com> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 727 Lines: 18 Ganesh Venkatesan wrote: > > On 5/17/05, Andrew Morton wrote: > > I think the e1000 driver is being a bit insane there. I figure that > Do you mean insane to use vmalloc? > > > sizeof(struct e1000_buffer) is 28 on 64-bit, so even with 4k pagesize we'll > > always succeed in being able to support a 32k/32 = 1024-entry Tx ring. > > > > Is there any real-world reason for wanting larger ring sizes than that? > > > > > We have had cases where allocation of 32K of memory (via kmalloc) fails. > Are you sure? The current page allocator will infinitely loop until success for <=32k GFP_KERNEL allocations - the only way it can fail is if the calling process gets oom-killed. From herbert@gondor.apana.org.au Wed May 18 14:30:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 14:31:05 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ILUkF3003697 for ; Wed, 18 May 2005 14:30:47 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYW6w-000661-00; Thu, 19 May 2005 07:29:50 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYW6t-0005GV-00; Thu, 19 May 2005 07:29:47 +1000 Date: Thu, 19 May 2005 07:29:47 +1000 To: David Woodhouse Cc: Linux Audit Discussion , netdev@oss.sgi.com, "David S. Miller" , linux-kernel@vger.kernel.org Subject: Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502 Message-ID: <20050518212947.GA20204@gondor.apana.org.au> References: <200505171624.j4HGOQwo017312@turing-police.cc.vt.edu> <20050517165528.GB27549@shell0.pdx.osdl.net> <1116349464.23972.118.camel@hades.cambridge.redhat.com> <20050517174300.GE27549@shell0.pdx.osdl.net> <20050518083002.GA30689@gondor.apana.org.au> <20050518170033.GT27549@shell0.pdx.osdl.net> <1116438756.25594.76.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116438756.25594.76.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 907 Lines: 21 On Wed, May 18, 2005 at 06:52:35PM +0100, David Woodhouse wrote: > > I've reverted your recent change to put audit messages directly into > skbs "in order to eliminate the extra copy", on the basis that it > blatantly wasn't having that effect anyway. Now we copy from the > audit_buffer into an optimally-sized skb which netlink_trim() won't have > to mangle. I've also removed the skb_get() immediately before > netlink_send() which always made me unhappy. Even if the audit code is never going to call netlink_unicast with spin locks held, we simply cannot assume that for all current and future users of netlink_unicast. As a consequence we can't use gfp_any() in netlink_unicast. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Wed May 18 14:46:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 14:46:23 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ILkDF3005194 for ; Wed, 18 May 2005 14:46:14 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYWM4-0006RA-00; Thu, 19 May 2005 07:45:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYWM2-0004jM-00; Thu, 19 May 2005 07:45:26 +1000 From: Herbert Xu To: rick.jones2@hp.com (Rick Jones) Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <428B6B72.5010407@hp.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 19 May 2005 07:45:26 +1000 X-archive-position: 1321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1359 Lines: 26 Rick Jones wrote: > If we ass-u-me that the sender is indeed using a random IP ID assignment > mechanism, 30000 is probably too many. There are only 65536 possible ID's, and > if we "choose" 30000 of them there will undoubtedly be many duplicated. Someone > who didn't fall asleep too often in ProbStats (unlike myself) can probably tell > us just how many. IMHO hosts using purely random IDs all the time are fundamentally broken for applications such as NFS over UDP over gigabit. However, in order to handle such hosts we should make this threshold configurable and then those who need it can set it to a value like 600 which gives a collision probability with the first fragment of just less than 1%. > Also, I think the count has to be _any_ IP datagram on that src/dst pair, > fragmented or not. Someone else pointed-out the possiblity of sending use one You might be there. However, we should keep in mind that we're not trying to come up with a perfect solution to the IP fragmentation problem. All we need is something that's good enough to deal with usages similar to NFS over UDP over gigabit. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Wed May 18 14:47:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 14:47:57 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ILloF3005411 for ; Wed, 18 May 2005 14:47:51 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYWNV-0006Rp-00; Thu, 19 May 2005 07:46:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYWNS-0004ju-00; Thu, 19 May 2005 07:46:54 +1000 From: Herbert Xu To: tgraf@suug.ch (Thomas Graf) Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Cc: rick.jones2@hp.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050518174454.GD15391@postel.suug.ch> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 19 May 2005 07:46:54 +1000 X-archive-position: 1322 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 641 Lines: 14 Thomas Graf wrote: > > Wild thought: We could introduce a new ip option stating that the id > generator uses a serial approach which would give us the possibility > to measure the absolute distance and resolve this issue in a perfect > matter for everyone supporting this extension. ;-> Well Linux does that anyway (apart from Suse) so all we need to do is to tell everyone doing NFS over gigabit to use Linux :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From satkinson@motorola.com Wed May 18 14:56:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 14:56:24 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ILuLF3006332 for ; Wed, 18 May 2005 14:56:21 -0700 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j4IM5UUv028776 for ; Wed, 18 May 2005 15:05:30 -0700 (MST) Received: from il06exm11.corp.mot.com (il06exm11.corp.mot.com [10.0.111.11]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j4ILwO5i019776 for ; Wed, 18 May 2005 16:58:30 -0500 (CDT) Received: by il06exm11 with Internet Mail Service (5.5.2657.72) id ; Wed, 18 May 2005 16:55:38 -0500 Message-ID: <5D454811D0A1D711A12A00065BF36FAD14D99A36@il06exm11> From: Atkinson Stephen-G19998 To: netdev@oss.sgi.com Subject: ETH_P_ALL and "NIT" Date: Wed, 18 May 2005 16:55:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-archive-position: 1323 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: satkinson@motorola.com Precedence: bulk X-list: netdev Content-Length: 776 Lines: 17 I would like to be able to receive all packets (regardless of type) on a given net_device. It seems the way to do this would be to use ETH_P_ALL however, ETH_P_ALL has two meanings, 1) receive all packets and 2) behave as a "NIT" (Network Interface Tap?). The NIT functionality causes packets transmitted on the net_device in question to be "received" by the ETH_P_ALL socket, unless the packet was sent by that socket. I have a need to receive all incoming packets on a net_device however, for my needs receiving transmitted packets is an undesirable side effect. So, I'd like to propose a new ethernet type (ETH_P_ALL_NO_NIT perhaps) which would behave like ETH_P_ALL without NIT. Comments? Does this sound reasonable? If so I'll submit a patch. Thanks, steve atkinson From buytenh@wantstofly.org Wed May 18 15:14:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 15:14:51 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IMEhF3007587 for ; Wed, 18 May 2005 15:14:48 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 435E6945D7; Thu, 19 May 2005 00:14:02 +0200 (MEST) Date: Thu, 19 May 2005 00:14:02 +0200 From: Lennert Buytenhek To: netdev@oss.sgi.com Subject: igmp snooping? Message-ID: <20050518221401.GA11148@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 1324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 826 Lines: 24 Hi, Is someone working on igmp snooping (and/or active discovery) for bridging yet? I currently have a need for this, so if noone is working on it yet, I'll probably give it a go myself. AFAICS, for the kernel part: - Add capability to add/modify/delete multicast (ethernet) addresses in the forwarding database. Each multicast fdb entry contains a port bitmask of ports that are interested in this address. - Lookup multicast addresses in the forwarding path, instead of flooding every packet. - Policy decision on whether to drop or flood traffic for multicast addresses that have no corresponding fdb entry. - Add capability for userland to 'steal' IGMP packets. (I.e. to be able to prevent them from being forwarded.) And some userspace daemon that implements the necessary bits. Ideas? cheers, Lennert From dlstevens@us.ibm.com Wed May 18 15:25:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 15:25:55 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IMPhF3008402; Wed, 18 May 2005 15:25:50 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4IMP0LK535214; Wed, 18 May 2005 18:25:00 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4IMOxrR188804; Wed, 18 May 2005 16:24:59 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4IMOxcM004576; Wed, 18 May 2005 16:24:59 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4IMOxBh004568; Wed, 18 May 2005 16:24:59 -0600 In-Reply-To: To: Herbert Xu Cc: netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, rick.jones2@hp.com, tgraf@suug.ch (Thomas Graf) MIME-Version: 1.0 Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 18 May 2005 15:24:57 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 05/18/2005 16:24:58, Serialize complete at 05/18/2005 16:24:58 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 1325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 978 Lines: 22 netdev-bounce@oss.sgi.com wrote on 05/18/2005 02:46:54 PM: > Thomas Graf wrote: > > > > Wild thought: We could introduce a new ip option stating that the id > > generator uses a serial approach which would give us the possibility > > to measure the absolute distance and resolve this issue in a perfect > > matter for everyone supporting this extension. ;-> > Well Linux does that anyway (apart from Suse) so all we need to do > is to tell everyone doing NFS over gigabit to use Linux :) If you're going to add an IP option, you can eliminate the problem entirely. Just add an "extended IP ID" IP option and give it as many bits as you want-- make that the high order of an n+16-bit IP ID. The IP timestamp option, if done per frag and required to be the same for all frags, could be used in this way, since you presumably won't wrap without incrementing that by at least 1. :-) +-DLS From niv@us.ibm.com Wed May 18 15:39:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 15:39:48 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4IMddF3009333; Wed, 18 May 2005 15:39:46 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4IMd2cu162602; Wed, 18 May 2005 18:39:02 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4IMd21o016894; Wed, 18 May 2005 16:39:02 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4IMd1Oc001515; Wed, 18 May 2005 16:39:01 -0600 Received: from [9.47.15.69] (dyn9047015069.beaverton.ibm.com [9.47.15.69]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4IMd0Cb001466; Wed, 18 May 2005 16:39:00 -0600 Message-ID: <428BC404.7000404@us.ibm.com> Date: Wed, 18 May 2005 15:39:00 -0700 From: Nivedita Singhvi User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Stevens CC: Herbert Xu , netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, rick.jones2@hp.com, Thomas Graf Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1154 Lines: 32 David Stevens wrote: > netdev-bounce@oss.sgi.com wrote on 05/18/2005 02:46:54 PM: > > >>Thomas Graf wrote: >> >>>Wild thought: We could introduce a new ip option stating that the id >>>generator uses a serial approach which would give us the possibility >>>to measure the absolute distance and resolve this issue in a perfect >>>matter for everyone supporting this extension. ;-> > > >>Well Linux does that anyway (apart from Suse) so all we need to do >>is to tell everyone doing NFS over gigabit to use Linux :) > > > If you're going to add an IP option, you can eliminate the > problem entirely. Just add an "extended IP ID" IP option and give > it as many bits as you want-- make that the high order of an n+16-bit > IP ID. > The IP timestamp option, if done per frag and required to be > the same for all frags, could be used in this way, since you > presumably won't wrap without incrementing that by at least 1. :-) > > +-DLS Whatever happened to UDP Path MTU? While we're at this, can't we start kicking some path-MTU-broken butt? thanks, Nivedita From tgraf@suug.ch Wed May 18 16:31:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 16:31:45 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4INVXF3015288; Wed, 18 May 2005 16:31:35 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id E0D4E1C0EB; Thu, 19 May 2005 01:31:13 +0200 (CEST) Date: Thu, 19 May 2005 01:31:13 +0200 From: Thomas Graf To: David Stevens Cc: Herbert Xu , netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, rick.jones2@hp.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050518233113.GG15391@postel.suug.ch> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 1327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 417 Lines: 8 * David Stevens 2005-05-18 15:24 > If you're going to add an IP option, you can eliminate the > problem entirely. Just add an "extended IP ID" IP option and give > it as many bits as you want-- make that the high order of an n+16-bit > IP ID. I was thinking of something more nasty such as using as value for this flag (IP_DF|IP_MF) ;-> From jdmason@us.ibm.com Wed May 18 16:54:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 16:54:21 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4INs8F3016545 for ; Wed, 18 May 2005 16:54:17 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4INrVua299008 for ; Wed, 18 May 2005 19:53:31 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4INrV1o088888 for ; Wed, 18 May 2005 17:53:31 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4INrVFS002916 for ; Wed, 18 May 2005 17:53:31 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4INrVBr002913; Wed, 18 May 2005 17:53:31 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id j4INrUdq042832; Wed, 18 May 2005 18:53:30 -0500 Received: from dreadnought (dreadnought.austin.ibm.com [9.53.90.32]) by popmail.austin.ibm.com (AIX5.1/8.11.6p2/8.9.3) with SMTP id j4INrTU93862; Wed, 18 May 2005 18:53:29 -0500 Received: by dreadnought (sSMTP sendmail emulation); Wed, 18 May 2005 18:53:29 -0500 Date: Wed, 18 May 2005 18:53:29 -0500 From: Jon Mason To: shemminger@osdl.org Cc: netdev@oss.sgi.com Subject: [PATCH] Ethernet Bridging: Enable Hardware Checksumming Message-ID: <20050518235329.GA17946@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i X-archive-position: 1328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1026 Lines: 23 Currently, locally generated ethernet traffic does not take advantage of hardware checksum offload when acting as a child device under a bridge device. This is because the upper layers do not see the available features of the child devices only the features of the bridge device (which is empty). There is an easy solution for this (see patch below), include hardware checksum and scatter gather as features of the bridge device. In the case that the physical ethernet device does not support scatter gather or hardware checksum, dev_queue_xmit() will check the dev->features and do the necessary linearization and calculate the checksum. Signed-off-by: Jon Mason --- net/bridge/br_device.c.orig 2005-05-13 11:23:02.552751024 -0500 +++ net/bridge/br_device.c 2005-05-13 11:25:39.155943720 -0500 @@ -101,4 +101,5 @@ void br_dev_setup(struct net_device *dev dev->tx_queue_len = 0; dev->set_mac_address = NULL; dev->priv_flags = IFF_EBRIDGE; + dev->features = NETIF_F_HW_CSUM | NETIF_F_SG; } From niv@us.ibm.com Wed May 18 17:04:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 17:04:39 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J04QF3017325 for ; Wed, 18 May 2005 17:04:33 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4J03nLK598734 for ; Wed, 18 May 2005 20:03:49 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4J03nrR123926 for ; Wed, 18 May 2005 18:03:49 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4J03n0u012305 for ; Wed, 18 May 2005 18:03:49 -0600 Received: from [9.65.8.68] (sig-9-65-8-68.mts.ibm.com [9.65.8.68]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4J03mu6012276; Wed, 18 May 2005 18:03:48 -0600 Message-ID: <428BD7E7.5080207@us.ibm.com> Date: Wed, 18 May 2005 17:03:51 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Mason CC: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming References: <20050518235329.GA17946@us.ibm.com> In-Reply-To: <20050518235329.GA17946@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1333 Lines: 37 Jon Mason wrote: > Currently, locally generated ethernet traffic does not take advantage of > hardware checksum offload when acting as a child device under a bridge > device. This is because the upper layers do not see the available > features of the child devices only the features of the bridge device > (which is empty). > > There is an easy solution for this (see patch below), include hardware > checksum and scatter gather as features of the bridge device. In the > case that the physical ethernet device does not support scatter > gather or hardware checksum, dev_queue_xmit() will check the > dev->features and do the necessary linearization and calculate the > checksum. > > Signed-off-by: Jon Mason > > --- net/bridge/br_device.c.orig 2005-05-13 11:23:02.552751024 -0500 > +++ net/bridge/br_device.c 2005-05-13 11:25:39.155943720 -0500 > @@ -101,4 +101,5 @@ void br_dev_setup(struct net_device *dev > dev->tx_queue_len = 0; > dev->set_mac_address = NULL; > dev->priv_flags = IFF_EBRIDGE; > + dev->features = NETIF_F_HW_CSUM | NETIF_F_SG; > } Stephen, I think this is a good thing to have, gives us performance gain (equivalent to using/not using checksum offload) and has very little impact on the bridging layer, and is independent of the virtualization stuff.. thanks, Nivedita From hadi@cyberus.ca Wed May 18 17:36:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 17:37:01 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J0anF3018911 for ; Wed, 18 May 2005 17:36:49 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DYZ1F-000633-Ji for netdev@oss.sgi.com; Wed, 18 May 2005 18:36:09 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DYZ1L-0006Hv-0W; Wed, 18 May 2005 20:36:15 -0400 Subject: patch: small fixup From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev Content-Type: multipart/mixed; boundary="=-dgQoTPmSywBqbDRi7eEX" Organization: unknown Date: Wed, 18 May 2005 20:36:10 -0400 Message-Id: <1116462970.6240.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 1330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1086 Lines: 43 --=-dgQoTPmSywBqbDRi7eEX Content-Type: text/plain Content-Transfer-Encoding: 7bit My first git patch (dangerously knowledgeable after 30 minutes of snorting blobs;->) against net-2.6.git. Consider this an excuse to send a git patch ;-> -- Fixup simple action define to be consistent with other net/sched files Signed-off-by: Jamal Hadi Salim cheers, jamal --=-dgQoTPmSywBqbDRi7eEX Content-Disposition: attachment; filename=act_g.p Content-Type: text/x-pascal; name=act_g.p; charset=UTF-8 Content-Transfer-Encoding: 7bit include/net/act_generic.h: needs update Index: include/net/act_generic.h =================================================================== --- 999772bc591650ab8b58d2c7a225ae83ecb6697f/include/net/act_generic.h (mode:100644) +++ uncommitted/include/net/act_generic.h (mode:100644) @@ -2,8 +2,8 @@ * include/net/act_generic.h * */ -#ifndef ACT_GENERIC_H -#define ACT_GENERIC_H +#ifndef _NET_ACT_GENERIC_H +#define _NET_ACT_GENERIC_H static inline int tcf_defact_release(struct tcf_defact *p, int bind) { int ret = 0; --=-dgQoTPmSywBqbDRi7eEX-- From hadi@cyberus.ca Wed May 18 18:11:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 18:11:55 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J1BfF3020986 for ; Wed, 18 May 2005 18:11:41 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DYZZ6-0007zS-NP for netdev@oss.sgi.com; Wed, 18 May 2005 21:11:08 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DYZZ2-0004ns-N9; Wed, 18 May 2005 21:11:04 -0400 Subject: Re: igmp snooping? From: jamal Reply-To: hadi@cyberus.ca To: Lennert Buytenhek Cc: netdev@oss.sgi.com In-Reply-To: <20050518221401.GA11148@xi.wantstofly.org> References: <20050518221401.GA11148@xi.wantstofly.org> Content-Type: text/plain Organization: unknown Date: Wed, 18 May 2005 21:10:59 -0400 Message-Id: <1116465059.6240.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1860 Lines: 54 On Thu, 2005-19-05 at 00:14 +0200, Lennert Buytenhek wrote: > Hi, > > Is someone working on igmp snooping (and/or active discovery) for > bridging yet? I currently have a need for this, so if noone is > working on it yet, I'll probably give it a go myself. > Not that i know of - someone else may. > AFAICS, for the kernel part: > - Add capability to add/modify/delete multicast (ethernet) addresses > in the forwarding database. Each multicast fdb entry contains a port > bitmask of ports that are interested in this address. You would probably also need to do a SIOCADDMULTI for those ports - unless bridging puts all those ports in promisc mode. If it doesnt go promisc, you _may_ also need to worry about boundary conditions when the tiny physical devices hardware multicast entries start overflowing. > - Lookup multicast addresses in the forwarding path, instead of flooding > every packet. > - Policy decision on whether to drop or flood traffic for multicast > addresses that have no corresponding fdb entry. Make this configurable. i.e flood on miss, drop on miss, pass to user space(daemon if one exists) on a miss. > - Add capability for userland to 'steal' IGMP packets. (I.e. to be able > to prevent them from being forwarded.) > That would be the the last policy above. I think you will also need to have something that just listens to the different IGMP variants (maybe a packet socket with a pcap filter). The nice thing about pcap (in mmaped format) is it will tell you about the ifindex of port it arrived on. > And some userspace daemon that implements the necessary bits. > > Ideas? > Above. Also take note of: http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-12.txt Many years of experience there on snooping IGMP. I think your most exciting challenge would be snooping IGMPv3 ;-> cheers, jamal From hadi@cyberus.ca Wed May 18 18:24:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 18:24:43 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J1OZF3022140 for ; Wed, 18 May 2005 18:24:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DYZlV-0006RK-3L for netdev@oss.sgi.com; Wed, 18 May 2005 21:23:57 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DYZlP-00076C-UX; Wed, 18 May 2005 21:23:52 -0400 Subject: another git excuse patch From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: netdev , "David S. Miller" Content-Type: multipart/mixed; boundary="=-OeXu7fNqfFdekE+h/zBq" Organization: unknown Date: Wed, 18 May 2005 21:23:45 -0400 Message-Id: <1116465825.6240.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 1332 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1056 Lines: 40 --=-OeXu7fNqfFdekE+h/zBq Content-Type: text/plain Content-Transfer-Encoding: 7bit Against Herbert's ipsec-2.6.git. Small fixup to use netlink macros instead of hardcoding. Signed-off-by: Jamal Hadi Salim cheers, jamal --=-OeXu7fNqfFdekE+h/zBq Content-Disposition: attachment; filename=ipsec12_p Content-Type: text/plain; name=ipsec12_p; charset=UTF-8 Content-Transfer-Encoding: 7bit net/xfrm/xfrm_user.c: needs update Index: net/xfrm/xfrm_user.c =================================================================== --- c24f26cfe03081d10a3a3f66d5d3e503395090b4/net/xfrm/xfrm_user.c (mode:100644) +++ uncommitted/net/xfrm/xfrm_user.c (mode:100644) @@ -1114,9 +1114,9 @@ static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c) { struct sk_buff *skb; + int len = NLMSG_LENGTH(sizeof(struct xfrm_user_expire)); - /* fix to do alloc using NLM macros */ - skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC); + skb = alloc_skb(len, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; --=-OeXu7fNqfFdekE+h/zBq-- From herbert@gondor.apana.org.au Wed May 18 18:29:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 18:29:17 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J1TCF3022707 for ; Wed, 18 May 2005 18:29:13 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYZpo-0007qN-00; Thu, 19 May 2005 11:28:24 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYZpm-00055K-00; Thu, 19 May 2005 11:28:22 +1000 Date: Thu, 19 May 2005 11:28:22 +1000 To: jamal Cc: netdev , "David S. Miller" Subject: Re: another git excuse patch Message-ID: <20050519012822.GA19536@gondor.apana.org.au> References: <1116465825.6240.27.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116465825.6240.27.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 439 Lines: 13 On Wed, May 18, 2005 at 09:23:45PM -0400, jamal wrote: > > Against Herbert's ipsec-2.6.git. > > Small fixup to use netlink macros instead of hardcoding. > Signed-off-by: Jamal Hadi Salim Thanks, I'll add it to my collection. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dlstevens@us.ibm.com Wed May 18 18:44:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 18:45:02 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J1irF3023728 for ; Wed, 18 May 2005 18:44:53 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4J1iC0c150344 for ; Wed, 18 May 2005 21:44:12 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4J1iBrR105272 for ; Wed, 18 May 2005 19:44:11 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4J1iBPX025183 for ; Wed, 18 May 2005 19:44:11 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4J1iBdA025178 for ; Wed, 18 May 2005 19:44:11 -0600 In-Reply-To: <1116465059.6240.20.camel@localhost.localdomain> To: hadi@cyberus.ca Cc: Lennert Buytenhek , netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: igmp snooping? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 18 May 2005 18:44:09 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 05/18/2005 19:44:10, Serialize complete at 05/18/2005 19:44:10 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 1334 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1255 Lines: 30 If you put the interface in multicast promiscuous mode (set flag IFF_ALLMULTI), you can receive all hardware groups without joining. For IGMP and MLD packets, one way to do that pat in an application is to create a raw socket and specify the protocol there. So, to receive all reports for any version of IGMP sent to any group, you can create a socket like this: s = socket(PF_INET, SOCK_RAW, IPPROTO_IGMP); For MLDv1 and MLDv2 (IPv6), they are part of ICMPv6, but you can use ICMPV6_FILTER with the MLD report types to receive only those. You can get the receiving interface as ancillary data on a recvmsg() call with the IPV6_PKTINFO socket option on Linux systems (IPV6_RECVPKTINFO when RFC 3542 compliant) for IPv6 and similarly with IP_PKTINFO with IPv4, I believe. You also can get this information by restricting the socket to receiving on a particular interface, if you don't want one socket to handle multiple interfaces. Then, you know which interface by which socket you received on. So, you should be able to do most, possibly all, of what you want at application level without modification to the kernel, if you're looking to do this in an application and not a kernel module. +-DLS From herbert@gondor.apana.org.au Wed May 18 19:03:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 19:03:51 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J23jF3025027 for ; Wed, 18 May 2005 19:03:47 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYaNN-0007zc-00; Thu, 19 May 2005 12:03:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYaNK-0005HT-00; Thu, 19 May 2005 12:03:02 +1000 Date: Thu, 19 May 2005 12:03:02 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPSEC] Fixed alg_key_len usage in attach_one_algo Message-ID: <20050519020302.GA20285@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1431 Lines: 54 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This bug was discovered by a Linux box running in a remote corner of Australia :) The variable alg_key_len is in bits and not bytes. The function attach_one_algo is currently using it as if it were in bytes. This causes it to read memory which may not be there. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-user-1 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -162,6 +162,7 @@ static int attach_one_algo(struct xfrm_a struct rtattr *rta = u_arg; struct xfrm_algo *p, *ualg; struct xfrm_algo_desc *algo; + int len; if (!rta) return 0; @@ -173,11 +174,12 @@ static int attach_one_algo(struct xfrm_a return -ENOSYS; *props = algo->desc.sadb_alg_id; - p = kmalloc(sizeof(*ualg) + ualg->alg_key_len, GFP_KERNEL); + len = sizeof(*ualg) + (ualg->alg_key_len + 7U) / 8; + p = kmalloc(len, GFP_KERNEL); if (!p) return -ENOMEM; - memcpy(p, ualg, sizeof(*ualg) + ualg->alg_key_len); + memcpy(p, ualg, len); *algpp = p; return 0; } --IS0zKkzwUGydFO0o-- From herbert@gondor.apana.org.au Wed May 18 19:15:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 19:15:55 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J2FmF3026323 for ; Wed, 18 May 2005 19:15:49 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYaZ1-000844-00; Thu, 19 May 2005 12:15:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYaYz-0005OB-00; Thu, 19 May 2005 12:15:05 +1000 Date: Thu, 19 May 2005 12:15:05 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPSEC] Verify key payload in verify_one_algo Message-ID: <20050519021505.GA20703@gondor.apana.org.au> References: <20050519020302.GA20285@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <20050519020302.GA20285@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1175 Lines: 50 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: We need to verify that the payload contains enough data so that attach_one_algo can copy alg_key_len bits from the payload. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-user-2 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -34,14 +34,21 @@ static int verify_one_alg(struct rtattr { struct rtattr *rt = xfrma[type - 1]; struct xfrm_algo *algp; + int len; if (!rt) return 0; - if ((rt->rta_len - sizeof(*rt)) < sizeof(*algp)) + len = (rt->rta_len - sizeof(*rt)) - sizeof(*algp); + if (len < 0) return -EINVAL; algp = RTA_DATA(rt); + + len -= (algp->alg_key_len + 7U) / 8; + if (len < 0) + return -EINVAL; + switch (type) { case XFRMA_ALG_AUTH: if (!algp->alg_key_len && --wac7ysb48OaltWcw-- From hadi@cyberus.ca Wed May 18 19:14:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 19:14:34 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J2ENF3026012 for ; Wed, 18 May 2005 19:14:25 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DYaXn-0008Q7-N5 for netdev@oss.sgi.com; Wed, 18 May 2005 22:13:51 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DYaXk-0007iC-OF; Wed, 18 May 2005 22:13:49 -0400 Subject: Re: igmp snooping? From: jamal Reply-To: hadi@cyberus.ca To: David Stevens Cc: Lennert Buytenhek , netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: unknown Date: Wed, 18 May 2005 22:13:43 -0400 Message-Id: <1116468823.6240.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1537 Lines: 39 On Wed, 2005-18-05 at 18:44 -0700, David Stevens wrote: > If you put the interface in multicast promiscuous mode (set flag > IFF_ALLMULTI), > you can receive all hardware groups without joining. > > For IGMP and MLD packets, one way to do that pat in an application is to > create > a raw socket and specify the protocol there. So, to receive all reports > for any version of IGMP sent to any group, you can create a socket like > this: > > s = socket(PF_INET, SOCK_RAW, IPPROTO_IGMP); > > > For MLDv1 and MLDv2 (IPv6), they are part of ICMPv6, but you can use > ICMPV6_FILTER with the MLD report types to receive only those. > > You can get the receiving interface as ancillary data on a recvmsg() > call with the IPV6_PKTINFO socket option on Linux systems > (IPV6_RECVPKTINFO when RFC 3542 compliant) for IPv6 and > similarly with IP_PKTINFO with IPv4, I believe. You also can get this > information by restricting the socket to receiving on a particular > interface, if you don't want one socket to handle multiple interfaces. > Then, you know which interface by which socket you received on. > Better approach than i proposed. > So, you should be able to do most, possibly all, of what you want at > application level without modification to the kernel, if you're looking > to do this in an application and not a kernel module. I think it belongs in user space. I would say its probably time that STP also got moved out. The fact it's in the kernel has hurt addition of interesting new features. cheers, jamal From herbert@gondor.apana.org.au Wed May 18 19:42:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 19:42:15 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J2g8F3027902 for ; Wed, 18 May 2005 19:42:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYayE-0008Fq-00; Thu, 19 May 2005 12:41:11 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYayB-0005Sk-00; Thu, 19 May 2005 12:41:07 +1000 From: Herbert Xu To: jdmason@us.ibm.com (Jon Mason) Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming Cc: shemminger@osdl.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050518235329.GA17946@us.ibm.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 19 May 2005 12:41:07 +1000 X-archive-position: 1338 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 761 Lines: 20 Jon Mason wrote: > > checksum and scatter gather as features of the bridge device. In the > case that the physical ethernet device does not support scatter > gather or hardware checksum, dev_queue_xmit() will check the > dev->features and do the necessary linearization and calculate the > checksum. Unfortunately skb_linearize is a lot more expensive than not generating the non-linear skb's in the first place. So this is going to hurt people using the bridge devices over physical devices that don't support SG. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From akpm@osdl.org Wed May 18 20:26:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 20:26:22 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J3QHF3001039 for ; Wed, 18 May 2005 20:26:17 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4J3PdU3004681 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 18 May 2005 20:25:39 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4J3Pc4R001266 for ; Wed, 18 May 2005 20:25:39 -0700 Date: Wed, 18 May 2005 20:24:58 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: 2.6.12-rc4-mm[12] - ULOG problem Message-Id: <20050518202458.55a63d37.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 687 Lines: 29 This is the second report of this happening. Begin forwarded message: Date: Wed, 18 May 2005 23:10:49 -0400 From: Nick Orlov To: linux-kernel@vger.kernel.org Cc: akpm@osdl.org Subject: 2.6.12-rc4-mm[12] - ULOG problem ipt_ULOG fails to load starting from 2.6.12-rc4-mm1 with the following error message: FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory rc3-mm3 works fine. Unfortunately, I wont have time to do a binary search till the weekend, but I hope you'll point suspicious patch(es) without it. Any additional info available by request. -- With best wishes, Nick Orlov. From herbert@gondor.apana.org.au Wed May 18 21:50:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 21:50:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J4oaF3004388 for ; Wed, 18 May 2005 21:50:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYcyi-0000ME-00; Thu, 19 May 2005 14:49:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYcyg-0005fP-00; Thu, 19 May 2005 14:49:46 +1000 From: Herbert Xu To: akpm@osdl.org (Andrew Morton) Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <20050518202458.55a63d37.akpm@osdl.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 19 May 2005 14:49:46 +1000 X-archive-position: 1340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 504 Lines: 14 Andrew Morton wrote: > > This is the second report of this happening. > > FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory This probably means that someone has stolen the NETLINK_NFLOG id. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Wed May 18 22:01:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 22:01:33 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J51KF3005204 for ; Wed, 18 May 2005 22:01:21 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYd95-0001KD-TG; Wed, 18 May 2005 22:00:31 -0700 Date: Wed, 18 May 2005 22:00:31 -0700 (PDT) Message-Id: <20050518.220031.75189050.davem@davemloft.net> To: niv@us.ibm.com Cc: jdmason@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming From: "David S. Miller" In-Reply-To: <428BD7E7.5080207@us.ibm.com> References: <20050518235329.GA17946@us.ibm.com> <428BD7E7.5080207@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1341 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 423 Lines: 11 From: Nivedita Singhvi Date: Wed, 18 May 2005 17:03:51 -0700 > I think this is a good thing to have, gives us performance > gain (equivalent to using/not using checksum offload) and > has very little impact on the bridging layer, and is > independent of the virtualization stuff.. I agree but keep in mind that when bridging over non-checksumming devices it will be more expensive. Especially for TCP. From imipak@yahoo.com Wed May 18 22:10:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 22:10:38 -0700 (PDT) Received: from web31503.mail.mud.yahoo.com (web31503.mail.mud.yahoo.com [68.142.198.132]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4J5AZF3005967 for ; Wed, 18 May 2005 22:10:36 -0700 Received: (qmail 86593 invoked by uid 60001); 19 May 2005 05:09:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=BTFtW1F4FcRRSOmvFKp2J0ZOAnpYitPyQxhvfw4Q/nJ2Iz7GwhQ0oy+JVu2gpoZ7g8qZszjrlC3cr9BeRqSrmjk1h7AsfzcMC0CozrdDBtw3U5ZtaWpf98l8FuuCOYoM3oAghU28Prb0/nKocgmL4BQ3gI9+ygMfLg8M+6dyYrU= ; Message-ID: <20050519050958.86591.qmail@web31503.mail.mud.yahoo.com> Received: from [67.42.217.221] by web31503.mail.mud.yahoo.com via HTTP; Wed, 18 May 2005 22:09:58 PDT Date: Wed, 18 May 2005 22:09:58 -0700 (PDT) From: Jonathan Day Subject: Re: igmp snooping? To: David Stevens , hadi@cyberus.ca Cc: Lennert Buytenhek , netdev@oss.sgi.com In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imipak@yahoo.com Precedence: bulk X-list: netdev Content-Length: 2848 Lines: 88 The information there is excellent, but I would add one note of caution. IGMPv3 is extensible, and one of the early extensions out there is for privacy and security. (No big surprise, there.) Unless you can guarantee that an IGMPv3 packet will not contain any extensions not directly supported by the underlying system, how much of the information you can snoop on once the packet has been parsed by the kernel is going to be implementation-dependent. Now, in 99.99% of all cases, you're not going to have any significant IGMPv3 traffic, as barely anyone uses it yet and IGMP specifies that the highest common version will be used in a group. Thus, if the group contains IPMPv2 or even IGMPv1 members, none of what I've written is the least bit important. If all the systems are using the same OS, then it also doesn't matter, as anything supported in one will be supported in the others. Any case that is left over is the case where you may need to intercept the traffic prior to it being parsed by the usual IGMP handler in the kernel. Even so, you're still using a userspace application, you'd just want to use one of the pseudo network devices to run a copy of the traffic to your program. So the direst case you could possibly imagine is certainly very doable, and most cases are considerably easier. --- David Stevens wrote: > If you put the interface in multicast promiscuous > mode (set flag > IFF_ALLMULTI), > you can receive all hardware groups without joining. > > For IGMP and MLD packets, one way to do that pat in > an application is to > create > a raw socket and specify the protocol there. So, to > receive all reports > for any version of IGMP sent to any group, you can > create a socket like > this: > > s = socket(PF_INET, SOCK_RAW, IPPROTO_IGMP); > > > For MLDv1 and MLDv2 (IPv6), they are part of ICMPv6, > but you can use > ICMPV6_FILTER with the MLD report types to receive > only those. > > You can get the receiving interface as ancillary > data on a recvmsg() > call with the IPV6_PKTINFO socket option on Linux > systems > (IPV6_RECVPKTINFO when RFC 3542 compliant) for IPv6 > and > similarly with IP_PKTINFO with IPv4, I believe. You > also can get this > information by restricting the socket to receiving > on a particular > interface, if you don't want one socket to handle > multiple interfaces. > Then, you know which interface by which socket you > received on. > > So, you should be able to do most, possibly all, of > what you want at > application level without modification to the > kernel, if you're looking > to do this in an application and not a kernel > module. > > +-DLS > > > Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html From akpm@osdl.org Wed May 18 22:29:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 22:29:07 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J5T2F3007265 for ; Wed, 18 May 2005 22:29:03 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4J5SBU3012568 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 May 2005 22:28:13 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4J5SAam005252; Wed, 18 May 2005 22:28:10 -0700 Date: Wed, 18 May 2005 22:27:29 -0700 From: Andrew Morton To: Herbert Xu Cc: netdev@oss.sgi.com, Evgeniy Polyakov Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem Message-Id: <20050518222729.007887b8.akpm@osdl.org> In-Reply-To: References: <20050518202458.55a63d37.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 473 Lines: 13 Herbert Xu wrote: > > Andrew Morton wrote: > > > > This is the second report of this happening. > > > > FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory Ah yes, thanks. netlink_kernel_create() has a dumbish return-value protocol. > This probably means that someone has stolen the NETLINK_NFLOG id. cn_init() uses NETLINK_NFLOG. Peculiar. From johnpol@2ka.mipt.ru Wed May 18 23:24:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 23:24:52 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J6OjF3010922 for ; Wed, 18 May 2005 23:24:46 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j4J6NYpI024960; Thu, 19 May 2005 10:23:35 +0400 Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Andrew Morton Cc: Herbert Xu , netdev@oss.sgi.com In-Reply-To: <20050518222729.007887b8.akpm@osdl.org> References: <20050518202458.55a63d37.akpm@osdl.org> <20050518222729.007887b8.akpm@osdl.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ICESXTcUFlDQU7GFlVId" Organization: MIPT Date: Thu, 19 May 2005 10:31:53 +0400 Message-Id: <1116484313.21310.78.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Thu, 19 May 2005 10:23:36 +0400 (MSD) X-archive-position: 1344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1265 Lines: 45 --=-ICESXTcUFlDQU7GFlVId Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-05-18 at 22:27 -0700, Andrew Morton wrote: > Herbert Xu wrote: > > > > Andrew Morton wrote: > > >=20 > > > This is the second report of this happening. > > >=20 > > > FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kerne= l/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory >=20 > Ah yes, thanks. netlink_kernel_create() has a dumbish return-value proto= col. >=20 > > This probably means that someone has stolen the NETLINK_NFLOG id. >=20 > cn_init() uses NETLINK_NFLOG. Peculiar. Yep... One may use "unit" module parameter to specify different socket. Should I ask David Miller to allocate new one specially for connector? --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-ICESXTcUFlDQU7GFlVId Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCjDLZIKTPhE+8wY0RAtoTAJ4l9jQ5bmP4W8PnE/swxMmw1fFlDACfQBWE w1ct28hi//kJ3AvOHu7+D3c= =I6jn -----END PGP SIGNATURE----- --=-ICESXTcUFlDQU7GFlVId-- From akpm@osdl.org Wed May 18 23:47:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 23:47:34 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J6lUF3012047 for ; Wed, 18 May 2005 23:47:30 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4J6kYU3017347 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 May 2005 23:46:35 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4J6kX3V007783; Wed, 18 May 2005 23:46:33 -0700 Date: Wed, 18 May 2005 23:45:52 -0700 From: Andrew Morton To: johnpol@2ka.mipt.ru Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, "David S. Miller" Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem Message-Id: <20050518234552.4aef6d02.akpm@osdl.org> In-Reply-To: <1116484313.21310.78.camel@uganda> References: <20050518202458.55a63d37.akpm@osdl.org> <20050518222729.007887b8.akpm@osdl.org> <1116484313.21310.78.camel@uganda> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2039 Lines: 55 Evgeniy Polyakov wrote: > > On Wed, 2005-05-18 at 22:27 -0700, Andrew Morton wrote: > > Herbert Xu wrote: > > > > > > Andrew Morton wrote: > > > > > > > > This is the second report of this happening. > > > > > > > > FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/kernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory > > > > Ah yes, thanks. netlink_kernel_create() has a dumbish return-value protocol. > > > > > This probably means that someone has stolen the NETLINK_NFLOG id. > > > > cn_init() uses NETLINK_NFLOG. Peculiar. > > Yep... Bah. > One may use "unit" module parameter to specify different socket. Is there any reason for being able to do that? > Should I ask David Miller to allocate new one specially for connector? Dave? diff -puN include/linux/netlink.h~connector-netlink-id-fix include/linux/netlink.h --- 25/include/linux/netlink.h~connector-netlink-id-fix 2005-05-18 23:44:43.000000000 -0700 +++ 25-akpm/include/linux/netlink.h 2005-05-18 23:44:43.000000000 -0700 @@ -14,6 +14,7 @@ #define NETLINK_SELINUX 7 /* SELinux event notifications */ #define NETLINK_ARPD 8 #define NETLINK_AUDIT 9 /* auditing */ +#define NETLINK_CONNECTOR 10 /* kernel connector */ #define NETLINK_ROUTE6 11 /* af_inet6 route comm channel */ #define NETLINK_IP6_FW 13 #define NETLINK_DNRTMSG 14 /* DECnet routing messages */ diff -puN drivers/connector/connector.c~connector-netlink-id-fix drivers/connector/connector.c --- 25/drivers/connector/connector.c~connector-netlink-id-fix 2005-05-18 23:44:43.000000000 -0700 +++ 25-akpm/drivers/connector/connector.c 2005-05-18 23:44:43.000000000 -0700 @@ -33,7 +33,7 @@ MODULE_LICENSE("GPL"); MODULE_AUTHOR("Evgeniy Polyakov "); MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector."); -static int unit = NETLINK_NFLOG; +static int unit = NETLINK_CONNECTOR; static u32 cn_idx = CN_IDX_CONNECTOR; static u32 cn_val = CN_VAL_CONNECTOR; _ From johnpol@2ka.mipt.ru Wed May 18 23:59:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 18 May 2005 23:59:28 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J6xJF3012786 for ; Wed, 18 May 2005 23:59:21 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j4J6w6NO026572; Thu, 19 May 2005 10:58:06 +0400 Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Andrew Morton Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <20050518234552.4aef6d02.akpm@osdl.org> References: <20050518202458.55a63d37.akpm@osdl.org> <20050518222729.007887b8.akpm@osdl.org> <1116484313.21310.78.camel@uganda> <20050518234552.4aef6d02.akpm@osdl.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eWbpboGa4GFliTliSj5n" Organization: MIPT Date: Thu, 19 May 2005 11:06:25 +0400 Message-Id: <1116486385.21310.82.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Thu, 19 May 2005 10:58:07 +0400 (MSD) X-archive-position: 1346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2971 Lines: 90 --=-eWbpboGa4GFliTliSj5n Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-05-18 at 23:45 -0700, Andrew Morton wrote: > Evgeniy Polyakov wrote: > > > > On Wed, 2005-05-18 at 22:27 -0700, Andrew Morton wrote: > > > Herbert Xu wrote: > > > > > > > > Andrew Morton wrote: > > > > >=20 > > > > > This is the second report of this happening. > > > > >=20 > > > > > FATAL: Error inserting ipt_ULOG (/lib/modules/2.6.12-rc4-mm1-2/k= ernel/net/ipv4/netfilter/ipt_ULOG.ko): Cannot allocate memory > > >=20 > > > Ah yes, thanks. netlink_kernel_create() has a dumbish return-value p= rotocol. > > >=20 > > > > This probably means that someone has stolen the NETLINK_NFLOG id. > > >=20 > > > cn_init() uses NETLINK_NFLOG. Peculiar. > >=20 > > Yep... >=20 > Bah. >=20 > > One may use "unit" module parameter to specify different socket. >=20 > Is there any reason for being able to do that? It was created to be able to load several different connector devices=20 from different modules [basically it was module1.ko unit=3D10, module2.ko unit=3D11 and so on]. > > Should I ask David Miller to allocate new one specially for connector? >=20 > Dave? >=20 >=20 > diff -puN include/linux/netlink.h~connector-netlink-id-fix include/linux/= netlink.h > --- 25/include/linux/netlink.h~connector-netlink-id-fix 2005-05-18 23:44:= 43.000000000 -0700 > +++ 25-akpm/include/linux/netlink.h 2005-05-18 23:44:43.000000000 -0700 > @@ -14,6 +14,7 @@ > #define NETLINK_SELINUX 7 /* SELinux event notifications */ > #define NETLINK_ARPD 8 > #define NETLINK_AUDIT 9 /* auditing */ > +#define NETLINK_CONNECTOR 10 /* kernel connector */ > #define NETLINK_ROUTE6 11 /* af_inet6 route comm channel */ > #define NETLINK_IP6_FW 13 > #define NETLINK_DNRTMSG 14 /* DECnet routing messages */ > diff -puN drivers/connector/connector.c~connector-netlink-id-fix drivers/= connector/connector.c > --- 25/drivers/connector/connector.c~connector-netlink-id-fix 2005-05-18 = 23:44:43.000000000 -0700 > +++ 25-akpm/drivers/connector/connector.c 2005-05-18 23:44:43.000000000 -= 0700 > @@ -33,7 +33,7 @@ MODULE_LICENSE("GPL"); > MODULE_AUTHOR("Evgeniy Polyakov "); > MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector."); > =20 > -static int unit =3D NETLINK_NFLOG; > +static int unit =3D NETLINK_CONNECTOR; > static u32 cn_idx =3D CN_IDX_CONNECTOR; > static u32 cn_val =3D CN_VAL_CONNECTOR; > =20 > _ --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-eWbpboGa4GFliTliSj5n Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCjDrxIKTPhE+8wY0RAl++AJ9fj9qV3rvl/n1q0/93XHGpi/iw8gCdHzxD ESCobFeRKDOhICPHamwwru0= =jLHB -----END PGP SIGNATURE----- --=-eWbpboGa4GFliTliSj5n-- From akpm@osdl.org Thu May 19 00:09:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 00:09:44 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J79dF3015219 for ; Thu, 19 May 2005 00:09:39 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4J78oU3018997 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 00:08:51 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4J78oMc008592; Thu, 19 May 2005 00:08:50 -0700 Date: Thu, 19 May 2005 00:08:09 -0700 From: Andrew Morton To: johnpol@2ka.mipt.ru Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, davem@davemloft.net Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem Message-Id: <20050519000809.2fca25c5.akpm@osdl.org> In-Reply-To: <1116486385.21310.82.camel@uganda> References: <20050518202458.55a63d37.akpm@osdl.org> <20050518222729.007887b8.akpm@osdl.org> <1116484313.21310.78.camel@uganda> <20050518234552.4aef6d02.akpm@osdl.org> <1116486385.21310.82.camel@uganda> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 626 Lines: 14 Evgeniy Polyakov wrote: > > > Is there any reason for being able to do that? > > It was created to be able to load several different connector devices > from different modules [basically it was module1.ko unit=10, module2.ko > unit=11 and so on]. Loading multiple instances of the same module so that we get multiple instances of its data structures? That's fairly ghastly. We should remove the feature. If there is demonstrated need for multiple instances then it should be done by more conventional means - syscall, allocation of a device major then use the minor as a selector or whatever. From johnpol@2ka.mipt.ru Thu May 19 00:19:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 00:20:00 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J7JuF3019654 for ; Thu, 19 May 2005 00:19:56 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j4J7J0aa027569; Thu, 19 May 2005 11:19:00 +0400 Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Andrew Morton Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, davem@davemloft.net In-Reply-To: <20050519000809.2fca25c5.akpm@osdl.org> References: <20050518202458.55a63d37.akpm@osdl.org> <20050518222729.007887b8.akpm@osdl.org> <1116484313.21310.78.camel@uganda> <20050518234552.4aef6d02.akpm@osdl.org> <1116486385.21310.82.camel@uganda> <20050519000809.2fca25c5.akpm@osdl.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CV9ty3Lp1Q6YbSHBcdSO" Organization: MIPT Date: Thu, 19 May 2005 11:27:19 +0400 Message-Id: <1116487639.21310.88.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Thu, 19 May 2005 11:19:01 +0400 (MSD) X-archive-position: 1348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1603 Lines: 50 --=-CV9ty3Lp1Q6YbSHBcdSO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-05-19 at 00:08 -0700, Andrew Morton wrote: > Evgeniy Polyakov wrote: > > > > > Is there any reason for being able to do that? > >=20 > > It was created to be able to load several different connector devices=20 > > from different modules [basically it was module1.ko unit=3D10, module2= .ko > > unit=3D11 and so on]. >=20 > Loading multiple instances of the same module so that we get multiple > instances of its data structures? That's fairly ghastly. It was not the same module. it was quite different module which implemented similar functionality and used different connector device for different purposes. > We should remove the feature. If there is demonstrated need for multiple > instances then it should be done by more conventional means - syscall, > allocation of a device major then use the minor as a selector or whatever= . It is easy to use feature which prevents problems with situation when the same socket number is used, for example,=20 in 2.6 kernel while connector uses it in -mm tree. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-CV9ty3Lp1Q6YbSHBcdSO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCjD/XIKTPhE+8wY0RAh4XAJ90TtaLiPqeGxRP9Ws07iFCjdelOgCfXc1I lFNcqe0utj+bAkrNZ9QAEvU= =qYwd -----END PGP SIGNATURE----- --=-CV9ty3Lp1Q6YbSHBcdSO-- From kostodo@gmail.com Thu May 19 01:03:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 01:03:38 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4J83SF3023591 for ; Thu, 19 May 2005 01:03:28 -0700 Received: by rproxy.gmail.com with SMTP id z35so188071rne for ; Thu, 19 May 2005 01:02:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lZnEjRIzOUpc2QvjeV1sTuvki2+7b2VVFR0XBgM35Zl+labpnk2dIDBhDDyYMRaA5xsdvm7+6sxEgq9itCaxK1gO8wgrT9PalCwTLVOxaaLrU+NLj9ACwX/MmSNtR7lB0StFjuKoUmcmOfKeXwtMY/tJI2/SSz3Z4Qel/pRr/sU= Received: by 10.38.104.24 with SMTP id b24mr860597rnc; Thu, 19 May 2005 01:02:49 -0700 (PDT) Received: by 10.38.208.46 with HTTP; Thu, 19 May 2005 01:02:49 -0700 (PDT) Message-ID: Date: Thu, 19 May 2005 12:02:49 +0400 From: Kosta Todorovic Reply-To: Kosta Todorovic To: jgarzik@pobox.com Subject: Re: Network card driver problem (znb.o/tulip) Cc: tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4J83SF3023591 X-archive-position: 1349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 2357 Lines: 65 Whats the best 4-port NIC currently available? I'm interested in purchasing 10 4-port NICs as a replacement for my current cards. I am looking for 10/100Mbps and a good driver for linux (2.4.x and 2.6.x). Preferably a mainstream company but thats not priority. Could the community please recommend the best card available? Money is not an issue since im really interested in the best of the best. Any suggestions? Regards, Kosta On 3/11/05, Kosta Todorovic wrote: > My company has recently purchased several ZNYX ZX274 network cards. > These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets. > > Unfortunately there exists no drivers for linux amd64 architecture. > There are 32bit drivers found at: > http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally > they wont compile under my amd64 system. > > The driver itself is called znb.o and can be downloaded from ZNYX's > website. I spoke to support staff there but they told me they have > discontinued support and development for this series of cards. > > The system I am running gentoo and have tried both 2.4.x and 2.6.x > kernels but no luck. > > Unfortunately there is NO 64bit drivers available for ANY platform. not even MS. > > Does anyone know of a customised znb.o driver built for amd64? > Is there any chance of anyone modifying the source code of the driver > to compile under a amd64 system? > > I've noticed that "tulip" drivers get loaded as a module at boot time. > but they dont function correctly. (lets you start the device and > attach ips but cant talk through it) > > Is there any variants of the tulip driver that will work for this? > > Help much appreciated. > > > /proc/pci extract for network cards: > > Bus 5, device 5, function 0: > Ethernet controller: Digital Equipment Corporation DECchip > 21142/43 (#30) (rev 65). > IRQ 30. > Master Capable. Latency=128. Min Gnt=20.Max Lat=40. > I/O at 0x0 [0x7f]. > Non-prefetchable 32 bit memory at 0xfa1ff400 [0xfa1ff7ff]. > Bus 5, device 4, function 0: > Ethernet controller: Digital Equipment Corporation DECchip > 21142/43 (#29) (rev 65). > IRQ 29. > Master Capable. No bursts. Min Gnt=20.Max Lat=40. > I/O at 0x0 [0x7f]. > Non-prefetchable 32 bit memory at 0xf9f00000 [0xf9f003ff]. > From yoshfuji@linux-ipv6.org Thu May 19 03:31:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 03:31:41 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JAVUF3029930 for ; Thu, 19 May 2005 03:31:31 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id ED8CA33CC2; Thu, 19 May 2005 19:33:39 +0900 (JST) Date: Thu, 19 May 2005 19:32:25 +0900 (JST) Message-Id: <20050519.193225.19442831.yoshfuji@linux-ipv6.org> To: usagi-announce@linux-ipv6.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Cc: torvalds@osdl.org, davem@davemloft.net, usagi-core@linux-ipv6.org Subject: Linux 2.6.11-rc2 Got IPv6 Ready Logo Phase-1 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_May_19_19:32:25_2005_149)--" Content-Transfer-Encoding: 7bit X-archive-position: 1350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1852 Lines: 59 ----Security_Multipart(Thu_May_19_19:32:25_2005_149)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, USAGI Project is pleased to announce a special news. The Linux mainline kernel (version 2.6.11-rc2) is approved by IPv6 Forum in IPv6 Ready Logo Phase-1 Program . [Approved Document] o Host Role - LogoID 01-000276 o Router Role - LogoID 01-000275 *) For router role, radvd in usagi-tools was used at the certification. The version of usagi-tools is sV6READYP1-20050121_20050124. [Sources] o Linux-2.6.11-rc2 (36,966,213 Bytes, md5sum: f18456c9da900820fba98576832d598c) o USAGI tools (sV6READYP1-20050121_20050124) (6,024,344 Bytes, md5sum: 199fd40a6caa80990efb61cd5f8cfbae) Although we are allowed to use the Logo only for the certified version, of course you can use the functionalities with the later versions, such as 2.6.11. Thank you. -- Hideaki YOSHIFUJI @ USAGI Project USAGI Project: http://www.linux-ipv6.org GPG FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA ----Security_Multipart(Thu_May_19_19:32:25_2005_149)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQBCjGs+SAf4lOBiDuoRAvmkAKCgU2FOuX3l7u7y/ymToiRqnWD6vQCfZnV5 VQaI3hh2feS+kjjV2Qrxwko= =bw3P -----END PGP SIGNATURE----- ----Security_Multipart(Thu_May_19_19:32:25_2005_149)---- From razb@bitband.com Thu May 19 03:42:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 03:42:41 -0700 (PDT) Received: from mail1.bitband.com (fw.bitband.com [213.8.50.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JAgaF3031208 for ; Thu, 19 May 2005 03:42:37 -0700 Received: from [172.16.1.60] ([172.16.1.60]) by mail1.bitband.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 May 2005 13:41:52 +0200 Subject: tg3 crash. From: raz ben jehuda To: davem@davemloft.net Cc: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1116542460.4240.9.camel@raz-laptop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 20 May 2005 01:41:00 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2005 11:41:52.0220 (UTC) FILETIME=[BFFAD1C0:01C55C67] X-archive-position: 1351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: razb@bitband.com Precedence: bulk X-list: netdev Content-Length: 81 Lines: 5 Hie david. did you take a look at the code i sent you and everyone else ? Raz. From tgraf@suug.ch Thu May 19 05:23:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 05:23:41 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JCNbF3007947 for ; Thu, 19 May 2005 05:23:37 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 44E521C0EB; Thu, 19 May 2005 14:23:19 +0200 (CEST) Date: Thu, 19 May 2005 14:23:19 +0200 From: Thomas Graf To: Herbert Xu Cc: Rick Jones , netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050519122319.GH15391@postel.suug.ch> References: <428B6B72.5010407@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 1353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2284 Lines: 40 * Herbert Xu 2005-05-19 07:45 > Rick Jones wrote: > > If we ass-u-me that the sender is indeed using a random IP ID assignment > > mechanism, 30000 is probably too many. There are only 65536 possible ID's, and > > if we "choose" 30000 of them there will undoubtedly be many duplicated. Someone > > who didn't fall asleep too often in ProbStats (unlike myself) can probably tell > > us just how many. > > IMHO hosts using purely random IDs all the time are fundamentally broken > for applications such as NFS over UDP over gigabit. However, in order > to handle such hosts we should make this threshold configurable and > then those who need it can set it to a value like 600 which gives a > collision probability with the first fragment of just less than 1%. I agree, however defining a value of 600 system wide is horrible for all hosts that behave "correctly". So what we could do is take probes of the id distribution and define the threshold on a per peer scope. Example: Once in a while we start a probe and set a bit in a bitmap for every id that matches a defined window. Not sure about the size of that bitmap yet but 2048 bits might be a good start. The first fragment id received during the probe defines the lower bound of the window and the probe lasts until we received 2048 fragment ids. Once the probe is finished we calculate the ratio between set and unset bits and calculate the threshold. Additionaly we can define a threshold of bits set to figure out if the peer is likely to use a counter for id generation, if so we can set a flag which switches from counting fragment ids to calculating the delta between the fragment id subject to expiration and the current last fragment id. So basically we would have two different modes, the "difficult peer"-mode for peers using random ids or if we only see a very small portion of the effective id space and a "counters"-mode for all peers using counters. The "counters"-mode can offer a nearly perfect solution to detect wraps without suffering from side effects such as droping perfectly legal fragments. This idea relies on the fact that the result of the probe stays true for some time which might not be true but is probably fair enough. From cranium2003@yahoo.com Thu May 19 05:20:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 05:20:21 -0700 (PDT) Received: from web33011.mail.mud.yahoo.com (web33011.mail.mud.yahoo.com [68.142.206.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4JCKFF3007647 for ; Thu, 19 May 2005 05:20:16 -0700 Received: (qmail 1116 invoked by uid 60001); 19 May 2005 12:19:38 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=kYaEWO+3bYJe9+coy6YMt0ROD2yLQrWkkSFTM7nbYAQ1YLhIWfoacHyF0wxnYnICDjA5FX9a8mlYxTT3MKNrh/5vUjsj6ywczsZ6eC7Q8mHg7z1yMWMvIl5LjYtgjoDQMFb9zy55eqqV0OwT52PseyeKBbv88bl+xhnGSB7fA84= ; Message-ID: <20050519121938.1114.qmail@web33011.mail.mud.yahoo.com> Received: from [203.199.141.99] by web33011.mail.mud.yahoo.com via HTTP; Thu, 19 May 2005 05:19:38 PDT Date: Thu, 19 May 2005 05:19:38 -0700 (PDT) From: cranium2003 Subject: ip logging function help To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 822 Lines: 29 hello, By adding iptable rule iptable -A OUTPUT -j LOG I am able to check log of each outgoing packets. But i want to know who is actually calling ipt_log_target function defined in ipt_LOG.c as static unsigned int ipt_log_target(struct sk_buff **pskb, unsigned int hooknum, const struct net_device *in, const struct net_device *out, const void *targinfo, void *userinfo) I want to know which file in source code has pointer to call ipt_log_target function? I want instance/copy of const struct net_device *out to my function in kernel to know that eth0 or eth1 is transmitting packet. Thanks in advance. regards, cranium Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From herbert@gondor.apana.org.au Thu May 19 05:49:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 05:49:26 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JCnHF3009500 for ; Thu, 19 May 2005 05:49:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYkRs-0003UH-00; Thu, 19 May 2005 22:48:24 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYkRp-0007oh-00; Thu, 19 May 2005 22:48:21 +1000 Date: Thu, 19 May 2005 22:48:21 +1000 To: Thomas Graf Cc: Rick Jones , netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050519124821.GA686@gondor.apana.org.au> References: <428B6B72.5010407@hp.com> <20050519122319.GH15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050519122319.GH15391@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 949 Lines: 21 On Thu, May 19, 2005 at 02:23:19PM +0200, Thomas Graf wrote: > > I agree, however defining a value of 600 system wide is horrible for > all hosts that behave "correctly". So what we could do is take probes > of the id distribution and define the threshold on a per peer scope. > > Example: Once in a while we start a probe and set a bit in a bitmap > for every id that matches a defined window. Not sure about the size of > that bitmap yet but 2048 bits might be a good start. The first fragment Sorry, but this scheme is way too complex for a problem that only affects a tiny section of the community. If you really want to do this then do it as a static route flag instead of something that the system tries to auto-detect. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jmorris@redhat.com Thu May 19 06:17:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 06:17:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JDHgF3011321 for ; Thu, 19 May 2005 06:17:42 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4JDGioe011316; Thu, 19 May 2005 09:16:44 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4JDGcO19371; Thu, 19 May 2005 09:16:38 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j4JDGcpW017840; Thu, 19 May 2005 09:16:38 -0400 Date: Thu, 19 May 2005 09:16:37 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Andrew Morton cc: Herbert Xu , , Evgeniy Polyakov Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem In-Reply-To: <20050518222729.007887b8.akpm@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 204 Lines: 13 On Wed, 18 May 2005, Andrew Morton wrote: > cn_init() uses NETLINK_NFLOG. Peculiar. I raised this some time ago, and it was never fixed by the author. - James -- James Morris From jmorris@redhat.com Thu May 19 06:20:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 06:20:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JDKWF3012038 for ; Thu, 19 May 2005 06:20:32 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4JDJYHR012075; Thu, 19 May 2005 09:19:34 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4JDJXO19836; Thu, 19 May 2005 09:19:33 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j4JDJXpW017962; Thu, 19 May 2005 09:19:33 -0400 Date: Thu, 19 May 2005 09:19:33 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Andrew Morton cc: johnpol@2ka.mipt.ru, , , Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem In-Reply-To: <20050519000809.2fca25c5.akpm@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 372 Lines: 15 On Thu, 19 May 2005, Andrew Morton wrote: > We should remove the feature. If there is demonstrated need for multiple > instances then it should be done by more conventional means - syscall, > allocation of a device major then use the minor as a selector or whatever. I'd suggest removing the connector code completely. - James -- James Morris From hadi@cyberus.ca Thu May 19 06:44:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 06:44:33 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JDiRF3013719 for ; Thu, 19 May 2005 06:44:27 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DYlJT-0006Ye-AV for netdev@oss.sgi.com; Thu, 19 May 2005 09:43:47 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DYlJQ-0000si-IQ; Thu, 19 May 2005 09:43:44 -0400 Subject: Re: igmp snooping? From: jamal Reply-To: hadi@cyberus.ca To: Jonathan Day Cc: David Stevens , Lennert Buytenhek , netdev@oss.sgi.com In-Reply-To: <20050519050958.86591.qmail@web31503.mail.mud.yahoo.com> References: <20050519050958.86591.qmail@web31503.mail.mud.yahoo.com> Content-Type: text/plain Organization: unknown Date: Thu, 19 May 2005 09:43:41 -0400 Message-Id: <1116510221.6240.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 491 Lines: 16 On Wed, 2005-18-05 at 22:09 -0700, Jonathan Day wrote: > mentation-dependent. > > Now, in 99.99% of all cases, you're not going to have > any significant IGMPv3 traffic, as barely anyone uses > it yet and IGMP specifies that the highest common > version will be used in a group. A significant amount of video type apps that i have seen lately try to use IGMPv3 and then fallback to IGMPv2. I think that this may be aggravated due to our friends at MS discovering IGMPv3. cheers, jamal From hadi@cyberus.ca Thu May 19 06:47:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 06:47:46 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JDlfF3014398 for ; Thu, 19 May 2005 06:47:41 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DYlMb-0001PW-VK for netdev@oss.sgi.com; Thu, 19 May 2005 09:47:01 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DYlMT-0001YE-S0; Thu, 19 May 2005 09:46:54 -0400 Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem From: jamal Reply-To: hadi@cyberus.ca To: James Morris Cc: Andrew Morton , Herbert Xu , netdev@oss.sgi.com, Evgeniy Polyakov In-Reply-To: References: Content-Type: text/plain Organization: unknown Date: Thu, 19 May 2005 09:46:50 -0400 Message-Id: <1116510411.6240.54.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 533 Lines: 19 On Thu, 2005-19-05 at 09:16 -0400, James Morris wrote: > On Wed, 18 May 2005, Andrew Morton wrote: > > > cn_init() uses NETLINK_NFLOG. Peculiar. > > I raised this some time ago, and it was never fixed by the author. > Sharing as was done here is not proper; perhaps the suggestion from Andrew is the way to go. The other thing we could do is allocate a set of IDs for private use (as in private IPs). However, something like connector should only get one ID and it can do its own multiplexing based on "units". cheers, jamal From niv@us.ibm.com Thu May 19 08:10:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 08:10:59 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JFAmF3002101 for ; Thu, 19 May 2005 08:10:54 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JFA9cE118566 for ; Thu, 19 May 2005 11:10:09 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JFA9OG161846 for ; Thu, 19 May 2005 09:10:09 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JFA8fE029368 for ; Thu, 19 May 2005 09:10:09 -0600 Received: from [9.49.131.1] (sig-9-49-131-1.mts.ibm.com [9.49.131.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JFA8Iu029283; Thu, 19 May 2005 09:10:08 -0600 Message-ID: <428CAC55.4000202@us.ibm.com> Date: Thu, 19 May 2005 08:10:13 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: Jon Mason , shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 905 Lines: 28 Herbert Xu wrote: > Jon Mason wrote: > >>checksum and scatter gather as features of the bridge device. In the >>case that the physical ethernet device does not support scatter >>gather or hardware checksum, dev_queue_xmit() will check the >>dev->features and do the necessary linearization and calculate the >>checksum. > > > Unfortunately skb_linearize is a lot more expensive than not > generating the non-linear skb's in the first place. > > So this is going to hurt people using the bridge devices over > physical devices that don't support SG. Fair point - though I would argue that devices that support SG are much more common now - so optimizing for the more common case might be preferable - since people using bridging with devices that support checksum offload are taking quite a hit when they do bridging - perhaps this could be a conditional? thanks, Nivedita From niv@us.ibm.com Thu May 19 08:14:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 08:14:24 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JFEIF3002928 for ; Thu, 19 May 2005 08:14:18 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JFDbLK436378 for ; Thu, 19 May 2005 11:13:37 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JFDacs228132 for ; Thu, 19 May 2005 09:13:36 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JFDad5012910 for ; Thu, 19 May 2005 09:13:36 -0600 Received: from [9.49.131.1] (sig-9-49-131-1.mts.ibm.com [9.49.131.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JFDZLI012860; Thu, 19 May 2005 09:13:35 -0600 Message-ID: <428CAD24.904@us.ibm.com> Date: Thu, 19 May 2005 08:13:40 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: jdmason@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming References: <20050518235329.GA17946@us.ibm.com> <428BD7E7.5080207@us.ibm.com> <20050518.220031.75189050.davem@davemloft.net> In-Reply-To: <20050518.220031.75189050.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 506 Lines: 18 David S. Miller wrote: >>I think this is a good thing to have, gives us performance >>gain (equivalent to using/not using checksum offload) and >>has very little impact on the bridging layer, and is >>independent of the virtualization stuff.. > > > I agree but keep in mind that when bridging over non-checksumming > devices it will be more expensive. Especially for TCP. Yep - as I just said to Herbert - perhaps worthwhile then conditional upon support of checksum offload & SG? thanks, Nivedita From tgraf@suug.ch Thu May 19 08:19:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 08:19:27 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JFJHF3007157 for ; Thu, 19 May 2005 08:19:18 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 85C721C0EB; Thu, 19 May 2005 17:19:01 +0200 (CEST) Date: Thu, 19 May 2005 17:19:01 +0200 From: Thomas Graf To: Herbert Xu Cc: Rick Jones , netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly Message-ID: <20050519151901.GI15391@postel.suug.ch> References: <428B6B72.5010407@hp.com> <20050519122319.GH15391@postel.suug.ch> <20050519124821.GA686@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050519124821.GA686@gondor.apana.org.au> X-archive-position: 1362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1012 Lines: 19 * Herbert Xu <20050519124821.GA686@gondor.apana.org.au> 2005-05-19 22:48 > On Thu, May 19, 2005 at 02:23:19PM +0200, Thomas Graf wrote: > > > > I agree, however defining a value of 600 system wide is horrible for > > all hosts that behave "correctly". So what we could do is take probes > > of the id distribution and define the threshold on a per peer scope. > > > > Example: Once in a while we start a probe and set a bit in a bitmap > > for every id that matches a defined window. Not sure about the size of > > that bitmap yet but 2048 bits might be a good start. The first fragment > > Sorry, but this scheme is way too complex for a problem that only affects > a tiny section of the community. If you really want to do this then > do it as a static route flag instead of something that the system tries > to auto-detect. Yes, it's currently quite complex, I'm trying to reduce it to something simpler. If we do the route flag thing then we should allow the same flag for permanent neighbours as well. From util@deuroconsult.ro Thu May 19 08:29:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 08:29:50 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JFTZF3007936 for ; Thu, 19 May 2005 08:29:38 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4JFSQNk009404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2005 18:28:26 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4JFSQHj009394; Thu, 19 May 2005 18:28:26 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Thu, 19 May 2005 18:28:26 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: netdev@oss.sgi.com cc: davem@davemloft.net Subject: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1646943047-586930094-1116511660=:24043" Content-ID: X-archive-position: 1363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 4039 Lines: 79 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1646943047-586930094-1116511660=:24043 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Hello! The attached patch, makes the bridge to select features (almost all) only if _all_ devices supports them. The patch was tested (create a bridge, add an interface, remove the interface and always check features flags). What do you think? Signed-off-by: Catalin(ux aka Dino) BOIE --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ---1646943047-586930094-1116511660=:24043 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=bridge_features.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=bridge_features.patch LS0tIGJyaWRnZTEvbmV0L2JyaWRnZS9icl9wcml2YXRlLmgJMjAwNS0wMy0w MiAwOTozNzo1MC4wMDAwMDAwMDAgKzAyMDANCisrKyBsaW51eC9uZXQvYnJp ZGdlL2JyX3ByaXZhdGUuaAkyMDA1LTA1LTE5IDE4OjAwOjA1LjAwMDAwMDAw MCArMDMwMA0KQEAgLTI3LDYgKzI3LDEwIEBADQogI2RlZmluZSBCUl9QT1JU X0JJVFMJMTANCiAjZGVmaW5lIEJSX01BWF9QT1JUUwkoMTw8QlJfUE9SVF9C SVRTKQ0KIA0KKyNkZWZpbmUgQlJfRkVBVF9NQVNLCShORVRJRl9GX0hXX0NT VU0gfCBORVRJRl9GX1NHIFwNCisJCQl8IE5FVElGX0ZfRlJBR0xJU1QgfCBO RVRJRl9GX0lQX0NTVU0gXA0KKwkJCXwgTkVUSUZfRl9ISUdIRE1BIHwgTkVU SUZfRl9UU08pDQorDQogdHlwZWRlZiBzdHJ1Y3QgYnJpZGdlX2lkIGJyaWRn ZV9pZDsNCiB0eXBlZGVmIHN0cnVjdCBtYWNfYWRkciBtYWNfYWRkcjsNCiB0 eXBlZGVmIF9fdTE2IHBvcnRfaWQ7DQotLS0gYnJpZGdlMS9uZXQvYnJpZGdl L2JyX2RldmljZS5jCTIwMDUtMDMtMDIgMDk6Mzc6MzAuMDAwMDAwMDAwICsw MjAwDQorKysgbGludXgvbmV0L2JyaWRnZS9icl9kZXZpY2UuYwkyMDA1LTA1 LTE5IDE3OjE0OjIxLjAwMDAwMDAwMCArMDMwMA0KQEAgLTEwNyw0ICsxMDcs NSBAQCB2b2lkIGJyX2Rldl9zZXR1cChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 DQogCWRldi0+dHhfcXVldWVfbGVuID0gMDsNCiAJZGV2LT5zZXRfbWFjX2Fk ZHJlc3MgPSBOVUxMOw0KIAlkZXYtPnByaXZfZmxhZ3MgPSBJRkZfRUJSSURH RTsNCisJZGV2LT5mZWF0dXJlcyA9IEJSX0ZFQVRfTUFTSzsNCiB9DQotLS0g YnJpZGdlMS9uZXQvYnJpZGdlL2JyX2lmLmMJMjAwNS0wMy0wMiAwOTozODoz My4wMDAwMDAwMDAgKzAyMDANCisrKyBsaW51eC9uZXQvYnJpZGdlL2JyX2lm LmMJMjAwNS0wNS0xOSAxODoyMTozOS4wMDAwMDAwMDAgKzAzMDANCkBAIC0z MTQsNiArMzE0LDI3IEBAIGludCBicl9taW5fbXR1KGNvbnN0IHN0cnVjdCBu ZXRfYnJpZGdlICoNCiAJcmV0dXJuIG10dTsNCiB9DQogDQorLyoNCisgKiBJ ZiBzbGF2ZSBkZXZpY2UgKEBkZXYpIGRvZXNuJ3Qgc3VwcG9ydCBzcGVjaWFs IGZlYXR1cmVzLA0KKyAqIHR1cm4gdGhlbSBvZmYgZ2xvYmFsbHkuDQorICov DQorc3RhdGljIGlubGluZSB2b2lkIGJyX2ZlYXR1cmVzX2NoYW5nZShzdHJ1 Y3QgbmV0X2JyaWRnZSAqYnIsIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQor ew0KKwlici0+ZGV2LT5mZWF0dXJlcyAmPSBkZXYtPmZlYXR1cmVzIHwgfkJS X0ZFQVRfTUFTSzsNCit9DQorDQorLyoNCisgKiBSZWNvbXB1dGVzIGZlYXR1 cmVzIHVzaW5nIHNsYXZlJ3MgZmVhdHVyZXMNCisgKi8NCitzdGF0aWMgdm9p ZCBicl9mZWF0dXJlc19yZWNvbXB1dGUoc3RydWN0IG5ldF9icmlkZ2UgKmJy KQ0KK3sNCisJc3RydWN0IG5ldF9icmlkZ2VfcG9ydCAqcDsNCisNCisJYnIt PmRldi0+ZmVhdHVyZXMgfD0gQlJfRkVBVF9NQVNLOw0KKwlsaXN0X2Zvcl9l YWNoX2VudHJ5KHAsICZici0+cG9ydF9saXN0LCBsaXN0KQ0KKwkJYnJfZmVh dHVyZXNfY2hhbmdlKGJyLCBwLT5kZXYpOw0KK30NCisNCiAvKiBjYWxsZWQg d2l0aCBSVE5MICovDQogaW50IGJyX2FkZF9pZihzdHJ1Y3QgbmV0X2JyaWRn ZSAqYnIsIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQogew0KQEAgLTMzMiw5 ICszNTMsMTAgQEAgaW50IGJyX2FkZF9pZihzdHJ1Y3QgbmV0X2JyaWRnZSAq YnIsIHN0cg0KIAlpZiAoSVNfRVJSKHAgPSBuZXdfbmJwKGJyLCBkZXYsIGJy X2luaXRpYWxfcG9ydF9jb3N0KGRldikpKSkNCiAJCXJldHVybiBQVFJfRVJS KHApOw0KIA0KKwlicl9mZWF0dXJlc19jaGFuZ2UoYnIsIGRldik7DQorDQog IAlpZiAoKGVyciA9IGJyX2ZkYl9pbnNlcnQoYnIsIHAsIGRldi0+ZGV2X2Fk ZHIsIDEpKSkNCiAJCWRlc3Ryb3lfbmJwKHApOw0KLSANCiAJZWxzZSBpZiAo KGVyciA9IGJyX3N5c2ZzX2FkZGlmKHApKSkNCiAJCWRlbF9uYnAocCk7DQog CWVsc2Ugew0KQEAgLTM2OCw2ICszOTAsNyBAQCBpbnQgYnJfZGVsX2lmKHN0 cnVjdCBuZXRfYnJpZGdlICpiciwgc3RyDQogDQogCXNwaW5fbG9ja19iaCgm YnItPmxvY2spOw0KIAlicl9zdHBfcmVjYWxjdWxhdGVfYnJpZGdlX2lkKGJy KTsNCisJYnJfZmVhdHVyZXNfcmVjb21wdXRlKGJyKTsNCiAJc3Bpbl91bmxv Y2tfYmgoJmJyLT5sb2NrKTsNCiANCiAJcmV0dXJuIDA7DQo= ---1646943047-586930094-1116511660=:24043-- From niv@us.ibm.com Thu May 19 09:00:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 09:00:29 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JG0AF3009982 for ; Thu, 19 May 2005 09:00:17 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JFxNLK493418 for ; Thu, 19 May 2005 11:59:26 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JFxKcs242042 for ; Thu, 19 May 2005 09:59:20 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JFxJSh029768 for ; Thu, 19 May 2005 09:59:20 -0600 Received: from [9.49.131.1] (sig-9-49-131-1.mts.ibm.com [9.49.131.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JFxJV6029705; Thu, 19 May 2005 09:59:19 -0600 Message-ID: <428CB7DC.1050206@us.ibm.com> Date: Thu, 19 May 2005 08:59:24 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Catalin(ux aka Dino) BOIE" CC: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2923 Lines: 95 Catalin(ux aka Dino) BOIE wrote: > Hello! > > The attached patch, makes the bridge to select features (almost all) > only if _all_ devices supports them. > The patch was tested (create a bridge, add an interface, remove the > interface and always check features flags). > > What do you think? While this is generally a cleaner thing to do - it breaks what we need - Jon's patch adds the checksum offload/SG unconditionally precisely because we don't want it to be an all or nothing - we'd like to utilize offload on those devices that do support it.. thanks, Nivedita > ------------------------------------------------------------------------ > > --- bridge1/net/bridge/br_private.h 2005-03-02 09:37:50.000000000 +0200 > +++ linux/net/bridge/br_private.h 2005-05-19 18:00:05.000000000 +0300 > @@ -27,6 +27,10 @@ > #define BR_PORT_BITS 10 > #define BR_MAX_PORTS (1< > +#define BR_FEAT_MASK (NETIF_F_HW_CSUM | NETIF_F_SG \ > + | NETIF_F_FRAGLIST | NETIF_F_IP_CSUM \ > + | NETIF_F_HIGHDMA | NETIF_F_TSO) > + > typedef struct bridge_id bridge_id; > typedef struct mac_addr mac_addr; > typedef __u16 port_id; > --- bridge1/net/bridge/br_device.c 2005-03-02 09:37:30.000000000 +0200 > +++ linux/net/bridge/br_device.c 2005-05-19 17:14:21.000000000 +0300 > @@ -107,4 +107,5 @@ void br_dev_setup(struct net_device *dev > dev->tx_queue_len = 0; > dev->set_mac_address = NULL; > dev->priv_flags = IFF_EBRIDGE; > + dev->features = BR_FEAT_MASK; > } > --- bridge1/net/bridge/br_if.c 2005-03-02 09:38:33.000000000 +0200 > +++ linux/net/bridge/br_if.c 2005-05-19 18:21:39.000000000 +0300 > @@ -314,6 +314,27 @@ int br_min_mtu(const struct net_bridge * > return mtu; > } > > +/* > + * If slave device (@dev) doesn't support special features, > + * turn them off globally. > + */ > +static inline void br_features_change(struct net_bridge *br, struct net_device *dev) > +{ > + br->dev->features &= dev->features | ~BR_FEAT_MASK; > +} > + > +/* > + * Recomputes features using slave's features > + */ > +static void br_features_recompute(struct net_bridge *br) > +{ > + struct net_bridge_port *p; > + > + br->dev->features |= BR_FEAT_MASK; > + list_for_each_entry(p, &br->port_list, list) > + br_features_change(br, p->dev); > +} > + > /* called with RTNL */ > int br_add_if(struct net_bridge *br, struct net_device *dev) > { > @@ -332,9 +353,10 @@ int br_add_if(struct net_bridge *br, str > if (IS_ERR(p = new_nbp(br, dev, br_initial_port_cost(dev)))) > return PTR_ERR(p); > > + br_features_change(br, dev); > + > if ((err = br_fdb_insert(br, p, dev->dev_addr, 1))) > destroy_nbp(p); > - > else if ((err = br_sysfs_addif(p))) > del_nbp(p); > else { > @@ -368,6 +390,7 @@ int br_del_if(struct net_bridge *br, str > > spin_lock_bh(&br->lock); > br_stp_recalculate_bridge_id(br); > + br_features_recompute(br); > spin_unlock_bh(&br->lock); > > return 0; From jdmason@us.ibm.com Thu May 19 09:07:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 09:07:40 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JG7XF3015137 for ; Thu, 19 May 2005 09:07:33 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JG6t0c159638 for ; Thu, 19 May 2005 12:06:55 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JG6tcs241988 for ; Thu, 19 May 2005 10:06:55 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JG6s0D016177 for ; Thu, 19 May 2005 10:06:54 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JG6sxV016152; Thu, 19 May 2005 10:06:54 -0600 From: Jon Mason Organization: IBM To: "Catalin(ux aka Dino) BOIE" Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) Date: Thu, 19 May 2005 11:06:53 -0500 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com, davem@davemloft.net References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505191106.53136.jdmason@us.ibm.com> X-archive-position: 1365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 799 Lines: 23 This patch only enables the features which are common between all of the bridged devices (at the time of their addition to the bridge). It overlooks the cases where not all of the adapters have the same features, or where the user has changed the enablement of a certain feature (via ethtool). Thanks, Jon On Thursday 19 May 2005 10:28 am, Catalin(ux aka Dino) BOIE wrote: > Hello! > > The attached patch, makes the bridge to select features (almost all) only > if _all_ devices supports them. > The patch was tested (create a bridge, add an interface, remove the > interface and always check features flags). > > What do you think? > > Signed-off-by: Catalin(ux aka Dino) BOIE > --- > Catalin(ux aka Dino) BOIE > catab at deuroconsult.ro > http://kernel.umbrella.ro/ From akpm@osdl.org Thu May 19 09:55:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 09:55:22 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JGtIF3030319 for ; Thu, 19 May 2005 09:55:18 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4JGsJU3030254 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 09:54:20 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4JGsFqu030077; Thu, 19 May 2005 09:54:16 -0700 Date: Thu, 19 May 2005 09:53:34 -0700 From: Andrew Morton To: James Morris Cc: johnpol@2ka.mipt.ru, herbert@gondor.apana.org.au, netdev@oss.sgi.com, davem@davemloft.net Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem Message-Id: <20050519095334.018dd674.akpm@osdl.org> In-Reply-To: References: <20050519000809.2fca25c5.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 650 Lines: 17 James Morris wrote: > > On Thu, 19 May 2005, Andrew Morton wrote: > > > We should remove the feature. If there is demonstrated need for multiple > > instances then it should be done by more conventional means - syscall, > > allocation of a device major then use the minor as a selector or whatever. > > I'd suggest removing the connector code completely. > How come? It seems sensible to have library code which consoldates the common netlink setup and teardown stuff and which offers a higher-level messaging API, although connector may be a bit overdesigned for that. The fork connector guys seemed to find it useful? From rick.jones2@hp.com Thu May 19 10:03:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 10:03:34 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JH3NF3031303 for ; Thu, 19 May 2005 10:03:24 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 146A9404229 for ; Thu, 19 May 2005 10:02:46 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id KAA29412 for ; Thu, 19 May 2005 10:02:45 -0700 (PDT) Message-ID: <428CC6B5.6070803@hp.com> Date: Thu, 19 May 2005 10:02:45 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly References: <428B6B72.5010407@hp.com> <20050519122319.GH15391@postel.suug.ch> In-Reply-To: <20050519122319.GH15391@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 399 Lines: 9 > I agree, however defining a value of 600 system wide is horrible for > all hosts that behave "correctly". So what we could do is take probes > of the id distribution and define the threshold on a per peer scope. Why would 600 penalize a host behaving "correctly?" I mean, what are the chances of a datagram's being reassembled, if 600 subsent datagrams have arrived from that same host? rick From jmorris@redhat.com Thu May 19 10:10:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 10:10:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JHAfF3031934 for ; Thu, 19 May 2005 10:10:42 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4JH9jed024801; Thu, 19 May 2005 13:09:45 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4JH9iO26590; Thu, 19 May 2005 13:09:45 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j4JH9ipW005495; Thu, 19 May 2005 13:09:44 -0400 Date: Thu, 19 May 2005 13:09:44 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Andrew Morton cc: johnpol@2ka.mipt.ru, , , Subject: Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem In-Reply-To: <20050519095334.018dd674.akpm@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1368 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 480 Lines: 17 On Thu, 19 May 2005, Andrew Morton wrote: > How come? It seems sensible to have library code which consoldates the > common netlink setup and teardown stuff and which offers a higher-level > messaging API, although connector may be a bit overdesigned for that. The > fork connector guys seemed to find it useful? I don't think it's the right implementation, and providing feedback on it has proven frustrating and unfruitful. - James -- James Morris From greearb@candelatech.com Thu May 19 10:14:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 10:14:52 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JHEjF3032715 for ; Thu, 19 May 2005 10:14:46 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j4JHjgGf012811; Thu, 19 May 2005 10:45:43 -0700 Message-ID: <428CC958.1080909@candelatech.com> Date: Thu, 19 May 2005 10:14:00 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kosta Todorovic CC: jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: Network card driver problem (znb.o/tulip) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 3124 Lines: 91 Kosta Todorovic wrote: > Whats the best 4-port NIC currently available? I'm interested in > purchasing 10 4-port NICs as a replacement for my current cards. > > I am looking for 10/100Mbps and a good driver for linux (2.4.x and > 2.6.x). Preferably a mainstream company but thats not priority. > > Could the community please recommend the best card available? Money is > not an issue since im really interested in the best of the best. Get an Intel 4-port GigE NIC. It will do 10/100/1000, and if you really want to use all 4 ports at even 100Mbps, you need the 64-bit PCI bus... I have been getting mine from silicom-usa.com lately. They also have 6-port NICs, and 4-port broadcom GigE nics that can be used in 32-bit PCI slots. (The Intel 4-port NICs will only work in 64-bit PCI slots.) If you really want 10/100 nics, try the p430tx from aei: http://www.aei-it.com/hardware/fastenet/p430tx.htm These are like the old DFE570tx NICs, and use the tulip driver. They are almost as expensive as the GigE NICs though... Thanks, Ben > > Any suggestions? > > Regards, > Kosta > > > > On 3/11/05, Kosta Todorovic wrote: > >>My company has recently purchased several ZNYX ZX274 network cards. >>These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets. >> >>Unfortunately there exists no drivers for linux amd64 architecture. >>There are 32bit drivers found at: >>http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally >>they wont compile under my amd64 system. >> >>The driver itself is called znb.o and can be downloaded from ZNYX's >>website. I spoke to support staff there but they told me they have >>discontinued support and development for this series of cards. >> >>The system I am running gentoo and have tried both 2.4.x and 2.6.x >>kernels but no luck. >> >>Unfortunately there is NO 64bit drivers available for ANY platform. not even MS. >> >>Does anyone know of a customised znb.o driver built for amd64? >>Is there any chance of anyone modifying the source code of the driver >>to compile under a amd64 system? >> >>I've noticed that "tulip" drivers get loaded as a module at boot time. >>but they dont function correctly. (lets you start the device and >>attach ips but cant talk through it) >> >>Is there any variants of the tulip driver that will work for this? >> >>Help much appreciated. >> >> >>/proc/pci extract for network cards: >> >> Bus 5, device 5, function 0: >> Ethernet controller: Digital Equipment Corporation DECchip >>21142/43 (#30) (rev 65). >> IRQ 30. >> Master Capable. Latency=128. Min Gnt=20.Max Lat=40. >> I/O at 0x0 [0x7f]. >> Non-prefetchable 32 bit memory at 0xfa1ff400 [0xfa1ff7ff]. >> Bus 5, device 4, function 0: >> Ethernet controller: Digital Equipment Corporation DECchip >>21142/43 (#29) (rev 65). >> IRQ 29. >> Master Capable. No bursts. Min Gnt=20.Max Lat=40. >> I/O at 0x0 [0x7f]. >> Non-prefetchable 32 bit memory at 0xf9f00000 [0xf9f003ff]. >> > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From util@deuroconsult.ro Thu May 19 10:23:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 10:23:46 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JHNfF3001135 for ; Thu, 19 May 2005 10:23:42 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4JHMoIZ012173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2005 20:22:50 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4JHMmr9012166; Thu, 19 May 2005 20:22:49 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Thu, 19 May 2005 20:22:48 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Jon Mason cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) In-Reply-To: <200505191106.53136.jdmason@us.ibm.com> Message-ID: References: <200505191106.53136.jdmason@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1289 Lines: 40 On Thu, 19 May 2005, Jon Mason wrote: > This patch only enables the features which are common between all of the > bridged devices (at the time of their addition to the bridge). It overlooks > the cases where not all of the adapters have the same features, or where the > user has changed the enablement of a certain feature (via ethtool). > > Thanks, > Jon I agree that the patch doesn't take care of ethtool oprations. I will correct this. But, it doesn't overlook the case when "not all of the adapters have the same features". If all devices have a feature, it is enabled on the bridge interface. Else, it is cleared. Am I missing your point? Thank you very much for looking over the patch! > On Thursday 19 May 2005 10:28 am, Catalin(ux aka Dino) BOIE wrote: >> Hello! >> >> The attached patch, makes the bridge to select features (almost all) only >> if _all_ devices supports them. >> The patch was tested (create a bridge, add an interface, remove the >> interface and always check features flags). >> >> What do you think? >> >> Signed-off-by: Catalin(ux aka Dino) BOIE >> --- >> Catalin(ux aka Dino) BOIE >> catab at deuroconsult.ro >> http://kernel.umbrella.ro/ > --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From jdmason@us.ibm.com Thu May 19 10:48:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 10:48:45 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JHmcF3002351 for ; Thu, 19 May 2005 10:48:39 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JHluLK607254 for ; Thu, 19 May 2005 13:47:56 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JHlucs260530 for ; Thu, 19 May 2005 11:47:56 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JHltkR026681 for ; Thu, 19 May 2005 11:47:56 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JHltlt026678; Thu, 19 May 2005 11:47:55 -0600 From: Jon Mason Organization: IBM To: "Catalin(ux aka Dino) BOIE" Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) Date: Thu, 19 May 2005 12:47:55 -0500 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com, davem@davemloft.net References: <200505191106.53136.jdmason@us.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505191247.55138.jdmason@us.ibm.com> X-archive-position: 1371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1406 Lines: 34 On Thursday 19 May 2005 12:22 pm, Catalin(ux aka Dino) BOIE wrote: > On Thu, 19 May 2005, Jon Mason wrote: > > This patch only enables the features which are common between all of the > > bridged devices (at the time of their addition to the bridge). It > > overlooks the cases where not all of the adapters have the same features, > > or where the user has changed the enablement of a certain feature (via > > ethtool). > > > > Thanks, > > Jon > > I agree that the patch doesn't take care of ethtool oprations. > I will correct this. I think trying to correct this could be a bear of a problem. Good luck. > But, it doesn't overlook the case when "not all of the adapters have the > same features". If all devices have a feature, it is enabled on the bridge > interface. Else, it is cleared. Am I missing your point? My point is that some features the user might want enabled regardless of whether all devices support them. An example of this is where a system has hardware checksum support for all devices except one. In this case, it would be benefitial to have this device do the checksum in software (via skb_checksum_help() call in dev_queue_xmit()). > Thank you very much for looking over the patch! I really like your patch, and I'm working on combining the two so that we have the best of both worlds. I'll submit it once I have tested it, and we'll see who likes it. Thanks, Jon From pb@bieringer.de Thu May 19 10:59:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 10:59:14 -0700 (PDT) Received: from smtp1.aerasec.de (pib.aerasec.de [195.226.187.146]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JHx5F3003665 for ; Thu, 19 May 2005 10:59:08 -0700 Received: from ppp-82-135-69-142.mnet-online.de (ppp-82-135-72-208.mnet-online.de [82.135.72.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.aerasec.de (Postfix) with ESMTP id C1D9B27245; Thu, 19 May 2005 19:58:25 +0200 (CEST) Date: Thu, 19 May 2005 19:58:23 +0200 From: Peter Bieringer To: netdev@oss.sgi.com cc: "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" , usagi-core@linux-ipv6.org Subject: Re: Linux 2.6.11-rc2 Got IPv6 Ready Logo Phase-1 Message-ID: <33B76C1D2C67B84F1EA687D9@gatemuc.muc.bieringer.de> In-Reply-To: <20050519.193225.19442831.yoshfuji@linux-ipv6.org> References: <20050519.193225.19442831.yoshfuji@linux-ipv6.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 1372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Content-Length: 618 Lines: 20 --On Thursday, May 19, 2005 07:32:25 PM +0900 "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" wrote: > Dear all, > > > USAGI Project is pleased to announce a special news. > > The Linux mainline kernel (version 2.6.11-rc2) is approved by IPv6 Forum > in IPv6 Ready Logo Phase-1 Program . Congratulation for the hard work! Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From davem@davemloft.net Thu May 19 11:45:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 11:45:18 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JIjEF3005535 for ; Thu, 19 May 2005 11:45:14 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYq0P-0004G2-8C; Thu, 19 May 2005 11:44:25 -0700 Date: Thu, 19 May 2005 11:44:25 -0700 (PDT) Message-Id: <20050519.114425.18307286.davem@davemloft.net> To: akpm@osdl.org Cc: johnpol@2ka.mipt.ru, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: "David S. Miller" In-Reply-To: <20050518234552.4aef6d02.akpm@osdl.org> References: <20050518222729.007887b8.akpm@osdl.org> <1116484313.21310.78.camel@uganda> <20050518234552.4aef6d02.akpm@osdl.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 435 Lines: 13 From: Andrew Morton Date: Wed, 18 May 2005 23:45:52 -0700 > > Should I ask David Miller to allocate new one specially for connector? > > Dave? Giving the connector a single value 10 is OK, the rest of what the connector is doing in this area is not. I wish you hadn't put the connector into -mm, it's really in need of several fixups still. The bogus reuse of the ULOG netlink number is simply indicative of that. From davem@davemloft.net Thu May 19 11:43:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 11:43:56 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JIhpF3005333 for ; Thu, 19 May 2005 11:43:51 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYpyj-0004FV-TQ; Thu, 19 May 2005 11:42:41 -0700 Date: Thu, 19 May 2005 11:42:41 -0700 (PDT) Message-Id: <20050519.114241.59656850.davem@davemloft.net> To: johnpol@2ka.mipt.ru Cc: akpm@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: "David S. Miller" In-Reply-To: <1116486385.21310.82.camel@uganda> References: <1116484313.21310.78.camel@uganda> <20050518234552.4aef6d02.akpm@osdl.org> <1116486385.21310.82.camel@uganda> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 508 Lines: 13 From: Evgeniy Polyakov Date: Thu, 19 May 2005 11:06:25 +0400 > It was created to be able to load several different connector devices > from different modules [basically it was module1.ko unit=10, module2.ko > unit=11 and so on]. That's bogus, each connector will need to allocate it's own specific define in the netlink header, and we're about to run out of numbers. Please redesign the connector so that it doesn't eat more than one netlink number, we're running out of them soon. From davem@davemloft.net Thu May 19 11:49:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 11:49:17 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JIn5F3006846 for ; Thu, 19 May 2005 11:49:05 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYq45-0004Gh-7C; Thu, 19 May 2005 11:48:13 -0700 Date: Thu, 19 May 2005 11:48:13 -0700 (PDT) Message-Id: <20050519.114813.85686672.davem@davemloft.net> To: jmorris@redhat.com Cc: akpm@osdl.org, johnpol@2ka.mipt.ru, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: "David S. Miller" In-Reply-To: References: <20050519000809.2fca25c5.akpm@osdl.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 605 Lines: 14 From: James Morris Date: Thu, 19 May 2005 09:19:33 -0400 (EDT) > On Thu, 19 May 2005, Andrew Morton wrote: > > > We should remove the feature. If there is demonstrated need for multiple > > instances then it should be done by more conventional means - syscall, > > allocation of a device major then use the minor as a selector or whatever. > > I'd suggest removing the connector code completely. I totally agree, it's crap at the current time and the author doesn't fix the problems being shown in it, in fact he defends some of them even this one. It needs lots of work still. From davem@davemloft.net Thu May 19 11:49:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 11:50:03 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JInwF3007092 for ; Thu, 19 May 2005 11:49:58 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYq4r-0004HD-DD; Thu, 19 May 2005 11:49:01 -0700 Date: Thu, 19 May 2005 11:49:01 -0700 (PDT) Message-Id: <20050519.114901.108984882.davem@davemloft.net> To: hadi@cyberus.ca Cc: jmorris@redhat.com, akpm@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com, johnpol@2ka.mipt.ru Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: "David S. Miller" In-Reply-To: <1116510411.6240.54.camel@localhost.localdomain> References: <1116510411.6240.54.camel@localhost.localdomain> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 253 Lines: 10 From: jamal Date: Thu, 19 May 2005 09:46:50 -0400 > However, something like connector should only get one ID and it can do > its own multiplexing based on "units". Yes. There is no reason connector needs more than one netlink ID. From davem@davemloft.net Thu May 19 11:52:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 11:52:36 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JIqXF3008027 for ; Thu, 19 May 2005 11:52:33 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYq7R-0004I3-C9; Thu, 19 May 2005 11:51:41 -0700 Date: Thu, 19 May 2005 11:51:41 -0700 (PDT) Message-Id: <20050519.115141.21926463.davem@davemloft.net> To: niv@us.ibm.com Cc: herbert@gondor.apana.org.au, jdmason@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming From: "David S. Miller" In-Reply-To: <428CAC55.4000202@us.ibm.com> References: <428CAC55.4000202@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 709 Lines: 17 From: Nivedita Singhvi Date: Thu, 19 May 2005 08:10:13 -0700 > Fair point - though I would argue that devices that > support SG are much more common now - so optimizing > for the more common case might be preferable - since > people using bridging with devices that support > checksum offload are taking quite a hit when they > do bridging - perhaps this could be a conditional? I disagree. Many low costs devices are non-SG still, there is no reason to penalize them explicitly. I think instead we should look at ways to propagate the hardware device features to the bridge. Even if a bridge is composed of multiple devices, we just advertise the subset of features actually supported. From davem@davemloft.net Thu May 19 11:54:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 11:54:06 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JIs2F3008576 for ; Thu, 19 May 2005 11:54:03 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYq8g-0004IX-UK; Thu, 19 May 2005 11:52:58 -0700 Date: Thu, 19 May 2005 11:52:58 -0700 (PDT) Message-Id: <20050519.115258.28787892.davem@davemloft.net> To: niv@us.ibm.com Cc: util@deuroconsult.ro, netdev@oss.sgi.com Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones From: "David S. Miller" In-Reply-To: <428CB7DC.1050206@us.ibm.com> References: <428CB7DC.1050206@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 420 Lines: 11 From: Nivedita Singhvi Date: Thu, 19 May 2005 08:59:24 -0700 > While this is generally a cleaner thing to do - it breaks > what we need - Jon's patch adds the checksum offload/SG > unconditionally precisely because we don't want it to be > an all or nothing - we'd like to utilize offload on those > devices that do support it.. No, I think Catalin's patch is exactly how this should be implemented. From davem@davemloft.net Thu May 19 11:54:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 11:54:47 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JIshF3008750 for ; Thu, 19 May 2005 11:54:43 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYq9Z-0004Ii-Q6; Thu, 19 May 2005 11:53:53 -0700 Date: Thu, 19 May 2005 11:53:53 -0700 (PDT) Message-Id: <20050519.115353.102574650.davem@davemloft.net> To: jdmason@us.ibm.com Cc: util@deuroconsult.ro, netdev@oss.sgi.com Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones From: "David S. Miller" In-Reply-To: <200505191106.53136.jdmason@us.ibm.com> References: <200505191106.53136.jdmason@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 640 Lines: 15 From: Jon Mason Date: Thu, 19 May 2005 11:06:53 -0500 > This patch only enables the features which are common between all of the > bridged devices (at the time of their addition to the bridge). It overlooks > the cases where not all of the adapters have the same features, or where the > user has changed the enablement of a certain feature (via ethtool). There is not valid setting other than the subset of what the devices all support. Yes, the bridging code should listen for network device events when netdev->flag settings change, but otherwise this is the way to implement this. Just like bonding does. From davem@davemloft.net Thu May 19 11:55:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 11:55:52 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JItnF3009447 for ; Thu, 19 May 2005 11:55:49 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqAY-0004J2-CM; Thu, 19 May 2005 11:54:54 -0700 Date: Thu, 19 May 2005 11:54:54 -0700 (PDT) Message-Id: <20050519.115454.45743895.davem@davemloft.net> To: jmorris@redhat.com Cc: akpm@osdl.org, johnpol@2ka.mipt.ru, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: "David S. Miller" In-Reply-To: References: <20050519095334.018dd674.akpm@osdl.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 244 Lines: 7 From: James Morris Date: Thu, 19 May 2005 13:09:44 -0400 (EDT) > I don't think it's the right implementation, and providing feedback on it > has proven frustrating and unfruitful. Yes, Evgeni is a complete control freak. From davem@davemloft.net Thu May 19 11:59:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 11:59:25 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JIxMF3010237 for ; Thu, 19 May 2005 11:59:22 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqE4-0004Jm-Ht; Thu, 19 May 2005 11:58:32 -0700 Date: Thu, 19 May 2005 11:58:32 -0700 (PDT) Message-Id: <20050519.115832.111205328.davem@davemloft.net> To: jdmason@us.ibm.com Cc: util@deuroconsult.ro, netdev@oss.sgi.com Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones From: "David S. Miller" In-Reply-To: <200505191247.55138.jdmason@us.ibm.com> References: <200505191106.53136.jdmason@us.ibm.com> <200505191247.55138.jdmason@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 633 Lines: 12 From: Jon Mason Date: Thu, 19 May 2005 12:47:55 -0500 > My point is that some features the user might want enabled regardless of > whether all devices support them. An example of this is where a system has > hardware checksum support for all devices except one. In this case, it would > be benefitial to have this device do the checksum in software (via > skb_checksum_help() call in dev_queue_xmit()). If "SG and checksumming is so common these days" as others have stated, what you are describing is a totally uncommon scenerio. What Catalin is proposing is infinitely better than what we have today. From jdmason@us.ibm.com Thu May 19 12:01:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:01:17 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJ1DF3010468 for ; Thu, 19 May 2005 12:01:13 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JJ0Zua192852 for ; Thu, 19 May 2005 15:00:35 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JJ0Ycs210196 for ; Thu, 19 May 2005 13:00:34 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JJ0Y87004255 for ; Thu, 19 May 2005 13:00:34 -0600 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JJ0YkU004241; Thu, 19 May 2005 13:00:34 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.10) with ESMTP id j4JJ0XbR394460; Thu, 19 May 2005 14:00:33 -0500 Received: from dreadnought (dreadnought.austin.ibm.com [9.53.90.32]) by popmail.austin.ibm.com (AIX5.1/8.11.6p2/8.9.3) with SMTP id j4JJ0WU973410; Thu, 19 May 2005 14:00:32 -0500 Received: by dreadnought (sSMTP sendmail emulation); Thu, 19 May 2005 14:00:32 -0500 Date: Thu, 19 May 2005 14:00:32 -0500 From: Jon Mason To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) Message-ID: <20050519190032.GA19620@us.ibm.com> References: <200505191106.53136.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-archive-position: 1382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2436 Lines: 79 I combined my previous patch with your patch, and came up with the following. I have tested it on my system, and it works exactly the way I wanted. What do you think? Thanks, Jon Signed-off-by: Catalin(ux aka Dino) BOIE Signed-off-by: Jon Mason --- linux-2.6.11-xenU/net/bridge/br_private.h 2005-03-02 01:37:50.000000000 -0600 +++ linux-2.6.11-xen0/net/bridge/br_private.h 2005-05-19 08:12:23.000000000 -0500 @@ -27,6 +27,10 @@ #define BR_PORT_BITS 10 #define BR_MAX_PORTS (1<tx_queue_len = 0; dev->set_mac_address = NULL; dev->priv_flags = IFF_EBRIDGE; + dev->features = BR_FEAT_MASK; } --- linux-2.6.11-xenU/net/bridge/br_if.c 2005-05-19 08:43:03.000000000 -0500 +++ linux-2.6.11-xen0/net/bridge/br_if.c 2005-05-19 08:43:58.000000000 -0500 @@ -314,6 +314,27 @@ int br_min_mtu(const struct net_bridge * return mtu; } +/* + * If slave device (@dev) doesn't support special features, + * turn them off globally. + */ +static inline void br_features_change(struct net_bridge *br, struct net_device *dev) +{ + br->dev->features &= dev->features | NETIF_F_HW_CSUM | NETIF_F_SG; +} + +/* + * Recomputes features using slave's features + */ +static void br_features_recompute(struct net_bridge *br) +{ + struct net_bridge_port *p; + + br->dev->features = BR_FEAT_MASK; + list_for_each_entry(p, &br->port_list, list) + br_features_change(br, p->dev); +} + /* called with RTNL */ int br_add_if(struct net_bridge *br, struct net_device *dev) { @@ -332,6 +353,8 @@ int br_add_if(struct net_bridge *br, str if (IS_ERR(p = new_nbp(br, dev, br_initial_port_cost(dev)))) return PTR_ERR(p); + br_features_change(br, dev); + if ((err = br_fdb_insert(br, p, dev->dev_addr, 1))) destroy_nbp(p); @@ -368,6 +391,7 @@ int br_del_if(struct net_bridge *br, str spin_lock_bh(&br->lock); br_stp_recalculate_bridge_id(br); + br_features_recompute(br); spin_unlock_bh(&br->lock); return 0; From jdmason@us.ibm.com Thu May 19 12:07:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:07:49 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJ7jF3011437 for ; Thu, 19 May 2005 12:07:45 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JJ76ua490976 for ; Thu, 19 May 2005 15:07:06 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JJ76OG187672 for ; Thu, 19 May 2005 13:07:06 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JJ75W8001995 for ; Thu, 19 May 2005 13:07:06 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JJ75Qw001953; Thu, 19 May 2005 13:07:05 -0600 From: Jon Mason Organization: IBM To: "David S. Miller" Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones Date: Thu, 19 May 2005 14:07:04 -0500 User-Agent: KMail/1.7.2 Cc: util@deuroconsult.ro, netdev@oss.sgi.com References: <200505191106.53136.jdmason@us.ibm.com> <200505191247.55138.jdmason@us.ibm.com> <20050519.115832.111205328.davem@davemloft.net> In-Reply-To: <20050519.115832.111205328.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505191407.04650.jdmason@us.ibm.com> X-archive-position: 1383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 995 Lines: 23 On Thursday 19 May 2005 01:58 pm, David S. Miller wrote: > From: Jon Mason > Date: Thu, 19 May 2005 12:47:55 -0500 > > > My point is that some features the user might want enabled regardless of > > whether all devices support them. An example of this is where a system > > has hardware checksum support for all devices except one. In this case, > > it would be benefitial to have this device do the checksum in software > > (via skb_checksum_help() call in dev_queue_xmit()). > > If "SG and checksumming is so common these days" as others have > stated, what you are describing is a totally uncommon scenerio. Uncommon, yes, but very possible and I am trying to mitigate the performance effects of this case. > What > Catalin is proposing is infinitely better than what we have today. I completely agree Catalin's patch is better than what we have now. My only arguement is that there are some cases where it should be augmented to include additional features. From davem@davemloft.net Thu May 19 12:22:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:22:20 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJM9F3015946 for ; Thu, 19 May 2005 12:22:11 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqaF-0000ap-Jb; Thu, 19 May 2005 12:21:27 -0700 Date: Thu, 19 May 2005 12:21:27 -0700 (PDT) Message-Id: <20050519.122127.74747706.davem@davemloft.net> To: jdmason@us.ibm.com Cc: util@deuroconsult.ro, netdev@oss.sgi.com Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones From: "David S. Miller" In-Reply-To: <20050519190032.GA19620@us.ibm.com> References: <200505191106.53136.jdmason@us.ibm.com> <20050519190032.GA19620@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 531 Lines: 16 From: Jon Mason Date: Thu, 19 May 2005 14:00:32 -0500 > I combined my previous patch with your patch, and came up with the > following. I have tested it on my system, and it works exactly the way > I wanted. What do you think? Look, let's do this. Do an initial patch that only does enables features possible on all devices. Because we all agree that is a definite improvement from the current situation. Then we can discuss the relative merits of enabling features available on only some devices. Ok? From davem@davemloft.net Thu May 19 12:28:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:28:39 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJSZF3016513 for ; Thu, 19 May 2005 12:28:35 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqgW-0000bu-6Q; Thu, 19 May 2005 12:27:56 -0700 Date: Thu, 19 May 2005 12:27:56 -0700 (PDT) Message-Id: <20050519.122756.41635751.davem@davemloft.net> To: hch@lst.de Cc: netdev@oss.sgi.com Subject: Re: [PATCH] use lookup_create in af_unix From: "David S. Miller" In-Reply-To: <20050512102336.GA26628@lst.de> References: <20050512102336.GA26628@lst.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1385 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 517 Lines: 16 From: Christoph Hellwig Date: Thu, 12 May 2005 12:23:36 +0200 > currently it opencodes it, but that's in the way of chaning the > lookup_hash interface. > > I'd prefer to disallow modular af_unix over exporting lookup_create, > but I'll leave that to you. > > Signed-off-by: Christoph Hellwig This patch looks fine. Applied, thanks Chirstophe. Maybe someone should add to the comments above these fs/namei.c functions that they will return with the semaphore held even in error cases. From hch@lst.de Thu May 19 12:30:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:30:55 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJUpF3017047 for ; Thu, 19 May 2005 12:30:51 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4JJU66t028761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 21:30:06 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j4JJU6OI028759; Thu, 19 May 2005 21:30:06 +0200 Date: Thu, 19 May 2005 21:30:06 +0200 From: Christoph Hellwig To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] use lookup_create in af_unix Message-ID: <20050519193006.GA28725@lst.de> References: <20050512102336.GA26628@lst.de> <20050519.122756.41635751.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050519.122756.41635751.davem@davemloft.net> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 321 Lines: 7 On Thu, May 19, 2005 at 12:27:56PM -0700, David S. Miller wrote: > Maybe someone should add to the comments above these fs/namei.c > functions that they will return with the semaphore held even > in error cases. I sent a patch to Andrew that adds this comment and various others that were in af_unix.c to lookup_create. From davem@davemloft.net Thu May 19 12:30:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:31:00 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJUuF3017083 for ; Thu, 19 May 2005 12:30:56 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqim-0000ca-8j; Thu, 19 May 2005 12:30:16 -0700 Date: Thu, 19 May 2005 12:30:16 -0700 (PDT) Message-Id: <20050519.123016.37533248.davem@davemloft.net> To: ja@ssi.bg Cc: netdev@oss.sgi.com, wensong@linux-vs.org Subject: Re: [PATCH] ipvs: remove extra __ip_vs_conn_put for incoming ICMP From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 323 Lines: 9 From: Julian Anastasov Date: Sat, 14 May 2005 10:57:26 +0300 (EEST) > Remove extra __ip_vs_conn_put for incoming ICMP in direct routing > mode. Mark de Vries reports that IPVS connections are not leaked anymore. > > Signed-off-by: Julian Anastasov Applied to 2.6.x, thanks for the patch Julian. From davem@davemloft.net Thu May 19 12:34:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:34:49 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJYjF3018144 for ; Thu, 19 May 2005 12:34:45 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqmU-0000du-W6; Thu, 19 May 2005 12:34:07 -0700 Date: Thu, 19 May 2005 12:34:06 -0700 (PDT) Message-Id: <20050519.123406.36924424.davem@davemloft.net> To: hch@lst.de Cc: netdev@oss.sgi.com Subject: Re: [PATCH] use lookup_create in af_unix From: "David S. Miller" In-Reply-To: <20050519193006.GA28725@lst.de> References: <20050512102336.GA26628@lst.de> <20050519.122756.41635751.davem@davemloft.net> <20050519193006.GA28725@lst.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 217 Lines: 7 From: Christoph Hellwig Date: Thu, 19 May 2005 21:30:06 +0200 > I sent a patch to Andrew that adds this comment and various others that > were in af_unix.c to lookup_create. That's great, thanks a lot. From davem@davemloft.net Thu May 19 12:36:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:36:18 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJaDF3018655 for ; Thu, 19 May 2005 12:36:13 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqnr-0000eC-0c; Thu, 19 May 2005 12:35:31 -0700 Date: Thu, 19 May 2005 12:35:30 -0700 (PDT) Message-Id: <20050519.123530.55508893.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames From: "David S. Miller" In-Reply-To: <20050516010058.GA20704@gondor.apana.org.au> References: <20050515235913.GA20242@gondor.apana.org.au> <20050515.173944.122590923.davem@davemloft.net> <20050516010058.GA20704@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1633 Lines: 67 From: Herbert Xu Date: Mon, 16 May 2005 11:00:58 +1000 [ For other readers, Herbert and I are discussing ip_ct_gather_frags(). ] > On Sun, May 15, 2005 at 05:39:44PM -0700, David S. Miller wrote: > > > > This code should therefore just skb_orphan(), and nothing > > more. Right? > > Ideally we should move the ownership to the head skb here as well. > However, doing this would cause havoc when you have nasty users > sending fragments from two different sockets :) > > So let's stick with just the skb_orphan. Ok, based upon this I am adding the following patch to my tree. Thanks. --- 1/net/ipv4/netfilter/ip_conntrack_core.c.~1~ 2005-05-18 22:45:26.000000000 -0700 +++ 2/net/ipv4/netfilter/ip_conntrack_core.c 2005-05-19 12:32:26.000000000 -0700 @@ -940,37 +940,25 @@ struct sk_buff * ip_ct_gather_frags(struct sk_buff *skb, u_int32_t user) { - struct sock *sk = skb->sk; #ifdef CONFIG_NETFILTER_DEBUG unsigned int olddebug = skb->nf_debug; #endif - if (sk) { - sock_hold(sk); - skb_orphan(skb); - } + skb_orphan(skb); local_bh_disable(); skb = ip_defrag(skb, user); local_bh_enable(); - if (!skb) { - if (sk) - sock_put(sk); - return skb; - } - - if (sk) { - skb_set_owner_w(skb, sk); - sock_put(sk); - } - - ip_send_check(skb->nh.iph); - skb->nfcache |= NFC_ALTERED; + if (skb) { + ip_send_check(skb->nh.iph); + skb->nfcache |= NFC_ALTERED; #ifdef CONFIG_NETFILTER_DEBUG - /* Packet path as if nothing had happened. */ - skb->nf_debug = olddebug; + /* Packet path as if nothing had happened. */ + skb->nf_debug = olddebug; #endif + } + return skb; } From davem@davemloft.net Thu May 19 12:40:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:40:58 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJesF3019365 for ; Thu, 19 May 2005 12:40:54 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqsS-0001I9-DR; Thu, 19 May 2005 12:40:16 -0700 Date: Thu, 19 May 2005 12:40:15 -0700 (PDT) Message-Id: <20050519.124015.122255786.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Fixed alg_key_len usage in attach_one_algo From: "David S. Miller" In-Reply-To: <20050519020302.GA20285@gondor.apana.org.au> References: <20050519020302.GA20285@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 457 Lines: 15 From: Herbert Xu Date: Thu, 19 May 2005 12:03:02 +1000 > This bug was discovered by a Linux box running in a remote corner > of Australia :) Hehe :-) > The variable alg_key_len is in bits and not bytes. The function > attach_one_algo is currently using it as if it were in bytes. > This causes it to read memory which may not be there. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From davem@davemloft.net Thu May 19 12:41:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:41:42 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJfcF3019573 for ; Thu, 19 May 2005 12:41:38 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqt9-0001LF-Cy; Thu, 19 May 2005 12:40:59 -0700 Date: Thu, 19 May 2005 12:40:59 -0700 (PDT) Message-Id: <20050519.124059.85410159.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Verify key payload in verify_one_algo From: "David S. Miller" In-Reply-To: <20050519021505.GA20703@gondor.apana.org.au> References: <20050519020302.GA20285@gondor.apana.org.au> <20050519021505.GA20703@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 472 Lines: 13 From: Herbert Xu Date: Thu, 19 May 2005 12:15:05 +1000 > We need to verify that the payload contains enough data so that > attach_one_algo can copy alg_key_len bits from the payload. > > Signed-off-by: Herbert Xu Also applied, thanks again. I gather from these two patches that once you found the first problem you went around auditing alg_key_len usage and these were the only two bugs you spotted. Right? From davem@davemloft.net Thu May 19 12:43:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:43:45 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJhfF3020434 for ; Thu, 19 May 2005 12:43:41 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqv7-0001Lm-Qy; Thu, 19 May 2005 12:43:01 -0700 Date: Thu, 19 May 2005 12:43:01 -0700 (PDT) Message-Id: <20050519.124301.39157305.davem@davemloft.net> To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: patch: small fixup From: "David S. Miller" In-Reply-To: <1116462970.6240.9.camel@localhost.localdomain> References: <1116462970.6240.9.camel@localhost.localdomain> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 421 Lines: 15 From: jamal Date: Wed, 18 May 2005 20:36:10 -0400 > My first git patch (dangerously knowledgeable after 30 minutes of > snorting blobs;->) against net-2.6.git. Consider this an excuse to send > a git patch ;-> :-) > Fixup simple action define to be consistent with other net/sched files > > Signed-off-by: Jamal Hadi Salim Applied, please supply an email in your signed-off line next time, thanks. From davem@davemloft.net Thu May 19 12:48:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:48:16 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJm7F3021451 for ; Thu, 19 May 2005 12:48:13 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYqzE-0001Mf-Lm; Thu, 19 May 2005 12:47:16 -0700 Date: Thu, 19 May 2005 12:47:16 -0700 (PDT) Message-Id: <20050519.124716.74565187.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: tommy.christensen@tpack.net, chamas@h4.dion.ne.jp, netdev@oss.sgi.com Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) From: "David S. Miller" In-Reply-To: <20050511222210.GA21280@gondor.apana.org.au> References: <20050511005836.GA1674@gondor.apana.org.au> <4282846F.6070403@tpack.net> <20050511222210.GA21280@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 556 Lines: 14 From: Herbert Xu Date: Thu, 12 May 2005 08:22:10 +1000 > > What about an alternative fix, that avoids even more cloning (where > > possible)? This resurrects the skb_orphan call that was moved out, last > > time we had 'shared-skb troubles'. It is practically a no-op in the > > common case, but still prevents the possible race with recvmsg. > > (And I have a weakness for one-line-fixes). :-) > > Yep this is much better. Thanks Tommy. > > Acked-by: Herbert Xu Applied, thanks a lot guys. From davem@davemloft.net Thu May 19 12:50:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 12:50:07 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JJo2F3022004 for ; Thu, 19 May 2005 12:50:02 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYr1F-0001ND-KS; Thu, 19 May 2005 12:49:21 -0700 Date: Thu, 19 May 2005 12:49:21 -0700 (PDT) Message-Id: <20050519.124921.115910096.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: tommy.christensen@tpack.net, chamas@h4.dion.ne.jp, netdev@oss.sgi.com Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) From: "David S. Miller" In-Reply-To: <20050512110738.GA5937@gondor.apana.org.au> References: <20050512104229.GB25631@gondor.apana.org.au> <1115895482.30106.95.camel@tsc-6.cph.tpack.net> <20050512110738.GA5937@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 372 Lines: 11 From: Herbert Xu Date: Thu, 12 May 2005 21:07:38 +1000 > On Thu, May 12, 2005 at 12:58:03PM +0200, Tommy Christensen wrote: > > > > Signed-off-by: Tommy S. Christensen > > Acked-by: Herbert Xu Hmmm, should I undo Tommy's one-liner skb_orphan() change then add this one instead? From davem@davemloft.net Thu May 19 13:09:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 13:09:58 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JK9jF3023641 for ; Thu, 19 May 2005 13:09:45 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYrKF-0001TC-Pw; Thu, 19 May 2005 13:08:59 -0700 Date: Thu, 19 May 2005 13:08:59 -0700 (PDT) Message-Id: <20050519.130859.115641546.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: tommy.christensen@tpack.net, netdev@oss.sgi.com, chamas@h4.dion.ne.jp Subject: Re: [PATCH] netlink: defer socket destruction a bit From: "David S. Miller" In-Reply-To: <20050512103639.GA25631@gondor.apana.org.au> References: <20050511230309.GA21547@gondor.apana.org.au> <1115891821.30106.86.camel@tsc-6.cph.tpack.net> <20050512103639.GA25631@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1589 Lines: 56 From: Herbert Xu Date: Thu, 12 May 2005 20:36:39 +1000 > On Thu, May 12, 2005 at 11:57:01AM +0200, Tommy Christensen wrote: > > > > I moved the call to skb_orphan in the other patch, as you > > suggested. I think that also makes this patch safe as it is. > > > > Right? > > Indeed it is. This also means that we don't hold onto the skb's > share of rmalloc quota for an excessive amount of time if the > number of broadcast sockets is large. Ok, I think I got all the patches straight. All of Tommy's patches combined together look like this diff in my tree. Please double check it. Thanks. diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -735,11 +735,15 @@ static inline int do_one_broadcast(struc sock_hold(sk); if (p->skb2 == NULL) { - if (atomic_read(&p->skb->users) != 1) { + if (skb_shared(p->skb)) { p->skb2 = skb_clone(p->skb, p->allocation); } else { - p->skb2 = p->skb; - atomic_inc(&p->skb->users); + p->skb2 = skb_get(p->skb); + /* + * skb ownership may have been set when + * delivered to a previous socket. + */ + skb_orphan(p->skb2); } } if (p->skb2 == NULL) { @@ -785,11 +789,12 @@ int netlink_broadcast(struct sock *ssk, sk_for_each_bound(sk, node, &nl_table[ssk->sk_protocol].mc_list) do_one_broadcast(sk, &info); + kfree_skb(skb); + netlink_unlock_table(); if (info.skb2) kfree_skb(info.skb2); - kfree_skb(skb); if (info.delivered) { if (info.congested && (allocation & __GFP_WAIT)) From jdmason@us.ibm.com Thu May 19 13:21:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 13:21:39 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JKLPF3024386 for ; Thu, 19 May 2005 13:21:35 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JKKkcE028776 for ; Thu, 19 May 2005 16:20:46 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JKKkcs258846 for ; Thu, 19 May 2005 14:20:46 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JKKj89017525 for ; Thu, 19 May 2005 14:20:46 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JKKjnn017501; Thu, 19 May 2005 14:20:45 -0600 From: Jon Mason Organization: IBM To: "David S. Miller" Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones Date: Thu, 19 May 2005 15:20:44 -0500 User-Agent: KMail/1.7.2 Cc: util@deuroconsult.ro, netdev@oss.sgi.com References: <200505191106.53136.jdmason@us.ibm.com> <20050519190032.GA19620@us.ibm.com> <20050519.122127.74747706.davem@davemloft.net> In-Reply-To: <20050519.122127.74747706.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505191520.44653.jdmason@us.ibm.com> X-archive-position: 1396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 643 Lines: 19 On Thursday 19 May 2005 02:21 pm, David S. Miller wrote: > From: Jon Mason > Date: Thu, 19 May 2005 14:00:32 -0500 > > > I combined my previous patch with your patch, and came up with the > > following. I have tested it on my system, and it works exactly the way > > I wanted. What do you think? > > Look, let's do this. Do an initial patch that only does > enables features possible on all devices. Because we > all agree that is a definite improvement from the current > situation. > > Then we can discuss the relative merits of enabling features > available on only some devices. > > Ok? That is acceptable to me. From shemminger@osdl.org Thu May 19 13:34:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 13:34:24 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JKYCF3025358 for ; Thu, 19 May 2005 13:34:12 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4JKXXU3013385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 13:33:33 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4JKXXEm007647; Thu, 19 May 2005 13:33:33 -0700 Date: Thu, 19 May 2005 13:33:33 -0700 From: Stephen Hemminger To: Jon Mason Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming Message-ID: <20050519133333.07a992e6@dxpl.pdx.osdl.net> In-Reply-To: <20050518235329.GA17946@us.ibm.com> References: <20050518235329.GA17946@us.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 658 Lines: 17 Here is a somewhat different patch from 2.6.12-rc4-bridge http://developer.osdl.org/shemminger/patches/2.6.12-rc4-bridge/ The bridge doesn't need locking, or checksumming and can allow highdma buffers; all of which are handled by net/core/dev.c if needed. =================================================================== --- netem-2.6.12-rc4.orig/net/bridge/br_device.c +++ netem-2.6.12-rc4/net/bridge/br_device.c @@ -101,4 +99,6 @@ void br_dev_setup(struct net_device *dev dev->tx_queue_len = 0; dev->set_mac_address = NULL; dev->priv_flags = IFF_EBRIDGE; + dev->features |= NETIF_F_SG | NETIF_F_NO_CSUM + | NETIF_F_HIGHDMA | NETIF_F_LLTX; } From shemminger@osdl.org Thu May 19 13:35:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 13:35:19 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JKZGF3025584 for ; Thu, 19 May 2005 13:35:16 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4JKYbU3013426 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 13:34:37 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4JKYb1n007687; Thu, 19 May 2005 13:34:37 -0700 Date: Thu, 19 May 2005 13:34:37 -0700 From: Stephen Hemminger To: Nivedita Singhvi Cc: "David S. Miller" , jdmason@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming Message-ID: <20050519133437.0c28eb36@dxpl.pdx.osdl.net> In-Reply-To: <428CAD24.904@us.ibm.com> References: <20050518235329.GA17946@us.ibm.com> <428BD7E7.5080207@us.ibm.com> <20050518.220031.75189050.davem@davemloft.net> <428CAD24.904@us.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 624 Lines: 18 On Thu, 19 May 2005 08:13:40 -0700 Nivedita Singhvi wrote: > David S. Miller wrote: > > >>I think this is a good thing to have, gives us performance > >>gain (equivalent to using/not using checksum offload) and > >>has very little impact on the bridging layer, and is > >>independent of the virtualization stuff.. > > > > > > I agree but keep in mind that when bridging over non-checksumming > > devices it will be more expensive. Especially for TCP. > > Yep - as I just said to Herbert - perhaps worthwhile then > conditional upon support of checksum offload & SG? What about mixed device bridges? From shemminger@osdl.org Thu May 19 13:40:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 13:40:47 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JKegF3026500 for ; Thu, 19 May 2005 13:40:42 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4JKdxU3013840 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 13:40:00 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4JKdxaX007903; Thu, 19 May 2005 13:39:59 -0700 Date: Thu, 19 May 2005 13:39:59 -0700 From: Stephen Hemminger To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) Message-ID: <20050519133959.566989da@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 514 Lines: 16 On Thu, 19 May 2005 18:28:26 +0300 (EEST) "Catalin(ux aka Dino) BOIE" wrote: > Hello! > > The attached patch, makes the bridge to select features (almost all) only > if _all_ devices supports them. > The patch was tested (create a bridge, add an interface, remove the > interface and always check features flags). > > What do you think? > > Signed-off-by: Catalin(ux aka Dino) BOIE Okay, but just open code this, don't need BR_FEAT_MASK and br_features_change. From niv@us.ibm.com Thu May 19 13:43:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 13:43:43 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JKhbF3027015 for ; Thu, 19 May 2005 13:43:38 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JKgxmD630860 for ; Thu, 19 May 2005 16:42:59 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JKgxOG240570 for ; Thu, 19 May 2005 14:42:59 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JKgwOn026760 for ; Thu, 19 May 2005 14:42:58 -0600 Received: from [9.49.131.1] (sig-9-49-131-1.mts.ibm.com [9.49.131.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JKgvTh026718; Thu, 19 May 2005 14:42:57 -0600 Message-ID: <428CFA57.1020501@us.ibm.com> Date: Thu, 19 May 2005 13:43:03 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: herbert@gondor.apana.org.au, jdmason@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming References: <428CAC55.4000202@us.ibm.com> <20050519.115141.21926463.davem@davemloft.net> In-Reply-To: <20050519.115141.21926463.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 944 Lines: 31 David S. Miller wrote: > I think instead we should look at ways to propagate > the hardware device features to the bridge. Even if > a bridge is composed of multiple devices, we just > advertise the subset of features actually supported. Just for some background: In the typical Xen virtual environment, the primary interface is typically bridged with virtual interfaces that talk to other partitions. Since currently the bridge doesn't advertise them, this results in the loss of hw checksum offload, segmentation offload, and sendfile exploitation (sendfile() falls down to the usual tcp_sendmsg() case) etc on the primary partition traffic talking to remote hosts. This can be rather painful, and performance comparisons with other OSs which don't do this are even more of an apples to oranges comparison since this is somewhat silently happening. Hence the need for enhancing the bridging environment somewhat :). thanks, Nivedita From shemminger@osdl.org Thu May 19 14:21:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 14:21:05 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLL2F3029974 for ; Thu, 19 May 2005 14:21:02 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4JLKJU3016683 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 14:20:20 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4JLKJmA009751; Thu, 19 May 2005 14:20:19 -0700 Date: Thu, 19 May 2005 14:20:19 -0700 From: Stephen Hemminger To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) Message-ID: <20050519142019.5963f1c9@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 93 Lines: 1 Also NETIF_F_LLTX should always be set on the bridge, independent of what devices are in it. From herbert@gondor.apana.org.au Thu May 19 14:35:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 14:36:00 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLZsF3032228 for ; Thu, 19 May 2005 14:35:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYsfU-0007mW-00; Fri, 20 May 2005 07:35:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYsfR-0006Hz-00; Fri, 20 May 2005 07:34:57 +1000 Date: Fri, 20 May 2005 07:34:57 +1000 To: "David S. Miller" Cc: tommy.christensen@tpack.net, chamas@h4.dion.ne.jp, netdev@oss.sgi.com Subject: Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122) Message-ID: <20050519213457.GB24024@gondor.apana.org.au> References: <20050512104229.GB25631@gondor.apana.org.au> <1115895482.30106.95.camel@tsc-6.cph.tpack.net> <20050512110738.GA5937@gondor.apana.org.au> <20050519.124921.115910096.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050519.124921.115910096.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 727 Lines: 21 On Thu, May 19, 2005 at 12:49:21PM -0700, David S. Miller wrote: > From: Herbert Xu > Date: Thu, 12 May 2005 21:07:38 +1000 > > > On Thu, May 12, 2005 at 12:58:03PM +0200, Tommy Christensen wrote: > > > > > > Signed-off-by: Tommy S. Christensen > > > > Acked-by: Herbert Xu > > Hmmm, should I undo Tommy's one-liner skb_orphan() change > then add this one instead? Please do since the first one had a subtle bug. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu May 19 14:35:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 14:35:06 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLYwF3032025 for ; Thu, 19 May 2005 14:34:59 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYsel-0007lt-00; Fri, 20 May 2005 07:34:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYsej-0006Ha-00; Fri, 20 May 2005 07:34:13 +1000 Date: Fri, 20 May 2005 07:34:13 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Verify key payload in verify_one_algo Message-ID: <20050519213413.GA24024@gondor.apana.org.au> References: <20050519020302.GA20285@gondor.apana.org.au> <20050519021505.GA20703@gondor.apana.org.au> <20050519.124059.85410159.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050519.124059.85410159.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 470 Lines: 14 On Thu, May 19, 2005 at 12:40:59PM -0700, David S. Miller wrote: > > I gather from these two patches that once you found the > first problem you went around auditing alg_key_len usage > and these were the only two bugs you spotted. Right? Correct. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu May 19 14:39:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 14:39:31 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLdQF3001267 for ; Thu, 19 May 2005 14:39:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYsj2-0007oS-00; Fri, 20 May 2005 07:38:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYsj1-0006Ig-00; Fri, 20 May 2005 07:38:39 +1000 Date: Fri, 20 May 2005 07:38:39 +1000 To: "David S. Miller" Cc: tommy.christensen@tpack.net, netdev@oss.sgi.com, chamas@h4.dion.ne.jp Subject: Re: [PATCH] netlink: defer socket destruction a bit Message-ID: <20050519213839.GC24024@gondor.apana.org.au> References: <20050511230309.GA21547@gondor.apana.org.au> <1115891821.30106.86.camel@tsc-6.cph.tpack.net> <20050512103639.GA25631@gondor.apana.org.au> <20050519.130859.115641546.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050519.130859.115641546.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1404 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1479 Lines: 49 On Thu, May 19, 2005 at 01:08:59PM -0700, David S. Miller wrote: > > Ok, I think I got all the patches straight. All of Tommy's > patches combined together look like this diff in my tree. > Please double check it. Yes this is the one. > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c > --- a/net/netlink/af_netlink.c > +++ b/net/netlink/af_netlink.c > @@ -735,11 +735,15 @@ static inline int do_one_broadcast(struc > > sock_hold(sk); > if (p->skb2 == NULL) { > - if (atomic_read(&p->skb->users) != 1) { > + if (skb_shared(p->skb)) { > p->skb2 = skb_clone(p->skb, p->allocation); > } else { > - p->skb2 = p->skb; > - atomic_inc(&p->skb->users); > + p->skb2 = skb_get(p->skb); > + /* > + * skb ownership may have been set when > + * delivered to a previous socket. > + */ > + skb_orphan(p->skb2); > } > } > if (p->skb2 == NULL) { > @@ -785,11 +789,12 @@ int netlink_broadcast(struct sock *ssk, > sk_for_each_bound(sk, node, &nl_table[ssk->sk_protocol].mc_list) > do_one_broadcast(sk, &info); > > + kfree_skb(skb); > + > netlink_unlock_table(); > > if (info.skb2) > kfree_skb(info.skb2); > - kfree_skb(skb); > > if (info.delivered) { > if (info.congested && (allocation & __GFP_WAIT)) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jdmason@us.ibm.com Thu May 19 14:41:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 14:41:09 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLexF3001997 for ; Thu, 19 May 2005 14:41:00 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JLeL0c827734 for ; Thu, 19 May 2005 17:40:21 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JLeLOG196502 for ; Thu, 19 May 2005 15:40:21 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JLeLvU024992 for ; Thu, 19 May 2005 15:40:21 -0600 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JLeKLO024967; Thu, 19 May 2005 15:40:20 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.10) with ESMTP id j4JLeKbR223336; Thu, 19 May 2005 16:40:20 -0500 Received: from dreadnought (dreadnought.austin.ibm.com [9.53.90.32]) by popmail.austin.ibm.com (AIX5.1/8.11.6p2/8.9.3) with SMTP id j4JLeFU884682; Thu, 19 May 2005 16:40:19 -0500 Received: by dreadnought (sSMTP sendmail emulation); Thu, 19 May 2005 16:40:15 -0500 Date: Thu, 19 May 2005 16:40:15 -0500 From: Jon Mason To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) Message-ID: <20050519214015.GA19961@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-archive-position: 1405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3134 Lines: 98 On Thu, May 19, 2005 at 06:28:26PM +0300, Catalin(ux aka Dino) BOIE wrote: > Hello! > > The attached patch, makes the bridge to select features (almost all) only > if _all_ devices supports them. > The patch was tested (create a bridge, add an interface, remove the > interface and always check features flags). > > What do you think? > > Signed-off-by: Catalin(ux aka Dino) BOIE > --- > Catalin(ux aka Dino) BOIE > catab at deuroconsult.ro > http://kernel.umbrella.ro/ > --- bridge1/net/bridge/br_private.h 2005-03-02 09:37:50.000000000 +0200 > +++ linux/net/bridge/br_private.h 2005-05-19 18:00:05.000000000 +0300 > @@ -27,6 +27,10 @@ > #define BR_PORT_BITS 10 > #define BR_MAX_PORTS (1< > +#define BR_FEAT_MASK (NETIF_F_HW_CSUM | NETIF_F_SG \ > + | NETIF_F_FRAGLIST | NETIF_F_IP_CSUM \ > + | NETIF_F_HIGHDMA | NETIF_F_TSO) > + > typedef struct bridge_id bridge_id; > typedef struct mac_addr mac_addr; > typedef __u16 port_id; > --- bridge1/net/bridge/br_device.c 2005-03-02 09:37:30.000000000 +0200 > +++ linux/net/bridge/br_device.c 2005-05-19 17:14:21.000000000 +0300 > @@ -107,4 +107,5 @@ void br_dev_setup(struct net_device *dev > dev->tx_queue_len = 0; > dev->set_mac_address = NULL; > dev->priv_flags = IFF_EBRIDGE; > + dev->features = BR_FEAT_MASK; > } > --- bridge1/net/bridge/br_if.c 2005-03-02 09:38:33.000000000 +0200 > +++ linux/net/bridge/br_if.c 2005-05-19 18:21:39.000000000 +0300 > @@ -314,6 +314,27 @@ int br_min_mtu(const struct net_bridge * > return mtu; > } > > +/* > + * If slave device (@dev) doesn't support special features, > + * turn them off globally. > + */ > +static inline void br_features_change(struct net_bridge *br, struct net_device *dev) > +{ > + br->dev->features &= dev->features | ~BR_FEAT_MASK; ~BR_FEAT_MASK isn't necessary. Either you wanted to do an '&' just before it, so that BR_FEAT_MASK features are the only ones that you want or you are enabling features that aren't necessarily supported by the adapter/driver (like LLTX and HW_VLAN stuff). > +} > + > +/* > + * Recomputes features using slave's features > + */ > +static void br_features_recompute(struct net_bridge *br) > +{ > + struct net_bridge_port *p; > + > + br->dev->features |= BR_FEAT_MASK; The OR is not needed. Just re-initialize features to BR_FEAT_MASK and everything will take case of itself. > + list_for_each_entry(p, &br->port_list, list) > + br_features_change(br, p->dev); > +} > + > /* called with RTNL */ > int br_add_if(struct net_bridge *br, struct net_device *dev) > { > @@ -332,9 +353,10 @@ int br_add_if(struct net_bridge *br, str > if (IS_ERR(p = new_nbp(br, dev, br_initial_port_cost(dev)))) > return PTR_ERR(p); > > + br_features_change(br, dev); > + > if ((err = br_fdb_insert(br, p, dev->dev_addr, 1))) > destroy_nbp(p); > - > else if ((err = br_sysfs_addif(p))) > del_nbp(p); > else { > @@ -368,6 +390,7 @@ int br_del_if(struct net_bridge *br, str > > spin_lock_bh(&br->lock); > br_stp_recalculate_bridge_id(br); > + br_features_recompute(br); > spin_unlock_bh(&br->lock); > > return 0; From herbert@gondor.apana.org.au Thu May 19 14:49:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 14:49:37 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLnTF3004784 for ; Thu, 19 May 2005 14:49:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DYssj-0007xd-00; Fri, 20 May 2005 07:48:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DYssg-0006Km-00; Fri, 20 May 2005 07:48:38 +1000 Date: Fri, 20 May 2005 07:48:38 +1000 To: "David S. Miller" Cc: johnpol@2ka.mipt.ru, netdev@oss.sgi.com Subject: Re: [IPV4/IPV6] Keep wmem accounting separate in ip*_push_pending_frames Message-ID: <20050519214838.GD24024@gondor.apana.org.au> References: <20050515235913.GA20242@gondor.apana.org.au> <20050515.173944.122590923.davem@davemloft.net> <20050516010058.GA20704@gondor.apana.org.au> <20050519.123530.55508893.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050519.123530.55508893.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1496 Lines: 59 On Thu, May 19, 2005 at 12:35:30PM -0700, David S. Miller wrote: > > Ok, based upon this I am adding the following patch to my > tree. Thanks. Thanks Dave, this looks good to me. > --- 1/net/ipv4/netfilter/ip_conntrack_core.c.~1~ 2005-05-18 22:45:26.000000000 -0700 > +++ 2/net/ipv4/netfilter/ip_conntrack_core.c 2005-05-19 12:32:26.000000000 -0700 > @@ -940,37 +940,25 @@ > struct sk_buff * > ip_ct_gather_frags(struct sk_buff *skb, u_int32_t user) > { > - struct sock *sk = skb->sk; > #ifdef CONFIG_NETFILTER_DEBUG > unsigned int olddebug = skb->nf_debug; > #endif > > - if (sk) { > - sock_hold(sk); > - skb_orphan(skb); > - } > + skb_orphan(skb); > > local_bh_disable(); > skb = ip_defrag(skb, user); > local_bh_enable(); > > - if (!skb) { > - if (sk) > - sock_put(sk); > - return skb; > - } > - > - if (sk) { > - skb_set_owner_w(skb, sk); > - sock_put(sk); > - } > - > - ip_send_check(skb->nh.iph); > - skb->nfcache |= NFC_ALTERED; > + if (skb) { > + ip_send_check(skb->nh.iph); > + skb->nfcache |= NFC_ALTERED; > #ifdef CONFIG_NETFILTER_DEBUG > - /* Packet path as if nothing had happened. */ > - skb->nf_debug = olddebug; > + /* Packet path as if nothing had happened. */ > + skb->nf_debug = olddebug; > #endif > + } > + > return skb; > } -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Thu May 19 14:48:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 14:48:59 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JLmiF3004686 for ; Thu, 19 May 2005 14:48:45 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYss4-0003F9-Kl; Thu, 19 May 2005 14:48:00 -0700 Date: Thu, 19 May 2005 14:48:00 -0700 (PDT) Message-Id: <20050519.144800.71090042.davem@davemloft.net> To: shemminger@osdl.org Cc: jdmason@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming From: "David S. Miller" In-Reply-To: <20050519133333.07a992e6@dxpl.pdx.osdl.net> References: <20050518235329.GA17946@us.ibm.com> <20050519133333.07a992e6@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1296 Lines: 28 From: Stephen Hemminger Date: Thu, 19 May 2005 13:33:33 -0700 > The bridge doesn't need locking, or checksumming and can allow highdma > buffers; all of which are handled by net/core/dev.c if needed. As discuesed elsewhere, this handling by net/core/dev.c makes TCP sending much more expensive when it is actually used. Furthermore, I just found another hole in the idea to propagate sub-device features into the bridge device. If one device has NETIF_F_HW_CSUM and the others have NETIF_F_IP_CSUM, both bits will be set in the bridge device and things will entirely break. The two checksumming on output schemes are different, and all of the stack assumes that only one of these two bits are set. I have such a setup in two of my sparc64 systems (sunhme does NETIF_F_HW_CSUM, and tg3 does NETIF_F_IP_CSUM). Also, my PowerMAC G5 has this problem too, the onboard sungem chip does NETIF_F_HW_CSUM and the tg3 I have in a PCI slot does NETIF_F_P_CSUM. So given that half the machines I have powered on right here could trigger the problem, it's far from theoretical :-) There are multiple spots that want to do this kind of stuff now (bridging, vlan, bonding) which indicates that some sort of common infrastructure should be written to implement this kind of stuff. From shemminger@osdl.org Thu May 19 15:13:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 15:13:41 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JMDYF3008729 for ; Thu, 19 May 2005 15:13:36 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4JMCoU3020505 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 15:12:51 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4JMCoJd012245; Thu, 19 May 2005 15:12:50 -0700 Date: Thu, 19 May 2005 15:12:50 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, netem@lists.osdl.org Subject: [PATCH] (1/3) netem - reinsert for duplication Message-ID: <20050519151250.17ab5c81@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2527 Lines: 82 Handle duplication of packets in netem by re-inserting at top of qdisc tree. This avoid problems with qlen accounting with nested qdisc. This recursion requires no additional locking but will potentially increase stack depth. Signed-off-by: Stephen Hemminger Index: netem-2.6.12-rc4/net/sched/sch_netem.c =================================================================== --- netem-2.6.12-rc4.orig/net/sched/sch_netem.c +++ netem-2.6.12-rc4/net/sched/sch_netem.c @@ -203,42 +203,47 @@ static int netem_run(struct Qdisc *sch) return 0; } +/* + * Insert one skb into qdisc. + * Note: parent depends on return value to account for queue length. + * NET_XMIT_DROP: queue length didn't change. + * NET_XMIT_SUCCESS: one skb was queued. + */ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); + struct sk_buff *skb2; int ret; + int count = 1; pr_debug("netem_enqueue skb=%p\n", skb); + /* Random duplication */ + if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor)) + ++count; + /* Random packet drop 0 => none, ~0 => all */ - if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { - pr_debug("netem_enqueue: random loss\n"); + if (q->loss && q->loss >= get_crandom(&q->loss_cor)) + --count; + + if (count == 0) { sch->qstats.drops++; kfree_skb(skb); - return 0; /* lie about loss so TCP doesn't know */ + return NET_XMIT_DROP; } - /* Random duplication */ - if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor)) { - struct sk_buff *skb2; + /* + * If we need to duplicate packet, then re-insert at top of the + * qdisc tree, since parent queuer expects that only one + * skb will be queued. + */ + if (count > 1 && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { + struct Qdisc *rootq = sch->dev->qdisc; + u32 dupsave = q->duplicate; /* prevent duplicating a dup... */ + q->duplicate = 0; - skb2 = skb_clone(skb, GFP_ATOMIC); - if (skb2 && netem_delay(sch, skb2) == NET_XMIT_SUCCESS) { - struct Qdisc *qp; - - /* Since one packet can generate two packets in the - * queue, the parent's qlen accounting gets confused, - * so fix it. - */ - qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); - if (qp) - qp->q.qlen++; - - sch->q.qlen++; - sch->bstats.bytes += skb2->len; - sch->bstats.packets++; - } else - sch->qstats.drops++; + rootq->enqueue(skb2, rootq); + q->duplicate = dupsave; } /* If doing simple delay then gap == 0 so all packets From shemminger@osdl.org Thu May 19 15:13:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 15:13:44 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JMDdF3008740 for ; Thu, 19 May 2005 15:13:40 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4JMCsU3020515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 15:12:54 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4JMCsrq012250; Thu, 19 May 2005 15:12:54 -0700 Date: Thu, 19 May 2005 15:12:54 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, netem@osdl.org Subject: [PATCH] (3/3) netem: allow random reordering Message-ID: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4516 Lines: 157 Enhance the reorder feature of netem to allow random percent to be reordered. Has expected backwards compatibility behaviour. Signed-off-by: Stephen Hemminger Index: netem-2.6.12-rc4/include/linux/pkt_sched.h =================================================================== --- netem-2.6.12-rc4.orig/include/linux/pkt_sched.h +++ netem-2.6.12-rc4/include/linux/pkt_sched.h @@ -427,6 +427,7 @@ enum TCA_NETEM_UNSPEC, TCA_NETEM_CORR, TCA_NETEM_DELAY_DIST, + TCA_NETEM_REORDER, __TCA_NETEM_MAX, }; @@ -437,7 +438,7 @@ struct tc_netem_qopt __u32 latency; /* added delay (us) */ __u32 limit; /* fifo limit (packets) */ __u32 loss; /* random packet loss (0=none ~0=100%) */ - __u32 gap; /* re-ordering gap (0 for delay all) */ + __u32 gap; /* re-ordering gap (0 for none) */ __u32 duplicate; /* random packet dup (0=none ~0=100%) */ __u32 jitter; /* random jitter in latency (us) */ }; @@ -449,6 +450,12 @@ struct tc_netem_corr __u32 dup_corr; /* duplicate correlation */ }; +struct tc_netem_reorder +{ + __u32 probability; + __u32 correlation; +}; + #define NETEM_DIST_SCALE 8192 #endif Index: netem-2.6.12-rc4/net/sched/sch_netem.c =================================================================== --- netem-2.6.12-rc4.orig/net/sched/sch_netem.c +++ netem-2.6.12-rc4/net/sched/sch_netem.c @@ -62,11 +62,12 @@ struct netem_sched_data { u32 gap; u32 jitter; u32 duplicate; + u32 reorder; struct crndstate { unsigned long last; unsigned long rho; - } delay_cor, loss_cor, dup_cor; + } delay_cor, loss_cor, dup_cor, reorder_cor; struct disttable { u32 size; @@ -185,18 +186,18 @@ static int netem_enqueue(struct sk_buff * of the queue. * gap == 0 is special case for no-reordering. */ - if (q->gap == 0 || q->counter != q->gap) { + if (q->gap == 0 && q->counter < q->gap && + q->reorder < get_crandom(&q->reorder_cor)) { psched_time_t now; PSCHED_GET_TIME(now); - PSCHED_TADD2(now, - tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist), + PSCHED_TADD2(now, tabledist(q->latency, q->jitter, + &q->delay_cor, q->delay_dist), cb->time_to_send); - ++q->counter; ret = q->qdisc->enqueue(skb, q->qdisc); } else { - q->counter = 0; PSCHED_GET_TIME(cb->time_to_send); + q->counter = 0; ret = q->qdisc->ops->requeue(skb, q->qdisc); } @@ -351,6 +352,19 @@ static int get_correlation(struct Qdisc return 0; } +static int get_reorder(struct Qdisc *sch, const struct rtattr *attr) +{ + struct netem_sched_data *q = qdisc_priv(sch); + const struct tc_netem_reorder *r = RTA_DATA(attr); + + if (RTA_PAYLOAD(attr) != sizeof(*r)) + return -EINVAL; + + q->reorder = r->probability; + init_crandom(&q->reorder_cor, r->correlation); + return 0; +} + static int netem_change(struct Qdisc *sch, struct rtattr *opt) { struct netem_sched_data *q = qdisc_priv(sch); @@ -371,9 +385,15 @@ static int netem_change(struct Qdisc *sc q->jitter = qopt->jitter; q->limit = qopt->limit; q->gap = qopt->gap; + q->counter = 0; q->loss = qopt->loss; q->duplicate = qopt->duplicate; + /* for compatiablity with earlier versions. + * if gap is set, need to assume 100% probablity + */ + q->reorder = ~0; + /* Handle nested options after initial queue options. * Should have put all options in nested format but too late now. */ @@ -395,6 +415,11 @@ static int netem_change(struct Qdisc *sc if (ret) return ret; } + if (tb[TCA_NETEM_REORDER-1]) { + ret = get_reorder(sch, tb[TCA_NETEM_REORDER-1]); + if (ret) + return ret; + } } @@ -412,7 +437,6 @@ static int netem_init(struct Qdisc *sch, init_timer(&q->timer); q->timer.function = netem_watchdog; q->timer.data = (unsigned long) sch; - q->counter = 0; q->qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); if (!q->qdisc) { @@ -444,6 +468,7 @@ static int netem_dump(struct Qdisc *sch, struct rtattr *rta = (struct rtattr *) b; struct tc_netem_qopt qopt; struct tc_netem_corr cor; + struct tc_netem_reorder reorder; qopt.latency = q->latency; qopt.jitter = q->jitter; @@ -457,6 +482,11 @@ static int netem_dump(struct Qdisc *sch, cor.loss_corr = q->loss_cor.rho; cor.dup_corr = q->dup_cor.rho; RTA_PUT(skb, TCA_NETEM_CORR, sizeof(cor), &cor); + + reorder.probability = q->reorder; + reorder.correlation = q->reorder_cor.rho; + RTA_PUT(skb, TCA_NETEM_REORDER, sizeof(reorder), &reorder); + rta->rta_len = skb->tail - b; return skb->len; From shemminger@osdl.org Thu May 19 15:13:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 15:13:46 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JMDcF3008737 for ; Thu, 19 May 2005 15:13:39 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4JMCqU3020509 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 15:12:53 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4JMCq7m012248; Thu, 19 May 2005 15:12:52 -0700 Date: Thu, 19 May 2005 15:12:52 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, netem@osdl.org Subject: [PATCH] (2/3) netem: use only inner qdisc -- no private skbuff queue Message-ID: <20050519151252.6cbbf0b7@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 6001 Lines: 204 Netem works better if there if packets are just queued in the inner discipline rather than having a separate delayed queue. Change to use the dequeue/requeue to peek like TBF does. By doing this potential qlen problems with the old method are avoided. The problems happened when the netem_run that moved packets from the inner discipline to the nested discipline failed (because inner queue was full). This happened in dequeue, so the effective qlen of the netem would be decreased (because of the drop), but there was no way to keep the outer qdisc (caller of netem dequeue) in sync. The problem window is still there since this patch doesn't address the issue of requeue failing in netem_dequeue, but that shouldn't happen since the sequence dequeue/requeue should always work. Long term correct fix is to implement qdisc->peek in all the qdisc's to allow for this (needed by several other qdisc's as well). Signed-off-by: Stephen Hemminger Index: netem-2.6.12-rc4/net/sched/sch_netem.c =================================================================== --- netem-2.6.12-rc4.orig/net/sched/sch_netem.c +++ netem-2.6.12-rc4/net/sched/sch_netem.c @@ -53,7 +53,6 @@ struct netem_sched_data { struct Qdisc *qdisc; - struct sk_buff_head delayed; struct timer_list timer; u32 latency; @@ -137,72 +136,6 @@ static long tabledist(unsigned long mu, return x / NETEM_DIST_SCALE + (sigma / NETEM_DIST_SCALE) * t + mu; } -/* Put skb in the private delayed queue. */ -static int netem_delay(struct Qdisc *sch, struct sk_buff *skb) -{ - struct netem_sched_data *q = qdisc_priv(sch); - psched_tdiff_t td; - psched_time_t now; - - PSCHED_GET_TIME(now); - td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist); - - /* Always queue at tail to keep packets in order */ - if (likely(q->delayed.qlen < q->limit)) { - struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; - - PSCHED_TADD2(now, td, cb->time_to_send); - - pr_debug("netem_delay: skb=%p now=%llu tosend=%llu\n", skb, - now, cb->time_to_send); - - __skb_queue_tail(&q->delayed, skb); - return NET_XMIT_SUCCESS; - } - - pr_debug("netem_delay: queue over limit %d\n", q->limit); - sch->qstats.overlimits++; - kfree_skb(skb); - return NET_XMIT_DROP; -} - -/* - * Move a packet that is ready to send from the delay holding - * list to the underlying qdisc. - */ -static int netem_run(struct Qdisc *sch) -{ - struct netem_sched_data *q = qdisc_priv(sch); - struct sk_buff *skb; - psched_time_t now; - - PSCHED_GET_TIME(now); - - skb = skb_peek(&q->delayed); - if (skb) { - const struct netem_skb_cb *cb - = (const struct netem_skb_cb *)skb->cb; - long delay - = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); - pr_debug("netem_run: skb=%p delay=%ld\n", skb, delay); - - /* if more time remaining? */ - if (delay > 0) { - mod_timer(&q->timer, jiffies + delay); - return 1; - } - - __skb_unlink(skb, &q->delayed); - - if (q->qdisc->enqueue(skb, q->qdisc)) { - sch->q.qlen--; - sch->qstats.drops++; - } - } - - return 0; -} - /* * Insert one skb into qdisc. * Note: parent depends on return value to account for queue length. @@ -212,6 +145,7 @@ static int netem_run(struct Qdisc *sch) static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; struct sk_buff *skb2; int ret; int count = 1; @@ -246,18 +180,24 @@ static int netem_enqueue(struct sk_buff q->duplicate = dupsave; } - /* If doing simple delay then gap == 0 so all packets - * go into the delayed holding queue - * otherwise if doing out of order only "1 out of gap" - * packets will be delayed. + /* + * Do re-ordering by putting one out of N packets at the front + * of the queue. + * gap == 0 is special case for no-reordering. */ - if (q->counter < q->gap) { + if (q->gap == 0 || q->counter != q->gap) { + psched_time_t now; + PSCHED_GET_TIME(now); + PSCHED_TADD2(now, + tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist), + cb->time_to_send); + ++q->counter; ret = q->qdisc->enqueue(skb, q->qdisc); } else { q->counter = 0; - ret = netem_delay(sch, skb); - netem_run(sch); + PSCHED_GET_TIME(cb->time_to_send); + ret = q->qdisc->ops->requeue(skb, q->qdisc); } if (likely(ret == NET_XMIT_SUCCESS)) { @@ -301,22 +241,33 @@ static struct sk_buff *netem_dequeue(str { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb; - int pending; - - pending = netem_run(sch); skb = q->qdisc->dequeue(q->qdisc); if (skb) { - pr_debug("netem_dequeue: return skb=%p\n", skb); - sch->q.qlen--; - sch->flags &= ~TCQ_F_THROTTLED; - } - else if (pending) { - pr_debug("netem_dequeue: throttling\n"); + const struct netem_skb_cb *cb + = (const struct netem_skb_cb *)skb->cb; + psched_time_t now; + long delay; + + /* if more time remaining? */ + PSCHED_GET_TIME(now); + delay = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_run: skb=%p delay=%ld\n", skb, delay); + if (delay <= 0) { + pr_debug("netem_dequeue: return skb=%p\n", skb); + sch->q.qlen--; + sch->flags &= ~TCQ_F_THROTTLED; + return skb; + } + + mod_timer(&q->timer, jiffies + delay); sch->flags |= TCQ_F_THROTTLED; - } - return skb; + if (q->qdisc->ops->requeue(skb, q->qdisc) != 0) + sch->qstats.drops++; + } + + return NULL; } static void netem_watchdog(unsigned long arg) @@ -333,8 +284,6 @@ static void netem_reset(struct Qdisc *sc struct netem_sched_data *q = qdisc_priv(sch); qdisc_reset(q->qdisc); - skb_queue_purge(&q->delayed); - sch->q.qlen = 0; sch->flags &= ~TCQ_F_THROTTLED; del_timer_sync(&q->timer); @@ -460,7 +409,6 @@ static int netem_init(struct Qdisc *sch, if (!opt) return -EINVAL; - skb_queue_head_init(&q->delayed); init_timer(&q->timer); q->timer.function = netem_watchdog; q->timer.data = (unsigned long) sch; From tommy.christensen@tpack.net Thu May 19 16:14:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 16:14:03 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4JNDxF3012338 for ; Thu, 19 May 2005 16:14:00 -0700 Received: (qmail 26856 invoked from network); 19 May 2005 23:13:18 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.1) by 0 with SMTP; 19 May 2005 23:13:18 -0000 Message-ID: <428D1E19.9030204@tpack.net> Date: Fri, 20 May 2005 01:15:37 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com, chamas@h4.dion.ne.jp Subject: Re: [PATCH] netlink: defer socket destruction a bit References: <20050511230309.GA21547@gondor.apana.org.au> <1115891821.30106.86.camel@tsc-6.cph.tpack.net> <20050512103639.GA25631@gondor.apana.org.au> <20050519.130859.115641546.davem@davemloft.net> <20050519213839.GC24024@gondor.apana.org.au> In-Reply-To: <20050519213839.GC24024@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 321 Lines: 13 Herbert Xu wrote: > On Thu, May 19, 2005 at 01:08:59PM -0700, David S. Miller wrote: > >>Ok, I think I got all the patches straight. All of Tommy's >>patches combined together look like this diff in my tree. >>Please double check it. > > Yes this is the one. Yup. This combination fixes both problems. Thanks, Tommy From davem@davemloft.net Thu May 19 16:16:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 16:16:58 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JNGsF3012829 for ; Thu, 19 May 2005 16:16:54 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYuFO-0000cP-3b; Thu, 19 May 2005 16:16:10 -0700 Date: Thu, 19 May 2005 16:16:09 -0700 (PDT) Message-Id: <20050519.161609.00748235.davem@davemloft.net> To: tommy.christensen@tpack.net Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, chamas@h4.dion.ne.jp Subject: Re: [PATCH] netlink: defer socket destruction a bit From: "David S. Miller" In-Reply-To: <428D1E19.9030204@tpack.net> References: <20050519.130859.115641546.davem@davemloft.net> <20050519213839.GC24024@gondor.apana.org.au> <428D1E19.9030204@tpack.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 531 Lines: 16 From: Tommy Christensen Subject: Re: [PATCH] netlink: defer socket destruction a bit Date: Fri, 20 May 2005 01:15:37 +0200 > Herbert Xu wrote: > > On Thu, May 19, 2005 at 01:08:59PM -0700, David S. Miller wrote: > > > >>Ok, I think I got all the patches straight. All of Tommy's > >>patches combined together look like this diff in my tree. > >>Please double check it. > > > > Yes this is the one. > > Yup. This combination fixes both problems. Thanks a lot for double checking, both of you :-) From jdmason@us.ibm.com Thu May 19 16:24:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 16:24:21 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JNOHF3017084 for ; Thu, 19 May 2005 16:24:17 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4JNNccE448052 for ; Thu, 19 May 2005 19:23:38 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4JNNXcs250134 for ; Thu, 19 May 2005 17:23:33 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4JNNWCa024614 for ; Thu, 19 May 2005 17:23:33 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4JNNWfl024611; Thu, 19 May 2005 17:23:32 -0600 From: Jon Mason Organization: IBM To: "David S. Miller" Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming Date: Thu, 19 May 2005 18:23:31 -0500 User-Agent: KMail/1.7.2 Cc: shemminger@osdl.org, netdev@oss.sgi.com References: <20050518235329.GA17946@us.ibm.com> <20050519133333.07a992e6@dxpl.pdx.osdl.net> <20050519.144800.71090042.davem@davemloft.net> In-Reply-To: <20050519.144800.71090042.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505191823.31777.jdmason@us.ibm.com> X-archive-position: 1413 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1575 Lines: 35 On Thursday 19 May 2005 04:48 pm, David S. Miller wrote: > From: Stephen Hemminger > Date: Thu, 19 May 2005 13:33:33 -0700 > > > The bridge doesn't need locking, or checksumming and can allow highdma > > buffers; all of which are handled by net/core/dev.c if needed. > > As discuesed elsewhere, this handling by net/core/dev.c makes > TCP sending much more expensive when it is actually used. > > Furthermore, I just found another hole in the idea to propagate > sub-device features into the bridge device. > > If one device has NETIF_F_HW_CSUM and the others have NETIF_F_IP_CSUM, > both bits will be set in the bridge device and things will entirely > break. The two checksumming on output schemes are different, and all > of the stack assumes that only one of these two bits are set. > > I have such a setup in two of my sparc64 systems (sunhme does > NETIF_F_HW_CSUM, and tg3 does NETIF_F_IP_CSUM). Also, my PowerMAC G5 > has this problem too, the onboard sungem chip does NETIF_F_HW_CSUM and > the tg3 I have in a PCI slot does NETIF_F_IP_CSUM. So given that > half the machines I have powered on right here could trigger the > problem, it's far from theoretical :-) > > There are multiple spots that want to do this kind of stuff > now (bridging, vlan, bonding) which indicates that some sort > of common infrastructure should be written to implement this > kind of stuff. Since NETIF_F_HW_CSUM encompasses NETIF_F_IP_CSUM, perhaps it would be better to use the latter until such time as a new infrastructure can be implimented. Thanks, Jon From shemminger@osdl.org Thu May 19 16:33:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 16:33:17 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JNXEF3017836 for ; Thu, 19 May 2005 16:33:14 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4JNWYU3026884 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 16:32:35 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4JNWYvq016274; Thu, 19 May 2005 16:32:34 -0700 Date: Thu, 19 May 2005 16:32:35 -0700 From: Stephen Hemminger To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [Netem] [PATCH] (1/3) netem - reinsert for duplication Message-ID: <20050519163235.2f5db193@dxpl.pdx.osdl.net> In-Reply-To: <20050519151250.17ab5c81@dxpl.pdx.osdl.net> References: <20050519151250.17ab5c81@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 541 Lines: 12 On Thu, 19 May 2005 15:12:50 -0700 Stephen Hemminger wrote: > Handle duplication of packets in netem by re-inserting at top of qdisc tree. > This avoid problems with qlen accounting with nested qdisc. This recursion > requires no additional locking but will potentially increase stack depth. > > Signed-off-by: Stephen Hemminger > Hold off on applying these patches until next week, I am seeing some timing anomalies when using this for TCP testing, and not sure if these patches are related. From davem@davemloft.net Thu May 19 16:38:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 16:38:21 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JNcIF3018520 for ; Thu, 19 May 2005 16:38:18 -0700 Received: from localhost ([127.0.0.1]) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYuaC-00010K-7w; Thu, 19 May 2005 16:37:40 -0700 Date: Thu, 19 May 2005 16:37:10 -0700 (PDT) Message-Id: <20050519.163710.71087722.davem@davemloft.net> To: shemminger@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [Netem] [PATCH] (1/3) netem - reinsert for duplication From: "David S. Miller" In-Reply-To: <20050519163235.2f5db193@dxpl.pdx.osdl.net> References: <20050519151250.17ab5c81@dxpl.pdx.osdl.net> <20050519163235.2f5db193@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1416 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 258 Lines: 8 From: Stephen Hemminger Date: Thu, 19 May 2005 16:32:35 -0700 > Hold off on applying these patches until next week, I am seeing some > timing anomalies when using this for TCP testing, and not sure if > these patches are related. Ok. From davem@davemloft.net Thu May 19 16:37:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 16:37:49 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4JNbfF3018475 for ; Thu, 19 May 2005 16:37:41 -0700 Received: from localhost ([127.0.0.1]) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYuZV-000102-Ff; Thu, 19 May 2005 16:36:57 -0700 Date: Thu, 19 May 2005 16:36:27 -0700 (PDT) Message-Id: <20050519.163627.92582487.davem@davemloft.net> To: jdmason@us.ibm.com Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming From: "David S. Miller" In-Reply-To: <200505191823.31777.jdmason@us.ibm.com> References: <20050519133333.07a992e6@dxpl.pdx.osdl.net> <20050519.144800.71090042.davem@davemloft.net> <200505191823.31777.jdmason@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 317 Lines: 10 From: Jon Mason Date: Thu, 19 May 2005 18:23:31 -0500 > Since NETIF_F_HW_CSUM encompasses NETIF_F_IP_CSUM, perhaps it would > be better to use the latter until such time as a new infrastructure > can be implimented. Probably, that is the best idea, it is again another definition of "subset". From leonid.grossman@neterion.com Thu May 19 17:16:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 17:16:49 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K0GhF3020493 for ; Thu, 19 May 2005 17:16:44 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j4K0FSOC011169; Thu, 19 May 2005 20:15:28 -0400 (EDT) Received: from lgt40 ([10.16.16.54]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j4K0FNVG005262; Thu, 19 May 2005 20:15:24 -0400 (EDT) Message-Id: <200505200015.j4K0FNVG005262@guinness.s2io.com> From: "Leonid Grossman" To: "'David S. Miller'" Cc: Subject: RE: [PATCH] Super TSO Date: Thu, 19 May 2005 17:15:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVbUNbZ4kpsuIduTriuU6mXc6BULQBfKuJg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050517.192416.108741581.davem@davemloft.net> X-Scanned-By: MIMEDefang 2.34 X-archive-position: 1417 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 41589 Lines: 1315 A somewhat related thought, while we are at it... It would arguably make sense to allow a NIC to set max TSO size that the card is willing to support (rather than assume/enforce 64k). Some NICs support bigger max TSO size today, but it is even more important to allow a NIC to limit TSO to a smaller size. One likely scenario where this feature is desirable is a system with highly fragmented memory. In this case, the number of physical fragments per TSO frame could be always so high that it will be cheaper (on a given platform) to copy the frame than to DMA it. In this case, 64k TSO becomes a liability and it will make sense to limit it. TSO "sweet spot" will be captured anyways - at least on fast networks, going from 1.5k to 9k typically doubles throughput, while going from 9k to 64k adds no more than another 10% (plus a little bit of free %cpu, but not that much). > -----Original Message----- > From: netdev-bounce@oss.sgi.com > [mailto:netdev-bounce@oss.sgi.com] On Behalf Of David S. Miller > Sent: Tuesday, May 17, 2005 7:24 PM > To: netdev@oss.sgi.com > Subject: [PATCH] Super TSO > > > Ok, this implements the idea Herbert and I kicked around last week. > > Basically, we build as large TSO segments as humanly possible. > Then we slice and dice them to fit the congestion and send > windows at transmit time. > > It works remarkably well. Even application limited cases > like "scp" behave nicely. > > During straight streaming tests like "bw_tcp", I see full > "65535 MOD mss" sized frames going out to my onboard tg3 card > once the congestion and send window grow large enough. > > I did some cross-continent (San Francisco --> east coast of > US) transfers to make sure TSO stays on when packet drops > occur and that performance doesn't suffer compared to TSO > being off. It all looks fine so far. > > There were many bugs discovered along the way. For example, > the old code would use the TSO mss to do nagle calculations. > It also would mess up the packet sizing for TSO when SACK > blocks were being advertised. > > So we don't have to calculate this "(65535 - headers) % mss" > thing all the time, I keep a cache of three pieces of state. > MSS, number of SACKS being advertized, and if TSO is enabled > or not. If any of these change, we recalculate the packet > building goal size. > > I moved all of the "should we send" logic privately into the > file net/ipv4/tcp_output.c, and I am sure there are many > simplifications possible. There are several spurious > tcp_current_mss() calls scattered about in certain code paths > as well. For example, some places would call it in order to > decide whether to call tcp_write_xmit() or not, then > tcp_write_xmit() does it once more. But there are call sites > that do not do this, so tcp_write_xmit() has to do it for those cases. > > Comments? > > --- 1/include/linux/tcp.h.~1~ 2005-05-16 22:29:56.000000000 -0700 > +++ 2/include/linux/tcp.h 2005-05-17 11:15:46.000000000 -0700 > @@ -280,13 +280,15 @@ struct tcp_sock { > __u32 snd_wnd; /* The window we expect to > receive */ > __u32 max_window; /* Maximal window ever seen > from peer */ > __u32 pmtu_cookie; /* Last pmtu seen by socket > */ > - __u32 mss_cache; /* Cached effective mss, not > including SACKS */ > - __u16 mss_cache_std; /* Like mss_cache, but without TSO */ > + __u16 mss_cache; /* Cached effective mss, not > including SACKS */ > + __u16 xmit_size_goal; /* Goal for segmenting output > packets */ > + __u32 xmit_size_cache;/* Cache for keeping > xmit_size_goal uptodate */ > __u16 ext_header_len; /* Network protocol overhead > (IP/IPv6 options) */ > __u8 ca_state; /* State of fast-retransmit > machine */ > __u8 retransmits; /* Number of unrecovered RTO > timeouts. */ > > __u16 advmss; /* Advertised MSS > */ > + __u16 __pad0; > __u32 window_clamp; /* Maximal window to advertise > */ > __u32 rcv_ssthresh; /* Current window clamp > */ > > --- 1/include/net/tcp.h.~1~ 2005-05-16 22:29:56.000000000 -0700 > +++ 2/include/net/tcp.h 2005-05-17 16:44:32.000000000 -0700 > @@ -817,11 +817,18 @@ static inline int tcp_ack_scheduled(stru > return tp->ack.pending&TCP_ACK_SCHED; > } > > -static __inline__ void tcp_dec_quickack_mode(struct tcp_sock *tp) > +static __inline__ void tcp_dec_quickack_mode(struct tcp_sock *tp, > +unsigned int pkts) > { > - if (tp->ack.quick && --tp->ack.quick == 0) { > - /* Leaving quickack mode we deflate ATO. */ > - tp->ack.ato = TCP_ATO_MIN; > + if (tp->ack.quick) { > + if (pkts > tp->ack.quick) > + tp->ack.quick = 0; > + else > + tp->ack.quick -= pkts; > + > + if (!tp->ack.quick) { > + /* Leaving quickack mode we deflate ATO. */ > + tp->ack.ato = TCP_ATO_MIN; > + } > } > } > > @@ -939,7 +946,14 @@ extern __u32 cookie_v4_init_sequence(str > > /* tcp_output.c */ > > -extern int tcp_write_xmit(struct sock *, int nonagle); > +extern void __tcp_data_snd_check(struct sock *sk, struct > sk_buff *skb); > +extern void __tcp_push_pending_frames(struct sock *sk, > + struct tcp_sock *tp, > + unsigned int cur_mss, > + int nonagle); > +extern int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp); > +extern int tcp_tso_mince(struct sock *sk, struct tcp_sock *tp, > + struct sk_buff *skb); > extern int tcp_retransmit_skb(struct sock *, struct sk_buff > *); extern void tcp_xmit_retransmit_queue(struct sock *); > extern void tcp_simple_retransmit(struct sock *); @@ -951,7 > +965,7 @@ extern int tcp_write_wakeup(struct sock extern > void tcp_send_fin(struct sock *sk); extern void > tcp_send_active_reset(struct sock *sk, int priority); extern > int tcp_send_synack(struct sock *); -extern void > tcp_push_one(struct sock *, unsigned mss_now); > +extern void tcp_push_one(struct sock *, unsigned int mss_now); > extern void tcp_send_ack(struct sock *sk); extern void > tcp_send_delayed_ack(struct sock *sk); > > @@ -1054,7 +1068,7 @@ static inline void > tcp_reset_xmit_timer( static inline void > tcp_initialize_rcv_mss(struct sock *sk) { > struct tcp_sock *tp = tcp_sk(sk); > - unsigned int hint = min(tp->advmss, tp->mss_cache_std); > + unsigned int hint = min(tp->advmss, tp->mss_cache); > > hint = min(hint, tp->rcv_wnd/2); > hint = min(hint, TCP_MIN_RCVMSS); > @@ -1353,23 +1367,23 @@ static inline void tcp_cwnd_validate(str } > > /* Set slow start threshould and cwnd not falling to slow > start */ -static inline void __tcp_enter_cwr(struct tcp_sock *tp) > +static inline void __tcp_enter_cwr(struct tcp_sock *tp, unsigned int > +pkts) > { > tp->undo_marker = 0; > tp->snd_ssthresh = tcp_recalc_ssthresh(tp); > tp->snd_cwnd = min(tp->snd_cwnd, > - tcp_packets_in_flight(tp) + 1U); > + tcp_packets_in_flight(tp) + pkts); > tp->snd_cwnd_cnt = 0; > tp->high_seq = tp->snd_nxt; > tp->snd_cwnd_stamp = tcp_time_stamp; > TCP_ECN_queue_cwr(tp); > } > > -static inline void tcp_enter_cwr(struct tcp_sock *tp) > +static inline void tcp_enter_cwr(struct tcp_sock *tp, unsigned int > +pkts) > { > tp->prior_ssthresh = 0; > if (tp->ca_state < TCP_CA_CWR) { > - __tcp_enter_cwr(tp); > + __tcp_enter_cwr(tp, pkts); > tcp_set_ca_state(tp, TCP_CA_CWR); > } > } > @@ -1397,74 +1411,6 @@ static __inline__ void tcp_minshall_upda > tp->snd_sml = TCP_SKB_CB(skb)->end_seq; } > > -/* Return 0, if packet can be sent now without violation > Nagle's rules: > - 1. It is full sized. > - 2. Or it contains FIN. > - 3. Or TCP_NODELAY was set. > - 4. Or TCP_CORK is not set, and all sent packets are ACKed. > - With Minshall's modification: all sent small packets are ACKed. > - */ > - > -static __inline__ int > -tcp_nagle_check(const struct tcp_sock *tp, const struct > sk_buff *skb, > - unsigned mss_now, int nonagle) > -{ > - return (skb->len < mss_now && > - !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && > - ((nonagle&TCP_NAGLE_CORK) || > - (!nonagle && > - tp->packets_out && > - tcp_minshall_check(tp)))); > -} > - > -extern void tcp_set_skb_tso_segs(struct sock *, struct sk_buff *); > - > -/* This checks if the data bearing packet SKB (usually > sk->sk_send_head) > - * should be put on the wire right now. > - */ > -static __inline__ int tcp_snd_test(struct sock *sk, > - struct sk_buff *skb, > - unsigned cur_mss, int nonagle) > -{ > - struct tcp_sock *tp = tcp_sk(sk); > - int pkts = tcp_skb_pcount(skb); > - > - if (!pkts) { > - tcp_set_skb_tso_segs(sk, skb); > - pkts = tcp_skb_pcount(skb); > - } > - > - /* RFC 1122 - section 4.2.3.4 > - * > - * We must queue if > - * > - * a) The right edge of this frame exceeds the window > - * b) There are packets in flight and we have a > small segment > - * [SWS avoidance and Nagle algorithm] > - * (part of SWS is done on packetization) > - * Minshall version sounds: there are no _small_ > - * segments in flight. (tcp_nagle_check) > - * c) We have too many packets 'in flight' > - * > - * Don't use the nagle rule for urgent data (or > - * for the final FIN -DaveM). > - * > - * Also, Nagle rule does not apply to frames, which > - * sit in the middle of queue (they have no chances > - * to get new data) and if room at tail of skb is > - * not enough to save something seriously (<32 for now). > - */ > - > - /* Don't be strict about the congestion window for the > - * final FIN frame. -DaveM > - */ > - return (((nonagle&TCP_NAGLE_PUSH) || tp->urg_mode > - || !tcp_nagle_check(tp, skb, cur_mss, nonagle)) && > - (((tcp_packets_in_flight(tp) + (pkts-1)) < > tp->snd_cwnd) || > - (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) && > - !after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + > tp->snd_wnd)); > -} > - > static __inline__ void tcp_check_probe_timer(struct sock > *sk, struct tcp_sock *tp) { > if (!tp->packets_out && !tp->pending) > @@ -1477,42 +1423,12 @@ static __inline__ int tcp_skb_is_last(co > return skb->next == (struct sk_buff *)&sk->sk_write_queue; } > > -/* Push out any pending frames which were held back due to > - * TCP_CORK or attempt at coalescing tiny packets. > - * The socket must be locked by the caller. > - */ > -static __inline__ void __tcp_push_pending_frames(struct sock *sk, > - struct tcp_sock *tp, > - unsigned cur_mss, > - int nonagle) > -{ > - struct sk_buff *skb = sk->sk_send_head; > - > - if (skb) { > - if (!tcp_skb_is_last(sk, skb)) > - nonagle = TCP_NAGLE_PUSH; > - if (!tcp_snd_test(sk, skb, cur_mss, nonagle) || > - tcp_write_xmit(sk, nonagle)) > - tcp_check_probe_timer(sk, tp); > - } > - tcp_cwnd_validate(sk, tp); > -} > - > static __inline__ void tcp_push_pending_frames(struct sock *sk, > struct tcp_sock *tp) > { > __tcp_push_pending_frames(sk, tp, tcp_current_mss(sk, > 1), tp->nonagle); } > > -static __inline__ int tcp_may_send_now(struct sock *sk, > struct tcp_sock *tp) -{ > - struct sk_buff *skb = sk->sk_send_head; > - > - return (skb && > - tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), > - tcp_skb_is_last(sk, skb) ? > TCP_NAGLE_PUSH : tp->nonagle)); > -} > - > static __inline__ void tcp_init_wl(struct tcp_sock *tp, u32 > ack, u32 seq) { > tp->snd_wl1 = seq; > @@ -1986,7 +1902,7 @@ static inline void > tcp_westwood_update_r static inline __u32 > __tcp_westwood_bw_rttmin(const struct tcp_sock *tp) { > return max((tp->westwood.bw_est) * (tp->westwood.rtt_min) / > - (__u32) (tp->mss_cache_std), > + (__u32) (tp->mss_cache), > 2U); > } > > --- 1/include/net/sock.h.~1~ 2005-05-16 22:29:56.000000000 -0700 > +++ 2/include/net/sock.h 2005-05-17 12:06:44.000000000 -0700 > @@ -1130,13 +1130,16 @@ static inline void > sk_stream_moderate_sn static inline struct sk_buff > *sk_stream_alloc_pskb(struct sock *sk, > int size, > int mem, int gfp) > { > - struct sk_buff *skb = alloc_skb(size + > sk->sk_prot->max_header, gfp); > + struct sk_buff *skb; > + int hdr_len; > > + hdr_len = SKB_DATA_ALIGN(sk->sk_prot->max_header); > + skb = alloc_skb(size + hdr_len, gfp); > if (skb) { > skb->truesize += mem; > if (sk->sk_forward_alloc >= (int)skb->truesize || > sk_stream_mem_schedule(sk, skb->truesize, 0)) { > - skb_reserve(skb, sk->sk_prot->max_header); > + skb_reserve(skb, hdr_len); > return skb; > } > __kfree_skb(skb); > --- 1/net/ipv4/tcp_output.c.~1~ 2005-05-16 > 22:29:56.000000000 -0700 > +++ 2/net/ipv4/tcp_output.c 2005-05-17 19:14:23.000000000 -0700 > @@ -141,11 +141,11 @@ static inline void tcp_event_data_sent(s > tp->ack.pingpong = 1; > } > > -static __inline__ void tcp_event_ack_sent(struct sock *sk) > +static __inline__ void tcp_event_ack_sent(struct sock *sk, > unsigned int > +pkts) > { > struct tcp_sock *tp = tcp_sk(sk); > > - tcp_dec_quickack_mode(tp); > + tcp_dec_quickack_mode(tp, pkts); > tcp_clear_xmit_timer(sk, TCP_TIME_DACK); } > > @@ -361,7 +361,7 @@ static int tcp_transmit_skb(struct sock > tp->af_specific->send_check(sk, th, skb->len, skb); > > if (tcb->flags & TCPCB_FLAG_ACK) > - tcp_event_ack_sent(sk); > + tcp_event_ack_sent(sk, tcp_skb_pcount(skb)); > > if (skb->len != tcp_header_size) > tcp_event_data_sent(tp, skb, sk); > @@ -372,7 +372,7 @@ static int tcp_transmit_skb(struct sock > if (err <= 0) > return err; > > - tcp_enter_cwr(tp); > + tcp_enter_cwr(tp, tcp_skb_pcount(skb)); > > /* NET_XMIT_CN is special. It does not guarantee, > * that this packet is lost. It tells that > device @@ -419,32 +419,11 @@ static inline void tcp_tso_set_push(stru > TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; } > > -/* Send _single_ skb sitting at the send head. This function requires > - * true push pending frames to setup probe timer etc. > - */ > -void tcp_push_one(struct sock *sk, unsigned cur_mss) -{ > - struct tcp_sock *tp = tcp_sk(sk); > - struct sk_buff *skb = sk->sk_send_head; > - > - if (tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH)) { > - /* Send it out now. */ > - TCP_SKB_CB(skb)->when = tcp_time_stamp; > - tcp_tso_set_push(skb); > - if (!tcp_transmit_skb(sk, skb_clone(skb, > sk->sk_allocation))) { > - sk->sk_send_head = NULL; > - tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; > - tcp_packets_out_inc(sk, tp, skb); > - return; > - } > - } > -} > - > void tcp_set_skb_tso_segs(struct sock *sk, struct sk_buff *skb) { > struct tcp_sock *tp = tcp_sk(sk); > > - if (skb->len <= tp->mss_cache_std || > + if (skb->len <= tp->mss_cache || > !(sk->sk_route_caps & NETIF_F_TSO)) { > /* Avoid the costly divide in the normal > * non-TSO case. > @@ -454,10 +433,10 @@ void tcp_set_skb_tso_segs(struct sock *s > } else { > unsigned int factor; > > - factor = skb->len + (tp->mss_cache_std - 1); > - factor /= tp->mss_cache_std; > + factor = skb->len + (tp->mss_cache - 1); > + factor /= tp->mss_cache; > skb_shinfo(skb)->tso_segs = factor; > - skb_shinfo(skb)->tso_size = tp->mss_cache_std; > + skb_shinfo(skb)->tso_size = tp->mss_cache; > } > } > > @@ -662,7 +641,7 @@ unsigned int tcp_sync_mss(struct sock *s > > /* And store cached results */ > tp->pmtu_cookie = pmtu; > - tp->mss_cache = tp->mss_cache_std = mss_now; > + tp->mss_cache = mss_now; > > return mss_now; > } > @@ -674,59 +653,274 @@ unsigned int tcp_sync_mss(struct sock *s > * cannot be large. However, taking into account rare use of > URG, this > * is not a big flaw. > */ > +static inline u32 compute_xmit_cache(u32 mss, int sacks, int > +tso_enabled) { > + u32 ret = (mss << 16) | sacks; > + > + if (tso_enabled) > + ret |= (1 << 8); > + > + return ret; > +} > > -unsigned int tcp_current_mss(struct sock *sk, int large) > +unsigned int tcp_current_mss(struct sock *sk, int large_allowed) > { > struct tcp_sock *tp = tcp_sk(sk); > struct dst_entry *dst = __sk_dst_get(sk); > - unsigned int do_large, mss_now; > + u32 mss_now; > + u32 xmit_cache; > + int doing_tso = 0; > + > + mss_now = tp->mss_cache; > + > + if (large_allowed && > + (sk->sk_route_caps & NETIF_F_TSO) && > + !tp->urg_mode) > + doing_tso = 1; > > - mss_now = tp->mss_cache_std; > if (dst) { > u32 mtu = dst_mtu(dst); > if (mtu != tp->pmtu_cookie) > mss_now = tcp_sync_mss(sk, mtu); > } > > - do_large = (large && > - (sk->sk_route_caps & NETIF_F_TSO) && > - !tp->urg_mode); > - > - if (do_large) { > - unsigned int large_mss, factor, limit; > - > - large_mss = 65535 - tp->af_specific->net_header_len - > - tp->ext_header_len - tp->tcp_header_len; > - > - if (tp->max_window && large_mss > (tp->max_window>>1)) > - large_mss = max((tp->max_window>>1), > - 68U - tp->tcp_header_len); > - > - factor = large_mss / mss_now; > - > - /* Always keep large mss multiple of real mss, but > - * do not exceed 1/tso_win_divisor of the > congestion window > - * so we can keep the ACK clock ticking and minimize > - * bursting. > - */ > - limit = tp->snd_cwnd; > - if (sysctl_tcp_tso_win_divisor) > - limit /= sysctl_tcp_tso_win_divisor; > - limit = max(1U, limit); > - if (factor > limit) > - factor = limit; > - > - tp->mss_cache = mss_now * factor; > - > - mss_now = tp->mss_cache; > - } > + /* If the MSS, the TSO state, or the number of SACK blocks > + * changes, we have to recompute tp->xmit_size_goal. > + */ > + xmit_cache = compute_xmit_cache(mss_now, tp->rx_opt.eff_sacks, > + doing_tso); > > if (tp->rx_opt.eff_sacks) > mss_now -= (TCPOLEN_SACK_BASE_ALIGNED + > (tp->rx_opt.eff_sacks * > TCPOLEN_SACK_PERBLOCK)); > + > + if (tp->xmit_size_cache != xmit_cache) { > + u16 xmit_size_goal = mss_now; > + > + if (doing_tso) { > + xmit_size_goal = 65535 - > + tp->af_specific->net_header_len - > + tp->ext_header_len - tp->tcp_header_len; > + > + if (tp->rx_opt.eff_sacks) > + xmit_size_goal -= > (TCPOLEN_SACK_BASE_ALIGNED + > + > (tp->rx_opt.eff_sacks * > + > TCPOLEN_SACK_PERBLOCK)); > + > + xmit_size_goal -= (xmit_size_goal % mss_now); > + } > + tp->xmit_size_goal = xmit_size_goal; > + tp->xmit_size_cache = xmit_cache; > + } > + > return mss_now; > } > > +/* This must be invoked the first time we consider transmitting > + * SKB onto the wire. > + */ > +static inline int tcp_init_tso_segs(struct sock *sk, struct sk_buff > +*skb) { > + int tso_segs = tcp_skb_pcount(skb); > + > + if (!tso_segs) { > + tcp_set_skb_tso_segs(sk, skb); > + tso_segs = tcp_skb_pcount(skb); > + } > + return tso_segs; > +} > + > +/* Return 0, if packet can be sent now without violation > Nagle's rules: > + * 1. It is full sized. > + * 2. Or it contains FIN. > + * 3. Or TCP_NODELAY was set. > + * 4. Or TCP_CORK is not set, and all sent packets are ACKed. > + * With Minshall's modification: all sent small packets are ACKed. > + */ > + > +static inline int tcp_nagle_check(const struct tcp_sock *tp, > + const struct sk_buff *skb, > + unsigned mss_now, int nonagle) > +{ > + return (skb->len < mss_now && > + !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && > + ((nonagle&TCP_NAGLE_CORK) || > + (!nonagle && > + tp->packets_out && > + tcp_minshall_check(tp)))); > +} > + > +/* Return non-zero if the Nagle test allows this packet to be > + * sent now. > + */ > +static inline int tcp_nagle_test(struct tcp_sock *tp, struct sk_buff > +*skb, unsigned int cur_mss, int nonagle) { > + /* Nagle rule does not apply to frames, which > + * sit in the middle of queue (they have no chances > + * to get new data) and if room at tail of skb is > + * not enough to save something seriously (<32 for now). > + * > + * This is implemented in the callers, where they modify > + * the 'nonagle' argument based upon the location of SKB > + * in the send queue. > + */ > + if (nonagle & TCP_NAGLE_PUSH) > + return 1; > + > + /* Don't use the nagle rule for urgent data (or > + * for the final FIN -DaveM). > + */ > + if (tp->urg_mode || > + (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) > + return 1; > + > + if (!tcp_nagle_check(tp, skb, cur_mss, nonagle)) > + return 1; > + > + return 0; > +} > + > +/* Can at least one segment of SKB be sent right now, according > + * to the congestion window rules? If so, return how many segments > + * are allowed. > + */ > +static inline unsigned int tcp_cwnd_test(struct tcp_sock *tp, struct > +sk_buff *skb) { > + u32 in_flight, cwnd; > + > + /* Don't be strict about the congestion window for the > + * final FIN frame. -DaveM > + */ > + if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) > + return 1; > + > + in_flight = tcp_packets_in_flight(tp); > + cwnd = tp->snd_cwnd; > + if (in_flight < cwnd) > + return (cwnd - in_flight); > + > + return 0; > +} > + > +/* Does at least the first segment of SKB fit into the congestion > + * window? > + */ > +static inline int tcp_snd_wnd_test(struct tcp_sock *tp, > struct sk_buff > +*skb, unsigned int cur_mss) { > + u32 end_seq = TCP_SKB_CB(skb)->end_seq; > + > + if (skb->len > cur_mss) > + end_seq = TCP_SKB_CB(skb)->seq + cur_mss; > + > + return !after(end_seq, tp->snd_una + tp->snd_wnd); } > + > +/* This checks if the data bearing packet SKB (usually > + * sk->sk_send_head) should be put on the wire right now. If so, it > + * returns the number of packets allowed by the congestion window. > + */ > +static unsigned int tcp_snd_test(struct sock *sk, struct > sk_buff *skb, > + unsigned cur_mss, int nonagle) > +{ > + struct tcp_sock *tp = tcp_sk(sk); > + unsigned int cwnd_quota; > + > + if (!tcp_nagle_test(tp, skb, cur_mss, nonagle)) > + return 0; > + > + cwnd_quota = tcp_cwnd_test(tp, skb); > + if (cwnd_quota && > + !tcp_snd_wnd_test(tp, skb, cur_mss)) > + cwnd_quota = 0; > + > + return cwnd_quota; > +} > + > +int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp) { > + struct sk_buff *skb = sk->sk_send_head; > + > + return (skb && > + tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), > + tcp_skb_is_last(sk, skb) ? > TCP_NAGLE_PUSH : tp->nonagle)); } > + > +/* Trim TSO SKB to LEN bytes, put the remaining data into a > new packet > + * which is put after SKB on the list. It is very much like > + * tcp_fragment() except that it may make several kinds of > assumptions > + * in order to speed up the splitting operation. In particular, we > + * know that all the data is in scatter-gather pages, and that the > + * packet has never been sent out before (and thus is not cloned). > + */ > +static int tso_fragment(struct sock *sk, struct sk_buff > *skb, unsigned > +int len) { > + struct sk_buff *buff; > + int nlen = skb->len - len; > + u16 flags; > + > + /* All of a TSO frame must be composed of paged data. */ > + BUG_ON(skb->len != skb->data_len); > + > + buff = sk_stream_alloc_pskb(sk, 0, 0, GFP_ATOMIC); > + if (unlikely(buff == NULL)) > + return -ENOMEM; > + sk_charge_skb(sk, buff); > + > + buff->truesize += nlen; > + skb->truesize -= nlen; > + > + /* Correct the sequence numbers. */ > + TCP_SKB_CB(buff)->seq = TCP_SKB_CB(skb)->seq + len; > + TCP_SKB_CB(buff)->end_seq = TCP_SKB_CB(skb)->end_seq; > + TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(buff)->seq; > + > + /* PSH and FIN should only be set in the second packet. */ > + flags = TCP_SKB_CB(skb)->flags; > + TCP_SKB_CB(skb)->flags = flags & > ~(TCPCB_FLAG_FIN|TCPCB_FLAG_PSH); > + TCP_SKB_CB(buff)->flags = flags; > + > + /* This packet was never sent out yet, so no SACK bits. */ > + TCP_SKB_CB(buff)->sacked = 0; > + > + buff->ip_summed = skb->ip_summed = CHECKSUM_HW; > + skb_split(skb, buff, len); > + > + /* Fix up tso_factor for both original and new SKB. */ > + tcp_set_skb_tso_segs(sk, skb); > + tcp_set_skb_tso_segs(sk, buff); > + > + /* Link BUFF into the send queue. */ > + __skb_append(skb, buff); > + > + return 0; > +} > + > +/* Split TSO frame SKB into one MSS sized packet, then the rest. > + * This is called during SACK processing when some SACK information > + * hits a TSO packet. > + */ > +int tcp_tso_mince(struct sock *sk, struct tcp_sock *tp, > struct sk_buff > +*skb) { > + unsigned int mss_now = tcp_current_mss(sk, 1); > + > + BUG_ON(tcp_skb_pcount(skb) <= 1); > + > + /* We cannot use tso_fragment() in this case, because > + * the packet has been sent once already and thus may > + * be cloned or have other non-trivial details to deal > + * with. > + */ > + return tcp_fragment(sk, skb, mss_now); } > + > +static inline unsigned int tso_size_limit(u32 window, unsigned int > +mss_now, unsigned int cwnd) { > + u32 cwnd_len; > + > + cwnd_len = mss_now * cwnd; > + return min(window, cwnd_len); > +} > + > /* This routine writes packets to the network. It advances the > * send_head. This happens as incoming acks open up the remote > * window for us. > @@ -734,57 +928,167 @@ unsigned int tcp_current_mss(struct sock > * Returns 1, if no segments are in flight and we have > queued segments, but > * cannot send anything now because of SWS or another problem. > */ > -int tcp_write_xmit(struct sock *sk, int nonagle) > +static int tcp_write_xmit(struct sock *sk, int nonagle) > { > struct tcp_sock *tp = tcp_sk(sk); > - unsigned int mss_now; > + unsigned int mss_now, cwnd_quota, sent_pkts, tso_segs; > + struct sk_buff *skb; > > /* If we are closed, the bytes will have to remain here. > * In time closedown will finish, we empty the write > queue and all > * will be happy. > */ > - if (sk->sk_state != TCP_CLOSE) { > - struct sk_buff *skb; > - int sent_pkts = 0; > + if (unlikely(sk->sk_state == TCP_CLOSE)) > + return 0; > > - /* Account for SACKS, we may need to fragment > due to this. > - * It is just like the real MSS changing on us > midstream. > - * We also handle things correctly when the > user adds some > - * IP options mid-stream. Silly to do, but cover it. > - */ > - mss_now = tcp_current_mss(sk, 1); > + /* Account for SACKS, we may need to fragment due to this. > + * It is just like the real MSS changing on us midstream. > + * We also handle things correctly when the user adds some > + * IP options mid-stream. Silly to do, but cover it. > + */ > + mss_now = tcp_current_mss(sk, 1); > + skb = sk->sk_send_head; > + if (unlikely(!skb)) > + return 0; > + > + tso_segs = tcp_init_tso_segs(sk, skb); > + cwnd_quota = tcp_cwnd_test(tp, skb); > + sent_pkts = 0; > + > + while (cwnd_quota) { > + u32 end_seq, window_seq; > + > + if (!tcp_nagle_test(tp, skb, mss_now, > + (tcp_skb_is_last(sk, skb) ? > + nonagle : TCP_NAGLE_PUSH))) > + break; > + > + end_seq = TCP_SKB_CB(skb)->end_seq; > + window_seq = tp->snd_una + tp->snd_wnd; > + if (skb->len > mss_now) > + end_seq = TCP_SKB_CB(skb)->seq + mss_now; > + if (after(end_seq, window_seq)) > + break; > + > + BUG_ON(!tso_segs); > + > + if (tso_segs > 1) { > + u32 limit = tso_size_limit(window_seq - > + TCP_SKB_CB(skb)->seq, > + mss_now, cwnd_quota); > > - while ((skb = sk->sk_send_head) && > - tcp_snd_test(sk, skb, mss_now, > - tcp_skb_is_last(sk, skb) ? nonagle : > - > TCP_NAGLE_PUSH)) { > - if (skb->len > mss_now) { > - if (tcp_fragment(sk, skb, mss_now)) > + if (skb->len > limit) { > + if (tso_fragment(sk, skb, limit)) > break; > } > - > - TCP_SKB_CB(skb)->when = tcp_time_stamp; > - tcp_tso_set_push(skb); > - if (tcp_transmit_skb(sk, skb_clone(skb, > GFP_ATOMIC))) > + } else if (skb->len > mss_now) { > + if (tcp_fragment(sk, skb, mss_now)) > break; > + } > > - /* Advance the send_head. This one is sent out. > - * This call will increment packets_out. > - */ > - update_send_head(sk, tp, skb); > + TCP_SKB_CB(skb)->when = tcp_time_stamp; > + tcp_tso_set_push(skb); > + if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) > + break; > > - tcp_minshall_update(tp, mss_now, skb); > - sent_pkts = 1; > - } > + /* Advance the send_head. This one is sent out. > + * This call will increment packets_out. > + */ > + update_send_head(sk, tp, skb); > > - if (sent_pkts) { > - tcp_cwnd_validate(sk, tp); > - return 0; > + tcp_minshall_update(tp, mss_now, skb); > + sent_pkts++; > + > + cwnd_quota -= tcp_skb_pcount(skb); > + skb = sk->sk_send_head; > + if (!skb) > + break; > + tso_segs = tcp_init_tso_segs(sk, skb); > + } > + > + if (sent_pkts) { > + tcp_cwnd_validate(sk, tp); > + return 0; > + } > + > + return !tp->packets_out && sk->sk_send_head; } > + > +/* Push out any pending frames which were held back due to > + * TCP_CORK or attempt at coalescing tiny packets. > + * The socket must be locked by the caller. > + */ > +void __tcp_push_pending_frames(struct sock *sk, > + struct tcp_sock *tp, > + unsigned int cur_mss, > + int nonagle) > +{ > + struct sk_buff *skb = sk->sk_send_head; > + > + if (skb) { > + if (!tcp_skb_is_last(sk, skb)) > + nonagle = TCP_NAGLE_PUSH; > + if (tcp_write_xmit(sk, nonagle)) > + tcp_check_probe_timer(sk, tp); > + } > + tcp_cwnd_validate(sk, tp); > +} > + > +/* As ACKs arrive and the send and congestion windows potentially > + * open up, we call this to try and make write queue transmit > + * progress. > + * > + * The caller has the socket locked, and has verified that > + * sk->sk_send_head is not NULL. > + */ > +void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb) { > + struct tcp_sock *tp = tcp_sk(sk); > + > + if (tcp_write_xmit(sk, tp->nonagle)) > + tcp_check_probe_timer(sk, tp); > +} > + > +/* Send _single_ skb sitting at the send head. This function requires > + * true push pending frames to setup probe timer etc. Caller makes > + * sure that sk->sk_send_head is non-NULL. > + */ > +void tcp_push_one(struct sock *sk, unsigned int cur_mss) { > + struct tcp_sock *tp = tcp_sk(sk); > + struct sk_buff *skb = sk->sk_send_head; > + unsigned int tso_segs, cwnd_quota; > + > + tso_segs = tcp_init_tso_segs(sk, skb); > + cwnd_quota = tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH); > + if (cwnd_quota) { > + u32 window_seq; > + > + window_seq = tp->snd_una + tp->snd_wnd; > + BUG_ON(!tso_segs); > + > + if (tso_segs > 1) { > + u32 limit = tso_size_limit(window_seq - > + TCP_SKB_CB(skb)->seq, > + cur_mss, cwnd_quota); > + > + if (skb->len > limit) { > + if (tso_fragment(sk, skb, limit)) > + return; > + } > + } else if (skb->len > cur_mss) { > + if (tcp_fragment(sk, skb, cur_mss)) > + return; > } > > - return !tp->packets_out && sk->sk_send_head; > + /* Send it out now. */ > + TCP_SKB_CB(skb)->when = tcp_time_stamp; > + tcp_tso_set_push(skb); > + if (!tcp_transmit_skb(sk, skb_clone(skb, > sk->sk_allocation))) { > + update_send_head(sk, tp, skb); > + return; > + } > } > - return 0; > } > > /* This function returns the amount that we can raise the @@ > -1041,12 +1345,6 @@ int tcp_retransmit_skb(struct sock *sk, > if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una)) > BUG(); > > - if (sk->sk_route_caps & NETIF_F_TSO) { > - sk->sk_route_caps &= ~NETIF_F_TSO; > - sock_set_flag(sk, SOCK_NO_LARGESEND); > - tp->mss_cache = tp->mss_cache_std; > - } > - > if (tcp_trim_head(sk, skb, tp->snd_una - > TCP_SKB_CB(skb)->seq)) > return -ENOMEM; > } > @@ -1671,13 +1969,6 @@ int tcp_write_wakeup(struct sock *sk) > TCP_SKB_CB(skb)->flags |= > TCPCB_FLAG_PSH; > if (tcp_fragment(sk, skb, seg_size)) > return -1; > - /* SWS override triggered > forced fragmentation. > - * Disable TSO, the connection > is too sick. */ > - if (sk->sk_route_caps & NETIF_F_TSO) { > - sock_set_flag(sk, > SOCK_NO_LARGESEND); > - sk->sk_route_caps &= > ~NETIF_F_TSO; > - tp->mss_cache = > tp->mss_cache_std; > - } > } else if (!tcp_skb_pcount(skb)) > tcp_set_skb_tso_segs(sk, skb); > > --- 1/net/ipv4/tcp.c.~1~ 2005-05-16 22:29:56.000000000 -0700 > +++ 2/net/ipv4/tcp.c 2005-05-17 12:07:26.000000000 -0700 > @@ -634,7 +634,7 @@ static ssize_t do_tcp_sendpages(struct s > size_t psize, int flags) > { > struct tcp_sock *tp = tcp_sk(sk); > - int mss_now; > + int mss_now, size_goal; > int err; > ssize_t copied; > long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT); > @@ -647,6 +647,7 @@ static ssize_t do_tcp_sendpages(struct s > clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); > > mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); > + size_goal = tp->xmit_size_goal; > copied = 0; > > err = -EPIPE; > @@ -660,7 +661,7 @@ static ssize_t do_tcp_sendpages(struct s > int offset = poffset % PAGE_SIZE; > int size = min_t(size_t, psize, PAGE_SIZE - offset); > > - if (!sk->sk_send_head || (copy = mss_now - > skb->len) <= 0) { > + if (!sk->sk_send_head || (copy = size_goal - > skb->len) <= 0) { > new_segment: > if (!sk_stream_memory_free(sk)) > goto wait_for_sndbuf; > @@ -671,7 +672,7 @@ new_segment: > goto wait_for_memory; > > skb_entail(sk, tp, skb); > - copy = mss_now; > + copy = size_goal; > } > > if (copy > size) > @@ -712,7 +713,7 @@ new_segment: > if (!(psize -= copy)) > goto out; > > - if (skb->len != mss_now || (flags & MSG_OOB)) > + if (skb->len != size_goal || (flags & MSG_OOB)) > continue; > > if (forced_push(tp)) { > @@ -732,6 +733,7 @@ wait_for_memory: > goto do_error; > > mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); > + size_goal = tp->xmit_size_goal; > } > > out: > @@ -773,15 +775,11 @@ ssize_t tcp_sendpage(struct socket *sock > > static inline int select_size(struct sock *sk, struct > tcp_sock *tp) { > - int tmp = tp->mss_cache_std; > + int tmp = tp->mss_cache; > > - if (sk->sk_route_caps & NETIF_F_SG) { > - int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER); > + if (sk->sk_route_caps & NETIF_F_SG) > + tmp = 0; > > - if (tmp >= pgbreak && > - tmp <= pgbreak + (MAX_SKB_FRAGS - 1) * PAGE_SIZE) > - tmp = pgbreak; > - } > return tmp; > } > > @@ -792,7 +790,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru > struct tcp_sock *tp = tcp_sk(sk); > struct sk_buff *skb; > int iovlen, flags; > - int mss_now; > + int mss_now, size_goal; > int err, copied; > long timeo; > > @@ -811,6 +809,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru > clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); > > mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); > + size_goal = tp->xmit_size_goal; > > /* Ok commence sending. */ > iovlen = msg->msg_iovlen; > @@ -833,7 +832,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru > skb = sk->sk_write_queue.prev; > > if (!sk->sk_send_head || > - (copy = mss_now - skb->len) <= 0) { > + (copy = size_goal - skb->len) <= 0) { > > new_segment: > /* Allocate new segment. If the > interface is SG, @@ -856,7 +855,7 @@ new_segment: > skb->ip_summed = CHECKSUM_HW; > > skb_entail(sk, tp, skb); > - copy = mss_now; > + copy = size_goal; > } > > /* Try to append data to the end of > skb. */ @@ -891,11 +890,6 @@ new_segment: > tcp_mark_push(tp, skb); > goto new_segment; > } else if (page) { > - /* If page is cached, align > - * offset to L1 cache boundary > - */ > - off = (off + > L1_CACHE_BYTES - 1) & > - ~(L1_CACHE_BYTES - 1); > if (off == PAGE_SIZE) { > put_page(page); > TCP_PAGE(sk) = > page = NULL; > @@ -956,7 +950,7 @@ new_segment: > if ((seglen -= copy) == 0 && iovlen == 0) > goto out; > > - if (skb->len != mss_now || (flags & MSG_OOB)) > + if (skb->len != size_goal || (flags & MSG_OOB)) > continue; > > if (forced_push(tp)) { > @@ -976,6 +970,7 @@ wait_for_memory: > goto do_error; > > mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); > + size_goal = tp->xmit_size_goal; > } > } > > @@ -2135,7 +2130,7 @@ void tcp_get_info(struct sock *sk, struc > > info->tcpi_rto = jiffies_to_usecs(tp->rto); > info->tcpi_ato = jiffies_to_usecs(tp->ack.ato); > - info->tcpi_snd_mss = tp->mss_cache_std; > + info->tcpi_snd_mss = tp->mss_cache; > info->tcpi_rcv_mss = tp->ack.rcv_mss; > > info->tcpi_unacked = tp->packets_out; > @@ -2185,7 +2180,7 @@ int tcp_getsockopt(struct sock *sk, int > > switch (optname) { > case TCP_MAXSEG: > - val = tp->mss_cache_std; > + val = tp->mss_cache; > if (!val && ((1 << sk->sk_state) & (TCPF_CLOSE > | TCPF_LISTEN))) > val = tp->rx_opt.user_mss; > break; > --- 1/net/ipv4/tcp_input.c.~1~ 2005-05-16 > 22:29:56.000000000 -0700 > +++ 2/net/ipv4/tcp_input.c 2005-05-17 16:49:26.000000000 -0700 > @@ -805,10 +805,10 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp, > __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0); > > if (!cwnd) { > - if (tp->mss_cache_std > 1460) > + if (tp->mss_cache > 1460) > cwnd = 2; > else > - cwnd = (tp->mss_cache_std > 1095) ? 3 : 4; > + cwnd = (tp->mss_cache > 1095) ? 3 : 4; > } > return min_t(__u32, cwnd, tp->snd_cwnd_clamp); } @@ > -974,14 +974,6 @@ tcp_sacktag_write_queue(struct sock *sk, > int flag = 0; > int i; > > - /* So, SACKs for already sent large segments will be lost. > - * Not good, but alternative is to resegment the queue. */ > - if (sk->sk_route_caps & NETIF_F_TSO) { > - sk->sk_route_caps &= ~NETIF_F_TSO; > - sock_set_flag(sk, SOCK_NO_LARGESEND); > - tp->mss_cache = tp->mss_cache_std; > - } > - > if (!tp->sacked_out) > tp->fackets_out = 0; > prior_fackets = tp->fackets_out; > @@ -1038,6 +1030,15 @@ tcp_sacktag_write_queue(struct sock *sk, > if(!before(TCP_SKB_CB(skb)->seq, end_seq)) > break; > > + /* Even if mincing a TSO frame fails, we > + * continue anyways. We will end up with > + * more coarse SACK information, but it is > + * better than ignoring all the SACK information > + * altogether. > + */ > + if (tcp_skb_pcount(skb) > 1) > + tcp_tso_mince(sk, tp, skb); > + > fack_count += tcp_skb_pcount(skb); > > in_sack = !after(start_seq, > TCP_SKB_CB(skb)->seq) && @@ -1142,7 +1143,7 @@ > tcp_sacktag_write_queue(struct sock *sk, > (IsFack(tp) || > !before(lost_retrans, > TCP_SKB_CB(skb)->ack_seq + > tp->reordering * > - tp->mss_cache_std))) { > + tp->mss_cache))) { > TCP_SKB_CB(skb)->sacked &= > ~TCPCB_SACKED_RETRANS; > tp->retrans_out -= tcp_skb_pcount(skb); > > @@ -1782,7 +1783,7 @@ static void tcp_try_to_open(struct sock > tp->retrans_stamp = 0; > > if (flag&FLAG_ECE) > - tcp_enter_cwr(tp); > + tcp_enter_cwr(tp, 1); > > if (tp->ca_state != TCP_CA_CWR) { > int state = TCP_CA_Open; > @@ -2170,7 +2171,7 @@ static void vegas_cong_avoid(struct tcp_ > * is the cwnd during the previous RTT. > */ > old_wnd = (tp->vegas.beg_snd_nxt - > tp->vegas.beg_snd_una) / > - tp->mss_cache_std; > + tp->mss_cache; > old_snd_cwnd = tp->vegas.beg_snd_cwnd; > > /* Save the extent of the current window so we > can use this @@ -2799,19 +2800,19 @@ static void > westwood_dupack_update(struc { > struct tcp_sock *tp = tcp_sk(sk); > > - tp->westwood.accounted += tp->mss_cache_std; > - tp->westwood.cumul_ack = tp->mss_cache_std; > + tp->westwood.accounted += tp->mss_cache; > + tp->westwood.cumul_ack = tp->mss_cache; > } > > static inline int westwood_may_change_cumul(struct tcp_sock *tp) { > - return (tp->westwood.cumul_ack > tp->mss_cache_std); > + return (tp->westwood.cumul_ack > tp->mss_cache); > } > > static inline void westwood_partial_update(struct tcp_sock *tp) { > tp->westwood.accounted -= tp->westwood.cumul_ack; > - tp->westwood.cumul_ack = tp->mss_cache_std; > + tp->westwood.cumul_ack = tp->mss_cache; > } > > static inline void westwood_complete_update(struct tcp_sock > *tp) @@ -3952,7 +3953,7 @@ static void tcp_new_space(struct sock *s > !(sk->sk_userlocks & SOCK_SNDBUF_LOCK) && > !tcp_memory_pressure && > atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0]) { > - int sndmem = max_t(u32, tp->rx_opt.mss_clamp, > tp->mss_cache_std) + > + int sndmem = max_t(u32, tp->rx_opt.mss_clamp, > tp->mss_cache) + > MAX_TCP_HEADER + 16 + sizeof(struct sk_buff), > demanded = max_t(unsigned int, tp->snd_cwnd, > tp->reordering + 1); > @@ -3975,16 +3976,6 @@ static inline void tcp_check_space(struc > } > } > > -static void __tcp_data_snd_check(struct sock *sk, struct > sk_buff *skb) -{ > - struct tcp_sock *tp = tcp_sk(sk); > - > - if (after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + > tp->snd_wnd) || > - tcp_packets_in_flight(tp) >= tp->snd_cwnd || > - tcp_write_xmit(sk, tp->nonagle)) > - tcp_check_probe_timer(sk, tp); > -} > - > static __inline__ void tcp_data_snd_check(struct sock *sk) { > struct sk_buff *skb = sk->sk_send_head; > --- 1/net/ipv4/tcp_ipv4.c.~1~ 2005-05-16 22:29:56.000000000 -0700 > +++ 2/net/ipv4/tcp_ipv4.c 2005-05-17 11:27:14.000000000 -0700 > @@ -2060,7 +2060,8 @@ static int tcp_v4_init_sock(struct sock > */ > tp->snd_ssthresh = 0x7fffffff; /* Infinity */ > tp->snd_cwnd_clamp = ~0; > - tp->mss_cache_std = tp->mss_cache = 536; > + tp->mss_cache = 536; > + tp->xmit_size_cache = ~0; > > tp->reordering = sysctl_tcp_reordering; > > --- 1/net/ipv6/tcp_ipv6.c.~1~ 2005-05-16 22:29:56.000000000 -0700 > +++ 2/net/ipv6/tcp_ipv6.c 2005-05-17 11:27:25.000000000 -0700 > @@ -2021,7 +2021,8 @@ static int tcp_v6_init_sock(struct sock > */ > tp->snd_ssthresh = 0x7fffffff; > tp->snd_cwnd_clamp = ~0; > - tp->mss_cache_std = tp->mss_cache = 536; > + tp->mss_cache = 536; > + tp->xmit_size_cache = ~0; > > tp->reordering = sysctl_tcp_reordering; > > From davem@davemloft.net Thu May 19 17:21:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 17:21:50 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K0LkF3021137 for ; Thu, 19 May 2005 17:21:46 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYvGF-0000b0-Oa; Thu, 19 May 2005 17:21:07 -0700 Date: Thu, 19 May 2005 17:21:07 -0700 (PDT) Message-Id: <20050519.172107.59468102.davem@davemloft.net> To: leonid.grossman@neterion.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO From: "David S. Miller" In-Reply-To: <200505200015.j4K0FNVG005262@guinness.s2io.com> References: <20050517.192416.108741581.davem@davemloft.net> <200505200015.j4K0FNVG005262@guinness.s2io.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1436 Lines: 36 From: "Leonid Grossman" Date: Thu, 19 May 2005 17:15:18 -0700 > A somewhat related thought, while we are at it... > > It would arguably make sense to allow a NIC to set max TSO size that the > card is > willing to support (rather than assume/enforce 64k). Some NICs support > bigger max > TSO size today, but it is even more important to allow a NIC to limit > TSO to a smaller size. We can never use a maximum greater than 65535 because that is the limit of the representation of the ipv4 header length field. These TSO packets have to be processed by the entire IP output path, including things like the firewalling and packet scheduler modules. So it must look like a valid IPV4 packet. > One likely scenario where this feature is desirable is a system with highly > fragmented memory. > In this case, the number of physical fragments per TSO frame could be always > so high that it will be cheaper > (on a given platform) to copy the frame than to DMA it. We always chop up the user data into individual system pages when we build TSO frames, so I can't see how any kind of memory fragmentation could be an issue. So this kind of nullifies your argument for smaller TSO size limits as specified by the card. The segmenter in the TCP code has the most knowledge about how it should segment, based upon numerous factors, many if not all of which the networking card is totally unaware of. From leonid.grossman@neterion.com Thu May 19 17:37:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 17:37:52 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K0bhF3021953 for ; Thu, 19 May 2005 17:37:44 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j4K0aXOC011249; Thu, 19 May 2005 20:36:33 -0400 (EDT) Received: from lgt40 ([10.16.16.54]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j4K0aVVG008391; Thu, 19 May 2005 20:36:32 -0400 (EDT) Message-Id: <200505200036.j4K0aVVG008391@guinness.s2io.com> From: "Leonid Grossman" To: "'David S.Miller'" Cc: Subject: RE: [PATCH] Super TSO Date: Thu, 19 May 2005 17:36:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVc0dHvPx7XXJuyRN2NysKS4KGyeAAAIqng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050519.172107.59468102.davem@davemloft.net> X-Scanned-By: MIMEDefang 2.34 X-archive-position: 1419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 2304 Lines: 67 > -----Original Message----- > From: David S.Miller [mailto:davem@davemloft.net] > Sent: Thursday, May 19, 2005 5:21 PM > To: leonid.grossman@neterion.com > Cc: netdev@oss.sgi.com > Subject: Re: [PATCH] Super TSO > > From: "Leonid Grossman" > Date: Thu, 19 May 2005 17:15:18 -0700 > > > A somewhat related thought, while we are at it... > > > > It would arguably make sense to allow a NIC to set max TSO > size that > > the card is willing to support (rather than assume/enforce > 64k). Some > > NICs support bigger max TSO size today, but it is even more > important > > to allow a NIC to limit TSO to a smaller size. > > We can never use a maximum greater than 65535 because that is > the limit of the representation of the ipv4 header length > field. These TSO packets have to be processed by the entire > IP output path, including things like the firewalling and > packet scheduler modules. > > So it must look like a valid IPV4 packet. > > > One likely scenario where this feature is desirable is a > system with > > highly fragmented memory. > > In this case, the number of physical fragments per TSO > frame could be > > always so high that it will be cheaper (on a given > platform) to copy > > the frame than to DMA it. > > We always chop up the user data into individual system pages > when we build TSO frames, so I can't see how any kind of > memory fragmentation could be an issue. This is exactly what I wanted to hear :-) If the TSO implementation guarantees that the payload comes (for the most part) in physically continuous pages, then the number of fragments will never get out of whack, and my argument indeed becomes invalid. > > So this kind of nullifies your argument for smaller TSO size > limits as specified by the card. > > The segmenter in the TCP code has the most knowledge about > how it should segment, based upon numerous factors, many if > not all of which the networking card is totally unaware of. Sure. On the other hand, the TCP code is unaware of the copy vs. DMA costs on a particular NIC (well, this is actually more specific to a system than to a NIC). But I guess as long as both the packet size and the number of fragments will not get very big at the same time, A NIC will be OK. > From rick.jones2@hp.com Thu May 19 17:47:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 17:47:24 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K0lJF3022778 for ; Thu, 19 May 2005 17:47:20 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 3D7C84364 for ; Thu, 19 May 2005 17:45:57 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id RAA04855 for ; Thu, 19 May 2005 17:45:56 -0700 (PDT) Message-ID: <428D3344.6090107@hp.com> Date: Thu, 19 May 2005 17:45:56 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO References: <200505200015.j4K0FNVG005262@guinness.s2io.com> In-Reply-To: <200505200015.j4K0FNVG005262@guinness.s2io.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 792 Lines: 20 > In this case, 64k TSO becomes a liability and it will make sense to limit it. > TSO "sweet spot" will be captured anyways - at least on fast networks, going > from 1.5k to 9k typically doubles throughput, while going from 9k to 64k > adds no more than another 10% (plus a little bit of free %cpu, but not that > much). On the surface, that just sounds like something adhering to the laws of diminishing returns. As you increase the TSO size, you are shrinking the per-send costs, but the per-byte costs (if there is a copy from user to kernel) and the ack costs remain the same. If that 1500 to 9K to 64K is an MTU (and thus real MSS) change than the per-send and ack costs are what are diminishing but the per-byte costs remain the same. Asymptotes and all that... rick jones From davem@davemloft.net Thu May 19 17:56:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 17:56:25 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K0uKF3023750 for ; Thu, 19 May 2005 17:56:20 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYvni-0000c8-AC; Thu, 19 May 2005 17:55:42 -0700 Date: Thu, 19 May 2005 17:55:42 -0700 (PDT) Message-Id: <20050519.175542.07642115.davem@davemloft.net> To: leonid.grossman@neterion.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO From: "David S. Miller" In-Reply-To: <200505200036.j4K0aVVG008391@guinness.s2io.com> References: <20050519.172107.59468102.davem@davemloft.net> <200505200036.j4K0aVVG008391@guinness.s2io.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1604 Lines: 41 From: "Leonid Grossman" Date: Thu, 19 May 2005 17:36:25 -0700 > > > One likely scenario where this feature is desirable is a > > system with > > > highly fragmented memory. > > > In this case, the number of physical fragments per TSO > > frame could be > > > always so high that it will be cheaper (on a given > > platform) to copy > > > the frame than to DMA it. > > > > We always chop up the user data into individual system pages > > when we build TSO frames, so I can't see how any kind of > > memory fragmentation could be an issue. > > This is exactly what I wanted to hear :-) > If the TSO implementation guarantees that the payload comes (for the most > part) > in physically continuous pages, then the number of fragments > will never get out of whack, and my argument indeed becomes invalid. You misunderstand me. The TCP segmenter splits the incoming user data into page size'd chunks. So a 64K packet uses 64K / PAGE_SIZE individual pages. The only thing the driver author needs to be aware of wrt. this is to never wake up the TX netif queue until at least "MAX_SKB_FRAGS + 1" transmit descriptors are available. You'll see that every driver setting NETIF_F_SG implements this test. > Sure. On the other hand, the TCP code is unaware of the copy vs. DMA > costs on a particular NIC (well, this is actually more specific to a > system than to a NIC). But I guess as long as both the packet size > and the number of fragments will not get very big at the same time, > A NIC will be OK. They can and will be as large as "MAX_SKB_FRAGS + 1". From leonid.grossman@neterion.com Thu May 19 18:26:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 18:26:52 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K1QmF3027191 for ; Thu, 19 May 2005 18:26:49 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j4K1PbOC011426; Thu, 19 May 2005 21:25:38 -0400 (EDT) Received: from lgt40 ([10.16.16.163]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j4K1PaVG015780; Thu, 19 May 2005 21:25:36 -0400 (EDT) Message-Id: <200505200125.j4K1PaVG015780@guinness.s2io.com> From: "Leonid Grossman" To: "'David S.Miller'" Cc: Subject: RE: [PATCH] Super TSO Date: Thu, 19 May 2005 18:25:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVc1qYjgpwCUI4MQviUkXnHIgoGKAAApebQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050519.175542.07642115.davem@davemloft.net> X-Scanned-By: MIMEDefang 2.34 X-archive-position: 1422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1563 Lines: 44 > > > We always chop up the user data into individual system > pages when we > > > build TSO frames, so I can't see how any kind of memory > > > fragmentation could be an issue. > > > > This is exactly what I wanted to hear :-) If the TSO implementation > > guarantees that the payload comes (for the most > > part) > > in physically continuous pages, then the number of fragments will > > never get out of whack, and my argument indeed becomes invalid. > > You misunderstand me. The TCP segmenter splits the incoming > user data into page size'd chunks. So a 64K packet uses 64K > / PAGE_SIZE individual pages. Yes, I think I'm actually with you. As long as each page is physically continuous and therefore requires one descriptor per page, the total number of descriptors per packet will be only 64K / PAGE_SIZE (plus some for headers), and this is fully manageable from a NIC prospective. > > The only thing the driver author needs to be aware of wrt. > this is to never wake up the TX netif queue until at least > "MAX_SKB_FRAGS + 1" transmit descriptors are available. > > You'll see that every driver setting NETIF_F_SG implements this test. > > > Sure. On the other hand, the TCP code is unaware of the > copy vs. DMA > > costs on a particular NIC (well, this is actually more > specific to a > > system than to a NIC). But I guess as long as both the packet size > > and the number of fragments will not get very big at the > same time, A > > NIC will be OK. > > They can and will be as large as "MAX_SKB_FRAGS + 1". > > From davem@davemloft.net Thu May 19 18:29:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 18:29:06 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K1T2F3027564 for ; Thu, 19 May 2005 18:29:02 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DYwJJ-0000o0-ID; Thu, 19 May 2005 18:28:21 -0700 Date: Thu, 19 May 2005 18:28:21 -0700 (PDT) Message-Id: <20050519.182821.71087031.davem@davemloft.net> To: leonid.grossman@neterion.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO From: "David S. Miller" In-Reply-To: <200505200125.j4K1PaVG015780@guinness.s2io.com> References: <20050519.175542.07642115.davem@davemloft.net> <200505200125.j4K1PaVG015780@guinness.s2io.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 420 Lines: 10 From: "Leonid Grossman" Date: Thu, 19 May 2005 18:25:35 -0700 > Yes, I think I'm actually with you. As long as each page is physically > continuous and therefore requires one descriptor per page, the total > number of descriptors per packet will be only 64K / PAGE_SIZE (plus > some for headers), and this is fully manageable from a NIC > prospective. Yes, that is exactly what happens. From kostodo@gmail.com Thu May 19 22:26:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 22:26:35 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K5QUF3011801 for ; Thu, 19 May 2005 22:26:30 -0700 Received: by rproxy.gmail.com with SMTP id z35so334352rne for ; Thu, 19 May 2005 22:25:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Uqiw0Pl+QAIaKuBD7Q4PN+VPlz537yi0z5/hxJ47hYOEGbl9ikvaZTgS8UXpZ8L0adK2q8I8cLtgbubaO7caczgQ0MlJxiyvHIVVWNsE/wVPwmzCBg07SySYi3FqJ0Lfd0IozBDgn4ZBOkI+cmgVlRa6p5vBgZPRef8ac8NhhIY= Received: by 10.38.14.25 with SMTP id 25mr1525291rnn; Thu, 19 May 2005 22:25:49 -0700 (PDT) Received: by 10.38.208.46 with HTTP; Thu, 19 May 2005 22:25:49 -0700 (PDT) Message-ID: Date: Fri, 20 May 2005 09:25:49 +0400 From: Kosta Todorovic Reply-To: Kosta Todorovic To: Ben Greear Subject: Re: Network card driver problem (znb.o/tulip) Cc: jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <428CC958.1080909@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428CC958.1080909@candelatech.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4K5QUF3011801 X-archive-position: 1424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 3902 Lines: 109 2 more questions: 1) Is there anything special I will need to compile in terms of the linux kernel for 64-bit PCI bus mode (PCI-X) ? (Currently I'm using kernel 2.4.x but that is because my current card drivers do not support 2.6.x) 2) The machine actually has a PCI extension with 9 other PCI-X slots. The current cards are 64-bit (pci-x) but as a test i'm planning on replacing them with DLinks DFE-580tx's. Unfortunately these are 32-bit cards (legacy pci). How will these 4 ports work in 32-bit mode? What will the effect be on the speed? On 5/19/05, Ben Greear wrote: > Kosta Todorovic wrote: > > Whats the best 4-port NIC currently available? I'm interested in > > purchasing 10 4-port NICs as a replacement for my current cards. > > > > I am looking for 10/100Mbps and a good driver for linux (2.4.x and > > 2.6.x). Preferably a mainstream company but thats not priority. > > > > Could the community please recommend the best card available? Money is > > not an issue since im really interested in the best of the best. > > Get an Intel 4-port GigE NIC. It will do 10/100/1000, and if you really > want to use all 4 ports at even 100Mbps, you need the 64-bit PCI bus... > > I have been getting mine from silicom-usa.com lately. They also have > 6-port NICs, and 4-port broadcom GigE nics that can be used in 32-bit > PCI slots. (The Intel 4-port NICs will only work in 64-bit PCI slots.) > > If you really want 10/100 nics, try the p430tx from aei: > http://www.aei-it.com/hardware/fastenet/p430tx.htm > > These are like the old DFE570tx NICs, and use the tulip driver. They > are almost as expensive as the GigE NICs though... > > Thanks, > Ben > > > > > Any suggestions? > > > > Regards, > > Kosta > > > > > > > > On 3/11/05, Kosta Todorovic wrote: > > > >>My company has recently purchased several ZNYX ZX274 network cards. > >>These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets. > >> > >>Unfortunately there exists no drivers for linux amd64 architecture. > >>There are 32bit drivers found at: > >>http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally > >>they wont compile under my amd64 system. > >> > >>The driver itself is called znb.o and can be downloaded from ZNYX's > >>website. I spoke to support staff there but they told me they have > >>discontinued support and development for this series of cards. > >> > >>The system I am running gentoo and have tried both 2.4.x and 2.6.x > >>kernels but no luck. > >> > >>Unfortunately there is NO 64bit drivers available for ANY platform. not even MS. > >> > >>Does anyone know of a customised znb.o driver built for amd64? > >>Is there any chance of anyone modifying the source code of the driver > >>to compile under a amd64 system? > >> > >>I've noticed that "tulip" drivers get loaded as a module at boot time. > >>but they dont function correctly. (lets you start the device and > >>attach ips but cant talk through it) > >> > >>Is there any variants of the tulip driver that will work for this? > >> > >>Help much appreciated. > >> > >> > >>/proc/pci extract for network cards: > >> > >> Bus 5, device 5, function 0: > >> Ethernet controller: Digital Equipment Corporation DECchip > >>21142/43 (#30) (rev 65). > >> IRQ 30. > >> Master Capable. Latency=128. Min Gnt=20.Max Lat=40. > >> I/O at 0x0 [0x7f]. > >> Non-prefetchable 32 bit memory at 0xfa1ff400 [0xfa1ff7ff]. > >> Bus 5, device 4, function 0: > >> Ethernet controller: Digital Equipment Corporation DECchip > >>21142/43 (#29) (rev 65). > >> IRQ 29. > >> Master Capable. No bursts. Min Gnt=20.Max Lat=40. > >> I/O at 0x0 [0x7f]. > >> Non-prefetchable 32 bit memory at 0xf9f00000 [0xf9f003ff]. > >> > > > > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From util@deuroconsult.ro Thu May 19 23:08:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 23:08:47 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K68UF3014736 for ; Thu, 19 May 2005 23:08:36 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4K67lVF003873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2005 09:07:47 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4K67kCk003849; Fri, 20 May 2005 09:07:46 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Fri, 20 May 2005 09:07:46 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Jon Mason cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) In-Reply-To: <20050519214015.GA19961@us.ibm.com> Message-ID: References: <20050519214015.GA19961@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1629 Lines: 49 >> +static inline void br_features_change(struct net_bridge *br, struct net_device *dev) >> +{ >> + br->dev->features &= dev->features | ~BR_FEAT_MASK; > > ~BR_FEAT_MASK isn't necessary. Either you wanted to do an '&' just > before it, so that BR_FEAT_MASK features are the only ones that you want > or you are enabling features that aren't necessarily supported by the > adapter/driver (like LLTX and HW_VLAN stuff). So, I invert BR_FEAT_MASK so I can, by default clear special features. Then I ored with dev->features, so I can enable special features if the slave device supports it. Then, I do & so I can clear stuff that is not supported by device, but the rest of br->dev features remains untouched. Let's test: if dev hash SG the code is like this: BR_FEAT_MASK = 1001 (only test SG and HW_CSUM) # br is inited br |= 1001 br &= 0001 | ~1001 br &= 0001 | 0110 br &= 0111 br = 1001 & 0111 = 0001 - so bit SG is set also in br. But not HW_CSUM because it's not in device. I can't see the code is wrong. Can you give me an example when it fails, please? >> +} >> + >> +/* >> + * Recomputes features using slave's features >> + */ >> +static void br_features_recompute(struct net_bridge *br) >> +{ >> + struct net_bridge_port *p; >> + >> + br->dev->features |= BR_FEAT_MASK; > > The OR is not needed. Just re-initialize features to BR_FEAT_MASK and > everything will take case of itself. Nope. Not correct. Because we might enable LLTX on the bridge, but not in BR_FEAT_MASK. I will post a patch in few hours with all stuff updated. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From johnpol@2ka.mipt.ru Thu May 19 23:18:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 23:18:39 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K6IYF3015967 for ; Thu, 19 May 2005 23:18:34 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j4K6H6wD017224; Fri, 20 May 2005 10:17:06 +0400 Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: "David S. Miller" Cc: hadi@cyberus.ca, jmorris@redhat.com, akpm@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20050519.114901.108984882.davem@davemloft.net> References: <1116510411.6240.54.camel@localhost.localdomain> <20050519.114901.108984882.davem@davemloft.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zXmMmqNM4Ni1K8Sx1ErA" Organization: MIPT Date: Fri, 20 May 2005 10:25:27 +0400 Message-Id: <1116570327.21310.106.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Fri, 20 May 2005 10:17:14 +0400 (MSD) X-archive-position: 1426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 915 Lines: 36 --=-zXmMmqNM4Ni1K8Sx1ErA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-05-19 at 11:49 -0700, David S. Miller wrote: > From: jamal > Date: Thu, 19 May 2005 09:46:50 -0400 >=20 > > However, something like connector should only get one ID and it can do > > its own multiplexing based on "units". >=20 > Yes. There is no reason connector needs more than one > netlink ID. It does not require several IDs. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-zXmMmqNM4Ni1K8Sx1ErA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCjYLXIKTPhE+8wY0RAobHAJ9FgefgAFZuAWC5OiJQorvLzRLI8gCfW0UU 8q/GgJQiTCqdcCjahh0rsp0= =F+Z5 -----END PGP SIGNATURE----- --=-zXmMmqNM4Ni1K8Sx1ErA-- From johnpol@2ka.mipt.ru Thu May 19 23:21:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 23:21:30 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K6LAF3016573 for ; Thu, 19 May 2005 23:21:26 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j4K6IvFv017286; Fri, 20 May 2005 10:18:57 +0400 Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: "David S. Miller" Cc: jmorris@redhat.com, akpm@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20050519.114813.85686672.davem@davemloft.net> References: <20050519000809.2fca25c5.akpm@osdl.org> <20050519.114813.85686672.davem@davemloft.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nBDj0w30x2x6ERkyL24d" Organization: MIPT Date: Fri, 20 May 2005 10:27:17 +0400 Message-Id: <1116570437.21310.109.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Fri, 20 May 2005 10:18:57 +0400 (MSD) X-archive-position: 1427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1437 Lines: 49 --=-nBDj0w30x2x6ERkyL24d Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-05-19 at 11:48 -0700, David S. Miller wrote: > From: James Morris > Date: Thu, 19 May 2005 09:19:33 -0400 (EDT) >=20 > > On Thu, 19 May 2005, Andrew Morton wrote: > >=20 > > > We should remove the feature. If there is demonstrated need for mult= iple > > > instances then it should be done by more conventional means - syscall= , > > > allocation of a device major then use the minor as a selector or what= ever. > >=20 > > I'd suggest removing the connector code completely. >=20 > I totally agree, it's crap at the current time and the author doesn't > fix the problems being shown in it, in fact he defends some of them > even this one. It needs lots of work still. There were no problems reported. Completely. What I defend is ability to function correctly when some changes=20 may be introduced by providing some extensions that may be used. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-nBDj0w30x2x6ERkyL24d Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCjYNFIKTPhE+8wY0RAtoRAJ0Ufb586V3GnUmHmemEBTnY0SEZPACfU6u0 5yW0wq0s1Q9difSukvT27Ms= =Pdlu -----END PGP SIGNATURE----- --=-nBDj0w30x2x6ERkyL24d-- From johnpol@2ka.mipt.ru Thu May 19 23:21:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 23:22:03 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K6LfF3016655 for ; Thu, 19 May 2005 23:21:58 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j4K6JXkw017347; Fri, 20 May 2005 10:19:33 +0400 Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: "David S. Miller" Cc: akpm@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20050519.114241.59656850.davem@davemloft.net> References: <1116484313.21310.78.camel@uganda> <20050518234552.4aef6d02.akpm@osdl.org> <1116486385.21310.82.camel@uganda> <20050519.114241.59656850.davem@davemloft.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-stMio8AyzMq4b+SiqS1d" Organization: MIPT Date: Fri, 20 May 2005 10:27:54 +0400 Message-Id: <1116570474.21310.111.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Fri, 20 May 2005 10:19:33 +0400 (MSD) X-archive-position: 1428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1251 Lines: 43 --=-stMio8AyzMq4b+SiqS1d Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-05-19 at 11:42 -0700, David S. Miller wrote: > From: Evgeniy Polyakov > Date: Thu, 19 May 2005 11:06:25 +0400 >=20 > > It was created to be able to load several different connector devices=20 > > from different modules [basically it was module1.ko unit=3D10, module2.= ko > > unit=3D11 and so on]. >=20 > That's bogus, each connector will need to allocate it's own > specific define in the netlink header, and we're about to > run out of numbers. >=20 > Please redesign the connector so that it doesn't eat more than > one netlink number, we're running out of them soon. It does not require more than one socket number. It just can use any other number provided. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-stMio8AyzMq4b+SiqS1d Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCjYNqIKTPhE+8wY0RAqqUAJ0Zaq1bPV2Yhq+q8j+BGARTzkRGwgCfU3u6 w91/eJHszFrKga0UUxX8qHQ= =+ghe -----END PGP SIGNATURE----- --=-stMio8AyzMq4b+SiqS1d-- From johnpol@2ka.mipt.ru Thu May 19 23:32:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 19 May 2005 23:32:40 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K6WZF3018230 for ; Thu, 19 May 2005 23:32:35 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j4K6VHK8017752; Fri, 20 May 2005 10:31:18 +0400 Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: "David S. Miller" Cc: akpm@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20050519.114425.18307286.davem@davemloft.net> References: <20050518222729.007887b8.akpm@osdl.org> <1116484313.21310.78.camel@uganda> <20050518234552.4aef6d02.akpm@osdl.org> <20050519.114425.18307286.davem@davemloft.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3vrfiseHvipfAvNB+2o2" Organization: MIPT Date: Fri, 20 May 2005 10:39:38 +0400 Message-Id: <1116571178.21310.124.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Fri, 20 May 2005 10:31:18 +0400 (MSD) X-archive-position: 1429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2422 Lines: 71 --=-3vrfiseHvipfAvNB+2o2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-05-19 at 11:44 -0700, David S. Miller wrote: > From: Andrew Morton > Date: Wed, 18 May 2005 23:45:52 -0700 >=20 > > > Should I ask David Miller to allocate new one specially for connector= ? > >=20 > > Dave? >=20 > Giving the connector a single value 10 is OK, the rest of > what the connector is doing in this area is not. >=20 > I wish you hadn't put the connector into -mm, it's really > in need of several fixups still. The bogus reuse of the > ULOG netlink number is simply indicative of that. And how does it indicate that it is bogus? :) It is one netlink user that can use any socket number - and now it is called bogus. What other people suggest is just create some wrapper over=20 netlink_broadcast() and alloc_skb(). if you do think it will solve all problems, then I even will not say anything. Point. I just want to note, that if you want message bus, you require at least oppsite direction, and thus input callback, and either several socket number for each user [kobject, audit, iscsi,=20 xfrm - all they implement what connector already does] or some header and thus parser in input callback, and thus some registration mechanism. Magically it is what connector does. And nothing more, btw. It only allows not to rewrite the whole driver just to move to new transport layer, only register new cn_dev device with different method. Ok, Dave, we all see your point, feel free to remove connector, I will not bother people to include it yet another time... But I believe in a month or two someone will reinvent the wheel and create somthing similar. If it will be simple wrapper, then it just can not solve message bus problem, only notification,=20 and thus someone will create it again. Thank you. P.S. smtp server from my old university years seems to still drop your messages, sorry for that, I will kick admins again. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-3vrfiseHvipfAvNB+2o2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCjYYqIKTPhE+8wY0RAo4WAJsG9qiUU1EbgY+i2svMbZRr4BPgCACeP2oC S2E4iWmI0w8jNtZH2YIeyBA= =ytJR -----END PGP SIGNATURE----- --=-3vrfiseHvipfAvNB+2o2-- From util@deuroconsult.ro Fri May 20 00:18:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 00:18:31 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K7IQF3023395 for ; Fri, 20 May 2005 00:18:27 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4K7HlLP009232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 May 2005 10:17:47 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4K7Hk2u009229 for ; Fri, 20 May 2005 10:17:46 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Fri, 20 May 2005 10:17:46 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: netdev@oss.sgi.com Subject: Notifier for features change? (related to Ethernet Bridging: Enable Hardware Checksumming) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 278 Lines: 14 Hello! Because bridge can change features based on slaves features, may I implement NETDEV_FEAT_CHANGE? It will be used to recompute bridge features when a slave ones are changed. Thank you. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From wichert@levante.wiggy.net Fri May 20 01:18:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 01:18:53 -0700 (PDT) Received: from mx1.wiggy.net (levante.wiggy.net [195.85.225.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4K8IkF3001403 for ; Fri, 20 May 2005 01:18:47 -0700 Received: from wichert by mx1.wiggy.net with local (Exim 4.50) id 1DZ2hp-0007zW-4l for netdev@oss.sgi.com; Fri, 20 May 2005 10:18:05 +0200 Date: Fri, 20 May 2005 10:18:05 +0200 From: Wichert Akkerman To: netdev@oss.sgi.com Subject: sendmsg ignoring bind? Message-ID: <20050520081805.GR25658@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-SA-Exim-Connect-IP: X-archive-position: 1431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Content-Length: 1779 Lines: 40 After moving a RADIUS server from a machine running 2.6.8.1 to to another host running 2.6.11.9 yesterday things suddenly broke: proxy requests were send from the wrong IP address. Here is the network configuration: 1: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:13:21:b3:ba:ef brd ff:ff:ff:ff:ff:ff inet 212.123.202.85/26 brd 212.123.202.127 scope global eth0 inet 212.123.202.78/26 scope global secondary eth0 inet 212.123.202.70/26 scope global secondary eth0 inet 212.123.202.73/26 scope global secondary eth0 inet 212.123.202.76/26 scope global secondary eth0 inet 212.123.202.74/26 scope global secondary eth0 inet6 2001:960:6a6:2:213:21ff:feb3:baef/64 scope global dynamic valid_lft 2591728sec preferred_lft 604528sec inet6 fe80::213:21ff:feb3:baef/64 scope link valid_lft forever preferred_lft forever This is an strace of the relevant code: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 7 setsockopt(7, SOL_IP, IP_PKTINFO, [1], 4) = 0 bind(7, {sa_family=AF_INET, sin_port=htons(1814), sin_addr=inet_addr("212.123.202.74")}, 16) = 0 sendmsg(7, {msg_name(16)={sa_family=AF_INET, sin_port=htons(1812), sin_addr=inet_addr("212.100.254.89")}, msg_iov(1)=[{"....", 249}], msg_controllen=24, {cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 249 One would expect that packet to be send from 212.123.202.74, but instead it is send using the machine's primary IP address 212.123.202.85. As a temporary workaround I added routes for the relevant targets that explicitly set the src to 212.123.202.74. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From util@deuroconsult.ro Fri May 20 03:12:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 03:12:19 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KACCF3009991 for ; Fri, 20 May 2005 03:12:13 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4KABOxn031935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2005 13:11:24 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4KABOTx031928; Fri, 20 May 2005 13:11:24 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Fri, 20 May 2005 13:11:24 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: netdev@oss.sgi.com cc: davem@davemloft.net Subject: [PATCH] dummy: improve performance Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1646943047-1317725015-1116583867=:29305" Content-ID: X-archive-position: 1432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 2177 Lines: 52 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1646943047-1317725015-1116583867=:29305 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Hello! Attached patch tries to improve performance of dummy device by activating NETIF_F_SG, NETIF_F_NO_CSUM, NETIF_F_HIGHDMA, NETIF_F_FRAGLIST, NETIF_F_TSO and NETIF_F_LLTX. Patch compiles and runs. I tested the speed and seems very low (both old version and the new one). Something like 37Mbits/s. It is normal? I can easily get 80Mbit/s on the same machine on ethernet. Thank you! Signed-off-by: Catalin BOIE --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ---1646943047-1317725015-1116583867=:29305 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=dummy_features.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=dummy_features.patch LS0tIGR1bW15MS9kcml2ZXJzL25ldC9kdW1teS5jCTIwMDUtMDMtMjYgMDU6 Mjg6MjAuMDAwMDAwMDAwICswMjAwDQorKysgbGludXgvZHJpdmVycy9uZXQv ZHVtbXkuYwkyMDA1LTA1LTIwIDExOjU3OjQ0LjAwMDAwMDAwMCArMDMwMA0K QEAgLTI2LDYgKzI2LDggQEANCiAJCQlOaWNrIEhvbGxvd2F5LCAyN3RoIE1h eSAxOTk0DQogCVtJIHR3ZWFrZWQgdGhpcyBleHBsYW5hdGlvbiBhIGxpdHRs ZSBidXQgdGhhdCdzIGFsbF0NCiAJCQlBbGFuIENveCwgMzB0aCBNYXkgMTk5 NA0KKw0KKwlBZGQgc3BlY2lhbCBmZWF0dXJlcyB0byBpbXByb3ZlIHBlcmZv cm1hbmNlIC0gQ2F0YWxpbiBCT0lFDQogKi8NCiANCiAjaW5jbHVkZSA8bGlu dXgvY29uZmlnLmg+DQpAQCAtNzMsNiArNzUsOCBAQCBzdGF0aWMgdm9pZCBf X2luaXQgZHVtbXlfc2V0dXAoc3RydWN0IG5lDQogCWRldi0+ZmxhZ3MgJj0g fklGRl9NVUxUSUNBU1Q7DQogCVNFVF9NT0RVTEVfT1dORVIoZGV2KTsNCiAJ cmFuZG9tX2V0aGVyX2FkZHIoZGV2LT5kZXZfYWRkcik7DQorCWRldi0+ZmVh dHVyZXMgPSBORVRJRl9GX1NHIHwgTkVUSUZfRl9OT19DU1VNIHwgTkVUSUZf Rl9ISUdIRE1BDQorCQkJfCBORVRJRl9GX0ZSQUdMSVNUIHwgTkVUSUZfRl9U U08gfCBORVRJRl9GX0xMVFg7DQogfQ0KIA0KIHN0YXRpYyBpbnQgZHVtbXlf eG1pdChzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgbmV0X2RldmljZSAq ZGV2KQ0K ---1646943047-1317725015-1116583867=:29305-- From herbert@gondor.apana.org.au Fri May 20 03:18:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 03:18:58 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KAIqF3010780 for ; Fri, 20 May 2005 03:18:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DZ4Zl-0004NY-00; Fri, 20 May 2005 20:17:53 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DZ4Zh-0002Gm-00; Fri, 20 May 2005 20:17:49 +1000 Date: Fri, 20 May 2005 20:17:49 +1000 To: Wichert Akkerman Cc: netdev@oss.sgi.com Subject: Re: sendmsg ignoring bind? Message-ID: <20050520101749.GA8661@gondor.apana.org.au> References: <20050520081805.GR25658@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520081805.GR25658@wiggy.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 637 Lines: 16 On Fri, May 20, 2005 at 08:18:05AM +0000, Wichert Akkerman wrote: > > sendmsg(7, {msg_name(16)={sa_family=AF_INET, sin_port=htons(1812), > sin_addr=inet_addr("212.100.254.89")}, > msg_iov(1)=[{"....", 249}], msg_controllen=24, {cmsg_len=24, > cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 249 This could be a cmsg option that overrode the bind address. Please decode it so that we know what it's doing. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From fischer@ikr.uni-stuttgart.de Fri May 20 04:20:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 04:20:45 -0700 (PDT) Received: from wall.ikr.uni-stuttgart.de (wall.ikr.uni-stuttgart.de [129.69.170.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KBKgF3019156 for ; Fri, 20 May 2005 04:20:42 -0700 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id A73CA56D0C for ; Fri, 20 May 2005 13:20:00 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 8D32CBD604; Fri, 20 May 2005 13:20:00 +0200 (CEST) Received: from ikr.uni-stuttgart.de (pc10 [10.21.21.10]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id D05D0BD602 for ; Fri, 20 May 2005 13:19:59 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Fri, 20 May 2005 13:19:59 +0200 From: Felix Fischer Organization: University of Stuttgart (Germany), IKR To: netdev@oss.sgi.com Subject: IPv6 Tunneling (reverse tunnel need) Date: Fri, 20 May 2005 13:19:59 +0200 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200505201319.59707.fischer@ikr.uni-stuttgart.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4KBKgF3019156 X-archive-position: 1434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fischer@ikr.uni-stuttgart.de Precedence: bulk X-list: netdev Content-Length: 984 Lines: 28 I'm currently working on a research project and ran into a question regarding tunneling/decapsulation in IPv6. <------> [ A ] ===== tunnel from A to B =====> [ B ] <------->   Packets tunneled from A to B are only decapsulated at node B if B has setup a tunnel-device in direction from B to A (reverse tunnel). Is the need for the tunnel-device on node B an implementation issue to handle tunneling, or does it come from something else (i.e. standard requirement) ? Further, I am wondering why the possibility to use the ANY_ADDRESS as tunnel-end-point isn't present in IPv6 ? The IPv4 implementation allows the usage of "0.0.0.0" as remote_address for tunnel-end-points. Any help would be greatly appreciated. Regards, Felix Fischer -- ------------------------------------------------------------------- Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany ------------------------------------------------------------------- From hadi@cyberus.ca Fri May 20 04:43:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 04:43:40 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KBhaF3020606 for ; Fri, 20 May 2005 04:43:36 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DZ5u1-0005oE-So for netdev@oss.sgi.com; Fri, 20 May 2005 05:42:53 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DZ5ty-0006WV-Ee; Fri, 20 May 2005 07:42:50 -0400 Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: "David S. Miller" , akpm@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <1116571178.21310.124.camel@uganda> References: <20050518222729.007887b8.akpm@osdl.org> <1116484313.21310.78.camel@uganda> <20050518234552.4aef6d02.akpm@osdl.org> <20050519.114425.18307286.davem@davemloft.net> <1116571178.21310.124.camel@uganda> Content-Type: text/plain Organization: unknown Date: Fri, 20 May 2005 07:42:47 -0400 Message-Id: <1116589367.6308.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 728 Lines: 20 On Fri, 2005-20-05 at 10:39 +0400, Evgeniy Polyakov wrote: > I just want to note, that if you want message bus, you require > at least oppsite direction, and thus input callback, and > either several socket number for each user [kobject, audit, iscsi, > xfrm - all they implement what connector already does] or > some header and thus parser in input callback, and thus > some registration mechanism. But if you are given your own ID, there should no issues, correct? i.e it will be no different than say rtnetlink. Users would still have to subscribe to topics etc, but thats something you already handle. IOW, Iam hoping you are not resorting to a single socket with some user space mux to do filtering. cheers, jamal From herbert@gondor.apana.org.au Fri May 20 06:25:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 06:25:32 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KDPHF3027058 for ; Fri, 20 May 2005 06:25:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DZ7UN-0005f5-00; Fri, 20 May 2005 23:24:31 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DZ7UL-0008Vm-00; Fri, 20 May 2005 23:24:29 +1000 Date: Fri, 20 May 2005 23:24:29 +1000 To: Wichert Akkerman Cc: netdev@oss.sgi.com Subject: Re: sendmsg ignoring bind? Message-ID: <20050520132429.GA32695@gondor.apana.org.au> References: <20050520081805.GR25658@wiggy.net> <20050520101749.GA8661@gondor.apana.org.au> <20050520132009.GD4151@wiggy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520132009.GD4151@wiggy.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 1437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 688 Lines: 16 On Fri, May 20, 2005 at 03:20:09PM +0200, Wichert Akkerman wrote: > > I had to hack strace a bit to decode that. The cmsg option turns out > to be somewhat useless: I suppose we can expect to have this in a future release of strace :) > cmsg_type=IP_PKTINFO, {ifindex=0,ipi_spec_dst=inet_addr("0.0.0.0"),ipi_addr=("0.0.0.0")}}, msg_flags=0}, This is far from useless. This will set the source address back to zero which essentially means that the bound address is ignored. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From wichert@levante.wiggy.net Fri May 20 06:20:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 06:20:58 -0700 (PDT) Received: from mx1.wiggy.net (levante.wiggy.net [195.85.225.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KDKmF3026515 for ; Fri, 20 May 2005 06:20:49 -0700 Received: from wichert by mx1.wiggy.net with local (Exim 4.50) id 1DZ7Q9-0001pM-80; Fri, 20 May 2005 15:20:09 +0200 Date: Fri, 20 May 2005 15:20:09 +0200 From: Wichert Akkerman To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: sendmsg ignoring bind? Message-ID: <20050520132009.GD4151@wiggy.net> References: <20050520081805.GR25658@wiggy.net> <20050520101749.GA8661@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520101749.GA8661@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i X-SA-Exim-Connect-IP: X-archive-position: 1436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Content-Length: 502 Lines: 14 Previously Herbert Xu wrote: > This could be a cmsg option that overrode the bind address. Please > decode it so that we know what it's doing. I had to hack strace a bit to decode that. The cmsg option turns out to be somewhat useless: cmsg_type=IP_PKTINFO, {ifindex=0,ipi_spec_dst=inet_addr("0.0.0.0"),ipi_addr=("0.0.0.0")}}, msg_flags=0}, Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From wichert@levante.wiggy.net Fri May 20 06:32:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 06:32:28 -0700 (PDT) Received: from mx1.wiggy.net (levante.wiggy.net [195.85.225.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KDWOF3028334 for ; Fri, 20 May 2005 06:32:24 -0700 Received: from wichert by mx1.wiggy.net with local (Exim 4.50) id 1DZ7bM-0001uJ-V2; Fri, 20 May 2005 15:31:45 +0200 Date: Fri, 20 May 2005 15:31:44 +0200 From: Wichert Akkerman To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: sendmsg ignoring bind? Message-ID: <20050520133144.GE4151@wiggy.net> References: <20050520081805.GR25658@wiggy.net> <20050520101749.GA8661@gondor.apana.org.au> <20050520132009.GD4151@wiggy.net> <20050520132429.GA32695@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520132429.GA32695@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i X-SA-Exim-Connect-IP: X-archive-position: 1438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wichert@wiggy.net Precedence: bulk X-list: netdev Content-Length: 688 Lines: 19 Previously Herbert Xu wrote: > I suppose we can expect to have this in a future release of strace :) It just might happen :) > > cmsg_type=IP_PKTINFO, {ifindex=0,ipi_spec_dst=inet_addr("0.0.0.0"),ipi_addr=("0.0.0.0")}}, msg_flags=0}, > > This is far from useless. This will set the source address back to zero > which essentially means that the bound address is ignored. I can see it being useful, except in my case it is somewhat unexpected and undesirable behaviour. I'll make sure to have that fixed in FreeRADIUS though. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From johnpol@2ka.mipt.ru Fri May 20 07:08:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 07:08:40 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KE8VF3030631 for ; Fri, 20 May 2005 07:08:32 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j4KE7IH9010340; Fri, 20 May 2005 18:07:18 +0400 Subject: Re: 2.6.12-rc4-mm[12] - ULOG problem From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: hadi@cyberus.ca Cc: "David S. Miller" , akpm@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <1116589367.6308.36.camel@localhost.localdomain> References: <20050518222729.007887b8.akpm@osdl.org> <1116484313.21310.78.camel@uganda> <20050518234552.4aef6d02.akpm@osdl.org> <20050519.114425.18307286.davem@davemloft.net> <1116571178.21310.124.camel@uganda> <1116589367.6308.36.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-i2Fx1frPqQmvuSu7WD7T" Organization: MIPT Date: Fri, 20 May 2005 18:15:39 +0400 Message-Id: <1116598539.21310.195.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Fri, 20 May 2005 18:07:21 +0400 (MSD) X-archive-position: 1439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1523 Lines: 52 --=-i2Fx1frPqQmvuSu7WD7T Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-05-20 at 07:42 -0400, jamal wrote: > On Fri, 2005-20-05 at 10:39 +0400, Evgeniy Polyakov wrote: >=20 > > I just want to note, that if you want message bus, you require > > at least oppsite direction, and thus input callback, and > > either several socket number for each user [kobject, audit, iscsi,=20 > > xfrm - all they implement what connector already does] or > > some header and thus parser in input callback, and thus > > some registration mechanism.=20 >=20 >=20 > But if you are given your own ID, there should no issues, correct? Yes. > i.e it will be no different than say rtnetlink. Users would still have > to subscribe to topics etc, but thats something you already handle. > IOW, Iam hoping you are not resorting to a single socket with some user > space mux to do filtering. Not following, sorry. Userspace should use the same socket as kernel - my application previously obtained it from dmesg and later used ULOG. > cheers, > jamal >=20 --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-i2Fx1frPqQmvuSu7WD7T Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCjfELIKTPhE+8wY0RAnJ7AKCExzSpBRYLKXojEcJseiXPPvymmwCdHq5c hH5c9iIcedpGNiJEJ5ZqUCU= =39jJ -----END PGP SIGNATURE----- --=-i2Fx1frPqQmvuSu7WD7T-- From greearb@candelatech.com Fri May 20 09:08:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 09:08:21 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KG8DF3010478 for ; Fri, 20 May 2005 09:08:13 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j4KGdCGf000810; Fri, 20 May 2005 09:39:12 -0700 Message-ID: <428E0B3B.1090507@candelatech.com> Date: Fri, 20 May 2005 09:07:23 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kosta Todorovic CC: jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: Network card driver problem (znb.o/tulip) References: <428CC958.1080909@candelatech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 4449 Lines: 132 Kosta Todorovic wrote: > 2 more questions: > > 1) Is there anything special I will need to compile in terms of the > linux kernel for 64-bit PCI bus mode (PCI-X) ? (Currently I'm using > kernel 2.4.x but that is because my current card drivers do not > support 2.6.x) Nothing special...2.4 and 2.6 kernels since way back will work just fine. > 2) The machine actually has a PCI extension with 9 other PCI-X slots. > The current cards are 64-bit (pci-x) but as a test i'm planning on > replacing them with DLinks DFE-580tx's. Unfortunately these are 32-bit > cards (legacy pci). How will these 4 ports work in 32-bit mode? What > will the effect be on the speed? If you put a 33Mhz NIC in a PCI-X bus it makes the entire bus run at 33Mhz speed. If you do want full backwards compatibility, get the 'universal' 4-port broadcom NIC from silicom-usa. It works fine in 32-bit PCI busses, and though I haven't personally tested it, it should work fine in PCI-X busses at high speed as well. Ben > > > > On 5/19/05, Ben Greear wrote: > >>Kosta Todorovic wrote: >> >>>Whats the best 4-port NIC currently available? I'm interested in >>>purchasing 10 4-port NICs as a replacement for my current cards. >>> >>>I am looking for 10/100Mbps and a good driver for linux (2.4.x and >>>2.6.x). Preferably a mainstream company but thats not priority. >>> >>>Could the community please recommend the best card available? Money is >>>not an issue since im really interested in the best of the best. >> >>Get an Intel 4-port GigE NIC. It will do 10/100/1000, and if you really >>want to use all 4 ports at even 100Mbps, you need the 64-bit PCI bus... >> >>I have been getting mine from silicom-usa.com lately. They also have >>6-port NICs, and 4-port broadcom GigE nics that can be used in 32-bit >>PCI slots. (The Intel 4-port NICs will only work in 64-bit PCI slots.) >> >>If you really want 10/100 nics, try the p430tx from aei: >>http://www.aei-it.com/hardware/fastenet/p430tx.htm >> >>These are like the old DFE570tx NICs, and use the tulip driver. They >>are almost as expensive as the GigE NICs though... >> >>Thanks, >>Ben >> >> >>>Any suggestions? >>> >>>Regards, >>>Kosta >>> >>> >>> >>>On 3/11/05, Kosta Todorovic wrote: >>> >>> >>>>My company has recently purchased several ZNYX ZX274 network cards. >>>>These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets. >>>> >>>>Unfortunately there exists no drivers for linux amd64 architecture. >>>>There are 32bit drivers found at: >>>>http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally >>>>they wont compile under my amd64 system. >>>> >>>>The driver itself is called znb.o and can be downloaded from ZNYX's >>>>website. I spoke to support staff there but they told me they have >>>>discontinued support and development for this series of cards. >>>> >>>>The system I am running gentoo and have tried both 2.4.x and 2.6.x >>>>kernels but no luck. >>>> >>>>Unfortunately there is NO 64bit drivers available for ANY platform. not even MS. >>>> >>>>Does anyone know of a customised znb.o driver built for amd64? >>>>Is there any chance of anyone modifying the source code of the driver >>>>to compile under a amd64 system? >>>> >>>>I've noticed that "tulip" drivers get loaded as a module at boot time. >>>>but they dont function correctly. (lets you start the device and >>>>attach ips but cant talk through it) >>>> >>>>Is there any variants of the tulip driver that will work for this? >>>> >>>>Help much appreciated. >>>> >>>> >>>>/proc/pci extract for network cards: >>>> >>>> Bus 5, device 5, function 0: >>>> Ethernet controller: Digital Equipment Corporation DECchip >>>>21142/43 (#30) (rev 65). >>>> IRQ 30. >>>> Master Capable. Latency=128. Min Gnt=20.Max Lat=40. >>>> I/O at 0x0 [0x7f]. >>>> Non-prefetchable 32 bit memory at 0xfa1ff400 [0xfa1ff7ff]. >>>> Bus 5, device 4, function 0: >>>> Ethernet controller: Digital Equipment Corporation DECchip >>>>21142/43 (#29) (rev 65). >>>> IRQ 29. >>>> Master Capable. No bursts. Min Gnt=20.Max Lat=40. >>>> I/O at 0x0 [0x7f]. >>>> Non-prefetchable 32 bit memory at 0xf9f00000 [0xf9f003ff]. >>>> >>> >>> >> >>-- >>Ben Greear >>Candela Technologies Inc http://www.candelatech.com >> >> > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From mchan@broadcom.com Fri May 20 11:14:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 11:14:24 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KIEJF3002711 for ; Fri, 20 May 2005 11:14:19 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 20 May 2005 11:13:47 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 20 May 2005 11:13:21 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZO07151; Fri, 20 May 2005 11:13:19 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA18806; Fri, 20 May 2005 11:13:19 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2005 18:13:19 +0000 Received: from rh4 by nt-irva-0741; 20 May 2005 10:15:29 -0700 Subject: A new driver for Broadcom bcm5706 From: "Michael Chan" To: davem@davemloft.net, jgarzik@redhat.com cc: netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Date: Fri, 20 May 2005 10:15:29 -0700 Message-ID: <1116609329.31523.16.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E90F7512V4268731-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 378 Lines: 13 A new driver bnx2 for Broadcom bcm5706 is available. Since the patch is over 500K, I've put it on the ftp server: ftp://Net_sys_anon@ftp1.broadcom.com/bnx2-2.patch The patch also includes new 1000BASE-X advertisement bit definitions in mii.h Thanks to David Miller and Jeff Garzik for reviewing and their valuable feedback. Signed-off-by: Michael Chan From davem@davemloft.net Fri May 20 11:11:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 11:11:38 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KIBRF3001535 for ; Fri, 20 May 2005 11:11:27 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DZBxI-0001OZ-RE; Fri, 20 May 2005 11:10:40 -0700 Date: Fri, 20 May 2005 11:10:40 -0700 (PDT) Message-Id: <20050520.111040.97294719.davem@davemloft.net> To: util@deuroconsult.ro Cc: netdev@oss.sgi.com Subject: Re: Notifier for features change? (related to Ethernet Bridging: Enable Hardware Checksumming) From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 300 Lines: 10 From: "Catalin(ux aka Dino) BOIE" Date: Fri, 20 May 2005 10:17:46 +0300 (EEST) > Because bridge can change features based on slaves features, > may I implement NETDEV_FEAT_CHANGE? > > It will be used to recompute bridge features when a slave ones are > changed. Please do. From davem@davemloft.net Fri May 20 11:52:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 11:52:44 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KIqcF3007388 for ; Fri, 20 May 2005 11:52:38 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DZCbC-0001my-GY for netdev@oss.sgi.com; Fri, 20 May 2005 11:51:54 -0700 Date: Fri, 20 May 2005 11:51:54 -0700 (PDT) Message-Id: <20050520.115154.48807299.davem@davemloft.net> To: netdev@oss.sgi.com Subject: [PATCH] Super TSO v2 From: "David S. Miller" X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 41266 Lines: 1342 Ok, new version of the patch. Besides some cleanups, the main change is packet send deferral at ACK arrival time. The issue is that an ACK can open up the window enough for one MSS sized segment, but not necessarily enough to send a significant portion of the TSO frame at the head of the queue. John Heffner described an algorithm to me which attempts to defer so that we accumulate some more send window space. It's quite effective. At first, this change had a side effect I couldn't account for, the congestion window would grow slowly and sometimes not at all with this change. It turns out that we do not grow the congestion window unless we had filled the current congestion window. These tests are in tcp_input.c:tcp_ack() where it goes: prior_in_flight = tcp_packets_in_flight(tp); ... if ((flag & FLAG_DATA_ACKED) && (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd)) tcp_cong_avoid(tp, ack, seq_rtt); tcp_cong_avoid() is what advances the congestion window. This precondition is part of congestion window validation (RFC2861), which basically states that the congestion window should not be advanced if the connection is application limited (and thus we are not really testing the link fully). If we defer, to leave more space for sending larger chunks of TSO frames, the "prior_in_flight >= tp->snd_cwnd" test will not pass when the next ACK arrives. In order to fix this, yet still preserve the intentions of the test, I added a tp->deferred which keeps track of how much send window space we left intentionally free to accumulate space. I'm slowly gaining a lot of confidence in this patch, so more testing would greatly be appreciated. It's pretty clear that the "TSO Reloaded" scheme is not worth pursuing much further, and that this stuff below is the way to go. Thanks. --- 1/include/linux/tcp.h.~1~ 2005-05-19 13:35:11.000000000 -0700 +++ 2/include/linux/tcp.h 2005-05-19 18:25:00.000000000 -0700 @@ -280,13 +280,15 @@ struct tcp_sock { __u32 snd_wnd; /* The window we expect to receive */ __u32 max_window; /* Maximal window ever seen from peer */ __u32 pmtu_cookie; /* Last pmtu seen by socket */ - __u32 mss_cache; /* Cached effective mss, not including SACKS */ - __u16 mss_cache_std; /* Like mss_cache, but without TSO */ + __u16 mss_cache; /* Cached effective mss, not including SACKS */ + __u16 xmit_size_goal; /* Goal for segmenting output packets */ + __u32 xmit_size_cache;/* Cache for keeping xmit_size_goal uptodate */ __u16 ext_header_len; /* Network protocol overhead (IP/IPv6 options) */ __u8 ca_state; /* State of fast-retransmit machine */ __u8 retransmits; /* Number of unrecovered RTO timeouts. */ __u16 advmss; /* Advertised MSS */ + __u16 deferred; /* Packets deferred for segmentation */ __u32 window_clamp; /* Maximal window to advertise */ __u32 rcv_ssthresh; /* Current window clamp */ --- 1/include/net/sock.h.~1~ 2005-05-19 13:35:11.000000000 -0700 +++ 2/include/net/sock.h 2005-05-19 13:35:15.000000000 -0700 @@ -1130,13 +1130,16 @@ static inline void sk_stream_moderate_sn static inline struct sk_buff *sk_stream_alloc_pskb(struct sock *sk, int size, int mem, int gfp) { - struct sk_buff *skb = alloc_skb(size + sk->sk_prot->max_header, gfp); + struct sk_buff *skb; + int hdr_len; + hdr_len = SKB_DATA_ALIGN(sk->sk_prot->max_header); + skb = alloc_skb(size + hdr_len, gfp); if (skb) { skb->truesize += mem; if (sk->sk_forward_alloc >= (int)skb->truesize || sk_stream_mem_schedule(sk, skb->truesize, 0)) { - skb_reserve(skb, sk->sk_prot->max_header); + skb_reserve(skb, hdr_len); return skb; } __kfree_skb(skb); --- 1/include/net/tcp.h.~1~ 2005-05-19 13:35:11.000000000 -0700 +++ 2/include/net/tcp.h 2005-05-19 13:35:15.000000000 -0700 @@ -817,11 +817,18 @@ static inline int tcp_ack_scheduled(stru return tp->ack.pending&TCP_ACK_SCHED; } -static __inline__ void tcp_dec_quickack_mode(struct tcp_sock *tp) +static __inline__ void tcp_dec_quickack_mode(struct tcp_sock *tp, unsigned int pkts) { - if (tp->ack.quick && --tp->ack.quick == 0) { - /* Leaving quickack mode we deflate ATO. */ - tp->ack.ato = TCP_ATO_MIN; + if (tp->ack.quick) { + if (pkts > tp->ack.quick) + tp->ack.quick = 0; + else + tp->ack.quick -= pkts; + + if (!tp->ack.quick) { + /* Leaving quickack mode we deflate ATO. */ + tp->ack.ato = TCP_ATO_MIN; + } } } @@ -939,7 +946,14 @@ extern __u32 cookie_v4_init_sequence(str /* tcp_output.c */ -extern int tcp_write_xmit(struct sock *, int nonagle); +extern void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb); +extern void __tcp_push_pending_frames(struct sock *sk, + struct tcp_sock *tp, + unsigned int cur_mss, + int nonagle); +extern int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp); +extern int tcp_tso_mince(struct sock *sk, struct tcp_sock *tp, + struct sk_buff *skb); extern int tcp_retransmit_skb(struct sock *, struct sk_buff *); extern void tcp_xmit_retransmit_queue(struct sock *); extern void tcp_simple_retransmit(struct sock *); @@ -951,7 +965,7 @@ extern int tcp_write_wakeup(struct sock extern void tcp_send_fin(struct sock *sk); extern void tcp_send_active_reset(struct sock *sk, int priority); extern int tcp_send_synack(struct sock *); -extern void tcp_push_one(struct sock *, unsigned mss_now); +extern void tcp_push_one(struct sock *, unsigned int mss_now); extern void tcp_send_ack(struct sock *sk); extern void tcp_send_delayed_ack(struct sock *sk); @@ -1054,7 +1068,7 @@ static inline void tcp_reset_xmit_timer( static inline void tcp_initialize_rcv_mss(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); - unsigned int hint = min(tp->advmss, tp->mss_cache_std); + unsigned int hint = min(tp->advmss, tp->mss_cache); hint = min(hint, tp->rcv_wnd/2); hint = min(hint, TCP_MIN_RCVMSS); @@ -1353,23 +1367,23 @@ static inline void tcp_cwnd_validate(str } /* Set slow start threshould and cwnd not falling to slow start */ -static inline void __tcp_enter_cwr(struct tcp_sock *tp) +static inline void __tcp_enter_cwr(struct tcp_sock *tp, unsigned int pkts) { tp->undo_marker = 0; tp->snd_ssthresh = tcp_recalc_ssthresh(tp); tp->snd_cwnd = min(tp->snd_cwnd, - tcp_packets_in_flight(tp) + 1U); + tcp_packets_in_flight(tp) + pkts); tp->snd_cwnd_cnt = 0; tp->high_seq = tp->snd_nxt; tp->snd_cwnd_stamp = tcp_time_stamp; TCP_ECN_queue_cwr(tp); } -static inline void tcp_enter_cwr(struct tcp_sock *tp) +static inline void tcp_enter_cwr(struct tcp_sock *tp, unsigned int pkts) { tp->prior_ssthresh = 0; if (tp->ca_state < TCP_CA_CWR) { - __tcp_enter_cwr(tp); + __tcp_enter_cwr(tp, pkts); tcp_set_ca_state(tp, TCP_CA_CWR); } } @@ -1397,74 +1411,6 @@ static __inline__ void tcp_minshall_upda tp->snd_sml = TCP_SKB_CB(skb)->end_seq; } -/* Return 0, if packet can be sent now without violation Nagle's rules: - 1. It is full sized. - 2. Or it contains FIN. - 3. Or TCP_NODELAY was set. - 4. Or TCP_CORK is not set, and all sent packets are ACKed. - With Minshall's modification: all sent small packets are ACKed. - */ - -static __inline__ int -tcp_nagle_check(const struct tcp_sock *tp, const struct sk_buff *skb, - unsigned mss_now, int nonagle) -{ - return (skb->len < mss_now && - !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && - ((nonagle&TCP_NAGLE_CORK) || - (!nonagle && - tp->packets_out && - tcp_minshall_check(tp)))); -} - -extern void tcp_set_skb_tso_segs(struct sock *, struct sk_buff *); - -/* This checks if the data bearing packet SKB (usually sk->sk_send_head) - * should be put on the wire right now. - */ -static __inline__ int tcp_snd_test(struct sock *sk, - struct sk_buff *skb, - unsigned cur_mss, int nonagle) -{ - struct tcp_sock *tp = tcp_sk(sk); - int pkts = tcp_skb_pcount(skb); - - if (!pkts) { - tcp_set_skb_tso_segs(sk, skb); - pkts = tcp_skb_pcount(skb); - } - - /* RFC 1122 - section 4.2.3.4 - * - * We must queue if - * - * a) The right edge of this frame exceeds the window - * b) There are packets in flight and we have a small segment - * [SWS avoidance and Nagle algorithm] - * (part of SWS is done on packetization) - * Minshall version sounds: there are no _small_ - * segments in flight. (tcp_nagle_check) - * c) We have too many packets 'in flight' - * - * Don't use the nagle rule for urgent data (or - * for the final FIN -DaveM). - * - * Also, Nagle rule does not apply to frames, which - * sit in the middle of queue (they have no chances - * to get new data) and if room at tail of skb is - * not enough to save something seriously (<32 for now). - */ - - /* Don't be strict about the congestion window for the - * final FIN frame. -DaveM - */ - return (((nonagle&TCP_NAGLE_PUSH) || tp->urg_mode - || !tcp_nagle_check(tp, skb, cur_mss, nonagle)) && - (((tcp_packets_in_flight(tp) + (pkts-1)) < tp->snd_cwnd) || - (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) && - !after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd)); -} - static __inline__ void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp) { if (!tp->packets_out && !tp->pending) @@ -1477,42 +1423,12 @@ static __inline__ int tcp_skb_is_last(co return skb->next == (struct sk_buff *)&sk->sk_write_queue; } -/* Push out any pending frames which were held back due to - * TCP_CORK or attempt at coalescing tiny packets. - * The socket must be locked by the caller. - */ -static __inline__ void __tcp_push_pending_frames(struct sock *sk, - struct tcp_sock *tp, - unsigned cur_mss, - int nonagle) -{ - struct sk_buff *skb = sk->sk_send_head; - - if (skb) { - if (!tcp_skb_is_last(sk, skb)) - nonagle = TCP_NAGLE_PUSH; - if (!tcp_snd_test(sk, skb, cur_mss, nonagle) || - tcp_write_xmit(sk, nonagle)) - tcp_check_probe_timer(sk, tp); - } - tcp_cwnd_validate(sk, tp); -} - static __inline__ void tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp) { __tcp_push_pending_frames(sk, tp, tcp_current_mss(sk, 1), tp->nonagle); } -static __inline__ int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp) -{ - struct sk_buff *skb = sk->sk_send_head; - - return (skb && - tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), - tcp_skb_is_last(sk, skb) ? TCP_NAGLE_PUSH : tp->nonagle)); -} - static __inline__ void tcp_init_wl(struct tcp_sock *tp, u32 ack, u32 seq) { tp->snd_wl1 = seq; @@ -1986,7 +1902,7 @@ static inline void tcp_westwood_update_r static inline __u32 __tcp_westwood_bw_rttmin(const struct tcp_sock *tp) { return max((tp->westwood.bw_est) * (tp->westwood.rtt_min) / - (__u32) (tp->mss_cache_std), + (__u32) (tp->mss_cache), 2U); } --- 1/net/ipv4/tcp.c.~1~ 2005-05-19 13:35:11.000000000 -0700 +++ 2/net/ipv4/tcp.c 2005-05-19 13:35:15.000000000 -0700 @@ -634,7 +634,7 @@ static ssize_t do_tcp_sendpages(struct s size_t psize, int flags) { struct tcp_sock *tp = tcp_sk(sk); - int mss_now; + int mss_now, size_goal; int err; ssize_t copied; long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT); @@ -647,6 +647,7 @@ static ssize_t do_tcp_sendpages(struct s clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; copied = 0; err = -EPIPE; @@ -660,7 +661,7 @@ static ssize_t do_tcp_sendpages(struct s int offset = poffset % PAGE_SIZE; int size = min_t(size_t, psize, PAGE_SIZE - offset); - if (!sk->sk_send_head || (copy = mss_now - skb->len) <= 0) { + if (!sk->sk_send_head || (copy = size_goal - skb->len) <= 0) { new_segment: if (!sk_stream_memory_free(sk)) goto wait_for_sndbuf; @@ -671,7 +672,7 @@ new_segment: goto wait_for_memory; skb_entail(sk, tp, skb); - copy = mss_now; + copy = size_goal; } if (copy > size) @@ -712,7 +713,7 @@ new_segment: if (!(psize -= copy)) goto out; - if (skb->len != mss_now || (flags & MSG_OOB)) + if (skb->len != size_goal || (flags & MSG_OOB)) continue; if (forced_push(tp)) { @@ -732,6 +733,7 @@ wait_for_memory: goto do_error; mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; } out: @@ -773,15 +775,11 @@ ssize_t tcp_sendpage(struct socket *sock static inline int select_size(struct sock *sk, struct tcp_sock *tp) { - int tmp = tp->mss_cache_std; + int tmp = tp->mss_cache; - if (sk->sk_route_caps & NETIF_F_SG) { - int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER); + if (sk->sk_route_caps & NETIF_F_SG) + tmp = 0; - if (tmp >= pgbreak && - tmp <= pgbreak + (MAX_SKB_FRAGS - 1) * PAGE_SIZE) - tmp = pgbreak; - } return tmp; } @@ -792,7 +790,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *skb; int iovlen, flags; - int mss_now; + int mss_now, size_goal; int err, copied; long timeo; @@ -811,6 +809,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; /* Ok commence sending. */ iovlen = msg->msg_iovlen; @@ -833,7 +832,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru skb = sk->sk_write_queue.prev; if (!sk->sk_send_head || - (copy = mss_now - skb->len) <= 0) { + (copy = size_goal - skb->len) <= 0) { new_segment: /* Allocate new segment. If the interface is SG, @@ -856,7 +855,7 @@ new_segment: skb->ip_summed = CHECKSUM_HW; skb_entail(sk, tp, skb); - copy = mss_now; + copy = size_goal; } /* Try to append data to the end of skb. */ @@ -891,11 +890,6 @@ new_segment: tcp_mark_push(tp, skb); goto new_segment; } else if (page) { - /* If page is cached, align - * offset to L1 cache boundary - */ - off = (off + L1_CACHE_BYTES - 1) & - ~(L1_CACHE_BYTES - 1); if (off == PAGE_SIZE) { put_page(page); TCP_PAGE(sk) = page = NULL; @@ -956,7 +950,7 @@ new_segment: if ((seglen -= copy) == 0 && iovlen == 0) goto out; - if (skb->len != mss_now || (flags & MSG_OOB)) + if (skb->len != size_goal || (flags & MSG_OOB)) continue; if (forced_push(tp)) { @@ -976,6 +970,7 @@ wait_for_memory: goto do_error; mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; } } @@ -2135,7 +2130,7 @@ void tcp_get_info(struct sock *sk, struc info->tcpi_rto = jiffies_to_usecs(tp->rto); info->tcpi_ato = jiffies_to_usecs(tp->ack.ato); - info->tcpi_snd_mss = tp->mss_cache_std; + info->tcpi_snd_mss = tp->mss_cache; info->tcpi_rcv_mss = tp->ack.rcv_mss; info->tcpi_unacked = tp->packets_out; @@ -2185,7 +2180,7 @@ int tcp_getsockopt(struct sock *sk, int switch (optname) { case TCP_MAXSEG: - val = tp->mss_cache_std; + val = tp->mss_cache; if (!val && ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN))) val = tp->rx_opt.user_mss; break; --- 1/net/ipv4/tcp_input.c.~1~ 2005-05-19 13:35:11.000000000 -0700 +++ 2/net/ipv4/tcp_input.c 2005-05-19 21:25:38.000000000 -0700 @@ -805,10 +805,10 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp, __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0); if (!cwnd) { - if (tp->mss_cache_std > 1460) + if (tp->mss_cache > 1460) cwnd = 2; else - cwnd = (tp->mss_cache_std > 1095) ? 3 : 4; + cwnd = (tp->mss_cache > 1095) ? 3 : 4; } return min_t(__u32, cwnd, tp->snd_cwnd_clamp); } @@ -974,14 +974,6 @@ tcp_sacktag_write_queue(struct sock *sk, int flag = 0; int i; - /* So, SACKs for already sent large segments will be lost. - * Not good, but alternative is to resegment the queue. */ - if (sk->sk_route_caps & NETIF_F_TSO) { - sk->sk_route_caps &= ~NETIF_F_TSO; - sock_set_flag(sk, SOCK_NO_LARGESEND); - tp->mss_cache = tp->mss_cache_std; - } - if (!tp->sacked_out) tp->fackets_out = 0; prior_fackets = tp->fackets_out; @@ -1038,6 +1030,15 @@ tcp_sacktag_write_queue(struct sock *sk, if(!before(TCP_SKB_CB(skb)->seq, end_seq)) break; + /* Even if mincing a TSO frame fails, we + * continue anyways. We will end up with + * more coarse SACK information, but it is + * better than ignoring all the SACK information + * altogether. + */ + if (tcp_skb_pcount(skb) > 1) + tcp_tso_mince(sk, tp, skb); + fack_count += tcp_skb_pcount(skb); in_sack = !after(start_seq, TCP_SKB_CB(skb)->seq) && @@ -1142,7 +1143,7 @@ tcp_sacktag_write_queue(struct sock *sk, (IsFack(tp) || !before(lost_retrans, TCP_SKB_CB(skb)->ack_seq + tp->reordering * - tp->mss_cache_std))) { + tp->mss_cache))) { TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS; tp->retrans_out -= tcp_skb_pcount(skb); @@ -1782,7 +1783,7 @@ static void tcp_try_to_open(struct sock tp->retrans_stamp = 0; if (flag&FLAG_ECE) - tcp_enter_cwr(tp); + tcp_enter_cwr(tp, 1); if (tp->ca_state != TCP_CA_CWR) { int state = TCP_CA_Open; @@ -2170,7 +2171,7 @@ static void vegas_cong_avoid(struct tcp_ * is the cwnd during the previous RTT. */ old_wnd = (tp->vegas.beg_snd_nxt - tp->vegas.beg_snd_una) / - tp->mss_cache_std; + tp->mss_cache; old_snd_cwnd = tp->vegas.beg_snd_cwnd; /* Save the extent of the current window so we can use this @@ -2799,19 +2800,19 @@ static void westwood_dupack_update(struc { struct tcp_sock *tp = tcp_sk(sk); - tp->westwood.accounted += tp->mss_cache_std; - tp->westwood.cumul_ack = tp->mss_cache_std; + tp->westwood.accounted += tp->mss_cache; + tp->westwood.cumul_ack = tp->mss_cache; } static inline int westwood_may_change_cumul(struct tcp_sock *tp) { - return (tp->westwood.cumul_ack > tp->mss_cache_std); + return (tp->westwood.cumul_ack > tp->mss_cache); } static inline void westwood_partial_update(struct tcp_sock *tp) { tp->westwood.accounted -= tp->westwood.cumul_ack; - tp->westwood.cumul_ack = tp->mss_cache_std; + tp->westwood.cumul_ack = tp->mss_cache; } static inline void westwood_complete_update(struct tcp_sock *tp) @@ -2932,7 +2933,7 @@ static int tcp_ack(struct sock *sk, stru if (!prior_packets) goto no_queue; - prior_in_flight = tcp_packets_in_flight(tp); + prior_in_flight = tcp_packets_in_flight(tp) + tp->deferred; /* See if we can take anything off of the retransmit queue. */ flag |= tcp_clean_rtx_queue(sk, &seq_rtt); @@ -2948,7 +2949,7 @@ static int tcp_ack(struct sock *sk, stru tcp_cong_avoid(tp, ack, seq_rtt); tcp_fastretrans_alert(sk, prior_snd_una, prior_packets, flag); } else { - if ((flag & FLAG_DATA_ACKED) && + if ((flag & FLAG_DATA_ACKED) && (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd)) tcp_cong_avoid(tp, ack, seq_rtt); } @@ -3948,11 +3949,11 @@ static void tcp_new_space(struct sock *s { struct tcp_sock *tp = tcp_sk(sk); - if (tp->packets_out < tp->snd_cwnd && + if ((tp->packets_out + tp->deferred) < tp->snd_cwnd && !(sk->sk_userlocks & SOCK_SNDBUF_LOCK) && !tcp_memory_pressure && atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0]) { - int sndmem = max_t(u32, tp->rx_opt.mss_clamp, tp->mss_cache_std) + + int sndmem = max_t(u32, tp->rx_opt.mss_clamp, tp->mss_cache) + MAX_TCP_HEADER + 16 + sizeof(struct sk_buff), demanded = max_t(unsigned int, tp->snd_cwnd, tp->reordering + 1); @@ -3975,16 +3976,6 @@ static inline void tcp_check_space(struc } } -static void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb) -{ - struct tcp_sock *tp = tcp_sk(sk); - - if (after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd) || - tcp_packets_in_flight(tp) >= tp->snd_cwnd || - tcp_write_xmit(sk, tp->nonagle)) - tcp_check_probe_timer(sk, tp); -} - static __inline__ void tcp_data_snd_check(struct sock *sk) { struct sk_buff *skb = sk->sk_send_head; --- 1/net/ipv4/tcp_ipv4.c.~1~ 2005-05-19 13:35:11.000000000 -0700 +++ 2/net/ipv4/tcp_ipv4.c 2005-05-19 13:35:15.000000000 -0700 @@ -2060,7 +2060,8 @@ static int tcp_v4_init_sock(struct sock */ tp->snd_ssthresh = 0x7fffffff; /* Infinity */ tp->snd_cwnd_clamp = ~0; - tp->mss_cache_std = tp->mss_cache = 536; + tp->mss_cache = 536; + tp->xmit_size_cache = ~0; tp->reordering = sysctl_tcp_reordering; --- 1/net/ipv4/tcp_output.c.~1~ 2005-05-19 13:35:11.000000000 -0700 +++ 2/net/ipv4/tcp_output.c 2005-05-19 21:34:15.000000000 -0700 @@ -58,6 +58,7 @@ static inline void update_send_head(stru if (sk->sk_send_head == (struct sk_buff *)&sk->sk_write_queue) sk->sk_send_head = NULL; tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; + tp->deferred = 0; tcp_packets_out_inc(sk, tp, skb); } @@ -141,11 +142,11 @@ static inline void tcp_event_data_sent(s tp->ack.pingpong = 1; } -static __inline__ void tcp_event_ack_sent(struct sock *sk) +static __inline__ void tcp_event_ack_sent(struct sock *sk, unsigned int pkts) { struct tcp_sock *tp = tcp_sk(sk); - tcp_dec_quickack_mode(tp); + tcp_dec_quickack_mode(tp, pkts); tcp_clear_xmit_timer(sk, TCP_TIME_DACK); } @@ -361,7 +362,7 @@ static int tcp_transmit_skb(struct sock tp->af_specific->send_check(sk, th, skb->len, skb); if (tcb->flags & TCPCB_FLAG_ACK) - tcp_event_ack_sent(sk); + tcp_event_ack_sent(sk, tcp_skb_pcount(skb)); if (skb->len != tcp_header_size) tcp_event_data_sent(tp, skb, sk); @@ -372,7 +373,7 @@ static int tcp_transmit_skb(struct sock if (err <= 0) return err; - tcp_enter_cwr(tp); + tcp_enter_cwr(tp, tcp_skb_pcount(skb)); /* NET_XMIT_CN is special. It does not guarantee, * that this packet is lost. It tells that device @@ -409,42 +410,11 @@ static void tcp_queue_skb(struct sock *s sk->sk_send_head = skb; } -static inline void tcp_tso_set_push(struct sk_buff *skb) -{ - /* Force push to be on for any TSO frames to workaround - * problems with busted implementations like Mac OS-X that - * hold off socket receive wakeups until push is seen. - */ - if (tcp_skb_pcount(skb) > 1) - TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; -} - -/* Send _single_ skb sitting at the send head. This function requires - * true push pending frames to setup probe timer etc. - */ -void tcp_push_one(struct sock *sk, unsigned cur_mss) -{ - struct tcp_sock *tp = tcp_sk(sk); - struct sk_buff *skb = sk->sk_send_head; - - if (tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH)) { - /* Send it out now. */ - TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); - if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { - sk->sk_send_head = NULL; - tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; - tcp_packets_out_inc(sk, tp, skb); - return; - } - } -} - void tcp_set_skb_tso_segs(struct sock *sk, struct sk_buff *skb) { struct tcp_sock *tp = tcp_sk(sk); - if (skb->len <= tp->mss_cache_std || + if (skb->len <= tp->mss_cache || !(sk->sk_route_caps & NETIF_F_TSO)) { /* Avoid the costly divide in the normal * non-TSO case. @@ -454,10 +424,10 @@ void tcp_set_skb_tso_segs(struct sock *s } else { unsigned int factor; - factor = skb->len + (tp->mss_cache_std - 1); - factor /= tp->mss_cache_std; + factor = skb->len + (tp->mss_cache - 1); + factor /= tp->mss_cache; skb_shinfo(skb)->tso_segs = factor; - skb_shinfo(skb)->tso_size = tp->mss_cache_std; + skb_shinfo(skb)->tso_size = tp->mss_cache; } } @@ -662,7 +632,7 @@ unsigned int tcp_sync_mss(struct sock *s /* And store cached results */ tp->pmtu_cookie = pmtu; - tp->mss_cache = tp->mss_cache_std = mss_now; + tp->mss_cache = mss_now; return mss_now; } @@ -674,117 +644,493 @@ unsigned int tcp_sync_mss(struct sock *s * cannot be large. However, taking into account rare use of URG, this * is not a big flaw. */ +static inline u32 compute_xmit_cache(u32 mss, int sacks, int tso_enabled) +{ + u32 ret = (mss << 16) | sacks; -unsigned int tcp_current_mss(struct sock *sk, int large) + if (tso_enabled) + ret |= (1 << 8); + + return ret; +} + +unsigned int tcp_current_mss(struct sock *sk, int large_allowed) { struct tcp_sock *tp = tcp_sk(sk); struct dst_entry *dst = __sk_dst_get(sk); - unsigned int do_large, mss_now; + u32 mss_now; + u32 xmit_cache; + int doing_tso = 0; + + mss_now = tp->mss_cache; + + if (large_allowed && + (sk->sk_route_caps & NETIF_F_TSO) && + !tp->urg_mode) + doing_tso = 1; - mss_now = tp->mss_cache_std; if (dst) { u32 mtu = dst_mtu(dst); if (mtu != tp->pmtu_cookie) mss_now = tcp_sync_mss(sk, mtu); } - do_large = (large && - (sk->sk_route_caps & NETIF_F_TSO) && - !tp->urg_mode); - - if (do_large) { - unsigned int large_mss, factor, limit; - - large_mss = 65535 - tp->af_specific->net_header_len - - tp->ext_header_len - tp->tcp_header_len; - - if (tp->max_window && large_mss > (tp->max_window>>1)) - large_mss = max((tp->max_window>>1), - 68U - tp->tcp_header_len); - - factor = large_mss / mss_now; - - /* Always keep large mss multiple of real mss, but - * do not exceed 1/tso_win_divisor of the congestion window - * so we can keep the ACK clock ticking and minimize - * bursting. - */ - limit = tp->snd_cwnd; - if (sysctl_tcp_tso_win_divisor) - limit /= sysctl_tcp_tso_win_divisor; - limit = max(1U, limit); - if (factor > limit) - factor = limit; - - tp->mss_cache = mss_now * factor; - - mss_now = tp->mss_cache; - } + /* If the MSS, the TSO state, or the number of SACK blocks + * changes, we have to recompute tp->xmit_size_goal. + */ + xmit_cache = compute_xmit_cache(mss_now, tp->rx_opt.eff_sacks, + doing_tso); if (tp->rx_opt.eff_sacks) mss_now -= (TCPOLEN_SACK_BASE_ALIGNED + (tp->rx_opt.eff_sacks * TCPOLEN_SACK_PERBLOCK)); + + if (tp->xmit_size_cache != xmit_cache) { + u16 xmit_size_goal = mss_now; + + if (doing_tso) { + xmit_size_goal = 65535 - + tp->af_specific->net_header_len - + tp->ext_header_len - tp->tcp_header_len; + + if (tp->rx_opt.eff_sacks) + xmit_size_goal -= (TCPOLEN_SACK_BASE_ALIGNED + + (tp->rx_opt.eff_sacks * + TCPOLEN_SACK_PERBLOCK)); + + xmit_size_goal -= (xmit_size_goal % mss_now); + } + tp->xmit_size_goal = xmit_size_goal; + tp->xmit_size_cache = xmit_cache; + } + return mss_now; } +static inline unsigned int tso_size_limit(u32 window, unsigned int mss_now, unsigned int cwnd) +{ + u32 cwnd_len; + + cwnd_len = mss_now * cwnd; + return min(window, cwnd_len); +} + +/* Can at least one segment of SKB be sent right now, according + * to the congestion window rules? If so, return how many segments + * are allowed. + */ +static inline unsigned int tcp_cwnd_test(struct tcp_sock *tp, struct sk_buff *skb) +{ + u32 in_flight, cwnd; + + /* Don't be strict about the congestion window for the + * final FIN frame. -DaveM + */ + if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) + return 1; + + in_flight = tcp_packets_in_flight(tp); + cwnd = tp->snd_cwnd; + if (in_flight < cwnd) + return (cwnd - in_flight); + + return 0; +} + +/* This must be invoked the first time we consider transmitting + * SKB onto the wire. + */ +static inline int tcp_init_tso_segs(struct sock *sk, struct sk_buff *skb) +{ + int tso_segs = tcp_skb_pcount(skb); + + if (!tso_segs) { + tcp_set_skb_tso_segs(sk, skb); + tso_segs = tcp_skb_pcount(skb); + } + return tso_segs; +} + +/* Return 0, if packet can be sent now without violation Nagle's rules: + * 1. It is full sized. + * 2. Or it contains FIN. + * 3. Or TCP_NODELAY was set. + * 4. Or TCP_CORK is not set, and all sent packets are ACKed. + * With Minshall's modification: all sent small packets are ACKed. + */ + +static inline int tcp_nagle_check(const struct tcp_sock *tp, + const struct sk_buff *skb, + unsigned mss_now, int nonagle) +{ + return (skb->len < mss_now && + !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && + ((nonagle&TCP_NAGLE_CORK) || + (!nonagle && + tp->packets_out && + tcp_minshall_check(tp)))); +} + +/* Return non-zero if the Nagle test allows this packet to be + * sent now. + */ +static inline int tcp_nagle_test(struct tcp_sock *tp, struct sk_buff *skb, unsigned int cur_mss, int nonagle) +{ + /* Nagle rule does not apply to frames, which + * sit in the middle of queue (they have no chances + * to get new data). + * + * This is implemented in the callers, where they modify + * the 'nonagle' argument based upon the location of SKB + * in the send queue. + */ + if (nonagle & TCP_NAGLE_PUSH) + return 1; + + /* Don't use the nagle rule for urgent data (or + * for the final FIN -DaveM). + */ + if (tp->urg_mode || + (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) + return 1; + + if (!tcp_nagle_check(tp, skb, cur_mss, nonagle)) + return 1; + + return 0; +} + +/* Does at least the first segment of SKB fit into the congestion + * window? + */ +static inline int tcp_snd_wnd_test(struct tcp_sock *tp, struct sk_buff *skb, unsigned int cur_mss) +{ + u32 end_seq = TCP_SKB_CB(skb)->end_seq; + + if (skb->len > cur_mss) + end_seq = TCP_SKB_CB(skb)->seq + cur_mss; + + return !after(end_seq, tp->snd_una + tp->snd_wnd); +} + +/* This checks if the data bearing packet SKB (usually + * sk->sk_send_head) should be put on the wire right now. If so, it + * returns the number of packets allowed by the congestion window. + */ +static unsigned int tcp_snd_test(struct sock *sk, struct sk_buff *skb, + unsigned cur_mss, int nonagle) +{ + struct tcp_sock *tp = tcp_sk(sk); + unsigned int cwnd_quota; + + if (!tcp_nagle_test(tp, skb, cur_mss, nonagle)) + return 0; + + cwnd_quota = tcp_cwnd_test(tp, skb); + if (cwnd_quota && + !tcp_snd_wnd_test(tp, skb, cur_mss)) + cwnd_quota = 0; + + return cwnd_quota; +} + +int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp) +{ + struct sk_buff *skb = sk->sk_send_head; + + return (skb && + tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), + tcp_skb_is_last(sk, skb) ? TCP_NAGLE_PUSH : tp->nonagle)); +} + +/* Trim TSO SKB to LEN bytes, put the remaining data into a new packet + * which is put after SKB on the list. It is very much like + * tcp_fragment() except that it may make several kinds of assumptions + * in order to speed up the splitting operation. In particular, we + * know that all the data is in scatter-gather pages, and that the + * packet has never been sent out before (and thus is not cloned). + */ +static int tso_fragment(struct sock *sk, struct sk_buff *skb, unsigned int len) +{ + struct sk_buff *buff; + int nlen = skb->len - len; + u16 flags; + + /* All of a TSO frame must be composed of paged data. */ + BUG_ON(skb->len != skb->data_len); + + buff = sk_stream_alloc_pskb(sk, 0, 0, GFP_ATOMIC); + if (unlikely(buff == NULL)) + return -ENOMEM; + sk_charge_skb(sk, buff); + + buff->truesize += nlen; + skb->truesize -= nlen; + + /* Correct the sequence numbers. */ + TCP_SKB_CB(buff)->seq = TCP_SKB_CB(skb)->seq + len; + TCP_SKB_CB(buff)->end_seq = TCP_SKB_CB(skb)->end_seq; + TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(buff)->seq; + + /* PSH and FIN should only be set in the second packet. */ + flags = TCP_SKB_CB(skb)->flags; + TCP_SKB_CB(skb)->flags = flags & ~(TCPCB_FLAG_FIN|TCPCB_FLAG_PSH); + TCP_SKB_CB(buff)->flags = flags; + + /* This packet was never sent out yet, so no SACK bits. */ + TCP_SKB_CB(buff)->sacked = 0; + + buff->ip_summed = skb->ip_summed = CHECKSUM_HW; + skb_split(skb, buff, len); + + /* Fix up tso_factor for both original and new SKB. */ + tcp_set_skb_tso_segs(sk, skb); + tcp_set_skb_tso_segs(sk, buff); + + /* Link BUFF into the send queue. */ + __skb_append(skb, buff); + + return 0; +} + +/* Split TSO frame SKB into one MSS sized packet, then the rest. + * This is called during SACK processing when some SACK information + * hits a TSO packet. + */ +int tcp_tso_mince(struct sock *sk, struct tcp_sock *tp, struct sk_buff *skb) +{ + unsigned int mss_now = tcp_current_mss(sk, 1); + + BUG_ON(tcp_skb_pcount(skb) <= 1); + + /* We cannot use tso_fragment() in this case, because + * the packet has been sent once already and thus may + * be cloned or have other non-trivial details to deal + * with. + */ + return tcp_fragment(sk, skb, mss_now); +} + /* This routine writes packets to the network. It advances the * send_head. This happens as incoming acks open up the remote - * window for us. + * window for us. Caller makes sure sk_send_head is non-NULL. * * Returns 1, if no segments are in flight and we have queued segments, but * cannot send anything now because of SWS or another problem. */ -int tcp_write_xmit(struct sock *sk, int nonagle) +static int tcp_write_xmit(struct sock *sk, int nonagle) { struct tcp_sock *tp = tcp_sk(sk); - unsigned int mss_now; + unsigned int mss_now, cwnd_quota, sent_pkts, tso_segs; + struct sk_buff *skb; /* If we are closed, the bytes will have to remain here. * In time closedown will finish, we empty the write queue and all * will be happy. */ - if (sk->sk_state != TCP_CLOSE) { - struct sk_buff *skb; - int sent_pkts = 0; + if (unlikely(sk->sk_state == TCP_CLOSE)) + return 0; - /* Account for SACKS, we may need to fragment due to this. - * It is just like the real MSS changing on us midstream. - * We also handle things correctly when the user adds some - * IP options mid-stream. Silly to do, but cover it. - */ - mss_now = tcp_current_mss(sk, 1); + /* Account for SACKS, we may need to fragment due to this. + * It is just like the real MSS changing on us midstream. + * We also handle things correctly when the user adds some + * IP options mid-stream. Silly to do, but cover it. + */ + mss_now = tcp_current_mss(sk, 1); - while ((skb = sk->sk_send_head) && - tcp_snd_test(sk, skb, mss_now, - tcp_skb_is_last(sk, skb) ? nonagle : - TCP_NAGLE_PUSH)) { - if (skb->len > mss_now) { - if (tcp_fragment(sk, skb, mss_now)) - break; - } + skb = sk->sk_send_head; + tso_segs = tcp_init_tso_segs(sk, skb); + cwnd_quota = tcp_cwnd_test(tp, skb); + sent_pkts = 0; + + while (cwnd_quota) { + if (!tcp_nagle_test(tp, skb, mss_now, + (tcp_skb_is_last(sk, skb) ? + nonagle : TCP_NAGLE_PUSH))) + break; - TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); - if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) - break; + if (!tcp_snd_wnd_test(tp, skb, mss_now)) + break; + + BUG_ON(!tso_segs); - /* Advance the send_head. This one is sent out. - * This call will increment packets_out. + if (tso_segs > 1) { + u32 window_seq = tp->snd_una + tp->snd_wnd; + u32 limit = tso_size_limit(window_seq - + TCP_SKB_CB(skb)->seq, + mss_now, cwnd_quota); + u32 naglet_size; + + /* If we have sub-mss chunk at the tail, + * split it off so that we nagle properly. */ - update_send_head(sk, tp, skb); + naglet_size = (skb->len % mss_now); + if (naglet_size) + limit = min(limit, skb->len - naglet_size); - tcp_minshall_update(tp, mss_now, skb); - sent_pkts = 1; + if (skb->len > limit) { + if (tso_fragment(sk, skb, limit)) + break; + } + } else if (skb->len > mss_now) { + if (tcp_fragment(sk, skb, mss_now)) + break; } - if (sent_pkts) { - tcp_cwnd_validate(sk, tp); - return 0; + TCP_SKB_CB(skb)->when = tcp_time_stamp; + if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) + break; + + /* Advance the send_head. This one is sent out. + * This call will increment packets_out. + */ + update_send_head(sk, tp, skb); + + tcp_minshall_update(tp, mss_now, skb); + sent_pkts++; + + cwnd_quota -= tcp_skb_pcount(skb); + skb = sk->sk_send_head; + if (!skb) + break; + tso_segs = tcp_init_tso_segs(sk, skb); + } + + if (sent_pkts) { + tcp_cwnd_validate(sk, tp); + return 0; + } + + return !tp->packets_out && sk->sk_send_head; +} + +/* Push out any pending frames which were held back due to + * TCP_CORK or attempt at coalescing tiny packets. + * The socket must be locked by the caller. + */ +void __tcp_push_pending_frames(struct sock *sk, + struct tcp_sock *tp, + unsigned int cur_mss, + int nonagle) +{ + if (sk->sk_send_head) { + if (tcp_write_xmit(sk, nonagle)) + tcp_check_probe_timer(sk, tp); + } +} + +/* As ACKs arrive and the send and congestion windows potentially + * open up, we call this to try and make write queue transmit + * progress. + * + * The caller has the socket locked, and has verified that + * sk->sk_send_head is not NULL. + */ +void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb) +{ + struct tcp_sock *tp = tcp_sk(sk); + unsigned int tso_segs = tcp_init_tso_segs(sk, skb); + u32 in_flight; + + /* First, do some very cheap tests to short circuit + * all the expensive ones coming up. + */ + if (after(TCP_SKB_CB(skb)->seq + tp->mss_cache, + tp->snd_una + tp->snd_wnd)) + goto check_probe_timer; + + in_flight = tcp_packets_in_flight(tp); + if (in_flight >= tp->snd_cwnd) + goto check_probe_timer; + + if (tso_segs > 1) { + u32 send_win, cong_win, limit, chunk; + + /* Try to defer sending, if possible, in order + * to minimize the amount of TSO splitting we do. + * This algorithm is from John Heffner. + * + * First, we must have at least some packets + * in flight to legally defer. Otherwise, + * no ACKs can be expected. + */ + if (!in_flight) + goto send_it; + + send_win = (tp->snd_una + tp->snd_wnd) - TCP_SKB_CB(skb)->seq; + + /* From in_flight test above, we know that + * cwnd > in_flight. + */ + cong_win = (tp->snd_cwnd - in_flight) * tp->mss_cache; + + limit = min(send_win, cong_win); + + /* If sk_send_head can be sent fully now, just do it. */ + if (!after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + limit)) + goto send_it; + + /* If at least some fraction of a window is available, + * just use it. + */ + chunk = min(tp->snd_wnd, tp->snd_cwnd * tp->mss_cache); + chunk /= sysctl_tcp_tso_win_divisor; + if (limit >= chunk) + goto send_it; + + /* Ok, it looks like it is advisable to defer. */ + tp->deferred = tp->snd_cwnd - in_flight; + return; + } +send_it: + + if (tcp_write_xmit(sk, tp->nonagle)) + goto check_probe_timer; + return; + +check_probe_timer: + tcp_check_probe_timer(sk, tp); +} + +/* Send _single_ skb sitting at the send head. This function requires + * true push pending frames to setup probe timer etc. Caller makes + * sure that sk->sk_send_head is non-NULL. + */ +void tcp_push_one(struct sock *sk, unsigned int cur_mss) +{ + struct tcp_sock *tp = tcp_sk(sk); + struct sk_buff *skb = sk->sk_send_head; + unsigned int tso_segs, cwnd_quota; + + tso_segs = tcp_init_tso_segs(sk, skb); + cwnd_quota = tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH); + if (cwnd_quota) { + u32 window_seq; + + window_seq = tp->snd_una + tp->snd_wnd; + BUG_ON(!tso_segs); + + if (tso_segs > 1) { + u32 limit = tso_size_limit(window_seq - + TCP_SKB_CB(skb)->seq, + cur_mss, cwnd_quota); + + if (skb->len > limit) { + if (tso_fragment(sk, skb, limit)) + return; + } + } else if (skb->len > cur_mss) { + if (tcp_fragment(sk, skb, cur_mss)) + return; } - return !tp->packets_out && sk->sk_send_head; + /* Send it out now. */ + TCP_SKB_CB(skb)->when = tcp_time_stamp; + if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { + update_send_head(sk, tp, skb); + return; + } } - return 0; } /* This function returns the amount that we can raise the @@ -1041,12 +1387,6 @@ int tcp_retransmit_skb(struct sock *sk, if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una)) BUG(); - if (sk->sk_route_caps & NETIF_F_TSO) { - sk->sk_route_caps &= ~NETIF_F_TSO; - sock_set_flag(sk, SOCK_NO_LARGESEND); - tp->mss_cache = tp->mss_cache_std; - } - if (tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)) return -ENOMEM; } @@ -1106,7 +1446,6 @@ int tcp_retransmit_skb(struct sock *sk, * is still in somebody's hands, else make a clone. */ TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); err = tcp_transmit_skb(sk, (skb_cloned(skb) ? pskb_copy(skb, GFP_ATOMIC): @@ -1671,19 +2010,11 @@ int tcp_write_wakeup(struct sock *sk) TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; if (tcp_fragment(sk, skb, seg_size)) return -1; - /* SWS override triggered forced fragmentation. - * Disable TSO, the connection is too sick. */ - if (sk->sk_route_caps & NETIF_F_TSO) { - sock_set_flag(sk, SOCK_NO_LARGESEND); - sk->sk_route_caps &= ~NETIF_F_TSO; - tp->mss_cache = tp->mss_cache_std; - } } else if (!tcp_skb_pcount(skb)) tcp_set_skb_tso_segs(sk, skb); TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); err = tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC)); if (!err) { update_send_head(sk, tp, skb); --- 1/net/ipv6/tcp_ipv6.c.~1~ 2005-05-19 13:35:11.000000000 -0700 +++ 2/net/ipv6/tcp_ipv6.c 2005-05-19 13:35:16.000000000 -0700 @@ -2021,7 +2021,8 @@ static int tcp_v6_init_sock(struct sock */ tp->snd_ssthresh = 0x7fffffff; tp->snd_cwnd_clamp = ~0; - tp->mss_cache_std = tp->mss_cache = 536; + tp->mss_cache = 536; + tp->xmit_size_cache = ~0; tp->reordering = sysctl_tcp_reordering; From jdmason@us.ibm.com Fri May 20 11:55:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 11:55:42 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KItcF3008283 for ; Fri, 20 May 2005 11:55:38 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4KIsncE446734 for ; Fri, 20 May 2005 14:54:49 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KIsmwj230044 for ; Fri, 20 May 2005 12:54:48 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4KIsmC3025887 for ; Fri, 20 May 2005 12:54:48 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4KIsmxT025861; Fri, 20 May 2005 12:54:48 -0600 From: Jon Mason Organization: IBM To: "Catalin(ux aka Dino) BOIE" Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) Date: Fri, 20 May 2005 13:54:46 -0500 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com, davem@davemloft.net References: <20050519214015.GA19961@us.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201354.46824.jdmason@us.ibm.com> X-archive-position: 1444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3411 Lines: 96 On Friday 20 May 2005 01:07 am, Catalin(ux aka Dino) BOIE wrote: > >> +static inline void br_features_change(struct net_bridge *br, struct > >> net_device *dev) +{ > >> + br->dev->features &= dev->features | ~BR_FEAT_MASK; > > > > ~BR_FEAT_MASK isn't necessary. Either you wanted to do an '&' just > > before it, so that BR_FEAT_MASK features are the only ones that you want > > or you are enabling features that aren't necessarily supported by the > > adapter/driver (like LLTX and HW_VLAN stuff). > > So, I invert BR_FEAT_MASK so I can, by default clear special features. > Then I ored with dev->features, so I can enable special features if the > slave device supports it. Then, I do & so I can clear stuff that is not > supported by device, but the rest of br->dev features remains untouched. > > Let's test: if dev hash SG the code is like this: > BR_FEAT_MASK = 1001 (only test SG and HW_CSUM) > # br is inited > br |= 1001 > br &= 0001 | ~1001 > br &= 0001 | 0110 > br &= 0111 > br = 1001 & 0111 = 0001 - so bit SG is set also in br. But not HW_CSUM > because it's not in device. > > I can't see the code is wrong. Can you give me an example when it fails, > please? Let's use the full BR_FEAT_MASK of NETIF_F_HW_CSUM | NETIF_F_SG | | NETIF_F_FRAGLIST | NETIF_F_IP_CSUM | NETIF_F_HIGHDMA | NETIF_F_TSO). That is 0011 0000 0110 1011 Now, let's assume that the NIC only has NETIF_F_TSO, NETIF_F_IP_CSUM, and NETIF_F_SG enabled. So, that is 0000 1000 0000 0011 So, we have the following: For the first adapter added: br = 0001 1000 0110 1011 br = 0001 1000 0110 1011 & 0000 1000 0000 0011 | ~0001 1000 0110 1011 br = 0001 1000 0110 1011 & 0000 1000 0000 0011 | 1110 0111 1001 0100 br = 0000 1000 0000 0011 | 1110 0111 1001 0100 br = 1110 1111 1001 0111 Note - this breaks down to the following being enabled: NETIF_F_SG NETIF_F_IP_CSUM NETIF_F_NO_CSUM UNDEFINED BIT NETIF_F_HW_VLAN_RX NETIF_F_HW_VLAN_FILTER NETIF_F_VLAN_CHALLENGED NETIF_F_TSO NETIF_F_LLTX For a second adapter with the same features added: br = 1110 1111 1001 0111 br = 1110 1111 1001 0111 & 0000 1000 0000 0011 | 1110 0111 1001 0100 br = 1110 1111 1001 0111 | 1110 0111 1001 0100 br = 1110 1111 1001 0111 So, NETIF_F_HW_VLAN_RX, NETIF_F_HW_VLAN_FILTER, NETIF_F_VLAN_CHALLENGED, and NETIF_F_LLTX will be enabled, and they might not be enabled/supported. If you take out the ~BR_FEAT_MASK then it will behave as I would expect (verified with printks on the last patch). On a side note: Wouldn't it make more sense to have NETIF_F_TSO defined as 16 in include/linux/netdevice.h (as it would be grouped with the other hardware offload bits and the bit is free). > >> +} > >> + > >> +/* > >> + * Recomputes features using slave's features > >> + */ > >> +static void br_features_recompute(struct net_bridge *br) > >> +{ > >> + struct net_bridge_port *p; > >> + > >> + br->dev->features |= BR_FEAT_MASK; > > > > The OR is not needed. Just re-initialize features to BR_FEAT_MASK and > > everything will take case of itself. > > Nope. Not correct. Because we might enable LLTX on the bridge, but not in > BR_FEAT_MASK. This is not the case. This is the same as re-doing the entire feature list (as if it was being done initially). All that needs to be done is for br->dev->features to have a initial value. > I will post a patch in few hours with all stuff updated. Great. Thanks. Thanks, Jon From jgarzik@pobox.com Fri May 20 11:59:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 11:59:58 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KIxrF3009175 for ; Fri, 20 May 2005 11:59:53 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DZCi6-00005G-2G; Fri, 20 May 2005 18:59:03 +0000 Message-ID: <428E3372.403@pobox.com> Date: Fri, 20 May 2005 14:58:58 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Grant Grundler , akpm@osdl.org CC: T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> <20050516222612.GD9282@colo.lackof.org> In-Reply-To: <20050516222612.GD9282@colo.lackof.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1283 Lines: 30 Grant Grundler wrote: > After three years of using/maintaining the (trivial) tulip patch > in parisc-linux tree (and shipped with RH/SuSe ia64 releases), > I don't recall anyone complaining that udelays in tulip phy reset > caused them problems. Sorry, I'm unmotivated to revisit this. > Convince someone else to make tulip to use workqueues and I'll > resubmit a clean patch on top of that for the phy init sequences. Long delays are unacceptable in new drivers, and we are working to remove them from older drivers. Lack of complaints is irrelevant -- its a design requirement of all drivers. Ingo and the real-time crowd are fighting against every delay, because every delay causes a spin, a blip in latency, an increase in CPU usage, and a complete stoppage of ALL work on a uniprocessor machine. Your patch is not a special case. We have been communicating this message on udelay/mdelay for -years-. All your patch [as-is] does is cause more work for someone else. This also presents a problem that Andrew points out on occasion: what happens when a patch is useful, but the patch author isn't (for whatever reason) doing the legwork necessary to get it into the mainline kernel? We certainly DON'T want to lose this patch, as the changes are useful. Jeff From romieu@fr.zoreil.com Fri May 20 12:16:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 12:16:24 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KJGJF3012239 for ; Fri, 20 May 2005 12:16:20 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4KJFGJs022161; Fri, 20 May 2005 21:15:16 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4KJFB9k022160; Fri, 20 May 2005 21:15:11 +0200 Date: Fri, 20 May 2005 21:15:11 +0200 From: Francois Romieu To: Jeff Garzik Cc: Grant Grundler , akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree Message-ID: <20050520191511.GA19354@electric-eye.fr.zoreil.com> References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> <20050516222612.GD9282@colo.lackof.org> <428E3372.403@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428E3372.403@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 202 Lines: 9 Jeff Garzik : [snip] I should start chewing it later today: it just reached the top of the pile (right before the "see if Chelsio publish something within 5 days" item). -- Ueimor From garzik@havoc.gtf.org Fri May 20 12:43:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 12:43:24 -0700 (PDT) Received: from bastet.signetmail.com (atlmail.prod.rxgsys.com [69.61.70.25]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KJhKF3018264 for ; Fri, 20 May 2005 12:43:20 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 3A2BEA8870; Fri, 20 May 2005 14:22:50 -0400 (EDT) Received: from bastet.signetmail.com ([127.0.0.1]) by localhost (atlmail.prod.rxgsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13166-02; Fri, 20 May 2005 14:22:44 -0400 (EDT) Received: from havoc.gtf.org (havoc.gtf.org [63.115.148.101]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id BBA4EA871F; Fri, 20 May 2005 14:22:39 -0400 (EDT) Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 5B8DA1C1E951; Fri, 20 May 2005 15:42:21 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id j4KJgKGI018329; Fri, 20 May 2005 15:42:20 -0400 Date: Fri, 20 May 2005 15:42:20 -0400 From: Jeff Garzik To: Michael Chan Cc: davem@davemloft.net, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 Message-ID: <20050520194220.GA18259@havoc.gtf.org> References: <1116609329.31523.16.camel@rh4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116609329.31523.16.camel@rh4> User-Agent: Mutt/1.4.1i X-archive-position: 1447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 8592 Lines: 297 On Fri, May 20, 2005 at 10:15:29AM -0700, Michael Chan wrote: > A new driver bnx2 for Broadcom bcm5706 is available. Since the patch is > over 500K, I've put it on the ftp server: > > ftp://Net_sys_anon@ftp1.broadcom.com/bnx2-2.patch > > The patch also includes new 1000BASE-X advertisement bit definitions in > mii.h Here's my in-depth review: 0) Please use 'jgarzik@pobox.com' for open source stuff, and 'jgarzik@redhat.com' only for private Red Hat (NDA'd) stuff. I know all these email addresses can be confusing; I apologize. 1) [style] don't use braces, when a single statement follows an 'if', 'for', etc. + bp->duplex = DUPLEX_FULL; + } + else { + bp->duplex = DUPLEX_HALF; + } + + if (!(bmcr & BMCR_ANENABLE)) { + return 0; + } [several areas of code need this] 2) bnx2_read_phy() returns a value, but the code quite often ignores its return value. 3) ditto for bnx2_write_phy() 4) ditto for bnx2_reset_phy() 5) ditto for bnx2_init_phy() 6) too many magic numbers in phy init. Please define constants for the BCM-specific phy registers, and register bits, where reasonable. + if (bp->dev->mtu > 1500) { + u32 val; + + /* Set extended packet length bit */ + bnx2_write_phy(bp, 0x18, 0x7); + bnx2_read_phy(bp, 0x18, &val); + bnx2_write_phy(bp, 0x18, (val & 0xfff8) | 0x4000); + + bnx2_write_phy(bp, 0x1c, 0x6c00); + bnx2_read_phy(bp, 0x1c, &val); + bnx2_write_phy(bp, 0x1c, (val & 0x3ff) | 0xec02); + } + else { + u32 val; + + bnx2_write_phy(bp, 0x18, 0x7); + bnx2_read_phy(bp, 0x18, &val); + bnx2_write_phy(bp, 0x18, val & ~0x4007); + + bnx2_write_phy(bp, 0x1c, 0x6c00); + bnx2_read_phy(bp, 0x1c, &val); + bnx2_write_phy(bp, 0x1c, (val & 0x3fd) | 0xec00); + } 7) the delays in bnx2_fw_sync(), bnx2_reset_chip() and bnx2_init_chip() might work better as sleeps, rather than udelay, since you are always in process context, and its not a performance critical path. As a general rule for all driver programming, msleep() is preferred over udelay() / mdelay(). udelay() spins, while msleep() allows other [possibly high priority real-time] processes to continue. Note that tg3 needs fixing for this too, but nobody has been motivated enough to care. 8) excessive stack size in bnx2_alloc_bad_rbuf(): + u16 good_mbuf[512]; a 1024-byte object is simply unacceptable, given that that is fully 1/4 of a 4K stack, for users that use the 4K stack option. Typical solution is kmalloc'ing a temporary buffer. 9) [additional review] DaveM, others: is this correct for all arches? + if (unlikely((align = (unsigned long) skb->data & 0x7))) { + skb_reserve(skb, 8 - align); + } 10) [additional review] doesn't bnx2_rx_int() need to move the rmb() inside the loop? Are you protecting against the compiler reordering/caching loads/stores, or against SMP CPUs? 10.1) [additional review] is the rmb() even needed in bnx2_rx_int(), since its caller also uses rmb()? 11) Don't use IRQ_RETVAL(1), use IRQ_NONE / IRQ_HANDLED for the constant cases. 12) use a named constant rather than magic number (aka numeric constant): + if ((len > (bp->dev->mtu + ETH_HLEN)) && + (htons(skb->protocol) != 0x8100)) { 13) [additional review] why is CHECKSUM_UNNECESSARY used when cksum==0xffff or cksum==0 ? + u16 cksum = rx_hdr->l2_fhdr_tcp_udp_xsum; + + if ((cksum == 0xffff) || (cksum == 0)) { + skb->ip_summed = CHECKSUM_UNNECESSARY; + } 14) is D0 guaranteed after 50 usec? + /* No more memory access after this point until + * device is brought back to D0. + */ + udelay(50); + break; 15) the following loop is just silly. use mdelay or (preferably) msleep. + if ((CHIP_ID(bp) == CHIP_ID_5706_A0) || + (CHIP_ID(bp) == CHIP_ID_5706_A1)) { + + for (i = 0; i < 500; i++) { + udelay(30); + } + } 16) [long term; grunt work] it would be nice if somebody would submit patches to ethtool, for verbose register dump of bnx2 and tg3 17) you may prefer msleep_interruptible() ? + for (i = 0; i < 10; i++) { + if ((REG_RD(bp, BNX2_PCICFG_INT_ACK_CMD) & 0xffff) != + status_idx) { + + break; + } + + current->state = TASK_INTERRUPTIBLE; + schedule_timeout(1); + } 18) you can eliminate one call to request_irq, by lengthening the 'if' test: + if ((CHIP_ID(bp) != CHIP_ID_5706_A0) && + (CHIP_ID(bp) != CHIP_ID_5706_A1) && + !disable_msi) { + + if (pci_enable_msi(bp->pdev) == 0) { + bp->flags |= USING_MSI_FLAG; + rc = request_irq(bp->pdev->irq, bnx2_msi, 0, dev->name, + dev); + } + else { + rc = request_irq(bp->pdev->irq, bnx2_interrupt, + SA_SHIRQ, dev->name, dev); + } + } + else { + rc = request_irq(bp->pdev->irq, bnx2_interrupt, SA_SHIRQ, + dev->name, dev); + } 19) [additional review] need flush_scheduled_work(), if using work queues? 20) is there any reason to #ifdef BCM_TSO? 2.4.x kernels I suppose? 21) need to call bnx2_netif_stop() in bnx2_close() 22) [namespace] s/ETH_NUM_STATS/BNX2_NUM_STATS/ 23) use msleep_interruptible() in bnx2_phys_id() + current->state = TASK_INTERRUPTIBLE; + schedule_timeout(HZ / 2); + if (signal_pending(current)) + break; 24) consider using pci_enable_msi() in bnx2_init_board(), rather than the request_irq() callsite. 25) don't assign dev->mem_{start,end}, it's pointless. Some drivers use it to pass _information_ these days, even. 26) Note that some PCI buses have speeds other than what is listed in bnx2_init_board(). Some weirdo platforms even vary the PCI bus speed (which is legal). 27) isn't 'timer_interval == HZ' too rapid a timer? Does it really need to fire every second? 28) use SET_ETHTOOL_OPS(), if you are backporting to 2.4.x as item #20 indicates. 29) do not use NETIF_F_SG independent of NETIF_F_xx_CSUM. + dev->features |= NETIF_F_SG; + if (bp->flags & USING_DAC_FLAG) + dev->features |= NETIF_F_HIGHDMA; + dev->features |= NETIF_F_IP_CSUM; 30) as David mentioned in a previous email, mark everything 'static': +int COM_b06FwReleaseMajor = 0x0; +int COM_b06FwReleaseMinor = 0x0; +int COM_b06FwReleaseFix = 0x0; +u32 COM_b06FwStartAddr = 0x080004a0; +u32 COM_b06FwTextAddr = 0x08000000; +int COM_b06FwTextLen = 0x4594; +u32 COM_b06FwDataAddr = 0x080045e0; +int COM_b06FwDataLen = 0x0; +u32 COM_b06FwRodataAddr = 0x08004598; +int COM_b06FwRodataLen = 0x18; +u32 COM_b06FwBssAddr = 0x08004600; +int COM_b06FwBssLen = 0x88; +u32 COM_b06FwSbssAddr = 0x080045e0; +int COM_b06FwSbssLen = 0x1c; +u32 COM_b06FwText[(0x4594/4) + 1] = { 31) use arrays, as requested in a previous email: + u16 status_tx_quick_consumer_index0; + u16 status_tx_quick_consumer_index1; + u16 status_tx_quick_consumer_index2; + u16 status_tx_quick_consumer_index3; + u16 status_rx_quick_consumer_index0; + u16 status_rx_quick_consumer_index1; + u16 status_rx_quick_consumer_index2; + u16 status_rx_quick_consumer_index3; + u16 status_rx_quick_consumer_index4; + u16 status_rx_quick_consumer_index5; + u16 status_rx_quick_consumer_index6; + u16 status_rx_quick_consumer_index7; + u16 status_rx_quick_consumer_index8; + u16 status_rx_quick_consumer_index9; + u16 status_rx_quick_consumer_index10; + u16 status_rx_quick_consumer_index11; + u16 status_rx_quick_consumer_index12; + u16 status_rx_quick_consumer_index13; + u16 status_rx_quick_consumer_index14; + u16 status_rx_quick_consumer_index15; 32) [speling] s/fileds/fields/ /* End of fileds used in the performance code paths. */ 33) [ack] I ACK the changes to linux/mii.h [I am the maintainer] From juliokriger@gmail.com Fri May 20 13:29:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 13:29:27 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KKTMF3021822 for ; Fri, 20 May 2005 13:29:22 -0700 Received: by zproxy.gmail.com with SMTP id 8so1033896nzo for ; Fri, 20 May 2005 13:28:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ksUyEIl3cHbrU7c7wsgnVxAN8vNqXVZT+U3stHUD19y6FFf5c4piz9BaetM21S/ZXQZ7BY4kjA/ctf2D5P+yzJ/8DRNwKPJCPGIfE7oJCLPY7n9Cj/ZvJspbI4K97Tt6iGW/7Qd3Bm3JugPuNhvr71w0BYEhGckVkPAyWLilUMU= Received: by 10.36.68.2 with SMTP id q2mr1017441nza; Fri, 20 May 2005 13:28:40 -0700 (PDT) Received: by 10.36.9.9 with HTTP; Fri, 20 May 2005 13:28:40 -0700 (PDT) Message-ID: <682bc30a050520132819b66fee@mail.gmail.com> Date: Fri, 20 May 2005 20:28:40 +0000 From: Julio Kriger Reply-To: Julio Kriger To: Stephen Hemminger Subject: Re: [Netem] [PATCH] (3/3) netem: allow random reordering Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org In-Reply-To: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4KKTMF3021822 X-archive-position: 1448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juliokriger@gmail.com Precedence: bulk X-list: netdev Content-Length: 6134 Lines: 180 Hi! How do I use this feature? Shouldn't tc be modified to accept this new feature? Regards, Julio On 5/19/05, Stephen Hemminger wrote: > Enhance the reorder feature of netem to allow random percent to be reordered. > Has expected backwards compatibility behaviour. > > Signed-off-by: Stephen Hemminger > > Index: netem-2.6.12-rc4/include/linux/pkt_sched.h > =================================================================== > --- netem-2.6.12-rc4.orig/include/linux/pkt_sched.h > +++ netem-2.6.12-rc4/include/linux/pkt_sched.h > @@ -427,6 +427,7 @@ enum > TCA_NETEM_UNSPEC, > TCA_NETEM_CORR, > TCA_NETEM_DELAY_DIST, > + TCA_NETEM_REORDER, > __TCA_NETEM_MAX, > }; > > @@ -437,7 +438,7 @@ struct tc_netem_qopt > __u32 latency; /* added delay (us) */ > __u32 limit; /* fifo limit (packets) */ > __u32 loss; /* random packet loss (0=none ~0=100%) */ > - __u32 gap; /* re-ordering gap (0 for delay all) */ > + __u32 gap; /* re-ordering gap (0 for none) */ > __u32 duplicate; /* random packet dup (0=none ~0=100%) */ > __u32 jitter; /* random jitter in latency (us) */ > }; > @@ -449,6 +450,12 @@ struct tc_netem_corr > __u32 dup_corr; /* duplicate correlation */ > }; > > +struct tc_netem_reorder > +{ > + __u32 probability; > + __u32 correlation; > +}; > + > #define NETEM_DIST_SCALE 8192 > > #endif > Index: netem-2.6.12-rc4/net/sched/sch_netem.c > =================================================================== > --- netem-2.6.12-rc4.orig/net/sched/sch_netem.c > +++ netem-2.6.12-rc4/net/sched/sch_netem.c > @@ -62,11 +62,12 @@ struct netem_sched_data { > u32 gap; > u32 jitter; > u32 duplicate; > + u32 reorder; > > struct crndstate { > unsigned long last; > unsigned long rho; > - } delay_cor, loss_cor, dup_cor; > + } delay_cor, loss_cor, dup_cor, reorder_cor; > > struct disttable { > u32 size; > @@ -185,18 +186,18 @@ static int netem_enqueue(struct sk_buff > * of the queue. > * gap == 0 is special case for no-reordering. > */ > - if (q->gap == 0 || q->counter != q->gap) { > + if (q->gap == 0 && q->counter < q->gap && > + q->reorder < get_crandom(&q->reorder_cor)) { > psched_time_t now; > PSCHED_GET_TIME(now); > - PSCHED_TADD2(now, > - tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist), > + PSCHED_TADD2(now, tabledist(q->latency, q->jitter, > + &q->delay_cor, q->delay_dist), > cb->time_to_send); > - > ++q->counter; > ret = q->qdisc->enqueue(skb, q->qdisc); > } else { > - q->counter = 0; > PSCHED_GET_TIME(cb->time_to_send); > + q->counter = 0; > ret = q->qdisc->ops->requeue(skb, q->qdisc); > } > > @@ -351,6 +352,19 @@ static int get_correlation(struct Qdisc > return 0; > } > > +static int get_reorder(struct Qdisc *sch, const struct rtattr *attr) > +{ > + struct netem_sched_data *q = qdisc_priv(sch); > + const struct tc_netem_reorder *r = RTA_DATA(attr); > + > + if (RTA_PAYLOAD(attr) != sizeof(*r)) > + return -EINVAL; > + > + q->reorder = r->probability; > + init_crandom(&q->reorder_cor, r->correlation); > + return 0; > +} > + > static int netem_change(struct Qdisc *sch, struct rtattr *opt) > { > struct netem_sched_data *q = qdisc_priv(sch); > @@ -371,9 +385,15 @@ static int netem_change(struct Qdisc *sc > q->jitter = qopt->jitter; > q->limit = qopt->limit; > q->gap = qopt->gap; > + q->counter = 0; > q->loss = qopt->loss; > q->duplicate = qopt->duplicate; > > + /* for compatiablity with earlier versions. > + * if gap is set, need to assume 100% probablity > + */ > + q->reorder = ~0; > + > /* Handle nested options after initial queue options. > * Should have put all options in nested format but too late now. > */ > @@ -395,6 +415,11 @@ static int netem_change(struct Qdisc *sc > if (ret) > return ret; > } > + if (tb[TCA_NETEM_REORDER-1]) { > + ret = get_reorder(sch, tb[TCA_NETEM_REORDER-1]); > + if (ret) > + return ret; > + } > } > > > @@ -412,7 +437,6 @@ static int netem_init(struct Qdisc *sch, > init_timer(&q->timer); > q->timer.function = netem_watchdog; > q->timer.data = (unsigned long) sch; > - q->counter = 0; > > q->qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); > if (!q->qdisc) { > @@ -444,6 +468,7 @@ static int netem_dump(struct Qdisc *sch, > struct rtattr *rta = (struct rtattr *) b; > struct tc_netem_qopt qopt; > struct tc_netem_corr cor; > + struct tc_netem_reorder reorder; > > qopt.latency = q->latency; > qopt.jitter = q->jitter; > @@ -457,6 +482,11 @@ static int netem_dump(struct Qdisc *sch, > cor.loss_corr = q->loss_cor.rho; > cor.dup_corr = q->dup_cor.rho; > RTA_PUT(skb, TCA_NETEM_CORR, sizeof(cor), &cor); > + > + reorder.probability = q->reorder; > + reorder.correlation = q->reorder_cor.rho; > + RTA_PUT(skb, TCA_NETEM_REORDER, sizeof(reorder), &reorder); > + > rta->rta_len = skb->tail - b; > > return skb->len; > > > _______________________________________________ > Netem mailing list > Netem@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/netem > > > -- ---------------------------- Julio Kriger mailto:juliokriger@gmail.com From jgarzik@pobox.com Fri May 20 13:52:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 13:52:32 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KKqTF3023962 for ; Fri, 20 May 2005 13:52:29 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DZETE-0000GX-K9; Fri, 20 May 2005 20:51:48 +0000 Message-ID: <428E4DE2.1020002@pobox.com> Date: Fri, 20 May 2005 16:51:46 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan , davem@davemloft.net CC: netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 References: <1116609329.31523.16.camel@rh4> <20050520194220.GA18259@havoc.gtf.org> In-Reply-To: <20050520194220.GA18259@havoc.gtf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 691 Lines: 22 Note that I only consider a very few of these items, highlighted below, to be merge-stoppers. The rest are minor things that can be fixed up at leisure. > 8) excessive stack size in bnx2_alloc_bad_rbuf(): > 9) [additional review] DaveM, others: is this correct for all arches? > 13) [additional review] why is CHECKSUM_UNNECESSARY used when > cksum==0xffff or cksum==0 ? > 15) the following loop is just silly. use mdelay or (preferably) > msleep. > 19) [additional review] need flush_scheduled_work(), if using work queues? > 21) need to call bnx2_netif_stop() in bnx2_close() > 27) isn't 'timer_interval == HZ' too rapid a timer? Does it really need > to fire every second? From greearb@candelatech.com Fri May 20 14:07:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 14:08:03 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KL7xF3025803 for ; Fri, 20 May 2005 14:07:59 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j4KLd7Gf004425; Fri, 20 May 2005 14:39:07 -0700 Message-ID: <428E5185.1070602@candelatech.com> Date: Fri, 20 May 2005 14:07:17 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Michael Chan , davem@davemloft.net, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 References: <1116609329.31523.16.camel@rh4> <20050520194220.GA18259@havoc.gtf.org> <428E4DE2.1020002@pobox.com> In-Reply-To: <428E4DE2.1020002@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 453 Lines: 16 Jeff Garzik wrote: > > Note that I only consider a very few of these items, highlighted below, > to be merge-stoppers. The rest are minor things that can be fixed up at > leisure. Out of curiousity: Is the intended goal to replace tg3 with this new driver eventually? I dig having the chipset manufacturer solidly behind the driver, like e1000! Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From grundler@lackof.org Fri May 20 14:09:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 14:10:01 -0700 (PDT) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KL9vF3026435 for ; Fri, 20 May 2005 14:09:58 -0700 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id DBF0C29806B; Fri, 20 May 2005 15:12:29 -0600 (MDT) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15680-10; Fri, 20 May 2005 15:12:29 -0600 (MDT) Received: by colo.lackof.org (Postfix, from userid 27253) id 8094029802F; Fri, 20 May 2005 15:12:29 -0600 (MDT) Date: Fri, 20 May 2005 15:12:29 -0600 From: Grant Grundler To: Jeff Garzik Cc: Grant Grundler , akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree Message-ID: <20050520211229.GA2411@colo.lackof.org> References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> <20050516222612.GD9282@colo.lackof.org> <428E3372.403@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428E3372.403@pobox.com> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.9i X-archive-position: 1451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev Content-Length: 3199 Lines: 77 On Fri, May 20, 2005 at 02:58:58PM -0400, Jeff Garzik wrote: > Grant Grundler wrote: > >After three years of using/maintaining the (trivial) tulip patch > >in parisc-linux tree (and shipped with RH/SuSe ia64 releases), > >I don't recall anyone complaining that udelays in tulip phy reset > >caused them problems. Sorry, I'm unmotivated to revisit this. > >Convince someone else to make tulip to use workqueues and I'll > >resubmit a clean patch on top of that for the phy init sequences. > > > Long delays are unacceptable in new drivers, Agreed. But that didn't stop tg3 from having a 1.5 *SECOND* spin delay during fiber phy init with interrupts off. That is certainly a much newer driver than tulip. (It's not obvious to me by code inspection which context tg3_setup_fiber_by_hand() gets called from now.) > and we are working to remove them from older drivers. > > Lack of complaints is irrelevant -- its > a design requirement of all drivers. It's totally relevant. Complaints (bug reports) and patches drive change. That's how both commercial *and* non-commercial developers prioritize. "Ingo and the real-time crowd" are a good example of a change in priorities driven by non-commercial users. > Ingo and the real-time crowd are fighting against every delay, because > every delay causes a spin, a blip in latency, an increase in CPU usage, > and a complete stoppage of ALL work on a uniprocessor machine. Understood. But they were not the first ones. Donald Becker has a fairly well known digust for use of CPU spin loops. But we can't eliminate *all* udelay just becuase of the way HW is designed and has bugs. I think it would be reasonable to get rid of many udelay calls (replace them with PCI read delay loops like Donald has advocated) and get the rest into a context where it matters less. I have no objection to people fixing those sorts of issues. > Your patch is not a special case. We have been communicating this > message on udelay/mdelay for -years-. All your patch [as-is] does is > cause more work for someone else. Not true. This patch brings the tulip driver into compliance with published specs and makes the driver functional for parisc/mips/ia64 users. > This also presents a problem that Andrew points out on occasion: > what happens when a patch is useful, but the patch author isn't (for > whatever reason) doing the legwork necessary to get it into the mainline > kernel? The "whatever reason" is clearly decided by the mainline kernel maintainer. If we treat other people's labor as "free", then the right answer is to drop the patch and wait for some subset of "we" to do the extra legwork. Several people care if tulip phy init works right. OTOH, I'm only aware of one person who specifically cares if tulip is holding the CPU hostage for 1 or 2 ms during the occasional phy init. Is being a technology purist more important than moving forward with what people care about? > We certainly DON'T want to lose this patch, as the changes are > useful. I think we also agree debugging the problem and providing a patch that works is a worthy contribution. We won't lose it. I maintain it in CVS on cvs.parisc-linux.org. thanks, grant From garzik@havoc.gtf.org Fri May 20 14:10:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 14:10:43 -0700 (PDT) Received: from bastet.signetmail.com (atlmail.prod.rxgsys.com [69.61.70.25]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KLAdF3026623 for ; Fri, 20 May 2005 14:10:41 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id F4227A8876; Fri, 20 May 2005 15:50:10 -0400 (EDT) Received: from bastet.signetmail.com ([127.0.0.1]) by localhost (atlmail.prod.rxgsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14176-02; Fri, 20 May 2005 15:50:09 -0400 (EDT) Received: from havoc.gtf.org (havoc.gtf.org [63.115.148.101]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id C98ACA8870; Fri, 20 May 2005 15:49:56 -0400 (EDT) Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 0F3161C1E954; Fri, 20 May 2005 17:09:39 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id j4KL9cw8023743; Fri, 20 May 2005 17:09:38 -0400 Date: Fri, 20 May 2005 17:09:38 -0400 From: Jeff Garzik To: Ben Greear Cc: Michael Chan , davem@davemloft.net, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 Message-ID: <20050520210938.GA23714@havoc.gtf.org> References: <1116609329.31523.16.camel@rh4> <20050520194220.GA18259@havoc.gtf.org> <428E4DE2.1020002@pobox.com> <428E5185.1070602@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428E5185.1070602@candelatech.com> User-Agent: Mutt/1.4.1i X-archive-position: 1452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 546 Lines: 23 On Fri, May 20, 2005 at 02:07:17PM -0700, Ben Greear wrote: > Jeff Garzik wrote: > > > >Note that I only consider a very few of these items, highlighted below, > >to be merge-stoppers. The rest are minor things that can be fixed up at > >leisure. > > Out of curiousity: Is the intended goal to replace tg3 with > this new driver eventually? No, different hardware. > I dig having the chipset manufacturer > solidly behind the driver, like e1000! Clearly you have been asleep :) Broadcom has been contributing actively to tg3. Jeff From mchan@broadcom.com Fri May 20 14:16:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 14:16:23 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KLGJF3027878 for ; Fri, 20 May 2005 14:16:20 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 20 May 2005 14:15:31 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 20 May 2005 14:15:29 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZO50770; Fri, 20 May 2005 14:15:27 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA03550; Fri, 20 May 2005 14:15:26 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2005 21:15:31 +0000 Received: from rh4 by nt-irva-0741; 20 May 2005 13:17:36 -0700 Subject: Re: A new driver for Broadcom bcm5706 From: "Michael Chan" To: "Jeff Garzik" cc: "Ben Greear" , davem@davemloft.net, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com In-Reply-To: <20050520210938.GA23714@havoc.gtf.org> References: <1116609329.31523.16.camel@rh4> <20050520194220.GA18259@havoc.gtf.org> <428E4DE2.1020002@pobox.com> <428E5185.1070602@candelatech.com> <20050520210938.GA23714@havoc.gtf.org> Date: Fri, 20 May 2005 13:17:36 -0700 Message-ID: <1116620256.31523.23.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E908CF92U4552211-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 335 Lines: 11 On Fri, 2005-05-20 at 17:09 -0400, Jeff Garzik wrote: > On Fri, May 20, 2005 at 02:07:17PM -0700, Ben Greear wrote: > > I dig having the chipset manufacturer > > solidly behind the driver, like e1000! > > Clearly you have been asleep :) Broadcom has been contributing actively > to tg3. > Yes, we are solidly behind tg3 and bnx2. From jgarzik@pobox.com Fri May 20 14:19:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 14:19:18 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KLJEF3028465 for ; Fri, 20 May 2005 14:19:14 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DZEt5-0000Hq-ND; Fri, 20 May 2005 21:18:34 +0000 Message-ID: <428E5425.3090605@pobox.com> Date: Fri, 20 May 2005 17:18:29 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: davem@davemloft.net, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 References: <1116609329.31523.16.camel@rh4> In-Reply-To: <1116609329.31523.16.camel@rh4> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 644 Lines: 23 Michael Chan wrote: > A new driver bnx2 for Broadcom bcm5706 is available. Since the patch is > over 500K, I've put it on the ftp server: > > ftp://Net_sys_anon@ftp1.broadcom.com/bnx2-2.patch > > The patch also includes new 1000BASE-X advertisement bit definitions in > mii.h > > Thanks to David Miller and Jeff Garzik for reviewing and their valuable > feedback. For what it's worth, DaveM and I decided that the patch submission procedure will be the same for bnx2 and tg3: DaveM will merge the bnx2 driver and patches, and send them upstream. (this deviates from the normal procedure of me merging all net driver changes) Jeff From jgarzik@pobox.com Fri May 20 14:35:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 14:35:14 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KLZBF3030125 for ; Fri, 20 May 2005 14:35:11 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DZF8X-0000Ic-P6; Fri, 20 May 2005 21:34:30 +0000 Message-ID: <428E57E2.2090204@pobox.com> Date: Fri, 20 May 2005 17:34:26 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Grant Grundler CC: akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> <20050516222612.GD9282@colo.lackof.org> <428E3372.403@pobox.com> <20050520211229.GA2411@colo.lackof.org> In-Reply-To: <20050520211229.GA2411@colo.lackof.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 4276 Lines: 115 Grant Grundler wrote: > On Fri, May 20, 2005 at 02:58:58PM -0400, Jeff Garzik wrote: > >>Grant Grundler wrote: >> >>>After three years of using/maintaining the (trivial) tulip patch >>>in parisc-linux tree (and shipped with RH/SuSe ia64 releases), >>>I don't recall anyone complaining that udelays in tulip phy reset >>>caused them problems. Sorry, I'm unmotivated to revisit this. >>>Convince someone else to make tulip to use workqueues and I'll >>>resubmit a clean patch on top of that for the phy init sequences. >> >> >>Long delays are unacceptable in new drivers, > > > Agreed. But that didn't stop tg3 from having a 1.5 *SECOND* > spin delay during fiber phy init with interrupts off. > That is certainly a much newer driver than tulip. > > (It's not obvious to me by code inspection which context > tg3_setup_fiber_by_hand() gets called from now.) Yes, tg3 is awful in this regard. I have made a bit of progress by moving some of the stuff into a workqueue. I got multiple reports from embedded tg3 platform developers, who had to really muck up the driver to fix the delay issue. It was apparently _really_ noticeable on one embedded platform. >>and we are working to remove them from older drivers. >> >>Lack of complaints is irrelevant -- its >>a design requirement of all drivers. > > > It's totally relevant. > Complaints (bug reports) and patches drive change. That's how both > commercial *and* non-commercial developers prioritize. > > "Ingo and the real-time crowd" are a good example of a change > in priorities driven by non-commercial users. No, these are commercial users. Embedded space really cares about this stuff. >>Ingo and the real-time crowd are fighting against every delay, because >>every delay causes a spin, a blip in latency, an increase in CPU usage, >>and a complete stoppage of ALL work on a uniprocessor machine. > > > Understood. But they were not the first ones. Donald Becker has a fairly > well known digust for use of CPU spin loops. But we can't eliminate > *all* udelay just becuase of the way HW is designed and has bugs. > I think it would be reasonable to get rid of many udelay calls > (replace them with PCI read delay loops like Donald has advocated) > and get the rest into a context where it matters less. > I have no objection to people fixing those sorts of issues. If you recognize the issue, you should object to new changes adding new issues! >>Your patch is not a special case. We have been communicating this >>message on udelay/mdelay for -years-. All your patch [as-is] does is >>cause more work for someone else. > > > Not true. This patch brings the tulip driver into compliance with > published specs and makes the driver functional for parisc/mips/ia64 users. Ok, yes, it fixes the tulip issue AND causes work for others. >>This also presents a problem that Andrew points out on occasion: >>what happens when a patch is useful, but the patch author isn't (for >>whatever reason) doing the legwork necessary to get it into the mainline >>kernel? > > > The "whatever reason" is clearly decided by the mainline kernel maintainer. > If we treat other people's labor as "free", then the right answer is > to drop the patch and wait for some subset of "we" to do the extra legwork. Um, this is how all kernel development works :) Maintainers are not supposed to merge patches into upstream, if they have flaws still remaining to be corrected. > Several people care if tulip phy init works right. OTOH, I'm only aware of > one person who specifically cares if tulip is holding the CPU hostage for > 1 or 2 ms during the occasional phy init. > > Is being a technology purist more important than moving forward with > what people care about? There will _always_ be ugly patches that get hardware going for some users. Tons of changes are kept outside the kernel until they are ready. This is just one more example. Merging code into the kernel is a big deal. That code will have to be maintained for years, maybe decades. "when in doubt, don't merge" is generally the right answer. I don't want your patch to become an issue that embedded developers must address (like the tg3 example above), causing further patching and headache in that area. Jeff From akepner@sgi.com Fri May 20 14:55:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 14:55:30 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KLtQF3000328 for ; Fri, 20 May 2005 14:55:26 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4KNdjx5001557 for ; Fri, 20 May 2005 16:39:45 -0700 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4KLsj3d28067060; Fri, 20 May 2005 14:54:45 -0700 (PDT) Date: Fri, 20 May 2005 14:52:35 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: "David S.Miller" cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: Perf data with recent tg3 patches In-Reply-To: <20050513.222007.78719997.davem@davemloft.net> Message-ID: References: <20050513.175013.00786860.davem@davemloft.net> <1116031159.6214.8.camel@rh4> <20050513.222007.78719997.davem@davemloft.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-567735041-1116625955=:11419" X-archive-position: 1456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 14042 Lines: 296 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323584-567735041-1116625955=:11419 Content-Type: TEXT/PLAIN; charset=US-ASCII Here are a couple more data points with the recent interrupt coalescing patches for the tg3 driver. Please see the attached graphs, which show how CPU utilization, and number of received packets per interrupt vary with link utilization. The workload here is receive-as-fast-as-you-can-over-TCP, with a single sending and a single receiving process. The data in the graphs is labelled as follows: ---------------------------------------------- 2.6.12-rc3: unmodified 2.6.12-rc3 dflt coal : 2.6.12-rc3 + [1] + [2] + [3] + [4] using the default intr coalescence values (rx-frames = rx-usecs-irq = 5) 4x coal : 2.6.12-rc3 + [1] + [2] + [3] + [4] + [5] using 4 times the default values for rx-frames and rx-frames-irq [1] http://marc.theaimsgroup.com/?l=linux-netdev&m=111446723510962&w=2 (This is one of a series of 3 patches - the others can't be found in the archive. But they're all in 2.6.12-rc4.) [2] http://marc.theaimsgroup.com/?l=linux-netdev&m=111567944730302&w=2 ("tagged status" patch) [3] http://marc.theaimsgroup.com/?l=linux-netdev&m=111586526522981&w=2 ("hw coalescing infrastructure" patch) [4] http://marc.theaimsgroup.com/?l=linux-netdev&m=111604846510646&w=2 ("tagged status update") [5] the patches below which allow "ethtool -[cC]" to work Patch [4] almost entirely eliminates updates to the tag in the status block between when it's been saved in tg3_poll() and when it's written back to the NIC in tg3_restart_ints(). It still happens, but the frequency is a few times in a thousand, so it doesn't significantly affect the interrupt rate. I had to make a couple of changes to allow setting/ retrieving the coalescence parameters with ethtool. Those patches are at the end. When the default coalescence parameters are used (rx-frames, rx-frames-irq both set to 5) the maximum number of received packets per interrupt is ~4.2. Setting rx-frames and rx-frames-irq to 20 caused the maximum number of received packets per interrupt to rise to ~19.6. Maximum CPU utilization went down from ~52% to ~35%. Very nice. Fix typo in ethtool_set_coalesce() Signed-off-by: Arthur Kepner --- linux.save/net/core/ethtool.c 2005-05-20 12:40:04.426385446 -0700 +++ linux/net/core/ethtool.c 2005-05-20 12:49:34.087515306 -0700 @@ -347,7 +347,7 @@ static int ethtool_set_coalesce(struct n { struct ethtool_coalesce coalesce; - if (!dev->ethtool_ops->get_coalesce) + if (!dev->ethtool_ops->set_coalesce) return -EOPNOTSUPP; if (copy_from_user(&coalesce, useraddr, sizeof(coalesce))) Changes to allow setting/getting coalescence parameters with tg3. Signed-off-by: Arthur Kepner --- linux.save/drivers/net/tg3.c 2005-05-20 13:02:41.610865448 -0700 +++ linux/drivers/net/tg3.c 2005-05-20 13:11:36.467011288 -0700 @@ -5094,8 +5094,11 @@ static void tg3_set_bdinfo(struct tg3 *t } static void __tg3_set_rx_mode(struct net_device *); -static void tg3_set_coalesce(struct tg3 *tp, struct ethtool_coalesce *ec) +static int tg3_set_coalesce(struct net_device *dev, + struct ethtool_coalesce *ec) { + struct tg3 *tp = netdev_priv(dev); + tw32(HOSTCC_RXCOL_TICKS, ec->rx_coalesce_usecs); tw32(HOSTCC_TXCOL_TICKS, ec->tx_coalesce_usecs); tw32(HOSTCC_RXMAX_FRAMES, ec->rx_max_coalesced_frames); @@ -5114,6 +5117,9 @@ static void tg3_set_coalesce(struct tg3 tw32(HOSTCC_STAT_COAL_TICKS, val); } + + memcpy(&tp->coal, ec, sizeof(tp->coal)); + return 0; } /* tp->lock is held. */ @@ -5437,7 +5443,7 @@ static int tg3_reset_hw(struct tg3 *tp) udelay(10); } - tg3_set_coalesce(tp, &tp->coal); + tg3_set_coalesce(tp->dev, &tp->coal); /* set status block DMA address */ tw32(HOSTCC_STATUS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, @@ -7302,6 +7308,8 @@ static int tg3_get_coalesce(struct net_d return 0; } +static int tg3_set_coalesce(struct net_device *, struct ethtool_coalesce *); + static struct ethtool_ops tg3_ethtool_ops = { .get_settings = tg3_get_settings, .set_settings = tg3_set_settings, @@ -7335,6 +7343,7 @@ static struct ethtool_ops tg3_ethtool_op .get_stats_count = tg3_get_stats_count, .get_ethtool_stats = tg3_get_ethtool_stats, .get_coalesce = tg3_get_coalesce, + .set_coalesce = tg3_set_coalesce, }; static void __devinit tg3_get_eeprom_size(struct tg3 *tp) -- Arthur --8323584-567735041-1116625955=:11419 Content-Type: IMAGE/png; name="cpu_vs_link.4.png" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: CPU utilization Content-Disposition: attachment; filename="cpu_vs_link.4.png" iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgAQAAAAAdquFJAAAAQ3RFWHRTb2Z0 d2FyZQBnbnVwbG90IHZlcnNpb24gNC4wIHBhdGNobGV2ZWwgMCBvbiBMaW51 eCAyLjYuOC0yNC1kZWZhdWx0nVoNlQAADF9JREFUCJntnb1vHMcVwJchEKa7 IH+ALx9FqkSliwA+u0idxomrhAmQwJWsIpFogLgbAmxSRW2AAKFLwYKsVGIC mjcUUrhUihgEopBzgAshIqg9RaL2xL2ZyXzs7sx+73xQFuN9AO+47/Z+9/bt m515M7OzAfUsQQ/sgT2wB/bAHtgDLwC4PR9CSMMwovRppgTJC4SI0s/MgOMo TIAjrAFHKXBJIyMgIVHkF0gzINWBVB2yJXBLAKNoBiTrH4ADp6sWQN2HUYSg AI4ewE3LQ87OMhRAzmNAiNCGABJzC2kOiDLgFT/AWQZc9wGMQ3GGBfCaHZCk QMCBGFEeKcqHR6ZAVlIoAjRC58JCAiG4yYCAAdlZRuDEGLgdUea2xQiTwZwd LTigzMJgMkBoTNkn0WJ03wxoJz2wB/bAHtgDLxvwYLjtF0h5zeMVeEw8A6dL z8DJuV8gIS/8AjF5wjbcZKADY3KcNKBpKBVSr6twF1UKjMjULzAkE79ARIhn IB37Bm77BZZ2/UoBa8U7sE1eMZCwov537so1sTnv8GPNQMyymn1KnxF5dkLo 4EPIX+JYbH+B5XcQcrBQANnBEvGaGOEV+CvmUHdglADZof+CORTa+3Cxyl+Z UWRVnOXZYLQZL4CrhTyj5Xk3NxPEqdkOwJjXhOwNJ0B0AUDHOGQ1K2EoCYyd 4pBK4IKOyUgCcRRCV+BiFbNaAcyWK0wvOwncgBXy/349fBXA3ofmQBQvQVLf i55sZx+iM5oBMW2XOmCcQtATP0Ccdgui0A+QSPfQ+ToDHgC6GN0nA0wdfLie /OCOtDBCUxq5WJhWHwhtC2AYAnmdbWO1WYgSH7JXN2DqQw04WW3xYSMwPcsa cOxkYRqHEsh7ssFmC5AEJeACbBdLijjLmPdkT3GbhTdLwAiOi0AWh8shoSIO V3klVe/DD/5QAoYqNbOQT8pARJa+gefWQExvlU8K4l0ELcAaHwJMZDafAx5M eBfBmw24vRq5/aO//TUI/rS3t5XrIkDTY8tDDsE+/eTP60UL0fHUGrg1/GEV cGLpw9naPq0EVsYhSv95WvooERKwQ/52sFIEhuWSwmWnYF1JAA0/DOjkL2tF 4FyV5XhP7b/eAQg+nX8drheByafiu7vqeJAOrPIhB07pRAcug2EeSO5mQIwg VJVUjYVxAYiV5yWQZj9AWVsdNFZSc+a7+KMBEF+tA8pMSkjE6vrmSgqI3Eh+ sYOF87UzrZKq9mE7UPMhay9plVSNhVtvJf93OMu8vdRcSYEkHWwC6nGY+LCx kkqbP50anMlZxrU+lEBN1QZM4nC1MpNC5hY2C8pvXhSQANgRWPIhqm4finJo YyFPVCsspKirhSVB1cAw03gCqqF7oPRpMOiqrj7M4sjXWS7MfbGX9Goz8Qwk fI6PDnx1nbodLXxdgaOR547xN4BXC+P//B56BeLfvZNZWK5GLeTJx9+tr0Yt fDja/flKQ0VvLmjz1jeu+AQ+we8G67WtLws5O38c+ItDAOgmfnfFXxxOuYW3 tvzF4RHzYfTT7/iz8IQxr378dr2Fpj5kddJbez/71noeKAb9rS2kN+784Eoe qA1lmgrzIb3zHiqlt9YZPTvL9F/cQ3UZvUUcgju4DLTP6JlsZL+hEvD2jL5e 5NBaPmymIqPfsJPr19nL27mMnh57HvSn1hm9kgKwPaOvFKLmmHTJ6DuImgVT l9G3+hDmVHu00ofzcu9crcDc1mG1hZo5hsAw/x8DzodOwLKFxUZ7mw8/XM2p yj5EBaChheWz7AasiEM3oCZ1QMM4LOxlY2GduKdmNcCDoWegEqD0fZ5iBFQ9 KEDpXXyoRss9WajG8y8L0NmHr/8hG5zl5pEpizjEZVVxL7OS0s3CLxOoLp0m wK+CD9EFA13LMvnlsLOFzZICrxUsdAWa+LAjMBOg9H29bAEEnucSE2DdRVC2 kHPwxGXQPw8UgwvxxGXQvwBE7D2anHvzobAwNOgi0DKJKguXAeegiUEXwfVK bdZFwI+YHrxhMOi/12hhcm2YGNwXcFhWVQANugjCBnVWUkzi8LBaXSh6BiWl xYcJ0KAsj8uqMlDpW6UlDs2BdWLd59AGPEV5oHNZPioAnS28fMBX4cOawltj IYGegYrjC5gJ0L6t+1BO3vPZtnGz0BJ4hGyAoHYXegpt8uVpWZXsdfTPD1Lg gwKwSY7qDfzjb64lwEMD4EntJ8+Dr91OgA8NgFWrD0hZfPPHawnQpCyflFXJ XgdBcDcBHhtYWO/DhbpFkS8g0RU4rf3keRCspsCd7sD6ODzVLER5oN318N9b wZUEqP1+q4X1goPg+16BJAjSOPQDpAcrP6kBWtYpHwVp0fNk4a9X/LZtyOPA c75M1CEXgJY+xO8kQKc+hyda5fC5jz6HF0j9f8+HD8+h+n+jLmxMfLgERZVj 2MwG2kYOaDJQqMlS/0oOWDM5uU10H+aB2mCriQ+fo6JKDQdbZfR6HBaBToP+ FcCpy6B/AYjY30Jl9O+L/Py3erL+fjmRL6vUoD8SFtpO4y9ZmEwx8jfon0yC sh30rwNaxmF9G9uypFRZKMWyLNcDhVwQsO+DdQe6+xD5ttAz8OJHK15DH2Zy WYB9WbYAZhyg9C4+tL8VosZC/4P+0C9QjlZoQHcfZj/hx8JLAFQClL4vy05A Vx+WArte9PvkmiyEXYH6nXxNQNQVqN9raABs8OGwrCruZWShdr+miYUNMvQM 7OpDmAfW+1Ce5ZyqtFcah53Siq5xKDZ8Jz7287FrgFoXgafrYUsXAV+Jz8zC ti6Cq4bAeXnQ/8YNfet7rVMB8vcFhBWLAfJh5Ez1maEPESl3EehRRwLaKgVg uYsgNxRfteJ5M7Ach3qvEb1tCqxYDJBbmKmuGvqw6h6fnA+N41D9UCbJ9Pc9 2M7qBEwnCzws/I4xMPPhBhCqx97aNvfkW+1SDl0tzORz+bY1MgPWtxy+kG/m FsI8MPMh/yVg40PUbOHDgrrdwjpg4kPzOKwD3usIagMW45B686GpmLcPuwEN WrDdgJoApfeap8SeLXz9gMMCMIw1KlC7dp5LrCq3xMLO16tqC3FxtQTXQ754 oKsPX8Eh28pFAUs3lfd9Du5AZx+CzDA/FhLfdYqX9Rwaga4+vHgL/QAx9TZQ KM/yS4+LlouWw1OntftyFkrBTmv3VQI9D/pjtXafn+uhXN7/zda0vXNGj1VG 7+uQPd/pj30v74+9x6H9mhjVwIsc9O/rZXdg70N3YO9Dd2DvQ3dg70MnIITU rw+Rk40VwA6932bAM9/AONN78qF3C7370PtZ9h6HLvZdZuBX0IfeD/m1BXp/ api/LgIpvp+8Ru0XA6wD+rvTPwF67iKgvp8ASHkXgQ9RwPpb8SyBk6bdbIA1 97JbA7X14zwBfT/N05f0wB7oCpyJV7QYsdf7/CGFNHm8eSRUWyN+h/JSqJYr QjUTjzCUe4XL4awAlO3NHfEo+6kY/OJPhGDySKigWFQ1liosVGgSZ3s9iEMG yAFFe5MOQ37pBZt8V/5ECPZ2KFRQPK8wkgMwWKr2cbbXzShigDxwJOwMH/C3 zWf8NZzwb+8KFcQvuYYKVSxV+0Il9gqjRwyQA06hBN4VQHEDeTjm394QKojP BFCoIqnaFyqxVxgdTgsW7ifAa5QvQvtQbGyyXUkkVFv4VAC5ikG4Co1PBXxT AHf3C0A5iQOJm/Dui8mGyxGfPYEjeV/emN8CPhOqZK8Z5qrFYEMAN/YKwF0J PBXujjfFxjXAY0So6P4+N02oKBQqNN4XjuGq8EW0WwDelcATcZbPZZ62Lhx2 IoFjcaxCBU7kWR5ne4Vn0d0CcEcCHwngSwkcCaBQ0U9ljHAVoUIFhYoirgqf RTvFsJFAGYexFodRKegw1VQUAuHDUhzKkoJEGQB6SYlKxQJTXQW4KiyXFFmW 10QpDSalsqwXXEx1FeWq7XJZ9iE9sAf2wB7YA78EYJS8xPxZTcmqA+l8pBmR dYAh8FkGfEDBM6mTmBCP1aQVL0CCbYBUHXKStaeHHLKU3waI1wRwNuJA3gze 4jP+tzkwsjrkZRxBdcgxawTQUTgdc2BoA4wxjoAAiqdcRqy5QaG4ryOkyBL4 X6qAoQ6ElsAzDYgWAwUElsAXGhBGykJCnXyIBBCEYQQSILYJm4gDIWtiE8iB hLUTzykMpwJ4Zg6cr80wT5hYkgZ4W43F4QCTwZwvlTijsXlZtpIe6C7/A+kv tsNPcZrVAAAAAElFTkSuQmCC --8323584-567735041-1116625955=:11419 Content-Type: IMAGE/png; name="packets_vs_link.4.png" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Received Pkts/Intr Content-Disposition: attachment; filename="packets_vs_link.4.png" iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgAQAAAAAdquFJAAAAQ3RFWHRTb2Z0 d2FyZQBnbnVwbG90IHZlcnNpb24gNC4wIHBhdGNobGV2ZWwgMCBvbiBMaW51 eCAyLjYuOC0yNC1kZWZhdWx0nVoNlQAAC/NJREFUCJntnTFv48gVgGX4ACeV r0sXpUiVBNkmQapAB6S51EHa+AIE2SIItkh2HcCQR4D7BPkF2wRIcci53MJr jRdbXHGFUwRwsbFHwBULnGGPNj6ZsqnhZOYNyRmSksghn88ylg8wLT1Rn968 ecN5MxySHYksnRbYAltgC2yBLbAFIgOnm2oTqj+m/iL1htvPWLzhPJDyXUVg GDhASXPA4xTYE1WBoQMkyMCoYKG0Ra4OHJO9UI6i9WlXSPpvsnbdlUJMu4b1 dReAAw9gIGk/ZIywgIeSHlM+4QoYcFPkK37mWWRVy2dRSCllXCo2Y/wqUEBu SsuD4NQAaWULpTyTN0QBA+U+DdT+EkEK/MIbOP6uvJWDHpv2mAVOewnwxBuo vBSqeGGS0QQYhVDDAHzjDWTgQ3kqOdHAS13abam5jg+Jj4VM17I858ooBZxo 4D5nXyqgMjdQtRywWy8fdvdCPpLBuKfaMmPQFtm4p/4ddfeCgBE57Yloc0yq AetLC2yBLbAFtsCHBlSpDC6Q0z4uUHXDuEB5NsMG3iIDh9e4wPHupXrTTDZd II9UtkLMS9iGRu+qRBVVWsvREBu42wwYXT5+kgVGDS38Xidroew3A4rB2qcu UCV9DYt8tPZPF1jY1RvY6TxCBcpcHDYGzjqd9QXAhVLXwnqyxIc1gR92FtVy vIMqwGvtyg14Wxg+5EX8p/PDpUA9UDyU8ioytcNpmQ//OzheBKR6o8f06v2X wnxHDapK5GJtoQ8BqAobwTY2ohQ4+X7m4LAU+Fvl0FLg9JMSYBADVdF/oxxK y3x4tDAOpxDxyqhoHWp5tNnbCaek1MJp5vBVsFD9dqT+Qm0mCROzl8jk6fIi K4Y+5oYiBrIy4MW/9n2By314eloSh1IoIImBYXkc5jopFygNcCr7Uc8ARcBp U+B0Xcg9SUazNaWfMxXgDZwjXv1yFWCZ3C1QOwwVeGM7+oXi5cN3NhXBsVCs PnCOD1k4I3F/D/PVXj6EWu78LAucyBQo5EGZDDazwNTCMIGwSxfoW2TrQzPT qoEcBxjFk+DjLQU80vOEr6JNIX196NTyVvyDz42FARvKwN9Cp5ap+cfYHgA5 J+Y46wWE4W3WQhb7UG1rAEEMMPGhA9xd9/aho09q2QH2G1mYxKEBUu3DnXLg KSs9wEItC6JrWZQDL2gpUMXhrKuCScfhuu6klvpwQpC7gCl2n3LUXQELv1kf VqhlP6kQh95yL7kNS14UTqrWtPB5zrpawPDAarYwgOJFqoiYC6zrw2g/VQhG qe2k6loou6lCn26t2Uk5QDOSAglUX1+zk5pv4Xhj4nRSCD5U+ZLTSdW10Kll nS/V7KSEnmAwQDcOYx9W6KTywBs9wUAK+8S1LPx9+E4r5wDjOFz3HkmJSOIe vlCBpCKwqg8ZBeB6IcfOSvUcG8bWQk8wlFhYJjkL0cYpsw7JAhvPYzOJa2EM rDAa9QK6OXZToBVi9U18mAeiW7j6wMY+HGNbyFMOEtBOvN0RsHlbvmsLVw9o Jy+J1Tfx4dEasoVWHgpw9Y6HaqSLC7QcLCDNApv7kGFbyOCnQlzgjbzCBb6T 53g+pPDJG7w4JAA8QM6x5Q520h7qlHhbyWO92f7TtiNG9XS56qPstHPUwS4y XhwG2ECeAyLl2IgWAnBMkIEgdwRs7EOObWGQapCA+J1UKsTqV6pfXn1gvpZX Lw7ZgwPiHA8xLXx4B4e2LTcHNvahPVWCZOGF+Sm8qapTJqst7fACvkOcPwSg kHjzh3cFxJvUvaAyXdqBkmPDNL/Q5vlbeMmdN7lRgKwDvGbIwFtaAegThzOS VzW0cLQ5z0LNGe/WGvjM3K+kvR5NNP7AuT5sMn/4NcurGlo4Lw7N2YqawIy8 x7mNlYcCfA9ym3EXGZjPYFcvDh8ecPV8iD5OeSBzDvey2tkLeAernWfIPoxu sSwU5lxAdI0NvExS4rqSpMSzTheAaBcAJhYOsYu8ix02d7emHScO73IlxuoD G/vQ2oVkIcUGMmwgem6DPjsXYgPt0kIkoL08nVh9o7acGoZkoZWHAly9cQr6 mqUzigyEyTQHiDN/eJcWriyw4XX0DvDcAPFS4oDqF9ipyF0Csdoy8rBC2lni pilxYhjiwlqqX2CuJWZZILqFTYHJhCTy4mTMtszSnyiz0L2modzCCkD3qosl QCtlQPe6EA/gEh92i6r8Xl4WOtfW+Fi4RLrIwIo+zJ/KXOxDU8sZVWGv5FRm JQsrxuGD6ZclWlte/SJfUGSgvWKJWP1K5dgPD7iCPmTIwPwy/sbAwHBeo/kw vvva3AsAa1lofwUJaAqHd72emYN1gEhxiH2JojQXAC5MoJ/93iPHNsCStSJ/ 9LawJMf+1NuHJSnx59UtNC2lBBh1Fn+WB8ZtuSTH9rAwXudQkmN7+LDaVUge tVwJqM+OoAKryCJg47aMfsTOZw6NgVbuCLiC/TI2EH2dwwXLAt+DHPs9HKdE FBloOVjAVIjV319b1t2vGpqLn/ew2nJfU7/6+FuP8sCwJvCAEEl/+kFnKwV2 zQdXNX14MpRy6weDDk2Ayb2uzitbGGXu2sxPpbw8/XiNJMDkXldvqhe57745 UZZMPvvHQOaBB9WBmcmRA/X98OlHnYKFO4t8eEDzPjyRjg/7ysI/3w46vRzQ XgCYl18VNI/dXPnZr7e3f/f0gw+/k6TECXDhOtivnNdD47bM50rH/vDLbz/K F3lhHLo3MDo1bst8ruOQpr5KxykWmPfhoGcddg6qvqzSlitZCKXJxqGVqkDX h+fzUX7AN4761AMoq8ThUJY1b8/DF1m2y8NJlvLAe88Pw5fyx59t4QH5jgL+ 9RsFevmQoFrI9Fc43JZ+DQ0YddZfyh91MC1s7kOaqJgcbywHmiNvmSQ7wQ2B lwMZ8QHGRSYynoKcA6wwyi4ArcwBTlL9Eh/+ZT1RMR2Hub2ywLDENlGw0JVF FlYH5qSGD72BUMtLfAhAG4flx8OyOLQLoytauHRXa1A14LIVkrWAVdZwiqIq v1e1+cNaFhaA0bPkfZXJwwpA+ZOChV5AUfDh32Wjfrm4tOMXc5PqqtPO+ldy RbYXUNUpsjPTnhxzXlfClAN5GFOb+XCOhbaWm1mYAG0c1gPagY8aR9SShf1y 4kNHBdva+WFZz+Jr4eoD7z3HLrVw9YGtD5sDWx82B76HPkQv8soC8VZIxoJ8 WRP+WmLsCwClvQAQC3iNDUR+AqDUFwBiiAUOsYG72MAFc8m1gdlzGhhA5Kd5 okkLbIFNgSPYsmlPbV/phxTqO/FrVQCqQU8/r3AGqtkaqEbwCEOzF591Rzkg TH3J5wFT2yGc/NJPhFDyFlQUnlcYGpUAFdsN072OQ64AGaCZ+upyfeglO3pX /UQI9e8EVBSeVxiYkyrCqA5FutffgkABssAe2MmP9b+dK73lu/rbL0BFxY3W SFCFRnUIKtiLB28VIAMcUgPcByCc0OJ9/e1tUFExASCoAqM6BBXsxYOTYc7C wxj4ROpTm2/gzY7aNQpANRAXANQqBdEq1r8A+A4AXxzmgAcGCDeteQUL2Ge9 baIrwNzHpq9Pmo1AFe81Elo13dwG4PZBDvjCAC/A3eEOvHlCdIyASh4eatNA JSmoWP8QHKNV/Dp4kQPuG+A51PIt9Mx8Cxx2boBwDtOoyLmp5X66F58E+zng cwN8C8AbA+wBEFTypYkRrYokqCioJNMqfhU8z4eNAZo4DJ04DApBJ6SjkpSA DwtxaFoKgzZA3JYSFJqFkK6KaBUvthTTljeglXZ2C23ZbbhCuiqpVXvFtowh LbAFtsAW2ALvARjEm1A/qym+S19yN4lRZPoAT+BVCjyW5MroDIaL/vxzpLWB kagDlLbI8ag9KTJXQ/46QLEBwFFPA3UaPNC3StzTwKBWkWdhQG2RQ5UEyB4f 9jWQ1wGGQgQEgPCUy0ClG5Kys0gDWU3g/6QFchdIawInDpBNNy2Q1AReO0Aa WAujBefqK/qQAZBwHpAYKOqETaCBVKXYEdXASOWJt5LyIQAn/sDxxkjoAZMa pBGdq6k43BTR5ng30nlc6N+Wa0kLbC7/B9txjRjvkl7/AAAAAElFTkSuQmCC --8323584-567735041-1116625955=:11419-- From greearb@candelatech.com Fri May 20 14:58:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 14:58:52 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KLwmF3001020 for ; Fri, 20 May 2005 14:58:48 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j4KMTuGf005032; Fri, 20 May 2005 15:29:56 -0700 Message-ID: <428E5D6D.1010803@candelatech.com> Date: Fri, 20 May 2005 14:58:05 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: Jeff Garzik , davem@davemloft.net, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 References: <1116609329.31523.16.camel@rh4> <20050520194220.GA18259@havoc.gtf.org> <428E4DE2.1020002@pobox.com> <428E5185.1070602@candelatech.com> <20050520210938.GA23714@havoc.gtf.org> <1116620256.31523.23.camel@rh4> In-Reply-To: <1116620256.31523.23.camel@rh4> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1119 Lines: 37 Michael Chan wrote: > On Fri, 2005-05-20 at 17:09 -0400, Jeff Garzik wrote: > >>On Fri, May 20, 2005 at 02:07:17PM -0700, Ben Greear wrote: >> >>>I dig having the chipset manufacturer >>>solidly behind the driver, like e1000! >> >>Clearly you have been asleep :) Broadcom has been contributing actively >>to tg3. >> > > > Yes, we are solidly behind tg3 and bnx2. Excellent...sorry for my sleepiness :) With regard to tg3, I (with the gracious help of the Intel driver folks) have added the ability to receive the ethernet checksum on the end of the skb, as well as tell the e1000 chipset to receive packets with bad checksums, etc.... Assuming the tg3 chipset can do this, are there documents or code snippets available to explain how to enable the feature? I would like to add generic support for this to the ethtool API and allow drivers to support it as they wish.... Of all my hacks, this one actually doesn't require new ioctls or /proc file API..so maybe it has a chance of getting accepted? :) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jdmason@us.ibm.com Fri May 20 15:11:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 15:11:13 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KMB1F3002112 for ; Fri, 20 May 2005 15:11:08 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4KMALmD566586 for ; Fri, 20 May 2005 18:10:21 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KMALwj238724 for ; Fri, 20 May 2005 16:10:21 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4KMAL3E021821 for ; Fri, 20 May 2005 16:10:21 -0600 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4KMAL8V021807 for ; Fri, 20 May 2005 16:10:21 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.10) with ESMTP id j4KMAKbR099746 for ; Fri, 20 May 2005 17:10:20 -0500 Received: from dreadnought (dreadnought.austin.ibm.com [9.53.90.32]) by popmail.austin.ibm.com (AIX5.1/8.11.6p2/8.9.3) with SMTP id j4KMAJU792090 for ; Fri, 20 May 2005 17:10:19 -0500 Received: by dreadnought (sSMTP sendmail emulation); Fri, 20 May 2005 17:10:19 -0500 Date: Fri, 20 May 2005 17:10:19 -0500 From: Jon Mason To: netdev@oss.sgi.com Subject: [PATCH] include/linux/if_tr.h clean-up Message-ID: <20050520221019.GA26211@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i X-archive-position: 1458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2342 Lines: 70 I removed the ethernet definitions (which were commented out) and cleaned up the tabs. Signed-off-by: Jon Mason --- include/linux/if_tr.h.orig 2005-05-20 15:24:46.723707576 -0500 +++ include/linux/if_tr.h 2005-05-20 15:31:44.657172032 -0500 @@ -9,7 +9,7 @@ * * Author: Fred N. van Kempen, * Donald Becker, - * Peter De Schrijver, + * Peter De Schrijver, * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -19,24 +19,16 @@ #ifndef _LINUX_IF_TR_H #define _LINUX_IF_TR_H - /* IEEE 802.5 Token-Ring magic constants. The frame sizes omit the preamble and FCS/CRC (frame check sequence). */ -#define TR_ALEN 6 /* Octets in one ethernet addr */ -#define TR_HLEN (sizeof(struct trh_hdr)+sizeof(struct trllc)) -#define AC 0x10 -#define LLC_FRAME 0x40 -#if 0 -#define ETH_HLEN 14 /* Total octets in header. */ -#define ETH_ZLEN 60 /* Min. octets in frame sans FCS */ -#define ETH_DATA_LEN 1500 /* Max. octets in payload */ -#define ETH_FRAME_LEN 1514 /* Max. octets in frame sans FCS */ -#endif - +#define TR_ALEN 6 /* Octets in one token-ring addr */ +#define TR_HLEN (sizeof(struct trh_hdr)+sizeof(struct trllc)) +#define AC 0x10 +#define LLC_FRAME 0x40 /* LLC and SNAP constants */ -#define EXTENDED_SAP 0xAA -#define UI_CMD 0x03 +#define EXTENDED_SAP 0xAA +#define UI_CMD 0x03 /* This is an Token-Ring frame header. */ struct trh_hdr { @@ -96,14 +88,13 @@ struct tr_statistics { }; /* source routing stuff */ - -#define TR_RII 0x80 -#define TR_RCF_DIR_BIT 0x80 -#define TR_RCF_LEN_MASK 0x1f00 -#define TR_RCF_BROADCAST 0x8000 /* all-routes broadcast */ -#define TR_RCF_LIMITED_BROADCAST 0xC000 /* single-route broadcast */ -#define TR_RCF_FRAME2K 0x20 -#define TR_RCF_BROADCAST_MASK 0xC000 -#define TR_MAXRIFLEN 18 +#define TR_RII 0x80 +#define TR_RCF_DIR_BIT 0x80 +#define TR_RCF_LEN_MASK 0x1f00 +#define TR_RCF_BROADCAST 0x8000 /* all-routes broadcast */ +#define TR_RCF_LIMITED_BROADCAST 0xC000 /* single-route broadcast */ +#define TR_RCF_FRAME2K 0x20 +#define TR_RCF_BROADCAST_MASK 0xC000 +#define TR_MAXRIFLEN 18 #endif /* _LINUX_IF_TR_H */ From davem@davemloft.net Fri May 20 15:29:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 15:29:33 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KMTSF3003397 for ; Fri, 20 May 2005 15:29:28 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DZFyv-00024F-42; Fri, 20 May 2005 15:28:37 -0700 Date: Fri, 20 May 2005 15:28:36 -0700 (PDT) Message-Id: <20050520.152836.48528379.davem@davemloft.net> To: jgarzik@pobox.com Cc: mchan@broadcom.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 From: "David S. Miller" In-Reply-To: <20050520194220.GA18259@havoc.gtf.org> References: <1116609329.31523.16.camel@rh4> <20050520194220.GA18259@havoc.gtf.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2081 Lines: 55 From: Jeff Garzik Date: Fri, 20 May 2005 15:42:20 -0400 > 9) [additional review] DaveM, others: is this correct for all arches? > > + if (unlikely((align = (unsigned long) skb->data & 0x7))) { > + skb_reserve(skb, 8 - align); > + } It's probably not even necessary. dev_alloc_skb() should be returning an SKB with skb->data at least cache_line_size() aligned (see mm/slab.c) unless the platform defines an ARCH_KMALLOC_MINALIGN override. > 10) [additional review] doesn't bnx2_rx_int() need to move the rmb() > inside the loop? Are you protecting against the compiler > reordering/caching loads/stores, or against SMP CPUs? This rmb() is needed to strongly order the status block consumer index read, from that of the descriptor data. I'm pretty sure it's in the right spot. > 10.1) [additional review] is the rmb() even needed in bnx2_rx_int(), > since its caller also uses rmb()? No, it's guarding status block consumer index read to the first RX descriptor read, as explained above. > 13) [additional review] why is CHECKSUM_UNNECESSARY used when > cksum==0xffff or cksum==0 ? > > + u16 cksum = rx_hdr->l2_fhdr_tcp_udp_xsum; > + > + if ((cksum == 0xffff) || (cksum == 0)) { > + skb->ip_summed = CHECKSUM_UNNECESSARY; > + } For UDP, a checksum value of zero means no checksum at all. > 18) you can eliminate one call to request_irq, by lengthening the 'if' test: Of just assigning a function pointer and set of flags to a local variable. Then doing on request_irq call. > 20) is there any reason to #ifdef BCM_TSO? 2.4.x kernels I suppose? Yeah, same for MSI stuff as well. > 27) isn't 'timer_interval == HZ' too rapid a timer? Does it really need > to fire every second? The pulse has to be written the the chip at least once every 50 milliseconds, or else the chip goes into OS absent mode. Anyways, the timer interval can probably be extended, although link probing at 1 second intervals does seem reasonable. From davem@davemloft.net Fri May 20 15:34:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 15:34:19 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KMYFF3004049 for ; Fri, 20 May 2005 15:34:16 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DZG3a-00024p-NK; Fri, 20 May 2005 15:33:26 -0700 Date: Fri, 20 May 2005 15:33:26 -0700 (PDT) Message-Id: <20050520.153326.08322399.davem@davemloft.net> To: akepner@sgi.com Cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: Perf data with recent tg3 patches From: "David S. Miller" In-Reply-To: References: <1116031159.6214.8.camel@rh4> <20050513.222007.78719997.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 715 Lines: 19 From: Arthur Kepner Date: Fri, 20 May 2005 14:52:35 -0700 (PDT) > When the default coalescence parameters are used (rx-frames, > rx-frames-irq both set to 5) the maximum number of received > packets per interrupt is ~4.2. Setting rx-frames and > rx-frames-irq to 20 caused the maximum number of received > packets per interrupt to rise to ~19.6. Maximum CPU > utilization went down from ~52% to ~35%. Very nice. Yes, but using such a high value makes latency go into the toilet. :-) I'd much rather see dynamic settings based upon packet rate. It's easy to resurrect the ancient code from the early tg3 days which does this. Thanks for all your testing, it is very informative and useful. From rick.jones2@hp.com Fri May 20 15:53:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 15:53:03 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KMr1F3005508 for ; Fri, 20 May 2005 15:53:01 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 774B6404114 for ; Fri, 20 May 2005 15:52:21 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA17714 for ; Fri, 20 May 2005 15:52:20 -0700 (PDT) Message-ID: <428E6A24.7060403@hp.com> Date: Fri, 20 May 2005 15:52:20 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: Perf data with recent tg3 patches References: <1116031159.6214.8.camel@rh4> <20050513.222007.78719997.davem@davemloft.net> <20050520.153326.08322399.davem@davemloft.net> In-Reply-To: <20050520.153326.08322399.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1021 Lines: 24 > Yes, but using such a high value makes latency go into the > toilet. :-) For low packet rates. > > I'd much rather see dynamic settings based upon packet rate. > It's easy to resurrect the ancient code from the early > tg3 days which does this. If that is the stuff I think it was, it was giving me _fits_ trying to run TCP_RR tests. Results bounced all over the place. I think it was trying to kick-in at pps rates that were below the limits of what a pair of systems could do on a single, synchronous request/response stream. Now, modulo an OS that I cannot mention because its EULA forbits discussing results with third parties, where the netperf TCP_RR perf is 8000 transactions per second no matter how powerful the CPU... if folks are simply free to set high coalescing parms on their own, presumably with some knowledge of their workloads, wouldn't that be enough? That has been "good enough" for one OS I can discuss - HP-UX - and its bcm570X-based GbE NICs and before to Tigon2. rick jones From akepner@sgi.com Fri May 20 15:57:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 15:58:00 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KMvsF3006496 for ; Fri, 20 May 2005 15:57:54 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4L0gDEw015067 for ; Fri, 20 May 2005 17:42:13 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4KMvEbT74194031 for ; Fri, 20 May 2005 15:57:15 -0700 (PDT) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-82.corp.sgi.com [134.15.0.82]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4KMuD3d28075125; Fri, 20 May 2005 15:56:13 -0700 (PDT) Date: Fri, 20 May 2005 15:54:03 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: "David S.Miller" cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: Perf data with recent tg3 patches In-Reply-To: <20050520.153326.08322399.davem@davemloft.net> Message-ID: References: <1116031159.6214.8.camel@rh4> <20050513.222007.78719997.davem@davemloft.net> <20050520.153326.08322399.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 190 Lines: 11 On Fri, 20 May 2005, David S.Miller wrote: > ..... > Yes, but using such a high value makes latency go into the > toilet. :-) > ..... Latency measurements are on my to-do list. -- Arthur From jgarzik@pobox.com Fri May 20 16:30:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 16:30:50 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KNUjF3012538 for ; Fri, 20 May 2005 16:30:46 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DZGwP-0000Kb-Db; Fri, 20 May 2005 23:30:05 +0000 Message-ID: <428E72F9.3070404@pobox.com> Date: Fri, 20 May 2005 19:30:01 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S.Miller" CC: mchan@broadcom.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 References: <1116609329.31523.16.camel@rh4> <20050520194220.GA18259@havoc.gtf.org> <20050520.152836.48528379.davem@davemloft.net> In-Reply-To: <20050520.152836.48528379.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1358 Lines: 44 David S.Miller wrote: > From: Jeff Garzik > Date: Fri, 20 May 2005 15:42:20 -0400 >>10) [additional review] doesn't bnx2_rx_int() need to move the rmb() >>inside the loop? Are you protecting against the compiler >>reordering/caching loads/stores, or against SMP CPUs? > > > This rmb() is needed to strongly order the status block consumer > index read, from that of the descriptor data. I'm pretty sure it's > in the right spot. > > >>10.1) [additional review] is the rmb() even needed in bnx2_rx_int(), >>since its caller also uses rmb()? > > > No, it's guarding status block consumer index read to the first > RX descriptor read, as explained above. OK >>13) [additional review] why is CHECKSUM_UNNECESSARY used when >>cksum==0xffff or cksum==0 ? >> >>+ u16 cksum = rx_hdr->l2_fhdr_tcp_udp_xsum; >>+ >>+ if ((cksum == 0xffff) || (cksum == 0)) { >>+ skb->ip_summed = CHECKSUM_UNNECESSARY; >>+ } > > > For UDP, a checksum value of zero means no checksum at all. Sure. What I'm driving at is that a checksum of zero seems to imply CHECKSUM_NONE not CHECKSUM_UNNECESSARY. tg3 only does the 0xffff check. I am also a bit surprised that, if the actual checksum value is available, why not use CHECKSUM_HW like sunhme? Jeff From davem@davemloft.net Fri May 20 16:45:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 16:45:58 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4KNjsF3013802 for ; Fri, 20 May 2005 16:45:54 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DZHAu-0002He-64; Fri, 20 May 2005 16:45:04 -0700 Date: Fri, 20 May 2005 16:45:04 -0700 (PDT) Message-Id: <20050520.164504.31639000.davem@davemloft.net> To: jgarzik@pobox.com Cc: mchan@broadcom.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 From: "David S. Miller" In-Reply-To: <428E72F9.3070404@pobox.com> References: <20050520194220.GA18259@havoc.gtf.org> <20050520.152836.48528379.davem@davemloft.net> <428E72F9.3070404@pobox.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 873 Lines: 20 From: Jeff Garzik Date: Fri, 20 May 2005 19:30:01 -0400 > Sure. What I'm driving at is that a checksum of zero seems to imply > CHECKSUM_NONE not CHECKSUM_UNNECESSARY. tg3 only does the 0xffff check. Sure, both ways are fine. > I am also a bit surprised that, if the actual checksum value is > available, why not use CHECKSUM_HW like sunhme? CHECKSUM_HW is for a different calculation than what 5706 and tg3 are providing here. CHECKSUM_HW is for when the chip provides a raw 2's complement 16-bit sum starting at a fixed offset from the beginning of the packet. The network stack then "undoes" or subtracts the header 2's complement checksum from the device provided sum to arrive at the real checksum result. 5706 and tg3 are actually interpreting the headers and running the checksum algorithm over the proper parts of the packet headers. From jgarzik@pobox.com Fri May 20 17:02:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 17:02:10 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4L026F3015295 for ; Fri, 20 May 2005 17:02:06 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DZHQj-0000M1-W7; Sat, 21 May 2005 00:01:26 +0000 Message-ID: <428E7A53.1030907@pobox.com> Date: Fri, 20 May 2005 20:01:23 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S.Miller" CC: mchan@broadcom.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 References: <20050520194220.GA18259@havoc.gtf.org> <20050520.152836.48528379.davem@davemloft.net> <428E72F9.3070404@pobox.com> <20050520.164504.31639000.davem@davemloft.net> In-Reply-To: <20050520.164504.31639000.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 445 Lines: 19 David S.Miller wrote: > From: Jeff Garzik > Date: Fri, 20 May 2005 19:30:01 -0400 > > >>Sure. What I'm driving at is that a checksum of zero seems to imply >>CHECKSUM_NONE not CHECKSUM_UNNECESSARY. tg3 only does the 0xffff check. > > > Sure, both ways are fine. huh? They are pretty different... one says "Checksum all good, dude" and the other says "I didn't checksum, do it in software for me." right? Jeff From mchan@broadcom.com Fri May 20 17:03:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 17:03:09 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4L035F3015416 for ; Fri, 20 May 2005 17:03:05 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 20 May 2005 17:02:13 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 20 May 2005 17:02:12 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZP33868; Fri, 20 May 2005 17:02:11 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA17902; Fri, 20 May 2005 17:02:11 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Sat, 21 May 2005 00:02:11 +0000 Received: from rh4 by nt-irva-0741; 20 May 2005 16:04:21 -0700 Subject: Re: A new driver for Broadcom bcm5706 From: "Michael Chan" To: "David S.Miller" cc: jgarzik@pobox.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com In-Reply-To: <20050520.152836.48528379.davem@davemloft.net> References: <1116609329.31523.16.camel@rh4> <20050520194220.GA18259@havoc.gtf.org> <20050520.152836.48528379.davem@davemloft.net> Date: Fri, 20 May 2005 16:04:21 -0700 Message-ID: <1116630261.31523.42.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E90A50F2U4586191-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 3238 Lines: 82 On Fri, 2005-05-20 at 15:28 -0700, David S.Miller wrote: > From: Jeff Garzik > Date: Fri, 20 May 2005 15:42:20 -0400 > > > 9) [additional review] DaveM, others: is this correct for all arches? > > > > + if (unlikely((align = (unsigned long) skb->data & 0x7))) { > > + skb_reserve(skb, 8 - align); > > + } > > It's probably not even necessary. dev_alloc_skb() should be returning > an SKB with skb->data at least cache_line_size() aligned (see mm/slab.c) > unless the platform defines an ARCH_KMALLOC_MINALIGN override. If I remember correctly, I was seeing some SKB with skb->data that is 4- byte aligned on some Fedora kernels. I don't remember which kernel. This device has an alignment requirement of at least 8-bytes for the receive buffers. > > > 10) [additional review] doesn't bnx2_rx_int() need to move the rmb() > > inside the loop? Are you protecting against the compiler > > reordering/caching loads/stores, or against SMP CPUs? > > This rmb() is needed to strongly order the status block consumer > index read, from that of the descriptor data. I'm pretty sure it's > in the right spot. > > > 10.1) [additional review] is the rmb() even needed in bnx2_rx_int(), > > since its caller also uses rmb()? > > No, it's guarding status block consumer index read to the first > RX descriptor read, as explained above. That's right. We saw rare failures in Anton's PPC environment that caused the driver to read stale rx buffer descriptors ahead of the rx index in the status block without the rmb(). > > > 13) [additional review] why is CHECKSUM_UNNECESSARY used when > > cksum==0xffff or cksum==0 ? > > > > + u16 cksum = rx_hdr->l2_fhdr_tcp_udp_xsum; > > + > > + if ((cksum == 0xffff) || (cksum == 0)) { > > + skb->ip_summed = CHECKSUM_UNNECESSARY; > > + } > > For UDP, a checksum value of zero means no checksum at all. Yes, but in this case, cksum is the checksum calculated over the entire TCP/UDP packet including the pseudo IP header. Jeff is right, it should always be 0xffff when the checksum is correct. Checking for zero is a bug. > > > 18) you can eliminate one call to request_irq, by lengthening the 'if' test: > > Of just assigning a function pointer and set of flags to a local variable. > Then doing on request_irq call. > > > 20) is there any reason to #ifdef BCM_TSO? 2.4.x kernels I suppose? > > Yeah, same for MSI stuff as well. > > > 27) isn't 'timer_interval == HZ' too rapid a timer? Does it really need > > to fire every second? > > The pulse has to be written the the chip at least once every 50 milliseconds, > or else the chip goes into OS absent mode. Anyways, the timer interval can > probably be extended, although link probing at 1 second intervals does seem > reasonable. > > Originally, the driver pulse interval was set at 250 msec, but it's been extended to a few seconds. So the driver currently will write the pulse every second and do the serdes related checking at the same time. David, Do you want me to fix some of these things and send you a new 500K patch or just send incremental patches over the existing driver? From mchan@broadcom.com Fri May 20 17:10:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 17:10:03 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4L0A0F3016967 for ; Fri, 20 May 2005 17:10:00 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 20 May 2005 17:09:01 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 20 May 2005 17:08:59 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZP36454; Fri, 20 May 2005 17:08:57 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA19291; Fri, 20 May 2005 17:08:57 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Sat, 21 May 2005 00:08:57 +0000 Received: from rh4 by nt-irva-0741; 20 May 2005 16:11:07 -0700 Subject: Re: A new driver for Broadcom bcm5706 From: "Michael Chan" To: "Jeff Garzik" cc: "David S.Miller" , netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com In-Reply-To: <428E7A53.1030907@pobox.com> References: <20050520194220.GA18259@havoc.gtf.org> <20050520.152836.48528379.davem@davemloft.net> <428E72F9.3070404@pobox.com> <20050520.164504.31639000.davem@davemloft.net> <428E7A53.1030907@pobox.com> Date: Fri, 20 May 2005 16:11:07 -0700 Message-ID: <1116630667.31523.45.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E90A3971VO476299-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 770 Lines: 23 On Fri, 2005-05-20 at 20:01 -0400, Jeff Garzik wrote: > David S.Miller wrote: > > From: Jeff Garzik > > Date: Fri, 20 May 2005 19:30:01 -0400 > > > > > >>Sure. What I'm driving at is that a checksum of zero seems to imply > >>CHECKSUM_NONE not CHECKSUM_UNNECESSARY. tg3 only does the 0xffff check. > > > > > > Sure, both ways are fine. > > huh? They are pretty different... one says "Checksum all good, dude" > and the other says "I didn't checksum, do it in software for me." > > right? > Yes, if the UDP checksum field in the UDP header is zero - meaning checksum is not calculated for this packet, the calculated checksum done by the chip will almost always be something other than 0xffff, and so it will end up with CHECKSUM_NONE. From xose.vazquez@gmail.com Fri May 20 17:33:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 17:33:44 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4L0XWF3018656 for ; Fri, 20 May 2005 17:33:33 -0700 Received: by wproxy.gmail.com with SMTP id 69so5734wri for ; Fri, 20 May 2005 17:32:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=oqSI07cxBpXs2VdWcyd+mBhwNMy6JUXlSuUyoqOqq3zLc59B2GcDz7P32QkX04gfHF9r4EIPqf5eTeyjhzk04U1x7K4b7t5nlb3WTQdXWwF3sxZ3cehfQxFGo9MaRS31P+XcDZg/OGMwOgUOZicrgqZimMEKs8s59zM90z03bTE= Received: by 10.54.81.14 with SMTP id e14mr2218556wrb; Fri, 20 May 2005 17:11:37 -0700 (PDT) Received: by 10.54.28.57 with HTTP; Fri, 20 May 2005 17:11:37 -0700 (PDT) Message-ID: Date: Sat, 21 May 2005 02:11:37 +0200 From: Xose Vazquez Perez Reply-To: Xose Vazquez Perez To: netdev@oss.sgi.com, davem@redhat.com, jgarzik@pobox.com, mchan@broadcom.com Subject: [PATCH] tg3: new ID Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2428_28044994.1116634297724" X-archive-position: 1468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xose.vazquez@gmail.com Precedence: bulk X-list: netdev Content-Length: 1987 Lines: 40 ------=_Part_2428_28044994.1116634297724 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Add 0x1601 as 5752M, it's a 5752 but for mobile PCs. Stolen from Broadcom bcm5700-8.1.55 driver. Someone forgot to add it to tg3 ;-) (against linux-2.6.12-rc4-git4) -thanks- ------=_Part_2428_28044994.1116634297724 Content-Type: text/x-patch; name="tg3_5752M_id.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tg3_5752M_id.diff" ZGlmZiAtTnVhciBvL2RyaXZlcnMvbmV0L3RnMy5jIG4vZHJpdmVycy9uZXQvdGczLmMKLS0tIG8v ZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yMSAwMTo1MDo0MC4wMDAwMDAwMDAgKzAyMDAKKysr IG4vZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yMSAwMTo0MjoyOS4wMDAwMDAwMDAgKzAyMDAK QEAgLTIwNiw2ICsyMDYsOCBAQAogCSAgUENJX0FOWV9JRCwgUENJX0FOWV9JRCwgMCwgMCwgMFVM IH0sCiAJeyBQQ0lfVkVORE9SX0lEX0JST0FEQ09NLCBQQ0lfREVWSUNFX0lEX1RJR09OM181NzUy LAogCSAgUENJX0FOWV9JRCwgUENJX0FOWV9JRCwgMCwgMCwgMFVMIH0sCisJeyBQQ0lfVkVORE9S X0lEX0JST0FEQ09NLCBQQ0lfREVWSUNFX0lEX1RJR09OM181NzUyTSwKKwkgIFBDSV9BTllfSUQs IFBDSV9BTllfSUQsIDAsIDAsIDBVTCB9LAogCXsgUENJX1ZFTkRPUl9JRF9CUk9BRENPTSwgUENJ X0RFVklDRV9JRF9USUdPTjNfNTc1MywKIAkgIFBDSV9BTllfSUQsIFBDSV9BTllfSUQsIDAsIDAs IDBVTCB9LAogCXsgUENJX1ZFTkRPUl9JRF9CUk9BRENPTSwgUENJX0RFVklDRV9JRF9USUdPTjNf NTc1M00sCmRpZmYgLU51YXIgby9pbmNsdWRlL2xpbnV4L3BjaV9pZHMuaCBuL2luY2x1ZGUvbGlu dXgvcGNpX2lkcy5oCi0tLSBvL2luY2x1ZGUvbGludXgvcGNpX2lkcy5oCTIwMDUtMDUtMjEgMDE6 NTA6MzQuMDAwMDAwMDAwICswMjAwCisrKyBuL2luY2x1ZGUvbGludXgvcGNpX2lkcy5oCTIwMDUt MDUtMjEgMDE6NTA6MDYuMDAwMDAwMDAwICswMjAwCkBAIC0yMDY0LDYgKzIwNjQsNyBAQAogCiAj ZGVmaW5lIFBDSV9WRU5ET1JfSURfQlJPQURDT00JCTB4MTRlNAogI2RlZmluZSBQQ0lfREVWSUNF X0lEX1RJR09OM181NzUyCTB4MTYwMAorI2RlZmluZSBQQ0lfREVWSUNFX0lEX1RJR09OM181NzUy TQkweDE2MDEKICNkZWZpbmUgUENJX0RFVklDRV9JRF9USUdPTjNfNTcwMAkweDE2NDQKICNkZWZp bmUgUENJX0RFVklDRV9JRF9USUdPTjNfNTcwMQkweDE2NDUKICNkZWZpbmUgUENJX0RFVklDRV9J RF9USUdPTjNfNTcwMgkweDE2NDYK ------=_Part_2428_28044994.1116634297724-- From grundler@lackof.org Fri May 20 17:49:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 17:49:10 -0700 (PDT) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4L0n7F3019771 for ; Fri, 20 May 2005 17:49:07 -0700 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id 8635829806B; Fri, 20 May 2005 18:51:39 -0600 (MDT) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30616-06; Fri, 20 May 2005 18:51:39 -0600 (MDT) Received: by colo.lackof.org (Postfix, from userid 27253) id 2211029802F; Fri, 20 May 2005 18:51:39 -0600 (MDT) Date: Fri, 20 May 2005 18:51:39 -0600 From: Grant Grundler To: Jeff Garzik Cc: Grant Grundler , akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree Message-ID: <20050521005139.GB2411@colo.lackof.org> References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> <20050516222612.GD9282@colo.lackof.org> <428E3372.403@pobox.com> <20050520211229.GA2411@colo.lackof.org> <428E57E2.2090204@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428E57E2.2090204@pobox.com> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.9i X-archive-position: 1469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev Content-Length: 4171 Lines: 109 On Fri, May 20, 2005 at 05:34:26PM -0400, Jeff Garzik wrote: > Yes, tg3 is awful in this regard. I have made a bit of progress by > moving some of the stuff into a workqueue. ah good! At some point I should re-install the fiber bcm5701 cards I have and see if they work better then. > >It's totally relevant. > >Complaints (bug reports) and patches drive change. That's how both > >commercial *and* non-commercial developers prioritize. > > > >"Ingo and the real-time crowd" are a good example of a change > >in priorities driven by non-commercial users. > > No, these are commercial users. Embedded space really cares about this > stuff. Sorry - maybe VM support for VIVT cache is a better example? (I'm thinking sparc/parisc support) Almost everything I think of has some form of commercial interest either directly (embedded, HA, infiniband, Server IO, ia64/amd64, etc) or indirectly (sponsorships at Universities or sourceforge projects). > >Understood. But they were not the first ones. Donald Becker has a fairly > >well known digust for use of CPU spin loops. But we can't eliminate > >*all* udelay just becuase of the way HW is designed and has bugs. > >I think it would be reasonable to get rid of many udelay calls > >(replace them with PCI read delay loops like Donald has advocated) > >and get the rest into a context where it matters less. > >I have no objection to people fixing those sorts of issues. > > If you recognize the issue, you should object to new changes adding new > issues! And ignore fixes for existing issues. "The enemy of good is perfect" ... > >Not true. This patch brings the tulip driver into compliance with > >published specs and makes the driver functional for parisc/mips/ia64 users. > > Ok, yes, it fixes the tulip issue AND causes work for others. But it's not new work. In timer.c, tulip_restart_rxtx() is called right after tulip_select_media(). tulip_restart_rxtx() has a potential 1300 usec delay loop. About the same as the code in tulip_select_media() needs. I now appreciate much more that a RH employee (IIRC, John Linville) submitted that patch indirectly on my behalf. I filed the original bugzilla and provided the patch based on work by Charlie Brett. > >The "whatever reason" is clearly decided by the mainline kernel maintainer. > >If we treat other people's labor as "free", then the right answer is > >to drop the patch and wait for some subset of "we" to do the extra legwork. > > Um, this is how all kernel development works :) *nod* > Maintainers are not supposed to merge patches into upstream, if they > have flaws still remaining to be corrected. Many patches are not this black and white. All patches have to survive at least one subjective evaluation: Is the cure worse than the illness? > >Several people care if tulip phy init works right. OTOH, I'm only aware of > >one person who specifically cares if tulip is holding the CPU hostage for > >1 or 2 ms during the occasional phy init. > > > >Is being a technology purist more important than moving forward with > >what people care about? > > There will _always_ be ugly patches that get hardware going for some users. "ugly" is subjective. Especially in the context of tulip phy init sequence. Anyone who finds beauty in that chunk of code is truly twisted. :^) (It just reflects the ugly mess of HW that too many vendors shipped. I don't ever expect tulip driver to be "clean" here.) > Tons of changes are kept outside the kernel until they are ready. This > is just one more example. > > Merging code into the kernel is a big deal. That code will have to be > maintained for years, maybe decades. "when in doubt, don't merge" is > generally the right answer. Agreed. > I don't want your patch to become an issue that embedded developers must > address (like the tg3 example above), causing further patching and > headache in that area. Certainly. No problem with that. BTW, which embedded developers still care about tulip driver? One could use this patch as a litmus test to see how much they care. :^) I was expecting they'd be using gigabit NICs, Wi-Fi, GSM, or bluetooth these days. thanks, grant From davem@davemloft.net Fri May 20 21:29:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 21:29:26 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4L4TIF3001601 for ; Fri, 20 May 2005 21:29:18 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DZLb3-0002VN-8v; Fri, 20 May 2005 21:28:21 -0700 Date: Fri, 20 May 2005 21:28:21 -0700 (PDT) Message-Id: <20050520.212821.88475745.davem@davemloft.net> To: jgarzik@pobox.com Cc: mchan@broadcom.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 From: "David S. Miller" In-Reply-To: <428E7A53.1030907@pobox.com> References: <428E72F9.3070404@pobox.com> <20050520.164504.31639000.davem@davemloft.net> <428E7A53.1030907@pobox.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 734 Lines: 23 From: Jeff Garzik Subject: Re: A new driver for Broadcom bcm5706 Date: Fri, 20 May 2005 20:01:23 -0400 > David S.Miller wrote: > > From: Jeff Garzik > > Date: Fri, 20 May 2005 19:30:01 -0400 > > > > > >>Sure. What I'm driving at is that a checksum of zero seems to imply > >>CHECKSUM_NONE not CHECKSUM_UNNECESSARY. tg3 only does the 0xffff check. > > > > > > Sure, both ways are fine. > > huh? They are pretty different... one says "Checksum all good, dude" > and the other says "I didn't checksum, do it in software for me." > > right? 0x0000 is the UDP "no checksum" case, so if we say "in software" for that UDP will just let it pass through still, so the effect is that same. From davem@davemloft.net Fri May 20 21:36:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 21:36:49 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4L4aiF3002494 for ; Fri, 20 May 2005 21:36:44 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DZLiE-0002W9-NB; Fri, 20 May 2005 21:35:46 -0700 Date: Fri, 20 May 2005 21:35:46 -0700 (PDT) Message-Id: <20050520.213546.98553218.davem@davemloft.net> To: mchan@broadcom.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 From: "David S. Miller" In-Reply-To: <1116630261.31523.42.camel@rh4> References: <20050520194220.GA18259@havoc.gtf.org> <20050520.152836.48528379.davem@davemloft.net> <1116630261.31523.42.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 372 Lines: 9 From: "Michael Chan" Date: Fri, 20 May 2005 16:04:21 -0700 > On Fri, 2005-05-20 at 15:28 -0700, David S.Miller wrote: > David, Do you want me to fix some of these things and send you a new > 500K patch or just send incremental patches over the existing driver? Please send incremental patches. That also makes the changes easier to review as well. From davem@davemloft.net Fri May 20 21:37:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 20 May 2005 21:37:53 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4L4bnF3002851 for ; Fri, 20 May 2005 21:37:49 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DZLjM-0002WM-Vg; Fri, 20 May 2005 21:36:57 -0700 Date: Fri, 20 May 2005 21:36:56 -0700 (PDT) Message-Id: <20050520.213656.28396543.davem@davemloft.net> To: mchan@broadcom.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 From: "David S. Miller" In-Reply-To: <1116630261.31523.42.camel@rh4> References: <20050520194220.GA18259@havoc.gtf.org> <20050520.152836.48528379.davem@davemloft.net> <1116630261.31523.42.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1543 Lines: 37 From: "Michael Chan" Date: Fri, 20 May 2005 16:04:21 -0700 > On Fri, 2005-05-20 at 15:28 -0700, David S.Miller wrote: > > From: Jeff Garzik > > Date: Fri, 20 May 2005 15:42:20 -0400 > > > > > 9) [additional review] DaveM, others: is this correct for all arches? > > > > > > + if (unlikely((align = (unsigned long) skb->data & 0x7))) { > > > + skb_reserve(skb, 8 - align); > > > + } > > > > It's probably not even necessary. dev_alloc_skb() should be returning > > an SKB with skb->data at least cache_line_size() aligned (see mm/slab.c) > > unless the platform defines an ARCH_KMALLOC_MINALIGN override. > > If I remember correctly, I was seeing some SKB with skb->data that is 4- > byte aligned on some Fedora kernels. I don't remember which kernel. This > device has an alignment requirement of at least 8-bytes for the receive > buffers. Just keep it in for now then. I wouldn't be surprised if some 2.4.x kernels let this happen. > Yes, but in this case, cksum is the checksum calculated over the entire > TCP/UDP packet including the pseudo IP header. Jeff is right, it should > always be 0xffff when the checksum is correct. Checking for zero is a > bug. Ok, thanks for verifying. > Originally, the driver pulse interval was set at 250 msec, but it's been > extended to a few seconds. So the driver currently will write the pulse > every second and do the serdes related checking at the same time. I think the current timer stuff is fine, at least for now. From cranium2003@yahoo.com Sat May 21 02:49:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 02:49:19 -0700 (PDT) Received: from web33015.mail.mud.yahoo.com (web33015.mail.mud.yahoo.com [68.142.206.79]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4L9nFF3020672 for ; Sat, 21 May 2005 02:49:15 -0700 Received: (qmail 79202 invoked by uid 60001); 21 May 2005 09:48:35 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=r8kzdYcHi8o7FME9h0CZ1Ncx1b5b80On2nIiAwyovY9havQmEphGFelV3wrp1uRiDQ3lDRl5vpJTdBvy4DBm1Z4K2SuO8si2f+wbA+e00ktBaKwaEo2ehra8BMfJFxtJToVOr2uBL2Evzqlh6mVBl6OJNEnEgbvD9LOYDnXue0U= ; Message-ID: <20050521094835.79200.qmail@web33015.mail.mud.yahoo.com> Received: from [203.199.141.99] by web33015.mail.mud.yahoo.com via HTTP; Sat, 21 May 2005 02:48:35 PDT Date: Sat, 21 May 2005 02:48:35 -0700 (PDT) From: cranium2003 Subject: who is eating hw header in packets? To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1595 Lines: 51 hello, I use ethereal to capture a packet. I sent a ping request packet to hosta from hostB. On hostA it will be captured and replyis generated and packet sent to hostB. But it is captured as Frame 2 (98 bytes on wire, 98 bytes captured) Arrival Time: May 21, 2005 10:37:57.360894000 Time delta from previous packet: 0.000409000 seconds Time relative to first packet: 0.000409000 seconds Frame Number: 2 Packet Length: 98 bytes Capture Length: 98 bytes Ethernet II, Src: 00:00:40:01:bc:29, Dst: 45:00:00:54:3a:2b Destination: 45:00:00:54:3a:2b (45:00:00:54:3a:2b) Source: 00:00:40:01:bc:29 (Applicon_01:bc:29) Type: Unknown (0xc0a8) Data (84 bytes) 0000 01 fa c0 a8 01 0a 00 00 82 68 0e 0f 00 01 2d c2 .........h....-. 0010 8e 42 c3 7f 05 00 08 09 0a 0b 0c 0d 0e 0f 10 11 .B.............. 0020 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 .............. ! 0030 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 "#$%&'()*+,-./01 0040 32 33 34 35 36 37 00 00 00 00 00 00 00 00 00 00 234567.......... 0050 00 00 00 00 .... I want to ask which routine in linux kernel is discarding packet? Because what i found is that the first 14 bytes((src + dst) HW header + protocol type field) 00 08 a1 43 61 f5 00 08 a1 43 62 91 08 00 bytes are replaced with next all bytes and last 14 bytes are filled with 0's. regards, cranium. __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From juliokriger@gmail.com Sat May 21 08:05:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 08:05:53 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4LF5nF3001569 for ; Sat, 21 May 2005 08:05:50 -0700 Received: by zproxy.gmail.com with SMTP id 8so1174927nzo for ; Sat, 21 May 2005 08:05:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Pxf3tZikVwA8tlQk4XaTSCxgByqJRVclDSSWhf3T6kS8Rc70YaMbJhwMB/F6pRo0ENHbCss5mPuTJsnZiNb8uHtjcsoTaojZVj1tXwmOjsaWQv2wLXBU8UQFaOjb47Vv1t/sXIvzisVTy7VZqLz5/PtqBFiPRzQlqbEli3Y1UC8= Received: by 10.36.75.4 with SMTP id x4mr1143832nza; Sat, 21 May 2005 08:05:09 -0700 (PDT) Received: by 10.36.9.9 with HTTP; Sat, 21 May 2005 08:05:09 -0700 (PDT) Message-ID: <682bc30a050521080551b561d5@mail.gmail.com> Date: Sat, 21 May 2005 15:05:09 +0000 From: Julio Kriger Reply-To: Julio Kriger To: Stephen Hemminger Subject: Re: [Netem] [PATCH] (3/3) netem: allow random reordering Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org In-Reply-To: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10705_15871841.1116687909176" References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> X-archive-position: 1474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juliokriger@gmail.com Precedence: bulk X-list: netdev Content-Length: 11886 Lines: 267 ------=_Part_10705_15871841.1116687909176 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi! Here is a patch to 'tc' that add funcionality need to use the new feature reorder. Regards, Julio On 5/19/05, Stephen Hemminger wrote: > Enhance the reorder feature of netem to allow random percent to be reorde= red. > Has expected backwards compatibility behaviour. >=20 > Signed-off-by: Stephen Hemminger >=20 > Index: netem-2.6.12-rc4/include/linux/pkt_sched.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- netem-2.6.12-rc4.orig/include/linux/pkt_sched.h > +++ netem-2.6.12-rc4/include/linux/pkt_sched.h > @@ -427,6 +427,7 @@ enum > TCA_NETEM_UNSPEC, > TCA_NETEM_CORR, > TCA_NETEM_DELAY_DIST, > + TCA_NETEM_REORDER, > __TCA_NETEM_MAX, > }; >=20 > @@ -437,7 +438,7 @@ struct tc_netem_qopt > __u32 latency; /* added delay (us) */ > __u32 limit; /* fifo limit (packets) */ > __u32 loss; /* random packet loss (0=3Dnone ~0=3D100%= ) */ > - __u32 gap; /* re-ordering gap (0 for delay all) */ > + __u32 gap; /* re-ordering gap (0 for none) */ > __u32 duplicate; /* random packet dup (0=3Dnone ~0=3D100%= ) */ > __u32 jitter; /* random jitter in latency (us) */ > }; > @@ -449,6 +450,12 @@ struct tc_netem_corr > __u32 dup_corr; /* duplicate correlation */ > }; >=20 > +struct tc_netem_reorder > +{ > + __u32 probability; > + __u32 correlation; > +}; > + > #define NETEM_DIST_SCALE 8192 >=20 > #endif > Index: netem-2.6.12-rc4/net/sched/sch_netem.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- netem-2.6.12-rc4.orig/net/sched/sch_netem.c > +++ netem-2.6.12-rc4/net/sched/sch_netem.c > @@ -62,11 +62,12 @@ struct netem_sched_data { > u32 gap; > u32 jitter; > u32 duplicate; > + u32 reorder; >=20 > struct crndstate { > unsigned long last; > unsigned long rho; > - } delay_cor, loss_cor, dup_cor; > + } delay_cor, loss_cor, dup_cor, reorder_cor; >=20 > struct disttable { > u32 size; > @@ -185,18 +186,18 @@ static int netem_enqueue(struct sk_buff > * of the queue. > * gap =3D=3D 0 is special case for no-reordering. > */ > - if (q->gap =3D=3D 0 || q->counter !=3D q->gap) { > + if (q->gap =3D=3D 0 && q->counter < q->gap && > + q->reorder < get_crandom(&q->reorder_cor)) { > psched_time_t now; > PSCHED_GET_TIME(now); > - PSCHED_TADD2(now, > - tabledist(q->latency, q->jitter, &q->delay_c= or, q->delay_dist), > + PSCHED_TADD2(now, tabledist(q->latency, q->jitter, > + &q->delay_cor, q->delay_dist)= , > cb->time_to_send); > - > ++q->counter; > ret =3D q->qdisc->enqueue(skb, q->qdisc); > } else { > - q->counter =3D 0; > PSCHED_GET_TIME(cb->time_to_send); > + q->counter =3D 0; > ret =3D q->qdisc->ops->requeue(skb, q->qdisc); > } >=20 > @@ -351,6 +352,19 @@ static int get_correlation(struct Qdisc > return 0; > } >=20 > +static int get_reorder(struct Qdisc *sch, const struct rtattr *attr) > +{ > + struct netem_sched_data *q =3D qdisc_priv(sch); > + const struct tc_netem_reorder *r =3D RTA_DATA(attr); > + > + if (RTA_PAYLOAD(attr) !=3D sizeof(*r)) > + return -EINVAL; > + > + q->reorder =3D r->probability; > + init_crandom(&q->reorder_cor, r->correlation); > + return 0; > +} > + > static int netem_change(struct Qdisc *sch, struct rtattr *opt) > { > struct netem_sched_data *q =3D qdisc_priv(sch); > @@ -371,9 +385,15 @@ static int netem_change(struct Qdisc *sc > q->jitter =3D qopt->jitter; > q->limit =3D qopt->limit; > q->gap =3D qopt->gap; > + q->counter =3D 0; > q->loss =3D qopt->loss; > q->duplicate =3D qopt->duplicate; >=20 > + /* for compatiablity with earlier versions. > + * if gap is set, need to assume 100% probablity > + */ > + q->reorder =3D ~0; > + > /* Handle nested options after initial queue options. > * Should have put all options in nested format but too late now. > */ > @@ -395,6 +415,11 @@ static int netem_change(struct Qdisc *sc > if (ret) > return ret; > } > + if (tb[TCA_NETEM_REORDER-1]) { > + ret =3D get_reorder(sch, tb[TCA_NETEM_REORDER-1])= ; > + if (ret) > + return ret; > + } > } >=20 >=20 > @@ -412,7 +437,6 @@ static int netem_init(struct Qdisc *sch, > init_timer(&q->timer); > q->timer.function =3D netem_watchdog; > q->timer.data =3D (unsigned long) sch; > - q->counter =3D 0; >=20 > q->qdisc =3D qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); > if (!q->qdisc) { > @@ -444,6 +468,7 @@ static int netem_dump(struct Qdisc *sch, > struct rtattr *rta =3D (struct rtattr *) b; > struct tc_netem_qopt qopt; > struct tc_netem_corr cor; > + struct tc_netem_reorder reorder; >=20 > qopt.latency =3D q->latency; > qopt.jitter =3D q->jitter; > @@ -457,6 +482,11 @@ static int netem_dump(struct Qdisc *sch, > cor.loss_corr =3D q->loss_cor.rho; > cor.dup_corr =3D q->dup_cor.rho; > RTA_PUT(skb, TCA_NETEM_CORR, sizeof(cor), &cor); > + > + reorder.probability =3D q->reorder; > + reorder.correlation =3D q->reorder_cor.rho; > + RTA_PUT(skb, TCA_NETEM_REORDER, sizeof(reorder), &reorder); > + > rta->rta_len =3D skb->tail - b; >=20 > return skb->len; >=20 >=20 > _______________________________________________ > Netem mailing list > Netem@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/netem >=20 >=20 >=20 --=20 ---------------------------- Julio Kriger mailto:juliokriger@gmail.com ------=_Part_10705_15871841.1116687909176 Content-Type: application/octet-stream; name="tc_patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tc_patch" ZGlmZiAtTmF1ciBvcmlnL2lwcm91dGUyLTIuNi4xMS0wNTAzMzAvaW5jbHVkZS9saW51eC9wa3Rf c2NoZWQuaCBuZXcvaXByb3V0ZTItMi42LjExLTA1MDMzMC9pbmNsdWRlL2xpbnV4L3BrdF9zY2hl ZC5oCi0tLSBvcmlnL2lwcm91dGUyLTIuNi4xMS0wNTAzMzAvaW5jbHVkZS9saW51eC9wa3Rfc2No ZWQuaAkyMDA1LTA0LTAxIDE5OjU4OjExLjAwMDAwMDAwMCArMDAwMAorKysgbmV3L2lwcm91dGUy LTIuNi4xMS0wNTAzMzAvaW5jbHVkZS9saW51eC9wa3Rfc2NoZWQuaAkyMDA1LTA1LTIxIDExOjU5 OjEyLjAwMDAwMDAwMCArMDAwMApAQCAtNDI3LDYgKzQyNyw3IEBACiAJVENBX05FVEVNX1VOU1BF QywKIAlUQ0FfTkVURU1fQ09SUiwKIAlUQ0FfTkVURU1fREVMQVlfRElTVCwKKwlUQ0FfTkVURU1f UkVPUkRFUiwKIAlfX1RDQV9ORVRFTV9NQVgsCiB9OwogCkBAIC00MzcsNyArNDM4LDcgQEAKIAlf X3UzMglsYXRlbmN5OwkvKiBhZGRlZCBkZWxheSAodXMpICovCiAJX191MzIgICBsaW1pdDsJCS8q IGZpZm8gbGltaXQgKHBhY2tldHMpICovCiAJX191MzIJbG9zczsJCS8qIHJhbmRvbSBwYWNrZXQg bG9zcyAoMD1ub25lIH4wPTEwMCUpICovCi0JX191MzIJZ2FwOwkJLyogcmUtb3JkZXJpbmcgZ2Fw ICgwIGZvciBkZWxheSBhbGwpICovCisJX191MzIJZ2FwOwkJLyogcmUtb3JkZXJpbmcgZ2FwICgw IGZvciBub25lKSAqLwogCV9fdTMyICAgZHVwbGljYXRlOwkvKiByYW5kb20gcGFja2V0IGR1cCAg KDA9bm9uZSB+MD0xMDAlKSAqLwogCV9fdTMyCWppdHRlcjsJCS8qIHJhbmRvbSBqaXR0ZXIgaW4g bGF0ZW5jeSAodXMpICovCiB9OwpAQCAtNDQ5LDYgKzQ1MCwxMiBAQAogCV9fdTMyCWR1cF9jb3Jy OwkvKiBkdXBsaWNhdGUgY29ycmVsYXRpb24gICovCiB9OwogCitzdHJ1Y3QgdGNfbmV0ZW1fcmVv cmRlcgoreworCV9fdTMyICAgcHJvYmFiaWxpdHk7CisJX191MzIgICBjb3JyZWxhdGlvbjsKK307 CisKICNkZWZpbmUgTkVURU1fRElTVF9TQ0FMRQk4MTkyCiAKICNlbmRpZgpkaWZmIC1OYXVyIG9y aWcvaXByb3V0ZTItMi42LjExLTA1MDMzMC90Yy9xX25ldGVtLmMgbmV3L2lwcm91dGUyLTIuNi4x MS0wNTAzMzAvdGMvcV9uZXRlbS5jCi0tLSBvcmlnL2lwcm91dGUyLTIuNi4xMS0wNTAzMzAvdGMv cV9uZXRlbS5jCTIwMDUtMDQtMDEgMTk6NTg6MTEuMDAwMDAwMDAwICswMDAwCisrKyBuZXcvaXBy b3V0ZTItMi42LjExLTA1MDMzMC90Yy9xX25ldGVtLmMJMjAwNS0wNS0yMSAxMDo1ODozMy4wMDAw MDAwMDAgKzAwMDAKQEAgLTMzLDYgKzMzLDcgQEAKICIgICAgICAgICAgICAgICAgIFsgZHJvcCBQ RVJDRU5UIFtDT1JSRUxBVElPTl1dIFxuIiBcCiAiICAgICAgICAgICAgICAgICBbIGR1cGxpY2F0 ZSBQRVJDRU5UIFtDT1JSRUxBVElPTl1dXG4iIFwKICIJCSAgWyBkaXN0cmlidXRpb24ge3VuaWZv cm18bm9ybWFsfHBhcmV0b3xwYXJldG9ub3JtYWx9IF1cbiIgXAorIgkJICBbIHJlb3JkZXIgUEVS Q0VOVCBbQ09SUkVMQVRJT05dXVxuIiBcCiAiICAgICAgICAgICAgICAgICBbIGdhcCBQQUNLRVRT IF1cbiIpOwogfQogCkBAIC0xMjcsMTEgKzEyOCwxMyBAQAogCXN0cnVjdCBydGF0dHIgKnRhaWw7 CiAJc3RydWN0IHRjX25ldGVtX3FvcHQgb3B0OwogCXN0cnVjdCB0Y19uZXRlbV9jb3JyIGNvcjsK KwlzdHJ1Y3QgdGNfbmV0ZW1fcmVvcmRlciByZW9yZGVyOwogCV9fczE2IGRpc3RfZGF0YVtNQVhE SVNUXTsKIAogCW1lbXNldCgmb3B0LCAwLCBzaXplb2Yob3B0KSk7CiAJb3B0LmxpbWl0ID0gMTAw MDsKIAltZW1zZXQoJmNvciwgMCwgc2l6ZW9mKGNvcikpOworCW1lbXNldCgmcmVvcmRlciwgMCwg c2l6ZW9mKHJlb3JkZXIpKTsKIAogCXdoaWxlIChhcmdjID4gMCkgewogCQlpZiAobWF0Y2hlcygq YXJndiwgImxpbWl0IikgPT0gMCkgewpAQCAtMTk3LDYgKzIwMCwxOSBAQAogCQkJCQlyZXR1cm4g LTE7CiAJCQkJfQogCQkJfQorCQl9IGVsc2UgaWYgKG1hdGNoZXMoKmFyZ3YsICJyZW9yZGVyIikg PT0gMCkgeworCQkJTkVYVF9BUkcoKTsKKwkJCWlmIChnZXRfcGVyY2VudCgmcmVvcmRlci5wcm9i YWJpbGl0eSwgKmFyZ3YpKSB7CisJCQkJZXhwbGFpbjEoInJlb3JkZXIiKTsKKwkJCQlyZXR1cm4g LTE7CisJCQl9CisJCQlpZiAoTkVYVF9JU19OVU1CRVIoKSkgeworCQkJCU5FWFRfQVJHKCk7CisJ CQkJaWYgKGdldF9wZXJjZW50KCZyZW9yZGVyLmNvcnJlbGF0aW9uLCAqYXJndikpIHsKKwkJCQkJ ZXhwbGFpbjEoInJlb3JkZXIiKTsKKwkJCQkJcmV0dXJuIC0xOworCQkJCX0KKwkJCX0KIAkJfSBl bHNlIGlmIChtYXRjaGVzKCphcmd2LCAiZGlzdHJpYnV0aW9uIikgPT0gMCkgewogCQkJTkVYVF9B UkcoKTsKIAkJCWRpc3Rfc2l6ZSA9IGdldF9kaXN0cmlidXRpb24oKmFyZ3YsIGRpc3RfZGF0YSk7 CkBAIC0yMTcsNiArMjMzLDcgQEAKIAogCWFkZGF0dHJfbChuLCAxMDI0LCBUQ0FfT1BUSU9OUywg Jm9wdCwgc2l6ZW9mKG9wdCkpOwogCWFkZGF0dHJfbChuLCAxMDI0LCBUQ0FfTkVURU1fQ09SUiwg JmNvciwgc2l6ZW9mKGNvcikpOworCWFkZGF0dHJfbChuLCAxMDI0LCBUQ0FfTkVURU1fUkVPUkRF UiwgJnJlb3JkZXIsIHNpemVvZihyZW9yZGVyKSk7CiAKIAlpZiAoZGlzdF9zaXplID4gMCkgewog CQlhZGRhdHRyX2wobiwgMzI3NjgsIFRDQV9ORVRFTV9ERUxBWV9ESVNULApAQCAtMjI5LDcgKzI0 Niw4IEBACiBzdGF0aWMgaW50IG5ldGVtX3ByaW50X29wdChzdHJ1Y3QgcWRpc2NfdXRpbCAqcXUs IEZJTEUgKmYsIHN0cnVjdCBydGF0dHIgKm9wdCkKIHsKIAljb25zdCBzdHJ1Y3QgdGNfbmV0ZW1f Y29yciAqY29yID0gTlVMTDsKLQlzdHJ1Y3QgdGNfbmV0ZW1fcW9wdCBxb3B0OworCWNvbnN0IHN0 cnVjdCB0Y19uZXRlbV9yZW9yZGVyICpyZW9yZGVyID0gTlVMTDsKKwlzdHJ1Y3QgdGNfbmV0ZW1f cW9wdCBxb3B0OwkKIAlpbnQgbGVuID0gUlRBX1BBWUxPQUQob3B0KSAtIHNpemVvZihxb3B0KTsK IAlTUFJJTlRfQlVGKGIxKTsKIApAQCAtMjUyLDYgKzI3MCwxMiBAQAogCQkJCXJldHVybiAtMTsK IAkJCWNvciA9IFJUQV9EQVRBKHRiW1RDQV9ORVRFTV9DT1JSXSk7CiAJCX0KKwkJCisJCWlmICh0 YltUQ0FfTkVURU1fUkVPUkRFUl0pIHsKKwkJCWlmIChSVEFfUEFZTE9BRCh0YltUQ0FfTkVURU1f UkVPUkRFUl0pIDwgc2l6ZW9mKCpyZW9yZGVyKSkKKwkJCQlyZXR1cm4gLTE7CisJCQlyZW9yZGVy ID0gUlRBX0RBVEEodGJbVENBX05FVEVNX1JFT1JERVJdKTsKKwkJfQogCX0KIAogCWZwcmludGYo ZiwgImxpbWl0ICVkIiwgcW9wdC5saW1pdCk7CkBAIC0yNzksNiArMzAzLDEzIEBACiAJCQlmcHJp bnRmKGYsICIgJXMiLCBzcHJpbnRfcGVyY2VudChjb3ItPmR1cF9jb3JyLCBiMSkpOwogCX0KIAor CWlmIChyZW9yZGVyICYmIHJlb3JkZXItPnByb2JhYmlsaXR5KSB7CisJCWZwcmludGYoZiwgIiBy ZW9yZGVyICVzIiwKKwkJCQlzcHJpbnRfcGVyY2VudChyZW9yZGVyLT5wcm9iYWJpbGl0eSwgYjEp KTsKKwkJaWYgKHJlb3JkZXIgJiYgcmVvcmRlci0+Y29ycmVsYXRpb24pCisJCQlmcHJpbnRmKGYs ICIgJXMiLCBzcHJpbnRfcGVyY2VudChyZW9yZGVyLT5jb3JyZWxhdGlvbiwgYjEpKTsKKwl9CisK IAlpZiAocW9wdC5nYXApCiAJCWZwcmludGYoZiwgIiBnYXAgJWx1IiwgKHVuc2lnbmVkIGxvbmcp cW9wdC5nYXApOwogCg== ------=_Part_10705_15871841.1116687909176-- From adobriyan@gmail.com Sat May 21 08:37:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 08:37:28 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4LFbPF3006726 for ; Sat, 21 May 2005 08:37:25 -0700 Received: by wproxy.gmail.com with SMTP id 69so231350wri for ; Sat, 21 May 2005 08:36:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=OmylFywTWJKGUQAMxvsIBK6JZ66Y/i9G1OHEMBbGJaNUpp7SSV2yCQW7cyU3QcvRTSsVzU8Jr14rGp9UxIPi3vtCo/9zRXmkl7k2JxR8GBDwQr+AuTlZPv3cYE1DAzLNhCheJZUnGAzbUQVODJ83TT3F+UM17HWtfn7VzJpADGU= Received: by 10.54.81.12 with SMTP id e12mr1852885wrb; Sat, 21 May 2005 08:36:44 -0700 (PDT) Received: from mipter.zuzino.mipt.ru ([217.10.38.130]) by mx.gmail.com with ESMTP id g3sm668962wra.2005.05.21.08.36.44; Sat, 21 May 2005 08:36:44 -0700 (PDT) From: Alexey Dobriyan To: netdev@oss.sgi.com Subject: [PATCH] netdevice.h: be'ify packet_type Date: Sat, 21 May 2005 19:40:59 +0400 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505211940.59240.adobriyan@gmail.com> X-archive-position: 1475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: netdev Content-Length: 806 Lines: 21 Everybody does struct packet_type foo_packet_type = { .type = __constant_htons(ETH_P_FOO); }; 5 introduced warnings will be properly fixed later. Signed-off-by: Alexey Dobriyan --- linux-20050521140543-000/include/linux/netdevice.h 2005-05-21 14:12:24.000000000 +0400 +++ linux-20050521140543-001/include/linux/netdevice.h 2005-05-21 17:14:26.000000000 +0400 @@ -503,7 +503,7 @@ static inline void *netdev_priv(struct n #define SET_NETDEV_DEV(net, pdev) ((net)->class_dev.dev = (pdev)) struct packet_type { - unsigned short type; /* This is really htons(ether_type). */ + __be16 type; /* This is really htons(ether_type). */ struct net_device *dev; /* NULL is wildcarded here */ int (*func) (struct sk_buff *, struct net_device *, struct packet_type *); From herbert@gondor.apana.org.au Sat May 21 12:50:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 12:50:45 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4LJoYF3018818 for ; Sat, 21 May 2005 12:50:35 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DZZye-00081Z-00; Sun, 22 May 2005 05:49:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DZZyX-0002v0-00; Sun, 22 May 2005 05:49:33 +1000 Date: Sun, 22 May 2005 05:49:32 +1000 To: Christophe Saout Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, YOSHIFUJI Hideaki , "David S. Miller" Subject: Re: [BUG 2.6.12-rc4] IPv6 xfrm tunnel oops with large packets Message-ID: <20050521194932.GA10959@gondor.apana.org.au> References: <1116702611.14509.10.camel@leto.cs.pocnet.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <1116702611.14509.10.camel@leto.cs.pocnet.net> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1120 Lines: 43 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, May 21, 2005 at 07:10:11PM +0000, Christophe Saout wrote: > > The oops occurs in line 391 in net/ipv6/icmp.c: > > > idev = in6_dev_get(skb->dev); Here is a minimal fix. Signed-off-by: Herbert Xu I wonder why I've never seen it before. BTW, icmpv6_send seems to ignore its dev argument altogether. Any reason why we can't just use it instead of skb->dev? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- a/net/ipv6/xfrm6_output.c +++ b/net/ipv6/xfrm6_output.c @@ -84,6 +84,7 @@ static int xfrm6_tunnel_check_size(struc mtu = IPV6_MIN_MTU; if (skb->len > mtu) { + skb->dev = dst->dev; icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev); ret = -EMSGSIZE; } --HlL+5n6rz5pIUxbD-- From netdev@nospam.otaku42.de Sat May 21 13:06:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 13:06:35 -0700 (PDT) Received: from legolas.otaku42.de (legolas.otaku42.de [217.24.0.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4LK6TF3019992 for ; Sat, 21 May 2005 13:06:30 -0700 Received: from dsl-084-058-129-148.arcor-ip.net ([84.58.129.148] helo=[192.168.2.42] ident=otaku) by legolas.otaku42.de with asmtp (Exim 4.20 and XAMS 0.0.11) id 1DZaEH-0003pY-Rt for netdev@oss.sgi.com; Sat, 21 May 2005 22:05:49 +0200 Message-ID: <428F949C.8080707@otaku42.de> Date: Sat, 21 May 2005 22:05:48 +0200 From: Michael Renzmann User-Agent: Mozilla Thunderbird 1.0 (X11/20050205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Network driver behaviour when loosing link X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: netdev@nospam.otaku42.de Precedence: bulk X-list: netdev Content-Length: 789 Lines: 22 Hi all. I'm playing with a network driver and came across one thing I'd like to ask something about. Let's assume a driver detects a link status change (for example, the link is dropped). I would have expected that the driver should signal the change via netif_carrier_on/_off (if used at all) and tell the kernel to stop/resume sending packets to the driver (via netif_wake_queue/netif_stop_queue). When checking several drivers I found some that call netif_[wake|stop]_queue (e100, e1000), while others don't (natsemi, tg3). Hence the question: what is the recommended behaviour in such a case? Is it ok to call netif_[stop|wake]_queue? How about adjusting the IFF_RUNNING flag accordingly? Is there any documentation available on this topic? Thanks in advance. Bye, Mike From yoshfuji@linux-ipv6.org Sat May 21 13:16:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 13:16:22 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4LKGIF3020814 for ; Sat, 21 May 2005 13:16:18 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id B9D5433CC2; Sun, 22 May 2005 05:18:25 +0900 (JST) Date: Sun, 22 May 2005 05:18:17 +0900 (JST) Message-Id: <20050522.051817.122678688.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: christophe@saout.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [BUG 2.6.12-rc4] IPv6 xfrm tunnel oops with large packets From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050521194932.GA10959@gondor.apana.org.au> References: <1116702611.14509.10.camel@leto.cs.pocnet.net> <20050521194932.GA10959@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 786 Lines: 24 In article <20050521194932.GA10959@gondor.apana.org.au> (at Sun, 22 May 2005 05:49:32 +1000), Herbert Xu says: > On Sat, May 21, 2005 at 07:10:11PM +0000, Christophe Saout wrote: > > > > The oops occurs in line 391 in net/ipv6/icmp.c: > > > > > idev = in6_dev_get(skb->dev); > > Here is a minimal fix. > > Signed-off-by: Herbert Xu Acked-by: Hideaki YOSHIFUJI > BTW, icmpv6_send seems to ignore its dev argument altogether. > Any reason why we can't just use it instead of skb->dev? (After looking into icmpv6_send() usages,) I don't know the reason why we needed the last argument "dev". It seems that we already had it at the time of 2.2.16. Probably, we can remove it. --yoshfuji From christophe@saout.de Sat May 21 14:50:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 14:50:16 -0700 (PDT) Received: from websrv2.werbeagentur-aufwind.de (websrv2.werbeagentur-aufwind.de [213.239.197.240]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4LLoBF3023955 for ; Sat, 21 May 2005 14:50:12 -0700 Received: (qmail 1715 invoked by uid 1003); 21 May 2005 23:49:30 +0200 Received: from 82.82.76.166 by websrv2 (envelope-from , uid 201) with qmail-scanner-1.25st (clamdscan: 0.85.1/888. spamassassin: 3.0.3. perlscan: 1.25st. Clear:RC:0(82.82.76.166):SA:0(-0.2/6.0):. Processed in 2.844371 secs); 21 May 2005 21:49:30 -0000 Received: from dsl-082-082-076-166.arcor-ip.net (HELO mail.cs.pocnet.net) (smtp@werbeagentur-aufwind.de@82.82.76.166) by websrv2.werbeagentur-aufwind.de with AES256-SHA encrypted SMTP; 21 May 2005 23:49:27 +0200 Received: (qmail 26797 invoked from network); 21 May 2005 23:49:25 +0200 Received: from leto.cs.pocnet.net (192.168.80.6) by server.cs.pocnet.net with RC4-MD5 encrypted SMTP; 21 May 2005 23:49:25 +0200 Subject: Re: [BUG 2.6.12-rc4] IPv6 xfrm tunnel oops with large packets From: Christophe Saout To: Herbert Xu Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, YOSHIFUJI Hideaki , "David S. Miller" In-Reply-To: <20050521194932.GA10959@gondor.apana.org.au> References: <1116702611.14509.10.camel@leto.cs.pocnet.net> <20050521194932.GA10959@gondor.apana.org.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-r3YcTXpdr+7HH7VyQ4I7" Date: Sat, 21 May 2005 23:49:24 +0200 Message-Id: <1116712164.10858.0.camel@leto.cs.pocnet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 1479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christophe@saout.de Precedence: bulk X-list: netdev Content-Length: 577 Lines: 26 --=-r3YcTXpdr+7HH7VyQ4I7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Am Sonntag, den 22.05.2005, 05:49 +1000 schrieb Herbert Xu: > Here is a minimal fix. Yes, it fixes the problem. --=-r3YcTXpdr+7HH7VyQ4I7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCj6zkZCYBcts5dM0RAk8OAJ9DRp4LZQvzKUY9Kux3Jv3g8ixs/QCfcFiI U7OQVPnnX7sufwbHRT9YkXk= =5+Ib -----END PGP SIGNATURE----- --=-r3YcTXpdr+7HH7VyQ4I7-- From romieu@fr.zoreil.com Sat May 21 15:44:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 15:44:26 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4LMiJF3025902 for ; Sat, 21 May 2005 15:44:20 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4LMe5Yl006854; Sun, 22 May 2005 00:40:05 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4LMdx4B006853; Sun, 22 May 2005 00:39:59 +0200 Date: Sun, 22 May 2005 00:39:59 +0200 From: Francois Romieu To: Jeff Garzik Cc: Grant Grundler , akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree Message-ID: <20050521223959.GA4337@electric-eye.fr.zoreil.com> References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4288CE51.1050703@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 11008 Lines: 341 Jeff Garzik : [tulip_media_select] > 1) called from timer context, from the media poll timer > > 2) called from spin_lock_irqsave() context, in the ->tx_timeout hook. > > The first case can be fixed by moved all the timer code to a workqueue. > Then when the existing timer fires, kick the workqueue. > > The second case can be fixed by kicking the workqueue upon tx_timeout > (which is the reason why I did not suggest queue_delayed_work() use). First try below. It only moves tulip_select_media() to process context. The original patch (with s/udelay/msleep/ or such) is not included. Patch applies/compiles against 2.6.12-rc4. Comments/suggestions ? diff -puN a/drivers/net/tulip/tulip.h~tulip-000 b/drivers/net/tulip/tulip.h --- a/drivers/net/tulip/tulip.h~tulip-000 2005-05-21 22:30:08.133891956 +0200 +++ b/drivers/net/tulip/tulip.h 2005-05-22 00:18:45.598682086 +0200 @@ -46,6 +46,7 @@ struct tulip_chip_table { int valid_intrs; /* CSR7 interrupt enable settings */ int flags; void (*media_timer) (unsigned long data); + void (*media_task) (void *); }; @@ -368,6 +369,7 @@ struct tulip_private { unsigned int medialock:1; /* Don't sense media type. */ unsigned int mediasense:1; /* Media sensing in progress. */ unsigned int nway:1, nwayset:1; /* 21143 internal NWay. */ + unsigned int timeout_recovery: 1; unsigned int csr0; /* CSR0 setting. */ unsigned int csr6; /* Current CSR6 control settings. */ unsigned char eeprom[EEPROM_SIZE]; /* Serial EEPROM contents. */ @@ -386,6 +388,7 @@ struct tulip_private { void __iomem *base_addr; int csr12_shadow; int pad0; /* Used for 8-byte alignment */ + struct work_struct media_work; }; @@ -400,7 +403,7 @@ struct eeprom_fixup { /* 21142.c */ extern u16 t21142_csr14[]; -void t21142_timer(unsigned long data); +void t21142_media_task(void *data); void t21142_start_nway(struct net_device *dev); void t21142_lnk_change(struct net_device *dev, int csr5); @@ -438,7 +441,7 @@ void pnic_lnk_change(struct net_device * void pnic_timer(unsigned long data); /* timer.c */ -void tulip_timer(unsigned long data); +void tulip_media_task(void *data); void mxic_timer(unsigned long data); void comet_timer(unsigned long data); @@ -490,4 +493,13 @@ static inline void tulip_restart_rxtx(st tulip_start_rxtx(tp); } +static inline void tulip_tx_timeout_complete(struct tulip_private *tp, void __iomem *ioaddr) +{ + /* Stop and restart the chip's Tx processes. */ + tulip_restart_rxtx(tp); + /* Trigger an immediate transmit demand. */ + iowrite32(0, ioaddr + CSR1); + + tp->stats.tx_errors++; +} #endif /* __NET_TULIP_H__ */ diff -puN a/drivers/net/tulip/tulip_core.c~tulip-000 b/drivers/net/tulip/tulip_core.c --- a/drivers/net/tulip/tulip_core.c~tulip-000 2005-05-21 20:57:38.385293188 +0200 +++ b/drivers/net/tulip/tulip_core.c 2005-05-22 00:24:29.144946592 +0200 @@ -132,6 +132,16 @@ int tulip_debug = 1; #endif +static struct workqueue_struct *ktulipd_workqueue; + +static void tulip_timer(unsigned long data) +{ + struct net_device *dev = (struct net_device *)data; + struct tulip_private *tp = netdev_priv(dev); + + if (likely(netif_running(dev))) + queue_work(ktulipd_workqueue, &tp->media_work); +} /* * This table use during operation for capabilities and media timer. @@ -145,63 +155,65 @@ struct tulip_chip_table tulip_tbl[] = { /* DC21140 */ { "Digital DS21140 Tulip", 128, 0x0001ebef, - HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_PCI_MWI, tulip_timer }, + HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_PCI_MWI, tulip_timer, + tulip_media_task }, /* DC21142, DC21143 */ { "Digital DS21143 Tulip", 128, 0x0801fbff, HAS_MII | HAS_MEDIA_TABLE | ALWAYS_CHECK_MII | HAS_ACPI | HAS_NWAY - | HAS_INTR_MITIGATION | HAS_PCI_MWI, t21142_timer }, + | HAS_INTR_MITIGATION | HAS_PCI_MWI, tulip_timer, t21142_media_task }, /* LC82C168 */ { "Lite-On 82c168 PNIC", 256, 0x0001fbef, - HAS_MII | HAS_PNICNWAY, pnic_timer }, + HAS_MII | HAS_PNICNWAY, pnic_timer, }, /* MX98713 */ { "Macronix 98713 PMAC", 128, 0x0001ebef, - HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM, mxic_timer }, + HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM, mxic_timer, }, /* MX98715 */ { "Macronix 98715 PMAC", 256, 0x0001ebef, - HAS_MEDIA_TABLE, mxic_timer }, + HAS_MEDIA_TABLE, mxic_timer, }, /* MX98725 */ { "Macronix 98725 PMAC", 256, 0x0001ebef, - HAS_MEDIA_TABLE, mxic_timer }, + HAS_MEDIA_TABLE, mxic_timer, }, /* AX88140 */ { "ASIX AX88140", 128, 0x0001fbff, HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | MC_HASH_ONLY - | IS_ASIX, tulip_timer }, + | IS_ASIX, tulip_timer, tulip_media_task }, /* PNIC2 */ { "Lite-On PNIC-II", 256, 0x0801fbff, - HAS_MII | HAS_NWAY | HAS_8023X | HAS_PCI_MWI, pnic2_timer }, + HAS_MII | HAS_NWAY | HAS_8023X | HAS_PCI_MWI, pnic2_timer, }, /* COMET */ { "ADMtek Comet", 256, 0x0001abef, - HAS_MII | MC_HASH_ONLY | COMET_MAC_ADDR, comet_timer }, + HAS_MII | MC_HASH_ONLY | COMET_MAC_ADDR, comet_timer, }, /* COMPEX9881 */ { "Compex 9881 PMAC", 128, 0x0001ebef, - HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM, mxic_timer }, + HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM, mxic_timer, }, /* I21145 */ { "Intel DS21145 Tulip", 128, 0x0801fbff, HAS_MII | HAS_MEDIA_TABLE | ALWAYS_CHECK_MII | HAS_ACPI - | HAS_NWAY | HAS_PCI_MWI, t21142_timer }, + | HAS_NWAY | HAS_PCI_MWI, tulip_timer, t21142_media_task }, /* DM910X */ { "Davicom DM9102/DM9102A", 128, 0x0001ebef, HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI, - tulip_timer }, + tulip_timer, tulip_media_task }, /* RS7112 */ { "Conexant LANfinity", 256, 0x0001ebef, - HAS_MII | HAS_ACPI, tulip_timer }, + HAS_MII | HAS_ACPI, tulip_timer, tulip_media_task }, /* ULi526X */ { "ULi M5261/M5263", 128, 0x0001ebef, - HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI, tulip_timer }, + HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI, tulip_timer, + tulip_media_task }, }; @@ -265,6 +277,17 @@ static void set_rx_mode(struct net_devic static void poll_tulip(struct net_device *dev); #endif +static inline int tulip_create_workqueue(void) +{ + ktulipd_workqueue = create_workqueue("ktulipd"); + return ktulipd_workqueue ? 0 : -ENOMEM; +} + +static inline void tulip_destroy_workqueue(void) +{ + destroy_workqueue(ktulipd_workqueue); +} + static void tulip_set_power_state (struct tulip_private *tp, int sleep, int snooze) { @@ -526,20 +549,9 @@ static void tulip_tx_timeout(struct net_ "SIA %8.8x %8.8x %8.8x %8.8x, resetting...\n", dev->name, ioread32(ioaddr + CSR5), ioread32(ioaddr + CSR12), ioread32(ioaddr + CSR13), ioread32(ioaddr + CSR14), ioread32(ioaddr + CSR15)); - if ( ! tp->medialock && tp->mtable) { - do - --tp->cur_index; - while (tp->cur_index >= 0 - && (tulip_media_cap[tp->mtable->mleaf[tp->cur_index].media] - & MediaIsFD)); - if (--tp->cur_index < 0) { - /* We start again, but should instead look for default. */ - tp->cur_index = tp->mtable->leafcount - 1; - } - tulip_select_media(dev, 0); - printk(KERN_WARNING "%s: transmit timed out, switching to %s " - "media.\n", dev->name, medianame[dev->if_port]); - } + tp->timeout_recovery = 1; + queue_work(ktulipd_workqueue, &tp->media_work); + goto out_unlock; } else if (tp->chip_id == PNIC2) { printk(KERN_WARNING "%s: PNIC2 transmit timed out, status %8.8x, " "CSR6/7 %8.8x / %8.8x CSR12 %8.8x, resetting...\n", @@ -579,14 +591,9 @@ static void tulip_tx_timeout(struct net_ } #endif - /* Stop and restart the chip's Tx processes . */ - - tulip_restart_rxtx(tp); - /* Trigger an immediate transmit demand. */ - iowrite32(0, ioaddr + CSR1); - - tp->stats.tx_errors++; + tulip_tx_timeout_complete(tp, ioaddr); +out_unlock: spin_unlock_irqrestore (&tp->lock, flags); dev->trans_start = jiffies; netif_wake_queue (dev); @@ -736,6 +743,8 @@ static void tulip_down (struct net_devic void __iomem *ioaddr = tp->base_addr; unsigned long flags; + flush_workqueue(ktulipd_workqueue); + del_timer_sync (&tp->timer); #ifdef CONFIG_TULIP_NAPI del_timer_sync (&tp->oom_timer); @@ -1408,6 +1417,8 @@ static int __devinit tulip_init_one (str tp->timer.data = (unsigned long)dev; tp->timer.function = tulip_tbl[tp->chip_id].media_timer; + INIT_WORK(&tp->media_work, tulip_tbl[tp->chip_id].media_task, dev); + dev->base_addr = (unsigned long)ioaddr; #ifdef CONFIG_TULIP_MWI @@ -1838,6 +1849,8 @@ static struct pci_driver tulip_driver = static int __init tulip_init (void) { + int ret; + #ifdef MODULE printk (KERN_INFO "%s", version); #endif @@ -1846,14 +1859,23 @@ static int __init tulip_init (void) tulip_rx_copybreak = rx_copybreak; tulip_max_interrupt_work = max_interrupt_work; + ret = tulip_create_workqueue(); + if (ret < 0) + goto out; + /* probe for and init boards */ - return pci_module_init (&tulip_driver); + ret = pci_module_init(&tulip_driver); + if (ret < 0) + tulip_destroy_workqueue(); +out: + return ret; } static void __exit tulip_cleanup (void) { pci_unregister_driver (&tulip_driver); + tulip_destroy_workqueue(); } diff -puN a/drivers/net/tulip/21142.c~tulip-000 b/drivers/net/tulip/21142.c --- a/drivers/net/tulip/21142.c~tulip-000 2005-05-21 20:57:37.978358686 +0200 +++ b/drivers/net/tulip/21142.c 2005-05-22 00:10:21.717431845 +0200 @@ -26,9 +26,9 @@ static u16 t21142_csr15[] = { 0x0008, 0x /* Handle the 21143 uniquely: do autoselect with NWay, not the EEPROM list of available transceivers. */ -void t21142_timer(unsigned long data) +void t21142_media_task(void *data) { - struct net_device *dev = (struct net_device *)data; + struct net_device *dev = data; struct tulip_private *tp = netdev_priv(dev); void __iomem *ioaddr = tp->base_addr; int csr12 = ioread32(ioaddr + CSR12); diff -puN a/drivers/net/tulip/timer.c~tulip-000 b/drivers/net/tulip/timer.c --- a/drivers/net/tulip/timer.c~tulip-000 2005-05-21 20:57:38.251314753 +0200 +++ b/drivers/net/tulip/timer.c 2005-05-22 00:24:05.889719386 +0200 @@ -18,13 +18,14 @@ #include "tulip.h" -void tulip_timer(unsigned long data) +void tulip_media_task(void *data) { - struct net_device *dev = (struct net_device *)data; + struct net_device *dev = data; struct tulip_private *tp = netdev_priv(dev); void __iomem *ioaddr = tp->base_addr; u32 csr12 = ioread32(ioaddr + CSR12); int next_tick = 2*HZ; + unsigned long flags; if (tulip_debug > 2) { printk(KERN_DEBUG "%s: Media selection tick, %s, status %8.8x mode" @@ -127,6 +128,14 @@ void tulip_timer(unsigned long data) } break; } + + spin_lock_irqsave (&tp->lock, flags); + if (tp->timeout_recovery) { + tp->timeout_recovery = 0; + tulip_tx_timeout_complete(tp, ioaddr); + } + spin_unlock_irqrestore (&tp->lock, flags); + /* mod_timer synchronizes us with potential add_timer calls * from interrupts. */ _ From juliokriger@gmail.com Sat May 21 16:01:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 16:01:26 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4LN1MF3027006 for ; Sat, 21 May 2005 16:01:23 -0700 Received: by zproxy.gmail.com with SMTP id 8so1233626nzo for ; Sat, 21 May 2005 16:00:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f2NedRbEy4htnr6zth+C3KiblZVi7j8Sw2m6ZpMjKw8Tx4gKEI04MqUVPxcCypgO2ORTTZhbWi9RCTTle3GxflxJ6ZLF3oZlRoEYJN43MaA0qRCxt4NmIF3qvd7jCEaHic/XmzzKUQfPn+FR36tEKKWQU2WRy9U4cWLReVWz54o= Received: by 10.36.66.4 with SMTP id o4mr1188612nza; Sat, 21 May 2005 16:00:41 -0700 (PDT) Received: by 10.36.9.9 with HTTP; Sat, 21 May 2005 16:00:41 -0700 (PDT) Message-ID: <682bc30a05052116005bc813a2@mail.gmail.com> Date: Sat, 21 May 2005 23:00:41 +0000 From: Julio Kriger Reply-To: Julio Kriger To: Stephen Hemminger Subject: Re: [Netem] [PATCH] (3/3) netem: allow random reordering Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org In-Reply-To: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4LN1MF3027006 X-archive-position: 1481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juliokriger@gmail.com Precedence: bulk X-list: netdev Content-Length: 6500 Lines: 194 Hi, I have a doubt about about this lines (#90) if (q->gap == 0 && q->counter < q->gap && q->reorder < get_crandom(&q->reorder_cor)) { I could not achieve reordering. I've set gap and reordering values but did'nt success. Then I've modified those lines to this one if( 0 < q->reorder && q->reorder < get_crandom(&q->reorder_cor) ) { and I achieve reordering (I test it pinging localhost). Is this correct or I'm doing something wrong? Regards, Julio On 5/19/05, Stephen Hemminger wrote: > Enhance the reorder feature of netem to allow random percent to be reordered. > Has expected backwards compatibility behaviour. > > Signed-off-by: Stephen Hemminger > > Index: netem-2.6.12-rc4/include/linux/pkt_sched.h > =================================================================== > --- netem-2.6.12-rc4.orig/include/linux/pkt_sched.h > +++ netem-2.6.12-rc4/include/linux/pkt_sched.h > @@ -427,6 +427,7 @@ enum > TCA_NETEM_UNSPEC, > TCA_NETEM_CORR, > TCA_NETEM_DELAY_DIST, > + TCA_NETEM_REORDER, > __TCA_NETEM_MAX, > }; > > @@ -437,7 +438,7 @@ struct tc_netem_qopt > __u32 latency; /* added delay (us) */ > __u32 limit; /* fifo limit (packets) */ > __u32 loss; /* random packet loss (0=none ~0=100%) */ > - __u32 gap; /* re-ordering gap (0 for delay all) */ > + __u32 gap; /* re-ordering gap (0 for none) */ > __u32 duplicate; /* random packet dup (0=none ~0=100%) */ > __u32 jitter; /* random jitter in latency (us) */ > }; > @@ -449,6 +450,12 @@ struct tc_netem_corr > __u32 dup_corr; /* duplicate correlation */ > }; > > +struct tc_netem_reorder > +{ > + __u32 probability; > + __u32 correlation; > +}; > + > #define NETEM_DIST_SCALE 8192 > > #endif > Index: netem-2.6.12-rc4/net/sched/sch_netem.c > =================================================================== > --- netem-2.6.12-rc4.orig/net/sched/sch_netem.c > +++ netem-2.6.12-rc4/net/sched/sch_netem.c > @@ -62,11 +62,12 @@ struct netem_sched_data { > u32 gap; > u32 jitter; > u32 duplicate; > + u32 reorder; > > struct crndstate { > unsigned long last; > unsigned long rho; > - } delay_cor, loss_cor, dup_cor; > + } delay_cor, loss_cor, dup_cor, reorder_cor; > > struct disttable { > u32 size; > @@ -185,18 +186,18 @@ static int netem_enqueue(struct sk_buff > * of the queue. > * gap == 0 is special case for no-reordering. > */ > - if (q->gap == 0 || q->counter != q->gap) { > + if (q->gap == 0 && q->counter < q->gap && > + q->reorder < get_crandom(&q->reorder_cor)) { > psched_time_t now; > PSCHED_GET_TIME(now); > - PSCHED_TADD2(now, > - tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist), > + PSCHED_TADD2(now, tabledist(q->latency, q->jitter, > + &q->delay_cor, q->delay_dist), > cb->time_to_send); > - > ++q->counter; > ret = q->qdisc->enqueue(skb, q->qdisc); > } else { > - q->counter = 0; > PSCHED_GET_TIME(cb->time_to_send); > + q->counter = 0; > ret = q->qdisc->ops->requeue(skb, q->qdisc); > } > > @@ -351,6 +352,19 @@ static int get_correlation(struct Qdisc > return 0; > } > > +static int get_reorder(struct Qdisc *sch, const struct rtattr *attr) > +{ > + struct netem_sched_data *q = qdisc_priv(sch); > + const struct tc_netem_reorder *r = RTA_DATA(attr); > + > + if (RTA_PAYLOAD(attr) != sizeof(*r)) > + return -EINVAL; > + > + q->reorder = r->probability; > + init_crandom(&q->reorder_cor, r->correlation); > + return 0; > +} > + > static int netem_change(struct Qdisc *sch, struct rtattr *opt) > { > struct netem_sched_data *q = qdisc_priv(sch); > @@ -371,9 +385,15 @@ static int netem_change(struct Qdisc *sc > q->jitter = qopt->jitter; > q->limit = qopt->limit; > q->gap = qopt->gap; > + q->counter = 0; > q->loss = qopt->loss; > q->duplicate = qopt->duplicate; > > + /* for compatiablity with earlier versions. > + * if gap is set, need to assume 100% probablity > + */ > + q->reorder = ~0; > + > /* Handle nested options after initial queue options. > * Should have put all options in nested format but too late now. > */ > @@ -395,6 +415,11 @@ static int netem_change(struct Qdisc *sc > if (ret) > return ret; > } > + if (tb[TCA_NETEM_REORDER-1]) { > + ret = get_reorder(sch, tb[TCA_NETEM_REORDER-1]); > + if (ret) > + return ret; > + } > } > > > @@ -412,7 +437,6 @@ static int netem_init(struct Qdisc *sch, > init_timer(&q->timer); > q->timer.function = netem_watchdog; > q->timer.data = (unsigned long) sch; > - q->counter = 0; > > q->qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); > if (!q->qdisc) { > @@ -444,6 +468,7 @@ static int netem_dump(struct Qdisc *sch, > struct rtattr *rta = (struct rtattr *) b; > struct tc_netem_qopt qopt; > struct tc_netem_corr cor; > + struct tc_netem_reorder reorder; > > qopt.latency = q->latency; > qopt.jitter = q->jitter; > @@ -457,6 +482,11 @@ static int netem_dump(struct Qdisc *sch, > cor.loss_corr = q->loss_cor.rho; > cor.dup_corr = q->dup_cor.rho; > RTA_PUT(skb, TCA_NETEM_CORR, sizeof(cor), &cor); > + > + reorder.probability = q->reorder; > + reorder.correlation = q->reorder_cor.rho; > + RTA_PUT(skb, TCA_NETEM_REORDER, sizeof(reorder), &reorder); > + > rta->rta_len = skb->tail - b; > > return skb->len; > > > _______________________________________________ > Netem mailing list > Netem@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/netem > > > -- ---------------------------- Julio Kriger mailto:juliokriger@gmail.com From tommy.christensen@tpack.net Sat May 21 17:50:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 17:50:56 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4M0oqF3000848 for ; Sat, 21 May 2005 17:50:53 -0700 Received: (qmail 12570 invoked from network); 22 May 2005 00:50:09 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.1) by 0 with SMTP; 22 May 2005 00:50:09 -0000 Message-ID: <428FD7CF.3050904@tpack.net> Date: Sun, 22 May 2005 02:52:31 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Renzmann CC: netdev@oss.sgi.com Subject: Re: Network driver behaviour when loosing link References: <428F949C.8080707@otaku42.de> In-Reply-To: <428F949C.8080707@otaku42.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 2085 Lines: 51 Michael Renzmann wrote: > Hi all. > > I'm playing with a network driver and came across one thing I'd like to > ask something about. > > Let's assume a driver detects a link status change (for example, the > link is dropped). I would have expected that the driver should signal > the change via netif_carrier_on/_off (if used at all) and tell the > kernel to stop/resume sending packets to the driver (via > netif_wake_queue/netif_stop_queue). > > When checking several drivers I found some that call > netif_[wake|stop]_queue (e100, e1000), while others don't (natsemi, tg3). > > Hence the question: what is the recommended behaviour in such a case? Is netif_carrier_on/off should certainly be used. The use of netif_stop_queue depends on your HW: A) If your NIC continues taking packets from the ring buffer while link is down, then just let it do so. No need to call netif_stop_queue. Since recently, the stack will seize sending packets to your driver anyway. NB: this doesn't happen instantly, but typically within 1 sec. after calling netif_carrier_off. B) If your NIC stops DMA'ing packets when link is down, you have two options: 1) Check netif_carrier_ok in your hard_start_xmit function. 2) Call netif_stop_queue when link is lost. In both cases you have to flush the NIC's TX ring buffer, in order not to hold up resources (and not to send out stale packets when link is restored). > it ok to call netif_[stop|wake]_queue? How about adjusting the The queue state is assumed stable when holding dev->xmit_lock, so you can only call netif_stop_queue/wake_queue when this lock is held. However, this requirement doesn't seem do be followed everywhere. And then there is the LLTX drivers... > IFF_RUNNING flag accordingly? Is there any documentation available on > this topic? Drivers shouldn't touch IFF_RUNNING. It is maintained by the stack. Documentation? I haven't really seen any myself, except for the usual: source code, and mailing-list discussions. Any pointers are welcome'd. -Tommy From grundler@lackof.org Sat May 21 21:53:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 21:53:39 -0700 (PDT) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4M4rWF3010583 for ; Sat, 21 May 2005 21:53:33 -0700 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id 2201F29803C; Sat, 21 May 2005 22:56:05 -0600 (MDT) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19061-02; Sat, 21 May 2005 22:56:04 -0600 (MDT) Received: by colo.lackof.org (Postfix, from userid 27253) id 9C41129800A; Sat, 21 May 2005 22:56:04 -0600 (MDT) Date: Sat, 21 May 2005 22:56:04 -0600 From: Grant Grundler To: Francois Romieu Cc: Jeff Garzik , Grant Grundler , akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree Message-ID: <20050522045604.GC2733@colo.lackof.org> References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> <20050521223959.GA4337@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050521223959.GA4337@electric-eye.fr.zoreil.com> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.9i X-archive-position: 1483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev Content-Length: 3212 Lines: 114 On Sun, May 22, 2005 at 12:39:59AM +0200, Francois Romieu wrote: > Jeff Garzik : > [tulip_media_select] > > 1) called from timer context, from the media poll timer > > > > 2) called from spin_lock_irqsave() context, in the ->tx_timeout hook. > > > > The first case can be fixed by moved all the timer code to a workqueue. > > Then when the existing timer fires, kick the workqueue. > > > > The second case can be fixed by kicking the workqueue upon tx_timeout > > (which is the reason why I did not suggest queue_delayed_work() use). > > First try below. It only moves tulip_select_media() to process context. Cool - thanks. > The original patch (with s/udelay/msleep/ or such) is not included. That's fine. I'll take care of that once Jeff is happy with this. > Comments/suggestions ? Basic workqueue create/destroy looks correct - but I've only played with workqueues once before. It wouldn't hurt if someone else double checked too. Comments below are mostly about the other parts. > +static inline int tulip_create_workqueue(void) > +{ > + ktulipd_workqueue = create_workqueue("ktulipd"); > + return ktulipd_workqueue ? 0 : -ENOMEM; > +} This just obfuscates the code. It's only called in one place. Please just directly call create_workqueue("ktulipd") from tulip_init() and check the return value. > +static inline void tulip_destroy_workqueue(void) > +{ > + destroy_workqueue(ktulipd_workqueue); > +} Same thing. > @@ -526,20 +549,9 @@ static void tulip_tx_timeout(struct net_ ... > + tp->timeout_recovery = 1; > + queue_work(ktulipd_workqueue, &tp->media_work); > + goto out_unlock; This is the key bit. > - /* Stop and restart the chip's Tx processes . */ > - > - tulip_restart_rxtx(tp); > - /* Trigger an immediate transmit demand. */ > - iowrite32(0, ioaddr + CSR1); > - > - tp->stats.tx_errors++; > + tulip_tx_timeout_complete(tp, ioaddr); This doesn't fix the existing issue with tulip_restart_rxtx(). Even without the patch to tulip_select_media(), tulip_restart_rxtx() does not comply with jgarzik's linux driver requirements becuase it can spin delay up to 1200us. > static void __exit tulip_cleanup (void) > { > pci_unregister_driver (&tulip_driver); > + tulip_destroy_workqueue(); > } Only one workqueue for all instances of tulip cards, right? ... > @@ -127,6 +128,14 @@ void tulip_timer(unsigned long data) > } > break; > } > + > + spin_lock_irqsave (&tp->lock, flags); > + if (tp->timeout_recovery) { > + tp->timeout_recovery = 0; > + tulip_tx_timeout_complete(tp, ioaddr); > + } > + spin_unlock_irqrestore (&tp->lock, flags); This suffers the original issue: blocked IRQs while CPU might spin for 1200us in tulip_tx_timeout_complete(). If tp->timeout_recovery acts as a sort of semaphore for us, do we even need the spinlock? I suspect "yes" because timeout_recovery is a bitfield and clearing it is a read/modify/write operation. This is why I don't like bitfields. ie. something like: if (tp->timeout_recovery) { tulip_tx_timeout_complete(tp, ioaddr); spin_lock_irqsave (&tp->lock, flags); tp->timeout_recovery = 0; /* Bitfields are NOT atomic. */ spin_unlock_irqrestore (&tp->lock, flags); } thanks, grant From razb@bitband.com Sat May 21 23:52:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 21 May 2005 23:53:01 -0700 (PDT) Received: from mail1.bitband.com (fw.bitband.com [213.8.50.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4M6qwF3015062 for ; Sat, 21 May 2005 23:52:59 -0700 Received: from [172.16.1.60] ([172.16.1.60]) by mail1.bitband.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 May 2005 09:52:12 +0200 Subject: user space checksum From: raz ben jehuda To: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1116744708.3021.12.camel@raz-laptop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 22 May 2005 09:51:48 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2005 07:52:13.0015 (UTC) FILETIME=[2A2C3E70:01C55EA3] X-archive-position: 1484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: razb@bitband.com Precedence: bulk X-list: netdev Content-Length: 473 Lines: 13 I do not know if this was ever suggested.so i'll try any way. Why not give the user the chance to supply the kernel/card with the checksums instead of having the kernel/network card do the work ? This is because a user is aware to the data he sends and he can optimize the data checksum calculations more than anyone else. for instance a web server sends its html pages, which are static data. it can pre-calculate the checksums. Anyone ? -- Raz Long Live The Penguin From herbert@gondor.apana.org.au Sun May 22 00:35:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 22 May 2005 00:35:51 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4M7ZiF3021933 for ; Sun, 22 May 2005 00:35:45 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DZkys-0002X9-00; Sun, 22 May 2005 17:34:38 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DZkyp-00048F-00; Sun, 22 May 2005 17:34:35 +1000 Date: Sun, 22 May 2005 17:34:35 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: christophe@saout.de, linux-net@vger.kernel.org, netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [BUG 2.6.12-rc4] IPv6 xfrm tunnel oops with large packets Message-ID: <20050522073435.GA15867@gondor.apana.org.au> References: <1116702611.14509.10.camel@leto.cs.pocnet.net> <20050521194932.GA10959@gondor.apana.org.au> <20050522.051817.122678688.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050522.051817.122678688.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 853 Lines: 21 On Sun, May 22, 2005 at 05:18:17AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > BTW, icmpv6_send seems to ignore its dev argument altogether. > > Any reason why we can't just use it instead of skb->dev? > > (After looking into icmpv6_send() usages,) > I don't know the reason why we needed the last argument "dev". > It seems that we already had it at the time of 2.2.16. > Probably, we can remove it. In a number of places (I've just created another one with my patch :) we are setting skb->dev specifically for icmpv6_send. If we make icmpv6_send use its dev argument instead of skb->dev then we can avoid those settings. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From netdev@nospam.otaku42.de Sun May 22 11:45:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 22 May 2005 11:45:11 -0700 (PDT) Received: from legolas.otaku42.de (legolas.otaku42.de [217.24.0.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4MIj8F3023714 for ; Sun, 22 May 2005 11:45:09 -0700 Received: from dsl-084-058-129-148.arcor-ip.net ([84.58.129.148] helo=[192.168.2.42] ident=otaku) by legolas.otaku42.de with asmtp (Exim 4.20 and XAMS 0.0.11) id 1DZvR3-0007jg-79 for netdev@oss.sgi.com; Sun, 22 May 2005 20:44:25 +0200 Message-ID: <4290D309.4020301@otaku42.de> Date: Sun, 22 May 2005 20:44:25 +0200 From: Michael Renzmann User-Agent: Mozilla Thunderbird 1.0 (X11/20050205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Good (exemplary) network driver? X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: netdev@nospam.otaku42.de Precedence: bulk X-list: netdev Content-Length: 286 Lines: 8 Hi all. Short question: which network driver is commonly regarded as a good implementation of what a linux network driver should look like? Is there something like a "reference driver" available, which could be consulted for all of those "how should I do xyz" questions? Bye, Mike From romieu@fr.zoreil.com Sun May 22 15:36:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 22 May 2005 15:36:29 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4MMaOF3002722 for ; Sun, 22 May 2005 15:36:25 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4MMYAHC010343; Mon, 23 May 2005 00:34:10 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4MMY4bh010342; Mon, 23 May 2005 00:34:04 +0200 Date: Mon, 23 May 2005 00:34:04 +0200 From: Francois Romieu To: Michael Renzmann Cc: netdev@oss.sgi.com Subject: Re: Good (exemplary) network driver? Message-ID: <20050522223404.GA8689@electric-eye.fr.zoreil.com> References: <4290D309.4020301@otaku42.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4290D309.4020301@otaku42.de> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 554 Lines: 13 Michael Renzmann : [...] > Short question: which network driver is commonly regarded as a good > implementation of what a linux network driver should look like? Is there > something like a "reference driver" available, which could be consulted > for all of those "how should I do xyz" questions? drivers/net/pci-skeleton.c provides some hints but it is not the best maintained/cleaned-up/feature-rich driver (no module_parm, no ethtool, no vlan, etc.). You will find some answers in the gigabit drivers as well. -- Ueimor From proski@gnu.org Sun May 22 20:41:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 22 May 2005 20:41:50 -0700 (PDT) Received: from dv.roinet.com (h-64-105-159-118.phlapafg.covad.net [64.105.159.118]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4N3fkF3019351 for ; Sun, 22 May 2005 20:41:46 -0700 Received: from dv.roinet.com (localhost.localdomain [127.0.0.1]) by dv.roinet.com (8.13.4/8.13.4) with ESMTP id j4N3efqg012934; Sun, 22 May 2005 23:40:41 -0400 Received: (from proski@localhost) by dv.roinet.com (8.13.4/8.13.4/Submit) id j4N3edxV012871; Sun, 22 May 2005 23:40:39 -0400 X-Authentication-Warning: dv.roinet.com: proski set sender to proski@gnu.org using -f Subject: Re: [PATCH 11/12] orinoco: monitor mode support From: Pavel Roskin To: Francois Romieu Cc: Christoph Hellwig , jgarzik@pobox.com, hermes@gibson.dropbear.id.au, netdev@oss.sgi.com In-Reply-To: <20050517212217.GB12936@electric-eye.fr.zoreil.com> References: <20050514153100.GL3643@lst.de> <20050514173947.GA32235@electric-eye.fr.zoreil.com> <1116358994.5534.2.camel@dv.roinet.com> <20050517212217.GB12936@electric-eye.fr.zoreil.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sun, 22 May 2005 23:40:39 -0400 Message-Id: <1116819639.726.6.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) X-archive-position: 1489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: proski@gnu.org Precedence: bulk X-list: netdev Content-Length: 1072 Lines: 37 Hello, Francois! On Tue, 2005-05-17 at 23:22 +0200, Francois Romieu wrote: > I am not fond of unneeded/hidden state variable. What about: > > + /* sanity check the length */ > + if (datalen > IEEE80211_DATA_LEN + 12) { > + printk(KERN_DEBUG "%s: oversized monitor frame, " > + "data length = %d\n", dev->name, datalen); > + err = -EIO; > + goto drop; > ^^^^^^^^^^ -> let's replace by 'goto update_stats;' > And turn: > + drop: > + stats->rx_errors++; > + stats->rx_dropped++; > > into: > > + drop: > + dev_kfree_skb_irq(skb); > + update_stats: > + stats->rx_errors++; > + stats->rx_dropped++; > > This way 'goto drop' really drops and the code does not issue a 'goto drop' > when it actually want to update the stats. I agree. Closer look shows that orinoco needs a complete overhaul of stats in the rx path. I'm going to fix it in CVS, and I'll post the patch to netdev after it receives some testing. -- Regards, Pavel Roskin From util@deuroconsult.ro Mon May 23 00:47:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 00:47:44 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4N7lbF3001612 for ; Mon, 23 May 2005 00:47:40 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4N7koAt032007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 May 2005 10:46:50 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4N7koim032004 for ; Mon, 23 May 2005 10:46:50 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Mon, 23 May 2005 10:46:50 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: netdev@oss.sgi.com Subject: Why /sys/class/net/*/features is read-only? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 310 Lines: 14 Hello! Why features file is read-only. If an admin want to force some attributes, we can let them, right? This way, an admin can force SG and HW_CSUM on a bridge, for example. ;) I can make a patch, if you want. Thank you! --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From util@deuroconsult.ro Mon May 23 02:41:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 02:41:08 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4N9f3F3006226 for ; Mon, 23 May 2005 02:41:04 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4N9eH0i018822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2005 12:40:17 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4N9eHxh018819; Mon, 23 May 2005 12:40:17 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Mon, 23 May 2005 12:40:17 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Jon Mason cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) In-Reply-To: <200505201354.46824.jdmason@us.ibm.com> Message-ID: References: <20050519214015.GA19961@us.ibm.com> <200505201354.46824.jdmason@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1389 Lines: 55 > Let's use the full BR_FEAT_MASK of NETIF_F_HW_CSUM | NETIF_F_SG | > | NETIF_F_FRAGLIST | NETIF_F_IP_CSUM | NETIF_F_HIGHDMA | NETIF_F_TSO). > That is 0011 0000 0110 1011 > > Now, let's assume that the NIC only has NETIF_F_TSO, > NETIF_F_IP_CSUM, and NETIF_F_SG enabled. > So, that is 0000 1000 0000 0011 > > So, we have the following: > For the first adapter added: > br = 0001 1000 0110 1011 > br = 0001 1000 0110 1011 & 0000 1000 0000 0011 | ~0001 1000 0110 1011 > br = 0001 1000 0110 1011 & 0000 1000 0000 0011 | 1110 0111 1001 0100 > br = 0000 1000 0000 0011 | 1110 0111 1001 0100 > br = 1110 1111 1001 0111 > Note - this breaks down to the following being enabled: > NETIF_F_SG > NETIF_F_IP_CSUM > NETIF_F_NO_CSUM > UNDEFINED BIT > NETIF_F_HW_VLAN_RX > NETIF_F_HW_VLAN_FILTER > NETIF_F_VLAN_CHALLENGED > NETIF_F_TSO > NETIF_F_LLTX [...] > Thanks, > Jon The code applies the ~ first, then the | and _then_ the &. If we have: a &= a | ~b; it is equivalent with: a = a & (a | ~b); For your example: br = 0001 1000 0110 1011 = 0x186B feat = 0001 1000 0110 1011 = 0x186B nic = 0000 1000 0000 0011 = 0x0803 br &= nic | ~feat br = 0x803 - I say this is correct! With the second nic: br = 0x0803 feat = 0x186B nic2 = 0x0803 br &= nic2 | ~feat; br = 0x0803 - I say it's correct Am I missing something? --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From util@deuroconsult.ro Mon May 23 02:40:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 02:40:59 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4N9edF3006202 for ; Mon, 23 May 2005 02:40:44 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4N9dcqu018574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2005 12:39:38 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4N9dZPR018513; Mon, 23 May 2005 12:39:38 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Mon, 23 May 2005 12:39:35 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Jon Mason cc: netdev@oss.sgi.com, davem@davemloft.net, Stephen Hemminger Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) In-Reply-To: <200505201354.46824.jdmason@us.ibm.com> Message-ID: References: <20050519214015.GA19961@us.ibm.com> <200505201354.46824.jdmason@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1069 Lines: 40 >>>> +/* >>>> + * Recomputes features using slave's features >>>> + */ >>>> +static void br_features_recompute(struct net_bridge *br) >>>> +{ >>>> + struct net_bridge_port *p; >>>> + >>>> + br->dev->features |= BR_FEAT_MASK; >>> >>> The OR is not needed. Just re-initialize features to BR_FEAT_MASK and >>> everything will take case of itself. >> >> Nope. Not correct. Because we might enable LLTX on the bridge, but not in >> BR_FEAT_MASK. > > This is not the case. This is the same as re-doing the entire feature list > (as if it was being done initially). All that needs to be done is for > br->dev->features to have a initial value. > >> I will post a patch in few hours with all stuff updated. > > Great. Thanks. > > Thanks, > Jon I will post a patch with the initial features as: dev->features = BR_FEAT_MASK | NETIF_F_NO_CSUM | NETIF_F_LLTX at Stephen's suggestion. But, BR_FEAT_MASK will not have NETIF_F_NO_CSUM and NETIF_F_LLTX. I think the code is correct as it is. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From util@deuroconsult.ro Mon May 23 02:44:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 02:44:14 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4N9iAF3007134 for ; Mon, 23 May 2005 02:44:10 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4N9hOJN020225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2005 12:43:24 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4N9hNUJ020188; Mon, 23 May 2005 12:43:23 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Mon, 23 May 2005 12:43:23 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: netdev@oss.sgi.com cc: davem@davemloft.net Subject: [PATCH] Implement NETDEV_FEAT_CHANGE Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1646943047-520198958-1116841403=:19416" X-archive-position: 1493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 4554 Lines: 92 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1646943047-520198958-1116841403=:19416 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hello! Bridge/bonding/etc. will use it (for bridge the patch will follow today). Patch was tested. David, please apply. Thank you very much. Signed-off-by: Catalin BOIE --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ---1646943047-520198958-1116841403=:19416 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=NETDEV_FEAT_CHANGE.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=NETDEV_FEAT_CHANGE.patch LS0tIG5vdGlmeTEvaW5jbHVkZS9saW51eC9ub3RpZmllci5oCTIwMDUtMDMt MDIgMDk6Mzc6NDguMDAwMDAwMDAwICswMjAwDQorKysgbGludXgvaW5jbHVk ZS9saW51eC9ub3RpZmllci5oCTIwMDUtMDUtMjAgMTM6MTc6NDIuMDAwMDAw MDAwICswMzAwDQpAQCAtNTYsNiArNTYsNyBAQCBleHRlcm4gaW50IG5vdGlm aWVyX2NhbGxfY2hhaW4oc3RydWN0IG5vDQogI2RlZmluZSBORVRERVZfQ0hB TkdFQUREUgkweDAwMDgNCiAjZGVmaW5lIE5FVERFVl9HT0lOR19ET1dOCTB4 MDAwOQ0KICNkZWZpbmUgTkVUREVWX0NIQU5HRU5BTUUJMHgwMDBBDQorI2Rl ZmluZSBORVRERVZfRkVBVF9DSEFOR0UJMHgwMDBCDQogDQogI2RlZmluZSBT WVNfRE9XTgkweDAwMDEJLyogTm90aWZ5IG9mIHN5c3RlbSBkb3duICovDQog I2RlZmluZSBTWVNfUkVTVEFSVAlTWVNfRE9XTg0KLS0tIG5vdGlmeTEvbmV0 L2NvcmUvZXRodG9vbC5jCTIwMDUtMDMtMDIgMDk6Mzg6MzcuMDAwMDAwMDAw ICswMjAwDQorKysgbGludXgvbmV0L2NvcmUvZXRodG9vbC5jCTIwMDUtMDUt MjMgMTE6MzA6NDcuMDAwMDAwMDAwICswMzAwDQpAQCAtNjgyLDYgKzY4Miw3 IEBAIGludCBkZXZfZXRodG9vbChzdHJ1Y3QgaWZyZXEgKmlmcikNCiAJdm9p ZCBfX3VzZXIgKnVzZXJhZGRyID0gaWZyLT5pZnJfZGF0YTsNCiAJdTMyIGV0 aGNtZDsNCiAJaW50IHJjOw0KKwlpbnQgb2xkX2ZlYXR1cmVzOw0KIA0KIAkv Kg0KIAkgKiBYWFg6IFRoaXMgY2FuIGJlIHB1c2hlZCBkb3duIGludG8gdGhl IGV0aHRvb2xfKiBoYW5kbGVycyB0aGF0DQpAQCAtNzAzLDYgKzcwNCw4IEBA IGludCBkZXZfZXRodG9vbChzdHJ1Y3QgaWZyZXEgKmlmcikNCiAJCWlmICgo cmMgPSBkZXYtPmV0aHRvb2xfb3BzLT5iZWdpbihkZXYpKSA8IDApDQogCQkJ cmV0dXJuIHJjOw0KIA0KKwlvbGRfZmVhdHVyZXMgPSBkZXYtPmZlYXR1cmVz Ow0KKw0KIAlzd2l0Y2ggKGV0aGNtZCkgew0KIAljYXNlIEVUSFRPT0xfR1NF VDoNCiAJCXJjID0gZXRodG9vbF9nZXRfc2V0dGluZ3MoZGV2LCB1c2VyYWRk cik7DQpAQCAtNzEyLDcgKzcxNSw2IEBAIGludCBkZXZfZXRodG9vbChzdHJ1 Y3QgaWZyZXEgKmlmcikNCiAJCWJyZWFrOw0KIAljYXNlIEVUSFRPT0xfR0RS VklORk86DQogCQlyYyA9IGV0aHRvb2xfZ2V0X2RydmluZm8oZGV2LCB1c2Vy YWRkcik7DQotDQogCQlicmVhazsNCiAJY2FzZSBFVEhUT09MX0dSRUdTOg0K IAkJcmMgPSBldGh0b29sX2dldF9yZWdzKGRldiwgdXNlcmFkZHIpOw0KQEAg LTgwMSw2ICs4MDMsMTAgQEAgaW50IGRldl9ldGh0b29sKHN0cnVjdCBpZnJl cSAqaWZyKQ0KIAkNCiAJaWYoZGV2LT5ldGh0b29sX29wcy0+Y29tcGxldGUp DQogCQlkZXYtPmV0aHRvb2xfb3BzLT5jb21wbGV0ZShkZXYpOw0KKw0KKwlp ZiAob2xkX2ZlYXR1cmVzICE9IGRldi0+ZmVhdHVyZXMpDQorCQluZXRkZXZf ZmVhdHVyZXNfY2hhbmdlKGRldik7DQorDQogCXJldHVybiByYzsNCiANCiAg aW9jdGw6DQotLS0gbm90aWZ5MS9uZXQvY29yZS9kZXYuYwkyMDA1LTAzLTI2 IDA1OjI4OjIxLjAwMDAwMDAwMCArMDIwMA0KKysrIGxpbnV4L25ldC9jb3Jl L2Rldi5jCTIwMDUtMDUtMjMgMTI6MTQ6MzIuMDAwMDAwMDAwICswMzAwDQpA QCAtNzYxLDYgKzc2MSwxOCBAQCBpbnQgZGV2X2NoYW5nZV9uYW1lKHN0cnVj dCBuZXRfZGV2aWNlICpkDQogfQ0KIA0KIC8qKg0KKyAqCW5ldGRldl9mZWF0 dXJlc19jaGFuZ2UgLSBkZXZpY2UgY2hhbmdlcyBmYXR1cmVzDQorICoJQGRl djogZGV2aWNlIHRvIGNhdXNlIG5vdGlmaWNhdGlvbg0KKyAqDQorICoJQ2Fs bGVkIHRvIGluZGljYXRlIGEgZGV2aWNlIGhhcyBjaGFuZ2VkIGZlYXR1cmVz Lg0KKyAqLw0KK3ZvaWQgbmV0ZGV2X2ZlYXR1cmVzX2NoYW5nZShzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2KQ0KK3sNCisJbm90aWZpZXJfY2FsbF9jaGFpbigm bmV0ZGV2X2NoYWluLCBORVRERVZfRkVBVF9DSEFOR0UsIGRldik7DQorfQ0K K0VYUE9SVF9TWU1CT0wobmV0ZGV2X2ZlYXR1cmVzX2NoYW5nZSk7DQorDQor LyoqDQogICoJbmV0ZGV2X3N0YXRlX2NoYW5nZSAtIGRldmljZSBjaGFuZ2Vz IHN0YXRlDQogICoJQGRldjogZGV2aWNlIHRvIGNhdXNlIG5vdGlmaWNhdGlv bg0KICAqDQotLS0gbm90aWZ5MS9pbmNsdWRlL2xpbnV4L25ldGRldmljZS5o CTIwMDUtMDMtMDIgMDk6Mzg6MjYuMDAwMDAwMDAwICswMjAwDQorKysgbGlu dXgvaW5jbHVkZS9saW51eC9uZXRkZXZpY2UuaAkyMDA1LTA1LTIzIDEwOjE2 OjQzLjAwMDAwMDAwMCArMDMwMA0KQEAgLTkxNiw2ICs5MTYsNyBAQCBleHRl cm4gdm9pZAkJZGV2X21jX2Rpc2NhcmQoc3RydWN0IG5ldF9kDQogZXh0ZXJu IHZvaWQJCWRldl9zZXRfcHJvbWlzY3VpdHkoc3RydWN0IG5ldF9kZXZpY2Ug KmRldiwgaW50IGluYyk7DQogZXh0ZXJuIHZvaWQJCWRldl9zZXRfYWxsbXVs dGkoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IGluYyk7DQogZXh0ZXJu IHZvaWQJCW5ldGRldl9zdGF0ZV9jaGFuZ2Uoc3RydWN0IG5ldF9kZXZpY2Ug KmRldik7DQorZXh0ZXJuIHZvaWQJCW5ldGRldl9mZWF0dXJlc19jaGFuZ2Uo c3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQogLyogTG9hZCBhIGRldmljZSB2 aWEgdGhlIGttb2QgKi8NCiBleHRlcm4gdm9pZAkJZGV2X2xvYWQoY29uc3Qg Y2hhciAqbmFtZSk7DQogZXh0ZXJuIHZvaWQJCWRldl9tY2FzdF9pbml0KHZv aWQpOw0K ---1646943047-520198958-1116841403=:19416-- From herbert@gondor.apana.org.au Mon May 23 02:55:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 02:55:20 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4N9tCF3008138 for ; Mon, 23 May 2005 02:55:13 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Da9dc-0003Js-00; Mon, 23 May 2005 19:54:20 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Da9dZ-0004u4-00; Mon, 23 May 2005 19:54:17 +1000 Date: Mon, 23 May 2005 19:54:17 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO v2 Message-ID: <20050523095417.GA18770@gondor.apana.org.au> References: <20050520.115154.48807299.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520.115154.48807299.davem@davemloft.net> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1610 Lines: 55 On Fri, May 20, 2005 at 06:51:54PM +0000, David S. Miller wrote: > > Ok, new version of the patch. Besides some cleanups, > the main change is packet send deferral at ACK arrival > time. Thanks for the great work Dave. > @@ -712,7 +713,7 @@ new_segment: > if (!(psize -= copy)) > goto out; > > - if (skb->len != mss_now || (flags & MSG_OOB)) > + if (skb->len != size_goal || (flags & MSG_OOB)) > continue; > +unsigned int tcp_current_mss(struct sock *sk, int large_allowed) > + > + if (tp->xmit_size_cache != xmit_cache) { > + u16 xmit_size_goal = mss_now; > + > + if (doing_tso) { > + xmit_size_goal = 65535 - > + tp->af_specific->net_header_len - > + tp->ext_header_len - tp->tcp_header_len; > + > + if (tp->rx_opt.eff_sacks) > + xmit_size_goal -= (TCPOLEN_SACK_BASE_ALIGNED + > + (tp->rx_opt.eff_sacks * > + TCPOLEN_SACK_PERBLOCK)); > + > + xmit_size_goal -= (xmit_size_goal % mss_now); > + } > + tp->xmit_size_goal = xmit_size_goal; > + tp->xmit_size_cache = xmit_cache; > + } > + > return mss_now; > } Perhaps we should set the goal based on the cwnd as we do now? As it is I believe we may be doing more work compared to the status quo because it's always building 64K blocks and then cutting them up as dictated by the cwnd. On the other hand, the current code simply builds the packets up to the size that cwnd allows. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From pravins@calsoftinc.com Mon May 23 05:25:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 05:25:45 -0700 (PDT) Received: from ganesha.intranet.calsoftinc.com ([220.225.34.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NCPTF3001838 for ; Mon, 23 May 2005 05:25:36 -0700 Received: from [172.16.0.108] (unknown [172.16.0.108]) by ganesha.intranet.calsoftinc.com (Postfix) with ESMTP id 6BC5ADB58B; Mon, 23 May 2005 17:47:24 +0530 (IST) Message-ID: <4291CBFF.6080106@calsoftinc.com> Date: Mon, 23 May 2005 17:56:39 +0530 From: pravin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: "David S. Miller" , "Herbert Xu" Subject: [PATCH] : bug fix in multipath drr code. Content-Type: multipart/mixed; boundary="------------000707030603080303070608" X-archive-position: 1495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pravins@calsoftinc.com Precedence: bulk X-list: netdev Content-Length: 3148 Lines: 111 This is a multi-part message in MIME format. --------------000707030603080303070608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi AFAIU, there is a race condition in multipath_drr code, these code paths try to access & change last_selection variable without any synchronization. Please correct me if I am wrong. Code Path - 1 __ip_route_output_key(...) { ... calls drr_select_route if(FLOWI_FLAG_MULTIPATHOLDROUTE set){ check last_selection. return last_selection //so it can return NULL pointer } .... } Code Path - 2 rt_secret_rebuild() { ..... rt_run_flush(..); ->rt_free(rth); -> multipath_remove(rt) ->drr_remove() reset last_selection. .... } Attached patch also fixes bug in function drr_init :: multipath_alg_register(..) is called with wrong algorithm ID. Regards Pravin. --------------000707030603080303070608 Content-Type: text/x-patch; name="multipath-last_selection-race-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="multipath-last_selection-race-fix.patch" Signed-off by: Pravin B. Shelar Index: linux-2.6.12-rc4/net/ipv4/multipath_drr.c =================================================================== --- linux-2.6.12-rc4.orig/net/ipv4/multipath_drr.c 2005-05-06 22:20:31.000000000 -0700 +++ linux-2.6.12-rc4/net/ipv4/multipath_drr.c 2005-05-22 06:41:39.000000000 -0700 @@ -145,11 +145,13 @@ int cur_min_devidx = -1; /* if necessary and possible utilize the old alternative */ - if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 && - last_selection != NULL) { - result = last_selection; - *rp = result; - return; + if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 ) { + struct rtable *last_result = last_selection; + if(last_result != NULL && + multipath_comparekeys(&last_result->fl, flp)) { + *rp = last_result; + return; + } } /* 1. make sure all alt. nexthops have the same GC related data */ @@ -244,7 +246,7 @@ if (err) return err; - err = multipath_alg_register(&drr_ops, IP_MP_ALG_RR); + err = multipath_alg_register(&drr_ops, IP_MP_ALG_DRR); if (err) goto fail; Index: linux-2.6.12-rc4/net/ipv4/multipath_rr.c =================================================================== --- linux-2.6.12-rc4.orig/net/ipv4/multipath_rr.c 2005-05-06 22:20:31.000000000 -0700 +++ linux-2.6.12-rc4/net/ipv4/multipath_rr.c 2005-05-22 06:41:20.000000000 -0700 @@ -64,10 +64,13 @@ int min_use = -1; /* if necessary and possible utilize the old alternative */ - if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 && - last_used != NULL) { - result = last_used; - goto out; + if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 ) { + struct rtable *last_result = last_used; + if(last_result != NULL && + multipath_comparekeys(&last_result->fl, flp)) { + result = last_result; + goto out; + } } /* 1. make sure all alt. nexthops have the same GC related data --------------000707030603080303070608-- From shemminger@osdl.org Mon May 23 09:34:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 09:34:21 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NGYHF3016159 for ; Mon, 23 May 2005 09:34:17 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4NGXTjA029811 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 09:33:30 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4NGXTVt006214; Mon, 23 May 2005 09:33:29 -0700 Date: Mon, 23 May 2005 09:33:29 -0700 From: Stephen Hemminger To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] Implement NETDEV_FEAT_CHANGE Message-ID: <20050523093329.40617690@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 693 Lines: 28 > --- notify1/net/core/ethtool.c 2005-03-02 09:38:37.000000000 +0200 > +++ linux/net/core/ethtool.c 2005-05-23 11:30:47.000000000 +0300 ... > @@ -712,7 +715,6 @@ int dev_ethtool(struct ifreq *ifr) > break; > case ETHTOOL_GDRVINFO: > rc = ethtool_get_drvinfo(dev, useraddr); > - > break; White space creep > case ETHTOOL_GREGS: > rc = ethtool_get_regs(dev, useraddr); > @@ -801,6 +803,10 @@ int dev_ethtool(struct ifreq *ifr) > > if(dev->ethtool_ops->complete) > dev->ethtool_ops->complete(dev); > + > + if (old_features != dev->features) > + netdev_features_change(dev); > + > return rc; > > ioctl: Did you check for any drivers that don't use ethtool_ops? From shemminger@osdl.org Mon May 23 09:29:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 09:29:28 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NGTJF3015656 for ; Mon, 23 May 2005 09:29:20 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4NGSRjA029521 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 09:28:28 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4NGSRDv005977; Mon, 23 May 2005 09:28:27 -0700 Date: Mon, 23 May 2005 09:28:27 -0700 From: Stephen Hemminger To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com Subject: Re: Why /sys/class/net/*/features is read-only? Message-ID: <20050523092827.7883af33@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 346 Lines: 11 On Mon, 23 May 2005 10:46:50 +0300 (EEST) "Catalin(ux aka Dino) BOIE" wrote: > Hello! > > Why features file is read-only. If an admin want to force some attributes, > we can let them, right? > Leave it read-only because the hardware may not want to allow them on that flavor and so it would have to be device specific. From shemminger@osdl.org Mon May 23 10:26:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 10:26:12 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NHQ3F3019973 for ; Mon, 23 May 2005 10:26:04 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4NHPGjA002096 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 10:25:17 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4NHPGbq008766; Mon, 23 May 2005 10:25:16 -0700 Date: Mon, 23 May 2005 10:25:17 -0700 From: Stephen Hemminger To: Julio Kriger Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: Re: [Netem] [PATCH] (3/3) netem: allow random reordering Message-ID: <20050523102517.1903f5f2@dxpl.pdx.osdl.net> In-Reply-To: <682bc30a050520132819b66fee@mail.gmail.com> References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> <682bc30a050520132819b66fee@mail.gmail.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4767 Lines: 165 On Fri, 20 May 2005 20:28:40 +0000 Julio Kriger wrote: > Hi! > How do I use this feature? Shouldn't tc be modified to accept this new feature? > Regards, > > Julio Use this (it will be in the next version of iproute2). Also, you need to specify a delay because that is how netem does the reordering. diff -X dontdiff -urN iproute2-2.6.11-050330/include/linux/pkt_sched.h iproute2-netem/include/linux/pkt_sched.h --- iproute2-2.6.11-050330/include/linux/pkt_sched.h 2005-04-01 11:58:11.000000000 -0800 +++ iproute2-netem/include/linux/pkt_sched.h 2005-05-04 11:31:14.000000000 -0700 @@ -427,6 +427,7 @@ TCA_NETEM_UNSPEC, TCA_NETEM_CORR, TCA_NETEM_DELAY_DIST, + TCA_NETEM_REORDER, __TCA_NETEM_MAX, }; @@ -437,7 +438,7 @@ __u32 latency; /* added delay (us) */ __u32 limit; /* fifo limit (packets) */ __u32 loss; /* random packet loss (0=none ~0=100%) */ - __u32 gap; /* re-ordering gap (0 for delay all) */ + __u32 gap; /* re-ordering gap (0 for none) */ __u32 duplicate; /* random packet dup (0=none ~0=100%) */ __u32 jitter; /* random jitter in latency (us) */ }; @@ -449,6 +450,12 @@ __u32 dup_corr; /* duplicate correlation */ }; +struct tc_netem_reorder +{ + __u32 probability; + __u32 correlation; +}; + #define NETEM_DIST_SCALE 8192 #endif diff -X dontdiff -urN iproute2-2.6.11-050330/tc/q_netem.c iproute2-netem/tc/q_netem.c --- iproute2-2.6.11-050330/tc/q_netem.c 2005-04-01 11:58:11.000000000 -0800 +++ iproute2-netem/tc/q_netem.c 2005-05-04 13:31:25.000000000 -0700 @@ -29,11 +29,11 @@ { fprintf(stderr, "Usage: ... netem [ limit PACKETS ] \n" \ -" [ delay TIME [ JITTER [CORRELATION]]]\n" \ +" [ delay TIME [ JITTER [CORRELATION]]]\n" \ +" [ distribution {uniform|normal|pareto|paretonormal} ]\n" \ " [ drop PERCENT [CORRELATION]] \n" \ " [ duplicate PERCENT [CORRELATION]]\n" \ -" [ distribution {uniform|normal|pareto|paretonormal} ]\n" \ -" [ gap PACKETS ]\n"); +" [ reorder PRECENT [CORRELATION] [ gap DISTANCE ]]\n"); } static void explain1(const char *arg) @@ -127,11 +127,13 @@ struct rtattr *tail; struct tc_netem_qopt opt; struct tc_netem_corr cor; + struct tc_netem_reorder reorder; __s16 dist_data[MAXDIST]; memset(&opt, 0, sizeof(opt)); opt.limit = 1000; memset(&cor, 0, sizeof(cor)); + memset(&reorder, 0, sizeof(reorder)); while (argc > 0) { if (matches(*argv, "limit") == 0) { @@ -178,6 +180,19 @@ return -1; } } + } else if (matches(*argv, "reorder") == 0) { + NEXT_ARG(); + if (get_percent(&reorder.probability, *argv)) { + explain1("reorder"); + return -1; + } + if (NEXT_IS_NUMBER()) { + NEXT_ARG(); + if (get_percent(&reorder.correlation, *argv)) { + explain1("reorder"); + return -1; + } + } } else if (matches(*argv, "gap") == 0) { NEXT_ARG(); if (get_u32(&opt.gap, *argv, 0)) { @@ -215,8 +230,27 @@ tail = NLMSG_TAIL(n); + if (reorder.probability) { + if (opt.latency == 0) { + fprintf(stderr, "reordering not possible without specifying some delay\n"); + } + if (opt.gap == 0) + opt.gap = 1; + } else if (opt.gap > 0) { + fprintf(stderr, "gap specified without reorder probability\n"); + explain(); + return -1; + } + + if (dist_size > 0 && (opt.latency == 0 || opt.jitter == 0)) { + fprintf(stderr, "distribution specified but no latency and jitter values\n"); + explain(); + return -1; + } + addattr_l(n, 1024, TCA_OPTIONS, &opt, sizeof(opt)); addattr_l(n, 1024, TCA_NETEM_CORR, &cor, sizeof(cor)); + addattr_l(n, 1024, TCA_NETEM_REORDER, &reorder, sizeof(reorder)); if (dist_size > 0) { addattr_l(n, 32768, TCA_NETEM_DELAY_DIST, @@ -229,6 +263,7 @@ static int netem_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt) { const struct tc_netem_corr *cor = NULL; + const struct tc_netem_reorder *reorder = NULL; struct tc_netem_qopt qopt; int len = RTA_PAYLOAD(opt) - sizeof(qopt); SPRINT_BUF(b1); @@ -252,6 +287,11 @@ return -1; cor = RTA_DATA(tb[TCA_NETEM_CORR]); } + if (tb[TCA_NETEM_REORDER]) { + if (RTA_PAYLOAD(tb[TCA_NETEM_REORDER]) < sizeof(*reorder)) + return -1; + reorder = RTA_DATA(tb[TCA_NETEM_REORDER]); + } } fprintf(f, "limit %d", qopt.limit); @@ -278,10 +318,19 @@ if (cor && cor->dup_corr) fprintf(f, " %s", sprint_percent(cor->dup_corr, b1)); } + + if (reorder && reorder->probability) { + fprintf(f, " reorder %s", + sprint_percent(reorder->probability, b1)); + if (reorder->correlation) + fprintf(f, " %s", + sprint_percent(reorder->correlation, b1)); + } if (qopt.gap) fprintf(f, " gap %lu", (unsigned long)qopt.gap); + return 0; } From shemminger@osdl.org Mon May 23 10:44:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 10:44:32 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NHiTF3021111 for ; Mon, 23 May 2005 10:44:30 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4NHhgjA003503 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 10:43:43 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4NHhgvR009638; Mon, 23 May 2005 10:43:42 -0700 Date: Mon, 23 May 2005 10:43:42 -0700 From: Stephen Hemminger To: Julio Kriger Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: [PATCH] netem: fix logic bug in reorder conditional Message-ID: <20050523104342.78b1032d@dxpl.pdx.osdl.net> In-Reply-To: <682bc30a05052116005bc813a2@mail.gmail.com> References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> <682bc30a05052116005bc813a2@mail.gmail.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1221 Lines: 34 Thanks, Julio you spotted the problem with the logic. This should fix it: Index: netem-2.6.12-rc4/net/sched/sch_netem.c =================================================================== --- netem-2.6.12-rc4.orig/net/sched/sch_netem.c +++ netem-2.6.12-rc4/net/sched/sch_netem.c @@ -181,13 +181,9 @@ static int netem_enqueue(struct sk_buff q->duplicate = dupsave; } - /* - * Do re-ordering by putting one out of N packets at the front - * of the queue. - * gap == 0 is special case for no-reordering. - */ - if (q->gap == 0 && q->counter < q->gap && - q->reorder < get_crandom(&q->reorder_cor)) { + if (q->gap == 0 /* not doing reordering */ + || q->counter < q->gap /* inside last reordering gap */ + || q->reorder < get_crandom(&q->reorder_cor)) { psched_time_t now; PSCHED_GET_TIME(now); PSCHED_TADD2(now, tabledist(q->latency, q->jitter, @@ -196,6 +192,10 @@ static int netem_enqueue(struct sk_buff ++q->counter; ret = q->qdisc->enqueue(skb, q->qdisc); } else { + /* + * Do re-ordering by putting one out of N packets at the front + * of the queue. + */ PSCHED_GET_TIME(cb->time_to_send); q->counter = 0; ret = q->qdisc->ops->requeue(skb, q->qdisc); From davem@davemloft.net Mon May 23 11:44:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 11:44:25 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NIiLF3024087 for ; Mon, 23 May 2005 11:44:21 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaHtj-0001h1-FD; Mon, 23 May 2005 11:43:31 -0700 Date: Mon, 23 May 2005 11:43:31 -0700 (PDT) Message-Id: <20050523.114331.104031931.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO v2 From: "David S. Miller" In-Reply-To: <20050523095417.GA18770@gondor.apana.org.au> References: <20050520.115154.48807299.davem@davemloft.net> <20050523095417.GA18770@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1024 Lines: 28 From: Herbert Xu Date: Mon, 23 May 2005 19:54:17 +1000 > Perhaps we should set the goal based on the cwnd as we do now? > > As it is I believe we may be doing more work compared to the > status quo because it's always building 64K blocks and then > cutting them up as dictated by the cwnd. On the other hand, the > current code simply builds the packets up to the size that cwnd > allows. I played with this, and it makes no difference. It would only help when: 1) we are building sk->sk_send_head, and 2) sk->sk_send_head is the tail of the write queue But the SKB splitting is so cheap that it doesn't show up. And if we sleep or defer for some reason, say while copying the data from userspace or whatever, all of this information changes and we don't bunch up as much as we could have. Also, in my current code we defer sending not just at ACK arrive processing, but also when doing normal sends from sendmsg() and sendpages(). Which totally invalidates your suggested scheme :-) From jdmason@us.ibm.com Mon May 23 12:15:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 12:15:56 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NJFfF3026332 for ; Mon, 23 May 2005 12:15:48 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4NJEn0c424636 for ; Mon, 23 May 2005 15:14:53 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4NJEmPd221112 for ; Mon, 23 May 2005 13:14:48 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4NJEmBr027798 for ; Mon, 23 May 2005 13:14:48 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4NJE1Fa022865; Mon, 23 May 2005 13:14:01 -0600 From: Jon Mason Organization: IBM To: "Catalin(ux aka Dino) BOIE" Subject: Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming) Date: Mon, 23 May 2005 14:14:00 -0500 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com, davem@davemloft.net References: <200505201354.46824.jdmason@us.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505231414.00146.jdmason@us.ibm.com> X-archive-position: 1501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 177 Lines: 7 > The code applies the ~ first, then the | and _then_ the &. > If we have: > a &= a | ~b; > it is equivalent with: > a = a & (a | ~b); Ah, that is what I was missing. Sorry. From davem@davemloft.net Mon May 23 12:20:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 12:20:36 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NJKVF3030611 for ; Mon, 23 May 2005 12:20:31 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaISl-0002HW-4f for netdev@oss.sgi.com; Mon, 23 May 2005 12:19:43 -0700 Date: Mon, 23 May 2005 12:19:43 -0700 (PDT) Message-Id: <20050523.121943.78708600.davem@davemloft.net> To: netdev@oss.sgi.com Subject: [PATCH] Super TSO v3 From: "David S. Miller" X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_May_23_12_19_43_2005_835)--" Content-Transfer-Encoding: 7bit X-archive-position: 1502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 43149 Lines: 1410 ----Next_Part(Mon_May_23_12_19_43_2005_835)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok, new version. This weekend has been productive. I discoevered a performance anomaly with Linux receivers, cause by enormous stretch ACK generation, which you'll need to fix if you want to test this patch against Linux receivers. When we do ucopy receive (ie. copying directly to userspace during tcp input processing) we attempt to delay the ACK until cleanup_rbuf() is invoked. Most of the time this technique works very well, and we emit one ACK advertising the largest window. But this explodes if the ucopy prequeue is large enough. When the receiver is cpu limited and TSO frames are large, the receiver is inundated with ucopy processing, such that the ACK comes out very late. Often, this is so late that by the time the sender gets the ACK the window has emptied too much to be kept full by the sender. The existing TSO code mostly avoided this by keeping the TSO packets no larger than 1/8 of the available window. But with the new code we can get much larger TSO frames. The other major change now is that we do TSO deferral both at sendmsg()/sendpage() packet send time, as well as when processing ACKs to make progress in the write queue. The guts of the logic is in tcp_tso_should_defer(). And when dealing with a TSO frame, tcp_write_xmit() calls this instead of tcp_nagle_test(). So you can view this deferral as a sort of "TSO Nagle". In v2, there was some code that checked if in_flight was non-zero, to make sure we will get some ACKs back, but that is implicitly handled by the "1/tso_win_divisor" check. Potential cleanups are of course still sprinkled all over. For example, __tcp_push_pending_frames() and __tcp_data_snd_check() are basically identical now. _iff_ you test this code, please make sure the receiver bug fix is installed on any Linux systems you are using as the receiver in your testing. There are three attachments: 1) the 2.6.12-rcX Super TSO patch v3 2) the 2.6.12.rcX TCP receiver bug fix 3) the 2.4.30 TCP receiver bug fix Enjoy. ----Next_Part(Mon_May_23_12_19_43_2005_835)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_super_tso.diff" --- 1/include/linux/tcp.h.~1~ 2005-05-20 22:12:09.000000000 -0700 +++ 2/include/linux/tcp.h 2005-05-20 22:12:22.000000000 -0700 @@ -280,13 +280,15 @@ struct tcp_sock { __u32 snd_wnd; /* The window we expect to receive */ __u32 max_window; /* Maximal window ever seen from peer */ __u32 pmtu_cookie; /* Last pmtu seen by socket */ - __u32 mss_cache; /* Cached effective mss, not including SACKS */ - __u16 mss_cache_std; /* Like mss_cache, but without TSO */ + __u16 mss_cache; /* Cached effective mss, not including SACKS */ + __u16 xmit_size_goal; /* Goal for segmenting output packets */ + __u32 xmit_size_cache;/* Cache for keeping xmit_size_goal uptodate */ __u16 ext_header_len; /* Network protocol overhead (IP/IPv6 options) */ __u8 ca_state; /* State of fast-retransmit machine */ __u8 retransmits; /* Number of unrecovered RTO timeouts. */ __u16 advmss; /* Advertised MSS */ + __u16 deferred; /* Packets deferred for segmentation */ __u32 window_clamp; /* Maximal window to advertise */ __u32 rcv_ssthresh; /* Current window clamp */ --- 1/include/net/sock.h.~1~ 2005-05-20 22:12:09.000000000 -0700 +++ 2/include/net/sock.h 2005-05-20 22:12:22.000000000 -0700 @@ -1130,13 +1130,16 @@ static inline void sk_stream_moderate_sn static inline struct sk_buff *sk_stream_alloc_pskb(struct sock *sk, int size, int mem, int gfp) { - struct sk_buff *skb = alloc_skb(size + sk->sk_prot->max_header, gfp); + struct sk_buff *skb; + int hdr_len; + hdr_len = SKB_DATA_ALIGN(sk->sk_prot->max_header); + skb = alloc_skb(size + hdr_len, gfp); if (skb) { skb->truesize += mem; if (sk->sk_forward_alloc >= (int)skb->truesize || sk_stream_mem_schedule(sk, skb->truesize, 0)) { - skb_reserve(skb, sk->sk_prot->max_header); + skb_reserve(skb, hdr_len); return skb; } __kfree_skb(skb); --- 1/include/net/tcp.h.~1~ 2005-05-20 22:12:09.000000000 -0700 +++ 2/include/net/tcp.h 2005-05-22 21:38:48.000000000 -0700 @@ -817,11 +817,18 @@ static inline int tcp_ack_scheduled(stru return tp->ack.pending&TCP_ACK_SCHED; } -static __inline__ void tcp_dec_quickack_mode(struct tcp_sock *tp) +static __inline__ void tcp_dec_quickack_mode(struct tcp_sock *tp, unsigned int pkts) { - if (tp->ack.quick && --tp->ack.quick == 0) { - /* Leaving quickack mode we deflate ATO. */ - tp->ack.ato = TCP_ATO_MIN; + if (tp->ack.quick) { + if (pkts > tp->ack.quick) + tp->ack.quick = 0; + else + tp->ack.quick -= pkts; + + if (!tp->ack.quick) { + /* Leaving quickack mode we deflate ATO. */ + tp->ack.ato = TCP_ATO_MIN; + } } } @@ -939,7 +946,14 @@ extern __u32 cookie_v4_init_sequence(str /* tcp_output.c */ -extern int tcp_write_xmit(struct sock *, int nonagle); +extern void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb); +extern void __tcp_push_pending_frames(struct sock *sk, + struct tcp_sock *tp, + unsigned int cur_mss, + int nonagle); +extern int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp); +extern int tcp_tso_mince(struct sock *sk, struct tcp_sock *tp, + struct sk_buff *skb); extern int tcp_retransmit_skb(struct sock *, struct sk_buff *); extern void tcp_xmit_retransmit_queue(struct sock *); extern void tcp_simple_retransmit(struct sock *); @@ -951,7 +965,7 @@ extern int tcp_write_wakeup(struct sock extern void tcp_send_fin(struct sock *sk); extern void tcp_send_active_reset(struct sock *sk, int priority); extern int tcp_send_synack(struct sock *); -extern void tcp_push_one(struct sock *, unsigned mss_now); +extern void tcp_push_one(struct sock *, unsigned int mss_now); extern void tcp_send_ack(struct sock *sk); extern void tcp_send_delayed_ack(struct sock *sk); @@ -1054,7 +1068,7 @@ static inline void tcp_reset_xmit_timer( static inline void tcp_initialize_rcv_mss(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); - unsigned int hint = min(tp->advmss, tp->mss_cache_std); + unsigned int hint = min(tp->advmss, tp->mss_cache); hint = min(hint, tp->rcv_wnd/2); hint = min(hint, TCP_MIN_RCVMSS); @@ -1353,23 +1367,23 @@ static inline void tcp_cwnd_validate(str } /* Set slow start threshould and cwnd not falling to slow start */ -static inline void __tcp_enter_cwr(struct tcp_sock *tp) +static inline void __tcp_enter_cwr(struct tcp_sock *tp, unsigned int pkts) { tp->undo_marker = 0; tp->snd_ssthresh = tcp_recalc_ssthresh(tp); tp->snd_cwnd = min(tp->snd_cwnd, - tcp_packets_in_flight(tp) + 1U); + tcp_packets_in_flight(tp) + pkts); tp->snd_cwnd_cnt = 0; tp->high_seq = tp->snd_nxt; tp->snd_cwnd_stamp = tcp_time_stamp; TCP_ECN_queue_cwr(tp); } -static inline void tcp_enter_cwr(struct tcp_sock *tp) +static inline void tcp_enter_cwr(struct tcp_sock *tp, unsigned int pkts) { tp->prior_ssthresh = 0; if (tp->ca_state < TCP_CA_CWR) { - __tcp_enter_cwr(tp); + __tcp_enter_cwr(tp, pkts); tcp_set_ca_state(tp, TCP_CA_CWR); } } @@ -1397,74 +1411,6 @@ static __inline__ void tcp_minshall_upda tp->snd_sml = TCP_SKB_CB(skb)->end_seq; } -/* Return 0, if packet can be sent now without violation Nagle's rules: - 1. It is full sized. - 2. Or it contains FIN. - 3. Or TCP_NODELAY was set. - 4. Or TCP_CORK is not set, and all sent packets are ACKed. - With Minshall's modification: all sent small packets are ACKed. - */ - -static __inline__ int -tcp_nagle_check(const struct tcp_sock *tp, const struct sk_buff *skb, - unsigned mss_now, int nonagle) -{ - return (skb->len < mss_now && - !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && - ((nonagle&TCP_NAGLE_CORK) || - (!nonagle && - tp->packets_out && - tcp_minshall_check(tp)))); -} - -extern void tcp_set_skb_tso_segs(struct sock *, struct sk_buff *); - -/* This checks if the data bearing packet SKB (usually sk->sk_send_head) - * should be put on the wire right now. - */ -static __inline__ int tcp_snd_test(struct sock *sk, - struct sk_buff *skb, - unsigned cur_mss, int nonagle) -{ - struct tcp_sock *tp = tcp_sk(sk); - int pkts = tcp_skb_pcount(skb); - - if (!pkts) { - tcp_set_skb_tso_segs(sk, skb); - pkts = tcp_skb_pcount(skb); - } - - /* RFC 1122 - section 4.2.3.4 - * - * We must queue if - * - * a) The right edge of this frame exceeds the window - * b) There are packets in flight and we have a small segment - * [SWS avoidance and Nagle algorithm] - * (part of SWS is done on packetization) - * Minshall version sounds: there are no _small_ - * segments in flight. (tcp_nagle_check) - * c) We have too many packets 'in flight' - * - * Don't use the nagle rule for urgent data (or - * for the final FIN -DaveM). - * - * Also, Nagle rule does not apply to frames, which - * sit in the middle of queue (they have no chances - * to get new data) and if room at tail of skb is - * not enough to save something seriously (<32 for now). - */ - - /* Don't be strict about the congestion window for the - * final FIN frame. -DaveM - */ - return (((nonagle&TCP_NAGLE_PUSH) || tp->urg_mode - || !tcp_nagle_check(tp, skb, cur_mss, nonagle)) && - (((tcp_packets_in_flight(tp) + (pkts-1)) < tp->snd_cwnd) || - (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) && - !after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd)); -} - static __inline__ void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp) { if (!tp->packets_out && !tp->pending) @@ -1477,42 +1423,12 @@ static __inline__ int tcp_skb_is_last(co return skb->next == (struct sk_buff *)&sk->sk_write_queue; } -/* Push out any pending frames which were held back due to - * TCP_CORK or attempt at coalescing tiny packets. - * The socket must be locked by the caller. - */ -static __inline__ void __tcp_push_pending_frames(struct sock *sk, - struct tcp_sock *tp, - unsigned cur_mss, - int nonagle) -{ - struct sk_buff *skb = sk->sk_send_head; - - if (skb) { - if (!tcp_skb_is_last(sk, skb)) - nonagle = TCP_NAGLE_PUSH; - if (!tcp_snd_test(sk, skb, cur_mss, nonagle) || - tcp_write_xmit(sk, nonagle)) - tcp_check_probe_timer(sk, tp); - } - tcp_cwnd_validate(sk, tp); -} - static __inline__ void tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp) { __tcp_push_pending_frames(sk, tp, tcp_current_mss(sk, 1), tp->nonagle); } -static __inline__ int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp) -{ - struct sk_buff *skb = sk->sk_send_head; - - return (skb && - tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), - tcp_skb_is_last(sk, skb) ? TCP_NAGLE_PUSH : tp->nonagle)); -} - static __inline__ void tcp_init_wl(struct tcp_sock *tp, u32 ack, u32 seq) { tp->snd_wl1 = seq; @@ -1986,7 +1902,7 @@ static inline void tcp_westwood_update_r static inline __u32 __tcp_westwood_bw_rttmin(const struct tcp_sock *tp) { return max((tp->westwood.bw_est) * (tp->westwood.rtt_min) / - (__u32) (tp->mss_cache_std), + (__u32) (tp->mss_cache), 2U); } --- 1/net/ipv4/tcp.c.~1~ 2005-05-20 22:12:09.000000000 -0700 +++ 2/net/ipv4/tcp.c 2005-05-22 21:39:38.000000000 -0700 @@ -634,7 +634,7 @@ static ssize_t do_tcp_sendpages(struct s size_t psize, int flags) { struct tcp_sock *tp = tcp_sk(sk); - int mss_now; + int mss_now, size_goal; int err; ssize_t copied; long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT); @@ -647,6 +647,7 @@ static ssize_t do_tcp_sendpages(struct s clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; copied = 0; err = -EPIPE; @@ -660,7 +661,7 @@ static ssize_t do_tcp_sendpages(struct s int offset = poffset % PAGE_SIZE; int size = min_t(size_t, psize, PAGE_SIZE - offset); - if (!sk->sk_send_head || (copy = mss_now - skb->len) <= 0) { + if (!sk->sk_send_head || (copy = size_goal - skb->len) <= 0) { new_segment: if (!sk_stream_memory_free(sk)) goto wait_for_sndbuf; @@ -671,7 +672,7 @@ new_segment: goto wait_for_memory; skb_entail(sk, tp, skb); - copy = mss_now; + copy = size_goal; } if (copy > size) @@ -712,7 +713,7 @@ new_segment: if (!(psize -= copy)) goto out; - if (skb->len != mss_now || (flags & MSG_OOB)) + if (skb->len != size_goal || (flags & MSG_OOB)) continue; if (forced_push(tp)) { @@ -732,6 +733,7 @@ wait_for_memory: goto do_error; mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; } out: @@ -773,15 +775,11 @@ ssize_t tcp_sendpage(struct socket *sock static inline int select_size(struct sock *sk, struct tcp_sock *tp) { - int tmp = tp->mss_cache_std; + int tmp = tp->mss_cache; - if (sk->sk_route_caps & NETIF_F_SG) { - int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER); + if (sk->sk_route_caps & NETIF_F_SG) + tmp = 0; - if (tmp >= pgbreak && - tmp <= pgbreak + (MAX_SKB_FRAGS - 1) * PAGE_SIZE) - tmp = pgbreak; - } return tmp; } @@ -792,7 +790,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *skb; int iovlen, flags; - int mss_now; + int mss_now, size_goal; int err, copied; long timeo; @@ -811,6 +809,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; /* Ok commence sending. */ iovlen = msg->msg_iovlen; @@ -833,7 +832,7 @@ int tcp_sendmsg(struct kiocb *iocb, stru skb = sk->sk_write_queue.prev; if (!sk->sk_send_head || - (copy = mss_now - skb->len) <= 0) { + (copy = size_goal - skb->len) <= 0) { new_segment: /* Allocate new segment. If the interface is SG, @@ -856,7 +855,7 @@ new_segment: skb->ip_summed = CHECKSUM_HW; skb_entail(sk, tp, skb); - copy = mss_now; + copy = size_goal; } /* Try to append data to the end of skb. */ @@ -891,11 +890,6 @@ new_segment: tcp_mark_push(tp, skb); goto new_segment; } else if (page) { - /* If page is cached, align - * offset to L1 cache boundary - */ - off = (off + L1_CACHE_BYTES - 1) & - ~(L1_CACHE_BYTES - 1); if (off == PAGE_SIZE) { put_page(page); TCP_PAGE(sk) = page = NULL; @@ -956,7 +950,7 @@ new_segment: if ((seglen -= copy) == 0 && iovlen == 0) goto out; - if (skb->len != mss_now || (flags & MSG_OOB)) + if (skb->len != size_goal || (flags & MSG_OOB)) continue; if (forced_push(tp)) { @@ -976,6 +970,7 @@ wait_for_memory: goto do_error; mss_now = tcp_current_mss(sk, !(flags&MSG_OOB)); + size_goal = tp->xmit_size_goal; } } @@ -2135,7 +2130,7 @@ void tcp_get_info(struct sock *sk, struc info->tcpi_rto = jiffies_to_usecs(tp->rto); info->tcpi_ato = jiffies_to_usecs(tp->ack.ato); - info->tcpi_snd_mss = tp->mss_cache_std; + info->tcpi_snd_mss = tp->mss_cache; info->tcpi_rcv_mss = tp->ack.rcv_mss; info->tcpi_unacked = tp->packets_out; @@ -2185,7 +2180,7 @@ int tcp_getsockopt(struct sock *sk, int switch (optname) { case TCP_MAXSEG: - val = tp->mss_cache_std; + val = tp->mss_cache; if (!val && ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN))) val = tp->rx_opt.user_mss; break; --- 1/net/ipv4/tcp_input.c.~1~ 2005-05-20 22:12:09.000000000 -0700 +++ 2/net/ipv4/tcp_input.c 2005-05-23 11:53:05.000000000 -0700 @@ -805,10 +805,10 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp, __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0); if (!cwnd) { - if (tp->mss_cache_std > 1460) + if (tp->mss_cache > 1460) cwnd = 2; else - cwnd = (tp->mss_cache_std > 1095) ? 3 : 4; + cwnd = (tp->mss_cache > 1095) ? 3 : 4; } return min_t(__u32, cwnd, tp->snd_cwnd_clamp); } @@ -974,14 +974,6 @@ tcp_sacktag_write_queue(struct sock *sk, int flag = 0; int i; - /* So, SACKs for already sent large segments will be lost. - * Not good, but alternative is to resegment the queue. */ - if (sk->sk_route_caps & NETIF_F_TSO) { - sk->sk_route_caps &= ~NETIF_F_TSO; - sock_set_flag(sk, SOCK_NO_LARGESEND); - tp->mss_cache = tp->mss_cache_std; - } - if (!tp->sacked_out) tp->fackets_out = 0; prior_fackets = tp->fackets_out; @@ -1038,6 +1030,15 @@ tcp_sacktag_write_queue(struct sock *sk, if(!before(TCP_SKB_CB(skb)->seq, end_seq)) break; + /* Even if mincing a TSO frame fails, we + * continue anyways. We will end up with + * more coarse SACK information, but it is + * better than ignoring all the SACK information + * altogether. + */ + if (tcp_skb_pcount(skb) > 1) + tcp_tso_mince(sk, tp, skb); + fack_count += tcp_skb_pcount(skb); in_sack = !after(start_seq, TCP_SKB_CB(skb)->seq) && @@ -1142,7 +1143,7 @@ tcp_sacktag_write_queue(struct sock *sk, (IsFack(tp) || !before(lost_retrans, TCP_SKB_CB(skb)->ack_seq + tp->reordering * - tp->mss_cache_std))) { + tp->mss_cache))) { TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS; tp->retrans_out -= tcp_skb_pcount(skb); @@ -1782,7 +1783,7 @@ static void tcp_try_to_open(struct sock tp->retrans_stamp = 0; if (flag&FLAG_ECE) - tcp_enter_cwr(tp); + tcp_enter_cwr(tp, 1); if (tp->ca_state != TCP_CA_CWR) { int state = TCP_CA_Open; @@ -2170,7 +2171,7 @@ static void vegas_cong_avoid(struct tcp_ * is the cwnd during the previous RTT. */ old_wnd = (tp->vegas.beg_snd_nxt - tp->vegas.beg_snd_una) / - tp->mss_cache_std; + tp->mss_cache; old_snd_cwnd = tp->vegas.beg_snd_cwnd; /* Save the extent of the current window so we can use this @@ -2799,19 +2800,19 @@ static void westwood_dupack_update(struc { struct tcp_sock *tp = tcp_sk(sk); - tp->westwood.accounted += tp->mss_cache_std; - tp->westwood.cumul_ack = tp->mss_cache_std; + tp->westwood.accounted += tp->mss_cache; + tp->westwood.cumul_ack = tp->mss_cache; } static inline int westwood_may_change_cumul(struct tcp_sock *tp) { - return (tp->westwood.cumul_ack > tp->mss_cache_std); + return (tp->westwood.cumul_ack > tp->mss_cache); } static inline void westwood_partial_update(struct tcp_sock *tp) { tp->westwood.accounted -= tp->westwood.cumul_ack; - tp->westwood.cumul_ack = tp->mss_cache_std; + tp->westwood.cumul_ack = tp->mss_cache; } static inline void westwood_complete_update(struct tcp_sock *tp) @@ -2932,7 +2933,7 @@ static int tcp_ack(struct sock *sk, stru if (!prior_packets) goto no_queue; - prior_in_flight = tcp_packets_in_flight(tp); + prior_in_flight = tcp_packets_in_flight(tp) + tp->deferred; /* See if we can take anything off of the retransmit queue. */ flag |= tcp_clean_rtx_queue(sk, &seq_rtt); @@ -3948,11 +3949,11 @@ static void tcp_new_space(struct sock *s { struct tcp_sock *tp = tcp_sk(sk); - if (tp->packets_out < tp->snd_cwnd && + if ((tp->packets_out + tp->deferred) < tp->snd_cwnd && !(sk->sk_userlocks & SOCK_SNDBUF_LOCK) && !tcp_memory_pressure && atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0]) { - int sndmem = max_t(u32, tp->rx_opt.mss_clamp, tp->mss_cache_std) + + int sndmem = max_t(u32, tp->rx_opt.mss_clamp, tp->mss_cache) + MAX_TCP_HEADER + 16 + sizeof(struct sk_buff), demanded = max_t(unsigned int, tp->snd_cwnd, tp->reordering + 1); @@ -3975,16 +3976,6 @@ static inline void tcp_check_space(struc } } -static void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb) -{ - struct tcp_sock *tp = tcp_sk(sk); - - if (after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd) || - tcp_packets_in_flight(tp) >= tp->snd_cwnd || - tcp_write_xmit(sk, tp->nonagle)) - tcp_check_probe_timer(sk, tp); -} - static __inline__ void tcp_data_snd_check(struct sock *sk) { struct sk_buff *skb = sk->sk_send_head; --- 1/net/ipv4/tcp_ipv4.c.~1~ 2005-05-20 22:12:09.000000000 -0700 +++ 2/net/ipv4/tcp_ipv4.c 2005-05-20 22:12:22.000000000 -0700 @@ -2060,7 +2060,8 @@ static int tcp_v4_init_sock(struct sock */ tp->snd_ssthresh = 0x7fffffff; /* Infinity */ tp->snd_cwnd_clamp = ~0; - tp->mss_cache_std = tp->mss_cache = 536; + tp->mss_cache = 536; + tp->xmit_size_cache = ~0; tp->reordering = sysctl_tcp_reordering; --- 1/net/ipv4/tcp_output.c.~1~ 2005-05-20 22:12:09.000000000 -0700 +++ 2/net/ipv4/tcp_output.c 2005-05-22 21:44:07.000000000 -0700 @@ -58,6 +58,7 @@ static inline void update_send_head(stru if (sk->sk_send_head == (struct sk_buff *)&sk->sk_write_queue) sk->sk_send_head = NULL; tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; + tp->deferred = 0; tcp_packets_out_inc(sk, tp, skb); } @@ -141,11 +142,11 @@ static inline void tcp_event_data_sent(s tp->ack.pingpong = 1; } -static __inline__ void tcp_event_ack_sent(struct sock *sk) +static __inline__ void tcp_event_ack_sent(struct sock *sk, unsigned int pkts) { struct tcp_sock *tp = tcp_sk(sk); - tcp_dec_quickack_mode(tp); + tcp_dec_quickack_mode(tp, pkts); tcp_clear_xmit_timer(sk, TCP_TIME_DACK); } @@ -361,7 +362,7 @@ static int tcp_transmit_skb(struct sock tp->af_specific->send_check(sk, th, skb->len, skb); if (tcb->flags & TCPCB_FLAG_ACK) - tcp_event_ack_sent(sk); + tcp_event_ack_sent(sk, tcp_skb_pcount(skb)); if (skb->len != tcp_header_size) tcp_event_data_sent(tp, skb, sk); @@ -372,7 +373,7 @@ static int tcp_transmit_skb(struct sock if (err <= 0) return err; - tcp_enter_cwr(tp); + tcp_enter_cwr(tp, tcp_skb_pcount(skb)); /* NET_XMIT_CN is special. It does not guarantee, * that this packet is lost. It tells that device @@ -409,42 +410,11 @@ static void tcp_queue_skb(struct sock *s sk->sk_send_head = skb; } -static inline void tcp_tso_set_push(struct sk_buff *skb) -{ - /* Force push to be on for any TSO frames to workaround - * problems with busted implementations like Mac OS-X that - * hold off socket receive wakeups until push is seen. - */ - if (tcp_skb_pcount(skb) > 1) - TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; -} - -/* Send _single_ skb sitting at the send head. This function requires - * true push pending frames to setup probe timer etc. - */ -void tcp_push_one(struct sock *sk, unsigned cur_mss) -{ - struct tcp_sock *tp = tcp_sk(sk); - struct sk_buff *skb = sk->sk_send_head; - - if (tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH)) { - /* Send it out now. */ - TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); - if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { - sk->sk_send_head = NULL; - tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; - tcp_packets_out_inc(sk, tp, skb); - return; - } - } -} - void tcp_set_skb_tso_segs(struct sock *sk, struct sk_buff *skb) { struct tcp_sock *tp = tcp_sk(sk); - if (skb->len <= tp->mss_cache_std || + if (skb->len <= tp->mss_cache || !(sk->sk_route_caps & NETIF_F_TSO)) { /* Avoid the costly divide in the normal * non-TSO case. @@ -454,10 +424,10 @@ void tcp_set_skb_tso_segs(struct sock *s } else { unsigned int factor; - factor = skb->len + (tp->mss_cache_std - 1); - factor /= tp->mss_cache_std; + factor = skb->len + (tp->mss_cache - 1); + factor /= tp->mss_cache; skb_shinfo(skb)->tso_segs = factor; - skb_shinfo(skb)->tso_size = tp->mss_cache_std; + skb_shinfo(skb)->tso_size = tp->mss_cache; } } @@ -542,6 +512,7 @@ static int tcp_fragment(struct sock *sk, } /* Link BUFF into the send queue. */ + skb_header_release(buff); __skb_append(skb, buff); return 0; @@ -662,7 +633,7 @@ unsigned int tcp_sync_mss(struct sock *s /* And store cached results */ tp->pmtu_cookie = pmtu; - tp->mss_cache = tp->mss_cache_std = mss_now; + tp->mss_cache = mss_now; return mss_now; } @@ -674,117 +645,477 @@ unsigned int tcp_sync_mss(struct sock *s * cannot be large. However, taking into account rare use of URG, this * is not a big flaw. */ +static inline u32 compute_xmit_cache(u32 mss, int sacks, int tso_enabled) +{ + u32 ret = (mss << 16) | sacks; -unsigned int tcp_current_mss(struct sock *sk, int large) + if (tso_enabled) + ret |= (1 << 8); + + return ret; +} + +unsigned int tcp_current_mss(struct sock *sk, int large_allowed) { struct tcp_sock *tp = tcp_sk(sk); struct dst_entry *dst = __sk_dst_get(sk); - unsigned int do_large, mss_now; + u32 mss_now; + u32 xmit_cache; + int doing_tso = 0; + + mss_now = tp->mss_cache; + + if (large_allowed && + (sk->sk_route_caps & NETIF_F_TSO) && + !tp->urg_mode) + doing_tso = 1; - mss_now = tp->mss_cache_std; if (dst) { u32 mtu = dst_mtu(dst); if (mtu != tp->pmtu_cookie) mss_now = tcp_sync_mss(sk, mtu); } - do_large = (large && - (sk->sk_route_caps & NETIF_F_TSO) && - !tp->urg_mode); - - if (do_large) { - unsigned int large_mss, factor, limit; - - large_mss = 65535 - tp->af_specific->net_header_len - - tp->ext_header_len - tp->tcp_header_len; - - if (tp->max_window && large_mss > (tp->max_window>>1)) - large_mss = max((tp->max_window>>1), - 68U - tp->tcp_header_len); - - factor = large_mss / mss_now; - - /* Always keep large mss multiple of real mss, but - * do not exceed 1/tso_win_divisor of the congestion window - * so we can keep the ACK clock ticking and minimize - * bursting. - */ - limit = tp->snd_cwnd; - if (sysctl_tcp_tso_win_divisor) - limit /= sysctl_tcp_tso_win_divisor; - limit = max(1U, limit); - if (factor > limit) - factor = limit; - - tp->mss_cache = mss_now * factor; - - mss_now = tp->mss_cache; - } + /* If the MSS, the TSO state, or the number of SACK blocks + * changes, we have to recompute tp->xmit_size_goal. + */ + xmit_cache = compute_xmit_cache(mss_now, tp->rx_opt.eff_sacks, + doing_tso); if (tp->rx_opt.eff_sacks) mss_now -= (TCPOLEN_SACK_BASE_ALIGNED + (tp->rx_opt.eff_sacks * TCPOLEN_SACK_PERBLOCK)); + + if (tp->xmit_size_cache != xmit_cache) { + u16 xmit_size_goal = mss_now; + + if (doing_tso) { + xmit_size_goal = 65535 - + tp->af_specific->net_header_len - + tp->ext_header_len - tp->tcp_header_len; + + if (tp->rx_opt.eff_sacks) + xmit_size_goal -= (TCPOLEN_SACK_BASE_ALIGNED + + (tp->rx_opt.eff_sacks * + TCPOLEN_SACK_PERBLOCK)); + + xmit_size_goal -= (xmit_size_goal % mss_now); + } + tp->xmit_size_goal = xmit_size_goal; + tp->xmit_size_cache = xmit_cache; + } + return mss_now; } +static unsigned int tcp_window_allows(struct tcp_sock *tp, struct sk_buff *skb, unsigned int mss_now, unsigned int cwnd) +{ + u32 window, cwnd_len; + + window = (tp->snd_una + tp->snd_wnd - TCP_SKB_CB(skb)->seq); + cwnd_len = mss_now * cwnd; + return min(window, cwnd_len); +} + +/* Can at least one segment of SKB be sent right now, according + * to the congestion window rules? If so, return how many segments + * are allowed. + */ +static inline unsigned int tcp_cwnd_test(struct tcp_sock *tp, struct sk_buff *skb) +{ + u32 in_flight, cwnd; + + /* Don't be strict about the congestion window for the + * final FIN frame. -DaveM + */ + if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) + return 1; + + in_flight = tcp_packets_in_flight(tp); + cwnd = tp->snd_cwnd; + if (in_flight < cwnd) + return (cwnd - in_flight); + + return 0; +} + +/* This must be invoked the first time we consider transmitting + * SKB onto the wire. + */ +static inline int tcp_init_tso_segs(struct sock *sk, struct sk_buff *skb) +{ + int tso_segs = tcp_skb_pcount(skb); + + if (!tso_segs) { + tcp_set_skb_tso_segs(sk, skb); + tso_segs = tcp_skb_pcount(skb); + } + return tso_segs; +} + +/* Return 0, if packet can be sent now without violation Nagle's rules: + * 1. It is full sized. + * 2. Or it contains FIN. + * 3. Or TCP_NODELAY was set. + * 4. Or TCP_CORK is not set, and all sent packets are ACKed. + * With Minshall's modification: all sent small packets are ACKed. + */ + +static inline int tcp_nagle_check(const struct tcp_sock *tp, + const struct sk_buff *skb, + unsigned mss_now, int nonagle) +{ + return (skb->len < mss_now && + !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && + ((nonagle&TCP_NAGLE_CORK) || + (!nonagle && + tp->packets_out && + tcp_minshall_check(tp)))); +} + +/* Return non-zero if the Nagle test allows this packet to be + * sent now. + */ +static inline int tcp_nagle_test(struct tcp_sock *tp, struct sk_buff *skb, unsigned int cur_mss, int nonagle) +{ + /* Nagle rule does not apply to frames, which + * sit in the middle of queue (they have no chances + * to get new data). + * + * This is implemented in the callers, where they modify + * the 'nonagle' argument based upon the location of SKB + * in the send queue. + */ + if (nonagle & TCP_NAGLE_PUSH) + return 1; + + /* Don't use the nagle rule for urgent data (or + * for the final FIN -DaveM). + */ + if (tp->urg_mode || + (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) + return 1; + + if (!tcp_nagle_check(tp, skb, cur_mss, nonagle)) + return 1; + + return 0; +} + +/* Does at least the first segment of SKB fit into the congestion + * window? + */ +static inline int tcp_snd_wnd_test(struct tcp_sock *tp, struct sk_buff *skb, unsigned int cur_mss) +{ + u32 end_seq = TCP_SKB_CB(skb)->end_seq; + + if (skb->len > cur_mss) + end_seq = TCP_SKB_CB(skb)->seq + cur_mss; + + return !after(end_seq, tp->snd_una + tp->snd_wnd); +} + +/* This checks if the data bearing packet SKB (usually + * sk->sk_send_head) should be put on the wire right now. If so, it + * returns the number of packets allowed by the congestion window. + */ +static unsigned int tcp_snd_test(struct sock *sk, struct sk_buff *skb, + unsigned cur_mss, int nonagle) +{ + struct tcp_sock *tp = tcp_sk(sk); + unsigned int cwnd_quota; + + if (!tcp_nagle_test(tp, skb, cur_mss, nonagle)) + return 0; + + cwnd_quota = tcp_cwnd_test(tp, skb); + if (cwnd_quota && + !tcp_snd_wnd_test(tp, skb, cur_mss)) + cwnd_quota = 0; + + return cwnd_quota; +} + +int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp) +{ + struct sk_buff *skb = sk->sk_send_head; + + return (skb && + tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), + tcp_skb_is_last(sk, skb) ? TCP_NAGLE_PUSH : tp->nonagle)); +} + +/* Trim TSO SKB to LEN bytes, put the remaining data into a new packet + * which is put after SKB on the list. It is very much like + * tcp_fragment() except that it may make several kinds of assumptions + * in order to speed up the splitting operation. In particular, we + * know that all the data is in scatter-gather pages, and that the + * packet has never been sent out before (and thus is not cloned). + */ +static int tso_fragment(struct sock *sk, struct sk_buff *skb, unsigned int len) +{ + struct sk_buff *buff; + int nlen = skb->len - len; + u16 flags; + + /* All of a TSO frame must be composed of paged data. */ + BUG_ON(skb->len != skb->data_len); + + buff = sk_stream_alloc_pskb(sk, 0, 0, GFP_ATOMIC); + if (unlikely(buff == NULL)) + return -ENOMEM; + sk_charge_skb(sk, buff); + + buff->truesize += nlen; + skb->truesize -= nlen; + + /* Correct the sequence numbers. */ + TCP_SKB_CB(buff)->seq = TCP_SKB_CB(skb)->seq + len; + TCP_SKB_CB(buff)->end_seq = TCP_SKB_CB(skb)->end_seq; + TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(buff)->seq; + + /* PSH and FIN should only be set in the second packet. */ + flags = TCP_SKB_CB(skb)->flags; + TCP_SKB_CB(skb)->flags = flags & ~(TCPCB_FLAG_FIN|TCPCB_FLAG_PSH); + TCP_SKB_CB(buff)->flags = flags; + + /* This packet was never sent out yet, so no SACK bits. */ + TCP_SKB_CB(buff)->sacked = 0; + + buff->ip_summed = skb->ip_summed = CHECKSUM_HW; + skb_split(skb, buff, len); + + /* Fix up tso_factor for both original and new SKB. */ + tcp_set_skb_tso_segs(sk, skb); + tcp_set_skb_tso_segs(sk, buff); + + /* Link BUFF into the send queue. */ + skb_header_release(buff); + __skb_append(skb, buff); + + return 0; +} + +/* Split TSO frame SKB into one MSS sized packet, then the rest. + * This is called during SACK processing when some SACK information + * hits a TSO packet. + */ +int tcp_tso_mince(struct sock *sk, struct tcp_sock *tp, struct sk_buff *skb) +{ + unsigned int mss_now = tcp_current_mss(sk, 1); + + BUG_ON(tcp_skb_pcount(skb) <= 1); + + /* We cannot use tso_fragment() in this case, because + * the packet has been sent once already and thus may + * be cloned or have other non-trivial details to deal + * with. + */ + return tcp_fragment(sk, skb, mss_now); +} + +/* Try to defer sending, if possible, in order + * to minimize the amount of TSO splitting we do. + * View it as a kind of TSO Nagle test. + * + * This algorithm is from John Heffner. + * + * We know that "tcp_skb_pcount(skb) > 1" and also + * that "tp->snd_cwnd > tcp_packets_in_flight(tp)". + */ +static int tcp_tso_should_defer(struct sock *sk, struct tcp_sock *tp, struct sk_buff *skb) +{ + u32 send_win, cong_win, limit, chunk, in_flight; + + in_flight = tcp_packets_in_flight(tp); + + BUG_ON(tcp_skb_pcount(skb) <= 1 || + (tp->snd_cwnd <= in_flight)); + + send_win = (tp->snd_una + tp->snd_wnd) - TCP_SKB_CB(skb)->seq; + + /* From in_flight test above, we know that + * cwnd > in_flight. + */ + cong_win = (tp->snd_cwnd - in_flight) * tp->mss_cache; + + limit = min(send_win, cong_win); + + /* If sk_send_head can be sent fully now, just do it. */ + if (skb->len <= limit) + return 0; + + /* If at least some fraction of a window is available, + * just use it. + */ + chunk = min(tp->snd_wnd, tp->snd_cwnd * tp->mss_cache); + chunk /= sysctl_tcp_tso_win_divisor; + if (limit >= chunk) + return 0; + + /* Ok, it looks like it is advisable to defer. */ + if (cong_win < send_win) + tp->deferred = tp->snd_cwnd - in_flight; + + return 1; +} + /* This routine writes packets to the network. It advances the * send_head. This happens as incoming acks open up the remote - * window for us. + * window for us. Caller makes sure sk_send_head is non-NULL. * * Returns 1, if no segments are in flight and we have queued segments, but * cannot send anything now because of SWS or another problem. */ -int tcp_write_xmit(struct sock *sk, int nonagle) +static int tcp_write_xmit(struct sock *sk, struct tcp_sock *tp, int nonagle) { - struct tcp_sock *tp = tcp_sk(sk); - unsigned int mss_now; + unsigned int mss_now, cwnd_quota, sent_pkts, tso_segs; + struct sk_buff *skb; /* If we are closed, the bytes will have to remain here. * In time closedown will finish, we empty the write queue and all * will be happy. */ - if (sk->sk_state != TCP_CLOSE) { - struct sk_buff *skb; - int sent_pkts = 0; + if (unlikely(sk->sk_state == TCP_CLOSE)) + return 0; - /* Account for SACKS, we may need to fragment due to this. - * It is just like the real MSS changing on us midstream. - * We also handle things correctly when the user adds some - * IP options mid-stream. Silly to do, but cover it. - */ - mss_now = tcp_current_mss(sk, 1); + /* Account for SACKS, we may need to fragment due to this. + * It is just like the real MSS changing on us midstream. + * We also handle things correctly when the user adds some + * IP options mid-stream. Silly to do, but cover it. + */ + mss_now = tcp_current_mss(sk, 1); + + skb = sk->sk_send_head; + tso_segs = tcp_init_tso_segs(sk, skb); + cwnd_quota = tcp_cwnd_test(tp, skb); + sent_pkts = 0; + + while (cwnd_quota) { + if (tso_segs > 1) { + if (tcp_tso_should_defer(sk, tp, skb)) + break; + } else if (!tcp_nagle_test(tp, skb, mss_now, + (tcp_skb_is_last(sk, skb) ? + nonagle : TCP_NAGLE_PUSH))) + break; + + if (!tcp_snd_wnd_test(tp, skb, mss_now)) + break; + + BUG_ON(!tso_segs); + + if (tso_segs > 1) { + u32 limit = tcp_window_allows(tp, skb, + mss_now, cwnd_quota); - while ((skb = sk->sk_send_head) && - tcp_snd_test(sk, skb, mss_now, - tcp_skb_is_last(sk, skb) ? nonagle : - TCP_NAGLE_PUSH)) { - if (skb->len > mss_now) { - if (tcp_fragment(sk, skb, mss_now)) + if (skb->len > limit) { + if (tso_fragment(sk, skb, limit)) break; } - - TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); - if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) + } else if (skb->len > mss_now) { + if (tcp_fragment(sk, skb, mss_now)) break; + } - /* Advance the send_head. This one is sent out. - * This call will increment packets_out. - */ - update_send_head(sk, tp, skb); + TCP_SKB_CB(skb)->when = tcp_time_stamp; + if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) + break; - tcp_minshall_update(tp, mss_now, skb); - sent_pkts = 1; - } + /* Advance the send_head. This one is sent out. + * This call will increment packets_out. + */ + update_send_head(sk, tp, skb); - if (sent_pkts) { - tcp_cwnd_validate(sk, tp); - return 0; + tcp_minshall_update(tp, mss_now, skb); + sent_pkts++; + + cwnd_quota -= tcp_skb_pcount(skb); + skb = sk->sk_send_head; + if (!skb) + break; + tso_segs = tcp_init_tso_segs(sk, skb); + } + + if (sent_pkts) { + tcp_cwnd_validate(sk, tp); + return 0; + } + + return !tp->packets_out && sk->sk_send_head; +} + +/* Push out any pending frames which were held back due to + * TCP_CORK or attempt at coalescing tiny packets. + * The socket must be locked by the caller. + */ +void __tcp_push_pending_frames(struct sock *sk, + struct tcp_sock *tp, + unsigned int cur_mss, + int nonagle) +{ + if (sk->sk_send_head) { + if (tcp_write_xmit(sk, tp, nonagle)) + tcp_check_probe_timer(sk, tp); + } +} + +/* As ACKs arrive and the send and congestion windows potentially + * open up, we call this to try and make write queue transmit + * progress. + * + * The caller has the socket locked, and has verified that + * sk->sk_send_head is not NULL. + */ +void __tcp_data_snd_check(struct sock *sk, struct sk_buff *skb) +{ + struct tcp_sock *tp = tcp_sk(sk); + + if (tcp_write_xmit(sk, tp, tp->nonagle)) + tcp_check_probe_timer(sk, tp); +} + +/* Send _single_ skb sitting at the send head. This function requires + * true push pending frames to setup probe timer etc. Caller makes + * sure that sk->sk_send_head is non-NULL. + */ +void tcp_push_one(struct sock *sk, unsigned int cur_mss) +{ + struct tcp_sock *tp = tcp_sk(sk); + struct sk_buff *skb = sk->sk_send_head; + unsigned int tso_segs, cwnd_quota; + + tso_segs = tcp_init_tso_segs(sk, skb); + cwnd_quota = tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH); + + if (cwnd_quota && tso_segs > 1) { + if (tcp_tso_should_defer(sk, tp, skb)) + return; + } + + if (cwnd_quota) { + BUG_ON(!tso_segs); + + if (tso_segs > 1) { + u32 limit = tcp_window_allows(tp, skb, + cur_mss, cwnd_quota); + + if (skb->len > limit) { + if (tso_fragment(sk, skb, limit)) + return; + } + } else if (skb->len > cur_mss) { + if (tcp_fragment(sk, skb, cur_mss)) + return; } - return !tp->packets_out && sk->sk_send_head; + /* Send it out now. */ + TCP_SKB_CB(skb)->when = tcp_time_stamp; + if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { + update_send_head(sk, tp, skb); + return; + } } - return 0; } /* This function returns the amount that we can raise the @@ -1041,12 +1372,6 @@ int tcp_retransmit_skb(struct sock *sk, if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una)) BUG(); - if (sk->sk_route_caps & NETIF_F_TSO) { - sk->sk_route_caps &= ~NETIF_F_TSO; - sock_set_flag(sk, SOCK_NO_LARGESEND); - tp->mss_cache = tp->mss_cache_std; - } - if (tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)) return -ENOMEM; } @@ -1106,7 +1431,6 @@ int tcp_retransmit_skb(struct sock *sk, * is still in somebody's hands, else make a clone. */ TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); err = tcp_transmit_skb(sk, (skb_cloned(skb) ? pskb_copy(skb, GFP_ATOMIC): @@ -1671,19 +1995,11 @@ int tcp_write_wakeup(struct sock *sk) TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; if (tcp_fragment(sk, skb, seg_size)) return -1; - /* SWS override triggered forced fragmentation. - * Disable TSO, the connection is too sick. */ - if (sk->sk_route_caps & NETIF_F_TSO) { - sock_set_flag(sk, SOCK_NO_LARGESEND); - sk->sk_route_caps &= ~NETIF_F_TSO; - tp->mss_cache = tp->mss_cache_std; - } } else if (!tcp_skb_pcount(skb)) tcp_set_skb_tso_segs(sk, skb); TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; TCP_SKB_CB(skb)->when = tcp_time_stamp; - tcp_tso_set_push(skb); err = tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC)); if (!err) { update_send_head(sk, tp, skb); --- 1/net/ipv6/tcp_ipv6.c.~1~ 2005-05-20 22:12:09.000000000 -0700 +++ 2/net/ipv6/tcp_ipv6.c 2005-05-20 22:12:22.000000000 -0700 @@ -2021,7 +2021,8 @@ static int tcp_v6_init_sock(struct sock */ tp->snd_ssthresh = 0x7fffffff; tp->snd_cwnd_clamp = ~0; - tp->mss_cache_std = tp->mss_cache = 536; + tp->mss_cache = 536; + tp->xmit_size_cache = ~0; tp->reordering = sysctl_tcp_reordering; ----Next_Part(Mon_May_23_12_19_43_2005_835)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_ack26.diff" diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4355,16 +4355,7 @@ int tcp_rcv_established(struct sock *sk, goto no_ack; } - if (eaten) { - if (tcp_in_quickack_mode(tp)) { - tcp_send_ack(sk); - } else { - tcp_send_delayed_ack(sk); - } - } else { - __tcp_ack_snd_check(sk, 0); - } - + __tcp_ack_snd_check(sk, 0); no_ack: if (eaten) __kfree_skb(skb); ----Next_Part(Mon_May_23_12_19_43_2005_835)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_ack24.diff" [TCP]: Fix stretch ACK performance killer when doing ucopy. When we are doing ucopy, we try to defer the ACK generation to cleanup_rbuf(). This works most of the time very well, but if the ucopy prequeue is large, this ACKing behavior kills performance. With TSO, it is possible to fill the prequeue so large that by the time the ACK is sent and gets back to the sender, most of the window has emptied of data and performance suffers significantly. This behavior does help in some cases, so we should think about re-enabling this trick in the future, using some kind of limit in order to avoid the bug case. Signed-off-by: David S. Miller --- 1/net/ipv4/tcp_input.c.~1~ 2005-05-23 12:03:26.000000000 -0700 +++ 2/net/ipv4/tcp_input.c 2005-05-23 12:03:28.000000000 -0700 @@ -4243,16 +4243,7 @@ goto no_ack; } - if (eaten) { - if (tcp_in_quickack_mode(tp)) { - tcp_send_ack(sk); - } else { - tcp_send_delayed_ack(sk); - } - } else { - __tcp_ack_snd_check(sk, 0); - } - + __tcp_ack_snd_check(sk, 0); no_ack: if (eaten) __kfree_skb(skb); ----Next_Part(Mon_May_23_12_19_43_2005_835)---- From davem@davemloft.net Mon May 23 12:54:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 12:54:18 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NJsFF3032353 for ; Mon, 23 May 2005 12:54:15 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaIzO-0002R4-9e; Mon, 23 May 2005 12:53:26 -0700 Date: Mon, 23 May 2005 12:53:26 -0700 (PDT) Message-Id: <20050523.125326.90119077.davem@davemloft.net> To: jdmason@us.ibm.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] include/linux/if_tr.h clean-up From: "David S. Miller" In-Reply-To: <20050520221019.GA26211@us.ibm.com> References: <20050520221019.GA26211@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 253 Lines: 11 From: Jon Mason Date: Fri, 20 May 2005 17:10:19 -0500 > I removed the ethernet definitions (which were commented out) and > cleaned up the tabs. > > Signed-off-by: Jon Mason Looks fine, applied. Thanks Jon. From davem@davemloft.net Mon May 23 12:52:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 12:52:32 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NJq2F3032194 for ; Mon, 23 May 2005 12:52:14 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaIx9-0002Q3-CQ; Mon, 23 May 2005 12:51:07 -0700 Date: Mon, 23 May 2005 12:51:07 -0700 (PDT) Message-Id: <20050523.125107.45741257.davem@davemloft.net> To: fubar@us.ibm.com Cc: eparis@parisplace.org, netdev@oss.sgi.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH] bonding using arp_ip_target may stay down with active path From: "David S. Miller" In-Reply-To: <200505162034.j4GKYbch022992@death.nxdomain.ibm.com> References: <200505162034.j4GKYbch022992@death.nxdomain.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 68 Lines: 3 Patch doesn't apply, tabs turned into spaces by your email client. From davem@davemloft.net Mon May 23 13:10:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 13:10:25 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NKANF3001319 for ; Mon, 23 May 2005 13:10:23 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaJF0-0002Uw-9A; Mon, 23 May 2005 13:09:34 -0700 Date: Mon, 23 May 2005 13:09:34 -0700 (PDT) Message-Id: <20050523.130934.93383300.davem@davemloft.net> To: adobriyan@gmail.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] netdevice.h: be'ify packet_type From: "David S. Miller" In-Reply-To: <200505211940.59240.adobriyan@gmail.com> References: <200505211940.59240.adobriyan@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 345 Lines: 16 From: Alexey Dobriyan Date: Sat, 21 May 2005 19:40:59 +0400 > Everybody does > > struct packet_type foo_packet_type = { > .type = __constant_htons(ETH_P_FOO); > }; > > 5 introduced warnings will be properly fixed later. > > Signed-off-by: Alexey Dobriyan Looks great, patch applied. Thanks. From davem@davemloft.net Mon May 23 13:12:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 13:12:46 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NKCeF3001847 for ; Mon, 23 May 2005 13:12:40 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaJH1-0002Vc-G5; Mon, 23 May 2005 13:11:39 -0700 Date: Mon, 23 May 2005 13:11:39 -0700 (PDT) Message-Id: <20050523.131139.51421880.davem@davemloft.net> To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, christophe@saout.de, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BUG 2.6.12-rc4] IPv6 xfrm tunnel oops with large packets From: "David S. Miller" In-Reply-To: <20050522.051817.122678688.yoshfuji@linux-ipv6.org> References: <1116702611.14509.10.camel@leto.cs.pocnet.net> <20050521194932.GA10959@gondor.apana.org.au> <20050522.051817.122678688.yoshfuji@linux-ipv6.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 1506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 627 Lines: 19 From: YOSHIFUJI Hideaki / $B5HF#1QL@(B Date: Sun, 22 May 2005 05:18:17 +0900 (JST) > In article <20050521194932.GA10959@gondor.apana.org.au> (at Sun, 22 May 2005 05:49:32 +1000), Herbert Xu says: > > > On Sat, May 21, 2005 at 07:10:11PM +0000, Christophe Saout wrote: > > > > > > The oops occurs in line 391 in net/ipv6/icmp.c: > > > > > > > idev = in6_dev_get(skb->dev); > > > > Here is a minimal fix. > > > > Signed-off-by: Herbert Xu > > > Acked-by: Hideaki YOSHIFUJI Applied, thanks everyone. From util@deuroconsult.ro Mon May 23 13:50:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 13:50:55 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NKooF3003815 for ; Mon, 23 May 2005 13:50:52 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4NKnvWq008578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2005 23:49:57 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4NKnv0s008575; Mon, 23 May 2005 23:49:57 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Mon, 23 May 2005 23:49:57 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Stephen Hemminger cc: netdev@oss.sgi.com Subject: Re: Why /sys/class/net/*/features is read-only? In-Reply-To: <20050523092827.7883af33@dxpl.pdx.osdl.net> Message-ID: References: <20050523092827.7883af33@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 735 Lines: 24 On Mon, 23 May 2005, Stephen Hemminger wrote: > On Mon, 23 May 2005 10:46:50 +0300 (EEST) > "Catalin(ux aka Dino) BOIE" wrote: > >> Hello! >> >> Why features file is read-only. If an admin want to force some attributes, >> we can let them, right? >> > > Leave it read-only because the hardware may not want to allow them on that flavor and so it would > have to be device specific. You are clear right for hardware devices, but for software ones (bridge for example) it makes sense. Anyway, only admin can change them. If you have a bridge with 5 net cards and 4 supports SG, some people may want to force SG on the bridge. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From jdmason@us.ibm.com Mon May 23 13:51:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 13:51:22 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NKpJF3003856 for ; Mon, 23 May 2005 13:51:19 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4NKoYLK485300 for ; Mon, 23 May 2005 16:50:35 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4NKoYlw085794 for ; Mon, 23 May 2005 14:50:34 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4NKoYY6015756 for ; Mon, 23 May 2005 14:50:34 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4NKoYrr015750; Mon, 23 May 2005 14:50:34 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id j4NKoXUe090618; Mon, 23 May 2005 15:50:33 -0500 Received: from dreadnought (dreadnought.austin.ibm.com [9.53.90.32]) by popmail.austin.ibm.com (AIX5.1/8.11.6p2/8.9.3) with SMTP id j4NKoPe30904; Mon, 23 May 2005 15:50:25 -0500 Received: by dreadnought (sSMTP sendmail emulation); Mon, 23 May 2005 15:50:32 -0500 Date: Mon, 23 May 2005 15:50:32 -0500 From: Jon Mason To: rl@hellgate.ch Cc: netdev@oss.sgi.com Subject: [PATCH linux-2.6.12-rc4-mm1] via-rhine: init clean-up Message-ID: <20050523205031.GA5910@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i X-archive-position: 1508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1489 Lines: 47 Removed unnecessary IF checks and variable assignments, as pci_revs are either < VTunknown0 or >= VT6102. dev->features is never populated. So, there could be garbage in there (then OR'ed with NETIF_F_SG | NETIF_F_HW_CSUM). Also, ethtool_op_get_tx_csum checks for NETIF_F_IP_CSUM not NETIF_F_HW_CSUM. I am sending out a patch to fix that (in ethtool.c) shortly. Signed-off-by: Jon Mason --- drivers/net/via-rhine.c.orig 2005-05-21 10:52:01.000000000 -0500 +++ drivers/net/via-rhine.c 2005-05-21 15:07:29.000000000 -0500 @@ -710,21 +710,18 @@ static int __devinit rhine_init_one(stru pci_read_config_byte(pdev, PCI_REVISION_ID, &pci_rev); - io_size = 256; phy_id = 0; - quirks = 0; - name = "Rhine"; if (pci_rev < VTunknown0) { + name = "Rhine"; quirks = rqRhineI; io_size = 128; - } - else if (pci_rev >= VT6102) { + } else { + io_size = 256; quirks = rqWOL | rqForceReset; if (pci_rev < VT6105) { name = "Rhine II"; quirks |= rqStatusWBRace; /* Rhine-II exclusive */ - } - else { + } else { phy_id = 1; /* Integrated PHY, phy_id fixed to 1 */ if (pci_rev >= VT6105_B0) quirks |= rq6patterns; @@ -847,7 +844,7 @@ static int __devinit rhine_init_one(stru dev->poll_controller = rhine_poll; #endif if (rp->quirks & rqRhineI) - dev->features |= NETIF_F_SG|NETIF_F_HW_CSUM; + dev->features = NETIF_F_SG | NETIF_F_HW_CSUM; /* dev->name not defined before register_netdev()! */ rc = register_netdev(dev); From davem@davemloft.net Mon May 23 13:55:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 13:55:11 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NKt6F3004971 for ; Mon, 23 May 2005 13:55:06 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaJvo-0003u6-OE; Mon, 23 May 2005 13:53:48 -0700 Date: Mon, 23 May 2005 13:53:48 -0700 (PDT) Message-Id: <20050523.135348.55831423.davem@davemloft.net> To: util@deuroconsult.ro Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Why /sys/class/net/*/features is read-only? From: "David S. Miller" In-Reply-To: References: <20050523092827.7883af33@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 239 Lines: 7 From: "Catalin(ux aka Dino) BOIE" Date: Mon, 23 May 2005 23:49:57 +0300 (EEST) > If you have a bridge with 5 net cards and 4 supports SG, some people > may want to force SG on the bridge. Let them use ethtool :-) From shemminger@osdl.org Mon May 23 13:56:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 13:56:07 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NKu4F3005091 for ; Mon, 23 May 2005 13:56:04 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4NKtGjA018014 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 13:55:17 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4NKtGgA018668; Mon, 23 May 2005 13:55:16 -0700 Date: Mon, 23 May 2005 13:55:16 -0700 From: Stephen Hemminger To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com Subject: Re: Why /sys/class/net/*/features is read-only? Message-ID: <20050523135516.7568ab99@dxpl.pdx.osdl.net> In-Reply-To: References: <20050523092827.7883af33@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 869 Lines: 24 On Mon, 23 May 2005 23:49:57 +0300 (EEST) "Catalin(ux aka Dino) BOIE" wrote: > On Mon, 23 May 2005, Stephen Hemminger wrote: > > > On Mon, 23 May 2005 10:46:50 +0300 (EEST) > > "Catalin(ux aka Dino) BOIE" wrote: > > > >> Hello! > >> > >> Why features file is read-only. If an admin want to force some attributes, > >> we can let them, right? > >> > > > > Leave it read-only because the hardware may not want to allow them on that flavor and so it would > > have to be device specific. > > You are clear right for hardware devices, but for software ones (bridge > for example) it makes sense. Anyway, only admin can change them. > > If you have a bridge with 5 net cards and 4 supports SG, some people > may want to force SG on the bridge. Then implement ethtool on the bridge device, it wouldn't be hard to do that. From juliokriger@gmail.com Mon May 23 13:56:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 13:56:24 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NKuJF3005227 for ; Mon, 23 May 2005 13:56:19 -0700 Received: by zproxy.gmail.com with SMTP id 8so1679164nzo for ; Mon, 23 May 2005 13:55:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i57rTB7ro8/E5NA4VQfQG3okCPWWBC97NgBIhcWlXqAQ5hVvoQjVHP76v6+dz+x3OtW7Qs5cYEvci3c0OESg2zu5tnl95sNAy4aCvm1Lp08iU0f6xv3Tcj4NyC9P2BtotVUeqIue6hlovrvIIF4qeKr/XGbgxEmCslH04HM5V2A= Received: by 10.36.24.7 with SMTP id 7mr1606357nzx; Mon, 23 May 2005 13:55:35 -0700 (PDT) Received: by 10.36.9.9 with HTTP; Mon, 23 May 2005 13:55:35 -0700 (PDT) Message-ID: <682bc30a050523135534b38b8b@mail.gmail.com> Date: Mon, 23 May 2005 17:55:35 -0300 From: Julio Kriger Reply-To: Julio Kriger To: Stephen Hemminger Subject: Re: [PATCH] netem: fix logic bug in reorder conditional Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org In-Reply-To: <20050523104342.78b1032d@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> <682bc30a05052116005bc813a2@mail.gmail.com> <20050523104342.78b1032d@dxpl.pdx.osdl.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4NKuJF3005227 X-archive-position: 1511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juliokriger@gmail.com Precedence: bulk X-list: netdev Content-Length: 2511 Lines: 69 Hi! 1) Supouse I don't want reordering, so in 'tc' I don't add reorder option. Will this code work? The previous (on this subject) patch has a the following: + /* for compatiablity with earlier versions. + * if gap is set, need to assume 100% probablity + */ + q->reorder = ~0; + Should it be set to 100% or 101%? This "q->reorder = ~0;" mean 100%? 2) If I set latency = 50ms and a jitter = 300ms, tabledist can give me a negative number. This value is addes to cb->time_to_send, so it could change it to a negative value. Should we only accept positives number before add it to cb->time_to_send? or will q->qdisc->enqueue(skb, q->qdisc) put the package on the queue in a special way so it will be handled "before" other packages alrealy on the queue but with gretaer time_to_send? Regards, Julio On 5/23/05, Stephen Hemminger wrote: > Thanks, Julio you spotted the problem with the logic. This should fix it: > > Index: netem-2.6.12-rc4/net/sched/sch_netem.c > =================================================================== > --- netem-2.6.12-rc4.orig/net/sched/sch_netem.c > +++ netem-2.6.12-rc4/net/sched/sch_netem.c > @@ -181,13 +181,9 @@ static int netem_enqueue(struct sk_buff > q->duplicate = dupsave; > } > > - /* > - * Do re-ordering by putting one out of N packets at the front > - * of the queue. > - * gap == 0 is special case for no-reordering. > - */ > - if (q->gap == 0 && q->counter < q->gap && > - q->reorder < get_crandom(&q->reorder_cor)) { > + if (q->gap == 0 /* not doing reordering */ > + || q->counter < q->gap /* inside last reordering gap */ > + || q->reorder < get_crandom(&q->reorder_cor)) { > psched_time_t now; > PSCHED_GET_TIME(now); > PSCHED_TADD2(now, tabledist(q->latency, q->jitter, > @@ -196,6 +192,10 @@ static int netem_enqueue(struct sk_buff > ++q->counter; > ret = q->qdisc->enqueue(skb, q->qdisc); > } else { > + /* > + * Do re-ordering by putting one out of N packets at the front > + * of the queue. > + */ > PSCHED_GET_TIME(cb->time_to_send); > q->counter = 0; > ret = q->qdisc->ops->requeue(skb, q->qdisc); > -- ---------------------------- Julio Kriger mailto:juliokriger@gmail.com From shemminger@osdl.org Mon May 23 14:01:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:01:46 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NL1hF3006822 for ; Mon, 23 May 2005 14:01:43 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4NL0tjA018381 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 14:00:55 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4NL0tZP019012; Mon, 23 May 2005 14:00:55 -0700 Date: Mon, 23 May 2005 14:00:55 -0700 From: Stephen Hemminger To: Julio Kriger Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] netem: fix logic bug in reorder conditional Message-ID: <20050523140055.127f1a9f@dxpl.pdx.osdl.net> In-Reply-To: <682bc30a050523135534b38b8b@mail.gmail.com> References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> <682bc30a05052116005bc813a2@mail.gmail.com> <20050523104342.78b1032d@dxpl.pdx.osdl.net> <682bc30a050523135534b38b8b@mail.gmail.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1298 Lines: 34 On Mon, 23 May 2005 17:55:35 -0300 Julio Kriger wrote: > Hi! > > 1) Supouse I don't want reordering, so in 'tc' I don't add reorder > option. Will this code work? The previous (on this subject) patch has > a the following: > > + /* for compatiablity with earlier versions. > + * if gap is set, need to assume 100% probablity > + */ > + q->reorder = ~0; > + If you don't want reordering, then gap = 0. so reorder is ignored. > > Should it be set to 100% or 101%? > This "q->reorder = ~0;" mean 100%? yes probability percentages are converted to 32-bit unsigned long scaled value. so 100% = 0xffffffff and 0% = 0 > 2) If I set latency = 50ms and a jitter = 300ms, tabledist can give me > a negative number. This value is addes to cb->time_to_send, so it > could change it to a negative value. Should we only accept positives > number before add it to cb->time_to_send? or will > q->qdisc->enqueue(skb, q->qdisc) put the package on the queue in a > special way so it will be handled "before" other packages alrealy on > the queue but with gretaer time_to_send? probably should bound the value to 0 before the addition, to avoid large wraparound problems, but since enqueue checks for for time it will work as long as delta less than 2^32/2. From jdmason@us.ibm.com Mon May 23 14:08:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:08:48 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NL8iF3007536 for ; Mon, 23 May 2005 14:08:44 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4NL7xLK015656 for ; Mon, 23 May 2005 17:07:59 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4NL7xPd238394 for ; Mon, 23 May 2005 15:07:59 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4NL7xnx022469 for ; Mon, 23 May 2005 15:07:59 -0600 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4NL7x4P022447 for ; Mon, 23 May 2005 15:07:59 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.9/8.12.10) with ESMTP id j4NL7wYl076626 for ; Mon, 23 May 2005 16:07:58 -0500 Received: from dreadnought (dreadnought.austin.ibm.com [9.53.90.32]) by popmail.austin.ibm.com (AIX5.1/8.11.6p2/8.9.3) with SMTP id j4NL7oe22930 for ; Mon, 23 May 2005 16:07:51 -0500 Received: by dreadnought (sSMTP sendmail emulation); Mon, 23 May 2005 16:07:57 -0500 Date: Mon, 23 May 2005 16:07:57 -0500 From: Jon Mason To: netdev@oss.sgi.com Subject: [PATCH linux-2.6.12-rc4-mm1] ethtool: Add NETIF_F_HW_CSUM support Message-ID: <20050523210757.GB5910@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i X-archive-position: 1513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1640 Lines: 46 Added support to ethtool for NETIF_F_HW_CSUM. Signed-off-by: Jon Mason --- include/linux/ethtool.h.orig 2005-05-16 08:49:43.000000000 -0500 +++ include/linux/ethtool.h 2005-05-21 15:11:05.000000000 -0500 @@ -256,6 +256,7 @@ struct net_device; u32 ethtool_op_get_link(struct net_device *dev); u32 ethtool_op_get_tx_csum(struct net_device *dev); int ethtool_op_set_tx_csum(struct net_device *dev, u32 data); +int ethtool_op_set_tx_hw_csum(struct net_device *dev, u32 data); u32 ethtool_op_get_sg(struct net_device *dev); int ethtool_op_set_sg(struct net_device *dev, u32 data); u32 ethtool_op_get_tso(struct net_device *dev); --- net/core/ethtool.c.orig 2005-05-21 14:16:33.000000000 -0500 +++ net/core/ethtool.c 2005-05-21 18:07:16.000000000 -0500 @@ -29,7 +29,7 @@ u32 ethtool_op_get_link(struct net_devic u32 ethtool_op_get_tx_csum(struct net_device *dev) { - return (dev->features & NETIF_F_IP_CSUM) != 0; + return (dev->features & (NETIF_F_IP_CSUM | NETIF_F_HW_CSUM)) != 0; } int ethtool_op_set_tx_csum(struct net_device *dev, u32 data) @@ -42,6 +42,15 @@ int ethtool_op_set_tx_csum(struct net_de return 0; } +int ethtool_op_set_tx_hw_csum(struct net_device *dev, u32 data) +{ + if (data) + dev->features |= NETIF_F_HW_CSUM; + else + dev->features &= ~NETIF_F_HW_CSUM; + + return 0; +} u32 ethtool_op_get_sg(struct net_device *dev) { return (dev->features & NETIF_F_SG) != 0; @@ -817,3 +826,4 @@ EXPORT_SYMBOL(ethtool_op_get_tx_csum); EXPORT_SYMBOL(ethtool_op_set_sg); EXPORT_SYMBOL(ethtool_op_set_tso); EXPORT_SYMBOL(ethtool_op_set_tx_csum); +EXPORT_SYMBOL(ethtool_op_set_tx_hw_csum); From davem@davemloft.net Mon May 23 14:20:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:21:03 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLKtF3010310 for ; Mon, 23 May 2005 14:20:55 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaKLJ-0000cP-Jr; Mon, 23 May 2005 14:20:09 -0700 Date: Mon, 23 May 2005 14:20:09 -0700 (PDT) Message-Id: <20050523.142009.74748115.davem@davemloft.net> To: jdmason@us.ibm.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH linux-2.6.12-rc4-mm1] ethtool: Add NETIF_F_HW_CSUM support From: "David S. Miller" In-Reply-To: <20050523210757.GB5910@us.ibm.com> References: <20050523210757.GB5910@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 451 Lines: 12 From: Jon Mason Subject: [PATCH linux-2.6.12-rc4-mm1] ethtool: Add NETIF_F_HW_CSUM support Date: Mon, 23 May 2005 16:07:57 -0500 > Added support to ethtool for NETIF_F_HW_CSUM. > > Signed-off-by: Jon Mason You cannot blindly set these flags, you need to provide a method for the driver to override the implementation of this method so it can return and error if it cannot provide support for this feature. From fubar@us.ibm.com Mon May 23 14:22:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:22:49 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLMiF3010824 for ; Mon, 23 May 2005 14:22:45 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4NLM0on028771 for ; Mon, 23 May 2005 17:22:00 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4NLM0AD147830 for ; Mon, 23 May 2005 17:22:00 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4NLM0Vo025134 for ; Mon, 23 May 2005 17:22:00 -0400 Received: from death.nxdomain.ibm.com (sig-9-65-36-188.mts.ibm.com [9.65.36.188]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4NLLxS6024977; Mon, 23 May 2005 17:21:59 -0400 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j4NLLbse000844; Mon, 23 May 2005 14:21:37 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j4NLLaYa000837; Mon, 23 May 2005 14:21:37 -0700 Message-Id: <200505232121.j4NLLaYa000837@death.nxdomain.ibm.com> To: "David S. Miller" cc: eparis@parisplace.org, netdev@oss.sgi.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH] bonding using arp_ip_target may stay down with active path In-Reply-To: Message from "David S. Miller" of "Mon, 23 May 2005 12:51:07 PDT." <20050523.125107.45741257.davem@davemloft.net> X-Mailer: MH-E 7.83; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 23 May 2005 14:21:36 -0700 From: Jay Vosburgh X-archive-position: 1515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 974 Lines: 28 David S. Miller wrote: >Patch doesn't apply, tabs turned into spaces by your >email client. As penance for test applying trivial patches by hand, here's a proper version. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com Signed-off-by: Jay Vosburgh diff -urN linux-2.6.11/drivers/net/bonding/bond_main.c linux-2.6.11-fix/drivers/net/bonding/bond_main.c --- linux-2.6.11/drivers/net/bonding/bond_main.c 2005-05-23 14:07:37.000000000 -0700 +++ linux-2.6.11-fix/drivers/net/bonding/bond_main.c 2005-05-23 14:08:13.000000000 -0700 @@ -3046,7 +3046,7 @@ bond_set_slave_inactive_flags(bond->current_arp_slave); /* search for next candidate */ - bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave) { + bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave->next) { if (IS_UP(slave->dev)) { slave->link = BOND_LINK_BACK; bond_set_slave_active_flags(slave); From jdmason@us.ibm.com Mon May 23 14:33:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:33:46 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLXhF3011653 for ; Mon, 23 May 2005 14:33:43 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4NLWx0c654428 for ; Mon, 23 May 2005 17:32:59 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4NLWxPd220844 for ; Mon, 23 May 2005 15:32:59 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4NLWwPJ009370 for ; Mon, 23 May 2005 15:32:59 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4NLWw91009357; Mon, 23 May 2005 15:32:58 -0600 From: Jon Mason Organization: IBM To: "David S. Miller" Subject: Re: [PATCH linux-2.6.12-rc4-mm1] ethtool: Add NETIF_F_HW_CSUM support Date: Mon, 23 May 2005 16:32:55 -0500 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <20050523210757.GB5910@us.ibm.com> <20050523.142009.74748115.davem@davemloft.net> In-Reply-To: <20050523.142009.74748115.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505231632.55476.jdmason@us.ibm.com> X-archive-position: 1517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 958 Lines: 26 On Monday 23 May 2005 04:20 pm, David S. Miller wrote: > From: Jon Mason > Subject: [PATCH linux-2.6.12-rc4-mm1] ethtool: Add NETIF_F_HW_CSUM support > Date: Mon, 23 May 2005 16:07:57 -0500 > > > Added support to ethtool for NETIF_F_HW_CSUM. > > > > Signed-off-by: Jon Mason > > You cannot blindly set these flags, you need to provide > a method for the driver to override the implementation of > this method so it can return and error if it cannot provide > support for this feature. I am only adding a generic function which gives the ability to use NETIF_F_HW_CSUM for ethtool tx offload (instead of only using NETIF_F_IP_CSUM). If ethtool_set_tx_csum does not point to ethtool_op_set_tx_csum or ethtool_op_set_tx_hw_csum (or a local driver function) then it will return an error. Isn't this sufficient (as it is what currently happening), or am I not sufficently understanding the problem? Thanks, Jon From util@deuroconsult.ro Mon May 23 14:33:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:33:19 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLXDF3011589 for ; Mon, 23 May 2005 14:33:14 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4NLWKNI017248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2005 00:32:20 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4NLWJA8017245; Tue, 24 May 2005 00:32:19 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Tue, 24 May 2005 00:32:19 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Stephen Hemminger cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] Implement NETDEV_FEAT_CHANGE In-Reply-To: <20050523093329.40617690@dxpl.pdx.osdl.net> Message-ID: References: <20050523093329.40617690@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 977 Lines: 40 On Mon, 23 May 2005, Stephen Hemminger wrote: > >> --- notify1/net/core/ethtool.c 2005-03-02 09:38:37.000000000 +0200 >> +++ linux/net/core/ethtool.c 2005-05-23 11:30:47.000000000 +0300 > ... >> @@ -712,7 +715,6 @@ int dev_ethtool(struct ifreq *ifr) >> break; >> case ETHTOOL_GDRVINFO: >> rc = ethtool_get_drvinfo(dev, useraddr); >> - >> break; > > White space creep Do you want to not touch that space? >> case ETHTOOL_GREGS: >> rc = ethtool_get_regs(dev, useraddr); >> @@ -801,6 +803,10 @@ int dev_ethtool(struct ifreq *ifr) >> >> if(dev->ethtool_ops->complete) >> dev->ethtool_ops->complete(dev); >> + >> + if (old_features != dev->features) >> + netdev_features_change(dev); >> + >> return rc; >> >> ioctl: > > Did you check for any drivers that don't use ethtool_ops? I checked now and I didn't find any possibility to change features. So I think we are ok. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From util@deuroconsult.ro Mon May 23 14:34:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:34:09 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLY3F3011789 for ; Mon, 23 May 2005 14:34:04 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4NLXEi5017527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2005 00:33:14 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4NLXEuP017524; Tue, 24 May 2005 00:33:14 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Tue, 24 May 2005 00:33:14 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: "David S. Miller" cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Why /sys/class/net/*/features is read-only? In-Reply-To: <20050523.135348.55831423.davem@davemloft.net> Message-ID: References: <20050523092827.7883af33@dxpl.pdx.osdl.net> <20050523.135348.55831423.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 415 Lines: 16 On Mon, 23 May 2005, David S. Miller wrote: > From: "Catalin(ux aka Dino) BOIE" > Date: Mon, 23 May 2005 23:49:57 +0300 (EEST) > >> If you have a bridge with 5 net cards and 4 supports SG, some people >> may want to force SG on the bridge. > > Let them use ethtool :-) They can't on a bridge device, right? --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From herbert@gondor.apana.org.au Mon May 23 14:35:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:35:36 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLZTF3013107 for ; Mon, 23 May 2005 14:35:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaKZN-0000WJ-00; Tue, 24 May 2005 07:34:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaKZK-0006Qv-00; Tue, 24 May 2005 07:34:38 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: [PATCH] Super TSO v3 Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <20050523.121943.78708600.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 24 May 2005 07:34:38 +1000 X-archive-position: 1519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 508 Lines: 12 David S. Miller wrote: > > I discoevered a performance anomaly with Linux receivers, > cause by enormous stretch ACK generation, which you'll need > to fix if you want to test this patch against Linux receivers. Are there non-Linux systems that have the same receive issue? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Mon May 23 14:49:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:49:47 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLndF3013909 for ; Mon, 23 May 2005 14:49:39 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaKn5-0000ja-5X; Mon, 23 May 2005 14:48:51 -0700 Date: Mon, 23 May 2005 14:48:50 -0700 (PDT) Message-Id: <20050523.144850.03976904.davem@davemloft.net> To: jdmason@us.ibm.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH linux-2.6.12-rc4-mm1] ethtool: Add NETIF_F_HW_CSUM support From: "David S. Miller" In-Reply-To: <200505231632.55476.jdmason@us.ibm.com> References: <20050523210757.GB5910@us.ibm.com> <20050523.142009.74748115.davem@davemloft.net> <200505231632.55476.jdmason@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 370 Lines: 9 From: Jon Mason Date: Mon, 23 May 2005 16:32:55 -0500 > If ethtool_set_tx_csum does not point to ethtool_op_set_tx_csum or > ethtool_op_set_tx_hw_csum (or a local driver function) then it will > return an error. Isn't this sufficient (as it is what currently > happening), or am I not sufficently understanding the problem? Ok, that looks right. From davem@davemloft.net Mon May 23 14:50:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:50:52 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLolF3014177 for ; Mon, 23 May 2005 14:50:47 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaKoD-0000jv-Im; Mon, 23 May 2005 14:50:01 -0700 Date: Mon, 23 May 2005 14:50:01 -0700 (PDT) Message-Id: <20050523.145001.104034315.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO v3 From: "David S. Miller" In-Reply-To: References: <20050523.121943.78708600.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 373 Lines: 9 From: Herbert Xu Date: Tue, 24 May 2005 07:34:38 +1000 > Are there non-Linux systems that have the same receive issue? Some generate stretch ACKs for other reasons (miscalculation of MSS due to TCP Timestamps) but I doubt any other OS implements the Van Jacobson ucopy stuff we do, and also implement the same ACKing hack on top of that :-) From davem@davemloft.net Mon May 23 14:51:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:52:04 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLpwF3014885 for ; Mon, 23 May 2005 14:51:59 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaKpM-0000kC-Eg; Mon, 23 May 2005 14:51:12 -0700 Date: Mon, 23 May 2005 14:51:12 -0700 (PDT) Message-Id: <20050523.145112.78711028.davem@davemloft.net> To: util@deuroconsult.ro Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Why /sys/class/net/*/features is read-only? From: "David S. Miller" In-Reply-To: References: <20050523.135348.55831423.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 371 Lines: 12 From: "Catalin(ux aka Dino) BOIE" Date: Tue, 24 May 2005 00:33:14 +0300 (EEST) > On Mon, 23 May 2005, David S. Miller wrote: > > > Let them use ethtool :-) > > They can't on a bridge device, right? Currently no. But there is no reason the bridge device should not have ethtool support added to it, and that's where this functionality belongs. From shemminger@osdl.org Mon May 23 14:54:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:54:11 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLs7F3015558 for ; Mon, 23 May 2005 14:54:07 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4NLrLjA022245 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 14:53:21 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4NLrL9P021677; Mon, 23 May 2005 14:53:21 -0700 Date: Mon, 23 May 2005 14:53:21 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: jdmason@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH linux-2.6.12-rc4-mm1] ethtool: Add NETIF_F_HW_CSUM support Message-ID: <20050523145321.49899042@dxpl.pdx.osdl.net> In-Reply-To: <20050523.142009.74748115.davem@davemloft.net> References: <20050523210757.GB5910@us.ibm.com> <20050523.142009.74748115.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 922 Lines: 29 On Mon, 23 May 2005 14:20:09 -0700 (PDT) "David S. Miller" wrote: > From: Jon Mason > Subject: [PATCH linux-2.6.12-rc4-mm1] ethtool: Add NETIF_F_HW_CSUM support > Date: Mon, 23 May 2005 16:07:57 -0500 > > > Added support to ethtool for NETIF_F_HW_CSUM. > > > > Signed-off-by: Jon Mason > > You cannot blindly set these flags, you need to provide > a method for the driver to override the implementation of > this method so it can return and error if it cannot provide > support for this feature. This patch makes perfect sense because it allows for common code to be used by device drivers in their ethtool_ops. So this is the logical way to handle this. In other words, drivers/net/sungem.c could do static struct ethtool_ops gem_ethtool_ops = { + .get_tx_csum = ethtool_op_get_tx_csum, + .set_tx_csum = ethtool_op_set_tx_hw_csum, }; From util@deuroconsult.ro Mon May 23 14:54:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 14:54:54 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NLsoF3015774 for ; Mon, 23 May 2005 14:54:51 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4NLrxaI000825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2005 00:53:59 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4NLrwi3000818; Tue, 24 May 2005 00:53:58 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Tue, 24 May 2005 00:53:58 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: "David S. Miller" cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Why /sys/class/net/*/features is read-only? In-Reply-To: <20050523.145112.78711028.davem@davemloft.net> Message-ID: References: <20050523.135348.55831423.davem@davemloft.net> <20050523.145112.78711028.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 643 Lines: 23 On Mon, 23 May 2005, David S. Miller wrote: > From: "Catalin(ux aka Dino) BOIE" > Date: Tue, 24 May 2005 00:33:14 +0300 (EEST) > >> On Mon, 23 May 2005, David S. Miller wrote: >> >>> Let them use ethtool :-) >> >> They can't on a bridge device, right? > > Currently no. But there is no reason the bridge device > should not have ethtool support added to it, and that's > where this functionality belongs. OK. I made this patch only to test how well slave notification worked. Next days I will implement ethtool for bridge. Thank you! --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From herbert@gondor.apana.org.au Mon May 23 16:23:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 16:23:23 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4NNNFF3023500 for ; Mon, 23 May 2005 16:23:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaMFe-0001Mk-00; Tue, 24 May 2005 09:22:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaMFc-0006cL-00; Tue, 24 May 2005 09:22:24 +1000 Date: Tue, 24 May 2005 09:22:24 +1000 To: pravin Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH] : bug fix in multipath drr code. Message-ID: <20050523232224.GA25349@gondor.apana.org.au> References: <4291CBFF.6080106@calsoftinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4291CBFF.6080106@calsoftinc.com> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1505 Lines: 41 On Mon, May 23, 2005 at 05:56:39PM +0530, pravin wrote: > AFAIU, there is a race condition in multipath_drr code, > these code paths try to access & change last_selection variable > without any synchronization. Yes you're right. > Index: linux-2.6.12-rc4/net/ipv4/multipath_drr.c > =================================================================== > --- linux-2.6.12-rc4.orig/net/ipv4/multipath_drr.c 2005-05-06 22:20:31.000000000 -0700 > +++ linux-2.6.12-rc4/net/ipv4/multipath_drr.c 2005-05-22 06:41:39.000000000 -0700 > @@ -145,11 +145,13 @@ > int cur_min_devidx = -1; > > /* if necessary and possible utilize the old alternative */ > - if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 && > - last_selection != NULL) { > - result = last_selection; > - *rp = result; > - return; > + if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 ) { > + struct rtable *last_result = last_selection; > + if(last_result != NULL && > + multipath_comparekeys(&last_result->fl, flp)) { > + *rp = last_result; > + return; > + } > } You don't need all this code. All you need to do is do result = last_selection before the if condition and then check result in the if condition instead of last_selection. The multipath_comparekeys isn't necessary either. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon May 23 17:33:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 17:33:13 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O0X5F3026758 for ; Mon, 23 May 2005 17:33:06 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaNL8-0001xP-00; Tue, 24 May 2005 10:32:10 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaNL6-0006iJ-00; Tue, 24 May 2005 10:32:08 +1000 Date: Tue, 24 May 2005 10:32:08 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO v3 Message-ID: <20050524003208.GA25778@gondor.apana.org.au> References: <20050523.121943.78708600.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523.121943.78708600.davem@davemloft.net> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 715 Lines: 19 On Mon, May 23, 2005 at 07:19:43PM +0000, David S. Miller wrote: > > The guts of the logic is in tcp_tso_should_defer(). And > when dealing with a TSO frame, tcp_write_xmit() calls > this instead of tcp_nagle_test(). So you can view this > deferral as a sort of "TSO Nagle". Should we skip this step if the socket has Nagle turned off? Also why are we doing this check in tcp_push_one? The only way we can get there is if the TSO goal has been reached or there is out-of-band stuff to send. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mchan@broadcom.com Mon May 23 17:58:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 17:58:50 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O0wmF3028725 for ; Mon, 23 May 2005 17:58:48 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 17:57:40 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 17:57:39 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZY32527; Mon, 23 May 2005 17:57:35 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA10449; Mon, 23 May 2005 17:57:34 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 May 2005 00:57:34 +0000 Received: from rh4 by nt-irva-0741; 23 May 2005 16:59:50 -0700 Subject: [PATCH 0/6] bnx2: Misc fixes From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com Date: Mon, 23 May 2005 16:53:59 -0700 Message-ID: <1116892439.4908.1.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E8CA38E1VO1438719-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 440 Lines: 18 These patches fix the following problems spotted by Jeff Garzik. Thanks Jeff. > 8) excessive stack size in bnx2_alloc_bad_rbuf(): > 13) [additional review] why is CHECKSUM_UNNECESSARY used when > cksum==0xffff or cksum==0 ? > 15) the following loop is just silly. use mdelay or (preferably) > msleep. > 19) [additional review] need flush_scheduled_work(), if using work queues? > 21) need to call bnx2_netif_stop() in bnx2_close() From acme@ghostprotocols.net Mon May 23 18:17:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:17:51 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1HcF3029890 for ; Mon, 23 May 2005 18:17:42 -0700 Received: from 201-15-204-66.ctame704.dsl.brasiltelecom.net.br ([201.15.204.66] helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DaO98-0001iV-00; Mon, 23 May 2005 22:23:51 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id E406614631; Mon, 23 May 2005 22:16:45 -0300 (BRT) Date: Mon, 23 May 2005 22:16:45 -0300 To: "David S.Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 1/2][NET] Generalise tcp_listen_opt Message-ID: <20050524011645.GI26989@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) X-archive-position: 1528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@ghostprotocols.net Precedence: bulk X-list: netdev Content-Length: 22574 Lines: 752 Hi David, Please consider pulling into your net-2.6.13 pending tree from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.13.git The bksend like output below was done using this script, people starting to use git may find it useful :-) http://dccp.ghostprotocols.net:81/acme-git-send-changeset Best Regards, - Arnaldo tree f416accfe16809dce40f34fb711d42a67aea892d parent 0642cf1e6afa649d8d9a9d3dc7275ceebb038ae0 author Arnaldo Carvalho de Melo 1113623934 -0300 committer Arnaldo Carvalho de Melo 1116886806 -0300 [NET] Generalise tcp_listen_opt This chunks out the accept_queue and tcp_listen_opt code and moves them to net/core/request_sock.c and include/net/request_sock.h, to make it useful for other transport protocols, DCCP being the first one to use it. Next patches will rename tcp_listen_opt to accept_sock and remove the inline tcp functions that just call a reqsk_queue_ function. Signed-off-by: Arnaldo Carvalho de Melo ------------------------------------------------------------------------------ include/linux/tcp.h | 17 ---- include/net/request_sock.h | 178 +++++++++++++++++++++++++++++++++++++++++++++ include/net/tcp.h | 46 ++--------- net/core/Makefile | 3 net/core/request_sock.c | 48 ++++++++++++ net/ipv4/tcp.c | 67 +++++----------- net/ipv4/tcp_diag.c | 6 - net/ipv4/tcp_ipv4.c | 32 +++----- net/ipv4/tcp_minisocks.c | 6 - net/ipv4/tcp_timer.c | 10 -- net/ipv6/tcp_ipv6.c | 14 --- 11 files changed, 281 insertions(+), 146 deletions(-) ------------------------------------------------------------------------------ diff --git a/include/linux/tcp.h b/include/linux/tcp.h --- a/include/linux/tcp.h +++ b/include/linux/tcp.h @@ -379,22 +379,7 @@ struct tcp_sock { __u32 total_retrans; /* Total retransmits for entire connection */ - /* The syn_wait_lock is necessary only to avoid proc interface having - * to grab the main lock sock while browsing the listening hash - * (otherwise it's deadlock prone). - * This lock is acquired in read mode only from listening_get_next() - * and it's acquired in write mode _only_ from code that is actively - * changing the syn_wait_queue. All readers that are holding - * the master sock lock don't need to grab this lock in read mode - * too as the syn_wait_queue writes are always protected from - * the main sock lock. - */ - rwlock_t syn_wait_lock; - struct tcp_listen_opt *listen_opt; - - /* FIFO of established children */ - struct request_sock *accept_queue; - struct request_sock *accept_queue_tail; + struct request_sock_queue accept_queue; /* FIFO of established children */ unsigned int keepalive_time; /* time before keep alive takes place */ unsigned int keepalive_intvl; /* time interval between keep alive probes */ diff --git a/include/net/request_sock.h b/include/net/request_sock.h --- a/include/net/request_sock.h +++ b/include/net/request_sock.h @@ -16,7 +16,9 @@ #define _REQUEST_SOCK_H #include +#include #include + #include struct request_sock; @@ -74,4 +76,180 @@ static inline void reqsk_free(struct req __reqsk_free(req); } +extern int sysctl_max_syn_backlog; + +/** struct tcp_listen_opt - listen state + * + * @max_qlen_log - log_2 of maximal queued SYNs/REQUESTs + */ +struct tcp_listen_opt { + u8 max_qlen_log; + /* 3 bytes hole, try to use */ + int qlen; + int qlen_young; + int clock_hand; + u32 hash_rnd; + struct request_sock *syn_table[0]; +}; + +/** struct request_sock_queue - queue of request_socks + * + * @rskq_accept_head - FIFO head of established children + * @rskq_accept_tail - FIFO tail of established children + * @syn_wait_lock - serializer + * + * %syn_wait_lock is necessary only to avoid proc interface having to grab the main + * lock sock while browsing the listening hash (otherwise it's deadlock prone). + * + * This lock is acquired in read mode only from listening_get_next() seq_file + * op and it's acquired in write mode _only_ from code that is actively + * changing rskq_accept_head. All readers that are holding the master sock lock + * don't need to grab this lock in read mode too as rskq_accept_head. writes + * are always protected from the main sock lock. + */ +struct request_sock_queue { + struct request_sock *rskq_accept_head; + struct request_sock *rskq_accept_tail; + rwlock_t syn_wait_lock; + struct tcp_listen_opt *listen_opt; +}; + +extern int reqsk_queue_alloc(struct request_sock_queue *queue, + const int nr_table_entries); + +static inline struct tcp_listen_opt *reqsk_queue_yank_listen_sk(struct request_sock_queue *queue) +{ + struct tcp_listen_opt *lopt; + + write_lock_bh(&queue->syn_wait_lock); + lopt = queue->listen_opt; + queue->listen_opt = NULL; + write_unlock_bh(&queue->syn_wait_lock); + + return lopt; +} + +static inline void reqsk_queue_destroy(struct request_sock_queue *queue) +{ + kfree(reqsk_queue_yank_listen_sk(queue)); +} + +static inline struct request_sock * + reqsk_queue_yank_acceptq(struct request_sock_queue *queue) +{ + struct request_sock *req = queue->rskq_accept_head; + + queue->rskq_accept_head = queue->rskq_accept_head = NULL; + return req; +} + +static inline int reqsk_queue_empty(struct request_sock_queue *queue) +{ + return queue->rskq_accept_head == NULL; +} + +static inline void reqsk_queue_unlink(struct request_sock_queue *queue, + struct request_sock *req, + struct request_sock **prev_req) +{ + write_lock(&queue->syn_wait_lock); + *prev_req = req->dl_next; + write_unlock(&queue->syn_wait_lock); +} + +static inline void reqsk_queue_add(struct request_sock_queue *queue, + struct request_sock *req, + struct sock *parent, + struct sock *child) +{ + req->sk = child; + sk_acceptq_added(parent); + + if (queue->rskq_accept_head == NULL) + queue->rskq_accept_head = req; + else + queue->rskq_accept_tail->dl_next = req; + + queue->rskq_accept_tail = req; + req->dl_next = NULL; +} + +static inline struct request_sock *reqsk_queue_remove(struct request_sock_queue *queue) +{ + struct request_sock *req = queue->rskq_accept_head; + + BUG_TRAP(req != NULL); + + queue->rskq_accept_head = req->dl_next; + if (queue->rskq_accept_head == NULL) + queue->rskq_accept_tail = NULL; + + return req; +} + +static inline struct sock *reqsk_queue_get_child(struct request_sock_queue *queue, + struct sock *parent) +{ + struct request_sock *req = reqsk_queue_remove(queue); + struct sock *child = req->sk; + + BUG_TRAP(child != NULL); + + sk_acceptq_removed(parent); + __reqsk_free(req); + return child; +} + +static inline int reqsk_queue_removed(struct request_sock_queue *queue, + struct request_sock *req) +{ + struct tcp_listen_opt *lopt = queue->listen_opt; + + if (req->retrans == 0) + --lopt->qlen_young; + + return --lopt->qlen; +} + +static inline int reqsk_queue_added(struct request_sock_queue *queue) +{ + struct tcp_listen_opt *lopt = queue->listen_opt; + const int prev_qlen = lopt->qlen; + + lopt->qlen_young++; + lopt->qlen++; + return prev_qlen; +} + +static inline int reqsk_queue_len(struct request_sock_queue *queue) +{ + return queue->listen_opt != NULL ? queue->listen_opt->qlen : 0; +} + +static inline int reqsk_queue_len_young(struct request_sock_queue *queue) +{ + return queue->listen_opt->qlen_young; +} + +static inline int reqsk_queue_is_full(struct request_sock_queue *queue) +{ + return queue->listen_opt->qlen >> queue->listen_opt->max_qlen_log; +} + +static inline void reqsk_queue_hash_req(struct request_sock_queue *queue, + u32 hash, struct request_sock *req, + unsigned timeout) +{ + struct tcp_listen_opt *lopt = queue->listen_opt; + + req->expires = jiffies + timeout; + req->retrans = 0; + req->sk = NULL; + req->dl_next = lopt->syn_table[hash]; + + write_lock(&queue->syn_wait_lock); + lopt->syn_table[hash] = req; + write_unlock(&queue->syn_wait_lock); +} + #endif /* _REQUEST_SOCK_H */ diff --git a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -1686,71 +1686,41 @@ static inline int tcp_full_space(const s static inline void tcp_acceptq_queue(struct sock *sk, struct request_sock *req, struct sock *child) { - struct tcp_sock *tp = tcp_sk(sk); - - req->sk = child; - sk_acceptq_added(sk); - - if (!tp->accept_queue_tail) { - tp->accept_queue = req; - } else { - tp->accept_queue_tail->dl_next = req; - } - tp->accept_queue_tail = req; - req->dl_next = NULL; + reqsk_queue_add(&tcp_sk(sk)->accept_queue, req, sk, child); } -struct tcp_listen_opt -{ - u8 max_qlen_log; /* log_2 of maximal queued SYNs */ - int qlen; - int qlen_young; - int clock_hand; - u32 hash_rnd; - struct request_sock *syn_table[TCP_SYNQ_HSIZE]; -}; - static inline void tcp_synq_removed(struct sock *sk, struct request_sock *req) { - struct tcp_listen_opt *lopt = tcp_sk(sk)->listen_opt; - - if (--lopt->qlen == 0) + if (reqsk_queue_removed(&tcp_sk(sk)->accept_queue, req) == 0) tcp_delete_keepalive_timer(sk); - if (req->retrans == 0) - lopt->qlen_young--; } static inline void tcp_synq_added(struct sock *sk) { - struct tcp_listen_opt *lopt = tcp_sk(sk)->listen_opt; - - if (lopt->qlen++ == 0) + if (reqsk_queue_added(&tcp_sk(sk)->accept_queue) == 0) tcp_reset_keepalive_timer(sk, TCP_TIMEOUT_INIT); - lopt->qlen_young++; } static inline int tcp_synq_len(struct sock *sk) { - return tcp_sk(sk)->listen_opt->qlen; + return reqsk_queue_len(&tcp_sk(sk)->accept_queue); } static inline int tcp_synq_young(struct sock *sk) { - return tcp_sk(sk)->listen_opt->qlen_young; + return reqsk_queue_len_young(&tcp_sk(sk)->accept_queue); } static inline int tcp_synq_is_full(struct sock *sk) { - return tcp_synq_len(sk) >> tcp_sk(sk)->listen_opt->max_qlen_log; + return reqsk_queue_is_full(&tcp_sk(sk)->accept_queue); } static inline void tcp_synq_unlink(struct tcp_sock *tp, struct request_sock *req, - struct request_sock **prev) + struct request_sock **prev) { - write_lock(&tp->syn_wait_lock); - *prev = req->dl_next; - write_unlock(&tp->syn_wait_lock); + reqsk_queue_unlink(&tp->accept_queue, req, prev); } static inline void tcp_synq_drop(struct sock *sk, struct request_sock *req, diff --git a/net/core/Makefile b/net/core/Makefile --- a/net/core/Makefile +++ b/net/core/Makefile @@ -2,7 +2,8 @@ # Makefile for the Linux networking core. # -obj-y := sock.o skbuff.o iovec.o datagram.o stream.o scm.o gen_stats.o gen_estimator.o +obj-y := sock.o request_sock.o skbuff.o iovec.o datagram.o stream.o scm.o \ + gen_stats.o gen_estimator.o obj-$(CONFIG_SYSCTL) += sysctl_net_core.o diff --git a/net/core/request_sock.c b/net/core/request_sock.c new file mode 100644 --- /dev/null +++ b/net/core/request_sock.c @@ -0,0 +1,48 @@ +/* + * NET Generic infrastructure for Network protocols. + * + * Authors: Arnaldo Carvalho de Melo + * + * From code originally in include/net/tcp.h + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include + +#include + +int reqsk_queue_alloc(struct request_sock_queue *queue, + const int nr_table_entries) +{ + const int lopt_size = sizeof(struct tcp_listen_opt) + + nr_table_entries * sizeof(struct request_sock *); + struct tcp_listen_opt *lopt = kmalloc(lopt_size, GFP_KERNEL); + + if (lopt == NULL) + return -ENOMEM; + + memset(lopt, 0, lopt_size); + + for (lopt->max_qlen_log = 6; + (1 << lopt->max_qlen_log) < sysctl_max_syn_backlog; + lopt->max_qlen_log++); + + get_random_bytes(&lopt->hash_rnd, sizeof(lopt->hash_rnd)); + rwlock_init(&queue->syn_wait_lock); + queue->rskq_accept_head = queue->rskq_accept_head = NULL; + + write_lock_bh(&queue->syn_wait_lock); + queue->listen_opt = lopt; + write_unlock_bh(&queue->syn_wait_lock); + + return 0; +} + +EXPORT_SYMBOL(reqsk_queue_alloc); diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -316,7 +316,7 @@ EXPORT_SYMBOL(tcp_enter_memory_pressure) static __inline__ unsigned int tcp_listen_poll(struct sock *sk, poll_table *wait) { - return tcp_sk(sk)->accept_queue ? (POLLIN | POLLRDNORM) : 0; + return !reqsk_queue_empty(&tcp_sk(sk)->accept_queue) ? (POLLIN | POLLRDNORM) : 0; } /* @@ -462,28 +462,15 @@ int tcp_listen_start(struct sock *sk) { struct inet_sock *inet = inet_sk(sk); struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt; + int rc = reqsk_queue_alloc(&tp->accept_queue, TCP_SYNQ_HSIZE); + + if (rc != 0) + return rc; sk->sk_max_ack_backlog = 0; sk->sk_ack_backlog = 0; - tp->accept_queue = tp->accept_queue_tail = NULL; - rwlock_init(&tp->syn_wait_lock); tcp_delack_init(tp); - lopt = kmalloc(sizeof(struct tcp_listen_opt), GFP_KERNEL); - if (!lopt) - return -ENOMEM; - - memset(lopt, 0, sizeof(struct tcp_listen_opt)); - for (lopt->max_qlen_log = 6; ; lopt->max_qlen_log++) - if ((1 << lopt->max_qlen_log) >= sysctl_max_syn_backlog) - break; - get_random_bytes(&lopt->hash_rnd, 4); - - write_lock_bh(&tp->syn_wait_lock); - tp->listen_opt = lopt; - write_unlock_bh(&tp->syn_wait_lock); - /* There is race window here: we announce ourselves listening, * but this transition is still not validated by get_port(). * It is OK, because this socket enters to hash table only @@ -500,10 +487,7 @@ int tcp_listen_start(struct sock *sk) } sk->sk_state = TCP_CLOSE; - write_lock_bh(&tp->syn_wait_lock); - tp->listen_opt = NULL; - write_unlock_bh(&tp->syn_wait_lock); - kfree(lopt); + reqsk_queue_destroy(&tp->accept_queue); return -EADDRINUSE; } @@ -515,18 +499,16 @@ int tcp_listen_start(struct sock *sk) static void tcp_listen_stop (struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt = tp->listen_opt; - struct request_sock *acc_req = tp->accept_queue; + struct tcp_listen_opt *lopt; + struct request_sock *acc_req; struct request_sock *req; int i; tcp_delete_keepalive_timer(sk); /* make all the listen_opt local to us */ - write_lock_bh(&tp->syn_wait_lock); - tp->listen_opt = NULL; - write_unlock_bh(&tp->syn_wait_lock); - tp->accept_queue = tp->accept_queue_tail = NULL; + lopt = reqsk_queue_yank_listen_sk(&tp->accept_queue); + acc_req = reqsk_queue_yank_acceptq(&tp->accept_queue); if (lopt->qlen) { for (i = 0; i < TCP_SYNQ_HSIZE; i++) { @@ -1867,11 +1849,11 @@ static int wait_for_connect(struct sock prepare_to_wait_exclusive(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE); release_sock(sk); - if (!tp->accept_queue) + if (reqsk_queue_empty(&tp->accept_queue)) timeo = schedule_timeout(timeo); lock_sock(sk); err = 0; - if (tp->accept_queue) + if (!reqsk_queue_empty(&tp->accept_queue)) break; err = -EINVAL; if (sk->sk_state != TCP_LISTEN) @@ -1894,7 +1876,6 @@ static int wait_for_connect(struct sock struct sock *tcp_accept(struct sock *sk, int flags, int *err) { struct tcp_sock *tp = tcp_sk(sk); - struct request_sock *req; struct sock *newsk; int error; @@ -1905,37 +1886,31 @@ struct sock *tcp_accept(struct sock *sk, */ error = -EINVAL; if (sk->sk_state != TCP_LISTEN) - goto out; + goto out_err; /* Find already established connection */ - if (!tp->accept_queue) { + if (reqsk_queue_empty(&tp->accept_queue)) { long timeo = sock_rcvtimeo(sk, flags & O_NONBLOCK); /* If this is a non blocking socket don't sleep */ error = -EAGAIN; if (!timeo) - goto out; + goto out_err; error = wait_for_connect(sk, timeo); if (error) - goto out; + goto out_err; } - req = tp->accept_queue; - if ((tp->accept_queue = req->dl_next) == NULL) - tp->accept_queue_tail = NULL; - - newsk = req->sk; - sk_acceptq_removed(sk); - __reqsk_free(req); + newsk = reqsk_queue_get_child(&tp->accept_queue, sk); BUG_TRAP(newsk->sk_state != TCP_SYN_RECV); - release_sock(sk); - return newsk; - out: release_sock(sk); + return newsk; +out_err: + newsk = NULL; *err = error; - return NULL; + goto out; } /* diff --git a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c --- a/net/ipv4/tcp_diag.c +++ b/net/ipv4/tcp_diag.c @@ -529,9 +529,9 @@ static int tcpdiag_dump_reqs(struct sk_b entry.family = sk->sk_family; - read_lock_bh(&tp->syn_wait_lock); + read_lock_bh(&tp->accept_queue.syn_wait_lock); - lopt = tp->listen_opt; + lopt = tp->accept_queue.listen_opt; if (!lopt || !lopt->qlen) goto out; @@ -588,7 +588,7 @@ static int tcpdiag_dump_reqs(struct sk_b } out: - read_unlock_bh(&tp->syn_wait_lock); + read_unlock_bh(&tp->accept_queue.syn_wait_lock); return err; } diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -874,7 +874,7 @@ static struct request_sock *tcp_v4_searc __u16 rport, __u32 raddr, __u32 laddr) { - struct tcp_listen_opt *lopt = tp->listen_opt; + struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; struct request_sock *req, **prev; for (prev = &lopt->syn_table[tcp_v4_synq_hash(raddr, rport, lopt->hash_rnd)]; @@ -898,18 +898,10 @@ static struct request_sock *tcp_v4_searc static void tcp_v4_synq_add(struct sock *sk, struct request_sock *req) { struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt = tp->listen_opt; + struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; u32 h = tcp_v4_synq_hash(inet_rsk(req)->rmt_addr, inet_rsk(req)->rmt_port, lopt->hash_rnd); - req->expires = jiffies + TCP_TIMEOUT_INIT; - req->retrans = 0; - req->sk = NULL; - req->dl_next = lopt->syn_table[h]; - - write_lock(&tp->syn_wait_lock); - lopt->syn_table[h] = req; - write_unlock(&tp->syn_wait_lock); - + reqsk_queue_hash_req(&tp->accept_queue, h, req, TCP_TIMEOUT_INIT); tcp_synq_added(sk); } @@ -2167,17 +2159,17 @@ static void *listening_get_next(struct s if (++st->sbucket >= TCP_SYNQ_HSIZE) break; get_req: - req = tp->listen_opt->syn_table[st->sbucket]; + req = tp->accept_queue.listen_opt->syn_table[st->sbucket]; } sk = sk_next(st->syn_wait_sk); st->state = TCP_SEQ_STATE_LISTENING; - read_unlock_bh(&tp->syn_wait_lock); + read_unlock_bh(&tp->accept_queue.syn_wait_lock); } else { tp = tcp_sk(sk); - read_lock_bh(&tp->syn_wait_lock); - if (tp->listen_opt && tp->listen_opt->qlen) + read_lock_bh(&tp->accept_queue.syn_wait_lock); + if (reqsk_queue_len(&tp->accept_queue)) goto start_req; - read_unlock_bh(&tp->syn_wait_lock); + read_unlock_bh(&tp->accept_queue.syn_wait_lock); sk = sk_next(sk); } get_sk: @@ -2187,8 +2179,8 @@ get_sk: goto out; } tp = tcp_sk(sk); - read_lock_bh(&tp->syn_wait_lock); - if (tp->listen_opt && tp->listen_opt->qlen) { + read_lock_bh(&tp->accept_queue.syn_wait_lock); + if (reqsk_queue_len(&tp->accept_queue)) { start_req: st->uid = sock_i_uid(sk); st->syn_wait_sk = sk; @@ -2196,7 +2188,7 @@ start_req: st->sbucket = 0; goto get_req; } - read_unlock_bh(&tp->syn_wait_lock); + read_unlock_bh(&tp->accept_queue.syn_wait_lock); } if (++st->bucket < TCP_LHTABLE_SIZE) { sk = sk_head(&tcp_listening_hash[st->bucket]); @@ -2383,7 +2375,7 @@ static void tcp_seq_stop(struct seq_file case TCP_SEQ_STATE_OPENREQ: if (v) { struct tcp_sock *tp = tcp_sk(st->syn_wait_sk); - read_unlock_bh(&tp->syn_wait_lock); + read_unlock_bh(&tp->accept_queue.syn_wait_lock); } case TCP_SEQ_STATE_LISTENING: if (v != SEQ_START_TOKEN) diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c --- a/net/ipv4/tcp_minisocks.c +++ b/net/ipv4/tcp_minisocks.c @@ -790,10 +790,8 @@ struct sock *tcp_create_openreq_child(st newtp->probes_out = 0; newtp->rx_opt.num_sacks = 0; newtp->urg_data = 0; - newtp->listen_opt = NULL; - newtp->accept_queue = newtp->accept_queue_tail = NULL; - /* Deinitialize syn_wait_lock to trap illegal accesses. */ - memset(&newtp->syn_wait_lock, 0, sizeof(newtp->syn_wait_lock)); + /* Deinitialize accept_queue to trap illegal accesses. */ + memset(&newtp->accept_queue, 0, sizeof(newtp->accept_queue)); /* Back to base struct sock members. */ newsk->sk_err = 0; diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c --- a/net/ipv4/tcp_timer.c +++ b/net/ipv4/tcp_timer.c @@ -464,7 +464,7 @@ out_unlock: static void tcp_synack_timer(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt = tp->listen_opt; + struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; int max_retries = tp->syn_retries ? : sysctl_tcp_synack_retries; int thresh = max_retries; unsigned long now = jiffies; @@ -527,12 +527,8 @@ static void tcp_synack_timer(struct sock } /* Drop this request */ - write_lock(&tp->syn_wait_lock); - *reqp = req->dl_next; - write_unlock(&tp->syn_wait_lock); - lopt->qlen--; - if (req->retrans == 0) - lopt->qlen_young--; + tcp_synq_unlink(tp, req, reqp); + reqsk_queue_removed(&tp->accept_queue, req); reqsk_free(req); continue; } diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -401,7 +401,7 @@ static struct request_sock *tcp_v6_searc struct in6_addr *laddr, int iif) { - struct tcp_listen_opt *lopt = tp->listen_opt; + struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; struct request_sock *req, **prev; for (prev = &lopt->syn_table[tcp_v6_synq_hash(raddr, rport, lopt->hash_rnd)]; @@ -1267,18 +1267,10 @@ static struct sock *tcp_v6_hnd_req(struc static void tcp_v6_synq_add(struct sock *sk, struct request_sock *req) { struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt = tp->listen_opt; + struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; u32 h = tcp_v6_synq_hash(&tcp6_rsk(req)->rmt_addr, inet_rsk(req)->rmt_port, lopt->hash_rnd); - req->sk = NULL; - req->expires = jiffies + TCP_TIMEOUT_INIT; - req->retrans = 0; - req->dl_next = lopt->syn_table[h]; - - write_lock(&tp->syn_wait_lock); - lopt->syn_table[h] = req; - write_unlock(&tp->syn_wait_lock); - + reqsk_queue_hash_req(&tp->accept_queue, h, req, TCP_TIMEOUT_INIT); tcp_synq_added(sk); } From acme@ghostprotocols.net Mon May 23 18:18:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:18:51 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1IiF3030103 for ; Mon, 23 May 2005 18:18:45 -0700 Received: from 201-15-204-66.ctame704.dsl.brasiltelecom.net.br ([201.15.204.66] helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DaOAJ-0001ia-00; Mon, 23 May 2005 22:25:03 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id 7697314631; Mon, 23 May 2005 22:17:58 -0300 (BRT) Date: Mon, 23 May 2005 22:17:58 -0300 To: "David S.Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2/2][NET] rename struct tcp_listen_opt to struct listen_sock Message-ID: <20050524011758.GJ26989@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) X-archive-position: 1529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@ghostprotocols.net Precedence: bulk X-list: netdev Content-Length: 6806 Lines: 188 Hi David, Please consider pulling into your net-2.6.13 pending tree from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.13.git Best Regards, - Arnaldo tree b1aabc6ec772af37643e4eab8d35a48f5ca5d799 parent a48a17a6700bb4e6eed677e25422adf478f85c4d author Arnaldo Carvalho de Melo 1113624884 -0300 committer Arnaldo Carvalho de Melo 1116888488 -0300 [NET] rename struct tcp_listen_opt to struct listen_sock Signed-off-by: Arnaldo Carvalho de Melo ------------------------------------------------------------------------------ include/net/request_sock.h | 16 ++++++++-------- net/core/request_sock.c | 4 ++-- net/ipv4/tcp.c | 2 +- net/ipv4/tcp_diag.c | 2 +- net/ipv4/tcp_ipv4.c | 4 ++-- net/ipv4/tcp_timer.c | 2 +- net/ipv6/tcp_ipv6.c | 4 ++-- 7 files changed, 17 insertions(+), 17 deletions(-) ------------------------------------------------------------------------------ diff --git a/include/net/request_sock.h b/include/net/request_sock.h --- a/include/net/request_sock.h +++ b/include/net/request_sock.h @@ -78,11 +78,11 @@ static inline void reqsk_free(struct req extern int sysctl_max_syn_backlog; -/** struct tcp_listen_opt - listen state +/** struct listen_sock - listen state * * @max_qlen_log - log_2 of maximal queued SYNs/REQUESTs */ -struct tcp_listen_opt { +struct listen_sock { u8 max_qlen_log; /* 3 bytes hole, try to use */ int qlen; @@ -111,15 +111,15 @@ struct request_sock_queue { struct request_sock *rskq_accept_head; struct request_sock *rskq_accept_tail; rwlock_t syn_wait_lock; - struct tcp_listen_opt *listen_opt; + struct listen_sock *listen_opt; }; extern int reqsk_queue_alloc(struct request_sock_queue *queue, const int nr_table_entries); -static inline struct tcp_listen_opt *reqsk_queue_yank_listen_sk(struct request_sock_queue *queue) +static inline struct listen_sock *reqsk_queue_yank_listen_sk(struct request_sock_queue *queue) { - struct tcp_listen_opt *lopt; + struct listen_sock *lopt; write_lock_bh(&queue->syn_wait_lock); lopt = queue->listen_opt; @@ -203,7 +203,7 @@ static inline struct sock *reqsk_queue_g static inline int reqsk_queue_removed(struct request_sock_queue *queue, struct request_sock *req) { - struct tcp_listen_opt *lopt = queue->listen_opt; + struct listen_sock *lopt = queue->listen_opt; if (req->retrans == 0) --lopt->qlen_young; @@ -213,7 +213,7 @@ static inline int reqsk_queue_removed(st static inline int reqsk_queue_added(struct request_sock_queue *queue) { - struct tcp_listen_opt *lopt = queue->listen_opt; + struct listen_sock *lopt = queue->listen_opt; const int prev_qlen = lopt->qlen; lopt->qlen_young++; @@ -240,7 +240,7 @@ static inline void reqsk_queue_hash_req( u32 hash, struct request_sock *req, unsigned timeout) { - struct tcp_listen_opt *lopt = queue->listen_opt; + struct listen_sock *lopt = queue->listen_opt; req->expires = jiffies + timeout; req->retrans = 0; diff --git a/net/core/request_sock.c b/net/core/request_sock.c --- a/net/core/request_sock.c +++ b/net/core/request_sock.c @@ -21,9 +21,9 @@ int reqsk_queue_alloc(struct request_sock_queue *queue, const int nr_table_entries) { - const int lopt_size = sizeof(struct tcp_listen_opt) + + const int lopt_size = sizeof(struct listen_sock) + nr_table_entries * sizeof(struct request_sock *); - struct tcp_listen_opt *lopt = kmalloc(lopt_size, GFP_KERNEL); + struct listen_sock *lopt = kmalloc(lopt_size, GFP_KERNEL); if (lopt == NULL) return -ENOMEM; diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -499,7 +499,7 @@ int tcp_listen_start(struct sock *sk) static void tcp_listen_stop (struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt; + struct listen_sock *lopt; struct request_sock *acc_req; struct request_sock *req; int i; diff --git a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c --- a/net/ipv4/tcp_diag.c +++ b/net/ipv4/tcp_diag.c @@ -514,7 +514,7 @@ static int tcpdiag_dump_reqs(struct sk_b struct tcpdiag_entry entry; struct tcpdiagreq *r = NLMSG_DATA(cb->nlh); struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt; + struct listen_sock *lopt; struct rtattr *bc = NULL; struct inet_sock *inet = inet_sk(sk); int j, s_j; diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -874,7 +874,7 @@ static struct request_sock *tcp_v4_searc __u16 rport, __u32 raddr, __u32 laddr) { - struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; + struct listen_sock *lopt = tp->accept_queue.listen_opt; struct request_sock *req, **prev; for (prev = &lopt->syn_table[tcp_v4_synq_hash(raddr, rport, lopt->hash_rnd)]; @@ -898,7 +898,7 @@ static struct request_sock *tcp_v4_searc static void tcp_v4_synq_add(struct sock *sk, struct request_sock *req) { struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; + struct listen_sock *lopt = tp->accept_queue.listen_opt; u32 h = tcp_v4_synq_hash(inet_rsk(req)->rmt_addr, inet_rsk(req)->rmt_port, lopt->hash_rnd); reqsk_queue_hash_req(&tp->accept_queue, h, req, TCP_TIMEOUT_INIT); diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c --- a/net/ipv4/tcp_timer.c +++ b/net/ipv4/tcp_timer.c @@ -464,7 +464,7 @@ out_unlock: static void tcp_synack_timer(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; + struct listen_sock *lopt = tp->accept_queue.listen_opt; int max_retries = tp->syn_retries ? : sysctl_tcp_synack_retries; int thresh = max_retries; unsigned long now = jiffies; diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -401,7 +401,7 @@ static struct request_sock *tcp_v6_searc struct in6_addr *laddr, int iif) { - struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; + struct listen_sock *lopt = tp->accept_queue.listen_opt; struct request_sock *req, **prev; for (prev = &lopt->syn_table[tcp_v6_synq_hash(raddr, rport, lopt->hash_rnd)]; @@ -1267,7 +1267,7 @@ static struct sock *tcp_v6_hnd_req(struc static void tcp_v6_synq_add(struct sock *sk, struct request_sock *req) { struct tcp_sock *tp = tcp_sk(sk); - struct tcp_listen_opt *lopt = tp->accept_queue.listen_opt; + struct listen_sock *lopt = tp->accept_queue.listen_opt; u32 h = tcp_v6_synq_hash(&tcp6_rsk(req)->rmt_addr, inet_rsk(req)->rmt_port, lopt->hash_rnd); reqsk_queue_hash_req(&tp->accept_queue, h, req, TCP_TIMEOUT_INIT); From mchan@broadcom.com Mon May 23 18:23:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:23:52 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1NlF3031067 for ; Mon, 23 May 2005 18:23:47 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:22:54 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:22:52 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZY37476; Mon, 23 May 2005 18:22:51 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16125; Mon, 23 May 2005 18:22:50 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:22:50 +0000 Received: from rh4 by nt-irva-0741; 23 May 2005 17:25:07 -0700 Subject: [PATCH 1/6] bnx2: Fix excessive stack usage From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1116892439.4908.1.camel@rh4> References: <1116892439.4908.1.camel@rh4> Date: Mon, 23 May 2005 17:25:07 -0700 Message-ID: <1116894307.4908.28.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E8C5E641VO1443191-01-01 Content-Type: multipart/mixed; boundary="=-wQetfnmSM4zpCE9lu3Ns" X-archive-position: 1530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 3038 Lines: 57 --=-wQetfnmSM4zpCE9lu3Ns Content-Type: text/plain Content-Transfer-Encoding: 7bit Fix excessive stack usage in bnx2_alloc_bad_rbuf() by replacing local variable array with kmalloc array. Also changed function to return error code, and changed some of the callers to check for the return code. Spotted by Jeff Garzik. Signed-off-by: Michael Chan --=-wQetfnmSM4zpCE9lu3Ns Content-Disposition: attachment; filename=bnx2-11.patch Content-Type: text/x-patch; charset=utf-8; name=bnx2-11.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDEwL2RyaXZlcnMvbmV0L2JueDIuYyAxMS9kcml2ZXJzL25ldC9ibngyLmMNCi0t LSAxMC9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDoyMDowMi4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMS9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDoyMDoyMC4wMDAwMDAw MDAgLTA3MDANCkBAIC0xMTM4LDEzICsxMTM4LDIwIEBADQogCX0NCiB9DQogDQotc3RhdGljIHZv aWQNCitzdGF0aWMgaW50DQogYm54Ml9hbGxvY19iYWRfcmJ1ZihzdHJ1Y3QgYm54MiAqYnApDQog ew0KLQl1MTYgZ29vZF9tYnVmWzUxMl07DQorCXUxNiAqZ29vZF9tYnVmOw0KIAl1MzIgZ29vZF9t YnVmX2NudDsNCiAJdTMyIHZhbDsNCiANCisJZ29vZF9tYnVmID0ga21hbGxvYyg1MTIgKiBzaXpl b2YodTE2KSwgR0ZQX0tFUk5FTCk7DQorCWlmIChnb29kX21idWYgPT0gTlVMTCkgew0KKwkJcHJp bnRrKEtFUk5fRVJSIFBGWCAiRmFpbGVkIHRvIGFsbG9jYXRlIG1lbW9yeSBpbiAiDQorCQkJCSAg ICAiYm54Ml9hbGxvY19iYWRfcmJ1ZlxuIik7DQorCQlyZXR1cm4gLUVOT01FTTsNCisJfQ0KKw0K IAlSRUdfV1IoYnAsIEJOWDJfTUlTQ19FTkFCTEVfU0VUX0JJVFMsDQogCQlCTlgyX01JU0NfRU5B QkxFX1NFVF9CSVRTX1JYX01CVUZfRU5BQkxFKTsNCiANCkBAIC0xMTc4LDYgKzExODUsNyBAQA0K IA0KIAkJUkVHX1dSX0lORChicCwgQk5YMl9SQlVGX0ZXX0JVRl9GUkVFLCB2YWwpOw0KIAl9DQor CXJldHVybiAwOw0KIH0NCiANCiBzdGF0aWMgdm9pZA0KQEAgLTI3MTAsNyArMjcxOCw3IEBADQog Ym54Ml9yZXNldF9jaGlwKHN0cnVjdCBibngyICpicCwgdTMyIHJlc2V0X2NvZGUpDQogew0KIAl1 MzIgdmFsOw0KLQlpbnQgaTsNCisJaW50IGksIHJjID0gMDsNCiANCiAJLyogV2FpdCBmb3IgdGhl IGN1cnJlbnQgUENJIHRyYW5zYWN0aW9uIHRvIGNvbXBsZXRlIGJlZm9yZQ0KIAkgKiBpc3N1aW5n IGEgcmVzZXQuICovDQpAQCAtMjc4NSwxMCArMjc5MywxMCBAQA0KIAkJUkVHX1dSKGJwLCBCTlgy X01JU0NfVlJFR19DT05UUk9MLCAweDAwMDAwMGZhKTsNCiANCiAJCS8qIFJlbW92ZSBiYWQgcmJ1 ZiBtZW1vcnkgZnJvbSB0aGUgZnJlZSBwb29sLiAqLw0KLQkJYm54Ml9hbGxvY19iYWRfcmJ1Zihi cCk7DQorCQlyYyA9IGJueDJfYWxsb2NfYmFkX3JidWYoYnApOw0KIAl9DQogDQotCXJldHVybiAw Ow0KKwlyZXR1cm4gcmM7DQogfQ0KIA0KIHN0YXRpYyBpbnQNCkBAIC0zMDk3LDggKzMxMDUsMTMg QEANCiBzdGF0aWMgaW50DQogYm54Ml9yZXNldF9uaWMoc3RydWN0IGJueDIgKmJwLCB1MzIgcmVz ZXRfY29kZSkNCiB7DQotCWJueDJfcmVzZXRfY2hpcChicCwgcmVzZXRfY29kZSk7DQorCWludCBy YzsNCisNCisJcmMgPSBibngyX3Jlc2V0X2NoaXAoYnAsIHJlc2V0X2NvZGUpOw0KIAlibngyX2Zy ZWVfc2ticyhicCk7DQorCWlmIChyYykNCisJCXJldHVybiByYzsNCisNCiAJYm54Ml9pbml0X2No aXAoYnApOw0KIAlibngyX2luaXRfdHhfcmluZyhicCk7DQogCWJueDJfaW5pdF9yeF9yaW5nKGJw KTsNCkBAIC0zMTA4LDcgKzMxMjEsMTEgQEANCiBzdGF0aWMgaW50DQogYm54Ml9pbml0X25pYyhz dHJ1Y3QgYm54MiAqYnApDQogew0KLQlibngyX3Jlc2V0X25pYyhicCwgQk5YMl9EUlZfTVNHX0NP REVfUkVTRVQpOw0KKwlpbnQgcmM7DQorDQorCWlmICgocmMgPSBibngyX3Jlc2V0X25pYyhicCwg Qk5YMl9EUlZfTVNHX0NPREVfUkVTRVQpKSAhPSAwKQ0KKwkJcmV0dXJuIHJjOw0KKw0KIAlibngy X2luaXRfcGh5KGJwKTsNCiAJYm54Ml9zZXRfbGluayhicCk7DQogCXJldHVybiAwOw0K --=-wQetfnmSM4zpCE9lu3Ns-- From mchan@broadcom.com Mon May 23 18:25:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:25:08 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1P4F3031331 for ; Mon, 23 May 2005 18:25:04 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:24:08 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:24:07 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZY37732; Mon, 23 May 2005 18:24:07 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16376; Mon, 23 May 2005 18:24:06 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:24:06 +0000 Received: from rh4 by nt-irva-0741; 23 May 2005 17:26:23 -0700 Subject: [PATCH 2/6] bnx2: Fix rx checksum From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1116892439.4908.1.camel@rh4> References: <1116892439.4908.1.camel@rh4> Date: Mon, 23 May 2005 17:26:23 -0700 Message-ID: <1116894383.4908.29.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E8C5DB21VO1443376-01-01 Content-Type: multipart/mixed; boundary="=-MjP9kNbfLluHpwDwIMre" X-archive-position: 1531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1030 Lines: 33 --=-MjP9kNbfLluHpwDwIMre Content-Type: text/plain Content-Transfer-Encoding: 7bit Fix bug in rx checksum by indicating CHECKSUM_UNNECESSARY only when the hw calculated checksum is 0xffff. Spotted by Jeff Garzik. Signed-off-by: Michael Chan --=-MjP9kNbfLluHpwDwIMre Content-Disposition: attachment; filename=bnx2-12.patch Content-Type: text/x-patch; charset=utf-8; name=bnx2-12.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDExL2RyaXZlcnMvbmV0L2JueDIuYyAxMi9kcml2ZXJzL25ldC9ibngyLmMNCi0t LSAxMS9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDoyMDoyMC4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMi9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDoyOTowMi4wMDAwMDAw MDAgLTA3MDANCkBAIC0xNDcwLDkgKzE0NzAsOCBAQA0KIA0KIAkJCXUxNiBja3N1bSA9IHJ4X2hk ci0+bDJfZmhkcl90Y3BfdWRwX3hzdW07DQogDQotCQkJaWYgKChja3N1bSA9PSAweGZmZmYpIHx8 IChja3N1bSA9PSAwKSkgew0KKwkJCWlmIChja3N1bSA9PSAweGZmZmYpDQogCQkJCXNrYi0+aXBf c3VtbWVkID0gQ0hFQ0tTVU1fVU5ORUNFU1NBUlk7DQotCQkJfQ0KIAkJfQ0KIA0KICNpZmRlZiBC Q01fVkxBTg0K --=-MjP9kNbfLluHpwDwIMre-- From mchan@broadcom.com Mon May 23 18:26:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:26:28 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1QQF3031861 for ; Mon, 23 May 2005 18:26:26 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:25:32 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:25:31 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZY37927; Mon, 23 May 2005 18:25:27 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16597; Mon, 23 May 2005 18:25:26 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:25:26 +0000 Received: from rh4 by nt-irva-0741; 23 May 2005 17:27:43 -0700 Subject: [PATCH 3/6] bnx2: Fix excessive udelay From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1116892439.4908.1.camel@rh4> References: <1116892439.4908.1.camel@rh4> Date: Mon, 23 May 2005 17:27:43 -0700 Message-ID: <1116894463.4908.30.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E8C5D061VO1443603-01-01 Content-Type: multipart/mixed; boundary="=-4hS86m+LI1RxJ2a9xzMz" X-archive-position: 1532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 3754 Lines: 67 --=-4hS86m+LI1RxJ2a9xzMz Content-Type: text/plain Content-Transfer-Encoding: 7bit Replaced one excessive udelay of 15msec with msleep since the calling context is always process. Also replaced some schedule_timeout calls with msleep/msleep_interruptible. Spotted by Jeff Garzik. Signed-off-by: Michael Chan --=-4hS86m+LI1RxJ2a9xzMz Content-Disposition: attachment; filename=bnx2-13.patch Content-Type: text/x-patch; charset=utf-8; name=bnx2-13.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDEyL2RyaXZlcnMvbmV0L2JueDIuYyAxMy9kcml2ZXJzL25ldC9ibngyLmMNCi0t LSAxMi9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDoyOTowMi4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMy9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDo1Nzo0MS4wMDAwMDAw MDAgLTA3MDANCkBAIC0yMDExLDExICsyMDExLDkgQEANCiAJCQkocG1jc3IgJiB+UENJX1BNX0NU UkxfU1RBVEVfTUFTSykgfA0KIAkJCVBDSV9QTV9DVFJMX1BNRV9TVEFUVVMpOw0KIA0KLQkJaWYg KHBtY3NyICYgUENJX1BNX0NUUkxfU1RBVEVfTUFTSykgew0KKwkJaWYgKHBtY3NyICYgUENJX1BN X0NUUkxfU1RBVEVfTUFTSykNCiAJCQkvKiBkZWxheSByZXF1aXJlZCBkdXJpbmcgdHJhbnNpdGlv biBvdXQgb2YgRDNob3QgKi8NCi0JCQljdXJyZW50LT5zdGF0ZSA9IFRBU0tfVU5JTlRFUlJVUFRJ QkxFOw0KLQkJCXNjaGVkdWxlX3RpbWVvdXQoSFogLyA1MCk7DQotCQl9DQorCQkJbXNsZWVwKDIw KTsNCiANCiAJCXZhbCA9IFJFR19SRChicCwgQk5YMl9FTUFDX01PREUpOw0KIAkJdmFsIHw9IEJO WDJfRU1BQ19NT0RFX01QS1RfUkNWRCB8IEJOWDJfRU1BQ19NT0RFX0FDUElfUkNWRDsNCkBAIC0y NzUxLDEyICsyNzQ5LDggQEANCiAJUkVHX1dSKGJwLCBCTlgyX1BDSUNGR19NSVNDX0NPTkZJRywg dmFsKTsNCiANCiAJaWYgKChDSElQX0lEKGJwKSA9PSBDSElQX0lEXzU3MDZfQTApIHx8DQotCSAg ICAoQ0hJUF9JRChicCkgPT0gQ0hJUF9JRF81NzA2X0ExKSkgew0KLQ0KLQkgICAgICAgIGZvciAo aSA9IDA7IGkgPCA1MDA7IGkrKykgew0KLQkJCXVkZWxheSgzMCk7DQotCQl9DQotCX0NCisJICAg IChDSElQX0lEKGJwKSA9PSBDSElQX0lEXzU3MDZfQTEpKQ0KKwkJbXNsZWVwKDE1KTsNCiANCiAJ LyogUmVzZXQgdGFrZXMgYXBwcm94aW1hdGUgMzAgdXNlYyAqLw0KIAlmb3IgKGkgPSAwOyBpIDwg MTA7IGkrKykgew0KQEAgLTM3ODUsOCArMzc3OSw2IEBADQogCVJFR19XUihicCwgQk5YMl9IQ19D T01NQU5ELCB2YWwgfCBCTlgyX0hDX0NPTU1BTkRfQ09BTF9OT1cpOw0KIAlSRUdfUkQoYnAsIEJO WDJfSENfQ09NTUFORCk7DQogDQotCXVkZWxheSg4MCk7DQotDQogCWZvciAoaSA9IDA7IGkgPCAx MDsgaSsrKSB7DQogCQlpZiAoKFJFR19SRChicCwgQk5YMl9QQ0lDRkdfSU5UX0FDS19DTUQpICYg MHhmZmZmKSAhPQ0KIAkJCXN0YXR1c19pZHgpIHsNCkBAIC0zNzk0LDggKzM3ODYsNyBAQA0KIAkJ CWJyZWFrOw0KIAkJfQ0KIA0KLQkJY3VycmVudC0+c3RhdGUgPSBUQVNLX0lOVEVSUlVQVElCTEU7 DQotCQlzY2hlZHVsZV90aW1lb3V0KDEpOw0KKwkJbXNsZWVwX2ludGVycnVwdGlibGUoMTApOw0K IAl9DQogCWlmIChpIDwgMTApDQogCQlyZXR1cm4gMDsNCkBAIC00NDc4LDggKzQ0NjksNyBAQA0K IAkJYm54Ml93cml0ZV9waHkoYnAsIE1JSV9CTUNSLCBCTUNSX0xPT1BCQUNLKTsNCiAJCXNwaW5f dW5sb2NrX2lycSgmYnAtPnBoeV9sb2NrKTsNCiANCi0JCWN1cnJlbnQtPnN0YXRlID0gVEFTS19V TklOVEVSUlVQVElCTEU7DQotCQlzY2hlZHVsZV90aW1lb3V0KEhaIC8gNTApOw0KKwkJbXNsZWVw KDIwKTsNCiANCiAJCXNwaW5fbG9ja19pcnEoJmJwLT5waHlfbG9jayk7DQogCQlpZiAoQ0hJUF9O VU0oYnApID09IENISVBfTlVNXzU3MDYpIHsNCkBAIC00ODY5LDEyICs0ODU5LDkgQEANCiAJCX0N CiANCiAJCS8qIHdhaXQgZm9yIGxpbmsgdXAgKi8NCi0JCWN1cnJlbnQtPnN0YXRlID0gVEFTS19J TlRFUlJVUFRJQkxFOw0KLQkJc2NoZWR1bGVfdGltZW91dCgzICogSFopOw0KLQkJaWYgKCghYnAt PmxpbmtfdXApICYmICEoYnAtPnBoeV9mbGFncyAmIFBIWV9TRVJERVNfRkxBRykpIHsNCi0JCQlj dXJyZW50LT5zdGF0ZSA9IFRBU0tfSU5URVJSVVBUSUJMRTsNCi0JCQlzY2hlZHVsZV90aW1lb3V0 KDQgKiBIWik7DQotCQl9DQorCQltc2xlZXBfaW50ZXJydXB0aWJsZSgzMDAwKTsNCisJCWlmICgo IWJwLT5saW5rX3VwKSAmJiAhKGJwLT5waHlfZmxhZ3MgJiBQSFlfU0VSREVTX0ZMQUcpKQ0KKwkJ CW1zbGVlcF9pbnRlcnJ1cHRpYmxlKDQwMDApOw0KIAl9DQogDQogCWlmIChibngyX3Rlc3RfbnZy YW0oYnApICE9IDApIHsNCkBAIC00OTc1LDggKzQ5NjIsNyBAQA0KIAkJCQlCTlgyX0VNQUNfTEVE X1RSQUZGSUNfT1ZFUlJJREUgfA0KIAkJCQlCTlgyX0VNQUNfTEVEX1RSQUZGSUMpOw0KIAkJfQ0K LQkJY3VycmVudC0+c3RhdGUgPSBUQVNLX0lOVEVSUlVQVElCTEU7DQotCQlzY2hlZHVsZV90aW1l b3V0KEhaIC8gMik7DQorCQltc2xlZXBfaW50ZXJydXB0aWJsZSg1MDApOw0KIAkJaWYgKHNpZ25h bF9wZW5kaW5nKGN1cnJlbnQpKQ0KIAkJCWJyZWFrOw0KIAl9DQo= --=-4hS86m+LI1RxJ2a9xzMz-- From mchan@broadcom.com Mon May 23 18:27:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:27:46 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1RhF3032603 for ; Mon, 23 May 2005 18:27:43 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:26:49 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:26:48 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZY38167; Mon, 23 May 2005 18:26:47 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16842; Mon, 23 May 2005 18:26:47 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:26:47 +0000 Received: from rh4 by nt-irva-0741; 23 May 2005 17:29:03 -0700 Subject: [PATCH 4/6] bnx2: Fix bug in bnx2_close From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1116892439.4908.1.camel@rh4> References: <1116892439.4908.1.camel@rh4> Date: Mon, 23 May 2005 17:29:03 -0700 Message-ID: <1116894543.4908.32.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E8C5D531VO1443816-01-01 Content-Type: multipart/mixed; boundary="=-kVtupVzl5sY8iZGVxtrc" X-archive-position: 1533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1121 Lines: 34 --=-kVtupVzl5sY8iZGVxtrc Content-Type: text/plain Content-Transfer-Encoding: 7bit Fix bug in bnx2_close() by calling flush_scheduled_work() since we are using a work queue in netdev watchdog. Also added bnx2_netif_stop() call in bnx2_close(). Spotted by Jeff Garzik. Signed-off-by: Michael Chan --=-kVtupVzl5sY8iZGVxtrc Content-Disposition: attachment; filename=bnx2-14.patch Content-Type: text/x-patch; charset=utf-8; name=bnx2-14.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDEzL2RyaXZlcnMvbmV0L2JueDIuYyAxNC9kcml2ZXJzL25ldC9ibngyLmMNCi0t LSAxMy9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDo1Nzo0MS4wMDAwMDAwMDAgLTA3 MDANCisrKyAxNC9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMzowMTo0NS4wMDAwMDAw MDAgLTA3MDANCkBAIC00MTcyLDcgKzQxNzIsOCBAQA0KIAlzdHJ1Y3QgYm54MiAqYnAgPSBkZXYt PnByaXY7DQogCXUzMiByZXNldF9jb2RlOw0KIA0KLQlibngyX2Rpc2FibGVfaW50X3N5bmMoYnAp Ow0KKwlmbHVzaF9zY2hlZHVsZWRfd29yaygpOw0KKwlibngyX25ldGlmX3N0b3AoYnApOw0KIAlk ZWxfdGltZXJfc3luYygmYnAtPnRpbWVyKTsNCiAJaWYgKGJwLT53b2wpDQogCQlyZXNldF9jb2Rl ID0gQk5YMl9EUlZfTVNHX0NPREVfU1VTUEVORF9XT0w7DQo= --=-kVtupVzl5sY8iZGVxtrc-- From mchan@broadcom.com Mon May 23 18:28:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:28:16 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1SDF3000312 for ; Mon, 23 May 2005 18:28:13 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:27:17 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:27:15 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZY38258; Mon, 23 May 2005 18:27:15 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16891; Mon, 23 May 2005 18:27:15 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:27:15 +0000 Received: from rh4 by nt-irva-0741; 23 May 2005 17:29:31 -0700 Subject: [PATCH 5/6] bnx2: Add bnx2 prefix and mark static From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1116892439.4908.1.camel@rh4> References: <1116892439.4908.1.camel@rh4> Date: Mon, 23 May 2005 17:29:31 -0700 Message-ID: <1116894571.4908.33.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E8C5D7F1VO1443898-01-01 Content-Type: multipart/mixed; boundary="=-ntrXuoi1OaRC1/w9Dti2" X-archive-position: 1534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 26943 Lines: 368 --=-ntrXuoi1OaRC1/w9Dti2 Content-Type: text/plain Content-Transfer-Encoding: 7bit Add bnx2_ prefix to some remaining names and mark some remaining names static. Spotted by David Miller and Jeff Garzik. Signed-off-by: Michael Chan --=-ntrXuoi1OaRC1/w9Dti2 Content-Disposition: attachment; filename=bnx2-15.patch Content-Type: text/x-patch; charset=utf-8; name=bnx2-15.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDE0L2RyaXZlcnMvbmV0L2JueDIuYyAxNS9kcml2ZXJzL25ldC9ibngyLmMNCi0t LSAxNC9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMzowMTo0NS4wMDAwMDAwMDAgLTA3 MDANCisrKyAxNS9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMzozMTowNS4wMDAwMDAw MDAgLTA3MDANCkBAIC0yNjQsNyArMjY0LDcgQEANCiAJc3luY2hyb25pemVfaXJxKGJwLT5wZGV2 LT5pcnEpOw0KIH0NCiANCi12b2lkDQorc3RhdGljIHZvaWQNCiBibngyX25ldGlmX3N0b3Aoc3Ry dWN0IGJueDIgKmJwKQ0KIHsNCiAJYm54Ml9kaXNhYmxlX2ludF9zeW5jKGJwKTsNCkBAIC0yNzUs NyArMjc1LDcgQEANCiAJfQ0KIH0NCiANCi12b2lkDQorc3RhdGljIHZvaWQNCiBibngyX25ldGlm X3N0YXJ0KHN0cnVjdCBibngyICpicCkNCiB7DQogCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCZi cC0+aW50cl9zZW0pKSB7DQpAQCAtMTgwNyw4ICsxODA3LDggQEANCiAJc3RydWN0IGZ3X2luZm8g Znc7DQogDQogCS8qIEluaXRpYWxpemUgdGhlIFJWMlAgcHJvY2Vzc29yLiAqLw0KLQlsb2FkX3J2 MnBfZncoYnAsIHJ2MnBfcHJvYzEsIHNpemVvZihydjJwX3Byb2MxKSwgUlYyUF9QUk9DMSk7DQot CWxvYWRfcnYycF9mdyhicCwgcnYycF9wcm9jMiwgc2l6ZW9mKHJ2MnBfcHJvYzIpLCBSVjJQX1BS T0MyKTsNCisJbG9hZF9ydjJwX2Z3KGJwLCBibngyX3J2MnBfcHJvYzEsIHNpemVvZihibngyX3J2 MnBfcHJvYzEpLCBSVjJQX1BST0MxKTsNCisJbG9hZF9ydjJwX2Z3KGJwLCBibngyX3J2MnBfcHJv YzIsIHNpemVvZihibngyX3J2MnBfcHJvYzIpLCBSVjJQX1BST0MyKTsNCiANCiAJLyogSW5pdGlh bGl6ZSB0aGUgUlggUHJvY2Vzc29yLiAqLw0KIAljcHVfcmVnLm1vZGUgPSBCTlgyX1JYUF9DUFVf TU9ERTsNCkBAIC0xODI0LDM1ICsxODI0LDM1IEBADQogCWNwdV9yZWcuc3BhZF9iYXNlID0gQk5Y Ml9SWFBfU0NSQVRDSDsNCiAJY3B1X3JlZy5taXBzX3ZpZXdfYmFzZSA9IDB4ODAwMDAwMDsNCiAg ICAgDQotCWZ3LnZlcl9tYWpvciA9IFJYUF9iMDZGd1JlbGVhc2VNYWpvcjsNCi0JZncudmVyX21p bm9yID0gUlhQX2IwNkZ3UmVsZWFzZU1pbm9yOw0KLQlmdy52ZXJfZml4ID0gUlhQX2IwNkZ3UmVs ZWFzZUZpeDsNCi0JZncuc3RhcnRfYWRkciA9IFJYUF9iMDZGd1N0YXJ0QWRkcjsNCisJZncudmVy X21ham9yID0gYm54Ml9SWFBfYjA2RndSZWxlYXNlTWFqb3I7DQorCWZ3LnZlcl9taW5vciA9IGJu eDJfUlhQX2IwNkZ3UmVsZWFzZU1pbm9yOw0KKwlmdy52ZXJfZml4ID0gYm54Ml9SWFBfYjA2RndS ZWxlYXNlRml4Ow0KKwlmdy5zdGFydF9hZGRyID0gYm54Ml9SWFBfYjA2RndTdGFydEFkZHI7DQog DQotCWZ3LnRleHRfYWRkciA9IFJYUF9iMDZGd1RleHRBZGRyOw0KLQlmdy50ZXh0X2xlbiA9IFJY UF9iMDZGd1RleHRMZW47DQorCWZ3LnRleHRfYWRkciA9IGJueDJfUlhQX2IwNkZ3VGV4dEFkZHI7 DQorCWZ3LnRleHRfbGVuID0gYm54Ml9SWFBfYjA2RndUZXh0TGVuOw0KIAlmdy50ZXh0X2luZGV4 ID0gMDsNCi0JZncudGV4dCA9IFJYUF9iMDZGd1RleHQ7DQorCWZ3LnRleHQgPSBibngyX1JYUF9i MDZGd1RleHQ7DQogDQotCWZ3LmRhdGFfYWRkciA9IFJYUF9iMDZGd0RhdGFBZGRyOw0KLQlmdy5k YXRhX2xlbiA9IFJYUF9iMDZGd0RhdGFMZW47DQorCWZ3LmRhdGFfYWRkciA9IGJueDJfUlhQX2Iw NkZ3RGF0YUFkZHI7DQorCWZ3LmRhdGFfbGVuID0gYm54Ml9SWFBfYjA2RndEYXRhTGVuOw0KIAlm dy5kYXRhX2luZGV4ID0gMDsNCi0JZncuZGF0YSA9IFJYUF9iMDZGd0RhdGE7DQorCWZ3LmRhdGEg PSBibngyX1JYUF9iMDZGd0RhdGE7DQogDQotCWZ3LnNic3NfYWRkciA9IFJYUF9iMDZGd1Nic3NB ZGRyOw0KLQlmdy5zYnNzX2xlbiA9IFJYUF9iMDZGd1Nic3NMZW47DQorCWZ3LnNic3NfYWRkciA9 IGJueDJfUlhQX2IwNkZ3U2Jzc0FkZHI7DQorCWZ3LnNic3NfbGVuID0gYm54Ml9SWFBfYjA2RndT YnNzTGVuOw0KIAlmdy5zYnNzX2luZGV4ID0gMDsNCi0JZncuc2JzcyA9IFJYUF9iMDZGd1Nic3M7 DQorCWZ3LnNic3MgPSBibngyX1JYUF9iMDZGd1Nic3M7DQogDQotCWZ3LmJzc19hZGRyID0gUlhQ X2IwNkZ3QnNzQWRkcjsNCi0JZncuYnNzX2xlbiA9IFJYUF9iMDZGd0Jzc0xlbjsNCisJZncuYnNz X2FkZHIgPSBibngyX1JYUF9iMDZGd0Jzc0FkZHI7DQorCWZ3LmJzc19sZW4gPSBibngyX1JYUF9i MDZGd0Jzc0xlbjsNCiAJZncuYnNzX2luZGV4ID0gMDsNCi0JZncuYnNzID0gUlhQX2IwNkZ3QnNz Ow0KKwlmdy5ic3MgPSBibngyX1JYUF9iMDZGd0JzczsNCiANCi0JZncucm9kYXRhX2FkZHIgPSBS WFBfYjA2RndSb2RhdGFBZGRyOw0KLQlmdy5yb2RhdGFfbGVuID0gUlhQX2IwNkZ3Um9kYXRhTGVu Ow0KKwlmdy5yb2RhdGFfYWRkciA9IGJueDJfUlhQX2IwNkZ3Um9kYXRhQWRkcjsNCisJZncucm9k YXRhX2xlbiA9IGJueDJfUlhQX2IwNkZ3Um9kYXRhTGVuOw0KIAlmdy5yb2RhdGFfaW5kZXggPSAw Ow0KLQlmdy5yb2RhdGEgPSBSWFBfYjA2RndSb2RhdGE7DQorCWZ3LnJvZGF0YSA9IGJueDJfUlhQ X2IwNkZ3Um9kYXRhOw0KIA0KIAlsb2FkX2NwdV9mdyhicCwgJmNwdV9yZWcsICZmdyk7DQogDQpA QCAtMTg3MCwzNSArMTg3MCwzNSBAQA0KIAljcHVfcmVnLnNwYWRfYmFzZSA9IEJOWDJfVFhQX1ND UkFUQ0g7DQogCWNwdV9yZWcubWlwc192aWV3X2Jhc2UgPSAweDgwMDAwMDA7DQogICAgIA0KLQlm dy52ZXJfbWFqb3IgPSBUWFBfYjA2RndSZWxlYXNlTWFqb3I7DQotCWZ3LnZlcl9taW5vciA9IFRY UF9iMDZGd1JlbGVhc2VNaW5vcjsNCi0JZncudmVyX2ZpeCA9IFRYUF9iMDZGd1JlbGVhc2VGaXg7 DQotCWZ3LnN0YXJ0X2FkZHIgPSBUWFBfYjA2RndTdGFydEFkZHI7DQorCWZ3LnZlcl9tYWpvciA9 IGJueDJfVFhQX2IwNkZ3UmVsZWFzZU1ham9yOw0KKwlmdy52ZXJfbWlub3IgPSBibngyX1RYUF9i MDZGd1JlbGVhc2VNaW5vcjsNCisJZncudmVyX2ZpeCA9IGJueDJfVFhQX2IwNkZ3UmVsZWFzZUZp eDsNCisJZncuc3RhcnRfYWRkciA9IGJueDJfVFhQX2IwNkZ3U3RhcnRBZGRyOw0KIA0KLQlmdy50 ZXh0X2FkZHIgPSBUWFBfYjA2RndUZXh0QWRkcjsNCi0JZncudGV4dF9sZW4gPSBUWFBfYjA2RndU ZXh0TGVuOw0KKwlmdy50ZXh0X2FkZHIgPSBibngyX1RYUF9iMDZGd1RleHRBZGRyOw0KKwlmdy50 ZXh0X2xlbiA9IGJueDJfVFhQX2IwNkZ3VGV4dExlbjsNCiAJZncudGV4dF9pbmRleCA9IDA7DQot CWZ3LnRleHQgPSBUWFBfYjA2RndUZXh0Ow0KKwlmdy50ZXh0ID0gYm54Ml9UWFBfYjA2RndUZXh0 Ow0KIA0KLQlmdy5kYXRhX2FkZHIgPSBUWFBfYjA2RndEYXRhQWRkcjsNCi0JZncuZGF0YV9sZW4g PSBUWFBfYjA2RndEYXRhTGVuOw0KKwlmdy5kYXRhX2FkZHIgPSBibngyX1RYUF9iMDZGd0RhdGFB ZGRyOw0KKwlmdy5kYXRhX2xlbiA9IGJueDJfVFhQX2IwNkZ3RGF0YUxlbjsNCiAJZncuZGF0YV9p bmRleCA9IDA7DQotCWZ3LmRhdGEgPSBUWFBfYjA2RndEYXRhOw0KKwlmdy5kYXRhID0gYm54Ml9U WFBfYjA2RndEYXRhOw0KIA0KLQlmdy5zYnNzX2FkZHIgPSBUWFBfYjA2RndTYnNzQWRkcjsNCi0J Zncuc2Jzc19sZW4gPSBUWFBfYjA2RndTYnNzTGVuOw0KKwlmdy5zYnNzX2FkZHIgPSBibngyX1RY UF9iMDZGd1Nic3NBZGRyOw0KKwlmdy5zYnNzX2xlbiA9IGJueDJfVFhQX2IwNkZ3U2Jzc0xlbjsN CiAJZncuc2Jzc19pbmRleCA9IDA7DQotCWZ3LnNic3MgPSBUWFBfYjA2RndTYnNzOw0KKwlmdy5z YnNzID0gYm54Ml9UWFBfYjA2RndTYnNzOw0KIA0KLQlmdy5ic3NfYWRkciA9IFRYUF9iMDZGd0Jz c0FkZHI7DQotCWZ3LmJzc19sZW4gPSBUWFBfYjA2RndCc3NMZW47DQorCWZ3LmJzc19hZGRyID0g Ym54Ml9UWFBfYjA2RndCc3NBZGRyOw0KKwlmdy5ic3NfbGVuID0gYm54Ml9UWFBfYjA2RndCc3NM ZW47DQogCWZ3LmJzc19pbmRleCA9IDA7DQotCWZ3LmJzcyA9IFRYUF9iMDZGd0JzczsNCisJZncu YnNzID0gYm54Ml9UWFBfYjA2RndCc3M7DQogDQotCWZ3LnJvZGF0YV9hZGRyID0gVFhQX2IwNkZ3 Um9kYXRhQWRkcjsNCi0JZncucm9kYXRhX2xlbiA9IFRYUF9iMDZGd1JvZGF0YUxlbjsNCisJZncu cm9kYXRhX2FkZHIgPSBibngyX1RYUF9iMDZGd1JvZGF0YUFkZHI7DQorCWZ3LnJvZGF0YV9sZW4g PSBibngyX1RYUF9iMDZGd1JvZGF0YUxlbjsNCiAJZncucm9kYXRhX2luZGV4ID0gMDsNCi0JZncu cm9kYXRhID0gVFhQX2IwNkZ3Um9kYXRhOw0KKwlmdy5yb2RhdGEgPSBibngyX1RYUF9iMDZGd1Jv ZGF0YTsNCiANCiAJbG9hZF9jcHVfZncoYnAsICZjcHVfcmVnLCAmZncpOw0KIA0KQEAgLTE5MTYs MzUgKzE5MTYsMzUgQEANCiAJY3B1X3JlZy5zcGFkX2Jhc2UgPSBCTlgyX1RQQVRfU0NSQVRDSDsN CiAJY3B1X3JlZy5taXBzX3ZpZXdfYmFzZSA9IDB4ODAwMDAwMDsNCiAgICAgDQotCWZ3LnZlcl9t YWpvciA9IFRQQVRfYjA2RndSZWxlYXNlTWFqb3I7DQotCWZ3LnZlcl9taW5vciA9IFRQQVRfYjA2 RndSZWxlYXNlTWlub3I7DQotCWZ3LnZlcl9maXggPSBUUEFUX2IwNkZ3UmVsZWFzZUZpeDsNCi0J Zncuc3RhcnRfYWRkciA9IFRQQVRfYjA2RndTdGFydEFkZHI7DQorCWZ3LnZlcl9tYWpvciA9IGJu eDJfVFBBVF9iMDZGd1JlbGVhc2VNYWpvcjsNCisJZncudmVyX21pbm9yID0gYm54Ml9UUEFUX2Iw NkZ3UmVsZWFzZU1pbm9yOw0KKwlmdy52ZXJfZml4ID0gYm54Ml9UUEFUX2IwNkZ3UmVsZWFzZUZp eDsNCisJZncuc3RhcnRfYWRkciA9IGJueDJfVFBBVF9iMDZGd1N0YXJ0QWRkcjsNCiANCi0JZncu dGV4dF9hZGRyID0gVFBBVF9iMDZGd1RleHRBZGRyOw0KLQlmdy50ZXh0X2xlbiA9IFRQQVRfYjA2 RndUZXh0TGVuOw0KKwlmdy50ZXh0X2FkZHIgPSBibngyX1RQQVRfYjA2RndUZXh0QWRkcjsNCisJ ZncudGV4dF9sZW4gPSBibngyX1RQQVRfYjA2RndUZXh0TGVuOw0KIAlmdy50ZXh0X2luZGV4ID0g MDsNCi0JZncudGV4dCA9IFRQQVRfYjA2RndUZXh0Ow0KKwlmdy50ZXh0ID0gYm54Ml9UUEFUX2Iw NkZ3VGV4dDsNCiANCi0JZncuZGF0YV9hZGRyID0gVFBBVF9iMDZGd0RhdGFBZGRyOw0KLQlmdy5k YXRhX2xlbiA9IFRQQVRfYjA2RndEYXRhTGVuOw0KKwlmdy5kYXRhX2FkZHIgPSBibngyX1RQQVRf YjA2RndEYXRhQWRkcjsNCisJZncuZGF0YV9sZW4gPSBibngyX1RQQVRfYjA2RndEYXRhTGVuOw0K IAlmdy5kYXRhX2luZGV4ID0gMDsNCi0JZncuZGF0YSA9IFRQQVRfYjA2RndEYXRhOw0KKwlmdy5k YXRhID0gYm54Ml9UUEFUX2IwNkZ3RGF0YTsNCiANCi0JZncuc2Jzc19hZGRyID0gVFBBVF9iMDZG d1Nic3NBZGRyOw0KLQlmdy5zYnNzX2xlbiA9IFRQQVRfYjA2RndTYnNzTGVuOw0KKwlmdy5zYnNz X2FkZHIgPSBibngyX1RQQVRfYjA2RndTYnNzQWRkcjsNCisJZncuc2Jzc19sZW4gPSBibngyX1RQ QVRfYjA2RndTYnNzTGVuOw0KIAlmdy5zYnNzX2luZGV4ID0gMDsNCi0JZncuc2JzcyA9IFRQQVRf YjA2RndTYnNzOw0KKwlmdy5zYnNzID0gYm54Ml9UUEFUX2IwNkZ3U2JzczsNCiANCi0JZncuYnNz X2FkZHIgPSBUUEFUX2IwNkZ3QnNzQWRkcjsNCi0JZncuYnNzX2xlbiA9IFRQQVRfYjA2RndCc3NM ZW47DQorCWZ3LmJzc19hZGRyID0gYm54Ml9UUEFUX2IwNkZ3QnNzQWRkcjsNCisJZncuYnNzX2xl biA9IGJueDJfVFBBVF9iMDZGd0Jzc0xlbjsNCiAJZncuYnNzX2luZGV4ID0gMDsNCi0JZncuYnNz ID0gVFBBVF9iMDZGd0JzczsNCisJZncuYnNzID0gYm54Ml9UUEFUX2IwNkZ3QnNzOw0KIA0KLQlm dy5yb2RhdGFfYWRkciA9IFRQQVRfYjA2RndSb2RhdGFBZGRyOw0KLQlmdy5yb2RhdGFfbGVuID0g VFBBVF9iMDZGd1JvZGF0YUxlbjsNCisJZncucm9kYXRhX2FkZHIgPSBibngyX1RQQVRfYjA2RndS b2RhdGFBZGRyOw0KKwlmdy5yb2RhdGFfbGVuID0gYm54Ml9UUEFUX2IwNkZ3Um9kYXRhTGVuOw0K IAlmdy5yb2RhdGFfaW5kZXggPSAwOw0KLQlmdy5yb2RhdGEgPSBUUEFUX2IwNkZ3Um9kYXRhOw0K Kwlmdy5yb2RhdGEgPSBibngyX1RQQVRfYjA2RndSb2RhdGE7DQogDQogCWxvYWRfY3B1X2Z3KGJw LCAmY3B1X3JlZywgJmZ3KTsNCiANCkBAIC0xOTYyLDM1ICsxOTYyLDM1IEBADQogCWNwdV9yZWcu c3BhZF9iYXNlID0gQk5YMl9DT01fU0NSQVRDSDsNCiAJY3B1X3JlZy5taXBzX3ZpZXdfYmFzZSA9 IDB4ODAwMDAwMDsNCiAgICAgDQotCWZ3LnZlcl9tYWpvciA9IENPTV9iMDZGd1JlbGVhc2VNYWpv cjsNCi0JZncudmVyX21pbm9yID0gQ09NX2IwNkZ3UmVsZWFzZU1pbm9yOw0KLQlmdy52ZXJfZml4 ID0gQ09NX2IwNkZ3UmVsZWFzZUZpeDsNCi0JZncuc3RhcnRfYWRkciA9IENPTV9iMDZGd1N0YXJ0 QWRkcjsNCisJZncudmVyX21ham9yID0gYm54Ml9DT01fYjA2RndSZWxlYXNlTWFqb3I7DQorCWZ3 LnZlcl9taW5vciA9IGJueDJfQ09NX2IwNkZ3UmVsZWFzZU1pbm9yOw0KKwlmdy52ZXJfZml4ID0g Ym54Ml9DT01fYjA2RndSZWxlYXNlRml4Ow0KKwlmdy5zdGFydF9hZGRyID0gYm54Ml9DT01fYjA2 RndTdGFydEFkZHI7DQogDQotCWZ3LnRleHRfYWRkciA9IENPTV9iMDZGd1RleHRBZGRyOw0KLQlm dy50ZXh0X2xlbiA9IENPTV9iMDZGd1RleHRMZW47DQorCWZ3LnRleHRfYWRkciA9IGJueDJfQ09N X2IwNkZ3VGV4dEFkZHI7DQorCWZ3LnRleHRfbGVuID0gYm54Ml9DT01fYjA2RndUZXh0TGVuOw0K IAlmdy50ZXh0X2luZGV4ID0gMDsNCi0JZncudGV4dCA9IENPTV9iMDZGd1RleHQ7DQorCWZ3LnRl eHQgPSBibngyX0NPTV9iMDZGd1RleHQ7DQogDQotCWZ3LmRhdGFfYWRkciA9IENPTV9iMDZGd0Rh dGFBZGRyOw0KLQlmdy5kYXRhX2xlbiA9IENPTV9iMDZGd0RhdGFMZW47DQorCWZ3LmRhdGFfYWRk ciA9IGJueDJfQ09NX2IwNkZ3RGF0YUFkZHI7DQorCWZ3LmRhdGFfbGVuID0gYm54Ml9DT01fYjA2 RndEYXRhTGVuOw0KIAlmdy5kYXRhX2luZGV4ID0gMDsNCi0JZncuZGF0YSA9IENPTV9iMDZGd0Rh dGE7DQorCWZ3LmRhdGEgPSBibngyX0NPTV9iMDZGd0RhdGE7DQogDQotCWZ3LnNic3NfYWRkciA9 IENPTV9iMDZGd1Nic3NBZGRyOw0KLQlmdy5zYnNzX2xlbiA9IENPTV9iMDZGd1Nic3NMZW47DQor CWZ3LnNic3NfYWRkciA9IGJueDJfQ09NX2IwNkZ3U2Jzc0FkZHI7DQorCWZ3LnNic3NfbGVuID0g Ym54Ml9DT01fYjA2RndTYnNzTGVuOw0KIAlmdy5zYnNzX2luZGV4ID0gMDsNCi0JZncuc2JzcyA9 IENPTV9iMDZGd1Nic3M7DQorCWZ3LnNic3MgPSBibngyX0NPTV9iMDZGd1Nic3M7DQogDQotCWZ3 LmJzc19hZGRyID0gQ09NX2IwNkZ3QnNzQWRkcjsNCi0JZncuYnNzX2xlbiA9IENPTV9iMDZGd0Jz c0xlbjsNCisJZncuYnNzX2FkZHIgPSBibngyX0NPTV9iMDZGd0Jzc0FkZHI7DQorCWZ3LmJzc19s ZW4gPSBibngyX0NPTV9iMDZGd0Jzc0xlbjsNCiAJZncuYnNzX2luZGV4ID0gMDsNCi0JZncuYnNz ID0gQ09NX2IwNkZ3QnNzOw0KKwlmdy5ic3MgPSBibngyX0NPTV9iMDZGd0JzczsNCiANCi0JZncu cm9kYXRhX2FkZHIgPSBDT01fYjA2RndSb2RhdGFBZGRyOw0KLQlmdy5yb2RhdGFfbGVuID0gQ09N X2IwNkZ3Um9kYXRhTGVuOw0KKwlmdy5yb2RhdGFfYWRkciA9IGJueDJfQ09NX2IwNkZ3Um9kYXRh QWRkcjsNCisJZncucm9kYXRhX2xlbiA9IGJueDJfQ09NX2IwNkZ3Um9kYXRhTGVuOw0KIAlmdy5y b2RhdGFfaW5kZXggPSAwOw0KLQlmdy5yb2RhdGEgPSBDT01fYjA2RndSb2RhdGE7DQorCWZ3LnJv ZGF0YSA9IGJueDJfQ09NX2IwNkZ3Um9kYXRhOw0KIA0KIAlsb2FkX2NwdV9mdyhicCwgJmNwdV9y ZWcsICZmdyk7DQogDQpAQCAtNDY5NSwxMSArNDY5NSwxMSBAQA0KIAlyZXR1cm4gMDsNCiB9DQog DQotI2RlZmluZSBFVEhfTlVNX1NUQVRTIDQ1DQorI2RlZmluZSBCTlgyX05VTV9TVEFUUyA0NQ0K IA0KIHN0cnVjdCB7DQogCWNoYXIgc3RyaW5nW0VUSF9HU1RSSU5HX0xFTl07DQotfSBibngyX3N0 YXRzX3N0cl9hcnJbRVRIX05VTV9TVEFUU10gPSB7DQorfSBibngyX3N0YXRzX3N0cl9hcnJbQk5Y Ml9OVU1fU1RBVFNdID0gew0KIAl7ICJyeF9ieXRlcyIgfSwNCiAJeyAicnhfZXJyb3JfYnl0ZXMi IH0sDQogCXsgInR4X2J5dGVzIiB9LA0KQEAgLTQ3NDksNyArNDc0OSw3IEBADQogDQogI2RlZmlu ZSBTVEFUU19PRkZTRVQzMihvZmZzZXRfbmFtZSkgKG9mZnNldG9mKHN0cnVjdCBzdGF0aXN0aWNz X2Jsb2NrLCBvZmZzZXRfbmFtZSkgLyA0KQ0KIA0KLXVuc2lnbmVkIGxvbmcgYm54Ml9zdGF0c19v ZmZzZXRfYXJyW0VUSF9OVU1fU1RBVFNdID0gew0KK3Vuc2lnbmVkIGxvbmcgYm54Ml9zdGF0c19v ZmZzZXRfYXJyW0JOWDJfTlVNX1NUQVRTXSA9IHsNCiAgICAgU1RBVFNfT0ZGU0VUMzIoc3RhdF9J ZkhDSW5PY3RldHNfaGkpLA0KICAgICBTVEFUU19PRkZTRVQzMihzdGF0X0lmSENJbkJhZE9jdGV0 c19oaSksDQogICAgIFNUQVRTX09GRlNFVDMyKHN0YXRfSWZIQ091dE9jdGV0c19oaSksDQpAQCAt NDgwMCw3ICs0ODAwLDcgQEANCiAvKiBzdGF0X0lmSENJbkJhZE9jdGV0cyBhbmQgc3RhdF9Eb3Qz U3RhdHNDYXJyaWVyU2Vuc2VFcnJvcnMgYXJlDQogICogc2tpcHBlZCBiZWNhdXNlIG9mIGVycmF0 YS4NCiAgKi8gICAgICAgICAgICAgICANCi11OCBibngyXzU3MDZfc3RhdHNfbGVuX2FycltFVEhf TlVNX1NUQVRTXSA9IHsNCit1OCBibngyXzU3MDZfc3RhdHNfbGVuX2FycltCTlgyX05VTV9TVEFU U10gPSB7DQogCTgsMCw4LDgsOCw4LDgsOCw4LDgsDQogCTQsMCw0LDQsNCw0LDQsNCw0LDQsDQog CTQsNCw0LDQsNCw0LDQsNCw0LDQsDQpAQCAtNDgwOCwxMSArNDgwOCwxMSBAQA0KIAk0LDQsNCw0 LDQsDQogfTsNCiANCi0jZGVmaW5lIEVUSF9OVU1fVEVTVFMgNg0KKyNkZWZpbmUgQk5YMl9OVU1f VEVTVFMgNg0KIA0KIHN0cnVjdCB7DQogCWNoYXIgc3RyaW5nW0VUSF9HU1RSSU5HX0xFTl07DQot fSBibngyX3Rlc3RzX3N0cl9hcnJbRVRIX05VTV9URVNUU10gPSB7DQorfSBibngyX3Rlc3RzX3N0 cl9hcnJbQk5YMl9OVU1fVEVTVFNdID0gew0KIAl7ICJyZWdpc3Rlcl90ZXN0IChvZmZsaW5lKSIg fSwNCiAJeyAibWVtb3J5X3Rlc3QgKG9mZmxpbmUpIiB9LA0KIAl7ICJsb29wYmFja190ZXN0IChv ZmZsaW5lKSIgfSwNCkBAIC00ODI0LDcgKzQ4MjQsNyBAQA0KIHN0YXRpYyBpbnQNCiBibngyX3Nl bGZfdGVzdF9jb3VudChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KIHsNCi0JcmV0dXJuIEVUSF9O VU1fVEVTVFM7DQorCXJldHVybiBCTlgyX05VTV9URVNUUzsNCiB9DQogDQogc3RhdGljIHZvaWQN CkBAIC00ODMyLDcgKzQ4MzIsNyBAQA0KIHsNCiAJc3RydWN0IGJueDIgKmJwID0gZGV2LT5wcml2 Ow0KIA0KLQltZW1zZXQoYnVmLCAwLCBzaXplb2YodTY0KSAqIEVUSF9OVU1fVEVTVFMpOw0KKwlt ZW1zZXQoYnVmLCAwLCBzaXplb2YodTY0KSAqIEJOWDJfTlVNX1RFU1RTKTsNCiAJaWYgKGV0ZXN0 LT5mbGFncyAmIEVUSF9URVNUX0ZMX09GRkxJTkUpIHsNCiAJCWJueDJfbmV0aWZfc3RvcChicCk7 DQogCQlibngyX3Jlc2V0X2NoaXAoYnAsIEJOWDJfRFJWX01TR19DT0RFX0RJQUcpOw0KQEAgLTQ4 OTksNyArNDg5OSw3IEBADQogc3RhdGljIGludA0KIGJueDJfZ2V0X3N0YXRzX2NvdW50KHN0cnVj dCBuZXRfZGV2aWNlICpkZXYpDQogew0KLQlyZXR1cm4gRVRIX05VTV9TVEFUUzsNCisJcmV0dXJu IEJOWDJfTlVNX1NUQVRTOw0KIH0NCiANCiBzdGF0aWMgdm9pZA0KQEAgLTQ5MTIsMTQgKzQ5MTIs MTQgQEANCiAJdTggKnN0YXRzX2xlbl9hcnIgPSAwOw0KIA0KIAlpZiAoaHdfc3RhdHMgPT0gTlVM TCkgew0KLQkJbWVtc2V0KGJ1ZiwgMCwgc2l6ZW9mKHU2NCkgKiBFVEhfTlVNX1NUQVRTKTsNCisJ CW1lbXNldChidWYsIDAsIHNpemVvZih1NjQpICogQk5YMl9OVU1fU1RBVFMpOw0KIAkJcmV0dXJu Ow0KIAl9DQogDQogCWlmIChDSElQX05VTShicCkgPT0gQ0hJUF9OVU1fNTcwNikNCiAJCXN0YXRz X2xlbl9hcnIgPSBibngyXzU3MDZfc3RhdHNfbGVuX2FycjsNCiANCi0JZm9yIChpID0gMDsgaSA8 IEVUSF9OVU1fU1RBVFM7IGkrKykgew0KKwlmb3IgKGkgPSAwOyBpIDwgQk5YMl9OVU1fU1RBVFM7 IGkrKykgew0KIAkJaWYgKHN0YXRzX2xlbl9hcnJbaV0gPT0gMCkgew0KIAkJCS8qIHNraXAgdGhp cyBjb3VudGVyICovDQogCQkJYnVmW2ldID0gMDsNCmRpZmYgLU5ydSAxNC9kcml2ZXJzL25ldC9i bngyX2Z3LmggMTUvZHJpdmVycy9uZXQvYm54Ml9mdy5oDQotLS0gMTQvZHJpdmVycy9uZXQvYm54 Ml9mdy5oCTIwMDUtMDUtMjMgMTM6MzM6MjguMDAwMDAwMDAwIC0wNzAwDQorKysgMTUvZHJpdmVy cy9uZXQvYm54Ml9mdy5oCTIwMDUtMDUtMjMgMTM6MzE6MTAuMDAwMDAwMDAwIC0wNzAwDQpAQCAt MTUsMjEgKzE1LDIxIEBADQogICovDQogDQogDQotaW50IENPTV9iMDZGd1JlbGVhc2VNYWpvciA9 IDB4MDsNCi1pbnQgQ09NX2IwNkZ3UmVsZWFzZU1pbm9yID0gMHgwOw0KLWludCBDT01fYjA2RndS ZWxlYXNlRml4ID0gMHgwOw0KLXUzMiBDT01fYjA2RndTdGFydEFkZHIgPSAweDA4MDAwNGEwOw0K LXUzMiBDT01fYjA2RndUZXh0QWRkciA9IDB4MDgwMDAwMDA7DQotaW50IENPTV9iMDZGd1RleHRM ZW4gPSAweDQ1OTQ7DQotdTMyIENPTV9iMDZGd0RhdGFBZGRyID0gMHgwODAwNDVlMDsNCi1pbnQg Q09NX2IwNkZ3RGF0YUxlbiA9IDB4MDsNCi11MzIgQ09NX2IwNkZ3Um9kYXRhQWRkciA9IDB4MDgw MDQ1OTg7DQotaW50IENPTV9iMDZGd1JvZGF0YUxlbiA9IDB4MTg7DQotdTMyIENPTV9iMDZGd0Jz c0FkZHIgPSAweDA4MDA0NjAwOw0KLWludCBDT01fYjA2RndCc3NMZW4gPSAweDg4Ow0KLXUzMiBD T01fYjA2RndTYnNzQWRkciA9IDB4MDgwMDQ1ZTA7DQotaW50IENPTV9iMDZGd1Nic3NMZW4gPSAw eDFjOw0KLXUzMiBDT01fYjA2RndUZXh0WygweDQ1OTQvNCkgKyAxXSA9IHsNCitzdGF0aWMgaW50 IGJueDJfQ09NX2IwNkZ3UmVsZWFzZU1ham9yID0gMHgwOw0KK3N0YXRpYyBpbnQgYm54Ml9DT01f YjA2RndSZWxlYXNlTWlub3IgPSAweDA7DQorc3RhdGljIGludCBibngyX0NPTV9iMDZGd1JlbGVh c2VGaXggPSAweDA7DQorc3RhdGljIHUzMiBibngyX0NPTV9iMDZGd1N0YXJ0QWRkciA9IDB4MDgw MDA0YTA7DQorc3RhdGljIHUzMiBibngyX0NPTV9iMDZGd1RleHRBZGRyID0gMHgwODAwMDAwMDsN CitzdGF0aWMgaW50IGJueDJfQ09NX2IwNkZ3VGV4dExlbiA9IDB4NDU5NDsNCitzdGF0aWMgdTMy IGJueDJfQ09NX2IwNkZ3RGF0YUFkZHIgPSAweDA4MDA0NWUwOw0KK3N0YXRpYyBpbnQgYm54Ml9D T01fYjA2RndEYXRhTGVuID0gMHgwOw0KK3N0YXRpYyB1MzIgYm54Ml9DT01fYjA2RndSb2RhdGFB ZGRyID0gMHgwODAwNDU5ODsNCitzdGF0aWMgaW50IGJueDJfQ09NX2IwNkZ3Um9kYXRhTGVuID0g MHgxODsNCitzdGF0aWMgdTMyIGJueDJfQ09NX2IwNkZ3QnNzQWRkciA9IDB4MDgwMDQ2MDA7DQor c3RhdGljIGludCBibngyX0NPTV9iMDZGd0Jzc0xlbiA9IDB4ODg7DQorc3RhdGljIHUzMiBibngy X0NPTV9iMDZGd1Nic3NBZGRyID0gMHgwODAwNDVlMDsNCitzdGF0aWMgaW50IGJueDJfQ09NX2Iw NkZ3U2Jzc0xlbiA9IDB4MWM7DQorc3RhdGljIHUzMiBibngyX0NPTV9iMDZGd1RleHRbKDB4NDU5 NC80KSArIDFdID0gew0KIAkweDBhMDAwMTI4LCAweDAwMDAwMDAwLCAweDAwMDAwMDAwLCAweDAw MDAwMDBkLCAweDYzNmY2ZDIwLCAweDMwMmUzNjJlLA0KIAkweDM5MDAwMDAwLCAweDAwMDYwOTAy LCAweDAwMDAwMDAwLCAweDAwMDAwMDAzLCAweDAwMDAwMDE0LCAweDAwMDAwMDMyLA0KIAkweDAw MDAwMDAzLCAweDAwMDAwMDAwLCAweDAwMDAwMDAwLCAweDAwMDAwMDAwLCAweDAwMDAwMDAwLCAw eDAwMDAwMDAwLA0KQEAgLTc3NCwzMCArNzc0LDMwIEBADQogCTB4OGY0MjAwMDAsIDB4MzA0MjAw MjAsIDB4MTA0MGZmZmQsIDB4M2MwMjAwMjAsIDB4YWY0MjAwMzAsIDB4MDNlMDAwMDgsDQogCTB4 MDAwMDAwMDAsIDB4MDAwMDAwMDAgfTsNCiANCi11MzIgQ09NX2IwNkZ3RGF0YVsoMHgwLzQpICsg MV0gPSB7IDB4MDAwMDAwMDAgfTsNCi11MzIgQ09NX2IwNkZ3Um9kYXRhWygweDE4LzQpICsgMV0g PSB7DQorc3RhdGljIHUzMiBibngyX0NPTV9iMDZGd0RhdGFbKDB4MC80KSArIDFdID0geyAweDAw MDAwMDAwIH07DQorc3RhdGljIHUzMiBibngyX0NPTV9iMDZGd1JvZGF0YVsoMHgxOC80KSArIDFd ID0gew0KIAkweDA4MDAyMzE4LCAweDA4MDAyMzQ4LCAweDA4MDAyMzc4LCAweDA4MDAyM2E4LCAw eDA4MDAyM2Q4LCAweDAwMDAwMDAwLA0KIAkweDAwMDAwMDAwIH07DQogDQotdTMyIENPTV9iMDZG d0Jzc1soMHg4OC80KSArIDFdID0geyAweDAwMDAwMDAwIH07DQotdTMyIENPTV9iMDZGd1Nic3Nb KDB4MWMvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KK3N0YXRpYyB1MzIgYm54Ml9DT01fYjA2 RndCc3NbKDB4ODgvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KK3N0YXRpYyB1MzIgYm54Ml9D T01fYjA2RndTYnNzWygweDFjLzQpICsgMV0gPSB7IDB4MDAwMDAwMDAgfTsNCiANCi1pbnQgUlhQ X2IwNkZ3UmVsZWFzZU1ham9yID0gMHgwOw0KLWludCBSWFBfYjA2RndSZWxlYXNlTWlub3IgPSAw eDA7DQotaW50IFJYUF9iMDZGd1JlbGVhc2VGaXggPSAweDA7DQotdTMyIFJYUF9iMDZGd1N0YXJ0 QWRkciA9IDB4MDgwMDAwNjA7DQotdTMyIFJYUF9iMDZGd1RleHRBZGRyID0gMHgwODAwMDAwMDsN Ci1pbnQgUlhQX2IwNkZ3VGV4dExlbiA9IDB4MjBiODsNCi11MzIgUlhQX2IwNkZ3RGF0YUFkZHIg PSAweDA4MDAyMGUwOw0KLWludCBSWFBfYjA2RndEYXRhTGVuID0gMHgwOw0KLXUzMiBSWFBfYjA2 RndSb2RhdGFBZGRyID0gMHgwMDAwMDAwMDsNCi1pbnQgUlhQX2IwNkZ3Um9kYXRhTGVuID0gMHgw Ow0KLXUzMiBSWFBfYjA2RndCc3NBZGRyID0gMHgwODAwMjEwMDsNCi1pbnQgUlhQX2IwNkZ3QnNz TGVuID0gMHgyMzljOw0KLXUzMiBSWFBfYjA2RndTYnNzQWRkciA9IDB4MDgwMDIwZTA7DQotaW50 IFJYUF9iMDZGd1Nic3NMZW4gPSAweDE0Ow0KK3N0YXRpYyBpbnQgYm54Ml9SWFBfYjA2RndSZWxl YXNlTWFqb3IgPSAweDA7DQorc3RhdGljIGludCBibngyX1JYUF9iMDZGd1JlbGVhc2VNaW5vciA9 IDB4MDsNCitzdGF0aWMgaW50IGJueDJfUlhQX2IwNkZ3UmVsZWFzZUZpeCA9IDB4MDsNCitzdGF0 aWMgdTMyIGJueDJfUlhQX2IwNkZ3U3RhcnRBZGRyID0gMHgwODAwMDA2MDsNCitzdGF0aWMgdTMy IGJueDJfUlhQX2IwNkZ3VGV4dEFkZHIgPSAweDA4MDAwMDAwOw0KK3N0YXRpYyBpbnQgYm54Ml9S WFBfYjA2RndUZXh0TGVuID0gMHgyMGI4Ow0KK3N0YXRpYyB1MzIgYm54Ml9SWFBfYjA2RndEYXRh QWRkciA9IDB4MDgwMDIwZTA7DQorc3RhdGljIGludCBibngyX1JYUF9iMDZGd0RhdGFMZW4gPSAw eDA7DQorc3RhdGljIHUzMiBibngyX1JYUF9iMDZGd1JvZGF0YUFkZHIgPSAweDAwMDAwMDAwOw0K K3N0YXRpYyBpbnQgYm54Ml9SWFBfYjA2RndSb2RhdGFMZW4gPSAweDA7DQorc3RhdGljIHUzMiBi bngyX1JYUF9iMDZGd0Jzc0FkZHIgPSAweDA4MDAyMTAwOw0KK3N0YXRpYyBpbnQgYm54Ml9SWFBf YjA2RndCc3NMZW4gPSAweDIzOWM7DQorc3RhdGljIHUzMiBibngyX1JYUF9iMDZGd1Nic3NBZGRy ID0gMHgwODAwMjBlMDsNCitzdGF0aWMgaW50IGJueDJfUlhQX2IwNkZ3U2Jzc0xlbiA9IDB4MTQ7 DQogDQotdTMyIFJYUF9iMDZGd1RleHRbKDB4MjBiOC80KSArIDFdID0gew0KK3N0YXRpYyB1MzIg Ym54Ml9SWFBfYjA2RndUZXh0WygweDIwYjgvNCkgKyAxXSA9IHsNCiAJMHgwYTAwMDAxOCwgMHgw MDAwMDAwMCwgMHgwMDAwMDAwMCwgMHgwMDAwMDAwZCwgMHg3Mjc4NzAyMCwgMHgzMDJlMzYyZSwN CiAJMHgzOTAwMDAwMCwgMHgwMDA2MDkwMywgMHgwMDAwMDAwMCwgMHgwMDAwMDAwZCwgMHgwMDAw MDAwMCwgMHgwMDAwMDAwMCwNCiAJMHgwMDAwMDAwMCwgMHgwMDAwMDAwMCwgMHgwMDAwMDAwMCwg MHgwMDAwMDAwMCwgMHgwMDAwMDAwMCwgMHgwMDAwMDAwMCwNCkBAIC0xMTQ5LDEyICsxMTQ5LDEy IEBADQogCTB4MjQ4NDAwMDQsIDB4MDBhMDEwMjEsIDB4MTQ0MGZmZmMsIDB4MjRhNWZmZmYsIDB4 MDNlMDAwMDgsIDB4MDAwMDAwMDAsDQogCTB4MDAwMDAwMDAgfTsgDQogDQotdTMyIFJYUF9iMDZG d0RhdGFbKDB4MC80KSArIDFdID0geyAweDAwMDAwMDAwIH07DQotdTMyIFJYUF9iMDZGd1JvZGF0 YVsoMHgwLzQpICsgMV0gPSB7IDB4MDAwMDAwMDAgfTsNCi11MzIgUlhQX2IwNkZ3QnNzWygweDIz OWMvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KLXUzMiBSWFBfYjA2RndTYnNzWygweDE0LzQp ICsgMV0gPSB7IDB4MDAwMDAwMDAgfTsNCitzdGF0aWMgdTMyIGJueDJfUlhQX2IwNkZ3RGF0YVso MHgwLzQpICsgMV0gPSB7IDB4MDAwMDAwMDAgfTsNCitzdGF0aWMgdTMyIGJueDJfUlhQX2IwNkZ3 Um9kYXRhWygweDAvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KK3N0YXRpYyB1MzIgYm54Ml9S WFBfYjA2RndCc3NbKDB4MjM5Yy80KSArIDFdID0geyAweDAwMDAwMDAwIH07DQorc3RhdGljIHUz MiBibngyX1JYUF9iMDZGd1Nic3NbKDB4MTQvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KIA0K LXUzMiBydjJwX3Byb2MxW10gPSB7DQorc3RhdGljIHUzMiBibngyX3J2MnBfcHJvYzFbXSA9IHsN CiAJMHgwMDAwMDAwOCwgMHhhYzAwMDAwMSwgMHgwMDAwMDAwYywgMHgyZjgwMDAwMSwgMHgwMDAw MDAxMCwgMHgyMTNmMDAwNCwNCiAJMHgwMDAwMDAxMCwgMHgyMGJmMDAyYywgMHgwMDAwMDAxMCwg MHgyMDNmMDE0MywgMHgwMDAwMDAxOCwgMHg4MDAwZmZmZCwNCiAJMHgwMDAwMDAxMCwgMHhiMWI4 YjAxNywgMHgwMDAwMDAwYiwgMHgyZmRmMDAwMiwgMHgwMDAwMDAwMCwgMHgwM2Q4MDAwMCwNCkBA IC0xMjc5LDcgKzEyNzksNyBAQA0KIAkweDAwMDAwMDAxLCAweDg2MGMwZTAwLCAweDAwMDAwMDA4 LCAweDAyMDQwMDA0LCAweDAwMDAwMDAwLCAweDAyMDQxODAwLA0KIAkweDAwMDAwMDAwLCAweDgz ODcxODAwLCAweDAwMDAwMDE4LCAweDAwMDIwMDAwIH07DQogDQotdTMyIHJ2MnBfcHJvYzJbXSA9 IHsNCitzdGF0aWMgdTMyIGJueDJfcnYycF9wcm9jMltdID0gew0KIAkweDAwMDAwMDAwLCAweDJh MDAwMDAwLCAweDAwMDAwMDEwLCAweGIxZDQwMDAwLCAweDAwMDAwMDA4LCAweDAyNTQwMDAzLA0K IAkweDAwMDAwMDE4LCAweDAwMDQwMDAwLCAweDAwMDAwMDE4LCAweDgwMDAwMDBhLCAweDAwMDAw MDE4LCAweDgwMDAwMDBhLA0KIAkweDAwMDAwMDE4LCAweDgwMDAwMDBlLCAweDAwMDAwMDE4LCAw eDgwMDAwMDU2LCAweDAwMDAwMDE4LCAweDgwMDAwMWI5LA0KQEAgLTE1MzYsMjIgKzE1MzYsMjIg QEANCiAJMHgwMDAwMDAwYywgMHgyOTUyMDAwMCwgMHgwMDAwMDAxOCwgMHg4MDAwMDAwMiwgMHgw MDAwMDAwYywgMHgyOTgwMDAwMCwNCiAJMHgwMDAwMDAxOCwgMHgwMDU3MDAwMCB9Ow0KIA0KLWlu dCBUUEFUX2IwNkZ3UmVsZWFzZU1ham9yID0gMHgwOw0KLWludCBUUEFUX2IwNkZ3UmVsZWFzZU1p bm9yID0gMHgwOw0KLWludCBUUEFUX2IwNkZ3UmVsZWFzZUZpeCA9IDB4MDsNCi11MzIgVFBBVF9i MDZGd1N0YXJ0QWRkciA9IDB4MDgwMDA4NTg7DQotdTMyIFRQQVRfYjA2RndUZXh0QWRkciA9IDB4 MDgwMDA4MDA7DQotaW50IFRQQVRfYjA2RndUZXh0TGVuID0gMHgxMzE0Ow0KLXUzMiBUUEFUX2Iw NkZ3RGF0YUFkZHIgPSAweDA4MDAxYjQwOw0KLWludCBUUEFUX2IwNkZ3RGF0YUxlbiA9IDB4MDsN Ci11MzIgVFBBVF9iMDZGd1JvZGF0YUFkZHIgPSAweDAwMDAwMDAwOw0KLWludCBUUEFUX2IwNkZ3 Um9kYXRhTGVuID0gMHgwOw0KLXUzMiBUUEFUX2IwNkZ3QnNzQWRkciA9IDB4MDgwMDFiOTA7DQot aW50IFRQQVRfYjA2RndCc3NMZW4gPSAweDgwOw0KLXUzMiBUUEFUX2IwNkZ3U2Jzc0FkZHIgPSAw eDA4MDAxYjQwOw0KLWludCBUUEFUX2IwNkZ3U2Jzc0xlbiA9IDB4NDg7DQorc3RhdGljIGludCBi bngyX1RQQVRfYjA2RndSZWxlYXNlTWFqb3IgPSAweDA7DQorc3RhdGljIGludCBibngyX1RQQVRf YjA2RndSZWxlYXNlTWlub3IgPSAweDA7DQorc3RhdGljIGludCBibngyX1RQQVRfYjA2RndSZWxl YXNlRml4ID0gMHgwOw0KK3N0YXRpYyB1MzIgYm54Ml9UUEFUX2IwNkZ3U3RhcnRBZGRyID0gMHgw ODAwMDg1ODsNCitzdGF0aWMgdTMyIGJueDJfVFBBVF9iMDZGd1RleHRBZGRyID0gMHgwODAwMDgw MDsNCitzdGF0aWMgaW50IGJueDJfVFBBVF9iMDZGd1RleHRMZW4gPSAweDEzMTQ7DQorc3RhdGlj IHUzMiBibngyX1RQQVRfYjA2RndEYXRhQWRkciA9IDB4MDgwMDFiNDA7DQorc3RhdGljIGludCBi bngyX1RQQVRfYjA2RndEYXRhTGVuID0gMHgwOw0KK3N0YXRpYyB1MzIgYm54Ml9UUEFUX2IwNkZ3 Um9kYXRhQWRkciA9IDB4MDAwMDAwMDA7DQorc3RhdGljIGludCBibngyX1RQQVRfYjA2RndSb2Rh dGFMZW4gPSAweDA7DQorc3RhdGljIHUzMiBibngyX1RQQVRfYjA2RndCc3NBZGRyID0gMHgwODAw MWI5MDsNCitzdGF0aWMgaW50IGJueDJfVFBBVF9iMDZGd0Jzc0xlbiA9IDB4ODA7DQorc3RhdGlj IHUzMiBibngyX1RQQVRfYjA2RndTYnNzQWRkciA9IDB4MDgwMDFiNDA7DQorc3RhdGljIGludCBi bngyX1RQQVRfYjA2RndTYnNzTGVuID0gMHg0ODsNCiANCi11MzIgVFBBVF9iMDZGd1RleHRbKDB4 MTMxNC80KSArIDFdID0gew0KK3N0YXRpYyB1MzIgYm54Ml9UUEFUX2IwNkZ3VGV4dFsoMHgxMzE0 LzQpICsgMV0gPSB7DQogCTB4MGEwMDAyMTYsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsIDB4MDAw MDAwMGQsIDB4NzQ3MDYxNzQsIDB4MjAzMDJlMzYsDQogCTB4MmUzOTAwMDAsIDB4MDAwNjA5MDEs IDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsDQogCTB4MDAw MDAwMDAsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsIDB4 MDAwMDAwMDAsDQpAQCAtMTc1NywyNiArMTc1NywyNiBAQA0KIAkweDNjMDU2MDAwLCAweDI0MDMw MDE5LCAweGFjYTIyM2Y4LCAweGE3NDMwMTRhLCAweDhjYTQ0NDQ4LCAweDNjMDIwODAwLA0KIAkw eGFjNDQwODU0LCAweDAzZTAwMDA4LCAweDAwMDAwMDAwLCAweDAwMDAwMDAwIH07DQogDQotdTMy IFRQQVRfYjA2RndEYXRhWygweDAvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KLXUzMiBUUEFU X2IwNkZ3Um9kYXRhWygweDAvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KLXUzMiBUUEFUX2Iw NkZ3QnNzWygweDgwLzQpICsgMV0gPSB7IDB4MDAwMDAwMDAgfTsNCi11MzIgVFBBVF9iMDZGd1Ni c3NbKDB4NDgvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KK3N0YXRpYyB1MzIgYm54Ml9UUEFU X2IwNkZ3RGF0YVsoMHgwLzQpICsgMV0gPSB7IDB4MDAwMDAwMDAgfTsNCitzdGF0aWMgdTMyIGJu eDJfVFBBVF9iMDZGd1JvZGF0YVsoMHgwLzQpICsgMV0gPSB7IDB4MDAwMDAwMDAgfTsNCitzdGF0 aWMgdTMyIGJueDJfVFBBVF9iMDZGd0Jzc1soMHg4MC80KSArIDFdID0geyAweDAwMDAwMDAwIH07 DQorc3RhdGljIHUzMiBibngyX1RQQVRfYjA2RndTYnNzWygweDQ4LzQpICsgMV0gPSB7IDB4MDAw MDAwMDAgfTsNCiANCi1pbnQgVFhQX2IwNkZ3UmVsZWFzZU1ham9yID0gMHgwOw0KLWludCBUWFBf YjA2RndSZWxlYXNlTWlub3IgPSAweDA7DQotaW50IFRYUF9iMDZGd1JlbGVhc2VGaXggPSAweDA7 DQotdTMyIFRYUF9iMDZGd1N0YXJ0QWRkciA9IDB4MDgwMDIwOTA7DQotdTMyIFRYUF9iMDZGd1Rl eHRBZGRyID0gMHgwODAwMDAwMDsNCi1pbnQgVFhQX2IwNkZ3VGV4dExlbiA9IDB4M2ZmYzsNCi11 MzIgVFhQX2IwNkZ3RGF0YUFkZHIgPSAweDA4MDA0MDIwOw0KLWludCBUWFBfYjA2RndEYXRhTGVu ID0gMHgwOw0KLXUzMiBUWFBfYjA2RndSb2RhdGFBZGRyID0gMHgwMDAwMDAwMDsNCi1pbnQgVFhQ X2IwNkZ3Um9kYXRhTGVuID0gMHgwOw0KLXUzMiBUWFBfYjA2RndCc3NBZGRyID0gMHgwODAwNDA2 MDsNCi1pbnQgVFhQX2IwNkZ3QnNzTGVuID0gMHgxOTQ7DQotdTMyIFRYUF9iMDZGd1Nic3NBZGRy ID0gMHgwODAwNDAyMDsNCi1pbnQgVFhQX2IwNkZ3U2Jzc0xlbiA9IDB4MzQ7DQotdTMyIFRYUF9i MDZGd1RleHRbKDB4M2ZmYy80KSArIDFdID0gew0KK3N0YXRpYyBpbnQgYm54Ml9UWFBfYjA2RndS ZWxlYXNlTWFqb3IgPSAweDA7DQorc3RhdGljIGludCBibngyX1RYUF9iMDZGd1JlbGVhc2VNaW5v ciA9IDB4MDsNCitzdGF0aWMgaW50IGJueDJfVFhQX2IwNkZ3UmVsZWFzZUZpeCA9IDB4MDsNCitz dGF0aWMgdTMyIGJueDJfVFhQX2IwNkZ3U3RhcnRBZGRyID0gMHgwODAwMjA5MDsNCitzdGF0aWMg dTMyIGJueDJfVFhQX2IwNkZ3VGV4dEFkZHIgPSAweDA4MDAwMDAwOw0KK3N0YXRpYyBpbnQgYm54 Ml9UWFBfYjA2RndUZXh0TGVuID0gMHgzZmZjOw0KK3N0YXRpYyB1MzIgYm54Ml9UWFBfYjA2RndE YXRhQWRkciA9IDB4MDgwMDQwMjA7DQorc3RhdGljIGludCBibngyX1RYUF9iMDZGd0RhdGFMZW4g PSAweDA7DQorc3RhdGljIHUzMiBibngyX1RYUF9iMDZGd1JvZGF0YUFkZHIgPSAweDAwMDAwMDAw Ow0KK3N0YXRpYyBpbnQgYm54Ml9UWFBfYjA2RndSb2RhdGFMZW4gPSAweDA7DQorc3RhdGljIHUz MiBibngyX1RYUF9iMDZGd0Jzc0FkZHIgPSAweDA4MDA0MDYwOw0KK3N0YXRpYyBpbnQgYm54Ml9U WFBfYjA2RndCc3NMZW4gPSAweDE5NDsNCitzdGF0aWMgdTMyIGJueDJfVFhQX2IwNkZ3U2Jzc0Fk ZHIgPSAweDA4MDA0MDIwOw0KK3N0YXRpYyBpbnQgYm54Ml9UWFBfYjA2RndTYnNzTGVuID0gMHgz NDsNCitzdGF0aWMgdTMyIGJueDJfVFhQX2IwNkZ3VGV4dFsoMHgzZmZjLzQpICsgMV0gPSB7DQog CTB4MGEwMDA4MjQsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMGQsIDB4NzQ3ODcw MjAsIDB4MzAyZTM2MmUsDQogCTB4MzkwMDAwMDAsIDB4MDAwNjA5MDAsIDB4MDAwMDAwMGEsIDB4 MDAwMDAzZTgsIDB4MDAwMGVhNjAsIDB4MDAwMDAwMDAsDQogCTB4MDAwMDAwMDAsIDB4MDAwMDAw MDAsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsIDB4MDAwMDAwMDAsDQpAQCAt MjQ2MSw4ICsyNDYxLDggQEANCiAJMHg4YzgyMDA2NCwgMHgyNTRhMDAwMSwgMHgzMTRhMDA3Ziwg MHgwMTA5NDAyMSwgMHhhZDZhMDA2MCwgMHgyNDQyMDAwMSwNCiAJMHhhYzgyMDA2NCwgMHgwM2Uw MDAwOCwgMHhhZDA1MDAxYywgMHgwMDAwMDAwMCB9Ow0KIA0KLXUzMiBUWFBfYjA2RndEYXRhWygw eDAvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KLXUzMiBUWFBfYjA2RndSb2RhdGFbKDB4MC80 KSArIDFdID0geyAweDAwMDAwMDAwIH07DQotdTMyIFRYUF9iMDZGd0Jzc1soMHgxOTQvNCkgKyAx XSA9IHsgMHgwMDAwMDAwMCB9Ow0KLXUzMiBUWFBfYjA2RndTYnNzWygweDM0LzQpICsgMV0gPSB7 IDB4MDAwMDAwMDAgfTsNCitzdGF0aWMgdTMyIGJueDJfVFhQX2IwNkZ3RGF0YVsoMHgwLzQpICsg MV0gPSB7IDB4MDAwMDAwMDAgfTsNCitzdGF0aWMgdTMyIGJueDJfVFhQX2IwNkZ3Um9kYXRhWygw eDAvNCkgKyAxXSA9IHsgMHgwMDAwMDAwMCB9Ow0KK3N0YXRpYyB1MzIgYm54Ml9UWFBfYjA2RndC c3NbKDB4MTk0LzQpICsgMV0gPSB7IDB4MDAwMDAwMDAgfTsNCitzdGF0aWMgdTMyIGJueDJfVFhQ X2IwNkZ3U2Jzc1soMHgzNC80KSArIDFdID0geyAweDAwMDAwMDAwIH07DQogDQo= --=-ntrXuoi1OaRC1/w9Dti2-- From mchan@broadcom.com Mon May 23 18:28:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:28:42 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1SdF3000572 for ; Mon, 23 May 2005 18:28:39 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:27:49 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:27:47 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZY38393; Mon, 23 May 2005 18:27:47 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16989; Mon, 23 May 2005 18:27:47 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:27:47 +0000 Received: from rh4 by nt-irva-0741; 23 May 2005 17:30:03 -0700 Subject: [PATCH 6/6] bnx2: Update revision and reldate From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1116892439.4908.1.camel@rh4> References: <1116892439.4908.1.camel@rh4> Date: Mon, 23 May 2005 17:30:03 -0700 Message-ID: <1116894603.4908.34.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E8C5C9F2U41548329-01-01 Content-Type: multipart/mixed; boundary="=-MN/U9CxwxV//K0skMUe7" X-archive-position: 1535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 994 Lines: 28 --=-MN/U9CxwxV//K0skMUe7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Signed-off-by: Michael Chan --=-MN/U9CxwxV//K0skMUe7 Content-Disposition: attachment; filename=bnx2-16.patch Content-Type: text/x-patch; charset=utf-8; name=bnx2-16.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDE1L2RyaXZlcnMvbmV0L2JueDIuYyAxNi9kcml2ZXJzL25ldC9ibngyLmMNCi0t LSAxNS9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMzozMTowNS4wMDAwMDAwMDAgLTA3 MDANCisrKyAxNi9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMzozNjo0MC4wMDAwMDAw MDAgLTA3MDANCkBAIC0xNCw4ICsxNCw4IEBADQogDQogI2RlZmluZSBEUlZfTU9EVUxFX05BTUUJ CSJibngyIg0KICNkZWZpbmUgUEZYIERSVl9NT0RVTEVfTkFNRQkiOiAiDQotI2RlZmluZSBEUlZf TU9EVUxFX1ZFUlNJT04JIjEuMi4xOCINCi0jZGVmaW5lIERSVl9NT0RVTEVfUkVMREFURQkiTWF5 IDE5LCAyMDA1Ig0KKyNkZWZpbmUgRFJWX01PRFVMRV9WRVJTSU9OCSIxLjIuMTkiDQorI2RlZmlu ZSBEUlZfTU9EVUxFX1JFTERBVEUJIk1heSAyMywgMjAwNSINCiANCiAjZGVmaW5lIFJVTl9BVCh4 KSAoamlmZmllcyArICh4KSkNCiANCg== --=-MN/U9CxwxV//K0skMUe7-- From jgarzik@pobox.com Mon May 23 18:43:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:43:59 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1htF3002796 for ; Mon, 23 May 2005 18:43:55 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DaORj-00017L-8S; Tue, 24 May 2005 01:43:04 +0000 Message-ID: <429286A3.1060606@pobox.com> Date: Mon, 23 May 2005 21:42:59 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 1/6] bnx2: Fix excessive stack usage References: <1116892439.4908.1.camel@rh4> <1116894307.4908.28.camel@rh4> In-Reply-To: <1116894307.4908.28.camel@rh4> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 877 Lines: 41 Michael Chan wrote: > diff -Nru 10/drivers/net/bnx2.c 11/drivers/net/bnx2.c > --- 10/drivers/net/bnx2.c 2005-05-23 10:20:02.000000000 -0700 > +++ 11/drivers/net/bnx2.c 2005-05-23 10:20:20.000000000 -0700 > @@ -1138,13 +1138,20 @@ > } > } > > -static void > +static int > bnx2_alloc_bad_rbuf(struct bnx2 *bp) > { > - u16 good_mbuf[512]; > + u16 *good_mbuf; > u32 good_mbuf_cnt; > u32 val; > > + good_mbuf = kmalloc(512 * sizeof(u16), GFP_KERNEL); > + if (good_mbuf == NULL) { > + printk(KERN_ERR PFX "Failed to allocate memory in " > + "bnx2_alloc_bad_rbuf\n"); > + return -ENOMEM; > + } > + > REG_WR(bp, BNX2_MISC_ENABLE_SET_BITS, > BNX2_MISC_ENABLE_SET_BITS_RX_MBUF_ENABLE); > > @@ -1178,6 +1185,7 @@ > > REG_WR_IND(bp, BNX2_RBUF_FW_BUF_FREE, val); > } > + return 0; > } > > static void memleak -- you need to free good_mbuf. Jeff From jgarzik@pobox.com Mon May 23 18:48:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:49:00 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1mtF3003471 for ; Mon, 23 May 2005 18:48:57 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DaOWe-000181-M2; Tue, 24 May 2005 01:48:09 +0000 Message-ID: <429287D2.7030406@pobox.com> Date: Mon, 23 May 2005 21:48:02 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 0/6] bnx2: Misc fixes References: <1116892439.4908.1.camel@rh4> In-Reply-To: <1116892439.4908.1.camel@rh4> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 215 Lines: 12 Michael Chan wrote: > These patches fix the following problems spotted by Jeff Garzik. Thanks > Jeff. Thanks for fixing them up. I ACK patches #2 - #6. Sent a comment related to #1 in a separate email. Jeff From herbert@gondor.apana.org.au Mon May 23 19:33:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 19:33:52 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O2XkF3006607 for ; Mon, 23 May 2005 19:33:47 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaPE2-0002l6-00; Tue, 24 May 2005 12:32:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaPE1-0007c4-00; Tue, 24 May 2005 12:32:57 +1000 Date: Tue, 24 May 2005 12:32:57 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO v3 Message-ID: <20050524023256.GA29242@gondor.apana.org.au> References: <20050523.121943.78708600.davem@davemloft.net> <20050524003208.GA25778@gondor.apana.org.au> <20050523.192917.48530622.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523.192917.48530622.davem@davemloft.net> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1001 Lines: 23 On Mon, May 23, 2005 at 07:29:17PM -0700, David S. Miller wrote: > > > Should we skip this step if the socket has Nagle turned off? > > No, that Nagle is trying to achieve something different (optimize > request/response type communication) compared to what we're doing > here (optimizing the number of transmit calls per byte during a > bulk transfer, without allowing the congestion window to empty > too much). True, the Nagle algorithm itself aims to do something different from this function. However, the act of turning Nagle off is an indication that the application wants to minimise the latency by sending things out ASAP. So we should either respect that here by not delaying the packets to increase the TSO size, or we'll need a new socket option to do that for TSO. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Mon May 23 19:30:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 19:30:27 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O2UOF3006186 for ; Mon, 23 May 2005 19:30:24 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaPAT-0000Uk-5S; Mon, 23 May 2005 19:29:17 -0700 Date: Mon, 23 May 2005 19:29:17 -0700 (PDT) Message-Id: <20050523.192917.48530622.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO v3 From: "David S. Miller" In-Reply-To: <20050524003208.GA25778@gondor.apana.org.au> References: <20050523.121943.78708600.davem@davemloft.net> <20050524003208.GA25778@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 960 Lines: 24 From: Herbert Xu Subject: Re: [PATCH] Super TSO v3 Date: Tue, 24 May 2005 10:32:08 +1000 > On Mon, May 23, 2005 at 07:19:43PM +0000, David S. Miller wrote: > > > > The guts of the logic is in tcp_tso_should_defer(). And > > when dealing with a TSO frame, tcp_write_xmit() calls > > this instead of tcp_nagle_test(). So you can view this > > deferral as a sort of "TSO Nagle". > > Should we skip this step if the socket has Nagle turned off? No, that Nagle is trying to achieve something different (optimize request/response type communication) compared to what we're doing here (optimizing the number of transmit calls per byte during a bulk transfer, without allowing the congestion window to empty too much). > Also why are we doing this check in tcp_push_one? The only > way we can get there is if the TSO goal has been reached > or there is out-of-band stuff to send. Good point, that copy of the test can be removed. From davem@davemloft.net Mon May 23 19:39:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 19:39:10 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O2d3F3007472 for ; Mon, 23 May 2005 19:39:07 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DaPJB-0000Zl-8x; Mon, 23 May 2005 19:38:17 -0700 Date: Mon, 23 May 2005 19:38:17 -0700 (PDT) Message-Id: <20050523.193817.112290763.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO v3 From: "David S. Miller" In-Reply-To: <20050524023256.GA29242@gondor.apana.org.au> References: <20050524003208.GA25778@gondor.apana.org.au> <20050523.192917.48530622.davem@davemloft.net> <20050524023256.GA29242@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 617 Lines: 14 From: Herbert Xu Date: Tue, 24 May 2005 12:32:57 +1000 > True, the Nagle algorithm itself aims to do something different > from this function. However, the act of turning Nagle off is > an indication that the application wants to minimise the latency > by sending things out ASAP. So we should either respect that > here by not delaying the packets to increase the TSO size, or > we'll need a new socket option to do that for TSO. Sure, we can check tp->nonagle to turn this deferring off. But, I bet there are folks who want traditional Nagle turned off, yet TSO chunking enabled. From yoshfuji@linux-ipv6.org Mon May 23 20:47:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 20:47:24 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O3lGF3015582 for ; Mon, 23 May 2005 20:47:19 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9815633CC2; Tue, 24 May 2005 12:49:19 +0900 (JST) Date: Tue, 24 May 2005 12:49:19 +0900 (JST) Message-Id: <20050524.124919.00464304.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com Subject: [XFRM] Call dst_check() with appropriate cookie From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 2883 Lines: 84 From: Kazunori Miyazawa [XFRM] Call dst_check() with appropriate cookie. This fixes infinite loop issue with IPv6 tunnel mode. Signed-off-by: Kazunori Miyazawa Signed-off-by: Hideaki YOSHIFUJI diff -ruN linux-2.6.12-rc4-git7/include/net/xfrm.h linux-2.6.12-rc4-git7-ipv6ipsec/include/net/xfrm.h --- linux-2.6.12-rc4-git7/include/net/xfrm.h 2005-05-24 00:15:26.000000000 +0900 +++ linux-2.6.12-rc4-git7-ipv6ipsec/include/net/xfrm.h 2005-05-24 00:19:24.000000000 +0900 @@ -515,6 +515,8 @@ struct dst_entry *route; u32 route_mtu_cached; u32 child_mtu_cached; + u32 route_cookie; + u32 path_cookie; }; static inline void xfrm_dst_destroy(struct xfrm_dst *xdst) diff -ruN linux-2.6.12-rc4-git7/net/ipv4/xfrm4_policy.c linux-2.6.12-rc4-git7-ipv6ipsec/net/ipv4/xfrm4_policy.c --- linux-2.6.12-rc4-git7/net/ipv4/xfrm4_policy.c 2005-05-24 00:15:27.000000000 +0900 +++ linux-2.6.12-rc4-git7-ipv6ipsec/net/ipv4/xfrm4_policy.c 2005-05-24 00:20:29.000000000 +0900 @@ -95,6 +95,7 @@ xdst = (struct xfrm_dst *)dst1; xdst->route = &rt->u.dst; + xdst->route_cookie = 0; dst1->next = dst_prev; dst_prev = dst1; @@ -119,6 +120,7 @@ dst_prev->child = &rt->u.dst; dst->path = &rt->u.dst; + ((struct xfrm_dst*)dst)->path_cookie = 0; *dst_p = dst; dst = dst_prev; diff -ruN linux-2.6.12-rc4-git7/net/ipv6/xfrm6_policy.c linux-2.6.12-rc4-git7-ipv6ipsec/net/ipv6/xfrm6_policy.c --- linux-2.6.12-rc4-git7/net/ipv6/xfrm6_policy.c 2005-05-24 00:15:27.000000000 +0900 +++ linux-2.6.12-rc4-git7-ipv6ipsec/net/ipv6/xfrm6_policy.c 2005-05-24 00:22:15.000000000 +0900 @@ -113,6 +113,7 @@ xdst = (struct xfrm_dst *)dst1; xdst->route = &rt->u.dst; + xdst->route_cookie = rt->rt6i_node->fn_sernum; dst1->next = dst_prev; dst_prev = dst1; @@ -137,6 +138,7 @@ dst_prev->child = &rt->u.dst; dst->path = &rt->u.dst; + ((struct xfrm_dst*)dst)->path_cookie = rt->rt6i_node->fn_sernum; *dst_p = dst; dst = dst_prev; diff -ruN linux-2.6.12-rc4-git7/net/xfrm/xfrm_policy.c linux-2.6.12-rc4-git7-ipv6ipsec/net/xfrm/xfrm_policy.c --- linux-2.6.12-rc4-git7/net/xfrm/xfrm_policy.c 2005-05-24 00:15:28.000000000 +0900 +++ linux-2.6.12-rc4-git7-ipv6ipsec/net/xfrm/xfrm_policy.c 2005-05-24 00:22:57.000000000 +0900 @@ -1136,7 +1136,7 @@ struct xfrm_dst *last; u32 mtu; - if (!dst_check(dst->path, 0) || + if (!dst_check(dst->path, ((struct xfrm_dst*)dst)->path_cookie) || (dst->dev && !netif_running(dst->dev))) return 0; @@ -1156,7 +1156,7 @@ xdst->child_mtu_cached = mtu; } - if (!dst_check(xdst->route, 0)) + if (!dst_check(xdst->route, xdst->route_cookie)) return 0; mtu = dst_mtu(xdst->route); if (xdst->route_mtu_cached != mtu) { -- YOSHIFUJI Hideaki @ USAGI Project GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From jgarzik@pobox.com Mon May 23 21:27:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 21:27:39 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O4RYF3017521 for ; Mon, 23 May 2005 21:27:34 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DaR0B-0001Lw-Th; Tue, 24 May 2005 04:26:49 +0000 Message-ID: <4292AD04.9090700@pobox.com> Date: Tue, 24 May 2005 00:26:44 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John W. Linville" CC: netdev@oss.sgi.com, Clear.Zhang@uli.com.tw Subject: Re: [patch 2.6.12-rc4 1/1] tulip: add return to ULI526X clause in tulip_mdio_write References: <20050518174132.GB16148@tuxdriver.com> In-Reply-To: <20050518174132.GB16148@tuxdriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 8 Lines: 1 applied From mchan@broadcom.com Mon May 23 22:28:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 22:28:09 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O5S4F3019930 for ; Mon, 23 May 2005 22:28:04 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 22:27:03 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 22:27:02 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AZY77476; Mon, 23 May 2005 22:27:00 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id WAA17713; Mon, 23 May 2005 22:27:00 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 May 2005 05:27:00 +0000 Received: from rh4 by nt-irva-0741; 23 May 2005 21:29:16 -0700 Subject: Re: [PATCH 1/6] bnx2: Fix excessive stack usage From: "Michael Chan" To: "Jeff Garzik" cc: davem@davemloft.net, netdev@oss.sgi.com In-Reply-To: <429286A3.1060606@pobox.com> References: <1116892439.4908.1.camel@rh4> <1116894307.4908.28.camel@rh4> <429286A3.1060606@pobox.com> Date: Mon, 23 May 2005 21:29:16 -0700 Message-ID: <1116908956.5984.4.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E8C64AD1VO1483929-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 2200 Lines: 102 On Mon, 2005-05-23 at 21:42 -0400, Jeff Garzik wrote: > > memleak -- you need to free good_mbuf. > Oops, here is the revised patch with kfree(). Thanks. Fix excessive stack usage in bnx2_alloc_bad_rbuf() by replacing local variable array with kmalloc array. Also changed function to return error code, and changed some of the callers to check for the return code. Spotted by Jeff Garzik. Signed-off-by: Michael Chan diff -Nru 10/drivers/net/bnx2.c 11/drivers/net/bnx2.c --- 10/drivers/net/bnx2.c 2005-05-23 10:20:02.000000000 -0700 +++ 11/drivers/net/bnx2.c 2005-05-23 21:13:46.000000000 -0700 @@ -1138,13 +1138,20 @@ } } -static void +static int bnx2_alloc_bad_rbuf(struct bnx2 *bp) { - u16 good_mbuf[512]; + u16 *good_mbuf; u32 good_mbuf_cnt; u32 val; + good_mbuf = kmalloc(512 * sizeof(u16), GFP_KERNEL); + if (good_mbuf == NULL) { + printk(KERN_ERR PFX "Failed to allocate memory in " + "bnx2_alloc_bad_rbuf\n"); + return -ENOMEM; + } + REG_WR(bp, BNX2_MISC_ENABLE_SET_BITS, BNX2_MISC_ENABLE_SET_BITS_RX_MBUF_ENABLE); @@ -1178,6 +1185,8 @@ REG_WR_IND(bp, BNX2_RBUF_FW_BUF_FREE, val); } + kfree(good_mbuf); + return 0; } static void @@ -2710,7 +2719,7 @@ bnx2_reset_chip(struct bnx2 *bp, u32 reset_code) { u32 val; - int i; + int i, rc = 0; /* Wait for the current PCI transaction to complete before * issuing a reset. */ @@ -2785,10 +2794,10 @@ REG_WR(bp, BNX2_MISC_VREG_CONTROL, 0x000000fa); /* Remove bad rbuf memory from the free pool. */ - bnx2_alloc_bad_rbuf(bp); + rc = bnx2_alloc_bad_rbuf(bp); } - return 0; + return rc; } static int @@ -3097,8 +3106,13 @@ static int bnx2_reset_nic(struct bnx2 *bp, u32 reset_code) { - bnx2_reset_chip(bp, reset_code); + int rc; + + rc = bnx2_reset_chip(bp, reset_code); bnx2_free_skbs(bp); + if (rc) + return rc; + bnx2_init_chip(bp); bnx2_init_tx_ring(bp); bnx2_init_rx_ring(bp); @@ -3108,7 +3122,11 @@ static int bnx2_init_nic(struct bnx2 *bp) { - bnx2_reset_nic(bp, BNX2_DRV_MSG_CODE_RESET); + int rc; + + if ((rc = bnx2_reset_nic(bp, BNX2_DRV_MSG_CODE_RESET)) != 0) + return rc; + bnx2_init_phy(bp); bnx2_set_link(bp); return 0; From jgarzik@pobox.com Mon May 23 22:44:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 22:44:08 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O5i5F3020882 for ; Mon, 23 May 2005 22:44:05 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DaSCG-0001Nh-1q; Tue, 24 May 2005 05:43:20 +0000 Message-ID: <4292BEF6.2080804@pobox.com> Date: Tue, 24 May 2005 01:43:18 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 1/6] bnx2: Fix excessive stack usage References: <1116892439.4908.1.camel@rh4> <1116894307.4908.28.camel@rh4> <429286A3.1060606@pobox.com> <1116908956.5984.4.camel@rh4> In-Reply-To: <1116908956.5984.4.camel@rh4> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 495 Lines: 20 Michael Chan wrote: > On Mon, 2005-05-23 at 21:42 -0400, Jeff Garzik wrote: > >>memleak -- you need to free good_mbuf. >> > > > Oops, here is the revised patch with kfree(). Thanks. > > Fix excessive stack usage in bnx2_alloc_bad_rbuf() by replacing local > variable array with kmalloc array. Also changed function to return error > code, and changed some of the callers to check for the return code. > > Spotted by Jeff Garzik. > > Signed-off-by: Michael Chan ACK From torvalds@osdl.org Mon May 23 23:07:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 23:07:10 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O676F3022037 for ; Mon, 23 May 2005 23:07:06 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4O66LjA023291 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 23:06:21 -0700 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4O66KuD011104; Mon, 23 May 2005 23:06:20 -0700 Date: Mon, 23 May 2005 23:08:25 -0700 (PDT) From: Linus Torvalds To: Jeff Garzik cc: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches] 2.6.x net driver updates In-Reply-To: <4292BA66.8070806@pobox.com> Message-ID: References: <4292BA66.8070806@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev Content-Length: 4514 Lines: 116 On Tue, 24 May 2005, Jeff Garzik wrote: > Please pull the 'for-linus' branch from > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git Is this really what you meant to do? There's seven merges there, none of which have _any_ information about _what_ you merged, because you've mixed everything up in one tree, so that there's absolutely no record of the fact that you actually had seven different repositories that you pulled.. That sucks, Jeff. I don't understand why you don't use different trees, like you did with BK. You can share the object directory with the different trees, but the way you work now, it all looks like mush. Even if you don't get confused youself, you sure are confusing everybody else with it.. Anyway, if you really want to work this way, with one big mushed-together thing that has different heads that you keep track of, can you _please_ at least make the commit message tell what you're doing. It's not a complex script, and you're definitely mis-using it as things stand now by switching heads around inside one repository, and not telling other people about it. --- side note --- Also, the way you work, I think you actually may want to do a multi-parent merge. That is, you may want to merge multiple parents in _one_ commit, rather than having seven commits for it. The way to do that is to just do "git-read-tree -m" (and the subsequent merge) several times. You do not have to commit in between each step, you just need to remember the parents, and then you do the final commit with git-commit-tree $result_tree -p $head -p $p1 -p $p2 -p $p3 ... ie you build up a commit command line that grows one more "-p xxxx" for each parent you have merged. That requires a bit more work, but as it is, your merges just look like crap. --- end side note ---- Please? Linus ---- commit fd3fac6ffe20bc6ca75b3ad38be0a8be6666b5d3 tree 49b4cfa6c95094612438b1ddeb0c9511a19125fe parent c97f5a778ed33aef8f62496d7b82ba3cb896a587 parent b3dd65f958354226275522b5a64157834bdc5415 author Tue, 24 May 2005 00:47:58 -0400 committer Jeff Garzik Tue, 24 May 2005 00:47:58 -0400 Automatic merge of /spare/repo/netdev-2.6/.git commit c97f5a778ed33aef8f62496d7b82ba3cb896a587 tree c72dbed812b0ffa83700a1896895714248407daf parent 09fc75b6757852798969e7585456499784a982e1 parent 1bcd315362e215a72b56d1330bbf32f1c74eefb5 author Tue, 24 May 2005 00:47:43 -0400 committer Jeff Garzik Tue, 24 May 2005 00:47:43 -0400 Automatic merge of /spare/repo/netdev-2.6/.git commit 09fc75b6757852798969e7585456499784a982e1 tree 60a2d2893cb757307edf0a0c450689610644cac2 parent b5545f2a2d915f5b6d86fb57e6ccc96b3010259e parent ac79c82e793bc2440c4765e5eb1b834d2c18edf2 author Tue, 24 May 2005 00:47:28 -0400 committer Jeff Garzik Tue, 24 May 2005 00:47:28 -0400 Automatic merge of /spare/repo/netdev-2.6/.git commit b5545f2a2d915f5b6d86fb57e6ccc96b3010259e tree 0ece2dd139d1fa4a6b0c5f61fc2be75692d0ea47 parent f180e742711ce512e62161436d166eb4df92b34d parent 2648345fcbadfae8e7113112ff9402e465a184dc author Tue, 24 May 2005 00:47:20 -0400 committer Jeff Garzik Tue, 24 May 2005 00:47:20 -0400 Automatic merge of /spare/repo/netdev-2.6/.git commit f180e742711ce512e62161436d166eb4df92b34d tree 21fcfc0ca4a47776bc1182898d9b394529aa1daf parent 7b5c2db59567052805771e1de2ad4e089b88c847 parent 042e2fb70006f135469d546726451b7d14768980 author Tue, 24 May 2005 00:47:12 -0400 committer Jeff Garzik Tue, 24 May 2005 00:47:12 -0400 Automatic merge of /spare/repo/netdev-2.6/.git commit 7b5c2db59567052805771e1de2ad4e089b88c847 tree d18dc44dcfd34a99ac11a83e6d324730784b7d81 parent 02dd6b49b3f75dacfa7eddf7f2faa8b810906e47 parent 9092f46b5aed4515d9a427d5dab3be1584851f07 author Tue, 24 May 2005 00:45:05 -0400 committer Jeff Garzik Tue, 24 May 2005 00:45:05 -0400 Merge of /spare/repo/netdev-2.6/.git commit 02dd6b49b3f75dacfa7eddf7f2faa8b810906e47 tree 240cfa2396a6ed006ee28f3848b4cceebfc35b11 parent 187a1a94d629621d1471b42308e63573b1150773 parent dfa1b73ffb414b64dc0452260132a090eb25bf52 author Tue, 24 May 2005 00:44:49 -0400 committer Jeff Garzik Tue, 24 May 2005 00:44:49 -0400 Automatic merge of /spare/repo/netdev-2.6/.git From jgarzik@pobox.com Mon May 23 23:26:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 23:26:44 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O6QfF3023064 for ; Mon, 23 May 2005 23:26:41 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DaSrU-0001Og-4d; Tue, 24 May 2005 06:25:56 +0000 Message-ID: <4292C8EF.3090307@pobox.com> Date: Tue, 24 May 2005 02:25:51 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linus Torvalds CC: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches] 2.6.x net driver updates References: <4292BA66.8070806@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 2060 Lines: 60 Linus Torvalds wrote: > > On Tue, 24 May 2005, Jeff Garzik wrote: > > >>Please pull the 'for-linus' branch from >> >>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git > > > Is this really what you meant to do? There's seven merges there, none of > which have _any_ information about _what_ you merged, because you've mixed > everything up in one tree, so that there's absolutely no record of the > fact that you actually had seven different repositories that you pulled.. > > That sucks, Jeff. > > I don't understand why you don't use different trees, like you did with > BK. You can share the object directory with the different trees, but the > way you work now, it all looks like mush. > > Even if you don't get confused youself, you sure are confusing everybody > else with it.. You are getting precisely the same thing you got under BitKeeper: pull from X, you get my tree, which was composed from $N repositories. The tree you pull was created by my running 'bk pull' locally $N times. Ultimately, you appear to be complaining about: * your own git-pull-script, which doesn't record the $2 (branch) argument in the commit message. * the fact that my changelog includes the merge csets that were present-but-invisible by my BitKeeper submissions. i.e. I lack a shortlog that filters out merge csets. > Anyway, if you really want to work this way, with one big mushed-together > thing that has different heads that you keep track of, can you _please_ at > least make the commit message tell what you're doing. It's not a complex Hey, I didn't write git-pull-script, I just use it :) > script, and you're definitely mis-using it as things stand now by > switching heads around inside one repository, and not telling other people > about it. Switching heads around? It sounds like you did not pull from the branch I mentioned. This is how git-pull-script pulls from a branch: git-pull-script \ rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\ refs/heads/for-linus Jeff From jgarzik@pobox.com Mon May 23 23:35:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 23:35:31 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O6ZTF3023832 for ; Mon, 23 May 2005 23:35:29 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DaT00-0001Ow-FO; Tue, 24 May 2005 06:34:44 +0000 Message-ID: <4292CB01.6090506@pobox.com> Date: Tue, 24 May 2005 02:34:41 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linus Torvalds CC: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches] 2.6.x net driver updates References: <4292BA66.8070806@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 314 Lines: 13 Linus Torvalds wrote: > I don't understand why you don't use different trees, like you did with > BK. You can share the object directory with the different trees, but the You really can't beat cp .git/refs/heads/master .git/refs/heads/new-branch as the fastest way to create a new branch off the tip. Jeff From pravins@calsoftinc.com Mon May 23 23:45:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 23:45:37 -0700 (PDT) Received: from ganesha.intranet.calsoftinc.com ([220.225.34.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O6jWF3024888 for ; Mon, 23 May 2005 23:45:33 -0700 Received: from [172.16.0.108] (unknown [172.16.0.108]) by ganesha.intranet.calsoftinc.com (Postfix) with ESMTP id 6FC7EDB58B; Tue, 24 May 2005 12:07:27 +0530 (IST) Message-ID: <4292CDCE.2090600@calsoftinc.com> Date: Tue, 24 May 2005 12:16:38 +0530 From: pravin b shelar User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH] : bug fix in multipath drr code. References: <4291CBFF.6080106@calsoftinc.com> <20050523232224.GA25349@gondor.apana.org.au> In-Reply-To: <20050523232224.GA25349@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pravins@calsoftinc.com Precedence: bulk X-list: netdev Content-Length: 1192 Lines: 41 Herbert Xu wrote: >On Mon, May 23, 2005 at 05:56:39PM +0530, pravin wrote: > > >> /* if necessary and possible utilize the old alternative */ >>- if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 && >>- last_selection != NULL) { >>- result = last_selection; >>- *rp = result; >>- return; >>+ if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 ) { >>+ struct rtable *last_result = last_selection; >>+ if(last_result != NULL && >>+ multipath_comparekeys(&last_result->fl, flp)) { >>+ *rp = last_result; >>+ return; >>+ } >> } >> >> > >You don't need all this code. All you need to do is do >result = last_selection before the if condition and then >check result in the if condition instead of last_selection. > >The multipath_comparekeys isn't necessary either. > > > In concurrent invocations of drr_select_route() last_selection will change to different route. So in that case we can not use last_selection route on basis of FLOWI_FLAG_MULTIPATHOLDROUTE flag only, since old route might be totally different due another invocation of same function. So, I think multipath_comparekeys is necessary. Please correct me if I am wrong. Regards, Pravin. From torvalds@osdl.org Mon May 23 23:47:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 23:47:20 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O6lEF3025226 for ; Mon, 23 May 2005 23:47:14 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4O6kTjA025713 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 23:46:29 -0700 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4O6kScg012582; Mon, 23 May 2005 23:46:28 -0700 Date: Mon, 23 May 2005 23:48:33 -0700 (PDT) From: Linus Torvalds To: Jeff Garzik cc: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches] 2.6.x net driver updates In-Reply-To: <4292C8EF.3090307@pobox.com> Message-ID: References: <4292BA66.8070806@pobox.com> <4292C8EF.3090307@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev Content-Length: 1754 Lines: 53 On Tue, 24 May 2005, Jeff Garzik wrote: > > You are getting precisely the same thing you got under BitKeeper: pull > from X, you get my tree, which was composed from $N repositories. The > tree you pull was created by my running 'bk pull' locally $N times. No. Under BK, you had DIFFERENT TREES. What does that mean? They had DIFFERENT NAMES. Which meant that the commit message was MEANINGFUL. > Ultimately, you appear to be complaining about: > > * your own git-pull-script, which doesn't record the $2 (branch) > argument in the commit message. Yes, because _my_ pull script is meant to work with the way _I_ have told people (including you) they should work. The fact that you mush everything up in one tree _despite_ me having told you that isn't a good thing to do is the problem. Git can technically do it, but then you shouldn't use my scripts, which aren't written for that behaviour. > Hey, I didn't write git-pull-script, I just use it :) You don't use it, you MIS-use it. Which is what I'm complaining about. > Switching heads around? It sounds like you did not pull from the branch > I mentioned. No, I pulled exactly from the head you mentioned. In fact, go look at YOUR OWN changelog. And then compare that changelog to the changelog you had when you used BK, and realize that IT IS NOT AT ALL EQUIVALENT. You used to have valid changelogs, even for the merge heads. You don't any more: Automatic merge of /spare/repo/netdev-2.6/.git Automatic merge of /spare/repo/netdev-2.6/.git Automatic merge of /spare/repo/netdev-2.6/.git Automatic merge of /spare/repo/netdev-2.6/.git Merge of /spare/repo/netdev-2.6/.git See a pattern? Your BK usage was equivalent to having multiple GIT repositories. Linus From torvalds@osdl.org Mon May 23 23:49:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 23:49:20 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O6nHF3025973 for ; Mon, 23 May 2005 23:49:17 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4O6mWjA025872 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 May 2005 23:48:32 -0700 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4O6mVWw012672; Mon, 23 May 2005 23:48:31 -0700 Date: Mon, 23 May 2005 23:50:36 -0700 (PDT) From: Linus Torvalds To: Jeff Garzik cc: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches] 2.6.x net driver updates In-Reply-To: <4292CB01.6090506@pobox.com> Message-ID: References: <4292BA66.8070806@pobox.com> <4292CB01.6090506@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev Content-Length: 348 Lines: 16 On Tue, 24 May 2005, Jeff Garzik wrote: > > You really can't beat > > cp .git/refs/heads/master .git/refs/heads/new-branch > > as the fastest way to create a new branch off the tip. So? It's the fastest, but it's also BROKEN. Exactly because the way you do things, the merge messages are meaningless. So fix your merge messages. Linus From herbert@gondor.apana.org.au Tue May 24 00:12:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 00:12:46 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O7CbF3029481 for ; Tue, 24 May 2005 00:12:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaTZs-000437-00; Tue, 24 May 2005 17:11:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaTZq-00084T-00; Tue, 24 May 2005 17:11:46 +1000 Date: Tue, 24 May 2005 17:11:46 +1000 To: pravin b shelar Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH] : bug fix in multipath drr code. Message-ID: <20050524071146.GA30995@gondor.apana.org.au> References: <4291CBFF.6080106@calsoftinc.com> <20050523232224.GA25349@gondor.apana.org.au> <4292CDCE.2090600@calsoftinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4292CDCE.2090600@calsoftinc.com> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 799 Lines: 20 On Tue, May 24, 2005 at 12:16:38PM +0530, pravin b shelar wrote: > > >The multipath_comparekeys isn't necessary either. > > In concurrent invocations of drr_select_route() last_selection will > change to different route. > So in that case we can not use last_selection route on basis of > FLOWI_FLAG_MULTIPATHOLDROUTE flag only, since old > route might be totally different due another invocation of same function. > So, I think multipath_comparekeys is necessary. Indeed. In fact this whole MULTIPATHOLDROUTE thing can't possibly work at all. I'd suggest that it be removed. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue May 24 00:17:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 00:17:45 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O7HXF3030187 for ; Tue, 24 May 2005 00:17:34 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaTeZ-00045O-00; Tue, 24 May 2005 17:16:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaTeW-00085B-00; Tue, 24 May 2005 17:16:36 +1000 From: Herbert Xu To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / ????) Subject: Re: [XFRM] Call dst_check() with appropriate cookie Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050524.124919.00464304.yoshfuji@linux-ipv6.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 24 May 2005 17:16:36 +1000 X-archive-position: 1552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 496 Lines: 15 YOSHIFUJI Hideaki / ???? wrote: > From: Kazunori Miyazawa > > [XFRM] Call dst_check() with appropriate cookie. > > This fixes infinite loop issue with IPv6 tunnel mode. Can someone please tell me where this infinite loop is? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Tue May 24 00:28:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 00:28:09 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O7S4F3002040 for ; Tue, 24 May 2005 00:28:04 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1D96E33CC2; Tue, 24 May 2005 16:30:19 +0900 (JST) Date: Tue, 24 May 2005 16:30:18 +0900 (JST) Message-Id: <20050524.163018.29919354.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, kazunori@miyazawa.org Subject: Re: [XFRM] Call dst_check() with appropriate cookie From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20050524.124919.00464304.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 448 Lines: 11 In article (at Tue, 24 May 2005 17:16:36 +1000), Herbert Xu says: > > This fixes infinite loop issue with IPv6 tunnel mode. > > Can someone please tell me where this infinite loop is? Honestly speaking, we haven't tracked down deeply where it is, but that patch is logically reauired and it definetely solves grave "freeze" issue with ipv6 tunnel mode xfrm. --yoshfuji From util@deuroconsult.ro Tue May 24 00:30:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 00:30:30 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O7UOF3002669 for ; Tue, 24 May 2005 00:30:25 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4O7TPSc021803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2005 10:29:25 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4O7TPWA021800; Tue, 24 May 2005 10:29:25 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Tue, 24 May 2005 10:29:25 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: netdev@oss.sgi.com cc: davem@davemloft.net Subject: [PATCH] [BRIDGE] Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1646943047-1535395764-1116919588=:19687" Content-ID: X-archive-position: 1554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 4969 Lines: 97 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1646943047-1535395764-1116919588=:19687 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Hello! This patch set bridge device features using the common features of all slaves. Also, it reacts to features change using ethtool on the slaves. This patch depends on NETDEV_FEAT_CHANGE.patch. David, please apply if it looks good. Thank you. Signed-off-by: Catalin BOIE --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ---1646943047-1535395764-1116919588=:19687 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=bridge_features.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=bridge_features.patch LS0tIGJyaWRnZTEvbmV0L2JyaWRnZS9icl9wcml2YXRlLmgJMjAwNS0wMy0w MiAwOTozNzo1MC4wMDAwMDAwMDAgKzAyMDANCisrKyBsaW51eC9uZXQvYnJp ZGdlL2JyX3ByaXZhdGUuaAkyMDA1LTA1LTIzIDExOjExOjIyLjAwMDAwMDAw MCArMDMwMA0KQEAgLTI3LDYgKzI3LDEwIEBADQogI2RlZmluZSBCUl9QT1JU X0JJVFMJMTANCiAjZGVmaW5lIEJSX01BWF9QT1JUUwkoMTw8QlJfUE9SVF9C SVRTKQ0KIA0KKyNkZWZpbmUgQlJfRkVBVF9NQVNLCShORVRJRl9GX1NHIFwN CisJCQl8IE5FVElGX0ZfRlJBR0xJU1QgXA0KKwkJCXwgTkVUSUZfRl9ISUdI RE1BIHwgTkVUSUZfRl9UU08pDQorDQogdHlwZWRlZiBzdHJ1Y3QgYnJpZGdl X2lkIGJyaWRnZV9pZDsNCiB0eXBlZGVmIHN0cnVjdCBtYWNfYWRkciBtYWNf YWRkcjsNCiB0eXBlZGVmIF9fdTE2IHBvcnRfaWQ7DQpAQCAtMTc0LDYgKzE3 OCw3IEBAIGV4dGVybiBpbnQgYnJfYWRkX2lmKHN0cnVjdCBuZXRfYnJpZGdl ICoNCiBleHRlcm4gaW50IGJyX2RlbF9pZihzdHJ1Y3QgbmV0X2JyaWRnZSAq YnIsDQogCSAgICAgIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpOw0KIGV4dGVy biBpbnQgYnJfbWluX210dShjb25zdCBzdHJ1Y3QgbmV0X2JyaWRnZSAqYnIp Ow0KK2V4dGVybiB2b2lkIGJyX2ZlYXR1cmVzX3JlY29tcHV0ZShzdHJ1Y3Qg bmV0X2JyaWRnZSAqYnIpOw0KIA0KIC8qIGJyX2lucHV0LmMgKi8NCiBleHRl cm4gaW50IGJyX2hhbmRsZV9mcmFtZV9maW5pc2goc3RydWN0IHNrX2J1ZmYg KnNrYik7DQotLS0gYnJpZGdlMS9uZXQvYnJpZGdlL2JyX25vdGlmeS5jCTIw MDUtMDMtMjYgMDU6Mjg6MTQuMDAwMDAwMDAwICswMjAwDQorKysgbGludXgv bmV0L2JyaWRnZS9icl9ub3RpZnkuYwkyMDA1LTA1LTIzIDExOjIwOjE0LjAw MDAwMDAwMCArMDMwMA0KQEAgLTY1LDYgKzY1LDEwIEBAIHN0YXRpYyBpbnQg YnJfZGV2aWNlX2V2ZW50KHN0cnVjdCBub3RpZmkNCiAJCX0NCiAJCWJyZWFr Ow0KIA0KKwljYXNlIE5FVERFVl9GRUFUX0NIQU5HRToNCisJCWJyX2ZlYXR1 cmVzX3JlY29tcHV0ZShicik7DQorCQlicmVhazsNCisNCiAJY2FzZSBORVRE RVZfRE9XTjoNCiAJCWlmIChici0+ZGV2LT5mbGFncyAmIElGRl9VUCkNCiAJ CQlicl9zdHBfZGlzYWJsZV9wb3J0KHApOw0KLS0tIGJyaWRnZTEvbmV0L2Jy aWRnZS9icl9kZXZpY2UuYwkyMDA1LTAzLTAyIDA5OjM3OjMwLjAwMDAwMDAw MCArMDIwMA0KKysrIGxpbnV4L25ldC9icmlkZ2UvYnJfZGV2aWNlLmMJMjAw NS0wNS0yMCAwODo1MzozNy4wMDAwMDAwMDAgKzAzMDANCkBAIC0xMDcsNCAr MTA3LDUgQEAgdm9pZCBicl9kZXZfc2V0dXAoc3RydWN0IG5ldF9kZXZpY2Ug KmRldg0KIAlkZXYtPnR4X3F1ZXVlX2xlbiA9IDA7DQogCWRldi0+c2V0X21h Y19hZGRyZXNzID0gTlVMTDsNCiAJZGV2LT5wcml2X2ZsYWdzID0gSUZGX0VC UklER0U7DQorCWRldi0+ZmVhdHVyZXMgPSBCUl9GRUFUX01BU0sgfCBORVRJ Rl9GX05PX0NTVU0gfCBORVRJRl9GX0xMVFg7DQogfQ0KLS0tIGJyaWRnZTEv bmV0L2JyaWRnZS9icl9pZi5jCTIwMDUtMDMtMDIgMDk6Mzg6MzMuMDAwMDAw MDAwICswMjAwDQorKysgbGludXgvbmV0L2JyaWRnZS9icl9pZi5jCTIwMDUt MDUtMjAgMDk6MTg6MjkuMDAwMDAwMDAwICswMzAwDQpAQCAtMzE0LDYgKzMx NCwyNyBAQCBpbnQgYnJfbWluX210dShjb25zdCBzdHJ1Y3QgbmV0X2JyaWRn ZSAqDQogCXJldHVybiBtdHU7DQogfQ0KIA0KKy8qDQorICogSWYgc2xhdmUg ZGV2aWNlIChAZGV2KSBkb2Vzbid0IHN1cHBvcnQgc3BlY2lhbCBmZWF0dXJl cywNCisgKiB0dXJuIHRoZW0gb2ZmIGdsb2JhbGx5Lg0KKyAqLw0KK3ZvaWQg YnJfZmVhdHVyZXNfY2hhbmdlKHN0cnVjdCBuZXRfYnJpZGdlICpiciwgc3Ry dWN0IG5ldF9kZXZpY2UgKmRldikNCit7DQorCWJyLT5kZXYtPmZlYXR1cmVz ICY9IGRldi0+ZmVhdHVyZXMgfCB+QlJfRkVBVF9NQVNLOw0KK30NCisNCisv Kg0KKyAqIFJlY29tcHV0ZXMgZmVhdHVyZXMgdXNpbmcgc2xhdmUncyBmZWF0 dXJlcw0KKyAqLw0KK3ZvaWQgYnJfZmVhdHVyZXNfcmVjb21wdXRlKHN0cnVj dCBuZXRfYnJpZGdlICpicikNCit7DQorCXN0cnVjdCBuZXRfYnJpZGdlX3Bv cnQgKnA7DQorDQorCWJyLT5kZXYtPmZlYXR1cmVzIHw9IEJSX0ZFQVRfTUFT SzsNCisJbGlzdF9mb3JfZWFjaF9lbnRyeShwLCAmYnItPnBvcnRfbGlzdCwg bGlzdCkNCisJCWJyX2ZlYXR1cmVzX2NoYW5nZShiciwgcC0+ZGV2KTsNCit9 DQorDQogLyogY2FsbGVkIHdpdGggUlROTCAqLw0KIGludCBicl9hZGRfaWYo c3RydWN0IG5ldF9icmlkZ2UgKmJyLCBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 KQ0KIHsNCkBAIC0zMzIsOSArMzUzLDEwIEBAIGludCBicl9hZGRfaWYoc3Ry dWN0IG5ldF9icmlkZ2UgKmJyLCBzdHINCiAJaWYgKElTX0VSUihwID0gbmV3 X25icChiciwgZGV2LCBicl9pbml0aWFsX3BvcnRfY29zdChkZXYpKSkpDQog CQlyZXR1cm4gUFRSX0VSUihwKTsNCiANCisJYnJfZmVhdHVyZXNfY2hhbmdl KGJyLCBkZXYpOw0KKw0KICAJaWYgKChlcnIgPSBicl9mZGJfaW5zZXJ0KGJy LCBwLCBkZXYtPmRldl9hZGRyLCAxKSkpDQogCQlkZXN0cm95X25icChwKTsN Ci0gDQogCWVsc2UgaWYgKChlcnIgPSBicl9zeXNmc19hZGRpZihwKSkpDQog CQlkZWxfbmJwKHApOw0KIAllbHNlIHsNCkBAIC0zNjgsNiArMzkwLDcgQEAg aW50IGJyX2RlbF9pZihzdHJ1Y3QgbmV0X2JyaWRnZSAqYnIsIHN0cg0KIA0K IAlzcGluX2xvY2tfYmgoJmJyLT5sb2NrKTsNCiAJYnJfc3RwX3JlY2FsY3Vs YXRlX2JyaWRnZV9pZChicik7DQorCWJyX2ZlYXR1cmVzX3JlY29tcHV0ZShi cik7DQogCXNwaW5fdW5sb2NrX2JoKCZici0+bG9jayk7DQogDQogCXJldHVy biAwOw0K ---1646943047-1535395764-1116919588=:19687-- From jgarzik@pobox.com Tue May 24 00:30:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 00:30:34 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O7UTF3002677 for ; Tue, 24 May 2005 00:30:29 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DaTrB-0001Q6-FC; Tue, 24 May 2005 07:29:44 +0000 Message-ID: <4292D7E1.80601@pobox.com> Date: Tue, 24 May 2005 03:29:37 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linus Torvalds CC: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches] 2.6.x net driver updates References: <4292BA66.8070806@pobox.com> <4292C8EF.3090307@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1310 Lines: 38 Linus Torvalds wrote: > > On Tue, 24 May 2005, Jeff Garzik wrote: > >>You are getting precisely the same thing you got under BitKeeper: pull >>from X, you get my tree, which was composed from $N repositories. The >>tree you pull was created by my running 'bk pull' locally $N times. > > > No. Under BK, you had DIFFERENT TREES. > > What does that mean? They had DIFFERENT NAMES. > > Which meant that the commit message was MEANINGFUL. Ok, I'll fix the commit message. As for different trees, I'm afraid you've written something that is _too useful_ to be used in that manner. Git has brought with it a _major_ increase in my productivity because I can now easily share ~50 branches with 50 different kernel hackers, without spending all day running rsync. Suddenly my kernel development is a whole lot more _open_ to the world, with a single "./push". And it's awesome. That wasn't possible before with BitKeeper, just due to sheer network overhead of 50 trees. With BitKeeper, the _only_ thing that kernel hackers and users could get from me is a mush tree with everything merged into a big 'ALL' repository. So I'll continue to be the oddball, because more people can work in parallel with me that way. I'll just have to make sure the commit messages look right to you. Jeff From torvalds@osdl.org Tue May 24 00:45:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 00:46:20 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O7jGF3004087 for ; Tue, 24 May 2005 00:45:16 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4O7iVjA029720 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 May 2005 00:44:31 -0700 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4O7iUjI014722; Tue, 24 May 2005 00:44:30 -0700 Date: Tue, 24 May 2005 00:46:35 -0700 (PDT) From: Linus Torvalds To: Jeff Garzik cc: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches] 2.6.x net driver updates In-Reply-To: <4292D7E1.80601@pobox.com> Message-ID: References: <4292BA66.8070806@pobox.com> <4292C8EF.3090307@pobox.com> <4292D7E1.80601@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev Content-Length: 1135 Lines: 28 On Tue, 24 May 2005, Jeff Garzik wrote: > > Ok, I'll fix the commit message. > > As for different trees, I'm afraid you've written something that is _too > useful_ to be used in that manner. I really think you'll eventually confuse yourself terminally, but as long as the commit messages end up being meaningful, your "mush everything together" clearly is the thing that is going to perform best. > Git has brought with it a _major_ increase in my productivity because I > can now easily share ~50 branches with 50 different kernel hackers, > without spending all day running rsync. Hey, I'm happy it works for you, but are you sure those 50 other kernel hackers aren't confused? IOW, your work model is pretty extreme, and I'm much more worried about mixing up trees by mistake than about the technical side of git per se. That's also why I think it's important that the commit logs are meaningful: they do end up containing the SHA1 key, so clearly "all the information" is there, but if something gets mixed up, I'd like some human to be able to eventualyl say "Aaahhh.. _that's_ where it got mixed up". Linus From david.lang@digitalinsight.com Tue May 24 00:56:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 00:56:23 -0700 (PDT) Received: from warden2.diginsite.com (warden2-p.diginsite.com [209.195.52.120]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4O7u6F3005749 for ; Tue, 24 May 2005 00:56:06 -0700 Received: from atlims01.diginsite.com by warden2.diginsite.com via smtpd (for oss.sgi.com [192.48.159.27]) with SMTP; Tue, 24 May 2005 00:50:16 -0700 Received: by atlexc02.diginsite.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 May 2005 03:55:06 -0400 Received: from dlang.diginsite.com ([10.201.10.67]) by wlvexc00.digitalinsight.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LNM3VH0R; Tue, 24 May 2005 00:55:02 -0700 From: David Lang To: Jeff Garzik Cc: Linus Torvalds , Andrew Morton , Netdev , Linux Kernel Date: Tue, 24 May 2005 00:55:03 -0700 (PDT) X-X-Sender: dlang@dlang.diginsite.com Subject: Re: [git patches] 2.6.x net driver updates In-Reply-To: <4292D7E1.80601@pobox.com> Message-ID: References: <4292BA66.8070806@pobox.com> <4292C8EF.3090307@pobox.com> <4292D7E1.80601@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david.lang@digitalinsight.com Precedence: bulk X-list: netdev Content-Length: 1625 Lines: 41 On Tue, 24 May 2005, Jeff Garzik wrote: > Linus Torvalds wrote: >> >> On Tue, 24 May 2005, Jeff Garzik wrote: >> >>> You are getting precisely the same thing you got under BitKeeper: pull >>> from X, you get my tree, which was composed from $N repositories. The >>> tree you pull was created by my running 'bk pull' locally $N times. >> >> >> No. Under BK, you had DIFFERENT TREES. >> >> What does that mean? They had DIFFERENT NAMES. >> >> Which meant that the commit message was MEANINGFUL. > > Ok, I'll fix the commit message. > > As for different trees, I'm afraid you've written something that is _too > useful_ to be used in that manner. > > Git has brought with it a _major_ increase in my productivity because I can > now easily share ~50 branches with 50 different kernel hackers, without > spending all day running rsync. Suddenly my kernel development is a whole > lot more _open_ to the world, with a single "./push". And it's awesome. > > That wasn't possible before with BitKeeper, just due to sheer network > overhead of 50 trees. With BitKeeper, the _only_ thing that kernel hackers > and users could get from me is a mush tree with everything merged into a big > 'ALL' repository. couldn't you just have your multiple 'trees' use the same object repository directory (still a single group of files to push), but still have your trees with different names? it would be just a little more then the copy of the HEAD object (you'd have to change the name in it), but it should be easily scriptable) or is there a limit in git that I'm overlooking that would prohibit this? David Lang From herbert@gondor.apana.org.au Tue May 24 01:12:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 01:13:03 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O8CvF3007879 for ; Tue, 24 May 2005 01:12:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaUW5-0004PN-00; Tue, 24 May 2005 18:11:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaUW2-00089x-00; Tue, 24 May 2005 18:11:54 +1000 Date: Tue, 24 May 2005 18:11:54 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, netdev@oss.sgi.com, kazunori@miyazawa.org Subject: Re: [XFRM] Call dst_check() with appropriate cookie Message-ID: <20050524081154.GA31352@gondor.apana.org.au> References: <20050524.124919.00464304.yoshfuji@linux-ipv6.org> <20050524.163018.29919354.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524.163018.29919354.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 660 Lines: 16 On Tue, May 24, 2005 at 04:30:18PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Honestly speaking, we haven't tracked down deeply where it is, > but that patch is logically reauired and it definetely solves grave > "freeze" issue with ipv6 tunnel mode xfrm. I'm happy with your patch as it is. However, I'd like us to track this freeze down first because if it is caused by another bug then this patch may make it harder to find it. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue May 24 01:21:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 01:21:28 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O8LLF3008570 for ; Tue, 24 May 2005 01:21:22 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaUeF-0004U9-00; Tue, 24 May 2005 18:20:23 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaUeD-0008C2-00; Tue, 24 May 2005 18:20:21 +1000 Date: Tue, 24 May 2005 18:20:21 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM] Call dst_check() with appropriate cookie Message-ID: <20050524082021.GA31446@gondor.apana.org.au> References: <20050524.124919.00464304.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524.124919.00464304.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1225 Lines: 37 On Tue, May 24, 2005 at 03:49:19AM +0000, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > diff -ruN linux-2.6.12-rc4-git7/net/ipv4/xfrm4_policy.c linux-2.6.12-rc4-git7-ipv6ipsec/net/ipv4/xfrm4_policy.c > --- linux-2.6.12-rc4-git7/net/ipv4/xfrm4_policy.c 2005-05-24 00:15:27.000000000 +0900 > +++ linux-2.6.12-rc4-git7-ipv6ipsec/net/ipv4/xfrm4_policy.c 2005-05-24 00:20:29.000000000 +0900 > @@ -95,6 +95,7 @@ > > xdst = (struct xfrm_dst *)dst1; > xdst->route = &rt->u.dst; > + xdst->route_cookie = 0; > > dst1->next = dst_prev; > dst_prev = dst1; > @@ -119,6 +120,7 @@ > > dst_prev->child = &rt->u.dst; > dst->path = &rt->u.dst; > + ((struct xfrm_dst*)dst)->path_cookie = 0; This isn't necessary since dst_alloc zeros the entire xfrm_dst entry. > dst_prev->child = &rt->u.dst; > dst->path = &rt->u.dst; > + ((struct xfrm_dst*)dst)->path_cookie = rt->rt6i_node->fn_sernum; Please add a space between xfrm_dst and the asterisk, i.e. (struct xfrm_dst *)dst Also, can rt6i_node be NULL? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kazunori@miyazawa.org Tue May 24 01:28:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 01:28:23 -0700 (PDT) Received: from miyazawa.org ([221.116.13.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O8SHF3009221 for ; Tue, 24 May 2005 01:28:18 -0700 Received: from [IPv6:2001:240:2:0:209:6bff:fe4d:3a14] ([2001:240:2:0:209:6bff:fe4d:3a14]) (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Tue, 24 May 2005 17:21:18 +0900 id 0000BACE.4292E3FE.00001AAF Message-ID: <4292E53D.7030805@miyazawa.org> Date: Tue, 24 May 2005 17:26:37 +0900 From: Kazunori Miyazawa User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "YOSHIFUJI Hideaki / ????" , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM] Call dst_check() with appropriate cookie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Content-Length: 801 Lines: 32 Hello, Without our patch, the dst_check in xfrm_bundle_ok returns NULL when it is IPv6 route, then xfrm_bundle_ok always fails. xfrm_lookup calls xfrm_bundle_ok via stalbe_bundle so that it goes to restart and recreate bundles. But stale_bundle always fails. It results the infinite loop accordingly. This bug only occurs on IPv6. IPv4 works correctly without the patch. I can not show the evidence of the infinite loop because the kernel freezes :-< Herbert Xu wrote: > YOSHIFUJI Hideaki / ???? wrote: > >>From: Kazunori Miyazawa >> >>[XFRM] Call dst_check() with appropriate cookie. >> >>This fixes infinite loop issue with IPv6 tunnel mode. > > > Can someone please tell me where this infinite loop is? > > Thanks, -- Kazunori Miyazawa From herbert@gondor.apana.org.au Tue May 24 01:35:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 01:35:26 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O8ZJF3009912 for ; Tue, 24 May 2005 01:35:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaUrl-0004cX-00; Tue, 24 May 2005 18:34:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaUrj-0008EE-00; Tue, 24 May 2005 18:34:19 +1000 Date: Tue, 24 May 2005 18:34:19 +1000 To: Kazunori Miyazawa Cc: YOSHIFUJI Hideaki / ???? , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM] Call dst_check() with appropriate cookie Message-ID: <20050524083419.GA31586@gondor.apana.org.au> References: <4292E53D.7030805@miyazawa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4292E53D.7030805@miyazawa.org> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 817 Lines: 20 On Tue, May 24, 2005 at 05:26:37PM +0900, Kazunori Miyazawa wrote: > > Without our patch, the dst_check in xfrm_bundle_ok returns NULL > when it is IPv6 route, then xfrm_bundle_ok always fails. > xfrm_lookup calls xfrm_bundle_ok via stalbe_bundle so that > it goes to restart and recreate bundles. > But stale_bundle always fails. It results the infinite loop accordingly. Yes this makes perfect sense. However, I'd still like to know why I have never seen it myself. Let me double-check my test setup. Anyway, I'm happy with the patch apart from the comments I gave elsewhere in this thread. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Tue May 24 01:47:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 01:47:20 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O8lHF3010789 for ; Tue, 24 May 2005 01:47:17 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 6132F33CC2; Tue, 24 May 2005 17:49:32 +0900 (JST) Date: Tue, 24 May 2005 17:49:31 +0900 (JST) Message-Id: <20050524.174931.46801018.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, kazunori@miyazawa.org Subject: Re: [XFRM] Call dst_check() with appropriate cookie From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050524082021.GA31446@gondor.apana.org.au> References: <20050524.124919.00464304.yoshfuji@linux-ipv6.org> <20050524082021.GA31446@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 2394 Lines: 77 In article <20050524082021.GA31446@gondor.apana.org.au> (at Tue, 24 May 2005 18:20:21 +1000), Herbert Xu says: > Also, can rt6i_node be NULL? Good point. Here's updated patch. ----------------- From: Kazunori Miyazawa [XFRM] Call dst_check() with appropriate cookie This fixes infinite loop issue with IPv6 tunnel mode. Signed-off-by: Kazunori Miyazawa Signed-off-by: Hideaki YOSHIFUJI Index: include/net/xfrm.h =================================================================== --- 5b713315560487f8c288820b17061fe27016c2cc/include/net/xfrm.h (mode:100644) +++ uncommitted/include/net/xfrm.h (mode:100644) @@ -515,6 +515,8 @@ struct dst_entry *route; u32 route_mtu_cached; u32 child_mtu_cached; + u32 route_cookie; + u32 path_cookie; }; static inline void xfrm_dst_destroy(struct xfrm_dst *xdst) Index: net/ipv6/xfrm6_policy.c =================================================================== --- 5b713315560487f8c288820b17061fe27016c2cc/net/ipv6/xfrm6_policy.c (mode:100644) +++ uncommitted/net/ipv6/xfrm6_policy.c (mode:100644) @@ -113,6 +113,8 @@ xdst = (struct xfrm_dst *)dst1; xdst->route = &rt->u.dst; + if (rt->rt6i_node) + xdst->route_cookie = rt->rt6i_node->fn_sernum; dst1->next = dst_prev; dst_prev = dst1; @@ -137,6 +139,8 @@ dst_prev->child = &rt->u.dst; dst->path = &rt->u.dst; + if (rt->rt6i_node) + ((struct xfrm_dst *)dst)->path_cookie = rt->rt6i_node->fn_sernum; *dst_p = dst; dst = dst_prev; Index: net/xfrm/xfrm_policy.c =================================================================== --- 5b713315560487f8c288820b17061fe27016c2cc/net/xfrm/xfrm_policy.c (mode:100644) +++ uncommitted/net/xfrm/xfrm_policy.c (mode:100644) @@ -1136,7 +1136,7 @@ struct xfrm_dst *last; u32 mtu; - if (!dst_check(dst->path, 0) || + if (!dst_check(dst->path, ((struct xfrm_dst *)dst)->path_cookie) || (dst->dev && !netif_running(dst->dev))) return 0; @@ -1156,7 +1156,7 @@ xdst->child_mtu_cached = mtu; } - if (!dst_check(xdst->route, 0)) + if (!dst_check(xdst->route, xdst->route_cookie)) return 0; mtu = dst_mtu(xdst->route); if (xdst->route_mtu_cached != mtu) { -- YOSHIFUJI Hideaki @ USAGI Project GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From pravins@calsoftinc.com Tue May 24 02:56:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 02:56:26 -0700 (PDT) Received: from ganesha.intranet.calsoftinc.com ([220.225.34.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O9uKlG021080 for ; Tue, 24 May 2005 02:56:21 -0700 Received: from [172.16.0.108] (unknown [172.16.0.108]) by ganesha.intranet.calsoftinc.com (Postfix) with ESMTP id DA373DB58D; Tue, 24 May 2005 15:18:05 +0530 (IST) Message-ID: <4292FA7C.80308@calsoftinc.com> Date: Tue, 24 May 2005 15:27:16 +0530 From: pravin b shelar User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH] : bug fix in multipath drr code. References: <4291CBFF.6080106@calsoftinc.com> <20050523232224.GA25349@gondor.apana.org.au> <4292CDCE.2090600@calsoftinc.com> <20050524071146.GA30995@gondor.apana.org.au> In-Reply-To: <20050524071146.GA30995@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------090501030509050709090905" X-archive-position: 1575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pravins@calsoftinc.com Precedence: bulk X-list: netdev Content-Length: 4332 Lines: 158 This is a multi-part message in MIME format. --------------090501030509050709090905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: >On Tue, May 24, 2005 at 12:16:38PM +0530, pravin b shelar wrote: > > >In fact this whole MULTIPATHOLDROUTE thing can't possibly >work at all. I'd suggest that it be removed. > > So I think we should ignore MULTIPATHOLDROUTE flag in drr and rr multipath algorithms as done in random multipath algorithm. Attached patch does same thing. Regards, Pravin. --------------090501030509050709090905 Content-Type: text/x-patch; name="multipath-drr_rr-last_use-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="multipath-drr_rr-last_use-fix.patch" Signed-off by: Pravin B. Shelar Index: linux-2.6.12-rc4/include/net/route.h =================================================================== --- linux-2.6.12-rc4.orig/include/net/route.h 2005-05-06 22:20:31.000000000 -0700 +++ linux-2.6.12-rc4/include/net/route.h 2005-05-24 02:37:10.000000000 -0700 @@ -181,9 +181,6 @@ memcpy(&fl, &(*rp)->fl, sizeof(fl)); fl.fl_ip_sport = sport; fl.fl_ip_dport = dport; -#if defined(CONFIG_IP_ROUTE_MULTIPATH_CACHED) - fl.flags |= FLOWI_FLAG_MULTIPATHOLDROUTE; -#endif ip_rt_put(*rp); *rp = NULL; return ip_route_output_flow(rp, &fl, sk, 0); Index: linux-2.6.12-rc4/net/ipv4/multipath_drr.c =================================================================== --- linux-2.6.12-rc4.orig/net/ipv4/multipath_drr.c 2005-05-06 22:20:31.000000000 -0700 +++ linux-2.6.12-rc4/net/ipv4/multipath_drr.c 2005-05-24 02:37:10.000000000 -0700 @@ -57,7 +57,6 @@ static struct multipath_device state[MULTIPATH_MAX_DEVICECANDIDATES]; static DEFINE_SPINLOCK(state_lock); -static struct rtable *last_selection = NULL; static int inline __multipath_findslot(void) { @@ -111,11 +110,6 @@ .notifier_call = drr_dev_event, }; -static void drr_remove(struct rtable *rt) -{ - if (last_selection == rt) - last_selection = NULL; -} static void drr_safe_inc(atomic_t *usecount) { @@ -144,14 +138,6 @@ int devidx = -1; int cur_min_devidx = -1; - /* if necessary and possible utilize the old alternative */ - if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 && - last_selection != NULL) { - result = last_selection; - *rp = result; - return; - } - /* 1. make sure all alt. nexthops have the same GC related data */ /* 2. determine the new candidate to be returned */ result = NULL; @@ -229,12 +215,10 @@ } *rp = result; - last_selection = result; } static struct ip_mp_alg_ops drr_ops = { .mp_alg_select_route = drr_select_route, - .mp_alg_remove = drr_remove, }; static int __init drr_init(void) @@ -244,7 +228,7 @@ if (err) return err; - err = multipath_alg_register(&drr_ops, IP_MP_ALG_RR); + err = multipath_alg_register(&drr_ops, IP_MP_ALG_DRR); if (err) goto fail; Index: linux-2.6.12-rc4/net/ipv4/multipath_rr.c =================================================================== --- linux-2.6.12-rc4.orig/net/ipv4/multipath_rr.c 2005-05-06 22:20:31.000000000 -0700 +++ linux-2.6.12-rc4/net/ipv4/multipath_rr.c 2005-05-24 02:37:10.000000000 -0700 @@ -47,29 +47,12 @@ #include #include -#define MULTIPATH_MAX_CANDIDATES 40 - -static struct rtable* last_used = NULL; - -static void rr_remove(struct rtable *rt) -{ - if (last_used == rt) - last_used = NULL; -} - static void rr_select_route(const struct flowi *flp, struct rtable *first, struct rtable **rp) { struct rtable *nh, *result, *min_use_cand = NULL; int min_use = -1; - /* if necessary and possible utilize the old alternative */ - if ((flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE) != 0 && - last_used != NULL) { - result = last_used; - goto out; - } - /* 1. make sure all alt. nexthops have the same GC related data * 2. determine the new candidate to be returned */ @@ -90,15 +73,12 @@ if (!result) result = first; -out: - last_used = result; result->u.dst.__use++; *rp = result; } static struct ip_mp_alg_ops rr_ops = { .mp_alg_select_route = rr_select_route, - .mp_alg_remove = rr_remove, }; static int __init rr_init(void) --------------090501030509050709090905-- From herbert@gondor.apana.org.au Tue May 24 05:00:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 05:00:21 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OC0FXq006143 for ; Tue, 24 May 2005 05:00:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaY46-0006Or-00; Tue, 24 May 2005 21:59:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaY43-0003Tz-00; Tue, 24 May 2005 21:59:15 +1000 Date: Tue, 24 May 2005 21:59:14 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, netdev@oss.sgi.com, kazunori@miyazawa.org Subject: Re: [XFRM] Call dst_check() with appropriate cookie Message-ID: <20050524115914.GA697@gondor.apana.org.au> References: <20050524.124919.00464304.yoshfuji@linux-ipv6.org> <20050524082021.GA31446@gondor.apana.org.au> <20050524.174931.46801018.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524.174931.46801018.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 591 Lines: 17 On Tue, May 24, 2005 at 05:49:31PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > [XFRM] Call dst_check() with appropriate cookie > > This fixes infinite loop issue with IPv6 tunnel mode. > > Signed-off-by: Kazunori Miyazawa > Signed-off-by: Hideaki YOSHIFUJI Looks good. Acked-by: Herbert Xu -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hpayer@cosy.sbg.ac.at Tue May 24 05:12:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 05:12:41 -0700 (PDT) Received: from dobermann.cosy.sbg.ac.at (dobermann.cosy.sbg.ac.at [141.201.2.56]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OCCZXq015990 for ; Tue, 24 May 2005 05:12:36 -0700 Received: by dobermann.cosy.sbg.ac.at (Postfix, from userid 102) id 20B70F8B9B; Tue, 24 May 2005 14:12:42 +0200 (CEST) Received: from drache.cosy.sbg.ac.at (drache.cosy.sbg.ac.at [141.201.150.46]) by dobermann.cosy.sbg.ac.at (Postfix) with ESMTP id 04007F8D3F for ; Tue, 24 May 2005 14:12:37 +0200 (CEST) Date: Tue, 24 May 2005 14:11:45 +0200 (CEST) From: Hannes Payer To: netdev@oss.sgi.com Subject: linux ipv6 multicast kernel implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hpayer@cosy.sbg.ac.at Precedence: bulk X-list: netdev Content-Length: 1888 Lines: 38 Dear oss team, last week i tryed to ask Alan Cox something about the data link layer imlplementation in the linux kernel. He gave me your email address and therefore i forward you this email and hope, that you can help me. forwarded message: Dear Alan Cox, we are trying to get ipv6 protocol independent multicast working on linux routers. We used the ipv6 multicast forwarding patch and the pim6sd daemon of Michael Hoerdt (http://clarinet.u-strasbg.fr/~hoerdt/linux_ipv6_mforwarding/, http://clarinet.u-strasbg.fr/~hoerdt/pim6sd_linux/). The ipv6 multicast kernel implementation is based on the existing ipv4 code and therefore we thought that you are the right contact person :-) The ipv6 patch does not work well and we already found some bugs, we were able to correct. We are not sure about one problem: When the kernel receives a pim register packet, it decapsulates the packet and loops the multicast packet back on the register interface (netif_rx(skb) in pim6_rcv() pim6.c). Before the packet is looped back, the kernel sets skb->dst = NULL; Therefore in ip6_input.c ip6_rcv_finish() looks up the unicast routing table and gets a matching entry. After that the kernel tries to forward the multicast packet, but stops at ip6_mr_forward() in ip6mr.c. The comparison vif6_table[vif].dev != skb->dev is true und therefore the packet is droped. (The lookup always returns dubios interfaces. It should return in our case the registry interface) Our question: Why should we lookup the unicast routing table in this case? Would it satisfy to look up the multicast forwarding cache, where a correct entry exists - created by the pim6sd daemon? Would it be a problem if we override the lookup result with the regvif device after the lookup in this case? I hope you understand the explanation of our problem. Thank you for your answer. Yours faithfully, Hannes Payer From mateuszb@gmail.com Tue May 24 05:36:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 05:36:53 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OCamXq017596 for ; Tue, 24 May 2005 05:36:49 -0700 Received: by wproxy.gmail.com with SMTP id 68so2598543wri for ; Tue, 24 May 2005 05:36:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=mAVDtfpMkUjqpex1RyA3i39n1gW58Z1vjqyJ+qclyvEfOQuktNx+/zhizvdQjW1Hb9wN8oFhECKBXNFhxV01sAMYOMVjN6LVGYRABfWrJL0YQBtU3djwoT6P0oFCIBFHk+zAIb6tfReTmkglp+KHNs3XO3yVaqyCvv7nOdy5ld8= Received: by 10.54.26.68 with SMTP id 68mr3158281wrz; Tue, 24 May 2005 05:36:01 -0700 (PDT) Received: from ?156.17.7.205? ([156.17.7.205]) by mx.gmail.com with ESMTP id 38sm155275wrl.2005.05.24.05.36.01; Tue, 24 May 2005 05:36:01 -0700 (PDT) Message-ID: <42932061.5050109@gmail.com> Date: Tue, 24 May 2005 14:38:57 +0200 From: Mateusz Berezecki User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050509) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev Subject: ieee80211.h and DSSS PHY type Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-archive-position: 1578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mateuszb@gmail.com Precedence: bulk X-list: netdev Content-Length: 488 Lines: 18 Hi list members, I got a quick question regarding modulation type defines in ieee80211.h in netdev tree ieee80211 branch from current netdev git tree. Isn't the #define IEEE80211_DSSS_MODULATION missing in the include file? or am I plain wrong? Im asking because atheros driver im writing is using some constant value which needs some name;) And after evaluating some IEEE pdf's this appears to be a DSSS PHY type and numeric constants do not look good in source code. regards /mb From herbert@gondor.apana.org.au Tue May 24 05:51:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 05:51:37 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OCpQXq018520 for ; Tue, 24 May 2005 05:51:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaYre-0006nz-00; Tue, 24 May 2005 22:50:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaYrc-00076H-00; Tue, 24 May 2005 22:50:28 +1000 Date: Tue, 24 May 2005 22:50:28 +1000 To: Kazunori Miyazawa Cc: YOSHIFUJI Hideaki / ???? , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM] Call dst_check() with appropriate cookie Message-ID: <20050524125028.GA27278@gondor.apana.org.au> References: <4292E53D.7030805@miyazawa.org> <20050524083419.GA31586@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524083419.GA31586@gondor.apana.org.au> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 508 Lines: 12 On Tue, May 24, 2005 at 06:34:19PM +1000, herbert wrote: > > Yes this makes perfect sense. However, I'd still like to know why I > have never seen it myself. Let me double-check my test setup. Aha, not all IPv6 dst entries have obsolete set to -1. Obviously your ones were and mine weren't :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue May 24 05:55:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 05:55:11 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OCt6Xq019104 for ; Tue, 24 May 2005 05:55:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DaYvB-0006rp-00; Tue, 24 May 2005 22:54:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DaYvA-000773-00; Tue, 24 May 2005 22:54:08 +1000 Date: Tue, 24 May 2005 22:54:08 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: kazunori@miyazawa.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM] Call dst_check() with appropriate cookie Message-ID: <20050524125408.GA27317@gondor.apana.org.au> References: <4292E53D.7030805@miyazawa.org> <20050524.174234.00553944.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524.174234.00553944.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 848 Lines: 21 On Tue, May 24, 2005 at 05:42:34PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Probably, it should be better to introduce some upper limit of number of > recreation. Yep, that's why a simple packet blackhole bug became a kernel hang. In fact, we don't need to retry at all. If the policy goes dead on us or if the route becomes invalid after we passed the check in xfrm_lookup, the packet is dropped anyway. There is no point in retrying the lookup here since that only covers the cases where we detect the problem before the bundle is inserted into the list. So we should simply return an error instead of retrying. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jbenc@suse.cz Tue May 24 06:11:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:11:07 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODB3Xq020466 for ; Tue, 24 May 2005 06:11:04 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id C775F628302; Tue, 24 May 2005 15:10:18 +0200 (CEST) Date: Tue, 24 May 2005 15:10:18 +0200 From: Jiri Benc To: NetDev Cc: LKML , jgarzik@pobox.com, pavel@suse.cz Subject: [1/5] ieee80211: cleanup Message-ID: <20050524151018.3304fbeb@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 3126 Lines: 128 Cleanup of unused and duplicated constants and structures in the ieee80211 header. Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac --- orig/include/net/ieee80211.h 2005-05-12 11:36:27.000000000 +0200 +++ new/include/net/ieee80211.h 2005-05-17 15:37:38.000000000 +0200 @@ -93,6 +93,8 @@ u16 length; } __attribute__ ((packed)); +#define IEEE80211_1ADDR_LEN 10 +#define IEEE80211_2ADDR_LEN 16 #define IEEE80211_3ADDR_LEN 24 #define IEEE80211_4ADDR_LEN 30 #define IEEE80211_FCS_LEN 4 @@ -299,23 +301,6 @@ #define WLAN_REASON_STA_REQ_ASSOC_WITHOUT_AUTH 9 -/* Information Element IDs */ -#define WLAN_EID_SSID 0 -#define WLAN_EID_SUPP_RATES 1 -#define WLAN_EID_FH_PARAMS 2 -#define WLAN_EID_DS_PARAMS 3 -#define WLAN_EID_CF_PARAMS 4 -#define WLAN_EID_TIM 5 -#define WLAN_EID_IBSS_PARAMS 6 -#define WLAN_EID_CHALLENGE 16 -#define WLAN_EID_RSN 48 -#define WLAN_EID_GENERIC 221 - -#define IEEE80211_MGMT_HDR_LEN 24 -#define IEEE80211_DATA_HDR3_LEN 24 -#define IEEE80211_DATA_HDR4_LEN 30 - - #define IEEE80211_STATMASK_SIGNAL (1<<0) #define IEEE80211_STATMASK_RSSI (1<<1) #define IEEE80211_STATMASK_NOISE (1<<2) @@ -489,15 +474,6 @@ */ -struct ieee80211_header_data { - u16 frame_ctl; - u16 duration_id; - u8 addr1[6]; - u8 addr2[6]; - u8 addr3[6]; - u16 seq_ctrl; -}; - #define BEACON_PROBE_SSID_ID_POSITION 12 /* Management Frame Information Element Types */ @@ -542,7 +518,7 @@ */ struct ieee80211_authentication { - struct ieee80211_header_data header; + struct ieee80211_hdr_3addr header; u16 algorithm; u16 transaction; u16 status; @@ -551,7 +527,7 @@ struct ieee80211_probe_response { - struct ieee80211_header_data header; + struct ieee80211_hdr_3addr header; u32 time_stamp[2]; u16 beacon_interval; u16 capability; @@ -793,21 +769,21 @@ extern inline int ieee80211_get_hdrlen(u16 fc) { - int hdrlen = 24; + int hdrlen = IEEE80211_3ADDR_LEN; switch (WLAN_FC_GET_TYPE(fc)) { case IEEE80211_FTYPE_DATA: if ((fc & IEEE80211_FCTL_FROMDS) && (fc & IEEE80211_FCTL_TODS)) - hdrlen = 30; /* Addr4 */ + hdrlen = IEEE80211_4ADDR_LEN; break; case IEEE80211_FTYPE_CTL: switch (WLAN_FC_GET_STYPE(fc)) { case IEEE80211_STYPE_CTS: case IEEE80211_STYPE_ACK: - hdrlen = 10; + hdrlen = IEEE80211_1ADDR_LEN; break; default: - hdrlen = 16; + hdrlen = IEEE80211_2ADDR_LEN; break; } break; --- orig/net/ieee80211/ieee80211_rx.c 2005-05-12 11:36:29.000000000 +0200 +++ new/net/ieee80211/ieee80211_rx.c 2005-05-17 15:37:38.000000000 +0200 @@ -475,7 +475,7 @@ #endif /* Data frame - extract src/dst addresses */ - if (skb->len < IEEE80211_DATA_HDR3_LEN) + if (skb->len < IEEE80211_3ADDR_LEN) goto rx_dropped; switch (fc & (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { @@ -488,7 +488,7 @@ memcpy(src, hdr->addr2, ETH_ALEN); break; case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: - if (skb->len < IEEE80211_DATA_HDR4_LEN) + if (skb->len < IEEE80211_4ADDR_LEN) goto rx_dropped; memcpy(dst, hdr->addr3, ETH_ALEN); memcpy(src, hdr->addr4, ETH_ALEN); -- Jiri Benc SUSE Labs From jbenc@suse.cz Tue May 24 06:08:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:08:39 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OD8XXq020182 for ; Tue, 24 May 2005 06:08:33 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id BE4756282FC; Tue, 24 May 2005 15:07:43 +0200 (CEST) Date: Tue, 24 May 2005 15:07:11 +0200 From: Jiri Benc To: NetDev Cc: LKML , jgarzik@pobox.com, pavel@suse.cz Subject: [0/5] Improvements to the ieee80211 layer Message-ID: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 1483 Lines: 33 The ieee80211 layer, now present in -mm, lacks many important features (actually it's just a part of the ipw2100/ipw2200 driver; these cards do a lot of the processing in the hardware/firmware and thus the layer currently can not be used for simpler devices). This is the first series of patches that try to convert it to a generic IEEE 802.11 layer, usable for most of today's wireless cards. The long term plan is: - to implement a complete 802.11 stack in the kernel, making it easy to write drivers for simple (cheap) devices - to implement all of Ad-Hoc, AP and monitor modes in the layer, so it will be easy to support them in the drivers - to integrate Wireless Extensions to unify the kernel-userspace interface of all the drivers This means that drivers for "stupid" (simple, cheap) cards should be very short and easy to write, whereas drivers for "clever" cards will be longer (but still shorter than they are now). We have a couple of cards for testing, and we gradually modify the drivers for ipw2100 and ipw2200 with the development of the layer. When the layer is mature enough for the "stupid" cards, we will rewrite the driver for Atheros-based cards to use this layer. We plan to send all the patches for these drivers to the netdev list. Of course, we are in close contact with Pavel Machek, who is pushing the ipw2100 driver upstream. Any comments and suggestions are appreciated. Jiri Benc and Jirka Bohac SUSE Labs From jbenc@suse.cz Tue May 24 06:12:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:12:12 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODC2Xq020714 for ; Tue, 24 May 2005 06:12:02 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 3F15A6282FC; Tue, 24 May 2005 15:11:17 +0200 (CEST) Date: Tue, 24 May 2005 15:11:17 +0200 From: Jiri Benc To: NetDev Cc: LKML , jgarzik@pobox.com, pavel@suse.cz Subject: [2/5] ieee80211: ieee80211_device alignment fix and cleanup Message-ID: <20050524151117.5e059d1d@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 8951 Lines: 291 Changes to the ieee80211 layer: - fixes a serious alignment problem of the driver's private data - makes the drivers use the ieee80211_device instead of the net_device where appropriate (will ease further development of ieee80211 as a self-contained layer) Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac --- linux-2.6.12-rc2-mm3.01/include/net/ieee80211.h 2005-05-18 10:49:01.000000000 +0200 +++ linux-2.6.12-rc2-mm3.02.0/include/net/ieee80211.h 2005-05-18 12:02:03.000000000 +0200 @@ -704,15 +704,13 @@ int abg_ture; /* ABG flag */ /* Callback functions */ - void (*set_security)(struct net_device *dev, + void (*set_security)(struct ieee80211_device *ieee, struct ieee80211_security *sec); int (*hard_start_xmit)(struct ieee80211_txb *txb, - struct net_device *dev); - int (*reset_port)(struct net_device *dev); + struct ieee80211_device *ieee); + int (*reset_port)(struct ieee80211_device *ieee); - /* This must be the last item so that it points to the data - * allocated beyond this structure by alloc_ieee80211 */ - u8 priv[0]; + void *priv; }; #define IEEE_A (1<<0) @@ -720,9 +718,18 @@ #define IEEE_G (1<<2) #define IEEE_MODE_MASK (IEEE_A|IEEE_B|IEEE_G) -extern inline void *ieee80211_priv(struct net_device *dev) +static inline void *ieee80211_priv(struct ieee80211_device *ieee) { - return ((struct ieee80211_device *)netdev_priv(dev))->priv; + return (char *)ieee + + ((sizeof(struct ieee80211_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST); +} + +static inline struct net_device *ieee80211_dev(struct ieee80211_device *ieee) +{ + return (struct net_device *)((char *)ieee - + ((sizeof(struct net_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST)); } extern inline int ieee80211_is_empty_essid(const char *essid, int essid_len) @@ -795,8 +802,8 @@ /* ieee80211.c */ -extern void free_ieee80211(struct net_device *dev); -extern struct net_device *alloc_ieee80211(int sizeof_priv); +extern void free_ieee80211(struct ieee80211_device *ieee); +extern struct ieee80211_device *alloc_ieee80211(int sizeof_priv); extern int ieee80211_set_encryption(struct ieee80211_device *ieee); --- linux-2.6.12-rc2-mm3.01/net/ieee80211/ieee80211_module.c 2005-04-19 17:04:43.000000000 +0200 +++ linux-2.6.12-rc2-mm3.02.0/net/ieee80211/ieee80211_module.c 2005-05-18 12:04:30.000000000 +0200 @@ -70,7 +70,7 @@ GFP_KERNEL); if (!ieee->networks) { printk(KERN_WARNING "%s: Out of memory allocating beacons\n", - ieee->dev->name); + ieee80211_dev(ieee)->name); return -ENOMEM; } @@ -99,23 +99,28 @@ } -struct net_device *alloc_ieee80211(int sizeof_priv) +struct ieee80211_device *alloc_ieee80211(int sizeof_priv) { struct ieee80211_device *ieee; struct net_device *dev; + int alloc_size; int err; IEEE80211_DEBUG_INFO("Initializing...\n"); - dev = alloc_etherdev(sizeof(struct ieee80211_device) + sizeof_priv); + alloc_size = ((sizeof(struct ieee80211_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST) + + sizeof_priv; + dev = alloc_etherdev(alloc_size); if (!dev) { IEEE80211_ERROR("Unable to network device.\n"); goto failed; } ieee = netdev_priv(dev); - dev->hard_start_xmit = ieee80211_xmit; - ieee->dev = dev; + ieee->priv = ieee80211_priv(ieee); + + dev->hard_start_xmit = ieee80211_xmit; err = ieee80211_networks_allocate(ieee); if (err) { @@ -148,7 +153,7 @@ ieee->privacy_invoked = 0; ieee->ieee802_1x = 1; - return dev; + return ieee; failed: if (dev) @@ -157,10 +162,8 @@ } -void free_ieee80211(struct net_device *dev) +void free_ieee80211(struct ieee80211_device *ieee) { - struct ieee80211_device *ieee = netdev_priv(dev); - int i; del_timer_sync(&ieee->crypt_deinit_timer); @@ -179,7 +182,7 @@ } ieee80211_networks_free(ieee); - free_netdev(dev); + free_netdev(ieee80211_dev(ieee)); } #ifdef CONFIG_IEEE80211_DEBUG --- linux-2.6.12-rc2-mm3.01/net/ieee80211/ieee80211_rx.c 2005-05-18 10:49:01.000000000 +0200 +++ linux-2.6.12-rc2-mm3.02.0/net/ieee80211/ieee80211_rx.c 2005-05-18 12:24:18.000000000 +0200 @@ -100,7 +100,7 @@ if (frag == 0) { /* Reserve enough space to fit maximum frame length */ - skb = dev_alloc_skb(ieee->dev->mtu + + skb = dev_alloc_skb(ieee80211_dev(ieee)->mtu + sizeof(struct ieee80211_hdr) + 8 /* LLC */ + 2 /* alignment */ + @@ -176,7 +176,7 @@ { if (ieee->iw_mode == IW_MODE_MASTER) { printk(KERN_DEBUG "%s: Master mode not yet suppported.\n", - ieee->dev->name); + ieee80211_dev(ieee)->name); return 0; /* hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr *) @@ -234,7 +234,7 @@ static int ieee80211_is_eapol_frame(struct ieee80211_device *ieee, struct sk_buff *skb) { - struct net_device *dev = ieee->dev; + struct net_device *dev = ieee80211_dev(ieee); u16 fc, ethertype; struct ieee80211_hdr *hdr; u8 *pos; @@ -290,7 +290,7 @@ if (net_ratelimit()) { printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " "received packet from " MAC_FMT "\n", - ieee->dev->name, MAC_ARG(hdr->addr2)); + ieee80211_dev(dev)->name, MAC_ARG(hdr->addr2)); } return -1; } @@ -335,7 +335,7 @@ if (res < 0) { printk(KERN_DEBUG "%s: MSDU decryption/MIC verification failed" " (SA=" MAC_FMT " keyidx=%d)\n", - ieee->dev->name, MAC_ARG(hdr->addr2), keyidx); + ieee80211_dev(ieee)->name, MAC_ARG(hdr->addr2), keyidx); return -1; } @@ -349,7 +349,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb, struct ieee80211_rx_stats *rx_stats) { - struct net_device *dev = ieee->dev; + struct net_device *dev = ieee80211_dev(ieee); struct ieee80211_hdr *hdr; size_t hdrlen; u16 fc, type, stype, sc; @@ -1195,7 +1195,7 @@ IEEE80211_DEBUG_MGMT("received UNKNOWN (%d)\n", WLAN_FC_GET_STYPE(header->frame_ctl)); IEEE80211_WARNING("%s: Unknown management packet: %d\n", - ieee->dev->name, + ieee80211_dev(ieee)->name, WLAN_FC_GET_STYPE(header->frame_ctl)); break; } --- linux-2.6.12-rc2-mm3.01/net/ieee80211/ieee80211_tx.c 2005-04-19 17:04:43.000000000 +0200 +++ linux-2.6.12-rc2-mm3.02.0/net/ieee80211/ieee80211_tx.c 2005-05-18 12:20:07.000000000 +0200 @@ -172,7 +172,7 @@ if (net_ratelimit()) { printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " "TX packet to " MAC_FMT "\n", - ieee->dev->name, MAC_ARG(header->addr1)); + ieee80211_dev(ieee)->name, MAC_ARG(header->addr1)); } return -1; } @@ -193,7 +193,7 @@ atomic_dec(&crypt->refcnt); if (res < 0) { printk(KERN_INFO "%s: Encryption failed: len=%d.\n", - ieee->dev->name, frag->len); + ieee80211_dev(ieee)->name, frag->len); ieee->ieee_stats.tx_discards++; return -1; } @@ -270,13 +270,13 @@ * creating it... */ if (!ieee->hard_start_xmit) { printk(KERN_WARNING "%s: No xmit handler.\n", - ieee->dev->name); + dev->name); goto success; } if (unlikely(skb->len < SNAP_SIZE + sizeof(u16))) { printk(KERN_WARNING "%s: skb too small (%d).\n", - ieee->dev->name, skb->len); + dev->name, skb->len); goto success; } @@ -372,7 +372,7 @@ txb = ieee80211_alloc_txb(nr_frags, frag_size, GFP_ATOMIC); if (unlikely(!txb)) { printk(KERN_WARNING "%s: Could not allocate TXB\n", - ieee->dev->name); + dev->name); goto failed; } txb->encrypted = encrypt; @@ -427,7 +427,7 @@ dev_kfree_skb_any(skb); if (txb) { - if ((*ieee->hard_start_xmit)(txb, dev) == 0) { + if ((*ieee->hard_start_xmit)(txb, ieee) == 0) { stats->tx_packets++; stats->tx_bytes += txb->payload_size; return 0; --- linux-2.6.12-rc2-mm3.01/net/ieee80211/ieee80211_wx.c 2005-04-19 17:04:43.000000000 +0200 +++ linux-2.6.12-rc2-mm3.02.0/net/ieee80211/ieee80211_wx.c 2005-05-18 12:27:28.000000000 +0200 @@ -252,7 +252,7 @@ union iwreq_data *wrqu, char *keybuf) { struct iw_point *erq = &(wrqu->encoding); - struct net_device *dev = ieee->dev; + struct net_device *dev = ieee80211_dev(ieee); struct ieee80211_security sec = { .flags = 0 }; @@ -402,7 +402,7 @@ sec.level = SEC_LEVEL_1; /* 40 and 104 bit WEP */ if (ieee->set_security) - ieee->set_security(dev, &sec); + ieee->set_security(ieee, &sec); /* Do not reset port if card is in Managed mode since resetting will * generate new IEEE 802.11 authentication which may end up in looping @@ -411,7 +411,7 @@ * the callbacks structures used to initialize the 802.11 stack. */ if (ieee->reset_on_keychange && ieee->iw_mode != IW_MODE_INFRA && - ieee->reset_port && ieee->reset_port(dev)) { + ieee->reset_port && ieee->reset_port(ieee)) { printk(KERN_DEBUG "%s: reset_port failed\n", dev->name); return -EINVAL; } -- Jiri Benc SUSE Labs From jbenc@suse.cz Tue May 24 06:12:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:12:55 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODCnXq021094 for ; Tue, 24 May 2005 06:12:52 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id C0A5A6282FC; Tue, 24 May 2005 15:12:04 +0200 (CEST) Date: Tue, 24 May 2005 15:12:04 +0200 From: Jiri Benc To: NetDev Cc: LKML , jgarzik@pobox.com, pavel@suse.cz Subject: [3/5] netdev: HH_DATA_OFF bugfix Message-ID: <20050524151204.554f73cb@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 666 Lines: 21 When the hardware header size is a multiple of HH_DATA_MOD, HH_DATA_OFF() incorrectly returns HH_DATA_MOD (instead of 0). Signed-off-by: Jiri Benc --- linux/include/linux/netdevice.h +++ work/include/linux/netdevice.h @@ -204,7 +209,7 @@ /* cached hardware header; allow for machine alignment needs. */ #define HH_DATA_MOD 16 #define HH_DATA_OFF(__len) \ - (HH_DATA_MOD - ((__len) & (HH_DATA_MOD - 1))) + (HH_DATA_MOD - (((__len - 1) & (HH_DATA_MOD - 1)) + 1)) #define HH_DATA_ALIGN(__len) \ (((__len)+(HH_DATA_MOD-1))&~(HH_DATA_MOD - 1)) unsigned long hh_data[HH_DATA_ALIGN(LL_MAX_HEADER) / sizeof(long)]; -- Jiri Benc SUSE Labs From jbenc@suse.cz Tue May 24 06:13:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:13:46 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODDeXq021495 for ; Tue, 24 May 2005 06:13:41 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 90E92628302; Tue, 24 May 2005 15:12:55 +0200 (CEST) Date: Tue, 24 May 2005 15:12:55 +0200 From: Jiri Benc To: NetDev Cc: LKML , jgarzik@pobox.com, pavel@suse.cz Subject: [4/5] ieee80211: ethernet independency Message-ID: <20050524151255.6454a8c6@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 34845 Lines: 1134 Makes the 802.11 layer independent of ethernet. (The previous implementation had the ethernet headers built by the ethernet layer and then parsed them and rebuilt them into 802.11 headers.) Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -83,13 +83,18 @@ * used. */ -#if !defined(CONFIG_AX25) && !defined(CONFIG_AX25_MODULE) && !defined(CONFIG_TR) +#if !defined(CONFIG_AX25) && !defined(CONFIG_AX25_MODULE) && !defined(CONFIG_TR) \ + && !defined(CONFIG_IEEE80211) #define LL_MAX_HEADER 32 #else #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) #define LL_MAX_HEADER 96 #else +#if defined(CONFIG_TR) #define LL_MAX_HEADER 48 +#else +#define LL_MAX_HEADER 38 +#endif #endif #endif --- a/include/net/ieee80211.h +++ b/include/net/ieee80211.h @@ -20,7 +20,6 @@ */ #ifndef IEEE80211_H #define IEEE80211_H -#include /* ETH_ALEN */ #include /* ARRAY_SIZE */ #if WIRELESS_EXT < 17 @@ -42,25 +41,26 @@ WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */ +#define IEEE80211_ALEN 6 #define IEEE80211_HLEN 30 #define IEEE80211_FRAME_LEN (IEEE80211_DATA_LEN + IEEE80211_HLEN) struct ieee80211_hdr { u16 frame_ctl; u16 duration_id; - u8 addr1[ETH_ALEN]; - u8 addr2[ETH_ALEN]; - u8 addr3[ETH_ALEN]; + u8 addr1[IEEE80211_ALEN]; + u8 addr2[IEEE80211_ALEN]; + u8 addr3[IEEE80211_ALEN]; u16 seq_ctl; - u8 addr4[ETH_ALEN]; + u8 addr4[IEEE80211_ALEN]; } __attribute__ ((packed)); struct ieee80211_hdr_3addr { u16 frame_ctl; u16 duration_id; - u8 addr1[ETH_ALEN]; - u8 addr2[ETH_ALEN]; - u8 addr3[ETH_ALEN]; + u8 addr1[IEEE80211_ALEN]; + u8 addr2[IEEE80211_ALEN]; + u8 addr3[IEEE80211_ALEN]; u16 seq_ctl; } __attribute__ ((packed)); @@ -233,7 +233,7 @@ #define ETH_P_PREAUTH 0x88C7 /* IEEE 802.11i pre-authentication */ #ifndef ETH_P_80211_RAW -#define ETH_P_80211_RAW (ETH_P_ECONET + 1) +#define ETH_P_80211_RAW 0x0003 #endif /* IEEE 802.11 defines */ @@ -246,11 +246,29 @@ u8 ssap; /* always 0xAA */ u8 ctrl; /* always 0x03 */ u8 oui[P80211_OUI_LEN]; /* organizational universal id */ + u16 type; /* packet type ID field */ } __attribute__ ((packed)); #define SNAP_SIZE sizeof(struct ieee80211_snap_hdr) +#define IEEE80211_SNAP_IS_RFC1042(snap) \ + ((snap)->oui[0] == 0 && (snap)->oui[1] == 0 && (snap)->oui[2] == 0) +#define IEEE80211_SNAP_IS_BRIDGE_TUNNEL(snap) \ + ((snap)->oui[0] == 0 && (snap)->oui[1] == 0 && (snap)->oui[2] == 0xf8) + +#define IEEE80211_FC_GET_TODS(hdr) \ + ((hdr)->frame_ctl & __constant_cpu_to_le16(IEEE80211_FCTL_TODS)) +#define IEEE80211_FC_GET_FROMDS(hdr) \ + ((hdr)->frame_ctl & __constant_cpu_to_le16(IEEE80211_FCTL_FROMDS)) +#define IEEE80211_GET_DADDR(hdr) \ + (IEEE80211_FC_GET_TODS(hdr) ? (hdr)->addr3 : (hdr)->addr1) +#define IEEE80211_GET_SADDR(hdr) \ + (IEEE80211_FC_GET_FROMDS(hdr) ? \ + (IEEE80211_FC_GET_TODS(hdr) ? (hdr)->addr4 : (hdr)->addr3) \ + : (hdr)->addr2) +/* IEEE80211_GET_xADDR do not work when both TODS and FROMDS are set. */ + #define WLAN_FC_GET_TYPE(fc) ((fc) & IEEE80211_FCTL_FTYPE) #define WLAN_FC_GET_STYPE(fc) ((fc) & IEEE80211_FCTL_STYPE) @@ -395,8 +413,8 @@ unsigned int seq; unsigned int last_frag; struct sk_buff *skb; - u8 src_addr[ETH_ALEN]; - u8 dst_addr[ETH_ALEN]; + u8 src_addr[IEEE80211_ALEN]; + u8 dst_addr[IEEE80211_ALEN]; }; struct ieee80211_stats { @@ -507,7 +525,7 @@ u16 auth_sequence; u16 beacon_interval; u16 capability; - u8 current_ap[ETH_ALEN]; + u8 current_ap[IEEE80211_ALEN]; u16 listen_interval; struct { u16 association_id:14, reserved:2; @@ -537,7 +555,7 @@ struct ieee80211_assoc_request_frame { u16 capability; u16 listen_interval; - u8 current_ap[ETH_ALEN]; + u8 current_ap[IEEE80211_ALEN]; struct ieee80211_info_element info_element; } __attribute__ ((packed)); @@ -581,7 +599,7 @@ struct ieee80211_network { /* These entries are used to identify a unique network */ - u8 bssid[ETH_ALEN]; + u8 bssid[IEEE80211_ALEN]; u8 channel; /* Ensure null-terminated for any debug msgs */ u8 ssid[IW_ESSID_MAX_SIZE + 1]; @@ -625,12 +643,12 @@ #define MAC_ARG(x) ((u8*)(x))[0],((u8*)(x))[1],((u8*)(x))[2],((u8*)(x))[3],((u8*)(x))[4],((u8*)(x))[5] -extern inline int is_multicast_ether_addr(const u8 *addr) +extern inline int is_multicast_ieee80211_addr(const u8 *addr) { return ((addr[0] != 0xff) && (0x01 & addr[0])); } -extern inline int is_broadcast_ether_addr(const u8 *addr) +extern inline int is_broadcast_ieee80211_addr(const u8 *addr) { return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) && \ (addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff)); @@ -694,7 +712,7 @@ u16 fts; /* Fragmentation Threshold */ /* Association info */ - u8 bssid[ETH_ALEN]; + u8 bssid[IEEE80211_ALEN]; enum ieee80211_state state; @@ -774,7 +792,7 @@ return 0; } -extern inline int ieee80211_get_hdrlen(u16 fc) +extern inline int __ieee80211_get_hdrlen(u16 fc) { int hdrlen = IEEE80211_3ADDR_LEN; @@ -798,12 +816,29 @@ return hdrlen; } +#define ieee80211_get_hdrlen(hdr) __ieee80211_get_hdrlen(le16_to_cpu((hdr)->frame_ctl)) + +#define IEEE80211_GET_DATA_HDR_LEN(hdr) \ + ((((hdr)->frame_ctl & \ + __constant_cpu_to_le16(IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) \ + == __constant_cpu_to_le16(IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) \ + ? IEEE80211_4ADDR_LEN : IEEE80211_3ADDR_LEN) +#define IEEE80211_GET_SNAP(hdr) \ + ((struct ieee80211_snap_hdr *) \ + ((u8 *)(hdr) + IEEE80211_GET_DATA_HDR_LEN(hdr))) +extern inline int ieee80211_get_proto(struct ieee80211_hdr *header) +{ + struct ieee80211_snap_hdr *snap = IEEE80211_GET_SNAP(header); + return (snap->dsap == 0xaa && snap->ssap == 0xaa ? + ntohs(snap->type) : ETH_P_802_2); +} /* ieee80211.c */ extern void free_ieee80211(struct ieee80211_device *ieee); extern struct ieee80211_device *alloc_ieee80211(int sizeof_priv); +extern void ieee80211_setup(struct net_device *dev); extern int ieee80211_set_encryption(struct ieee80211_device *ieee); --- a/net/ieee80211/ieee80211_rx.c +++ b/net/ieee80211/ieee80211_rx.c @@ -42,11 +42,10 @@ struct ieee80211_rx_stats *rx_stats) { struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; - u16 fc = le16_to_cpu(hdr->frame_ctl); skb->dev = ieee->dev; skb->mac.raw = skb->data; - skb_pull(skb, ieee80211_get_hdrlen(fc)); + skb_pull(skb, ieee80211_get_hdrlen(hdr)); skb->pkt_type = PACKET_OTHERHOST; skb->protocol = __constant_htons(ETH_P_80211_RAW); memset(skb->cb, 0, sizeof(skb->cb)); @@ -76,8 +75,8 @@ if (entry->skb != NULL && entry->seq == seq && (entry->last_frag + 1 == frag || frag == -1) && - memcmp(entry->src_addr, src, ETH_ALEN) == 0 && - memcmp(entry->dst_addr, dst, ETH_ALEN) == 0) + memcmp(entry->src_addr, src, IEEE80211_ALEN) == 0 && + memcmp(entry->dst_addr, dst, IEEE80211_ALEN) == 0) return entry; } @@ -104,7 +103,7 @@ sizeof(struct ieee80211_hdr) + 8 /* LLC */ + 2 /* alignment */ + - 8 /* WEP */ + ETH_ALEN /* WDS */); + 8 /* WEP */ + IEEE80211_ALEN /* WDS */); if (skb == NULL) return NULL; @@ -120,8 +119,8 @@ entry->seq = seq; entry->last_frag = frag; entry->skb = skb; - memcpy(entry->src_addr, hdr->addr2, ETH_ALEN); - memcpy(entry->dst_addr, hdr->addr1, ETH_ALEN); + memcpy(entry->src_addr, hdr->addr2, IEEE80211_ALEN); + memcpy(entry->dst_addr, hdr->addr1, IEEE80211_ALEN); } else { /* received a fragment of a frame for which the head fragment * should have already been received */ @@ -221,15 +220,6 @@ #endif -/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */ -/* Ethernet-II snap header (RFC1042 for most EtherTypes) */ -static unsigned char rfc1042_header[] = -{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 }; -/* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */ -static unsigned char bridge_tunnel_header[] = -{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 }; -/* No encapsulation header if EtherType < 0x600 (=length) */ - /* Called by ieee80211_rx_frame_decrypt */ static int ieee80211_is_eapol_frame(struct ieee80211_device *ieee, struct sk_buff *skb) @@ -237,7 +227,6 @@ struct net_device *dev = ieee80211_dev(ieee); u16 fc, ethertype; struct ieee80211_hdr *hdr; - u8 *pos; if (skb->len < 24) return 0; @@ -248,12 +237,12 @@ /* check that the frame is unicast frame to us */ if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == IEEE80211_FCTL_TODS && - memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0 && - memcmp(hdr->addr3, dev->dev_addr, ETH_ALEN) == 0) { + memcmp(hdr->addr1, dev->dev_addr, IEEE80211_ALEN) == 0 && + memcmp(hdr->addr3, dev->dev_addr, IEEE80211_ALEN) == 0) { /* ToDS frame with own addr BSSID and DA */ } else if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == IEEE80211_FCTL_FROMDS && - memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0) { + memcmp(hdr->addr1, dev->dev_addr, IEEE80211_ALEN) == 0) { /* FromDS frame with own addr as DA */ } else return 0; @@ -262,8 +251,7 @@ return 0; /* check for port access entity Ethernet type */ - pos = skb->data + 24; - ethertype = (pos[6] << 8) | pos[7]; + ethertype = ieee80211_get_proto(hdr); if (ethertype == ETH_P_PAE) return 1; @@ -282,7 +270,7 @@ return 0; hdr = (struct ieee80211_hdr *) skb->data; - hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + hdrlen = ieee80211_get_hdrlen(hdr); #ifdef CONFIG_IEEE80211_CRYPT_TKIP if (ieee->tkip_countermeasures && @@ -327,7 +315,7 @@ return 0; hdr = (struct ieee80211_hdr *) skb->data; - hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + hdrlen = ieee80211_get_hdrlen(hdr); atomic_inc(&crypt->refcnt); res = crypt->ops->decrypt_msdu(skb, keyidx, hdrlen, crypt->priv); @@ -343,6 +331,44 @@ } +unsigned short ieee80211_type_trans(struct sk_buff *skb, + struct ieee80211_device *ieee) +{ + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; + struct ieee80211_snap_hdr *snap; + int hdrlen; + u8 *daddr = IEEE80211_GET_DADDR(hdr); + unsigned short type; + + skb->mac.raw = skb->data; + + hdrlen = ieee80211_get_hdrlen(hdr); + snap = (struct ieee80211_snap_hdr *)(skb->data + hdrlen); + if (snap->dsap == 0xaa && snap->ssap == 0xaa && + ((IEEE80211_SNAP_IS_RFC1042(snap) && + snap->type != __constant_htons(ETH_P_AARP) && + snap->type != __constant_htons(ETH_P_IPX)) || + IEEE80211_SNAP_IS_BRIDGE_TUNNEL(snap))) { + type = snap->type; + skb_pull(skb, hdrlen + SNAP_SIZE); + } + else { + type = __constant_htons(ETH_P_802_2); + skb_pull(skb, hdrlen); + } + + skb->input_dev = ieee->dev; + if (is_broadcast_ieee80211_addr(daddr)) + skb->pkt_type = PACKET_BROADCAST; + else if (is_multicast_ieee80211_addr(daddr)) + skb->pkt_type = PACKET_MULTICAST; + else if (memcmp(daddr, ieee->dev->dev_addr, IEEE80211_ALEN)) + skb->pkt_type = PACKET_OTHERHOST; + + return type; +} + + /* All received frames are sent to this function. @skb contains the frame in * IEEE 802.11 format, i.e., in the format it was sent over air. * This function is called only as a tasklet (software IRQ). */ @@ -355,8 +381,6 @@ u16 fc, type, stype, sc; struct net_device_stats *stats; unsigned int frag; - u8 *payload; - u16 ethertype; #ifdef NOT_YET struct net_device *wds = NULL; struct sk_buff *skb2 = NULL; @@ -365,8 +389,8 @@ int from_assoc_ap = 0; void *sta = NULL; #endif - u8 dst[ETH_ALEN]; - u8 src[ETH_ALEN]; + u8 dst[IEEE80211_ALEN]; + u8 src[IEEE80211_ALEN]; struct ieee80211_crypt_data *crypt = NULL; int keyidx = 0; @@ -384,7 +408,7 @@ stype = WLAN_FC_GET_STYPE(fc); sc = le16_to_cpu(hdr->seq_ctl); frag = WLAN_GET_SEQ_FRAG(sc); - hdrlen = ieee80211_get_hdrlen(fc); + hdrlen = __ieee80211_get_hdrlen(fc); #ifdef NOT_YET #if WIRELESS_EXT > 15 @@ -480,22 +504,23 @@ switch (fc & (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { case IEEE80211_FCTL_FROMDS: - memcpy(dst, hdr->addr1, ETH_ALEN); - memcpy(src, hdr->addr3, ETH_ALEN); + memcpy(dst, hdr->addr1, IEEE80211_ALEN); + memcpy(src, hdr->addr3, IEEE80211_ALEN); break; case IEEE80211_FCTL_TODS: - memcpy(dst, hdr->addr3, ETH_ALEN); - memcpy(src, hdr->addr2, ETH_ALEN); + memcpy(dst, hdr->addr3, IEEE80211_ALEN); + memcpy(src, hdr->addr2, IEEE80211_ALEN); break; case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: if (skb->len < IEEE80211_4ADDR_LEN) goto rx_dropped; - memcpy(dst, hdr->addr3, ETH_ALEN); - memcpy(src, hdr->addr4, ETH_ALEN); + memcpy(dst, hdr->addr3, IEEE80211_ALEN); + memcpy(src, hdr->addr4, IEEE80211_ALEN); + /* FIXME: this is wrong */ break; case 0: - memcpy(dst, hdr->addr1, ETH_ALEN); - memcpy(src, hdr->addr2, ETH_ALEN); + memcpy(dst, hdr->addr1, IEEE80211_ALEN); + memcpy(src, hdr->addr2, IEEE80211_ALEN); break; } @@ -510,7 +535,7 @@ if (ieee->iw_mode == IW_MODE_MASTER && !wds && (fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == IEEE80211_FCTL_FROMDS && ieee->stadev && - memcmp(hdr->addr2, ieee->assoc_ap_addr, ETH_ALEN) == 0) { + memcmp(hdr->addr2, ieee->assoc_ap_addr, IEEE80211_ALEN) == 0) { /* Frame from BSSID of the AP for which we are a client */ skb->dev = dev = ieee->stadev; stats = hostap_get_stats(dev); @@ -668,9 +693,6 @@ /* skb: hdr + (possible reassembled) full plaintext payload */ - payload = skb->data + hdrlen; - ethertype = (payload[6] << 8) | payload[7]; - #ifdef NOT_YET /* If IEEE 802.1X is used, check whether the port is authorized to send * the received frame. */ @@ -697,38 +719,6 @@ } #endif - /* convert hdr + possible LLC headers into Ethernet header */ - if (skb->len - hdrlen >= 8 && - ((memcmp(payload, rfc1042_header, SNAP_SIZE) == 0 && - ethertype != ETH_P_AARP && ethertype != ETH_P_IPX) || - memcmp(payload, bridge_tunnel_header, SNAP_SIZE) == 0)) { - /* remove RFC1042 or Bridge-Tunnel encapsulation and - * replace EtherType */ - skb_pull(skb, hdrlen + SNAP_SIZE); - memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); - memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); - } else { - u16 len; - /* Leave Ethernet header part of hdr and full payload */ - skb_pull(skb, hdrlen); - len = htons(skb->len); - memcpy(skb_push(skb, 2), &len, 2); - memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); - memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); - } - -#ifdef NOT_YET - if (wds && ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == - IEEE80211_FCTL_TODS) && - skb->len >= ETH_HLEN + ETH_ALEN) { - /* Non-standard frame: get addr4 from its bogus location after - * the payload */ - memcpy(skb->data + ETH_ALEN, - skb->data + skb->len - ETH_ALEN, ETH_ALEN); - skb_trim(skb, skb->len - ETH_ALEN); - } -#endif - stats->rx_packets++; stats->rx_bytes += skb->len; @@ -754,7 +744,7 @@ if (skb2 != NULL) { /* send to wireless media */ - skb2->protocol = __constant_htons(ETH_P_802_3); + skb2->protocol = ieee80211_type_trans(skb2, ieee); skb2->mac.raw = skb2->nh.raw = skb2->data; /* skb2->nh.raw = skb2->data + ETH_HLEN; */ skb2->dev = dev; @@ -764,7 +754,7 @@ #endif if (skb) { - skb->protocol = eth_type_trans(skb, dev); + skb->protocol = ieee80211_type_trans(skb, ieee); memset(skb->cb, 0, sizeof(skb->cb)); skb->dev = dev; skb->ip_summed = CHECKSUM_NONE; /* 802.11 crc not sufficient */ @@ -821,7 +811,7 @@ u8 i; /* Pull out fixed field data */ - memcpy(network->bssid, beacon->header.addr3, ETH_ALEN); + memcpy(network->bssid, beacon->header.addr3, IEEE80211_ALEN); network->capability = beacon->capability; network->last_scanned = jiffies; network->time_stamp[0] = beacon->time_stamp[0]; @@ -849,7 +839,7 @@ while (left >= sizeof(struct ieee80211_info_element_hdr)) { if (sizeof(struct ieee80211_info_element_hdr) + info_element->len > left) { IEEE80211_DEBUG_SCAN("SCAN: parse failed: info_element->len + 2 > left : info_element->len+2=%d left=%d.\n", - info_element->len + sizeof(struct ieee80211_info_element), + info_element->len + (int)sizeof(struct ieee80211_info_element), left); return 1; } @@ -1017,7 +1007,7 @@ * as one network */ return ((src->ssid_len == dst->ssid_len) && (src->channel == dst->channel) && - !memcmp(src->bssid, dst->bssid, ETH_ALEN) && + !memcmp(src->bssid, dst->bssid, IEEE80211_ALEN) && !memcmp(src->ssid, dst->ssid, src->ssid_len)); } --- a/net/ieee80211/ieee80211_module.c +++ b/net/ieee80211/ieee80211_module.c @@ -48,7 +48,6 @@ #include #include #include -#include #include #include @@ -99,28 +98,230 @@ } +static int ieee80211_change_mtu(struct net_device *dev, int new_mtu) +{ + if ((new_mtu < 68) || (new_mtu > IEEE80211_DATA_LEN - 8 - SNAP_SIZE)) + return -EINVAL; + dev->mtu = new_mtu; + return 0; +} + + +static u8 P802_1H_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0xf8 }; +static u8 RFC1042_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0x00 }; + +static inline int __ieee80211_put_snap(u8 *data, u16 h_proto) +{ + struct ieee80211_snap_hdr *snap; + u8 *oui; + + snap = (struct ieee80211_snap_hdr *)data; + snap->dsap = 0xaa; + snap->ssap = 0xaa; + snap->ctrl = 0x03; + + if (h_proto == __constant_htons(ETH_P_IPX) || + h_proto == __constant_htons(ETH_P_AARP)) + oui = P802_1H_OUI; + else + oui = RFC1042_OUI; + snap->oui[0] = oui[0]; + snap->oui[1] = oui[1]; + snap->oui[2] = oui[2]; + + snap->type = h_proto; + + return SNAP_SIZE; +} + +static inline int ieee80211_put_snap(u8 *data, u16 h_proto) +{ + return __ieee80211_put_snap(data, htons(h_proto)); +} + +/* + * Create the IEEE 802.11 MAC header for an arbitrary protocol layer + * + * saddr=NULL means use device source address + * daddr=NULL means leave destination address (eg unresolved arp) + */ +static int ieee80211_header(struct sk_buff *skb, struct net_device *dev, + unsigned short type, void *daddr, void *saddr, unsigned len) +{ + struct ieee80211_device *ieee = netdev_priv(dev); + struct ieee80211_hdr *header; + int fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; + int hdr_len = IEEE80211_3ADDR_LEN; + + if (type != ETH_P_802_3 && type != ETH_P_802_2) { + ieee80211_put_snap(skb_push(skb, SNAP_SIZE), type); + hdr_len += SNAP_SIZE; + } + + if (!saddr) saddr = dev->dev_addr; + header = (struct ieee80211_hdr *)skb_push(skb, IEEE80211_3ADDR_LEN); + header->duration_id = header->seq_ctl = 0; + if (ieee->iw_mode == IW_MODE_INFRA) { + fc |= IEEE80211_FCTL_TODS; + /* To DS: Addr1 = BSSID, Addr2 = SA, + Addr3 = DA */ + memcpy(header->addr1, ieee->bssid, IEEE80211_ALEN); + memcpy(header->addr2, saddr, IEEE80211_ALEN); + if (daddr) + memcpy(header->addr3, daddr, IEEE80211_ALEN); + else + memset(header->addr3, 0, IEEE80211_ALEN); + } else if (ieee->iw_mode == IW_MODE_ADHOC) { + /* not From/To DS: Addr1 = DA, Addr2 = SA, + Addr3 = BSSID */ + if (daddr) + memcpy(header->addr1, daddr, IEEE80211_ALEN); + else + memset(header->addr1, 0, IEEE80211_ALEN); + memcpy(header->addr2, saddr, IEEE80211_ALEN); + memcpy(header->addr3, ieee->bssid, IEEE80211_ALEN); + } + header->frame_ctl = cpu_to_le16(fc); + + if (!daddr || (dev->flags & (IFF_LOOPBACK | IFF_NOARP))) + return -hdr_len; + return hdr_len; +} + +static int ieee80211_rebuild_header(struct sk_buff *skb) +{ + struct ieee80211_hdr *header = (struct ieee80211_hdr *)skb->data; + struct net_device *dev = skb->dev; + unsigned short type; + + type = ieee80211_get_proto(header); + + switch (type) { +#ifdef CONFIG_INET + case ETH_P_IP: + return arp_find(IEEE80211_GET_DADDR(header), skb); +#endif + default: + printk(KERN_DEBUG + "%s: unable to resolve type %X addresses.\n", + dev->name, type); + break; + } + + return 0; +} + +static int ieee80211_mac_addr(struct net_device *dev, void *p) +{ + struct sockaddr *addr = p; + + if (netif_running(dev)) + return -EBUSY; + memcpy(dev->dev_addr, addr->sa_data, dev->addr_len); + return 0; +} + +static int ieee80211_header_cache(struct neighbour *neigh, struct hh_cache *hh) +{ + struct net_device *dev = neigh->dev; + struct ieee80211_device *ieee = netdev_priv(dev); + unsigned short type = hh->hh_type; + struct ieee80211_hdr *header; + int fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; + + if (type == __constant_htons(ETH_P_802_3) || + type == __constant_htons(ETH_P_802_2)) + return -1; + + header = (struct ieee80211_hdr *) + (((u8 *)hh->hh_data) + + (HH_DATA_OFF(IEEE80211_3ADDR_LEN + SNAP_SIZE))); + __ieee80211_put_snap((u8 *)header + IEEE80211_3ADDR_LEN, type); + + header->duration_id = header->seq_ctl = 0; + if (ieee->iw_mode == IW_MODE_INFRA) { + fc |= IEEE80211_FCTL_TODS; + /* To DS: Addr1 = BSSID, Addr2 = SA, + Addr3 = DA */ + memcpy(header->addr1, ieee->bssid, IEEE80211_ALEN); + memcpy(header->addr2, dev->dev_addr, IEEE80211_ALEN); + memcpy(header->addr3, neigh->ha, IEEE80211_ALEN); + } else if (ieee->iw_mode == IW_MODE_ADHOC) { + /* not From/To DS: Addr1 = DA, Addr2 = SA, + Addr3 = BSSID */ + memcpy(header->addr1, neigh->ha, IEEE80211_ALEN); + memcpy(header->addr2, dev->dev_addr, IEEE80211_ALEN); + memcpy(header->addr3, ieee->bssid, IEEE80211_ALEN); + } + header->frame_ctl = cpu_to_le16(fc); + + hh->hh_len = IEEE80211_3ADDR_LEN + SNAP_SIZE; + return 0; +} + +static void ieee80211_header_cache_update(struct hh_cache *hh, + struct net_device *dev, unsigned char *haddr) +{ + struct ieee80211_hdr *header; + + header = (struct ieee80211_hdr *) + (((u8 *)hh->hh_data) + + (HH_DATA_OFF(IEEE80211_3ADDR_LEN + SNAP_SIZE))); + memcpy(IEEE80211_GET_DADDR(header), haddr, dev->addr_len); +} + +static int ieee80211_header_parse(struct sk_buff *skb, unsigned char *haddr) +{ + struct ieee80211_hdr *header = (struct ieee80211_hdr *)skb->data; + + memcpy(haddr, IEEE80211_GET_SADDR(header), IEEE80211_ALEN); + return IEEE80211_ALEN; +} + + +void ieee80211_setup(struct net_device *dev) +{ + dev->change_mtu = ieee80211_change_mtu; + dev->hard_header = ieee80211_header; + dev->rebuild_header = ieee80211_rebuild_header; + dev->set_mac_address = ieee80211_mac_addr; + dev->hard_header_cache = ieee80211_header_cache; + dev->header_cache_update = ieee80211_header_cache_update; + dev->hard_header_parse = ieee80211_header_parse; + + dev->hard_start_xmit = ieee80211_xmit; + + dev->type = ARPHRD_ETHER; + dev->hard_header_len = IEEE80211_3ADDR_LEN + SNAP_SIZE; + dev->mtu = IEEE80211_DATA_LEN - 8 - SNAP_SIZE; + dev->addr_len = IEEE80211_ALEN; + dev->tx_queue_len = 1000; + dev->flags = IFF_BROADCAST | IFF_MULTICAST; + + memset(dev->broadcast, 0xFF, IEEE80211_ALEN); +} + + struct ieee80211_device *alloc_ieee80211(int sizeof_priv) { struct ieee80211_device *ieee; struct net_device *dev; - int alloc_size; + int alloc_size; int err; IEEE80211_DEBUG_INFO("Initializing...\n"); - alloc_size = ((sizeof(struct ieee80211_device) + NETDEV_ALIGN_CONST) - & ~NETDEV_ALIGN_CONST) - + sizeof_priv; - dev = alloc_etherdev(alloc_size); + alloc_size = ((sizeof(struct ieee80211_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST) + + sizeof_priv; + dev = alloc_netdev(alloc_size, "wlan%d", ieee80211_setup); if (!dev) { - IEEE80211_ERROR("Unable to network device.\n"); + IEEE80211_ERROR("Unable to allocate network device.\n"); goto failed; } ieee = netdev_priv(dev); ieee->dev = dev; ieee->priv = ieee80211_priv(ieee); - - dev->hard_start_xmit = ieee80211_xmit; err = ieee80211_networks_allocate(ieee); if (err) { @@ -201,7 +402,7 @@ unsigned long count, void *data) { char buf[] = "0x00000000"; - unsigned long len = min(sizeof(buf) - 1, (u32)count); + unsigned long len = min((unsigned long)sizeof(buf) - 1, count); char *p = (char *)buf; unsigned long val; @@ -268,4 +469,5 @@ #endif +EXPORT_SYMBOL(ieee80211_setup); EXPORT_SYMBOL(alloc_ieee80211); EXPORT_SYMBOL(free_ieee80211); --- a/net/ieee80211/ieee80211_tx.c +++ b/net/ieee80211/ieee80211_tx.c @@ -84,16 +84,6 @@ Total: 8 non-data bytes -802.3 Ethernet Data Frame - - ,-----------------------------------------. -Bytes | 6 | 6 | 2 | Variable | 4 | - |-------|-------|------|-----------|------| -Desc. | Dest. | Source| Type | IP Packet | fcs | - | MAC | MAC | | | | - `-----------------------------------------' -Total: 18 non-data bytes - In the event that fragmentation is required, the incoming payload is split into N parts of size ieee->fts. The first fragment contains the SNAP header and the remaining packets are just data. @@ -104,56 +94,8 @@ encryption it will take 3 frames. With WEP it will take 4 frames as the payload of each frame is reduced to 492 bytes. -* SKB visualization -* -* ,- skb->data -* | -* | ETHERNET HEADER ,-<-- PAYLOAD -* | | 14 bytes from skb->data -* | 2 bytes for Type --> ,T. | (sizeof ethhdr) -* | | | | -* |,-Dest.--. ,--Src.---. | | | -* | 6 bytes| | 6 bytes | | | | -* v | | | | | | -* 0 | v 1 | v | v 2 -* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 -* ^ | ^ | ^ | -* | | | | | | -* | | | | `T' <---- 2 bytes for Type -* | | | | -* | | '---SNAP--' <-------- 6 bytes for SNAP -* | | -* `-IV--' <-------------------- 4 bytes for IV (WEP) -* -* SNAP HEADER -* */ -static u8 P802_1H_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0xf8 }; -static u8 RFC1042_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0x00 }; - -static inline int ieee80211_put_snap(u8 *data, u16 h_proto) -{ - struct ieee80211_snap_hdr *snap; - u8 *oui; - - snap = (struct ieee80211_snap_hdr *)data; - snap->dsap = 0xaa; - snap->ssap = 0xaa; - snap->ctrl = 0x03; - - if (h_proto == 0x8137 || h_proto == 0x80f3) - oui = P802_1H_OUI; - else - oui = RFC1042_OUI; - snap->oui[0] = oui[0]; - snap->oui[1] = oui[1]; - snap->oui[2] = oui[2]; - - *(u16 *)(data + SNAP_SIZE) = htons(h_proto); - - return SNAP_SIZE + sizeof(u16); -} static inline int ieee80211_encrypt_fragment( struct ieee80211_device *ieee, @@ -248,19 +190,16 @@ struct net_device *dev) { struct ieee80211_device *ieee = netdev_priv(dev); + struct ieee80211_hdr *header = (struct ieee80211_hdr *)skb->data; struct ieee80211_txb *txb = NULL; struct ieee80211_hdr *frag_hdr; int i, bytes_per_frag, nr_frags, bytes_last_frag, frag_size; unsigned long flags; struct net_device_stats *stats = &ieee->stats; - int ether_type, encrypt; + int type, encrypt; int bytes, fc, hdr_len; struct sk_buff *skb_frag; - struct ieee80211_hdr header = { /* Ensure zero initialized */ - .duration_id = 0, - .seq_ctl = 0 - }; - u8 dest[ETH_ALEN], src[ETH_ALEN]; + u8 *dest; struct ieee80211_crypt_data* crypt; @@ -269,76 +208,48 @@ /* If there is no driver handler to take the TXB, dont' bother * creating it... */ if (!ieee->hard_start_xmit) { - printk(KERN_WARNING "%s: No xmit handler.\n", - dev->name); + if (printk_ratelimit()) + printk(KERN_WARNING "%s: No xmit handler.\n", + dev->name); goto success; } - if (unlikely(skb->len < SNAP_SIZE + sizeof(u16))) { - printk(KERN_WARNING "%s: skb too small (%d).\n", - dev->name, skb->len); - goto success; - } - - ether_type = ntohs(((struct ethhdr *)skb->data)->h_proto); + type = ieee80211_get_proto(header); + dest = IEEE80211_GET_DADDR(header); + hdr_len = ieee80211_get_hdrlen(header); crypt = ieee->crypt[ieee->tx_keyidx]; - encrypt = !(ether_type == ETH_P_PAE && ieee->ieee802_1x) && + encrypt = !(type == ETH_P_PAE && ieee->ieee802_1x) && ieee->host_encrypt && crypt && crypt->ops; if (!encrypt && ieee->ieee802_1x && - ieee->drop_unencrypted && ether_type != ETH_P_PAE) { + ieee->drop_unencrypted && type != ETH_P_PAE) { stats->tx_dropped++; goto success; } #ifdef CONFIG_IEEE80211_DEBUG - if (crypt && !encrypt && ether_type == ETH_P_PAE) { - struct eapol *eap = (struct eapol *)(skb->data + - sizeof(struct ethhdr) - SNAP_SIZE - sizeof(u16)); + if (crypt && !encrypt && type == ETH_P_PAE) { + struct eapol *eap = (struct eapol *)(skb->data + hdr_len); IEEE80211_DEBUG_EAP("TX: IEEE 802.11 EAPOL frame: %s\n", eap_get_type(eap->type)); } #endif - /* Save source and destination addresses */ - memcpy(&dest, skb->data, ETH_ALEN); - memcpy(&src, skb->data+ETH_ALEN, ETH_ALEN); - - /* Advance the SKB to the start of the payload */ - skb_pull(skb, sizeof(struct ethhdr)); - /* Determine total amount of storage required for TXB packets */ - bytes = skb->len + SNAP_SIZE + sizeof(u16); + bytes = skb->len - hdr_len; + fc = le16_to_cpu(header->frame_ctl); if (encrypt) - fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA | - IEEE80211_FCTL_WEP; - else - fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; + fc |= IEEE80211_FCTL_WEP; - if (ieee->iw_mode == IW_MODE_INFRA) { - fc |= IEEE80211_FCTL_TODS; - /* To DS: Addr1 = BSSID, Addr2 = SA, - Addr3 = DA */ - memcpy(&header.addr1, ieee->bssid, ETH_ALEN); - memcpy(&header.addr2, &src, ETH_ALEN); - memcpy(&header.addr3, &dest, ETH_ALEN); - } else if (ieee->iw_mode == IW_MODE_ADHOC) { - /* not From/To DS: Addr1 = DA, Addr2 = SA, - Addr3 = BSSID */ - memcpy(&header.addr1, dest, ETH_ALEN); - memcpy(&header.addr2, src, ETH_ALEN); - memcpy(&header.addr3, ieee->bssid, ETH_ALEN); - } - header.frame_ctl = cpu_to_le16(fc); - hdr_len = IEEE80211_3ADDR_LEN; + header->frame_ctl = cpu_to_le16(fc); /* Determine fragmentation size based on destination (multicast * and broadcast are not fragmented) */ - if (is_multicast_ether_addr(dest) || - is_broadcast_ether_addr(dest)) + if (is_multicast_ieee80211_addr(dest) || + is_broadcast_ieee80211_addr(dest)) frag_size = MAX_FRAG_THRESHOLD; else frag_size = ieee->fts; @@ -347,7 +258,7 @@ * this stack is providing the full 802.11 header, one will * eventually be affixed to this fragment -- so we must account for * it when determining the amount of payload space. */ - bytes_per_frag = frag_size - IEEE80211_3ADDR_LEN; + bytes_per_frag = frag_size - hdr_len; if (ieee->config & (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) bytes_per_frag -= IEEE80211_FCS_LEN; @@ -378,6 +289,8 @@ txb->encrypted = encrypt; txb->payload_size = bytes; + skb_pull(skb, hdr_len); + for (i = 0; i < nr_frags; i++) { skb_frag = txb->fragments[i]; @@ -385,7 +298,7 @@ skb_reserve(skb_frag, crypt->ops->extra_prefix_len); frag_hdr = (struct ieee80211_hdr *)skb_put(skb_frag, hdr_len); - memcpy(frag_hdr, &header, hdr_len); + memcpy(frag_hdr, header, hdr_len); /* If this is not the last fragment, then add the MOREFRAGS * bit to the frame control */ @@ -398,14 +311,6 @@ bytes = bytes_last_frag; } - /* Put a SNAP header on the first fragment */ - if (i == 0) { - ieee80211_put_snap( - skb_put(skb_frag, SNAP_SIZE + sizeof(u16)), - ether_type); - bytes -= SNAP_SIZE + sizeof(u16); - } - memcpy(skb_put(skb_frag, bytes), skb->data, bytes); /* Advance the SKB... */ --- a/net/ieee80211/ieee80211_wx.c +++ b/net/ieee80211/ieee80211_wx.c @@ -53,7 +53,7 @@ /* First entry *MUST* be the AP MAC address */ iwe.cmd = SIOCGIWAP; iwe.u.ap_addr.sa_family = ARPHRD_ETHER; - memcpy(iwe.u.ap_addr.sa_data, network->bssid, ETH_ALEN); + memcpy(iwe.u.ap_addr.sa_data, network->bssid, IEEE80211_ALEN); start = iwe_stream_add_event(start, stop, &iwe, IW_EV_ADDR_LEN); /* Remaining entries will be displayed in the order we provide them */ --- a/net/ieee80211/ieee80211_crypt_ccmp.c +++ b/net/ieee80211/ieee80211_crypt_ccmp.c @@ -17,7 +17,6 @@ #include #include #include -#include #include #include #include @@ -156,7 +155,7 @@ * Dlen */ b0[0] = 0x59; b0[1] = qc; - memcpy(b0 + 2, hdr->addr2, ETH_ALEN); + memcpy(b0 + 2, hdr->addr2, IEEE80211_ALEN); memcpy(b0 + 8, pn, CCMP_PN_LEN); b0[14] = (dlen >> 8) & 0xff; b0[15] = dlen & 0xff; @@ -173,13 +172,13 @@ aad[1] = aad_len & 0xff; aad[2] = pos[0] & 0x8f; aad[3] = pos[1] & 0xc7; - memcpy(aad + 4, hdr->addr1, 3 * ETH_ALEN); + memcpy(aad + 4, hdr->addr1, 3 * IEEE80211_ALEN); pos = (u8 *) &hdr->seq_ctl; aad[22] = pos[0] & 0x0f; aad[23] = 0; /* all bits masked */ memset(aad + 24, 0, 8); if (a4_included) - memcpy(aad + 24, hdr->addr4, ETH_ALEN); + memcpy(aad + 24, hdr->addr4, IEEE80211_ALEN); if (qc_included) { aad[a4_included ? 30 : 24] = qc; /* rest of QC masked */ --- a/net/ieee80211/ieee80211_crypt_tkip.c +++ b/net/ieee80211/ieee80211_crypt_tkip.c @@ -17,7 +17,6 @@ #include #include #include -#include #include #include @@ -461,20 +460,20 @@ switch (le16_to_cpu(hdr11->frame_ctl) & (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { case IEEE80211_FCTL_TODS: - memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ - memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + memcpy(hdr, hdr11->addr3, IEEE80211_ALEN); /* DA */ + memcpy(hdr + IEEE80211_ALEN, hdr11->addr2, IEEE80211_ALEN); /* SA */ break; case IEEE80211_FCTL_FROMDS: - memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ - memcpy(hdr + ETH_ALEN, hdr11->addr3, ETH_ALEN); /* SA */ + memcpy(hdr, hdr11->addr1, IEEE80211_ALEN); /* DA */ + memcpy(hdr + IEEE80211_ALEN, hdr11->addr3, IEEE80211_ALEN); /* SA */ break; case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: - memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ - memcpy(hdr + ETH_ALEN, hdr11->addr4, ETH_ALEN); /* SA */ + memcpy(hdr, hdr11->addr3, IEEE80211_ALEN); /* DA */ + memcpy(hdr + IEEE80211_ALEN, hdr11->addr4, IEEE80211_ALEN); /* SA */ break; case 0: - memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ - memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + memcpy(hdr, hdr11->addr1, IEEE80211_ALEN); /* DA */ + memcpy(hdr + IEEE80211_ALEN, hdr11->addr2, IEEE80211_ALEN); /* SA */ break; } @@ -521,7 +520,7 @@ else ev.flags |= IW_MICFAILURE_PAIRWISE; ev.src_addr.sa_family = ARPHRD_ETHER; - memcpy(ev.src_addr.sa_data, hdr->addr2, ETH_ALEN); + memcpy(ev.src_addr.sa_data, hdr->addr2, IEEE80211_ALEN); memset(&wrqu, 0, sizeof(wrqu)); wrqu.data.length = sizeof(ev); wireless_send_event(dev, IWEVMICHAELMICFAILURE, &wrqu, (char *) &ev); -- Jiri Benc SUSE Labs From jbenc@suse.cz Tue May 24 06:14:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:14:32 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODEQXq021988 for ; Tue, 24 May 2005 06:14:26 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 2EB92628302; Tue, 24 May 2005 15:13:41 +0200 (CEST) Date: Tue, 24 May 2005 15:13:41 +0200 From: Jiri Benc To: NetDev Cc: LKML , jgarzik@pobox.com, pavel@suse.cz Subject: [5/5] ieee80211: add sequence numbers Message-ID: <20050524151341.612245e8@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 1692 Lines: 66 Adds sequence numbers to IEEE 802.11 headers. Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac --- a/include/net/ieee80211.h +++ b/include/net/ieee80211.h @@ -711,6 +711,8 @@ unsigned int frag_next_idx; u16 fts; /* Fragmentation Threshold */ + u16 seq_number; /* sequence number in transmitted frames */ + /* Association info */ u8 bssid[IEEE80211_ALEN]; --- a/net/ieee80211/ieee80211_module.c +++ b/net/ieee80211/ieee80211_module.c @@ -333,6 +333,7 @@ /* Default fragmentation threshold is maximum payload size */ ieee->fts = DEFAULT_FTS; + ieee->seq_number = 0; ieee->scan_age = DEFAULT_MAX_SCAN_AGE; ieee->open_wep = 1; --- a/net/ieee80211/ieee80211_tx.c +++ b/net/ieee80211/ieee80211_tx.c @@ -277,6 +277,13 @@ else bytes_last_frag = bytes_per_frag; + if (nr_frags > 16) { + /* Should never happen */ + printk(KERN_WARNING "%s: Fragmentation threshold too low\n", + dev->name); + goto failed; + } + /* When we allocate the TXB we allocate enough space for the reserve * and full fragment bytes (bytes_per_frag doesn't include prefix, * postfix, header, FCS, etc.) */ @@ -300,6 +307,8 @@ frag_hdr = (struct ieee80211_hdr *)skb_put(skb_frag, hdr_len); memcpy(frag_hdr, header, hdr_len); + frag_hdr->seq_ctl = cpu_to_le16(ieee->seq_number | i); + /* If this is not the last fragment, then add the MOREFRAGS * bit to the frame control */ if (i != nr_frags - 1) { @@ -324,7 +333,7 @@ (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) skb_put(skb_frag, 4); } - + ieee->seq_number += 0x10; success: spin_unlock_irqrestore(&ieee->lock, flags); -- Jiri Benc SUSE Labs From jbenc@suse.cz Tue May 24 06:15:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:15:59 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODFpXq022925 for ; Tue, 24 May 2005 06:15:52 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 09BDF6282FC; Tue, 24 May 2005 15:15:07 +0200 (CEST) Date: Tue, 24 May 2005 15:15:06 +0200 From: Jiri Benc To: NetDev Cc: pavel@suse.cz Subject: [1-2/6] ipw2100, ipw2200: patches to merge to kernel Message-ID: <20050524151506.48e5db65@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 419 Lines: 16 Patches to merge the ipw2100 and ipw2200 drivers to the kernel can be downloaded from: http://jikos.cz/~jbohac/wifi/import-ipw2100.patch http://jikos.cz/~jbohac/wifi/import-ipw2200.patch (they are too large to post them here) The ipw2100 patch is just a merge of ipw2100 driver with Pavel Machek's cleanup patch. The ipw2200 patch is not cleaned up and is intended for testing purposes only. -- Jiri Benc SUSE Labs From jbenc@suse.cz Tue May 24 06:16:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:16:57 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODGsXq023649 for ; Tue, 24 May 2005 06:16:54 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 4ABB3628302; Tue, 24 May 2005 15:16:09 +0200 (CEST) Date: Tue, 24 May 2005 15:16:09 +0200 From: Jiri Benc To: NetDev Cc: pavel@suse.cz Subject: [3/6] ipw2100: fix after "ieee80211: cleanup" Message-ID: <20050524151609.1da09c2b@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 657 Lines: 23 Fixes ipw2100 after the ieee80211 header cleanup (patch [1/5] ieee80211: cleanup). Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac --- a/drivers/net/wireless/ipw2100.h 2005-05-19 16:23:00.000000000 +0200 +++ b/drivers/net/wireless/ipw2100.h 2005-05-19 16:37:14.000000000 +0200 @@ -798,7 +798,7 @@ -#define IPW_HEADER_802_11_SIZE sizeof(struct ieee80211_header_data) +#define IPW_HEADER_802_11_SIZE sizeof(struct ieee80211_hdr_3addr) #define IPW_MAX_80211_PAYLOAD_SIZE 2304U #define IPW_MAX_802_11_PAYLOAD_LENGTH 2312 #define IPW_MAX_ACCEPTABLE_TX_FRAME_LENGTH 1536 -- Jiri Benc SUSE Labs From jbenc@suse.cz Tue May 24 06:18:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:18:51 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODIlXq024582 for ; Tue, 24 May 2005 06:18:47 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 5B0346282FC; Tue, 24 May 2005 15:18:02 +0200 (CEST) Date: Tue, 24 May 2005 15:18:02 +0200 From: Jiri Benc To: NetDev Cc: pavel@suse.cz Subject: [4/6] ipw2100: fix after "ieee80211_device alignment fix" Message-ID: <20050524151802.59124dde@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 16832 Lines: 557 Fixes ipw2100 after ieee80211_device alignment fix (patch [2/5] ieee80211: ieee80211_device alignment fix and cleanup) Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac --- linux-2.6.12-rc2-mm3.01/drivers/net/wireless/ipw2100.c 2005-05-19 16:23:00.000000000 +0200 +++ linux-2.6.12-rc2-mm3.04/drivers/net/wireless/ipw2100.c 2005-05-19 17:35:48.000000000 +0200 @@ -1717,7 +1717,7 @@ /* Called by register_netdev() */ static int ipw2100_net_init(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); return ipw2100_up(priv, 1); } @@ -3142,9 +3142,9 @@ return IRQ_NONE; } -static int ipw2100_tx(struct ieee80211_txb *txb, struct net_device *dev) +static int ipw2100_tx(struct ieee80211_txb *txb, struct ieee80211_device *ieee) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(ieee); struct list_head *element; struct ipw2100_tx_packet *packet; unsigned long flags; @@ -3154,7 +3154,7 @@ if (!(priv->status & STATUS_ASSOCIATED)) { IPW_DEBUG_INFO("Can not transmit when not connected.\n"); priv->ieee->stats.tx_carrier_errors++; - netif_stop_queue(dev); + netif_stop_queue(ieee80211_dev(ieee)); goto fail_unlock; } @@ -3185,7 +3185,7 @@ return 0; fail_unlock: - netif_stop_queue(dev); + netif_stop_queue(ieee80211_dev(ieee)); spin_unlock_irqrestore(&priv->low_lock, flags); return 1; } @@ -5087,10 +5087,10 @@ ipw2100_configure_security(priv, 0); } -static void shim__set_security(struct net_device *dev, +static void shim__set_security(struct ieee80211_device *ieee, struct ieee80211_security *sec) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(ieee); int i, force_update = 0; down(&priv->action_sem); @@ -5270,7 +5270,7 @@ * method as well) to talk to the firmware */ static int ipw2100_set_address(struct net_device *dev, void *p) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); struct sockaddr *addr = p; int err = 0; @@ -5298,7 +5298,7 @@ static int ipw2100_open(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); unsigned long flags; IPW_DEBUG_INFO("dev->open\n"); @@ -5312,7 +5312,7 @@ static int ipw2100_close(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); unsigned long flags; struct list_head *element; struct ipw2100_tx_packet *packet; @@ -5348,7 +5348,7 @@ */ static void ipw2100_tx_timeout(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); priv->ieee->stats.tx_errors++; @@ -5371,7 +5371,7 @@ */ static struct net_device_stats *ipw2100_stats(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); return &priv->ieee->stats; } @@ -5458,7 +5458,7 @@ } if (ieee->set_security) - ieee->set_security(ieee->dev, &sec); + ieee->set_security(ieee, &sec); else ret = -EOPNOTSUPP; @@ -5485,7 +5485,7 @@ } if (ieee->set_security) - ieee->set_security(ieee->dev, &sec); + ieee->set_security(ieee, &sec); else ret = -EOPNOTSUPP; @@ -5495,7 +5495,7 @@ static int ipw2100_wpa_set_param(struct net_device *dev, u8 name, u32 value){ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int ret=0; switch(name){ @@ -5534,7 +5534,7 @@ static int ipw2100_wpa_mlme(struct net_device *dev, int command, int reason){ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int ret=0; switch(command){ @@ -5576,8 +5576,8 @@ static int ipw2100_wpa_set_wpa_ie(struct net_device *dev, struct ipw2100_param *param, int plen){ - struct ipw2100_priv *priv = ieee80211_priv(dev); - struct ieee80211_device *ieee = priv->ieee; + struct ieee80211_device *ieee = netdev_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(ieee); u8 *buf; if (! ieee->wpa_enabled) @@ -5616,8 +5616,8 @@ struct ipw2100_param *param, int param_len){ int ret = 0; - struct ipw2100_priv *priv = ieee80211_priv(dev); - struct ieee80211_device *ieee = priv->ieee; + struct ieee80211_device *ieee = netdev_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(ieee); struct ieee80211_crypto_ops *ops; struct ieee80211_crypt_data **crypt; @@ -5737,7 +5737,7 @@ } done: if (ieee->set_security) - ieee->set_security(ieee->dev, &sec); + ieee->set_security(ieee, &sec); /* Do not reset port if card is in Managed mode since resetting will * generate new IEEE 802.11 authentication which may end up in looping @@ -5834,7 +5834,7 @@ static void ipw_ethtool_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); char fw_ver[64], ucode_ver[64]; strcpy(info->driver, DRV_NAME); @@ -5851,7 +5851,7 @@ static u32 ipw2100_ethtool_get_link(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); return (priv->status & STATUS_ASSOCIATED) ? 1 : 0; } @@ -5944,12 +5944,14 @@ { struct ipw2100_priv *priv; struct net_device *dev; + struct ieee80211_device *ieee; - dev = alloc_ieee80211(sizeof(struct ipw2100_priv)); - if (!dev) + ieee = alloc_ieee80211(sizeof(struct ipw2100_priv)); + if (!ieee) return NULL; - priv = ieee80211_priv(dev); - priv->ieee = netdev_priv(dev); + dev = ieee80211_dev(ieee); + priv = ieee80211_priv(ieee); + priv->ieee = ieee; priv->pci_dev = pci_dev; priv->net_dev = dev; @@ -6131,7 +6133,7 @@ return err; } - priv = ieee80211_priv(dev); + priv = ieee80211_priv(netdev_priv(dev)); pci_set_master(pci_dev); pci_set_drvdata(pci_dev, priv); @@ -6270,7 +6272,7 @@ ipw2100_queues_free(priv); sysfs_remove_group(&pci_dev->dev.kobj, &ipw2100_attribute_group); - free_ieee80211(dev); + free_ieee80211(netdev_priv(dev)); pci_set_drvdata(pci_dev, NULL); } @@ -6326,7 +6328,7 @@ if (dev->base_addr) iounmap((unsigned char *)dev->base_addr); - free_ieee80211(dev); + free_ieee80211(netdev_priv(dev)); } pci_release_regions(pci_dev); @@ -6547,7 +6549,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); if (!(priv->status & STATUS_ASSOCIATED)) strcpy(wrqu->name, "unassociated"); else @@ -6562,7 +6564,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); struct iw_freq *fwrq = &wrqu->freq; int err = 0; @@ -6613,7 +6615,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); wrqu->freq.e = 0; @@ -6634,7 +6636,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int err = 0; IPW_DEBUG_WX("SET Mode -> %d \n", wrqu->mode); @@ -6677,7 +6679,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); wrqu->mode = priv->ieee->iw_mode; IPW_DEBUG_WX("GET Mode -> %d\n", wrqu->mode); @@ -6713,7 +6715,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); struct iw_range *range = (struct iw_range *)extra; u16 val; int i, level; @@ -6825,7 +6827,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int err = 0; static const unsigned char any[] = { @@ -6880,7 +6882,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); /* If we are associated, trying to associate, or have a statically * configured BSSID then return that; otherwise return ANY */ @@ -6900,7 +6902,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); char *essid = ""; /* ANY */ int length = 0; int err = 0; @@ -6954,7 +6956,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); /* If we are associated, trying to associate, or have a statically * configured ESSID then return that; otherwise return ANY */ @@ -6982,7 +6984,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); if (wrqu->data.length > IW_ESSID_MAX_SIZE) return -E2BIG; @@ -7004,7 +7006,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); wrqu->data.length = strlen(priv->nick) + 1; memcpy(extra, priv->nick, wrqu->data.length); @@ -7019,7 +7021,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); u32 target_rate = wrqu->bitrate.value; u32 rate; int err = 0; @@ -7060,7 +7062,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int val; int len = sizeof(val); int err = 0; @@ -7112,7 +7114,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int value, err; /* Auto RTS not yet supported */ @@ -7152,7 +7154,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); wrqu->rts.value = priv->rts_threshold & ~RTS_DISABLED; wrqu->rts.fixed = 1; /* no auto select */ @@ -7169,7 +7171,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int err = 0, value; if (priv->ieee->iw_mode != IW_MODE_ADHOC) @@ -7209,7 +7211,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); if (priv->ieee->iw_mode != IW_MODE_ADHOC) { wrqu->power.disabled = 1; @@ -7245,7 +7247,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); if (!wrqu->frag.fixed) return -EINVAL; @@ -7275,7 +7277,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); wrqu->frag.value = priv->frag_threshold & ~FRAG_DISABLED; wrqu->frag.fixed = 0; /* no auto select */ wrqu->frag.disabled = (priv->frag_threshold & FRAG_DISABLED) ? 1 : 0; @@ -7289,7 +7291,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int err = 0; if (wrqu->retry.flags & IW_RETRY_LIFETIME || @@ -7338,7 +7340,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); wrqu->retry.disabled = 0; /* can't be disabled */ @@ -7367,7 +7369,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int err = 0; down(&priv->action_sem); @@ -7398,7 +7400,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); return ieee80211_wx_get_scan(priv->ieee, info, wrqu, extra); } @@ -7414,7 +7416,7 @@ * No check of STATUS_INITIALIZED required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); return ieee80211_wx_set_encode(priv->ieee, info, wrqu, key); } @@ -7426,7 +7428,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); return ieee80211_wx_get_encode(priv->ieee, info, wrqu, key); } @@ -7434,7 +7436,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int err = 0; down(&priv->action_sem); @@ -7484,7 +7486,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); if (!(priv->power_mode & IPW_POWER_ENABLED)) { wrqu->power.disabled = 1; @@ -7509,7 +7511,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int *parms = (int *)extra; int enable = (parms[0] > 0); int err = 0; @@ -7540,7 +7542,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); if (priv->status & STATUS_INITIALIZED) schedule_reset(priv); return 0; @@ -7552,7 +7554,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int err = 0, mode = *(int *)extra; down(&priv->action_sem); @@ -7580,7 +7582,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int level = IPW_POWER_LEVEL(priv->power_mode); s32 timeout, period; @@ -7617,7 +7619,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); int err, mode = *(int *)extra; down(&priv->action_sem); @@ -7650,7 +7652,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); if (priv->config & CFG_LONG_PREAMBLE) snprintf(wrqu->name, IFNAMSIZ, "long (1)"); @@ -7792,7 +7794,7 @@ int tx_qual; int beacon_qual; - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); struct iw_statistics *wstats; u32 rssi, quality, tx_retries, missed_beacons, tx_failures; u32 ord_len = sizeof(u32); -- Jiri Benc SUSE Labs From jbenc@suse.cz Tue May 24 06:20:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:20:06 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODK0Xq024798 for ; Tue, 24 May 2005 06:20:01 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id C8A7D6282FC for ; Tue, 24 May 2005 15:19:15 +0200 (CEST) Date: Tue, 24 May 2005 15:19:15 +0200 From: Jiri Benc To: NetDev Subject: [5/6] ipw2200: fix after "ieee80211_device alignment fix" Message-ID: <20050524151915.5b772c95@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 16818 Lines: 536 Fixes ipw2200 after ieee80211_device alignment fix (patch [2/5] ieee80211: ieee80211_device alignment fix and cleanup). Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac --- linux-2.6.12-rc2-mm3.02/drivers/net/wireless/ipw2200.c 2005-05-18 13:36:28.000000000 +0200 +++ linux-2.6.12-rc2-mm3.02-ipwfix/drivers/net/wireless/ipw2200.c 2005-05-18 16:50:29.000000000 +0200 @@ -5586,7 +5586,7 @@ } if (ieee->set_security) - ieee->set_security(ieee->dev, &sec); + ieee->set_security(ieee, &sec); else ret = -EOPNOTSUPP; @@ -5613,7 +5613,7 @@ } if (ieee->set_security) - ieee->set_security(ieee->dev, &sec); + ieee->set_security(ieee, &sec); else ret = -EOPNOTSUPP; @@ -5623,7 +5623,7 @@ static int ipw_wpa_set_param(struct net_device *dev, u8 name, u32 value) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); int ret=0; switch (name) { @@ -5662,7 +5662,7 @@ static int ipw_wpa_mlme(struct net_device *dev, int command, int reason) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); int ret = 0; switch (command) { @@ -5712,8 +5712,8 @@ static int ipw_wpa_set_wpa_ie(struct net_device *dev, struct ipw_param *param, int plen) { - struct ipw_priv *priv = ieee80211_priv(dev); - struct ieee80211_device *ieee = priv->ieee; + struct ieee80211_device *ieee = netdev_priv(dev); + struct ipw_priv *priv = ieee80211_priv(ieee); u8 *buf; if (!ieee->wpa_enabled) @@ -5748,8 +5748,7 @@ struct ipw_param *param, int param_len) { int ret = 0; - struct ipw_priv *priv = ieee80211_priv(dev); - struct ieee80211_device *ieee = priv->ieee; + struct ieee80211_device *ieee = netdev_priv(dev); struct ieee80211_crypto_ops *ops; struct ieee80211_crypt_data **crypt; @@ -5871,7 +5870,7 @@ } done: if (ieee->set_security) - ieee->set_security(ieee->dev, &sec); + ieee->set_security(ieee, &sec); /* Do not reset port if card is in Managed mode since resetting will * generate new IEEE 802.11 authentication which may end up in looping @@ -5881,7 +5880,7 @@ if (ieee->reset_on_keychange && ieee->iw_mode != IW_MODE_INFRA && ieee->reset_port && - ieee->reset_port(dev)) { + ieee->reset_port(ieee)) { IPW_DEBUG_INFO("%s: reset_port failed\n", dev->name); param->u.crypt.err = IPW_CRYPT_ERR_CARD_CONF_FAILED; return -EINVAL; @@ -6525,7 +6524,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); if (priv->status & STATUS_RF_KILL_MASK) strcpy(wrqu->name, "radio off"); @@ -6574,7 +6573,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); struct iw_freq *fwrq = &wrqu->freq; int ret = 0; @@ -6610,7 +6609,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); wrqu->freq.e = 0; @@ -6632,7 +6631,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); int err = 0; IPW_DEBUG_WX("Set MODE: %d\n", wrqu->mode); @@ -6688,7 +6687,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); wrqu->mode = priv->ieee->iw_mode; IPW_DEBUG_WX("Get MODE -> %d\n", wrqu->mode); @@ -6725,7 +6724,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); struct iw_range *range = (struct iw_range *)extra; u16 val; int i; @@ -6789,7 +6788,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); static const unsigned char any[] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff @@ -6838,7 +6837,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); /* If we are associated, trying to associate, or have a statically * configured BSSID then return that; otherwise return ANY */ down(&priv->sem); @@ -6859,7 +6858,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); char *essid = ""; /* ANY */ int length = 0; down(&priv->sem); @@ -6909,7 +6908,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); /* If we are associated, trying to associate, or have a statically * configured ESSID then return that; otherwise return ANY */ @@ -6934,7 +6933,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); IPW_DEBUG_WX("Setting nick to '%s'\n", extra); if (wrqu->data.length > IW_ESSID_MAX_SIZE) @@ -6954,7 +6953,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); IPW_DEBUG_WX("Getting nick\n"); down(&priv->sem); wrqu->data.length = strlen(priv->nick) + 1; @@ -6969,7 +6968,7 @@ union iwreq_data *wrqu, char *extra) { /* TODO: We should use semaphores or locks for access to priv */ - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); u32 target_rate = wrqu->bitrate.value; u32 fixed, mask; @@ -7081,7 +7080,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv * priv = ieee80211_priv(dev); + struct ipw_priv * priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); wrqu->bitrate.value = priv->last_rate; up(&priv->sem); @@ -7094,7 +7093,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); if (wrqu->rts.disabled) priv->rts_threshold = DEFAULT_RTS_THRESHOLD; @@ -7117,7 +7116,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); wrqu->rts.value = priv->rts_threshold; wrqu->rts.fixed = 0; /* no auto select */ @@ -7133,7 +7132,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); struct ipw_tx_power tx_power; int i; down(&priv->sem); @@ -7185,7 +7184,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); wrqu->power.value = priv->tx_power; wrqu->power.fixed = 1; @@ -7204,7 +7203,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); if (wrqu->frag.disabled) priv->ieee->fts = DEFAULT_FTS; @@ -7226,7 +7225,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); wrqu->frag.value = priv->ieee->fts; wrqu->frag.fixed = 0; /* no auto select */ @@ -7260,7 +7259,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); IPW_DEBUG_WX("Start scan\n"); down(&priv->sem); if (ipw_request_scan(priv)) { @@ -7275,7 +7274,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); return ieee80211_wx_get_scan(priv->ieee, info, wrqu, extra); } @@ -7283,7 +7282,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *key) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); return ieee80211_wx_set_encode(priv->ieee, info, wrqu, key); } @@ -7291,7 +7290,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *key) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); return ieee80211_wx_get_encode(priv->ieee, info, wrqu, key); } @@ -7299,7 +7298,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); int err; down(&priv->sem); if (wrqu->power.disabled) { @@ -7350,7 +7349,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); if (!(priv->power_mode & IPW_POWER_ENABLED)) wrqu->power.disabled = 1; @@ -7367,7 +7366,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); int mode = *(int *)extra; int err; down(&priv->sem); @@ -7396,7 +7395,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); int level = IPW_POWER_LEVEL(priv->power_mode); char *p = extra; @@ -7428,7 +7427,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(netdev_priv(dev))); int mode = *(int *)extra; u8 band = 0, modulation = 0; @@ -7495,7 +7494,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); switch (priv->ieee->mode) { case IEEE_A: @@ -7538,7 +7537,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); int mode = *(int *)extra; down(&priv->sem); /* Switching from SHORT -> LONG requires a disassociation */ @@ -7570,7 +7569,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); if (priv->config & CFG_PREAMBLE_LONG) snprintf(wrqu->name, IFNAMSIZ, "long (1)"); @@ -7745,7 +7744,7 @@ */ static struct iw_statistics *ipw_get_wireless_stats(struct net_device * dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); struct iw_statistics *wstats; wstats = &priv->wstats; @@ -7808,7 +7807,7 @@ static int ipw_net_open(struct net_device *dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); IPW_DEBUG_INFO("dev->open\n"); /* we should be verifying the device is ready to be opened */ down(&priv->sem); @@ -7972,9 +7971,9 @@ } static int ipw_net_hard_start_xmit(struct ieee80211_txb *txb, - struct net_device *dev) + struct ieee80211_device *ieee) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(ieee); unsigned long flags; IPW_DEBUG_TX("dev->xmit(%d bytes)\n", txb->payload_size); @@ -7983,7 +7982,7 @@ if (!(priv->status & STATUS_ASSOCIATED)) { IPW_DEBUG_INFO("Tx attempt while not associated.\n"); priv->ieee->stats.tx_carrier_errors++; - netif_stop_queue(dev); + netif_stop_queue(ieee80211_dev(ieee)); goto fail_unlock; } @@ -8002,7 +8001,7 @@ static struct net_device_stats *ipw_net_get_stats(struct net_device *dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); priv->ieee->stats.tx_packets = priv->tx_packets; priv->ieee->stats.rx_packets = priv->rx_packets; @@ -8016,7 +8015,7 @@ static int ipw_net_set_mac_address(struct net_device *dev, void *p) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); struct sockaddr *addr = p; if (!is_valid_ether_addr(addr->sa_data)) return -EADDRNOTAVAIL; @@ -8033,7 +8032,7 @@ static void ipw_ethtool_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct ipw_priv *p = ieee80211_priv(dev); + struct ipw_priv *p = ieee80211_priv(netdev_priv(dev)); char vers[64]; char date[32]; u32 len; @@ -8054,7 +8053,7 @@ static u32 ipw_ethtool_get_link(struct net_device *dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); return (priv->status & STATUS_ASSOCIATED) != 0; } @@ -8066,7 +8065,7 @@ static int ipw_ethtool_get_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom, u8 *bytes) { - struct ipw_priv *p = ieee80211_priv(dev); + struct ipw_priv *p = ieee80211_priv(netdev_priv(dev)); if (eeprom->offset + eeprom->len > CX2_EEPROM_IMAGE_SIZE) return -EINVAL; @@ -8079,7 +8078,7 @@ static int ipw_ethtool_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom, u8 *bytes) { - struct ipw_priv *p = ieee80211_priv(dev); + struct ipw_priv *p = ieee80211_priv(netdev_priv(dev)); int i; if (eeprom->offset + eeprom->len > CX2_EEPROM_IMAGE_SIZE) @@ -8293,10 +8292,10 @@ } -static void shim__set_security(struct net_device *dev, +static void shim__set_security(struct ieee80211_device *ieee, struct ieee80211_security *sec) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(ieee); int i; down(&priv->sem); for (i = 0; i < 4; i++) { @@ -8579,7 +8578,7 @@ /* Called by register_netdev() */ static int ipw_net_init(struct net_device *dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(netdev_priv(dev)); down(&priv->sem); if (priv->status & STATUS_RF_KILL_SW) { IPW_WARNING("Radio disabled by module parameter.\n"); @@ -8665,19 +8664,21 @@ { int err = 0; struct net_device *net_dev; + struct ieee80211_device *ieee; void __iomem *base; u32 length, val; struct ipw_priv *priv; int band, modulation; - net_dev = alloc_ieee80211(sizeof(struct ipw_priv)); - if (net_dev == NULL) { + ieee = alloc_ieee80211(sizeof(struct ipw_priv)); + if (ieee == NULL) { err = -ENOMEM; goto out; } + net_dev = ieee80211_dev(ieee); - priv = ieee80211_priv(net_dev); - priv->ieee = netdev_priv(net_dev); + priv = ieee80211_priv(ieee); + priv->ieee = ieee; priv->net_dev = net_dev; priv->pci_dev = pdev; @@ -8882,7 +8883,7 @@ pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); out_free_ieee80211: - free_ieee80211(priv->net_dev); + free_ieee80211(priv->ieee); out: return err; } @@ -8924,7 +8925,7 @@ pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); - free_ieee80211(priv->net_dev); + free_ieee80211(priv->ieee); #ifdef CONFIG_PM if (fw_loaded) { -- Jiri Benc SUSE Labs From jbenc@suse.cz Tue May 24 06:21:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 06:21:25 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ODLLXq025675 for ; Tue, 24 May 2005 06:21:21 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 409516282FC for ; Tue, 24 May 2005 15:20:36 +0200 (CEST) Date: Tue, 24 May 2005 15:20:36 +0200 From: Jiri Benc To: NetDev Subject: [6/6] ipw2200: fix after "ieee80211: ethernet independency" Message-ID: <20050524152036.1bd618b1@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 1916 Lines: 58 Fixes ipw2200 after making the 802.11 layer independent of ethernet (patch [4/5] ieee80211: ethernet independency). Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac --- a/drivers/net/wireless/ipw2200.c 2005-05-18 16:50:29.000000000 +0200 +++ b/drivers/net/wireless/ipw2200.c 2005-05-20 14:16:40.000000000 +0200 @@ -6316,8 +6316,8 @@ return 0; /* {broad,multi}cast packets to our IBSS go through */ - if (is_broadcast_ether_addr(header->addr1) || - is_multicast_ether_addr(header->addr1)) + if (is_broadcast_ieee80211_addr(header->addr1) || + is_multicast_ieee80211_addr(header->addr1)) return !memcmp(header->addr3, priv->bssid, ETH_ALEN); /* packets to our adapter go through */ @@ -6329,8 +6329,8 @@ return 0; /* {broad,multi}cast packets to our IBSS go through */ - if (is_broadcast_ether_addr(header->addr1) || - is_multicast_ether_addr(header->addr1)) + if (is_broadcast_ieee80211_addr(header->addr1) || + is_multicast_ieee80211_addr(header->addr1)) return !memcmp(header->addr2, priv->bssid, ETH_ALEN); /* packets to our adapter go through */ @@ -7847,8 +7847,8 @@ switch (priv->ieee->iw_mode) { case IW_MODE_ADHOC: hdr_len = IEEE80211_3ADDR_LEN; - unicast = !is_broadcast_ether_addr(hdr->addr1) && - !is_multicast_ether_addr(hdr->addr1); + unicast = !is_broadcast_ieee80211_addr(hdr->addr1) && + !is_multicast_ieee80211_addr(hdr->addr1); id = ipw_find_station(priv, hdr->addr1); if (id == IPW_INVALID_STATION) { id = ipw_add_station(priv, hdr->addr1); @@ -7863,8 +7863,8 @@ case IW_MODE_INFRA: default: - unicast = !is_broadcast_ether_addr(hdr->addr3) && - !is_multicast_ether_addr(hdr->addr3); + unicast = !is_broadcast_ieee80211_addr(hdr->addr3) && + !is_multicast_ieee80211_addr(hdr->addr3); hdr_len = IEEE80211_3ADDR_LEN; id = 0; break; -- Jiri Benc SUSE Labs From juliokriger@gmail.com Tue May 24 08:41:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 08:42:01 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OFfvXq006341 for ; Tue, 24 May 2005 08:41:58 -0700 Received: by zproxy.gmail.com with SMTP id 34so2003945nzf for ; Tue, 24 May 2005 08:41:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dpsWoZ0e/sanDt0iaeSCTCiPrmT8nHNnQxN4OglmyL1/UBwonAL8k58lAPgz3rU/NwiMErT6qNOmxm3TIUB2XfMe1+C8umcxb6hdX28Xr9MI9RvPA8eIMo0evp5bxZ/KQYUvCGn5M1L823vwhYPhk7ko2csjtxD6oFjl0qSOxEA= Received: by 10.36.19.19 with SMTP id 19mr650488nzs; Tue, 24 May 2005 08:41:12 -0700 (PDT) Received: by 10.36.8.5 with HTTP; Tue, 24 May 2005 08:41:11 -0700 (PDT) Message-ID: <682bc30a050524084136fa2fe3@mail.gmail.com> Date: Tue, 24 May 2005 12:41:11 -0300 From: Julio Kriger Reply-To: Julio Kriger To: Stephen Hemminger Subject: Re: [PATCH] netem: fix logic bug in reorder conditional Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org In-Reply-To: <20050523140055.127f1a9f@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> <682bc30a05052116005bc813a2@mail.gmail.com> <20050523104342.78b1032d@dxpl.pdx.osdl.net> <682bc30a050523135534b38b8b@mail.gmail.com> <20050523140055.127f1a9f@dxpl.pdx.osdl.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4OFfvXq006341 X-archive-position: 1592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juliokriger@gmail.com Precedence: bulk X-list: netdev Content-Length: 1147 Lines: 28 > > 2) If I set latency = 50ms and a jitter = 300ms, tabledist can give me > > a negative number. This value is addes to cb->time_to_send, so it > > could change it to a negative value. Should we only accept positives > > number before add it to cb->time_to_send? or will > > q->qdisc->enqueue(skb, q->qdisc) put the package on the queue in a > > special way so it will be handled "before" other packages alrealy on > > the queue but with gretaer time_to_send? > > probably should bound the value to 0 before the addition, to avoid large > wraparound problems, but since enqueue checks for for time it will work > as long as delta less than 2^32/2. > I think the value should be restricted to be positive and greater than zero. Becuase if a negative number is allowed we will be "losing" packages to be reordered, hence we will not be reordering, say 25%, of packages instead we will be reordering about 15%. In other words, packages that should be reordered will not be reordered because its new time to send will be the same as the old time to send. Regards, Julio -- ---------------------------- Julio Kriger mailto:juliokriger@gmail.com From rick.jones2@hp.com Tue May 24 09:15:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 09:16:04 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OGFuXq007815 for ; Tue, 24 May 2005 09:15:58 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 3753841A4C2 for ; Tue, 24 May 2005 09:12:22 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id JAA22331 for ; Tue, 24 May 2005 09:12:21 -0700 (PDT) Message-ID: <42935265.3040103@hp.com> Date: Tue, 24 May 2005 09:12:21 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [PATCH] Super TSO v3 References: <20050524003208.GA25778@gondor.apana.org.au> <20050523.192917.48530622.davem@davemloft.net> <20050524023256.GA29242@gondor.apana.org.au> <20050523.193817.112290763.davem@davemloft.net> In-Reply-To: <20050523.193817.112290763.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 995 Lines: 24 David S. Miller wrote: > From: Herbert Xu > Date: Tue, 24 May 2005 12:32:57 +1000 > > >>True, the Nagle algorithm itself aims to do something different >>from this function. However, the act of turning Nagle off is >>an indication that the application wants to minimise the latency >>by sending things out ASAP. So we should either respect that >>here by not delaying the packets to increase the TSO size, or >>we'll need a new socket option to do that for TSO. > > > Sure, we can check tp->nonagle to turn this deferring off. > > But, I bet there are folks who want traditional Nagle turned > off, yet TSO chunking enabled. I'm not sure there will be very many of those. I would have thought the folks who turn-off Nagle are typically doing small sends. If they were not wanting to wait to aggregate their small sends into MSS segments, or wait for the RTT, I doubt thet are looking to wait to aggregate to something larger than the MSS. rick jones From paulg@cs.yorku.ca Tue May 24 10:00:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 10:00:42 -0700 (PDT) Received: from silver.cs.yorku.ca (silver.cs.yorku.ca [130.63.86.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OH0cXq009951 for ; Tue, 24 May 2005 10:00:38 -0700 Received: from [130.63.90.185] (helo=jazzy.cs.yorku.ca.cs.yorku.ca ident=root) by silver.cs.yorku.ca with esmtp (Exim 4.51) id 1Dackx-0000g6-Qq for netdev@oss.sgi.com; Tue, 24 May 2005 12:59:53 -0400 Date: Tue, 24 May 2005 12:59:51 -0400 From: Paul Griffith To: netdev@oss.sgi.com Subject: tcp_mem setting bytes or memory pages Message-ID: <20050524125951.C11337@cs.yorku.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 1595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paulg@cs.yorku.ca Precedence: bulk X-list: netdev Content-Length: 240 Lines: 12 Greetings, I have been searching the Internet for a final answer what the values in net.ipv4.tcp_mem mean. I have seen some sites say it is in memory pages (4K blocks) and other have said it is in KB. What the real answer? Thanks Paul From tgraf@suug.ch Tue May 24 10:02:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 10:02:44 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OH2aXq010533 for ; Tue, 24 May 2005 10:02:37 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id D6EDA1C0EB; Tue, 24 May 2005 19:02:07 +0200 (CEST) Date: Tue, 24 May 2005 19:02:07 +0200 From: Thomas Graf To: netdev@oss.sgi.com Subject: [PATCH] neighbour tables via rtnetlink v2 Message-ID: <20050524170207.GL15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 1596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 23522 Lines: 742 Setting of values is still untested due to missing userspace part but reading of the configuration and the statistics works. Example libnl output including full statistics: arp_cache entries 2 reachable 26s 156msec retrans 1s thresh1 128 thresh2 512 thresh3 1024 key-len 4 entry-size 152 last-flush 24m 19s 474msec hash-rand 0xC7089C95/0x00000003 gc 1 last-rand 4s 472msec refcnt 1 qlen 3 proxy-qlen 64 locktime 1s base-reachable 30s app-probes 0 ucast-probes 3 mcast-probes 3 gc-stale-time 1m probe-delay 5s anycast-delay 1s proxy-delay 800msec lookups 65 hits 62 failed 0 allocations 3 destroys 1 hash-grows 1 forced-gc-runs 0 periodic-gc-runs 387 rcv-unicast-probes 0 rcv-multicast-probes 0 and for device specific parameter sets: arp_cache reachable 22s 443msec retrans 1s refcnt 3 qlen 3 proxy-qlen 64 locktime 1s base-reachable 30s app-probes 0 ucast-probes 3 mcast-probes 3 gc-stale-time 1m probe-delay 5s anycast-delay 1s proxy-delay 800msec I use msecs for all time values instead of user HZ and seconds to allow for greater precision and less headache for userspace. Attached are 3 patches, new netlink and rtnetlink shortcuts for prettier message building and the actual new code. [NETLINK] New message building macros NLMSG_NEW(skb, pid, sequence, type, length) Start a new netlink message, returns message header. NLMSG_NEW_ANSWER(skb, nlcb, type, length) Start a new netlink message as answer to a request, returns message header. NLMSG_END(skb, nlh) End a netlink message, fixes total message length, returns skb->len. NLMSG_CANCEL(skb, nlh) Cancel the building process and trim whole message from skb again, returns -1. Signed-off-by: Thomas Graf --- commit 7250be2b3e192904e66ce314a3d2d2e46bc8bce2 tree 4f7a765c06386f20a3a9b68eea4efd57e2b354ad parent d1faeaeb95a05275cf0c5b51b88f2fa833434625 author Thomas Graf Tue, 24 May 2005 14:26:10 +0200 committer Thomas Graf Tue, 24 May 2005 14:26:10 +0200 include/linux/netlink.h | 22 ++++++++++++++++++++-- 1 files changed, 20 insertions(+), 2 deletions(-) Index: include/linux/netlink.h =================================================================== --- c6f827347b3c6c28bc55a8eb1e62ea2659202cab/include/linux/netlink.h (mode:100644) +++ 4f7a765c06386f20a3a9b68eea4efd57e2b354ad/include/linux/netlink.h (mode:100644) @@ -170,9 +170,27 @@ return nlh; } +#define NLMSG_END(skb, nlh) \ +({ (nlh)->nlmsg_len = (skb)->tail - (unsigned char *) (nlh); \ + skb->len; }) + +#define NLMSG_CANCEL(skb, nlh) \ +({ skb_trim((skb), (unsigned char *) (nlh) - (skb)->data); \ + -1; }) + #define NLMSG_PUT(skb, pid, seq, type, len) \ -({ if (skb_tailroom(skb) < (int)NLMSG_SPACE(len)) goto nlmsg_failure; \ - __nlmsg_put(skb, pid, seq, type, len); }) +({ if (skb_tailroom(skb) < (int)NLMSG_SPACE(len)) \ + goto nlmsg_failure; \ + __nlmsg_put(skb, pid, seq, type, len); }) + +#define NLMSG_NEW(skb, pid, seq, type, len) \ +({ struct nlmsghdr *_hdr = NLMSG_PUT(skb, pid, seq, type, len); \ + _hdr->nlmsg_flags = pid ? NLM_F_MULTI : 0; \ + _hdr; }) + +#define NLMSG_NEW_ANSWER(skb, cb, type, len) \ + NLMSG_NEW(skb, NETLINK_CB((cb)->skb).pid, \ + (cb)->nlh->nlmsg_seq, type, len) extern int netlink_dump_start(struct sock *ssk, struct sk_buff *skb, struct nlmsghdr *nlh, [RTNETLINK] Routing attribute related shortcuts RTA_GET_U(32|64)(tlv) Assumes tlv is a u32/u64 field and returns its value. RTA_GET_[M]SECS(tlv) Assumes tlv is a u64 and transports jiffies converted to seconds or milliseconds and returns its value. RTA_PUT_U(32|64)(skb, type, value) Appends %value as fixed u32/u64 to %skb as TLV %type. RTA_PUT_[M]SECS(skb, type, jiffies) Converts %jiffies to secs/msecs and appends it as u64 to %skb as TLV %type. RTA_PUT_STRING(skb, type, string) Appends %NUL terminated %string to %skb as TLV %type. RTA_NEST(skb, type) Starts a nested TLV %type and returns the nesting handle. RTA_END_NEST(skb, nesting_handle) Finishes the nested TLV %nesting_handle, must be called symmetric to RTA_NEST(). Signed-off-by: Thomas Graf --- commit edab564809178ad08753d8d620fc9b518898fd79 tree d3a4a96913f779af77cd3486cdeb701dc92efed0 parent 7250be2b3e192904e66ce314a3d2d2e46bc8bce2 author Thomas Graf Tue, 24 May 2005 18:47:38 +0200 committer Thomas Graf Tue, 24 May 2005 18:47:38 +0200 include/linux/rtnetlink.h | 37 +++++++++++++++++++++++++++++++++++++ 1 files changed, 37 insertions(+) Index: include/linux/rtnetlink.h =================================================================== --- 4f7a765c06386f20a3a9b68eea4efd57e2b354ad/include/linux/rtnetlink.h (mode:100644) +++ d3a4a96913f779af77cd3486cdeb701dc92efed0/include/linux/rtnetlink.h (mode:100644) @@ -123,8 +123,20 @@ #define RTA_DATA(rta) ((void*)(((char*)(rta)) + RTA_LENGTH(0))) #define RTA_PAYLOAD(rta) ((int)((rta)->rta_len) - RTA_LENGTH(0)) +#define RTA_GET_U32(rta) \ +({ if (!rta || RTA_PAYLOAD(rta) < sizeof(u32)) \ + goto rtattr_failure; \ + *(u32 *) RTA_DATA(rta); }) +#define RTA_GET_U64(rta) \ +({ u64 _tmp; \ + if (!rta || RTA_PAYLOAD(rta) < sizeof(u64)) \ + goto rtattr_failure; \ + memcpy(&_tmp, RTA_DATA(rta), sizeof(_tmp)); \ + _tmp; }) +#define RTA_GET_SECS(rta) ((unsigned long) RTA_GET_U64(rta) * HZ) +#define RTA_GET_MSECS(rta) (msecs_to_jiffies((unsigned long) RTA_GET_U64(rta))) /****************************************************************************** * Definitions used in routing table administration. @@ -789,6 +801,31 @@ ({ if (unlikely(skb_tailroom(skb) < (int)(attrlen))) \ goto rtattr_failure; \ memcpy(skb_put(skb, RTA_ALIGN(attrlen)), data, attrlen); }) + +#define RTA_PUT_U32(skb, attrtype, value) \ +({ u32 _tmp = (value); \ + RTA_PUT(skb, attrtype, sizeof(u32), &_tmp); }) + +#define RTA_PUT_U64(skb, attrtype, value) \ +({ u64 _tmp = (value); \ + RTA_PUT(skb, attrtype, sizeof(u64), &_tmp); }) + +#define RTA_PUT_SECS(skb, attrtype, value) \ + RTA_PUT_U64(skb, attrtype, (value) / HZ) + +#define RTA_PUT_MSECS(skb, attrtype, value) \ + RTA_PUT_U64(skb, attrtype, jiffies_to_msecs(value)) + +#define RTA_PUT_STRING(skb, attrtype, value) \ + RTA_PUT(skb, attrtype, strlen(value) + 1, value) + +#define RTA_NEST(skb, type) \ +({ struct rtattr *__start = (struct rtattr *) (skb)->tail; \ + RTA_PUT(skb, type, 0, NULL); \ + __start; }) + +#define RTA_END_NEST(skb, start) \ +({ (start)->rta_len = ((skb)->tail - (unsigned char *) (start)); }) static inline struct rtattr * __rta_reserve(struct sk_buff *skb, int attrtype, int attrlen) [NEIGH] neighbour table configuration and statistics via rtnetlink Signed-off-by: Thomas Graf --- commit 51565b40aef15f4e4b5748f9d71121e029bc4fe7 tree 7fdf80f0bf19d8ed075ee7f423173f0838c87683 parent edab564809178ad08753d8d620fc9b518898fd79 author Thomas Graf Tue, 24 May 2005 18:48:08 +0200 committer Thomas Graf Tue, 24 May 2005 18:48:08 +0200 include/linux/rtnetlink.h | 94 +++++++++++++ include/net/neighbour.h | 4 net/core/neighbour.c | 310 +++++++++++++++++++++++++++++++++++++++++++- net/core/rtnetlink.c | 20 +- security/selinux/nlmsgtab.c | 2 5 files changed, 419 insertions(+), 11 deletions(-) Index: include/linux/rtnetlink.h =================================================================== --- d3a4a96913f779af77cd3486cdeb701dc92efed0/include/linux/rtnetlink.h (mode:100644) +++ 7fdf80f0bf19d8ed075ee7f423173f0838c87683/include/linux/rtnetlink.h (mode:100644) @@ -89,6 +89,13 @@ RTM_GETANYCAST = 62, #define RTM_GETANYCAST RTM_GETANYCAST + RTM_NEWNEIGHTBL = 64, +#define RTM_NEWNEIGHTBL RTM_NEWNEIGHTBL + RTM_GETNEIGHTBL = 66, +#define RTM_GETNEIGHTBL RTM_GETNEIGHTBL + RTM_SETNEIGHTBL, +#define RTM_SETNEIGHTBL RTM_SETNEIGHTBL + __RTM_MAX, #define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1) }; @@ -505,6 +512,93 @@ __u32 ndm_refcnt; }; + +/***************************************************************** + * Neighbour tables specific messages. + * + * Message Ordering: + * Phase 1: foreach neighbour table + * neighbour table base configuration and statistics + * NDTA_NAME, NDTA_CONFIG, NDTA_THRESH[1-3], NDTA_STATS + * NDTA_PARMS + * + * Phase 2: foreach neighbour table device parameter set + * NDTA_NAME, NDTA_PARMS + ****/ + +struct ndt_stats +{ + __u64 ndts_allocs; + __u64 ndts_destroys; + __u64 ndts_hash_grows; + __u64 ndts_res_failed; + __u64 ndts_lookups; + __u64 ndts_hits; + __u64 ndts_rcv_probes_mcast; + __u64 ndts_rcv_probes_ucast; + __u64 ndts_periodic_gc_runs; + __u64 ndts_forced_gc_runs; +}; + +enum { + NDTPA_UNSPEC, + NDTPA_IFINDEX, /* u32, read-only */ + NDTPA_REFCNT, /* u32, read-only */ + NDTPA_REACHABLE_TIME, /* u64, msecs, read-only */ + NDTPA_BASE_REACHABLE_TIME, /* u64, msecs */ + NDTPA_RETRANS_TIME, /* u64, msecs */ + NDTPA_GC_STALETIME, /* u64, msecs */ + NDTPA_DELAY_PROBE_TIME, /* u64, msecs */ + NDTPA_QUEUE_LEN, /* u32 */ + NDTPA_APP_PROBES, /* u32 */ + NDTPA_UCAST_PROBES, /* u32 */ + NDTPA_MCAST_PROBES, /* u32 */ + NDTPA_ANYCAST_DELAY, /* u64, msecs */ + NDTPA_PROXY_DELAY, /* u64, msecs */ + NDTPA_PROXY_QLEN, /* u32 */ + NDTPA_LOCKTIME, /* u64, msecs */ + __NDTPA_MAX +}; +#define NDTPA_MAX (__NDTPA_MAX - 1) + +struct ndtmsg +{ + __u8 ndtm_family; + __u8 ndtm_pad1; + __u16 ndtm_pad2; +}; + +struct ndt_config +{ + __u16 ndtc_key_len; + __u16 ndtc_entry_size; + __u32 ndtc_entries; + __u32 ndtc_last_flush; /* delta to now in msecs */ + __u32 ndtc_last_rand; /* delta to now in msecs */ + __u32 ndtc_hash_rnd; + __u32 ndtc_hash_mask; + __u32 ndtc_hash_chain_gc; + __u32 ndtc_proxy_qlen; +}; + +enum { + NDTA_UNSPEC, + NDTA_NAME, /* char * */ + NDTA_THRESH1, /* u32 */ + NDTA_THRESH2, /* u32 */ + NDTA_THRESH3, /* u32 */ + NDTA_CONFIG, /* struct ndt_config */ + NDTA_PARMS, /* NDTPA_* */ + NDTA_STATS, /* struct ndt_stats */ + __NDTA_MAX +}; +#define NDTA_MAX (__NDTA_MAX - 1) + +#define NDTA_RTA(r) ((struct rtattr*)(((char*)(r)) + \ + NLMSG_ALIGN(sizeof(struct ndtmsg)))) +#define NDTA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ndtmsg)) + + /**** * General form of address family dependent message. ****/ Index: include/net/neighbour.h =================================================================== --- d3a4a96913f779af77cd3486cdeb701dc92efed0/include/net/neighbour.h (mode:100644) +++ 7fdf80f0bf19d8ed075ee7f423173f0838c87683/include/net/neighbour.h (mode:100644) @@ -65,6 +65,7 @@ struct neigh_parms { + struct net_device *dev; struct neigh_parms *next; int (*neigh_setup)(struct neighbour *); struct neigh_table *tbl; @@ -252,6 +253,9 @@ extern int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); extern void neigh_app_ns(struct neighbour *n); +extern int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb); +extern int neightbl_set(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); + extern void neigh_for_each(struct neigh_table *tbl, void (*cb)(struct neighbour *, void *), void *cookie); extern void __neigh_for_each_release(struct neigh_table *tbl, int (*cb)(struct neighbour *)); extern void pneigh_for_each(struct neigh_table *tbl, void (*cb)(struct pneigh_entry *)); Index: net/core/neighbour.c =================================================================== --- d3a4a96913f779af77cd3486cdeb701dc92efed0/net/core/neighbour.c (mode:100644) +++ 7fdf80f0bf19d8ed075ee7f423173f0838c87683/net/core/neighbour.c (mode:100644) @@ -1276,9 +1276,14 @@ INIT_RCU_HEAD(&p->rcu_head); p->reachable_time = neigh_rand_reach_time(p->base_reachable_time); - if (dev && dev->neigh_setup && dev->neigh_setup(dev, p)) { - kfree(p); - return NULL; + if (dev) { + if (dev->neigh_setup && dev->neigh_setup(dev, p)) { + kfree(p); + return NULL; + } + + dev_hold(dev); + p->dev = dev; } p->sysctl_table = NULL; write_lock_bh(&tbl->lock); @@ -1309,6 +1314,8 @@ *p = parms->next; parms->dead = 1; write_unlock_bh(&tbl->lock); + if (parms->dev) + dev_put(parms->dev); call_rcu(&parms->rcu_head, neigh_rcu_free_parms); return; } @@ -1546,6 +1553,301 @@ return err; } +static int neightbl_fill_parms(struct sk_buff *skb, struct neigh_parms *parms) +{ + struct rtattr *nest_parms = RTA_NEST(skb, NDTA_PARMS); + + if (parms->dev) + RTA_PUT_U32(skb, NDTPA_IFINDEX, parms->dev->ifindex); + + RTA_PUT_U32(skb, NDTPA_REFCNT, atomic_read(&parms->refcnt)); + RTA_PUT_U32(skb, NDTPA_QUEUE_LEN, parms->queue_len); + RTA_PUT_U32(skb, NDTPA_PROXY_QLEN, parms->proxy_qlen); + RTA_PUT_U32(skb, NDTPA_APP_PROBES, parms->app_probes); + RTA_PUT_U32(skb, NDTPA_UCAST_PROBES, parms->ucast_probes); + RTA_PUT_U32(skb, NDTPA_MCAST_PROBES, parms->mcast_probes); + RTA_PUT_MSECS(skb, NDTPA_REACHABLE_TIME, parms->reachable_time); + RTA_PUT_MSECS(skb, NDTPA_BASE_REACHABLE_TIME, + parms->base_reachable_time); + RTA_PUT_MSECS(skb, NDTPA_GC_STALETIME, parms->gc_staletime); + RTA_PUT_MSECS(skb, NDTPA_DELAY_PROBE_TIME, parms->delay_probe_time); + RTA_PUT_MSECS(skb, NDTPA_RETRANS_TIME, parms->retrans_time); + RTA_PUT_MSECS(skb, NDTPA_ANYCAST_DELAY, parms->anycast_delay); + RTA_PUT_MSECS(skb, NDTPA_PROXY_DELAY, parms->proxy_delay); + RTA_PUT_MSECS(skb, NDTPA_LOCKTIME, parms->locktime); + + RTA_END_NEST(skb, nest_parms); + return 0; + +rtattr_failure: + return -1; +} + +static int neightbl_fill_info(struct neigh_table *tbl, struct sk_buff *skb, + struct netlink_callback *cb) +{ + struct nlmsghdr *nlh; + struct ndtmsg *ndtmsg; + + nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg)); + ndtmsg = NLMSG_DATA(nlh); + + read_lock_bh(&tbl->lock); + ndtmsg->ndtm_family = tbl->family; + + RTA_PUT_STRING(skb, NDTA_NAME, tbl->id); + RTA_PUT_U32(skb, NDTA_THRESH1, tbl->gc_thresh1); + RTA_PUT_U32(skb, NDTA_THRESH2, tbl->gc_thresh2); + RTA_PUT_U32(skb, NDTA_THRESH3, tbl->gc_thresh3); + + { + unsigned long now = jiffies; + unsigned int flush_delta = now - tbl->last_flush; + unsigned int rand_delta = now - tbl->last_rand; + + struct ndt_config ndc = { + .ndtc_key_len = tbl->key_len, + .ndtc_entry_size = tbl->entry_size, + .ndtc_entries = atomic_read(&tbl->entries), + .ndtc_last_flush = jiffies_to_msecs(flush_delta), + .ndtc_last_rand = jiffies_to_msecs(rand_delta), + .ndtc_hash_rnd = tbl->hash_rnd, + .ndtc_hash_mask = tbl->hash_mask, + .ndtc_hash_chain_gc = tbl->hash_chain_gc, + .ndtc_proxy_qlen = tbl->proxy_queue.qlen, + }; + + RTA_PUT(skb, NDTA_CONFIG, sizeof(ndc), &ndc); + } + + { + int cpu; + struct ndt_stats ndst; + + memset(&ndst, 0, sizeof(ndst)); + + for (cpu = 0; cpu < NR_CPUS; cpu++) { + struct neigh_statistics *st; + + if (!cpu_possible(cpu)) + continue; + + st = per_cpu_ptr(tbl->stats, cpu); + ndst.ndts_allocs += st->allocs; + ndst.ndts_destroys += st->destroys; + ndst.ndts_hash_grows += st->hash_grows; + ndst.ndts_res_failed += st->res_failed; + ndst.ndts_lookups += st->lookups; + ndst.ndts_hits += st->hits; + ndst.ndts_rcv_probes_mcast += st->rcv_probes_mcast; + ndst.ndts_rcv_probes_ucast += st->rcv_probes_ucast; + ndst.ndts_periodic_gc_runs += st->periodic_gc_runs; + ndst.ndts_forced_gc_runs += st->forced_gc_runs; + } + + RTA_PUT(skb, NDTA_STATS, sizeof(ndst), &ndst); + } + + BUG_ON(tbl->parms.dev); + if (neightbl_fill_parms(skb, &tbl->parms) < 0) + goto rtattr_failure; + + read_unlock_bh(&tbl->lock); + return NLMSG_END(skb, nlh); + +rtattr_failure: + read_unlock_bh(&tbl->lock); + return NLMSG_CANCEL(skb, nlh); + +nlmsg_failure: + return -1; +} + +static int neightbl_fill_param_info(struct neigh_table *tbl, + struct neigh_parms *parms, + struct sk_buff *skb, + struct netlink_callback *cb) +{ + struct ndtmsg *ndtmsg; + struct nlmsghdr *nlh; + + nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg)); + ndtmsg = NLMSG_DATA(nlh); + + read_lock_bh(&tbl->lock); + ndtmsg->ndtm_family = tbl->family; + RTA_PUT_STRING(skb, NDTA_NAME, tbl->id); + + if (neightbl_fill_parms(skb, parms) < 0) + goto rtattr_failure; + + read_unlock_bh(&tbl->lock); + return NLMSG_END(skb, nlh); + +rtattr_failure: + read_unlock_bh(&tbl->lock); + return NLMSG_CANCEL(skb, nlh); + +nlmsg_failure: + return -1; +} + +static inline struct neigh_parms *lookup_neigh_params(struct neigh_table *tbl, + int ifindex) +{ + struct neigh_parms *p; + + for (p = &tbl->parms; p; p = p->next) + if ((p->dev && p->dev->ifindex == ifindex) || + (!p->dev && !ifindex)) + return p; + + return NULL; +} + +int neightbl_set(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg) +{ + struct neigh_table *tbl; + struct ndtmsg *ndtmsg = NLMSG_DATA(nlh); + struct rtattr **tb = arg; + int err = -EINVAL; + + if (!tb[NDTA_NAME - 1] || !RTA_PAYLOAD(tb[NDTA_NAME - 1])) + return -EINVAL; + + read_lock(&neigh_tbl_lock); + for (tbl = neigh_tables; tbl; tbl = tbl->next) { + if (ndtmsg->ndtm_family && tbl->family != ndtmsg->ndtm_family) + continue; + + if (!rtattr_strcmp(tb[NDTA_NAME - 1], tbl->id)) + break; + } + + if (tbl == NULL) { + err = -ENOENT; + goto errout; + } + + /* + * We acquire tbl->lock to be nice to the periodic timers and + * make sure they always see a consistent set of values. + */ + write_lock_bh(&tbl->lock); + + if (tb[NDTA_THRESH1 - 1]) + tbl->gc_thresh1 = RTA_GET_U32(tb[NDTA_THRESH1 - 1]); + + if (tb[NDTA_THRESH2 - 1]) + tbl->gc_thresh2 = RTA_GET_U32(tb[NDTA_THRESH2 - 1]); + + if (tb[NDTA_THRESH3 - 1]) + tbl->gc_thresh3 = RTA_GET_U32(tb[NDTA_THRESH3 - 1]); + + if (tb[NDTA_PARMS - 1]) { + struct rtattr *tbp[NDTPA_MAX]; + struct neigh_parms *p; + u32 ifindex = 0; + + if (rtattr_parse_nested(tbp, NDTPA_MAX, tb[NDTA_PARMS - 1]) < 0) + goto rtattr_failure; + + if (tbp[NDTPA_IFINDEX - 1]) + ifindex = RTA_GET_U32(tbp[NDTPA_IFINDEX - 1]); + + p = lookup_neigh_params(tbl, ifindex); + if (p == NULL) { + err = -ENOENT; + goto rtattr_failure; + } + + if (tbp[NDTPA_QUEUE_LEN - 1]) + p->queue_len = RTA_GET_U32(tbp[NDTPA_QUEUE_LEN - 1]); + + if (tbp[NDTPA_PROXY_QLEN - 1]) + p->proxy_qlen = RTA_GET_U32(tbp[NDTPA_PROXY_QLEN - 1]); + + if (tbp[NDTPA_APP_PROBES - 1]) + p->app_probes = RTA_GET_U32(tbp[NDTPA_APP_PROBES - 1]); + + if (tbp[NDTPA_UCAST_PROBES - 1]) + p->ucast_probes = + RTA_GET_U32(tbp[NDTPA_UCAST_PROBES - 1]); + + if (tbp[NDTPA_MCAST_PROBES - 1]) + p->mcast_probes = + RTA_GET_U32(tbp[NDTPA_MCAST_PROBES - 1]); + + if (tbp[NDTPA_BASE_REACHABLE_TIME - 1]) + p->base_reachable_time = + RTA_GET_MSECS(tbp[NDTPA_BASE_REACHABLE_TIME - 1]); + + if (tbp[NDTPA_GC_STALETIME - 1]) + p->gc_staletime = + RTA_GET_MSECS(tbp[NDTPA_GC_STALETIME - 1]); + + if (tbp[NDTPA_DELAY_PROBE_TIME - 1]) + p->delay_probe_time = + RTA_GET_MSECS(tbp[NDTPA_DELAY_PROBE_TIME - 1]); + + if (tbp[NDTPA_RETRANS_TIME - 1]) + p->retrans_time = + RTA_GET_MSECS(tbp[NDTPA_RETRANS_TIME - 1]); + + if (tbp[NDTPA_ANYCAST_DELAY - 1]) + p->anycast_delay = + RTA_GET_MSECS(tbp[NDTPA_ANYCAST_DELAY - 1]); + + if (tbp[NDTPA_PROXY_DELAY - 1]) + p->proxy_delay = + RTA_GET_MSECS(tbp[NDTPA_PROXY_DELAY - 1]); + + if (tbp[NDTPA_LOCKTIME - 1]) + p->locktime = RTA_GET_MSECS(tbp[NDTPA_LOCKTIME - 1]); + } + + err = 0; + +rtattr_failure: + write_unlock_bh(&tbl->lock); +errout: + read_unlock(&neigh_tbl_lock); + return err; +} + +int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb) +{ + int idx, family; + int s_idx = cb->args[0]; + struct neigh_table *tbl; + + family = ((struct rtgenmsg *)NLMSG_DATA(cb->nlh))->rtgen_family; + + read_lock(&neigh_tbl_lock); + for (tbl = neigh_tables, idx = 0; tbl; tbl = tbl->next) { + struct neigh_parms *p; + + if (idx < s_idx || (family && tbl->family != family)) + continue; + + if (neightbl_fill_info(tbl, skb, cb) <= 0) + break; + + for (++idx, p = tbl->parms.next; p; p = p->next, idx++) { + if (idx < s_idx) + continue; + + if (neightbl_fill_param_info(tbl, p, skb, cb) <= 0) + goto out; + } + + } +out: + read_unlock(&neigh_tbl_lock); + cb->args[0] = idx; + + return skb->len; +} static int neigh_fill_info(struct sk_buff *skb, struct neighbour *n, u32 pid, u32 seq, int event) @@ -2352,6 +2654,8 @@ EXPORT_SYMBOL(neigh_update_hhs); EXPORT_SYMBOL(pneigh_enqueue); EXPORT_SYMBOL(pneigh_lookup); +EXPORT_SYMBOL(neightbl_dump_info); +EXPORT_SYMBOL(neightbl_set); #ifdef CONFIG_ARPD EXPORT_SYMBOL(neigh_app_ns); Index: net/core/rtnetlink.c =================================================================== --- d3a4a96913f779af77cd3486cdeb701dc92efed0/net/core/rtnetlink.c (mode:100644) +++ 7fdf80f0bf19d8ed075ee7f423173f0838c87683/net/core/rtnetlink.c (mode:100644) @@ -100,6 +100,7 @@ [RTM_FAM(RTM_NEWPREFIX)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)), [RTM_FAM(RTM_GETMULTICAST)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)), [RTM_FAM(RTM_GETANYCAST)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)), + [RTM_FAM(RTM_NEWNEIGHTBL)] = NLMSG_LENGTH(sizeof(struct ndtmsg)), }; static const int rta_max[RTM_NR_FAMILIES] = @@ -113,6 +114,7 @@ [RTM_FAM(RTM_NEWTCLASS)] = TCA_MAX, [RTM_FAM(RTM_NEWTFILTER)] = TCA_MAX, [RTM_FAM(RTM_NEWACTION)] = TCAA_MAX, + [RTM_FAM(RTM_NEWNEIGHTBL)] = NDTA_MAX, }; void __rta_fill(struct sk_buff *skb, int attrtype, int attrlen, const void *data) @@ -649,14 +651,16 @@ static struct rtnetlink_link link_rtnetlink_table[RTM_NR_MSGTYPES] = { - [RTM_GETLINK - RTM_BASE] = { .dumpit = rtnetlink_dump_ifinfo }, - [RTM_SETLINK - RTM_BASE] = { .doit = do_setlink }, - [RTM_GETADDR - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, - [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, - [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, - [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, - [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_GETLINK - RTM_BASE] = { .dumpit = rtnetlink_dump_ifinfo }, + [RTM_SETLINK - RTM_BASE] = { .doit = do_setlink }, + [RTM_GETADDR - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, + [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_GETNEIGHTBL - RTM_BASE] = { .dumpit = neightbl_dump_info }, + [RTM_SETNEIGHTBL - RTM_BASE] = { .doit = neightbl_set }, }; static int rtnetlink_event(struct notifier_block *this, unsigned long event, void *ptr) Index: security/selinux/nlmsgtab.c =================================================================== --- d3a4a96913f779af77cd3486cdeb701dc92efed0/security/selinux/nlmsgtab.c (mode:100644) +++ 7fdf80f0bf19d8ed075ee7f423173f0838c87683/security/selinux/nlmsgtab.c (mode:100644) @@ -63,6 +63,8 @@ { RTM_GETPREFIX, NETLINK_ROUTE_SOCKET__NLMSG_READ }, { RTM_GETMULTICAST, NETLINK_ROUTE_SOCKET__NLMSG_READ }, { RTM_GETANYCAST, NETLINK_ROUTE_SOCKET__NLMSG_READ }, + { RTM_GETNEIGHTBL, NETLINK_ROUTE_SOCKET__NLMSG_READ }, + { RTM_SETNEIGHTBL, NETLINK_ROUTE_SOCKET__NLMSG_WRITE }, }; static struct nlmsg_perm nlmsg_firewall_perms[] = From shemminger@osdl.org Tue May 24 09:57:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 09:58:00 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OGvuXq009615 for ; Tue, 24 May 2005 09:57:57 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4OGv7jA004715 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 May 2005 09:57:08 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4OGv7nh005864; Tue, 24 May 2005 09:57:07 -0700 Date: Tue, 24 May 2005 09:57:07 -0700 From: Stephen Hemminger To: Julio Kriger Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] netem: fix logic bug in reorder conditional Message-ID: <20050524095707.678f77ba@dxpl.pdx.osdl.net> In-Reply-To: <682bc30a050524084136fa2fe3@mail.gmail.com> References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> <682bc30a05052116005bc813a2@mail.gmail.com> <20050523104342.78b1032d@dxpl.pdx.osdl.net> <682bc30a050523135534b38b8b@mail.gmail.com> <20050523140055.127f1a9f@dxpl.pdx.osdl.net> <682bc30a050524084136fa2fe3@mail.gmail.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1677 Lines: 33 On Tue, 24 May 2005 12:41:11 -0300 Julio Kriger wrote: > > > 2) If I set latency = 50ms and a jitter = 300ms, tabledist can give me > > > a negative number. This value is addes to cb->time_to_send, so it > > > could change it to a negative value. Should we only accept positives > > > number before add it to cb->time_to_send? or will > > > q->qdisc->enqueue(skb, q->qdisc) put the package on the queue in a > > > special way so it will be handled "before" other packages alrealy on > > > the queue but with gretaer time_to_send? > > > > probably should bound the value to 0 before the addition, to avoid large > > wraparound problems, but since enqueue checks for for time it will work > > as long as delta less than 2^32/2. > > > > I think the value should be restricted to be positive and greater than > zero. Becuase if a negative number is allowed we will be "losing" > packages to be reordered, hence we will not be reordering, say 25%, of > packages instead we will be reordering about 15%. > In other words, packages that should be reordered will not be > reordered because its new time to send will be the same as the old > time to send. > Regards, > Julio The problem is that the user specification (latency 50ms +/- 300ms with reordering) is problematic. Just like specifying reordering without delay (and a fast connection). I chose to keep the original method of reordering by putting things at front of the queue. Another alternative would be to keep a side-stack of packets to wait for reordering. The problem with that is that if no following packet arrives, we end up holding onto the last packet forever; and that would be bad. From jheffner@psc.edu Tue May 24 10:10:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 10:10:27 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OHAOXq011480 for ; Tue, 24 May 2005 10:10:24 -0700 Received: from homer.psc.edu (homer.psc.edu [128.182.61.117]) by mailer1.psc.edu (8.13.3/8.13.3) with ESMTP id j4OH9bdm020752 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 May 2005 13:09:37 -0400 (EDT) From: John Heffner Organization: PSC To: Paul Griffith Subject: Re: tcp_mem setting bytes or memory pages Date: Tue, 24 May 2005 13:09:38 -0400 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <20050524125951.C11337@cs.yorku.ca> In-Reply-To: <20050524125951.C11337@cs.yorku.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505241309.38771.jheffner@psc.edu> X-archive-position: 1597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 558 Lines: 15 On Tuesday 24 May 2005 12:59 pm, Paul Griffith wrote: > Greetings, > > I have been searching the Internet for a final answer what the values > in net.ipv4.tcp_mem mean. > > I have seen some sites say it is in memory pages (4K blocks) and other > have said it is in KB. What the real answer? It's in pages, as described in Documentation/networking/ip-sysctl.txt. A lot of people have this wrong. If you find any incorrect sites, could you point them out or send mail to their maintainers? I've gotten a few corrected that I've noticed so far. -John From davej@redhat.com Tue May 24 10:25:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 10:25:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OHPAXq012343 for ; Tue, 24 May 2005 10:25:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4OHOM1h014584; Tue, 24 May 2005 13:24:22 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4OHOHO15938; Tue, 24 May 2005 13:24:17 -0400 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j4OHOHCt028843; Tue, 24 May 2005 13:24:17 -0400 Received: (from davej@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) id j4OHOG5u028828; Tue, 24 May 2005 13:24:16 -0400 X-Authentication-Warning: devserv.devel.redhat.com: davej set sender to davej@redhat.com using -f Date: Tue, 24 May 2005 13:24:16 -0400 From: Dave Jones To: Jiri Benc Cc: NetDev , pavel@suse.cz Subject: Re: [1-2/6] ipw2100, ipw2200: patches to merge to kernel Message-ID: <20050524172416.GB10479@redhat.com> References: <20050524150711.01632672@griffin.suse.cz> <20050524151506.48e5db65@griffin.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524151506.48e5db65@griffin.suse.cz> User-Agent: Mutt/1.4.1i X-archive-position: 1598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@redhat.com Precedence: bulk X-list: netdev Content-Length: 933 Lines: 30 On Tue, May 24, 2005 at 03:15:06PM +0200, Jiri Benc wrote: > Patches to merge the ipw2100 and ipw2200 drivers to the kernel can be > downloaded from: > http://jikos.cz/~jbohac/wifi/import-ipw2100.patch > http://jikos.cz/~jbohac/wifi/import-ipw2200.patch > (they are too large to post them here) > > The ipw2100 patch is just a merge of ipw2100 driver with Pavel Machek's > cleanup patch. It contains a number of bogus uses of HZ. + IPW_DEBUG_INFO("Command completion failed out after %dms.\n", + HOST_COMPLETE_TIMEOUT / (HZ / 100)); .. + schedule_timeout(HZ / 100); .. What I don't understand, is that HZ in kernel-code should be 1000 according to , though for some reason, I've seen divide by zeros, and really strange oopses with this code. It's as if its for some reason, choosing to use the userspace HZ definition. Hmm, does it need an explicit include of perhaps ? Dave From juliokriger@gmail.com Tue May 24 10:28:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 10:28:36 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OHSVXq012888 for ; Tue, 24 May 2005 10:28:31 -0700 Received: by zproxy.gmail.com with SMTP id 34so2051939nzf for ; Tue, 24 May 2005 10:27:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y0rYAGOAOWYeTwa7q6/HfcfyiD4MoRwBDgilZqn3eYCJZZuBgrkeSVik/ByqOH7Ck9AAiOHqZmWHTubTXEwJSKK2SrVtr232FNtACa3/xXt+oAy/omk0heq58B1YEdSuyoB4rd0LTazSLdAI3mpdo0qAfI07s4q6W5qsBUf3rRo= Received: by 10.36.157.16 with SMTP id f16mr716724nze; Tue, 24 May 2005 10:27:44 -0700 (PDT) Received: by 10.36.8.5 with HTTP; Tue, 24 May 2005 10:27:44 -0700 (PDT) Message-ID: <682bc30a05052410277a9652a1@mail.gmail.com> Date: Tue, 24 May 2005 14:27:44 -0300 From: Julio Kriger Reply-To: Julio Kriger To: Stephen Hemminger Subject: Re: [PATCH] netem: fix logic bug in reorder conditional Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org In-Reply-To: <20050524095707.678f77ba@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> <682bc30a05052116005bc813a2@mail.gmail.com> <20050523104342.78b1032d@dxpl.pdx.osdl.net> <682bc30a050523135534b38b8b@mail.gmail.com> <20050523140055.127f1a9f@dxpl.pdx.osdl.net> <682bc30a050524084136fa2fe3@mail.gmail.com> <20050524095707.678f77ba@dxpl.pdx.osdl.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4OHSVXq012888 X-archive-position: 1599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juliokriger@gmail.com Precedence: bulk X-list: netdev Content-Length: 1815 Lines: 44 On 5/24/05, Stephen Hemminger wrote: > On Tue, 24 May 2005 12:41:11 -0300 > Julio Kriger wrote: > > > > > 2) If I set latency = 50ms and a jitter = 300ms, tabledist can give me > > > > a negative number. This value is addes to cb->time_to_send, so it > > > > could change it to a negative value. Should we only accept positives > > > > number before add it to cb->time_to_send? or will > > > > q->qdisc->enqueue(skb, q->qdisc) put the package on the queue in a > > > > special way so it will be handled "before" other packages alrealy on > > > > the queue but with gretaer time_to_send? > > > > > > probably should bound the value to 0 before the addition, to avoid large > > > wraparound problems, but since enqueue checks for for time it will work > > > as long as delta less than 2^32/2. > > > > > > > I think the value should be restricted to be positive and greater than > > zero. Becuase if a negative number is allowed we will be "losing" > > packages to be reordered, hence we will not be reordering, say 25%, of > > packages instead we will be reordering about 15%. > > In other words, packages that should be reordered will not be > > reordered because its new time to send will be the same as the old > > time to send. > > Regards, > > Julio > > The problem is that the user specification (latency 50ms +/- 300ms with reordering) > is problematic. Just like specifying reordering without delay (and a fast connection). I agree with you. Maybe changing the actual parameters to a "range" could be a better solution. Say "I want delay a package between 50 and 300 ms with correlation of 50% and normal distribution". The code should not change too much, I think. Regards, Julio -- ---------------------------- Julio Kriger mailto:juliokriger@gmail.com From paulg@cs.yorku.ca Tue May 24 10:38:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 10:38:52 -0700 (PDT) Received: from silver.cs.yorku.ca (ns1.cs.yorku.ca [130.63.86.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OHcnXq013679 for ; Tue, 24 May 2005 10:38:49 -0700 Received: from [130.63.90.185] (helo=jazzy.cs.yorku.ca.cs.yorku.ca ident=root) by silver.cs.yorku.ca with esmtp (Exim 4.51) id 1DadLv-00056W-Np; Tue, 24 May 2005 13:38:04 -0400 Date: Tue, 24 May 2005 13:38:03 -0400 From: Paul Griffith To: John Heffner Cc: netdev@oss.sgi.com Subject: Tuning GigE NFS / Re: tcp_mem setting bytes or memory pages Message-ID: <20050524133803.D11337@cs.yorku.ca> References: <20050524125951.C11337@cs.yorku.ca> <200505241309.38771.jheffner@psc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200505241309.38771.jheffner@psc.edu>; from jheffner@psc.edu on Tue, May 24, 2005 at 01:09:38PM -0400 X-archive-position: 1600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paulg@cs.yorku.ca Precedence: bulk X-list: netdev Content-Length: 1835 Lines: 54 On Tue, May 24, 2005 at 01:09:38PM -0400, John Heffner wrote: > On Tuesday 24 May 2005 12:59 pm, Paul Griffith wrote: > > Greetings, > > > > I have been searching the Internet for a final answer what the values > > in net.ipv4.tcp_mem mean. > > > > I have seen some sites say it is in memory pages (4K blocks) and other > > have said it is in KB. What the real answer? > > It's in pages, as described in Documentation/networking/ip-sysctl.txt. A lot > of people have this wrong. If you find any incorrect sites, could you point > them out or send mail to their maintainers? I've gotten a few corrected that > I've noticed so far. > > -John Thanks for cleaning that up. I wanted to know, because I am tasked with tunning a Linux NFS/SMB server on GigE. Details below: Hardware: P4/2.8Ghz/1GB/40GB HDD/G4 FX5200 Intel 865PERL 1) When I boot with v2.4.29 on my local computer tcp_mem set to the following: cat /proc/sys/net/ipv4/tcp_mem 49152 65536 98304 (192MB) (256MB) (384MB) 2) When I boot the same computer with Knoppix v3.8.2 - v2.6.11.8 #3 cat /proc/sys/net/ipv4/tcp_mem 196608 262144 393216 (768MB) (1024MB) (1536MB) 3) When I boot the same computer with Slax v5.0.5 - v2.6.11.8 #1 cat /proc/sys/net/ipv4/tcp_mem 98304 131073 196608 (384MB) (512MB) (768MB) I can understand the change in the tcp stack from 2.4.x to 2.6.x. What I don't understand is why one level of the 2.6.11.8 #3 kernel will set my max TCP_MEM to 1.5 * MEMORY and the other 2.6.11.8 #1 sets TCP_MEM to .75 * MEMORY. Anyone one has any idea what is going on here??? I am trying to understand the tcp stack in Linux because I have to tune a GigE Linux based NFS/SMB server to as our departmental fileserver. The server is currently using the default tcp settings on 2.4.26 [patched to support quotas on RiserFS]. Thanks Paul From adobriyan@gmail.com Tue May 24 10:43:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 10:43:22 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OHhJXq014281 for ; Tue, 24 May 2005 10:43:19 -0700 Received: by wproxy.gmail.com with SMTP id 68so351652wra for ; Tue, 24 May 2005 10:42:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=d6KjWHlT5h2CV/3L53Jw2YOuZEgOKROYdo0hRBG2tagzf/I80n5BDApzUnzSzPYZtpxwf3ZHyvIEzKv32wm7AcFrzbFjYTrd49mRyyp4W1jp+6ulc3uaWyI5DOPz6Yr785Bjtqg3xyqYCNw4OpiZuKWX5J5z06x8Nh3tR1jyVPA= Received: by 10.54.138.5 with SMTP id l5mr669243wrd; Tue, 24 May 2005 10:42:34 -0700 (PDT) Received: from mipter.zuzino.mipt.ru ([217.10.38.130]) by mx.gmail.com with ESMTP id 13sm1425590wrl.2005.05.24.10.42.30; Tue, 24 May 2005 10:42:34 -0700 (PDT) From: Alexey Dobriyan To: netdev@oss.sgi.com Subject: [PATCH] tokenring: be'ify trh_hdr, trllc, rif_cache_s Date: Tue, 24 May 2005 21:46:53 +0400 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505242146.53270.adobriyan@gmail.com> X-archive-position: 1601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: netdev Content-Length: 1273 Lines: 38 Signed-off-by: Alexey Dobriyan --- linux-sparse-000/include/linux/if_tr.h 2005-05-24 08:49:03.000000000 +0400 +++ linux-sparse-001/include/linux/if_tr.h 2005-05-24 18:57:09.000000000 +0400 @@ -36,8 +36,8 @@ struct trh_hdr { __u8 fc; /* frame control field */ __u8 daddr[TR_ALEN]; /* destination address */ __u8 saddr[TR_ALEN]; /* source address */ - __u16 rcf; /* route control field */ - __u16 rseg[8]; /* routing registers */ + __be16 rcf; /* route control field */ + __be16 rseg[8]; /* routing registers */ }; #ifdef __KERNEL__ @@ -55,7 +55,7 @@ struct trllc { __u8 ssap; /* source SAP */ __u8 llc; /* LLC control field */ __u8 protid[3]; /* protocol id */ - __u16 ethertype; /* ether type field */ + __be16 ethertype; /* ether type field */ }; /* Token-Ring statistics collection data. */ --- linux-sparse-000/net/802/tr.c 2005-05-24 08:49:20.000000000 +0400 +++ linux-sparse-001/net/802/tr.c 2005-05-24 19:06:12.000000000 +0400 @@ -50,8 +50,8 @@ static void rif_check_expire(unsigned lo struct rif_cache_s { unsigned char addr[TR_ALEN]; int iface; - __u16 rcf; - __u16 rseg[8]; + __be16 rcf; + __be16 rseg[8]; struct rif_cache_s *next; unsigned long last_used; unsigned char local_ring; From adobriyan@gmail.com Tue May 24 10:44:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 10:44:43 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OHifXq014801 for ; Tue, 24 May 2005 10:44:41 -0700 Received: by wproxy.gmail.com with SMTP id 68so352269wra for ; Tue, 24 May 2005 10:43:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=DDNW0+wazjxt9AzGhcoLFlQDqNYz3TNcjdNx52PAoSpq9EBUWiLiBR4+Qo2vxjhV/i686SDsJ9vBzyuAZcsHNiY07vnVVAcN2ULhahDDBVsS6dQZ9CWw4SYvXX0mapyb0ffbuhjCdxgCda0FGjgDjjy6i40ad6/pPr7GgdHn6ks= Received: by 10.54.11.33 with SMTP id 33mr667539wrk; Tue, 24 May 2005 10:43:55 -0700 (PDT) Received: from mipter.zuzino.mipt.ru ([217.10.38.130]) by mx.gmail.com with ESMTP id d6sm1215258wra.2005.05.24.10.43.45; Tue, 24 May 2005 10:43:55 -0700 (PDT) From: Alexey Dobriyan To: netdev@oss.sgi.com Subject: [PATCH] net/802/tr.c: s/struct rif_cache_s/struct rif_cache/ Date: Tue, 24 May 2005 21:48:03 +0400 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505242148.03588.adobriyan@gmail.com> X-archive-position: 1602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: netdev Content-Length: 2690 Lines: 97 "_s" suffix is certainly of hungarian origin. Signed-off-by: Alexey Dobriyan --- linux-sparse-001/net/802/tr.c 2005-05-24 19:08:47.000000000 +0400 +++ linux-s/net/802/tr.c 2005-05-24 21:42:33.000000000 +0400 @@ -47,12 +47,12 @@ static void rif_check_expire(unsigned lo * Each RIF entry we learn is kept this way */ -struct rif_cache_s { +struct rif_cache { unsigned char addr[TR_ALEN]; int iface; __be16 rcf; __be16 rseg[8]; - struct rif_cache_s *next; + struct rif_cache *next; unsigned long last_used; unsigned char local_ring; }; @@ -64,7 +64,7 @@ struct rif_cache_s { * up a lot. */ -static struct rif_cache_s *rif_table[RIF_TABLE_SIZE]; +static struct rif_cache *rif_table[RIF_TABLE_SIZE]; static DEFINE_SPINLOCK(rif_lock); @@ -249,7 +249,7 @@ void tr_source_route(struct sk_buff *skb { int slack; unsigned int hash; - struct rif_cache_s *entry; + struct rif_cache *entry; unsigned char *olddata; static const unsigned char mcast_func_addr[] = {0xC0,0x00,0x00,0x04,0x00,0x00}; @@ -337,7 +337,7 @@ printk("source routing for %02X:%02X:%02 static void tr_add_rif_info(struct trh_hdr *trh, struct net_device *dev) { unsigned int hash, rii_p = 0; - struct rif_cache_s *entry; + struct rif_cache *entry; spin_lock_bh(&rif_lock); @@ -373,7 +373,7 @@ printk("adding rif_entry: addr:%02X:%02X * FIXME: We ought to keep some kind of cache size * limiting and adjust the timers to suit. */ - entry=kmalloc(sizeof(struct rif_cache_s),GFP_ATOMIC); + entry=kmalloc(sizeof(struct rif_cache),GFP_ATOMIC); if(!entry) { @@ -435,7 +435,7 @@ static void rif_check_expire(unsigned lo spin_lock_bh(&rif_lock); for(i =0; i < RIF_TABLE_SIZE; i++) { - struct rif_cache_s *entry, **pentry; + struct rif_cache *entry, **pentry; pentry = rif_table+i; while((entry=*pentry) != NULL) { @@ -467,10 +467,10 @@ static void rif_check_expire(unsigned lo #ifdef CONFIG_PROC_FS -static struct rif_cache_s *rif_get_idx(loff_t pos) +static struct rif_cache *rif_get_idx(loff_t pos) { int i; - struct rif_cache_s *entry; + struct rif_cache *entry; loff_t off = 0; for(i = 0; i < RIF_TABLE_SIZE; i++) @@ -493,7 +493,7 @@ static void *rif_seq_start(struct seq_fi static void *rif_seq_next(struct seq_file *seq, void *v, loff_t *pos) { int i; - struct rif_cache_s *ent = v; + struct rif_cache *ent = v; ++*pos; @@ -522,7 +522,7 @@ static void rif_seq_stop(struct seq_file static int rif_seq_show(struct seq_file *seq, void *v) { int j, rcf_len, segment, brdgnmb; - struct rif_cache_s *entry = v; + struct rif_cache *entry = v; if (v == SEQ_START_TOKEN) seq_puts(seq, From tgraf@suug.ch Tue May 24 10:56:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 10:56:47 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OHuhXq015851 for ; Tue, 24 May 2005 10:56:44 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id F10A61C0EB; Tue, 24 May 2005 19:56:19 +0200 (CEST) Date: Tue, 24 May 2005 19:56:19 +0200 From: Thomas Graf To: Dave Jones Cc: Jiri Benc , NetDev , pavel@suse.cz Subject: Re: [1-2/6] ipw2100, ipw2200: patches to merge to kernel Message-ID: <20050524175619.GM15391@postel.suug.ch> References: <20050524150711.01632672@griffin.suse.cz> <20050524151506.48e5db65@griffin.suse.cz> <20050524172416.GB10479@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524172416.GB10479@redhat.com> X-archive-position: 1603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1231 Lines: 32 * Dave Jones <20050524172416.GB10479@redhat.com> 2005-05-24 13:24 > On Tue, May 24, 2005 at 03:15:06PM +0200, Jiri Benc wrote: > > Patches to merge the ipw2100 and ipw2200 drivers to the kernel can be > > downloaded from: > > http://jikos.cz/~jbohac/wifi/import-ipw2100.patch > > http://jikos.cz/~jbohac/wifi/import-ipw2200.patch > > (they are too large to post them here) > > > > The ipw2100 patch is just a merge of ipw2100 driver with Pavel Machek's > > cleanup patch. > > It contains a number of bogus uses of HZ. > > + IPW_DEBUG_INFO("Command completion failed out after %dms.\n", > + HOST_COMPLETE_TIMEOUT / (HZ / 100)); > > .. > > + schedule_timeout(HZ / 100); > > .. > > What I don't understand, is that HZ in kernel-code should be 1000 > according to , though for some reason, I've seen > divide by zeros, and really strange oopses with this code. > It's as if its for some reason, choosing to use the userspace HZ > definition. Hmm, does it need an explicit include of > perhaps ? It should really use jiffies_to_msecs/usecs. HZ is < 100 on some architectures and thus results in a division by 0, even it was safe, the above code is inaccurate for some values of HZ. From eparis@parisplace.org Tue May 24 11:31:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 11:31:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OIVUXq018101 for ; Tue, 24 May 2005 11:31:30 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4OIUfSe005195; Tue, 24 May 2005 14:30:41 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4OIUUO04350; Tue, 24 May 2005 14:30:30 -0400 Received: from wbar1.sjo1-4-4-004-002.sjo1.dsl-verizon.net (vpn50-38.rdu.redhat.com [172.16.50.38]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j4OIUUsR004626; Tue, 24 May 2005 14:30:30 -0400 Subject: Re: [PATCH] bonding using arp_ip_target may stay down with active path From: Eric Paris To: Jay Vosburgh Cc: "David S. Miller" , netdev@oss.sgi.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net In-Reply-To: <1116959200.8954.5.camel@localhost.localdomain> References: <200505232121.j4NLLaYa000837@death.nxdomain.ibm.com> <1116959200.8954.5.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 24 May 2005 14:31:02 -0400 Message-Id: <1116959462.8954.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-archive-position: 1605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eparis@parisplace.org Precedence: bulk X-list: netdev Content-Length: 1462 Lines: 39 It ate my tabs again. This mailer is going out the window. -Eric On Tue, 2005-05-24 at 14:26 -0400, Eric Paris wrote: > >On Mon, 2005-05-23 at 14:21 -0700, Jay Vosburgh wrote: > David S. Miller wrote: > >Patch doesn't apply, tabs turned into spaces by your > >email client. > > > > As penance for test applying trivial patches by hand, here's a > >proper version. > > > > -J > > > >--- > > -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com > > I guess I should be in the signed off list as the original author. > sorry I'm an idiot and copied and pasted my original message (to the > bonding-devel list) which screwed up the spacing. > > Signed-off-by: Eric Paris > Signed-off-by: Jay Vosburgh > > diff -urN linux-2.6.11/drivers/net/bonding/bond_main.c linux-2.6.11-fix/drivers/net/bonding/bond_main.c > --- linux-2.6.11/drivers/net/bonding/bond_main.c 2005-05-23 14:07:37.000000000 -0700 > +++ linux-2.6.11-fix/drivers/net/bonding/bond_main.c 2005-05-23 14:08:13.000000000 -0700 > @@ -3046,7 +3046,7 @@ > bond_set_slave_inactive_flags(bond->current_arp_slave); > > /* search for next candidate */ > - bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave) { > + bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave->next) { > if (IS_UP(slave->dev)) { > slave->link = BOND_LINK_BACK; > bond_set_slave_active_flags(slave); > From eparis@parisplace.org Tue May 24 11:27:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 11:27:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OIR0Xq017497 for ; Tue, 24 May 2005 11:27:00 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4OIQ9bu003688; Tue, 24 May 2005 14:26:09 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4OIQ9O02841; Tue, 24 May 2005 14:26:09 -0400 Received: from wbar1.sjo1-4-4-004-002.sjo1.dsl-verizon.net (vpn50-38.rdu.redhat.com [172.16.50.38]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j4OIQ8sR003874; Tue, 24 May 2005 14:26:09 -0400 Subject: Re: [PATCH] bonding using arp_ip_target may stay down with active path From: Eric Paris To: Jay Vosburgh Cc: "David S. Miller" , netdev@oss.sgi.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net In-Reply-To: <200505232121.j4NLLaYa000837@death.nxdomain.ibm.com> References: <200505232121.j4NLLaYa000837@death.nxdomain.ibm.com> Content-Type: text/plain Date: Tue, 24 May 2005 14:26:40 -0400 Message-Id: <1116959200.8954.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-archive-position: 1604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eparis@parisplace.org Precedence: bulk X-list: netdev Content-Length: 1274 Lines: 33 >On Mon, 2005-05-23 at 14:21 -0700, Jay Vosburgh wrote: David S. Miller wrote: >Patch doesn't apply, tabs turned into spaces by your >email client. > > As penance for test applying trivial patches by hand, here's a >proper version. > > -J > >--- > -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com I guess I should be in the signed off list as the original author. sorry I'm an idiot and copied and pasted my original message (to the bonding-devel list) which screwed up the spacing. Signed-off-by: Eric Paris Signed-off-by: Jay Vosburgh diff -urN linux-2.6.11/drivers/net/bonding/bond_main.c linux-2.6.11-fix/drivers/net/bonding/bond_main.c --- linux-2.6.11/drivers/net/bonding/bond_main.c 2005-05-23 14:07:37.000000000 -0700 +++ linux-2.6.11-fix/drivers/net/bonding/bond_main.c 2005-05-23 14:08:13.000000000 -0700 @@ -3046,7 +3046,7 @@ bond_set_slave_inactive_flags(bond->current_arp_slave); /* search for next candidate */ - bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave) { + bond_for_each_slave_from(bond, slave, i, bond->current_arp_slave->next) { if (IS_UP(slave->dev)) { slave->link = BOND_LINK_BACK; bond_set_slave_active_flags(slave); From ganesh.venkatesan@gmail.com Tue May 24 11:37:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 11:37:43 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OIbYXq018771 for ; Tue, 24 May 2005 11:37:34 -0700 Received: by zproxy.gmail.com with SMTP id 8so2008775nzo for ; Tue, 24 May 2005 11:36:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rseGm8SLVExYsc3Z8u6E0HJ+nNIqm8m3W6N1pCRfdqCYfVdVUeE3GF32tkulq4+2IKLiXwhL+L4EbjwxHaE9b1hzDt495kqufklOEOR1ZzHTiQ0b/qd1f749PwkMcxNgjFypvkbheEbCaLiJEHJ/XOr5vD1QHXX8blyft0akV8I= Received: by 10.36.19.18 with SMTP id 18mr1993252nzs; Tue, 24 May 2005 11:36:49 -0700 (PDT) Received: by 10.36.65.5 with HTTP; Tue, 24 May 2005 11:36:49 -0700 (PDT) Message-ID: <5fc59ff305052411366b9b058c@mail.gmail.com> Date: Tue, 24 May 2005 11:36:49 -0700 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: Andrew Morton Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Cc: netdev@oss.sgi.com, hejianj@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, Anton Blanchard In-Reply-To: <20050516025901.4b26ccf3.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050516025901.4b26ccf3.akpm@osdl.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4OIbYXq018771 X-archive-position: 1606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 3457 Lines: 99 Could you tell me what the rhr test is? Is this an IBM internal test tool? On 5/16/05, Andrew Morton wrote: > > Might be a bug in the e100 driver, might not be. > > I assume this is the > > BUG_ON(skb->list != NULL); > > in __kfree_skb(), although the line number is off-by-one, and the > .__kfree_skb+0x188/0x240 would tend to contradict that. Anton, can you > help work out where we went splat please? > > tx timeouts are fairly rare events, so this might not be a recently-added > bug. > > Do we know if it is repeatable? > > > > Begin forwarded message: > > Date: Mon, 16 May 2005 02:44:04 -0700 > From: bugme-daemon@osdl.org > To: bugme-new@lists.osdl.org > Subject: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 > > > http://bugme.osdl.org/show_bug.cgi?id=4628 > > Summary: Test server hang while running rhr (network) test on > RHEL4 with kernel 2.6.12-rc1-mm4 > Kernel Version: 2.6.12-rc1 with mm4 patch > Status: NEW > Severity: normal > Owner: anton@samba.org > Submitter: hejianj@cn.ibm.com > CC: hanwenb@cn.ibm.com,mridge@us.ibm.com,rende@cn.ibm.com,wa > ngjs@cn.ibm.com > > > Distribution: > RHEL4 with kernel 2.6.12-rc1-mm4 > > Hardware Environment: > IBM OpenPower( CHRP IBM,9124-720 ) > > Software Environment: > RHEL4 > RHR: rhr2-rhel4-1.0-14a.noarch.rpm > > Problem Description: > The test server hang while running rhr (network) test on RHEL4 with kernel > 2.6.12-rc1-mm4. > > Steps to reproduce: > 1. Download kernel 2.6.12-rc1 and 2.6.12-rc1-mm4 patch from kernel.org, then > build the kernel on OpenPower 720 > 2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and install it on > the test machine. > 3. Configure and run the rhr test via invoking redhat-ready. > > Additional information: > Here is the backtrace from xmon. > > 3:mon> e > cpu 0x3: Vector: 700 (Program Check) at [c00000000ffe7920] > pc: c00000000029632c: .__kfree_skb+0x188/0x240 > lr: c000000000296328: .__kfree_skb+0x184/0x240 > sp: c00000000ffe7ba0 > msr: 8000000000029032 > current = 0xc000000107f94040 > paca = 0xc000000000431c00 > pid = 0, comm = swapper > kernel BUG in __kfree_skb at net/core/skbuff.c:282! > > 3:mon> t > [c00000000ffe7c40] d0000000000ebac4 .e100_rx_clean_list+0xa0/0x144 [e100] > [c00000000ffe7ce0] d0000000000ed6dc .e100_tx_timeout+0x7c/0xb0 [e100] > [c00000000ffe7d70] c0000000002b87bc .dev_watchdog+0xc8/0x154 > [c00000000ffe7e00] c00000000006d6b4 .run_timer_softirq+0x180/0x298 > [c00000000ffe7ed0] c0000000000667d8 .__do_softirq+0xdc/0x1b8 > [c00000000ffe7f90] c000000000014bf0 .call_do_softirq+0x14/0x24 > [c000000086b43860] c0000000000102c4 .do_softirq+0x98/0xac > [c000000086b438f0] c0000000000669cc .irq_exit+0x70/0x8c > [c000000086b43970] c000000000011fb8 .timer_interrupt+0x398/0x47c > [c000000086b43a90] c00000000000a2b4 decrementer_common+0xb4/0x100 > --- Exception: 901 (Decrementer) at c000000000010554 .dedicated_idle+0x114/0x280 > [c000000086b43e80] c0000000000108c8 .cpu_idle+0x3c/0x54 > [c000000086b43f00] c00000000003cc8c .start_secondary+0x108/0x148 > [c000000086b43f90] c00000000000bd84 .enable_64b_mode+0x0/0x28 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > From pavel@ucw.cz Tue May 24 11:53:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 11:53:42 -0700 (PDT) Received: from amd.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OIrXXq019553 for ; Tue, 24 May 2005 11:53:37 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 5597D8D187; Tue, 24 May 2005 20:52:41 +0200 (CEST) Date: Tue, 24 May 2005 20:52:41 +0200 From: Pavel Machek To: Jiri Benc Cc: NetDev , LKML , jgarzik@pobox.com Subject: Re: [0/5] Improvements to the ieee80211 layer Message-ID: <20050524185241.GB2470@elf.ucw.cz> References: <20050524150711.01632672@griffin.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524150711.01632672@griffin.suse.cz> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.9i X-archive-position: 1607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: netdev Content-Length: 577 Lines: 15 Hi! > The ieee80211 layer, now present in -mm, lacks many important features > (actually it's just a part of the ipw2100/ipw2200 driver; these cards do > a lot of the processing in the hardware/firmware and thus the layer > currently can not be used for simpler devices). > > This is the first series of patches that try to convert it to a generic > IEEE 802.11 layer, usable for most of today's wireless cards. Are they against -rc4-mm2? Would it be possible to put agregate patch on the web somewhere (or git tree?). I would certainly be easier to test.... Pavel From pavel@ucw.cz Tue May 24 11:59:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 11:59:17 -0700 (PDT) Received: from amd.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OIx9Xq020331 for ; Tue, 24 May 2005 11:59:11 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 9D09D8D187; Tue, 24 May 2005 20:58:20 +0200 (CEST) Date: Tue, 24 May 2005 20:58:20 +0200 From: Pavel Machek To: Jiri Benc Cc: NetDev Subject: Re: [4/6] ipw2100: fix after "ieee80211_device alignment fix" Message-ID: <20050524185820.GC2268@elf.ucw.cz> References: <20050524150711.01632672@griffin.suse.cz> <20050524151802.59124dde@griffin.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050524151802.59124dde@griffin.suse.cz> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.9i X-archive-position: 1608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: netdev Content-Length: 842 Lines: 24 On Út 24-05-05 15:18:02, Jiri Benc wrote: > Fixes ipw2100 after ieee80211_device alignment fix > (patch [2/5] ieee80211: ieee80211_device alignment fix and cleanup) > > > Signed-off-by: Jiri Benc > Signed-off-by: Jirka Bohac > > --- linux-2.6.12-rc2-mm3.01/drivers/net/wireless/ipw2100.c 2005-05-19 16:23:00.000000000 +0200 > +++ linux-2.6.12-rc2-mm3.04/drivers/net/wireless/ipw2100.c 2005-05-19 17:35:48.000000000 +0200 > @@ -1717,7 +1717,7 @@ > /* Called by register_netdev() */ > static int ipw2100_net_init(struct net_device *dev) > { > - struct ipw2100_priv *priv = ieee80211_priv(dev); > + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); > return ipw2100_up(priv, 1); > } Ugh, that is getting rather ugly. Perhaps inline function doing this should be introduced? Pavel From jb@suse.cz Tue May 24 12:31:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 12:31:29 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OJVOXq025527 for ; Tue, 24 May 2005 12:31:25 -0700 Received: from dwarf.suse.cz (dwarf.suse.cz [10.20.1.32]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id D34586282E2; Tue, 24 May 2005 21:30:38 +0200 (CEST) Received: by dwarf.suse.cz (Postfix, from userid 10013) id 0D41712F105; Tue, 24 May 2005 21:18:33 +0200 (CEST) Date: Tue, 24 May 2005 21:18:33 +0200 From: Jirka Bohac To: Pavel Machek Cc: Jiri Benc , NetDev Subject: Re: [4/6] ipw2100: fix after "ieee80211_device alignment fix" Message-ID: <20050524191832.GA10297@dwarf.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> <20050524151802.59124dde@griffin.suse.cz> <20050524185820.GC2268@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050524185820.GC2268@elf.ucw.cz> User-Agent: Mutt/1.5.6i X-archive-position: 1609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbohac@suse.cz Precedence: bulk X-list: netdev Content-Length: 1512 Lines: 44 On Tue, May 24, 2005 at 08:58:20PM +0200, Pavel Machek wrote: > On Út 24-05-05 15:18:02, Jiri Benc wrote: > > Fixes ipw2100 after ieee80211_device alignment fix > > (patch [2/5] ieee80211: ieee80211_device alignment fix and cleanup) > > > > > > Signed-off-by: Jiri Benc > > Signed-off-by: Jirka Bohac > > > > --- linux-2.6.12-rc2-mm3.01/drivers/net/wireless/ipw2100.c 2005-05-19 16:23:00.000000000 +0200 > > +++ linux-2.6.12-rc2-mm3.04/drivers/net/wireless/ipw2100.c 2005-05-19 17:35:48.000000000 +0200 > > @@ -1717,7 +1717,7 @@ > > /* Called by register_netdev() */ > > static int ipw2100_net_init(struct net_device *dev) > > { > > - struct ipw2100_priv *priv = ieee80211_priv(dev); > > + struct ipw2100_priv *priv = ieee80211_priv(netdev_priv(dev)); > > return ipw2100_up(priv, 1); > > } > > > Ugh, that is getting rather ugly. Perhaps inline function doing this > should be introduced? Ok, this is a little ugly, but this driver is slowly getting re-written as work on the ieee80211 layer proceeds. Drivers will not be supposed to use references to struct net_device internally. Instead, they should be using references to struct ieee80211_device -- this will be their interface to the stack, not net_device. So this patch is a quick fix for the driver to work with the unfinished layer. This "call" will disappear when the layer is finished. Both ieee80211_priv() and netdev_priv() are inline. Regards, -- Jirka Bohac SUSE Labs, SUSE CR From shemminger@osdl.org Tue May 24 15:27:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 15:27:09 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4OMR6Xq030647 for ; Tue, 24 May 2005 15:27:06 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4OMQAjA029100 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 May 2005 15:26:11 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4OMQALj021623; Tue, 24 May 2005 15:26:10 -0700 Date: Tue, 24 May 2005 15:26:10 -0700 From: Stephen Hemminger To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: [PATCH] (3/3) netem: allow random reordering (with fix) Message-ID: <20050524152610.256d248a@dxpl.pdx.osdl.net> In-Reply-To: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4912 Lines: 171 Here is a fixed up version of the reorder feature of netem. It is the same as the earlier patch plus with the bugfix from Julio merged in. Has expected backwards compatibility behaviour. Go ahead and merge this one, the TCP strangeness I was seeing was due to the reordering bug, and previous version of TSO patch. Signed-off-by: Stephen Hemminger Index: netem/include/linux/pkt_sched.h =================================================================== --- netem.orig/include/linux/pkt_sched.h +++ netem/include/linux/pkt_sched.h @@ -427,6 +427,7 @@ enum TCA_NETEM_UNSPEC, TCA_NETEM_CORR, TCA_NETEM_DELAY_DIST, + TCA_NETEM_REORDER, __TCA_NETEM_MAX, }; @@ -437,7 +438,7 @@ struct tc_netem_qopt __u32 latency; /* added delay (us) */ __u32 limit; /* fifo limit (packets) */ __u32 loss; /* random packet loss (0=none ~0=100%) */ - __u32 gap; /* re-ordering gap (0 for delay all) */ + __u32 gap; /* re-ordering gap (0 for none) */ __u32 duplicate; /* random packet dup (0=none ~0=100%) */ __u32 jitter; /* random jitter in latency (us) */ }; @@ -449,6 +450,12 @@ struct tc_netem_corr __u32 dup_corr; /* duplicate correlation */ }; +struct tc_netem_reorder +{ + __u32 probability; + __u32 correlation; +}; + #define NETEM_DIST_SCALE 8192 #endif Index: netem/net/sched/sch_netem.c =================================================================== --- netem.orig/net/sched/sch_netem.c +++ netem/net/sched/sch_netem.c @@ -62,11 +62,12 @@ struct netem_sched_data { u32 gap; u32 jitter; u32 duplicate; + u32 reorder; struct crndstate { unsigned long last; unsigned long rho; - } delay_cor, loss_cor, dup_cor; + } delay_cor, loss_cor, dup_cor, reorder_cor; struct disttable { u32 size; @@ -180,23 +181,23 @@ static int netem_enqueue(struct sk_buff q->duplicate = dupsave; } - /* - * Do re-ordering by putting one out of N packets at the front - * of the queue. - * gap == 0 is special case for no-reordering. - */ - if (q->gap == 0 || q->counter != q->gap) { + if (q->gap == 0 /* not doing reordering */ + || q->counter < q->gap /* inside last reordering gap */ + || q->reorder < get_crandom(&q->reorder_cor)) { psched_time_t now; PSCHED_GET_TIME(now); - PSCHED_TADD2(now, - tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist), + PSCHED_TADD2(now, tabledist(q->latency, q->jitter, + &q->delay_cor, q->delay_dist), cb->time_to_send); - ++q->counter; ret = q->qdisc->enqueue(skb, q->qdisc); } else { - q->counter = 0; + /* + * Do re-ordering by putting one out of N packets at the front + * of the queue. + */ PSCHED_GET_TIME(cb->time_to_send); + q->counter = 0; ret = q->qdisc->ops->requeue(skb, q->qdisc); } @@ -351,6 +352,19 @@ static int get_correlation(struct Qdisc return 0; } +static int get_reorder(struct Qdisc *sch, const struct rtattr *attr) +{ + struct netem_sched_data *q = qdisc_priv(sch); + const struct tc_netem_reorder *r = RTA_DATA(attr); + + if (RTA_PAYLOAD(attr) != sizeof(*r)) + return -EINVAL; + + q->reorder = r->probability; + init_crandom(&q->reorder_cor, r->correlation); + return 0; +} + static int netem_change(struct Qdisc *sch, struct rtattr *opt) { struct netem_sched_data *q = qdisc_priv(sch); @@ -371,9 +385,15 @@ static int netem_change(struct Qdisc *sc q->jitter = qopt->jitter; q->limit = qopt->limit; q->gap = qopt->gap; + q->counter = 0; q->loss = qopt->loss; q->duplicate = qopt->duplicate; + /* for compatiablity with earlier versions. + * if gap is set, need to assume 100% probablity + */ + q->reorder = ~0; + /* Handle nested options after initial queue options. * Should have put all options in nested format but too late now. */ @@ -395,6 +415,11 @@ static int netem_change(struct Qdisc *sc if (ret) return ret; } + if (tb[TCA_NETEM_REORDER-1]) { + ret = get_reorder(sch, tb[TCA_NETEM_REORDER-1]); + if (ret) + return ret; + } } @@ -412,7 +437,6 @@ static int netem_init(struct Qdisc *sch, init_timer(&q->timer); q->timer.function = netem_watchdog; q->timer.data = (unsigned long) sch; - q->counter = 0; q->qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); if (!q->qdisc) { @@ -444,6 +468,7 @@ static int netem_dump(struct Qdisc *sch, struct rtattr *rta = (struct rtattr *) b; struct tc_netem_qopt qopt; struct tc_netem_corr cor; + struct tc_netem_reorder reorder; qopt.latency = q->latency; qopt.jitter = q->jitter; @@ -457,6 +482,11 @@ static int netem_dump(struct Qdisc *sch, cor.loss_corr = q->loss_cor.rho; cor.dup_corr = q->dup_cor.rho; RTA_PUT(skb, TCA_NETEM_CORR, sizeof(cor), &cor); + + reorder.probability = q->reorder; + reorder.correlation = q->reorder_cor.rho; + RTA_PUT(skb, TCA_NETEM_REORDER, sizeof(reorder), &reorder); + rta->rta_len = skb->tail - b; return skb->len; From shemminger@osdl.org Tue May 24 16:43:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 16:43:18 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ONhEXq004378 for ; Tue, 24 May 2005 16:43:14 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4ONgJjA002738 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 May 2005 16:42:19 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4ONgJEu024958; Tue, 24 May 2005 16:42:19 -0700 Date: Tue, 24 May 2005 16:42:19 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Harry Edmon Subject: Re: [PATCH] Super TSO v3 Message-ID: <20050524164219.59cc6b01@dxpl.pdx.osdl.net> In-Reply-To: <20050523.121943.78708600.davem@davemloft.net> References: <20050523.121943.78708600.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 253 Lines: 10 On Mon, 23 May 2005 12:19:43 -0700 (PDT) "David S. Miller" wrote: > > Ok, new version. This weekend has been productive. > I wonder if the TSO stuff would fix the performance problems with MacOSX and their broken delayed ack? From shemminger@osdl.org Tue May 24 16:40:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 16:40:34 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ONeUXq004004 for ; Tue, 24 May 2005 16:40:30 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4ONddjA002569 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 May 2005 16:39:40 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4ONddSt024848; Tue, 24 May 2005 16:39:39 -0700 Date: Tue, 24 May 2005 16:39:39 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: 2.6.12-rc4-tcp3 Message-ID: <20050524163939.0fb86509@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 897 Lines: 34 http://developer.osdl.org/shemminger/patches/2.6.12-rc4-tcp3 This is the third revision of the TCP pluggable congestion framework with other network changes (targeted for 2.6.13) Minor tweaks from last time: - startup changed because westwood and hybla need to do setup after initial connection establishment - initialization happens when socket is created (fixes bug with auto module load and preempt). - module refcounting fix for passive opens - cleanup westwood and get rid of too much inlining - latest version of TSO patch included in set - fix min_cwnd undershoot bug for all but legacy reno # Changes involving network core to remove throttling fastroute-stats-remove no-congestion no-throttle bigger-backlog fix-weightp # TSO fixes from dave tcp_ack26 tcp_super_tso_v3 # TCP infrastructure tcp_infra tcp_bic tcp_westwood hstcp hybla vegas h-tcp # Makefile version version From davem@davemloft.net Tue May 24 17:38:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 17:38:36 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P0cQXq006385 for ; Tue, 24 May 2005 17:38:26 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Dajte-0003Yg-Pz; Tue, 24 May 2005 17:37:18 -0700 Date: Tue, 24 May 2005 17:37:18 -0700 (PDT) Message-Id: <20050524.173718.63998428.davem@davemloft.net> To: eparis@parisplace.org Cc: fubar@us.ibm.com, netdev@oss.sgi.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH] bonding using arp_ip_target may stay down with active path From: "David S. Miller" In-Reply-To: <1116959462.8954.6.camel@localhost.localdomain> References: <200505232121.j4NLLaYa000837@death.nxdomain.ibm.com> <1116959200.8954.5.camel@localhost.localdomain> <1116959462.8954.6.camel@localhost.localdomain> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 583 Lines: 15 From: Eric Paris Date: Tue, 24 May 2005 14:31:02 -0400 > It ate my tabs again. This mailer is going out the window. This is why I personally stick to Emacs/MEW and Sylpheed. I tried Evolution for a while long ago, but stopped the first time it refused to read in my entire mbox because it failed to parse a multi-byte character in _one_ of the emails contained within. I'm sure that's fixed, but it's very much a non-ascii-text mailer by default, so you have to pluck with it's configuration a little bit if you're sending patches and code around a lot. From davem@davemloft.net Tue May 24 17:52:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 17:53:00 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P0quXq007325 for ; Tue, 24 May 2005 17:52:56 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Dak7n-0003aQ-BR; Tue, 24 May 2005 17:51:55 -0700 Date: Tue, 24 May 2005 17:51:55 -0700 (PDT) Message-Id: <20050524.175155.35014470.davem@davemloft.net> To: shemminger@osdl.org Cc: netdev@oss.sgi.com, harry@atmos.washington.edu Subject: Re: [PATCH] Super TSO v3 From: "David S. Miller" In-Reply-To: <20050524164219.59cc6b01@dxpl.pdx.osdl.net> References: <20050523.121943.78708600.davem@davemloft.net> <20050524164219.59cc6b01@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 419 Lines: 13 From: Stephen Hemminger Date: Tue, 24 May 2005 16:42:19 -0700 > On Mon, 23 May 2005 12:19:43 -0700 (PDT) > "David S. Miller" wrote: > > > Ok, new version. This weekend has been productive. > > I wonder if the TSO stuff would fix the performance problems with MacOSX > and their broken delayed ack? This is very possible, and people are free to test it out to verify :-) From hejianj@cn.ibm.com Tue May 24 20:20:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 20:20:50 -0700 (PDT) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.com [202.81.18.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P3KfXq015516 for ; Tue, 24 May 2005 20:20:42 -0700 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id j4P3Fg2F383912 for ; Wed, 25 May 2005 13:15:42 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4P3Mja8083944 for ; Wed, 25 May 2005 13:22:45 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11/8.13.3) with ESMTP id j4P3JqI3031569 for ; Wed, 25 May 2005 13:19:53 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av01.au.ibm.com (8.12.11/8.12.11) with ESMTP id j4P3JoVq031536; Wed, 25 May 2005 13:19:51 +1000 In-Reply-To: <5fc59ff305052411366b9b058c@mail.gmail.com> Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 To: Ganesh Venkatesan Cc: Andrew Morton , Anton Blanchard , linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com, Dang En Ren , Lei CDL Wang , Jia Sen Wang X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Jian Jun He Date: Wed, 25 May 2005 11:21:23 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 05/25/2005 11:21:24 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B" X-archive-position: 1615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hejianj@cn.ibm.com Precedence: bulk X-list: netdev Content-Length: 16478 Lines: 451 --0__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B Content-type: multipart/alternative; Boundary="1__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B" --1__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable "rhr" is a "Red Hat Certification Testing Suite". You can download it f= rom redhat.com. Best Regards! Jian Jun He CSDL, Beijing Email: hejianj@cn.ibm.com = Ganesh Venkatesan = = To Andrew Morton = 2005-05-25 02:36 = cc netdev@oss.sgi.com, Jian Jun = He/China/Contr/IBM@IBMCN, = Please respond to linuxppc64-dev@lists.linuxppc.or= g.s Ganesh Venkatesan gi.com, Anton Blanchard = = Subj= ect Re: Fw: [Bugme-new] [Bug 4628] N= ew: Test server hang while running r= hr (network) test on RHEL4 with ker= nel 2.6.12-rc1-mm4 = = = = = = = Could you tell me what the rhr test is? Is this an IBM internal test to= ol? On 5/16/05, Andrew Morton wrote: > > Might be a bug in the e100 driver, might not be. > > I assume this is the > > BUG_ON(skb->list !=3D NULL); > > in __kfree_skb(), although the line number is off-by-one, and the > .__kfree_skb+0x188/0x240 would tend to contradict that. Anton, can y= ou > help work out where we went splat please? > > tx timeouts are fairly rare events, so this might not be a recently-a= dded > bug. > > Do we know if it is repeatable? > > > > Begin forwarded message: > > Date: Mon, 16 May 2005 02:44:04 -0700 > From: bugme-daemon@osdl.org > To: bugme-new@lists.osdl.org > Subject: [Bugme-new] [Bug 4628] New: Test server hang while running r= hr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 > > > http://bugme.osdl.org/show_bug.cgi?id=3D4628 > > Summary: Test server hang while running rhr (network) test= on > RHEL4 with kernel 2.6.12-rc1-mm4 > Kernel Version: 2.6.12-rc1 with mm4 patch > Status: NEW > Severity: normal > Owner: anton@samba.org > Submitter: hejianj@cn.ibm.com > CC: hanwenb@cn.ibm.com,mridge@us.ibm.com,rende@cn.ibm.com,wa > ngjs@cn.ibm.com > > > Distribution: > RHEL4 with kernel 2.6.12-rc1-mm4 > > Hardware Environment: > IBM OpenPower( CHRP IBM,9124-720 ) > > Software Environment: > RHEL4 > RHR: rhr2-rhel4-1.0-14a.noarch.rpm > > Problem Description: > The test server hang while running rhr (network) test on RHEL4 with kernel > 2.6.12-rc1-mm4. > > Steps to reproduce: > 1. Download kernel 2.6.12-rc1 and 2.6.12-rc1-mm4 patch from kernel.or= g, then > build the kernel on OpenPower 720 > 2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and ins= tall it on > the test machine. > 3. Configure and run the rhr test via invoking redhat-ready. > > Additional information: > Here is the backtrace from xmon. > > 3:mon> e > cpu 0x3: Vector: 700 (Program Check) at [c00000000ffe7920] > pc: c00000000029632c: .__kfree_skb+0x188/0x240 > lr: c000000000296328: .__kfree_skb+0x184/0x240 > sp: c00000000ffe7ba0 > msr: 8000000000029032 > current =3D 0xc000000107f94040 > paca =3D 0xc000000000431c00 > pid =3D 0, comm =3D swapper > kernel BUG in __kfree_skb at net/core/skbuff.c:282! > > 3:mon> t > [c00000000ffe7c40] d0000000000ebac4 .e100_rx_clean_list+0xa0/0x144 [e= 100] > [c00000000ffe7ce0] d0000000000ed6dc .e100_tx_timeout+0x7c/0xb0 [e100]= > [c00000000ffe7d70] c0000000002b87bc .dev_watchdog+0xc8/0x154 > [c00000000ffe7e00] c00000000006d6b4 .run_timer_softirq+0x180/0x298 > [c00000000ffe7ed0] c0000000000667d8 .__do_softirq+0xdc/0x1b8 > [c00000000ffe7f90] c000000000014bf0 .call_do_softirq+0x14/0x24 > [c000000086b43860] c0000000000102c4 .do_softirq+0x98/0xac > [c000000086b438f0] c0000000000669cc .irq_exit+0x70/0x8c > [c000000086b43970] c000000000011fb8 .timer_interrupt+0x398/0x47c > [c000000086b43a90] c00000000000a2b4 decrementer_common+0xb4/0x100 > --- Exception: 901 (Decrementer) at c000000000010554 .dedicated_idle+0x114/0x280 > [c000000086b43e80] c0000000000108c8 .cpu_idle+0x3c/0x54 > [c000000086b43f00] c00000000003cc8c .start_secondary+0x108/0x148 > [c000000086b43f90] c00000000000bd84 .enable_64b_mode+0x0/0x28 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > = --1__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

"rhr" is a "Red Hat Certification Testing Suite"= . You can download it from redhat.com.

Best Regards!

Jian Jun He

CSDL, Beijing
Email: hejianj@cn.ibm.com

3D"InactiveGanesh Venkatesan <= ;ganesh.venkatesan@gmail.com>


=
          Ganesh Venkatesan <ganesh.venkatesan@gmail.c= om>

          2005-05-25 02:36
          Please respond to
          Ganesh Venkatesan

 =
3D""
To
3D""
Andrew Morton <akpm@osdl.org>
3D""
cc
3D""
netdev@oss.sgi.com, Jian Jun He/China/Contr/IBM@IBMCN,= linuxppc64-dev@lists.linuxppc.org.sgi.com, Anton Blanchard <anton@s= amba.org>
3D""
Subject
3D""
Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang w= hile running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
3D=3D""

Could you tell me what the rhr test is? Is this an IBM internal tes= t tool?


On 5/16/05, Andrew Morton <akpm@osdl.org> wrote:
>
> Might be a bug in the e100 driver, might not be.
>
> I assume this is the
>
>         BUG_ON(skb->list !=3D NULL);
>
> in __kfree_skb(), although the line number is off-by-one, and the<= br> > .__kfree_skb+0x188/0x240 would tend to contradict that.  Anto= n, can you
> help work out where we went splat please?
>
> tx timeouts are fairly rare events, so this might not be a recentl= y-added
> bug.
>
> Do we know if it is repeatable?
>
>
>
> Begin forwarded message:
>
> Date: Mon, 16 May 2005 02:44:04 -0700
> From: bugme-daemon@osdl.org
> To: bugme-new@lists.osdl.org
> Subject: [Bugme-new] [Bug 4628] New: Test server hang while runnin= g rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
>
>
> = http://bugme.osdl.org/show_bug.cgi?id=3D4628
>
>            Summary: Test server hang= while running rhr (network) test on
>                   &nb= sp; RHEL4 with kernel 2.6.12-rc1-mm4
>     Kernel Version: 2.6.12-rc1 with mm4 patch
>             Status: NEW
>           Severity: normal
>              Owner: anton@samba= .org
>          Submitter: hejianj@cn.ibm.com >                 CC: hanwen= b@cn.ibm.com,mridge@us.ibm.com,rende@cn.ibm.com,wa
>                   &nb= sp; ngjs@cn.ibm.com
>
>
> Distribution:
> RHEL4 with kernel 2.6.12-rc1-mm4
>
> Hardware Environment:
> IBM OpenPower( CHRP IBM,9124-720 )
>
> Software Environment:
> RHEL4
> RHR: rhr2-rhel4-1.0-14a.noarch.rpm
>
> Problem Description:
> The test server hang while running rhr (network) test on RHEL4 wit= h kernel
> 2.6.12-rc1-mm4.
>
> Steps to reproduce:
> 1. Download kernel 2.6.12-rc1 and 2.6.12-rc1-mm4 patch from kernel= .org, then
> build the kernel on OpenPower 720
> 2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and = install it on
> the test machine.
> 3. Configure and run the rhr test via invoking redhat-ready.
>
> Additional information:
> Here is the backtrace from xmon.
>
> 3:mon> e
> cpu 0x3: Vector: 700 (Program Check) at [c00000000ffe7920]
>     pc: c00000000029632c: .__kfree_skb+0x188/0x240
>     lr: c000000000296328: .__kfree_skb+0x184/0x240
>     sp: c00000000ffe7ba0
>    msr: 8000000000029032
>   current =3D 0xc000000107f94040
>   paca    =3D 0xc000000000431c00
>     pid   =3D 0, comm =3D swapper
> kernel BUG in __kfree_skb at net/core/skbuff.c:282!
>
> 3:mon> t
> [c00000000ffe7c40] d0000000000ebac4 .e100_rx_clean_list+0xa0/0x144= [e100]
> [c00000000ffe7ce0] d0000000000ed6dc .e100_tx_timeout+0x7c/0xb0 [e1= 00]
> [c00000000ffe7d70] c0000000002b87bc .dev_watchdog+0xc8/0x154
> [c00000000ffe7e00] c00000000006d6b4 .run_timer_softirq+0x180/0x298=
> [c00000000ffe7ed0] c0000000000667d8 .__do_softirq+0xdc/0x1b8
> [c00000000ffe7f90] c000000000014bf0 .call_do_softirq+0x14/0x24
= > [c000000086b43860] c0000000000102c4 .do_softirq+0x98/0xac
> [c000000086b438f0] c0000000000669cc .irq_exit+0x70/0x8c
> [c000000086b43970] c000000000011fb8 .timer_interrupt+0x398/0x47c > [c000000086b43a90] c00000000000a2b4 decrementer_common+0xb4/0x100<= br> > --- Exception: 901 (Decrementer) at c000000000010554 .dedicated_id= le+0x114/0x280
> [c000000086b43e80] c0000000000108c8 .cpu_idle+0x3c/0x54
> [c000000086b43f00] c00000000003cc8c .start_secondary+0x108/0x148 > [c000000086b43f90] c00000000000bd84 .enable_64b_mode+0x0/0x28
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is= .
>
>

= --1__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B-- --0__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=C7BBFA9FDF82BA1B8f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B Content-type: image/gif; name="pic29731.gif" Content-Disposition: inline; filename="pic29731.gif" Content-ID: <2__=C7BBFA9FDF82BA1B8f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=C7BBFA9FDF82BA1B8f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=C7BBFA9FDF82BA1B8f9e8a93df938690918cC7BBFA9FDF82BA1B-- From michael@ellerman.id.au Tue May 24 22:04:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 22:04:12 -0700 (PDT) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.com [202.81.18.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P53rXq018683 for ; Tue, 24 May 2005 22:04:01 -0700 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id j4P4ws2F259310 for ; Wed, 25 May 2005 14:58:54 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4P55va8145548 for ; Wed, 25 May 2005 15:05:58 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11/8.13.3) with ESMTP id j4P535o4007745 for ; Wed, 25 May 2005 15:03:05 +1000 Received: from ozlabs.au.ibm.com (ozlabs.au.ibm.com [9.190.163.12]) by d23av02.au.ibm.com (8.12.11/8.12.11) with ESMTP id j4P534Dr007729 for ; Wed, 25 May 2005 15:03:05 +1000 Received: from concordia.ozlabs.ibm.com (haven.au.ibm.com [9.190.164.82]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ozlabs.au.ibm.com (Postfix) with ESMTP id 2C60673607 for ; Wed, 25 May 2005 15:03:18 +1000 (EST) From: Michael Ellerman Reply-To: michael@ellerman.id.au To: netdev@oss.sgi.com Subject: [PATCH] add is_multicast_ether_addr() in include/linux/etherdevice.h Date: Wed, 25 May 2005 15:03:00 +1000 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505251503.01039.michael@ellerman.id.au> X-archive-position: 1616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michael@ellerman.id.au Precedence: bulk X-list: netdev Content-Length: 1923 Lines: 57 Hi, This patch adds is_multicast_ether_addr() to go along with is_valid_ether_addr() and friends. It then changes is_valid_ether_addr() to use the new macro, and fixes up the comment on that function to move implementation details out of the API doco. Signed-off-by: Michael Ellerman Index: veth-dev/include/linux/etherdevice.h =================================================================== --- veth-dev.orig/include/linux/etherdevice.h +++ veth-dev/include/linux/etherdevice.h @@ -56,18 +56,32 @@ static inline int is_zero_ether_addr(con } /** + * is_multicast_ether_addr - Determine if the given Ethernet address is a + * multicast address. + * + * @addr: Pointer to a six-byte array containing the Ethernet address + * + * Return true if the address is a multicast address. + */ +static inline int is_multicast_ether_addr(const u8 *addr) +{ + return addr[0] & 0x01; +} + +/** * is_valid_ether_addr - Determine if the given Ethernet address is valid * @addr: Pointer to a six-byte array containing the Ethernet address * * Check that the Ethernet address (MAC) is not 00:00:00:00:00:00, is not - * a multicast address, and is not FF:FF:FF:FF:FF:FF. The multicast - * and FF:FF:... tests are combined into the single test "!(addr[0]&1)". + * a multicast address, and is not FF:FF:FF:FF:FF:FF. * * Return true if the address is valid. */ static inline int is_valid_ether_addr(const u8 *addr) { - return !(addr[0]&1) && !is_zero_ether_addr(addr); + /* FF:FF:FF:FF:FF:FF is a multicast address so we don't need to + * explicitly check for it here. */ + return !is_multicast_ether_addr(addr) && !is_zero_ether_addr(addr); } /** @@ -83,6 +97,6 @@ static inline void random_ether_addr(u8 addr [0] &= 0xfe; /* clear multicast bit */ addr [0] |= 0x02; /* set local assignment bit (IEEE802) */ } -#endif +#endif /* __KERNEL__ */ #endif /* _LINUX_ETHERDEVICE_H */ From yoshfuji@linux-ipv6.org Wed May 25 00:04:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 00:05:01 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P74tXq024948 for ; Wed, 25 May 2005 00:04:56 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 316FF33D10; Wed, 25 May 2005 16:07:04 +0900 (JST) Date: Wed, 25 May 2005 16:07:04 +0900 (JST) Message-Id: <20050525.160704.28910448.yoshfuji@linux-ipv6.org> To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, usagi-core@linux-ipv6.org Subject: [PATCH] NETDEV: fix receiving multicast frames. From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1600 Lines: 37 From: YOSHIFUJI Hideaki Some USB ethernet drivers did not accept multicast frames appropriately. IPv6 did not work with those drivers without this patch. Signed-off-by: YOSHIFUJI Hideaki Index: drivers/usb/net/pegasus.c =================================================================== --- 5b713315560487f8c288820b17061fe27016c2cc/drivers/usb/net/pegasus.c (mode:100644) +++ uncommitted/drivers/usb/net/pegasus.c (mode:100644) @@ -1166,7 +1166,7 @@ pegasus->eth_regs[EthCtrl2] |= RX_PROMISCUOUS; if (netif_msg_link(pegasus)) pr_info("%s: Promiscuous mode enabled.\n", net->name); - } else if ((net->mc_count > multicast_filter_limit) || + } else if (net->mc_count || (net->flags & IFF_ALLMULTI)) { pegasus->eth_regs[EthCtrl0] |= RX_MULTICAST; pegasus->eth_regs[EthCtrl2] &= ~RX_PROMISCUOUS; Index: drivers/usb/net/rtl8150.c =================================================================== --- 5b713315560487f8c288820b17061fe27016c2cc/drivers/usb/net/rtl8150.c (mode:100644) +++ uncommitted/drivers/usb/net/rtl8150.c (mode:100644) @@ -667,7 +667,7 @@ if (netdev->flags & IFF_PROMISC) { dev->rx_creg |= cpu_to_le16(0x0001); info("%s: promiscuous mode", netdev->name); - } else if ((netdev->mc_count > multicast_filter_limit) || + } else if (netdev->mc_count || (netdev->flags & IFF_ALLMULTI)) { dev->rx_creg &= cpu_to_le16(0xfffe); dev->rx_creg |= cpu_to_le16(0x0002); -- YOSHIFUJI Hideaki @ USAGI Project GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yi.zhu@intel.com Tue May 24 23:59:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 24 May 2005 23:59:10 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P6x5Xq022849 for ; Tue, 24 May 2005 23:59:05 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4P6wJTr003716; Wed, 25 May 2005 06:58:19 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4P6wFPq031071; Wed, 25 May 2005 06:58:19 GMT Received: from debian.sh.intel.com ([172.16.219.38]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052423581632389 ; Tue, 24 May 2005 23:58:18 -0700 Subject: Re: [0/5] Improvements to the ieee80211 layer From: Zhu Yi To: Jiri Benc Cc: NetDev , LKML , jgarzik@pobox.com, pavel@suse.cz In-Reply-To: <20050524150711.01632672@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> Content-Type: text/plain Organization: Intel Corp. Date: Wed, 25 May 2005 14:55:16 +0800 Message-Id: <1117004116.3737.30.camel@debian.sh.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yi.zhu@intel.com Precedence: bulk X-list: netdev Content-Length: 1068 Lines: 25 On Tue, 2005-05-24 at 15:07 +0200, Jiri Benc wrote: > The ieee80211 layer, now present in -mm, lacks many important features > (actually it's just a part of the ipw2100/ipw2200 driver; these cards do > a lot of the processing in the hardware/firmware and thus the layer > currently can not be used for simpler devices). > > This is the first series of patches that try to convert it to a generic > IEEE 802.11 layer, usable for most of today's wireless cards. > > The long term plan is: > - to implement a complete 802.11 stack in the kernel, making it easy to > write drivers for simple (cheap) devices > - to implement all of Ad-Hoc, AP and monitor modes in the layer, so it > will be easy to support them in the drivers > - to integrate Wireless Extensions to unify the kernel-userspace > interface of all the drivers Do you just clean up current ieee80211 code to still do 802.11 <-> 802.3 conversion inside the driver or you plan to handle real 802.11 frames in the stack like this? http://oss.sgi.com/archives/netdev/2005-03/msg01405.html Thanks, -yi From yoshfuji@linux-ipv6.org Wed May 25 00:04:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 00:05:00 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P74tXq024942 for ; Wed, 25 May 2005 00:04:55 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 2218433CC2; Wed, 25 May 2005 16:07:00 +0900 (JST) Date: Wed, 25 May 2005 16:06:59 +0900 (JST) Message-Id: <20050525.160659.60635970.yoshfuji@linux-ipv6.org> To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, nakam@linux-ipv6.org, usagi-core@linux-ipv6.org Subject: [PATCH] NETDEV: Elecom (Laneed) LD-USBL/TX support. From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 939 Lines: 23 From: YOSHIFUJI Hideaki Elecom (Laneed) LD-USBL/TX support. Signed-off-by: YOSHIFUJI Hideaki Index: drivers/usb/net/pegasus.h =================================================================== --- 5b713315560487f8c288820b17061fe27016c2cc/drivers/usb/net/pegasus.h (mode:100644) +++ uncommitted/drivers/usb/net/pegasus.h (mode:100644) @@ -249,6 +249,8 @@ DEFAULT_GPIO_RESET) PEGASUS_DEV( "LANEED USB Ethernet LD-USB/TX", VENDOR_LANEED, 0x4002, DEFAULT_GPIO_RESET ) +PEGASUS_DEV( "LANEED USB Ethernet LD-USBL/TX", VENDOR_LANEED, 0x4005, + DEFAULT_GPIO_RESET | PEGASUS_II) PEGASUS_DEV( "LANEED USB Ethernet LD-USB/TX", VENDOR_LANEED, 0x400b, DEFAULT_GPIO_RESET | PEGASUS_II ) PEGASUS_DEV( "LANEED USB Ethernet LD-USB/T", VENDOR_LANEED, 0xabc1, -- YOSHIFUJI Hideaki @ USAGI Project GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Wed May 25 01:20:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 01:20:33 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P8KPXq000503 for ; Wed, 25 May 2005 01:20:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Dar6q-00060w-00; Wed, 25 May 2005 18:19:24 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Dar6g-0002R8-00; Wed, 25 May 2005 18:19:14 +1000 From: Herbert Xu To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / ????) Subject: Re: [PATCH] NETDEV: fix receiving multicast frames. Cc: jgarzik@pobox.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, usagi-core@linux-ipv6.org Organization: Core In-Reply-To: <20050525.160704.28910448.yoshfuji@linux-ipv6.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 25 May 2005 18:19:14 +1000 X-archive-position: 1620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2121 Lines: 44 YOSHIFUJI Hideaki / ???? wrote: > From: YOSHIFUJI Hideaki > > Some USB ethernet drivers did not accept multicast frames appropriately. > IPv6 did not work with those drivers without this patch. > > Signed-off-by: YOSHIFUJI Hideaki > > Index: drivers/usb/net/pegasus.c > =================================================================== > --- 5b713315560487f8c288820b17061fe27016c2cc/drivers/usb/net/pegasus.c (mode:100644) > +++ uncommitted/drivers/usb/net/pegasus.c (mode:100644) > @@ -1166,7 +1166,7 @@ > pegasus->eth_regs[EthCtrl2] |= RX_PROMISCUOUS; > if (netif_msg_link(pegasus)) > pr_info("%s: Promiscuous mode enabled.\n", net->name); > - } else if ((net->mc_count > multicast_filter_limit) || > + } else if (net->mc_count || > (net->flags & IFF_ALLMULTI)) { > pegasus->eth_regs[EthCtrl0] |= RX_MULTICAST; > pegasus->eth_regs[EthCtrl2] &= ~RX_PROMISCUOUS; > Index: drivers/usb/net/rtl8150.c > =================================================================== > --- 5b713315560487f8c288820b17061fe27016c2cc/drivers/usb/net/rtl8150.c (mode:100644) > +++ uncommitted/drivers/usb/net/rtl8150.c (mode:100644) > @@ -667,7 +667,7 @@ > if (netdev->flags & IFF_PROMISC) { > dev->rx_creg |= cpu_to_le16(0x0001); > info("%s: promiscuous mode", netdev->name); > - } else if ((netdev->mc_count > multicast_filter_limit) || > + } else if (netdev->mc_count || > (netdev->flags & IFF_ALLMULTI)) { > dev->rx_creg &= cpu_to_le16(0xfffe); > dev->rx_creg |= cpu_to_le16(0x0002); This patch is correct. However, I presume these chips do actually have filter support so it'd be even better if we could utilise that. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jb@suse.cz Wed May 25 01:42:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 01:43:04 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P8grXq001605 for ; Wed, 25 May 2005 01:42:53 -0700 Received: from dwarf.suse.cz (dwarf.suse.cz [10.20.1.32]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id F3BEF628300; Wed, 25 May 2005 10:42:06 +0200 (CEST) Received: by dwarf.suse.cz (Postfix, from userid 10013) id 42B4A12F105; Wed, 25 May 2005 10:29:57 +0200 (CEST) Date: Wed, 25 May 2005 10:29:57 +0200 From: Jirka Bohac To: Pavel Machek Cc: NetDev Subject: Re: [0/5] Improvements to the ieee80211 layer Message-ID: <20050525082956.GA20739@dwarf.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> <20050524185241.GB2470@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524185241.GB2470@elf.ucw.cz> User-Agent: Mutt/1.5.6i X-archive-position: 1621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbohac@suse.cz Precedence: bulk X-list: netdev Content-Length: 762 Lines: 24 On Tue, May 24, 2005 at 08:52:41PM +0200, Pavel Machek wrote: > > This is the first series of patches that try to convert it to a generic > > IEEE 802.11 layer, usable for most of today's wireless cards. > > Are they against -rc4-mm2? No, they're against -rc3-mm3. The whole ieee80211 layer has been accidentally removed from -rc4-mm3 (see http://lkml.org/lkml/2005/5/18/57 ) > Would it be possible to put agregate patch on the web somewhere (or > git tree?). I would certainly be easier to test.... Hmm, always thought that small patches would be preferred ;-) Here you go: http://jikos.cz/~jbohac/tmp/big_80211_patch_01.patch.bz2 This is combined from all the 11 patches we posted yesterday regards, -- Jirka Bohac SUSE Labs, SUSE CR From pavel@ucw.cz Wed May 25 02:28:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 02:28:53 -0700 (PDT) Received: from amd.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P9SfXq005266 for ; Wed, 25 May 2005 02:28:44 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id CD2418C74A; Wed, 25 May 2005 11:27:10 +0200 (CEST) Date: Wed, 25 May 2005 11:27:10 +0200 From: Pavel Machek To: Jirka Bohac Cc: NetDev Subject: Re: [0/5] Improvements to the ieee80211 layer Message-ID: <20050525092710.GA1926@elf.ucw.cz> References: <20050524150711.01632672@griffin.suse.cz> <20050524185241.GB2470@elf.ucw.cz> <20050525082956.GA20739@dwarf.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050525082956.GA20739@dwarf.suse.cz> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.9i X-archive-position: 1622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: netdev Content-Length: 1515 Lines: 43 Hi! > > > This is the first series of patches that try to convert it to a generic > > > IEEE 802.11 layer, usable for most of today's wireless cards. > > > > Are they against -rc4-mm2? > > No, they're against -rc3-mm3. The whole ieee80211 layer has been > accidentally removed from -rc4-mm3 (see > http://lkml.org/lkml/2005/5/18/57 ) > > > Would it be possible to put agregate patch on the web somewhere (or > > git tree?). I would certainly be easier to test.... > > Hmm, always thought that small patches would be preferred ;-) > Here you go: http://jikos.cz/~jbohac/tmp/big_80211_patch_01.patch.bz2 > This is combined from all the 11 patches we posted yesterday Well, they certainly are prefered for review, but applying series of 11 patches, with two that need to be get from the web is not that easy.... I could not compile it: CC net/ieee80211/ieee80211_rx.o net/ieee80211/ieee80211_rx.c: In function `ieee80211_rx_frame_decrypt': net/ieee80211/ieee80211_rx.c:281: error: `dev' undeclared (first use in this function) net/ieee80211/ieee80211_rx.c:281: error: (Each undeclared identifier is reported only once net/ieee80211/ieee80211_rx.c:281: error: for each function it appears in.) make[2]: *** [net/ieee80211/ieee80211_rx.o] Error 1 make[1]: *** [net/ieee80211] Error 2 make: *** [net] Error 2 468.99user 31.35system 523.98 (8m43.981s) elapsed 95.49%CPU pavel@amd:/data/l/linux-mm$ After fixing that, ipw2100 seems to work. [Funny, it changed name from eth1 to wlan0?] Good. Pavel From jbenc@suse.cz Wed May 25 02:42:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 02:42:57 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4P9grXq006040 for ; Wed, 25 May 2005 02:42:54 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id A10F06282E9; Wed, 25 May 2005 11:42:07 +0200 (CEST) Date: Wed, 25 May 2005 11:42:07 +0200 From: Jiri Benc To: Pavel Machek Cc: Jirka Bohac , NetDev Subject: Re: [0/5] Improvements to the ieee80211 layer Message-ID: <20050525114207.63601e5b@griffin.suse.cz> In-Reply-To: <20050525092710.GA1926@elf.ucw.cz> References: <20050524150711.01632672@griffin.suse.cz> <20050524185241.GB2470@elf.ucw.cz> <20050525082956.GA20739@dwarf.suse.cz> <20050525092710.GA1926@elf.ucw.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 335 Lines: 12 On Wed, 25 May 2005 11:27:10 +0200, Pavel Machek wrote: > net/ieee80211/ieee80211_rx.c:281: error: `dev' undeclared (first use > in this function) Thanks, we had CONFIG_IEEE80211_CRYPT_TKIP disabled when testing as there seem to be more important things to deal with. Will be fixed in the next patch series. -- Jiri Benc SUSE Labs From jbenc@suse.cz Wed May 25 04:21:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 04:21:44 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PBLfXq019226 for ; Wed, 25 May 2005 04:21:42 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 69E336282FC; Wed, 25 May 2005 13:20:55 +0200 (CEST) Date: Wed, 25 May 2005 13:20:55 +0200 From: Jiri Benc To: Zhu Yi Cc: NetDev , jbohac@suse.cz Subject: Re: [0/5] Improvements to the ieee80211 layer Message-ID: <20050525132055.469f10d7@griffin.suse.cz> In-Reply-To: <1117004116.3737.30.camel@debian.sh.intel.com> References: <20050524150711.01632672@griffin.suse.cz> <1117004116.3737.30.camel@debian.sh.intel.com> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 482 Lines: 16 On Wed, 25 May 2005 14:55:16 +0800, Zhu Yi wrote: > Do you just clean up current ieee80211 code to still do 802.11 <-> 802.3 > conversion inside the driver or you plan to handle real 802.11 frames in > the stack like this? > http://oss.sgi.com/archives/netdev/2005-03/msg01405.html We are trying to handle real 802.11 frames. Have you made any progress in your work since posting that patch? If so, could you please post it to netdev (or to us)? Thanks. -- Jiri Benc SUSE Labs From linux-netdev@gmane.org Wed May 25 06:44:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 06:44:50 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PDilXq009781 for ; Wed, 25 May 2005 06:44:48 -0700 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Daw7p-0003GF-HM for netdev@oss.sgi.com; Wed, 25 May 2005 15:40:46 +0200 Received: from 221.216.98.168 ([221.216.98.168]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 May 2005 15:40:45 +0200 Received: from zlfcn by 221.216.98.168 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 May 2005 15:40:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: "zlf" Subject: Searching history network flow data Date: Wed, 25 May 2005 21:34:06 +0800 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 221.216.98.168 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-archive-position: 1625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zlfcn@hotmail.com Precedence: bulk X-list: netdev Content-Length: 229 Lines: 7 Hi, I am targeting network flow statistic and analyse. But without history network flow I can do nothing at all. I am searching it for a long time with no result. Please provide me some history network flow data. Thx. zlf From shemminger@osdl.org Wed May 25 09:15:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 09:15:49 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PGFZXq022699 for ; Wed, 25 May 2005 09:15:40 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4PGERjA002750 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 May 2005 09:14:29 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4PGER2I001277; Wed, 25 May 2005 09:14:27 -0700 Date: Wed, 25 May 2005 09:14:27 -0700 From: Stephen Hemminger To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Message-ID: <20050525091427.35621a21@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 395 Lines: 13 On Tue, 24 May 2005 10:29:25 +0300 (EEST) "Catalin(ux aka Dino) BOIE" wrote: > Hello! > > This patch set bridge device features using the common features of all > slaves. Also, it reacts to features change using ethtool on the slaves. > > This patch depends on NETDEV_FEAT_CHANGE.patch. > I will add it to the next set of patches for bridging. Hold off until 2.6.13 From shemminger@osdl.org Wed May 25 11:33:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 11:33:25 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PIXKXq026794 for ; Wed, 25 May 2005 11:33:20 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4PIWVjA013935 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 May 2005 11:32:32 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4PIWVWR008572; Wed, 25 May 2005 11:32:31 -0700 Date: Wed, 25 May 2005 11:32:31 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: 2.6.12-rc5-tcp3 Message-ID: <20050525113231.4b5fef39@dxpl.pdx.osdl.net> In-Reply-To: <20050524163939.0fb86509@dxpl.pdx.osdl.net> References: <20050524163939.0fb86509@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 391 Lines: 9 http://developer.osdl.org/shemminger/patches/2.6.12-rc5-tcp3 Keep up with the new 2.6.12-rc5 More minor tweaks: - tcp_ack26 is already in rc5 + change to min_cwnd to be same (ie ssthresh/2) for all reno like protocols eventually plan to fix the cwnd undershoot bug http://thread.gmane.org/gmane.linux.network/2094 http://oss.sgi.com/projects/netdev/archive/2005-04/msg00338.html From jheffner@psc.edu Wed May 25 12:51:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 12:51:43 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PJpbXq000464 for ; Wed, 25 May 2005 12:51:38 -0700 Received: from homer.psc.edu (homer.psc.edu [128.182.61.117]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j4PJohdj010844 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 25 May 2005 15:50:43 -0400 (EDT) From: John Heffner Organization: PSC To: Stephen Hemminger Subject: [PATCH] Scalable TCP Date: Wed, 25 May 2005 15:50:41 -0400 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200505251550.42252.jheffner@psc.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4PJpbXq000464 X-archive-position: 1628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 3981 Lines: 120 This patch implements Tom Kelly's Scalable TCP congestion control algorithm for the modular framework. The algorithm has some nice scaling properties, and has been used a fair bit in research, though is known to have significant fairness issues, so it's not really suitable for general purpose use. Signed-off-by: John Heffner Index: net/ipv4/Kconfig =================================================================== --- ba5d2c7b7d035e88291b9692bd7006907e4c46f5/net/ipv4/Kconfig  (mode:100644) +++ 4130df8533b79d0ccfd0195e707f4aa60a527e41/net/ipv4/Kconfig  (mode:100644) @@ -481,6 +481,15 @@         window. TCP Vegas should provide less packet loss, but it is         not as aggressive as TCP Reno.   +config TCP_CONG_SCALABLE +       tristate "Scalable TCP" +       depends on EXPERIMENTAL +       default n +       ---help--- +       Scalable TCP is a sender-side only change to TCP which uses a +       MIMD congestion control algorithm which has some nice scaling +       properties, though is known to have fairness issues. +       See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/    endmenu   Index: net/ipv4/Makefile =================================================================== --- ba5d2c7b7d035e88291b9692bd7006907e4c46f5/net/ipv4/Makefile  (mode:100644) +++ 4130df8533b79d0ccfd0195e707f4aa60a527e41/net/ipv4/Makefile  (mode:100644) @@ -35,6 +35,7 @@  obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o  obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o  obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o +obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o    obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \                       xfrm4_output.o Index: net/ipv4/tcp_scalable.c =================================================================== --- /dev/null  (tree:ba5d2c7b7d035e88291b9692bd7006907e4c46f5) +++ 4130df8533b79d0ccfd0195e707f4aa60a527e41/net/ipv4/tcp_scalable.c  (mode:100644) @@ -0,0 +1,71 @@ +/* Tom Kelly's Scalable TCP + * + * See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/ + * + * John Heffner + */ + +#include +#include +#include + +/* These factors derived from the recommended values in the paper: + * .01 and and 7/8.  We use 50 instead of 100 to account for + * delayed ack. */ +#define TCP_SCALABLE_AI_CNT    50U +#define TCP_SCALABLE_MD_SCALE  3 + +static void tcp_scalable_cong_avoid(struct tcp_sock *tp, u32 ack, u32 rtt, +                                   u32 in_flight, int flag) +{ +       if (in_flight < tp->snd_cwnd) +               return; +        +       if (tp->snd_cwnd <= tp->snd_ssthresh) { +               tp->snd_cwnd++; +       } else { +               tp->snd_cwnd_cnt++; +               if (tp->snd_cwnd_cnt > min(tp->snd_cwnd, TCP_SCALABLE_AI_CNT)) { +                       tp->snd_cwnd++; +                       tp->snd_cwnd_cnt = 0; +               } +       } +       tp->snd_cwnd = min(tp->snd_cwnd, (__u32)tp->snd_cwnd_clamp); +       tp->snd_cwnd_stamp = tcp_time_stamp; +} + +static u32 tcp_scalable_ssthresh(struct tcp_sock *tp) +{ +       return max(tp->snd_cwnd - (tp->snd_cwnd>>TCP_SCALABLE_MD_SCALE), 2U); +} + +static u32 tcp_scalable_min_cwnd(struct tcp_sock *tp) +{ +       return tp->snd_ssthresh / 2; +} + +static struct tcp_congestion_ops tcp_scalable = { +       .ssthresh       = tcp_scalable_ssthresh, +       .cong_avoid     = tcp_scalable_cong_avoid, +       .min_cwnd       = tcp_scalable_min_cwnd, +        +       .owner          = THIS_MODULE, +       .name           = "scalable" +}; + +static int __init tcp_scalable_register(void) +{ +       return tcp_register_congestion_control(&tcp_scalable); +} + +static void __exit tcp_scalable_unregister(void) +{ +       tcp_unregister_congestion_control(&tcp_scalable); +} + +module_init(tcp_scalable_register); +module_exit(tcp_scalable_unregister); + +MODULE_AUTHOR("John Heffner"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("Scalable TCP"); From torvalds@osdl.org Wed May 25 13:47:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 13:47:36 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PKlXXq001905 for ; Wed, 25 May 2005 13:47:34 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4PKkkjA023810 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 May 2005 13:46:46 -0700 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4PKkij0014696; Wed, 25 May 2005 13:46:45 -0700 Date: Wed, 25 May 2005 13:48:50 -0700 (PDT) From: Linus Torvalds To: Jeff Garzik cc: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches try2] 2.6.x net driver updates In-Reply-To: <4294BD9C.2050105@pobox.com> Message-ID: References: <4294BD9C.2050105@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev Content-Length: 290 Lines: 13 On Wed, 25 May 2005, Jeff Garzik wrote: > > Does this work better? Looks good. If this was automated, are your changes to git-pull-script generic enough to be useful for others, or did you do a totally specialized one for just the "lots of heads in the same directory" case? Linus From shemminger@osdl.org Wed May 25 14:00:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 14:00:13 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PL0AXq003158 for ; Wed, 25 May 2005 14:00:11 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4PKxLjA024751 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 May 2005 13:59:21 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4PKxKt4015321; Wed, 25 May 2005 13:59:20 -0700 Date: Wed, 25 May 2005 13:59:20 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netem@osdl.org, netdev@oss.sgi.com Subject: [PATCH] netem update for 2.4 Message-ID: <20050525135920.659f3a00@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 10403 Lines: 382 This includes the netem changes for 2.6 retargeted for 2.4 It covers: * make duplication reinsert from root to fix qlen issues * just use embedded qdisc for queueing to avoid qlen issues * probabilistic reordering support Index: netem-2.4/net/sched/sch_netem.c =================================================================== --- netem-2.4.orig/net/sched/sch_netem.c +++ netem-2.4/net/sched/sch_netem.c @@ -56,7 +56,6 @@ struct netem_sched_data { struct Qdisc *qdisc; - struct sk_buff_head delayed; struct timer_list timer; u32 latency; @@ -66,11 +65,12 @@ struct netem_sched_data { u32 gap; u32 jitter; u32 duplicate; + u32 reorder; struct crndstate { unsigned long last; unsigned long rho; - } delay_cor, loss_cor, dup_cor; + } delay_cor, loss_cor, dup_cor, reorder_cor; struct disttable { u32 size; @@ -140,81 +140,79 @@ static long tabledist(unsigned long mu, return x / NETEM_DIST_SCALE + (sigma / NETEM_DIST_SCALE) * t + mu; } -/* Put skb in the private delayed queue. */ -static int delay_skb(struct Qdisc *sch, struct sk_buff *skb) +/* + * Insert one skb into qdisc. + * Note: parent depends on return value to account for queue length. + * NET_XMIT_DROP: queue length didn't change. + * NET_XMIT_SUCCESS: one skb was queued. + */ +static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; - psched_tdiff_t td; - psched_time_t now; - - PSCHED_GET_TIME(now); - td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist); - PSCHED_TADD2(now, td, cb->time_to_send); - - /* Always queue at tail to keep packets in order */ - if (likely(q->delayed.qlen < q->limit)) { - __skb_queue_tail(&q->delayed, skb); - sch->stats.bytes += skb->len; - sch->stats.packets++; - - if (!timer_pending(&q->timer)) { - q->timer.expires = jiffies + PSCHED_US2JIFFIE(td); - add_timer(&q->timer); - } - return NET_XMIT_SUCCESS; - } - - sch->stats.drops++; - kfree_skb(skb); - return NET_XMIT_DROP; -} + struct sk_buff *skb2; + int ret; + int count = 1; -static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) -{ - struct netem_sched_data *q = qdisc_priv(sch); + pr_debug("netem_enqueue skb=%p\n", skb); - pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); + /* Random duplication */ + if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor)) + ++count; /* Random packet drop 0 => none, ~0 => all */ - if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { - pr_debug("netem_enqueue: random loss\n"); + if (q->loss && q->loss >= get_crandom(&q->loss_cor)) + --count; + + if (count == 0) { sch->stats.drops++; kfree_skb(skb); - return 0; /* lie about loss so TCP doesn't know */ + return NET_XMIT_DROP; } - /* Random duplication */ - if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor)) { - struct sk_buff *skb2 = skb_clone(skb, GFP_ATOMIC); - - pr_debug("netem_enqueue: dup %p\n", skb2); - if (skb2) - delay_skb(sch, skb2); - } - - /* If doing simple delay then gap == 0 so all packets - * go into the delayed holding queue - * otherwise if doing out of order only "1 out of gap" - * packets will be delayed. + /* + * If we need to duplicate packet, then re-insert at top of the + * qdisc tree, since parent queuer expects that only one + * skb will be queued. */ - if (q->counter < q->gap) { - int ret; - + if (count > 1 && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { + struct Qdisc *rootq = sch->dev->qdisc; + u32 dupsave = q->duplicate; /* prevent duplicating a dup... */ + q->duplicate = 0; + + rootq->enqueue(skb2, rootq); + q->duplicate = dupsave; + } + + if (q->gap == 0 /* not doing reordering */ + || q->counter < q->gap /* inside last reordering gap */ + || q->reorder < get_crandom(&q->reorder_cor)) { + psched_time_t now; + PSCHED_GET_TIME(now); + PSCHED_TADD2(now, tabledist(q->latency, q->jitter, + &q->delay_cor, q->delay_dist), + cb->time_to_send); ++q->counter; ret = q->qdisc->enqueue(skb, q->qdisc); - if (likely(ret == NET_XMIT_SUCCESS)) { - sch->q.qlen++; - sch->stats.bytes += skb->len; - sch->stats.packets++; - } else - sch->stats.drops++; - return ret; + } else { + /* + * Do re-ordering by putting one out of N packets at the front + * of the queue. + */ + PSCHED_GET_TIME(cb->time_to_send); + q->counter = 0; + ret = q->qdisc->ops->requeue(skb, q->qdisc); } - - q->counter = 0; - return delay_skb(sch, skb); + if (likely(ret == NET_XMIT_SUCCESS)) { + sch->q.qlen++; + sch->stats.bytes += skb->len; + sch->stats.packets++; + } else + sch->stats.drops++; + + pr_debug("netem: enqueue ret %d\n", ret); + return ret; } /* Requeue packets but don't change time stamp */ @@ -241,56 +239,46 @@ static unsigned int netem_drop(struct Qd return len; } -/* Dequeue packet. - * Move all packets that are ready to send from the delay holding - * list to the underlying qdisc, then just call dequeue - */ static struct sk_buff *netem_dequeue(struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb; skb = q->qdisc->dequeue(q->qdisc); - if (skb) - sch->q.qlen--; - return skb; -} - -static void netem_watchdog(unsigned long arg) -{ - struct Qdisc *sch = (struct Qdisc *)arg; - struct netem_sched_data *q = qdisc_priv(sch); - struct net_device *dev = sch->dev; - struct sk_buff *skb; - psched_time_t now; - - pr_debug("netem_watchdog: fired @%lu\n", jiffies); - - spin_lock_bh(&dev->queue_lock); - PSCHED_GET_TIME(now); - - while ((skb = skb_peek(&q->delayed)) != NULL) { + if (skb) { const struct netem_skb_cb *cb = (const struct netem_skb_cb *)skb->cb; - long delay - = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); - pr_debug("netem_watchdog: skb %p@%lu %ld\n", - skb, jiffies, delay); + psched_time_t now; + long delay; /* if more time remaining? */ - if (delay > 0) { - mod_timer(&q->timer, jiffies + delay); - break; + PSCHED_GET_TIME(now); + delay = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_run: skb=%p delay=%ld\n", skb, delay); + if (delay <= 0) { + pr_debug("netem_dequeue: return skb=%p\n", skb); + sch->q.qlen--; + sch->flags &= ~TCQ_F_THROTTLED; + return skb; } - __skb_unlink(skb, &q->delayed); - if (q->qdisc->enqueue(skb, q->qdisc)) + mod_timer(&q->timer, jiffies + delay); + sch->flags |= TCQ_F_THROTTLED; + + if (q->qdisc->ops->requeue(skb, q->qdisc) != 0) sch->stats.drops++; - else - sch->q.qlen++; } - qdisc_run(dev); - spin_unlock_bh(&dev->queue_lock); + + return NULL; +} + +static void netem_watchdog(unsigned long arg) +{ + struct Qdisc *sch = (struct Qdisc *)arg; + + pr_debug("netem_watchdog qlen=%d\n", sch->q.qlen); + sch->flags &= ~TCQ_F_THROTTLED; + netif_schedule(sch->dev); } static void netem_reset(struct Qdisc *sch) @@ -298,9 +286,8 @@ static void netem_reset(struct Qdisc *sc struct netem_sched_data *q = qdisc_priv(sch); qdisc_reset(q->qdisc); - skb_queue_purge(&q->delayed); - sch->q.qlen = 0; + sch->flags &= ~TCQ_F_THROTTLED; del_timer_sync(&q->timer); } @@ -366,6 +353,19 @@ static int get_correlation(struct Qdisc return 0; } +static int get_reorder(struct Qdisc *sch, const struct rtattr *attr) +{ + struct netem_sched_data *q = qdisc_priv(sch); + const struct tc_netem_reorder *r = RTA_DATA(attr); + + if (RTA_PAYLOAD(attr) != sizeof(*r)) + return -EINVAL; + + q->reorder = r->probability; + init_crandom(&q->reorder_cor, r->correlation); + return 0; +} + static int netem_change(struct Qdisc *sch, struct rtattr *opt) { struct netem_sched_data *q = qdisc_priv(sch); @@ -386,9 +386,15 @@ static int netem_change(struct Qdisc *sc q->jitter = qopt->jitter; q->limit = qopt->limit; q->gap = qopt->gap; + q->counter = 0; q->loss = qopt->loss; q->duplicate = qopt->duplicate; + /* for compatiablity with earlier versions. + * if gap is set, need to assume 100% probablity + */ + q->reorder = ~0; + /* Handle nested options after initial queue options. * Should have put all options in nested format but too late now. */ @@ -410,6 +416,11 @@ static int netem_change(struct Qdisc *sc if (ret) return ret; } + if (tb[TCA_NETEM_REORDER-1]) { + ret = get_reorder(sch, tb[TCA_NETEM_REORDER-1]); + if (ret) + return ret; + } } @@ -425,11 +436,9 @@ static int netem_init(struct Qdisc *sch, return -EINVAL; MOD_INC_USE_COUNT; - skb_queue_head_init(&q->delayed); init_timer(&q->timer); q->timer.function = netem_watchdog; q->timer.data = (unsigned long) sch; - q->counter = 0; q->qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); if (!q->qdisc) { @@ -463,6 +472,7 @@ static int netem_dump(struct Qdisc *sch, struct rtattr *rta = (struct rtattr *) b; struct tc_netem_qopt qopt; struct tc_netem_corr cor; + struct tc_netem_reorder reorder; qopt.latency = q->latency; qopt.jitter = q->jitter; @@ -476,6 +486,11 @@ static int netem_dump(struct Qdisc *sch, cor.loss_corr = q->loss_cor.rho; cor.dup_corr = q->dup_cor.rho; RTA_PUT(skb, TCA_NETEM_CORR, sizeof(cor), &cor); + + reorder.probability = q->reorder; + reorder.correlation = q->reorder_cor.rho; + RTA_PUT(skb, TCA_NETEM_REORDER, sizeof(reorder), &reorder); + rta->rta_len = skb->tail - b; return skb->len; Index: netem-2.4/include/linux/pkt_sched.h =================================================================== --- netem-2.4.orig/include/linux/pkt_sched.h +++ netem-2.4/include/linux/pkt_sched.h @@ -439,16 +439,17 @@ enum TCA_NETEM_UNSPEC, TCA_NETEM_CORR, TCA_NETEM_DELAY_DIST, + TCA_NETEM_REORDER, }; -#define TCA_NETEM_MAX TCA_NETEM_DELAY_DIST +#define TCA_NETEM_MAX TCA_NETEM_REORDER struct tc_netem_qopt { __u32 latency; /* added delay (us) */ __u32 limit; /* fifo limit (packets) */ __u32 loss; /* random packet loss (0=none ~0=100%) */ - __u32 gap; /* re-ordering gap (0 for delay all) */ + __u32 gap; /* re-ordering gap (0 for none) */ __u32 duplicate; /* random packet dup (0=none ~0=100%) */ __u32 jitter; /* random jitter in latency (us) */ }; @@ -460,6 +461,12 @@ struct tc_netem_corr __u32 dup_corr; /* duplicate correlation */ }; +struct tc_netem_reorder +{ + __u32 probability; + __u32 correlation; +}; + #define NETEM_DIST_SCALE 8192 #endif From shemminger@osdl.org Wed May 25 14:01:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 14:01:09 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PL17Xq003249 for ; Wed, 25 May 2005 14:01:07 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4PL0JjA024822 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 May 2005 14:00:20 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4PL0Jro015382; Wed, 25 May 2005 14:00:19 -0700 Date: Wed, 25 May 2005 14:00:19 -0700 From: Stephen Hemminger To: John Heffner Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Scalable TCP Message-ID: <20050525140019.4a5657f1@dxpl.pdx.osdl.net> In-Reply-To: <200505251550.42252.jheffner@psc.edu> References: <200505251550.42252.jheffner@psc.edu> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 98 Lines: 2 Okay, integrated it but there were some funky whitespace issues probably because of mailer stuff. From shemminger@osdl.org Wed May 25 14:47:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 14:47:29 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PLlPXq004898 for ; Wed, 25 May 2005 14:47:26 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4PLkYjA028036 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 May 2005 14:46:34 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4PLkXG3017600; Wed, 25 May 2005 14:46:34 -0700 Date: Wed, 25 May 2005 14:46:33 -0700 From: Stephen Hemminger To: "Catalin(ux aka Dino) BOIE" Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] Message-ID: <20050525144633.3a6f253e@dxpl.pdx.osdl.net> In-Reply-To: <20050525091427.35621a21@dxpl.pdx.osdl.net> References: <20050525091427.35621a21@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3480 Lines: 124 Here is the revised version, it deals with checksum mixtures better and ignores stuff until bridge is up. Index: bridge/net/bridge/br_private.h =================================================================== --- bridge.orig/net/bridge/br_private.h +++ bridge/net/bridge/br_private.h @@ -174,6 +174,7 @@ extern int br_add_if(struct net_bridge * extern int br_del_if(struct net_bridge *br, struct net_device *dev); extern int br_min_mtu(const struct net_bridge *br); +extern void br_features_recompute(struct net_bridge *br); /* br_input.c */ extern int br_handle_frame_finish(struct sk_buff *skb); Index: bridge/net/bridge/br_notify.c =================================================================== --- bridge.orig/net/bridge/br_notify.c +++ bridge/net/bridge/br_notify.c @@ -65,6 +65,15 @@ static int br_device_event(struct notifi } break; + case NETDEV_FEAT_CHANGE: + if (br->dev->flags & IFF_UP) + br_features_recompute(br); + + /* could do recursive feature change notification + * but who would care?? + */ + break; + case NETDEV_DOWN: if (br->dev->flags & IFF_UP) br_stp_disable_port(p); Index: bridge/net/bridge/br_device.c =================================================================== --- bridge.orig/net/bridge/br_device.c +++ bridge/net/bridge/br_device.c @@ -21,10 +21,7 @@ static struct net_device_stats *br_dev_get_stats(struct net_device *dev) { - struct net_bridge *br; - - br = dev->priv; - + struct net_bridge *br = netdev_priv(dev); return &br->statistics; } @@ -54,9 +51,11 @@ int br_dev_xmit(struct sk_buff *skb, str static int br_dev_open(struct net_device *dev) { - netif_start_queue(dev); + struct net_bridge *br = netdev_priv(dev); - br_stp_enable_bridge(dev->priv); + br_features_recompute(br); + netif_start_queue(dev); + br_stp_enable_bridge(br); return 0; } @@ -67,7 +66,7 @@ static void br_dev_set_multicast_list(st static int br_dev_stop(struct net_device *dev) { - br_stp_disable_bridge(dev->priv); + br_stp_disable_bridge(netdev_priv(dev)); netif_stop_queue(dev); @@ -76,7 +75,7 @@ static int br_dev_stop(struct net_device static int br_change_mtu(struct net_device *dev, int new_mtu) { - if ((new_mtu < 68) || new_mtu > br_min_mtu(dev->priv)) + if (new_mtu < 68 || new_mtu > br_min_mtu(netdev_priv(dev))) return -EINVAL; dev->mtu = new_mtu; Index: bridge/net/bridge/br_if.c =================================================================== --- bridge.orig/net/bridge/br_if.c +++ bridge/net/bridge/br_if.c @@ -314,6 +314,28 @@ int br_min_mtu(const struct net_bridge * return mtu; } +/* + * Recomputes features using slave's features + */ +void br_features_recompute(struct net_bridge *br) +{ + struct net_bridge_port *p; + unsigned long features, checksum; + + features = NETIF_F_SG | NETIF_F_FRAGLIST + | NETIF_F_HIGHDMA | NETIF_F_TSO; + checksum = NETIF_F_IP_CSUM; /* least commmon subset */ + + list_for_each_entry(p, &br->port_list, list) { + if (!(p->dev->features + & (NETIF_F_IP_CSUM|NETIF_F_NO_CSUM|NETIF_F_HW_CSUM))) + checksum = 0; + features &= p->dev->features; + } + + br->dev->features = features | checksum | NETIF_F_LLTX; +} + /* called with RTNL */ int br_add_if(struct net_bridge *br, struct net_device *dev) { @@ -368,6 +390,7 @@ int br_del_if(struct net_bridge *br, str spin_lock_bh(&br->lock); br_stp_recalculate_bridge_id(br); + br_features_recompute(br); spin_unlock_bh(&br->lock); return 0; From davem@davemloft.net Wed May 25 15:09:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 15:09:35 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PM9XXq005725 for ; Wed, 25 May 2005 15:09:33 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Db43K-0002vV-3J; Wed, 25 May 2005 15:08:38 -0700 Date: Wed, 25 May 2005 15:08:37 -0700 (PDT) Message-Id: <20050525.150837.18577459.davem@davemloft.net> To: shemminger@osdl.org Cc: netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: allow random reordering (with fix) From: "David S. Miller" In-Reply-To: <20050524152610.256d248a@dxpl.pdx.osdl.net> References: <20050519151254.79afe7e7@dxpl.pdx.osdl.net> <20050524152610.256d248a@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 46 Lines: 2 All 3 netem patches applied, thanks Stephen. From davem@davemloft.net Wed May 25 15:12:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 15:12:54 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PMCjXq006209 for ; Wed, 25 May 2005 15:12:49 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Db46P-0002vz-Eq; Wed, 25 May 2005 15:11:49 -0700 Date: Wed, 25 May 2005 15:11:49 -0700 (PDT) Message-Id: <20050525.151149.08323692.davem@davemloft.net> To: util@deuroconsult.ro Cc: netdev@oss.sgi.com Subject: Re: [PATCH] dummy: improve performance From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 538 Lines: 13 From: "Catalin(ux aka Dino) BOIE" Date: Fri, 20 May 2005 13:11:24 +0300 (EEST) > I tested the speed and seems very low (both old version and the new one). > Something like 37Mbits/s. It is normal? > I can easily get 80Mbit/s on the same machine on ethernet. How are you receiving packets on the dummy device for performance testing? This device is a transmit blackhole and receives no packets :-) I really don't see a real need for your patch, dummy device performance cannot be claimed to be important at all. From davem@davemloft.net Wed May 25 15:19:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 15:19:35 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PMJUXq007023 for ; Wed, 25 May 2005 15:19:30 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Db4Cv-0002yU-DC; Wed, 25 May 2005 15:18:33 -0700 Date: Wed, 25 May 2005 15:18:33 -0700 (PDT) Message-Id: <20050525.151833.21926577.davem@davemloft.net> To: jgarzik@pobox.com Cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: [PATCH 1/6] bnx2: Fix excessive stack usage From: "David S. Miller" In-Reply-To: <4292BEF6.2080804@pobox.com> References: <429286A3.1060606@pobox.com> <1116908956.5984.4.camel@rh4> <4292BEF6.2080804@pobox.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 258 Lines: 12 From: Jeff Garzik Date: Tue, 24 May 2005 01:43:18 -0400 > > Signed-off-by: Michael Chan > > ACK I've integrated the new bnx2 driver, with all updated bug fixes. I'll push this upstream shortly. Thanks everyone. From davem@davemloft.net Wed May 25 15:22:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 15:22:51 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PMMjXq007630 for ; Wed, 25 May 2005 15:22:45 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Db4G1-0002zN-3L; Wed, 25 May 2005 15:21:45 -0700 Date: Wed, 25 May 2005 15:21:44 -0700 (PDT) Message-Id: <20050525.152144.105431359.davem@davemloft.net> To: fubar@us.ibm.com Cc: eparis@parisplace.org, netdev@oss.sgi.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH] bonding using arp_ip_target may stay down with active path From: "David S. Miller" In-Reply-To: <200505232121.j4NLLaYa000837@death.nxdomain.ibm.com> References: <200505232121.j4NLLaYa000837@death.nxdomain.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 40 Lines: 2 Fixed patch applied, thanks a lot Jay. From davem@davemloft.net Wed May 25 15:40:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 15:41:11 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PMeoXq008600 for ; Wed, 25 May 2005 15:40:55 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Db4XP-00031S-9P; Wed, 25 May 2005 15:39:43 -0700 Date: Wed, 25 May 2005 15:39:43 -0700 (PDT) Message-Id: <20050525.153943.69020533.davem@davemloft.net> To: jdmason@us.ibm.com Cc: netdev@oss.sgi.com, niv@us.ibm.com, habanero@us.ibm.com Subject: Re: Interdomain/interpartition communication without a checksum From: "David S. Miller" In-Reply-To: <20050517163420.GA19251@us.ibm.com> References: <20050511183554.GA28298@us.ibm.com> <20050516.130737.77060495.davem@davemloft.net> <20050517163420.GA19251@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 868 Lines: 29 From: Jon Mason Date: Tue, 17 May 2005 11:34:20 -0500 > --- ../xen-unstable-pristine/linux-2.6.11-xen0/include/linux/skbuff.h 2005-03-02 01:38:38.000000000 -0600 > +++ linux-2.6.11-xen0/include/linux/skbuff.h 2005-05-13 10:43:08.000000000 -0500 > @@ -37,6 +37,10 @@ > #define CHECKSUM_HW 1 > #define CHECKSUM_UNNECESSARY 2 > > +#define SKB_CLONED 1 > +#define SKB_NOHDR 2 > +#define SKB_FDW_NO_CSUM 4 > + You create SKB_NOHDR yet do not make use of it to replace skb->nohdr. > @@ -603,7 +603,7 @@ int pskb_expand_head(struct sk_buff *skb > skb->mac.raw += off; > skb->h.raw += off; > skb->nh.raw += off; > - skb->cloned = 0; > + skb->flags &= SKB_CLONED; > atomic_set(&skb_shinfo(skb)->dataref, 1); > return 0; This does not clear SKB_CLONED, it makes it the only possible bit set. Clearly this was not your intention. From jgarzik@pobox.com Wed May 25 15:59:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 15:59:56 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PMxpXq009791 for ; Wed, 25 May 2005 15:59:54 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1Db4q8-0002TB-K8; Wed, 25 May 2005 22:59:05 +0000 Message-ID: <42950334.9090402@pobox.com> Date: Wed, 25 May 2005 18:59:00 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linus Torvalds CC: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches try2] 2.6.x net driver updates References: <4294BD9C.2050105@pobox.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000909010807040906020109" X-archive-position: 1638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 2965 Lines: 94 This is a multi-part message in MIME format. --------------000909010807040906020109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Linus Torvalds wrote: > > On Wed, 25 May 2005, Jeff Garzik wrote: > >>Does this work better? > > > Looks good. Groovy. > If this was automated, are your changes to git-pull-script generic enough > to be useful for others, or did you do a totally specialized one for just > the "lots of heads in the same directory" case? Not specialized at all. I do one pull at a time, so git-pull-script suffices with a simple addition to call git-resolve-script with the branch as $4, and a simple addition to git-resolve-script to add 'branch $foo' to merge_msg. See attached (note the patch includes my earlier 'optimization' patch). On this last run, I actually just ignored git-pull-script and simply ran git-resolve-script -- since all my objects are in-tree already, I don't need the fetch step: git-resolve-script $(cat .git/HEAD ) $(cat .git/refs/heads/amd8111) \ /spare/repo/netdev-2.6 amd8111 Jeff --------------000909010807040906020109 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" --- git-resolve-script 2005-05-25 15:21:32.772604549 -0400 +++ /usr/local/bin/git-resolve-script 2005-05-25 13:30:59.568504275 -0400 @@ -7,6 +7,7 @@ head="$1" merge="$2" merge_repo="$3" +merge_name=${4:-HEAD} : ${GIT_DIR=.git} : ${GIT_OBJECT_DIRECTORY="${SHA1_FILE_DIRECTORY-"$GIT_DIR/objects"}"} @@ -20,7 +21,7 @@ # but we do want it. # if [ "$merge_repo" == "" ]; then - echo "git-resolve-script " + echo "git-resolve-script " exit 1 fi @@ -39,23 +40,23 @@ echo "Destroying all noncommitted data!" echo "Kill me within 3 seconds.." sleep 3 - git-read-tree -m $merge && git-checkout-cache -f -u -a + git-read-tree -m $merge && git-checkout-cache -f -a && git-update-cache --refresh echo $merge > "$GIT_DIR"/HEAD git-diff-tree -p ORIG_HEAD HEAD | diffstat -p1 exit 0 fi echo "Trying to merge $merge into $head" git-read-tree -m $common $head $merge -merge_msg="Merge of $merge_repo" +merge_msg="Merge of $merge_repo branch $merge_name" result_tree=$(git-write-tree 2> /dev/null) if [ $? -ne 0 ]; then echo "Simple merge failed, trying Automatic merge" git-merge-cache git-merge-one-file-script -a - merge_msg="Automatic merge of $merge_repo" + merge_msg="Automatic merge of $merge_repo branch $merge_name" result_tree=$(git-write-tree) || exit 1 fi result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree -p $head -p $merge) echo "Committed merge $result_commit" echo $result_commit > "$GIT_DIR"/HEAD -git-checkout-cache -f -u -a +git-checkout-cache -f -a && git-update-cache --refresh git-diff-tree -p ORIG_HEAD HEAD | diffstat -p1 --------------000909010807040906020109-- From kumar.gala@freescale.com Wed May 25 16:01:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 16:01:32 -0700 (PDT) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PN1SXq010052 for ; Wed, 25 May 2005 16:01:29 -0700 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j4PN5gCP019056; Wed, 25 May 2005 16:05:42 -0700 (MST) Received: from [10.82.17.247] ([10.82.17.247]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j4PN3Z6p008938; Wed, 25 May 2005 18:03:35 -0500 (CDT) In-Reply-To: <30d87aabd768216ef8bee800f3e09b9e@freescale.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> <423734FB.40101@katalix.com> <96c50184a02557c88dee0e6d17f3a539@freescale.com> <42625DDB.4090600@katalix.com> <30d87aabd768216ef8bee800f3e09b9e@freescale.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6ad9943e3e0399b677519ad3653847bc@freescale.com> Cc: "David S. Miller" , ML linuxppc-embedded , Fleming Andy-afleming , Netdev , James Chapman From: Kumar Gala Subject: Re: RFC: PHY Abstraction Layer II Date: Wed, 25 May 2005 18:00:33 -0500 To: Jeff Garzik X-Mailer: Apple Mail (2.619.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4PN1SXq010052 X-archive-position: 1639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumar.gala@freescale.com Precedence: bulk X-list: netdev Content-Length: 1887 Lines: 58 Jeff, Where do we stand on this. Are there changes you feel need to be made? Some other issue? It would like to know what we need to do to get this in post 2.6.12. thanks - kumar On May 10, 2005, at 12:04 PM, Fleming Andy-afleming wrote: > > > On Apr 17, 2005, at 08:00, James Chapman wrote: > > > Andy Fleming wrote: > >> Ok, here's the new patch with changes suggested by James Chapman: > > > > I guess I still have questions about the way interrupts are used. > > > > Using an interrupt to schedule a work queue which then sets a > variable > > that is used by a timer seems odd. Why not do all the work in the > work > > queue and schedule it from the interrupt handler or timer? > > Ok, I've set up a new system for handling interrupts.  There are now > two "special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT.  > The first one is used to indicate that the PHY layer will poll the PHY > for state changes, and won't enable interrupts.  The second indicates > that the PHY layer will neither poll, nor enable interrupts, and thus > will allow the driver to handle interrupts.  The PHY layer will still > operate its state machine, though. > > The driver must insure a couple things: > > 1) It must set phydev->state to PHY_CHANGELINK > 2) It must do that in a work queue (or other non-interrupt time) > > The first one tells the PHY layer that the link state changed (it has > to grab a lock to do this).  The second one is required in order to > properly take the lock. > > > > > Also, did you mean to leave the #if 0 code in davicom.c? > > For now.  It worked around a problem some people were reporting, so I'd > like to see if they report it again now that the code's out.  If so, > they have a fairly easy fix, and I can reinsert it (or at least > reevaluate it) in the future. > > > > > /james > > Andy > From jgarzik@pobox.com Wed May 25 16:04:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 16:04:30 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PN4SXq010800 for ; Wed, 25 May 2005 16:04:28 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1Db4ub-0002TM-E4; Wed, 25 May 2005 23:03:41 +0000 Message-ID: <4295044B.7090604@pobox.com> Date: Wed, 25 May 2005 19:03:39 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linus Torvalds CC: Andrew Morton , Netdev , Linux Kernel Subject: Re: [git patches try2] 2.6.x net driver updates References: <4294BD9C.2050105@pobox.com> <42950334.9090402@pobox.com> In-Reply-To: <42950334.9090402@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 315 Lines: 6 Jeff Garzik wrote: > Not specialized at all. I do one pull at a time, so git-pull-script > suffices with a simple addition to call git-resolve-script with the > branch as $4, and a simple addition to git-resolve-script to add 'branch Correction: new $4 arg was added to git-resolve-script, not git-pull-script From olh@suse.de Wed May 25 16:17:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 16:17:45 -0700 (PDT) Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PNHdXq011810 for ; Wed, 25 May 2005 16:17:40 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 48E11E8D7; Thu, 26 May 2005 01:16:52 +0200 (CEST) Date: Thu, 26 May 2005 01:16:51 +0200 From: Olaf Hering To: Jeff Garzik , netdev@oss.sgi.com, prism54-private@prism54.org Subject: [PATCH] uninitialized variable in prism54 isl38xx_trigger_device Message-ID: <20050525231651.GA21816@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-archive-position: 1641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 1770 Lines: 47 drivers/net/wireless/prism54/isl_38xx.c:131: warning: 'current_time.tv_sec' is used uninitialized in this function drivers/net/wireless/prism54/isl_38xx.c:131: warning: 'current_time.tv_usec' is used uninitialized in this function Signed-off-by: Olaf Hering Index: linux-2.6.12-rc5-olh/drivers/net/wireless/prism54/isl_38xx.c =================================================================== --- linux-2.6.12-rc5-olh.orig/drivers/net/wireless/prism54/isl_38xx.c +++ linux-2.6.12-rc5-olh/drivers/net/wireless/prism54/isl_38xx.c @@ -112,10 +112,10 @@ isl38xx_handle_wakeup(isl38xx_control_bl void isl38xx_trigger_device(int asleep, void __iomem *device_base) { - struct timeval current_time; u32 reg, counter = 0; #if VERBOSE > SHOW_ERROR_MESSAGES + struct timeval current_time; DEBUG(SHOW_FUNCTION_CALLS, "isl38xx trigger device\n"); #endif @@ -126,11 +126,11 @@ isl38xx_trigger_device(int asleep, void do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", current_time.tv_sec, (long)current_time.tv_usec); -#endif DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", current_time.tv_sec, (long)current_time.tv_usec, readl(device_base + ISL38XX_CTRL_STAT_REG)); +#endif udelay(ISL38XX_WRITEIO_DELAY); reg = readl(device_base + ISL38XX_INT_IDENT_REG); @@ -148,10 +148,12 @@ isl38xx_trigger_device(int asleep, void counter++; } +#if VERBOSE > SHOW_ERROR_MESSAGES DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", current_time.tv_sec, (long)current_time.tv_usec, readl(device_base + ISL38XX_CTRL_STAT_REG)); +#endif udelay(ISL38XX_WRITEIO_DELAY); #if VERBOSE > SHOW_ERROR_MESSAGES From davem@davemloft.net Wed May 25 16:38:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 16:38:22 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PNcIXq016307 for ; Wed, 25 May 2005 16:38:18 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Db5R6-0004j7-R9; Wed, 25 May 2005 16:37:16 -0700 Date: Wed, 25 May 2005 16:37:16 -0700 (PDT) Message-Id: <20050525.163716.88475834.davem@davemloft.net> To: acme@ghostprotocols.net Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/2][NET] rename struct tcp_listen_opt to struct listen_sock From: "David S. Miller" In-Reply-To: <20050524011758.GJ26989@conectiva.com.br> References: <20050524011758.GJ26989@conectiva.com.br> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 251 Lines: 7 From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) Date: Mon, 23 May 2005 22:17:58 -0300 > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.13.git Both changes look good, pulled. It should show up on kernel.org in a little bit. From davem@davemloft.net Wed May 25 16:41:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 16:42:06 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PNfwXq016819 for ; Wed, 25 May 2005 16:41:58 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Db5UT-0005Pi-FS; Wed, 25 May 2005 16:40:45 -0700 Date: Wed, 25 May 2005 16:40:45 -0700 (PDT) Message-Id: <20050525.164045.90119936.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, kazunori@miyazawa.org Subject: Re: [XFRM] Call dst_check() with appropriate cookie From: "David S. Miller" In-Reply-To: <20050524115914.GA697@gondor.apana.org.au> References: <20050524082021.GA31446@gondor.apana.org.au> <20050524.174931.46801018.yoshfuji@linux-ipv6.org> <20050524115914.GA697@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 518 Lines: 17 From: Herbert Xu Date: Tue, 24 May 2005 21:59:14 +1000 > On Tue, May 24, 2005 at 05:49:31PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > > [XFRM] Call dst_check() with appropriate cookie > > > > This fixes infinite loop issue with IPv6 tunnel mode. > > > > Signed-off-by: Kazunori Miyazawa > > Signed-off-by: Hideaki YOSHIFUJI > > Looks good. > > Acked-by: Herbert Xu Applied, thanks everyone. From davem@davemloft.net Wed May 25 16:44:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 16:44:33 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PNiUXq017389 for ; Wed, 25 May 2005 16:44:30 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Db5XC-0005pD-34; Wed, 25 May 2005 16:43:34 -0700 Date: Wed, 25 May 2005 16:43:33 -0700 (PDT) Message-Id: <20050525.164333.102769726.davem@davemloft.net> To: adobriyan@gmail.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] net/802/tr.c: s/struct rif_cache_s/struct rif_cache/ From: "David S. Miller" In-Reply-To: <200505242148.03588.adobriyan@gmail.com> References: <200505242148.03588.adobriyan@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 207 Lines: 8 From: Alexey Dobriyan Date: Tue, 24 May 2005 21:48:03 +0400 > "_s" suffix is certainly of hungarian origin. > > Signed-off-by: Alexey Dobriyan Applied, thanks. From davem@davemloft.net Wed May 25 16:44:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 16:44:15 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PNiDXq017348 for ; Wed, 25 May 2005 16:44:13 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Db5Wp-0005jC-BH; Wed, 25 May 2005 16:43:11 -0700 Date: Wed, 25 May 2005 16:43:11 -0700 (PDT) Message-Id: <20050525.164311.131104203.davem@davemloft.net> To: adobriyan@gmail.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] tokenring: be'ify trh_hdr, trllc, rif_cache_s From: "David S. Miller" In-Reply-To: <200505242146.53270.adobriyan@gmail.com> References: <200505242146.53270.adobriyan@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1644 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 156 Lines: 6 From: Alexey Dobriyan Date: Tue, 24 May 2005 21:46:53 +0400 > Signed-off-by: Alexey Dobriyan Applied, thanks. From imcdnzl@gmail.com Wed May 25 16:52:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 16:52:54 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4PNqnXq018471 for ; Wed, 25 May 2005 16:52:50 -0700 Received: by zproxy.gmail.com with SMTP id 9so580003nzo for ; Wed, 25 May 2005 16:52:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Dlm/ZtBd9WvAimGo6qzopNCRqxVCc/yNynMRle0JRuDTl8/leRDB2rjEYh6tUzYaB4fKWlmLf5a/H1YYNidFLUttkgTeAAm6EMYPpK1V7SBU4Dlsxwq4IS89Jq/CCNIwYyMPH4HbYAlFm+ajnWxme78x/ryHqmRArNuOpOt5JRI= Received: by 10.36.106.18 with SMTP id e18mr381106nzc; Wed, 25 May 2005 16:52:00 -0700 (PDT) Received: by 10.36.50.2 with HTTP; Wed, 25 May 2005 16:52:00 -0700 (PDT) Message-ID: Date: Thu, 26 May 2005 11:52:00 +1200 From: Ian McDonald Reply-To: Ian McDonald To: "David S. Miller" Subject: Re: [PATCH 2/2][NET] rename struct tcp_listen_opt to struct listen_sock Cc: acme@ghostprotocols.net, netdev@oss.sgi.com In-Reply-To: <20050525.163716.88475834.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050524011758.GJ26989@conectiva.com.br> <20050525.163716.88475834.davem@davemloft.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4PNqnXq018471 X-archive-position: 1646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imcdnzl@gmail.com Precedence: bulk X-list: netdev Content-Length: 559 Lines: 20 David/Arnaldo, On 26/05/05, David S. Miller wrote: > From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) > Date: Mon, 23 May 2005 22:17:58 -0300 > > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.13.git > > Both changes look good, pulled. It should show up on kernel.org > in a little bit. > > Maybe I am looking at the wrong place but when I look at: http://kernel.org/git/?p=linux/kernel/git/acme/net-2.6.13.git;a=summary it shows non-network related patches in there as well. Is this intentional? Ian From arnaldo.melo@gmail.com Wed May 25 18:27:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 18:27:15 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q1RAXq021793 for ; Wed, 25 May 2005 18:27:10 -0700 Received: by zproxy.gmail.com with SMTP id 34so310237nzf for ; Wed, 25 May 2005 18:26:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=riZcAjV4hp+f2e51F3womcZlsobovcZQ06gP3XzXh6lawLCuFOvG9e/VbwYZ0YgJNRC8WY4hmv0/4xK7beRiwMNMGwYbbiqlR9JQ1O/d2PsiflQZVbmXmo4rmQjc/F6OyyI/I09kYiDQXhol6BpyR239F4V59TaJioxyaFSP0Og= Received: by 10.36.72.4 with SMTP id u4mr416489nza; Wed, 25 May 2005 18:26:21 -0700 (PDT) Received: by 10.36.56.14 with HTTP; Wed, 25 May 2005 18:26:21 -0700 (PDT) Message-ID: <39e6f6c70505251826381aefad@mail.gmail.com> Date: Wed, 25 May 2005 22:26:21 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@ghostprotocols.net To: Ian McDonald Subject: Re: [PATCH 2/2][NET] rename struct tcp_listen_opt to struct listen_sock Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050524011758.GJ26989@conectiva.com.br> <20050525.163716.88475834.davem@davemloft.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4Q1RAXq021793 X-archive-position: 1647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 787 Lines: 23 On 5/25/05, Ian McDonald wrote: > David/Arnaldo, > > > On 26/05/05, David S. Miller wrote: > > From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) > > Date: Mon, 23 May 2005 22:17:58 -0300 > > > > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.13.git > > > > Both changes look good, pulled. It should show up on kernel.org > > in a little bit. > > > > > Maybe I am looking at the wrong place but when I look at: > http://kernel.org/git/?p=linux/kernel/git/acme/net-2.6.13.git;a=summary > > it shows non-network related patches in there as well. Is this intentional? Its because I cloned David's tree that cloned Linus tree that... i.e. that summary is of the last changesets, not necessarily mine or commited by me. From yi.zhu@intel.com Wed May 25 20:40:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 20:40:13 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q3eAXq029892 for ; Wed, 25 May 2005 20:40:11 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4Q3dOHk015262; Thu, 26 May 2005 03:39:24 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4Q3dNPm014609; Thu, 26 May 2005 03:39:24 GMT Received: from debian.sh.intel.com ([172.16.219.38]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052520392229856 ; Wed, 25 May 2005 20:39:23 -0700 Subject: Re: [0/5] Improvements to the ieee80211 layer From: Zhu Yi To: Jiri Benc Cc: NetDev , jbohac@suse.cz In-Reply-To: <20050525132055.469f10d7@griffin.suse.cz> References: <20050524150711.01632672@griffin.suse.cz> <1117004116.3737.30.camel@debian.sh.intel.com> <20050525132055.469f10d7@griffin.suse.cz> Content-Type: text/plain Organization: Intel Corp. Date: Thu, 26 May 2005 11:36:20 +0800 Message-Id: <1117078580.3737.81.camel@debian.sh.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yi.zhu@intel.com Precedence: bulk X-list: netdev Content-Length: 822 Lines: 20 On Wed, 2005-05-25 at 13:20 +0200, Jiri Benc wrote: > On Wed, 25 May 2005 14:55:16 +0800, Zhu Yi wrote: > > Do you just clean up current ieee80211 code to still do 802.11 <-> 802.3 > > conversion inside the driver or you plan to handle real 802.11 frames in > > the stack like this? > > http://oss.sgi.com/archives/netdev/2005-03/msg01405.html > > We are trying to handle real 802.11 frames. Have you made any progress > in your work since posting that patch? If so, could you please post it > to netdev (or to us)? No much progress since that. I planned to add a new type SOCK_80211 to PF_PACKET domain, so that user space can send packets through the 80211 stack but don't need to build 802.11 headers themselves. This can be used by programs like wpa_supplicant. Do you know some better way to do this? Thanks, -yi From akpm@osdl.org Wed May 25 22:01:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 22:01:48 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q51gXq001121 for ; Wed, 25 May 2005 22:01:42 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4Q50qjA026265 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 May 2005 22:00:52 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4Q50pAE003337; Wed, 25 May 2005 22:00:51 -0700 Date: Wed, 25 May 2005 22:00:03 -0700 From: Andrew Morton To: Alessandro Suardi Cc: netdev@oss.sgi.com Subject: Re: non-fatal oops with EIP at skb_release_data, available for debugging Message-Id: <20050525220003.5f6ab060.akpm@osdl.org> In-Reply-To: <5a4c581d05040615306f12ebde@mail.gmail.com> References: <5a4c581d05030412482a596ee5@mail.gmail.com> <5a4c581d05040615306f12ebde@mail.gmail.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 5703 Lines: 124 Alessandro Suardi wrote: > > Quoting my post of over a month ago, hit another > non-fatal oops this time with 2.6.12-rc1-bk2... Has this bug been sighted in more recent kernels? > [17330.816664] Adding 232932k swap on /dev/hdb4. Priority:-2 extents:1 > [42120.713332] UDP: bad checksum. From 84.188.199.xxx:57483 to > 192.168.1.7:10600 ulen 27 > [56984.872784] UDP: bad checksum. From 216.155.90.xxx:11417 to > 192.168.1.7:10600 ulen 28 > [383152.586711] scsi: unknown opcode 0x01 > [630539.047761] UDP: short packet: From 4.46.101.xxx:5431 58/27 to > 192.168.1.7:1 0600 > [681405.777002] ------------[ cut here ]------------ > [681405.777337] kernel BUG at include/linux/mm.h:343! > [681405.777642] invalid operand: 0000 [#1] > [681405.777885] PREEMPT > [681405.778041] Modules linked in: parport_pc parport 8139too floppy > [681405.778488] CPU: 0 > [681405.778491] EIP: 0060:[] Not tainted VLI > [681405.778494] EFLAGS: 00210256 (2.6.12-rc1-bk2) > [681405.779293] EIP is at skb_release_data+0xa3/0xb0 > [681405.779593] eax: 00000000 ebx: 00000002 ecx: ceb1af80 edx: c10eeb40 > [681405.780027] esi: c30785c0 edi: c30785c0 ebp: ccd95d28 esp: ccd95d20 > [681405.780458] ds: 007b es: 007b ss: 0068 > [681405.780723] Process metacity (pid: 2190, threadinfo=ccd94000 task=cb501a40) > [681405.781164] Stack: c30785c0 00000020 ccd95d34 c02dcd3b cec7a6c0 > ccd95d54 c02 dcdb7 ccd95f3c > [681405.781807] 00001620 c30785c0 506c6f85 c30785c0 506c6f85 > ccd95da8 c03 0100a 00000000 > [681405.782448] c02dc46f caf7d420 ccd95d80 00000001 caf7d46c > ccd94000 000 00001 00000000 > [681405.783088] Call Trace: > [681405.783258] [] show_stack+0x7a/0x90 > [681405.783574] [] show_registers+0x14d/0x1c0 > [681405.783915] [] die+0xe4/0x170 > [681405.784192] [] do_invalid_op+0xa3/0xb0 > [681405.784517] [] error_code+0x2b/0x30 > [681405.785009] [] kfree_skbmem+0xb/0x20 > [681405.785494] [] __kfree_skb+0x67/0xf0 > [681405.785978] [] tcp_recvmsg+0x5fa/0x720 > [681405.786477] [] sock_common_recvmsg+0x46/0x60 > [681405.787004] [] sock_recvmsg+0xbd/0xf0 > [681405.787493] [] sock_readv_writev+0x83/0x90 > [681405.788009] [] sock_readv+0x3b/0x50 > [681405.788487] [] do_readv_writev+0x205/0x230 > [681405.789004] [] vfs_readv+0x3d/0x50 > [681405.789476] [] sys_readv+0x3d/0xa0 > [681405.789947] [] sysenter_past_esp+0x54/0x75 > [681405.790461] Code: 8b 86 98 00 00 00 5e c9 e9 7b e9 e5 ff 89 d0 e8 > 44 f7 e5 f f eb d6 89 f0 e8 fb fe ff ff 5b 8b 86 98 00 00 00 5e c9 e9 > 5d e9 e5 ff <0f> 0b 5 7 01 32 ed 35 c0 eb ac 8d 76 00 55 89 e5 53 89 > c3 e8 45 > [681405.857278] <7>UDP: short packet: From 213.23.1.xxx:11236 2814/33 > to 192.168. 1.7:10600 > > > On Mar 4, 2005 10:48 PM, Alessandro Suardi wrote: > > This is my K7-800, 256MB RAM machine running as > > ed2k/bittorrent 24/7 box... metacity died, but the > > windows are still alive (and working) so if someone > > wants to get more info about it, just ping me... > > > > [root@donkey ~]# cat /proc/version > > Linux version 2.6.11-rc3-bk8 (asuardi@donkey) (gcc version 3.4.2 > > 20041017 (Red Hat 3.4.2-6.fc3)) #1 Sat Feb 12 00:01:28 CET 2005 > > [root@donkey ~]# lsmod > > Module Size Used by > > loop 15368 - > > nls_iso8859_1 3840 - > > parport_pc 29444 - > > parport 24704 - > > 8139too 24896 - > > floppy 57392 - > > > > From the dmesg ring: > > > > kernel BUG at include/linux/mm.h:343! > > invalid operand: 0000 [#1] > > PREEMPT > > Modules linked in: loop nls_iso8859_1 parport_pc parport 8139too floppy > > CPU: 0 > > EIP: 0060:[] Not tainted VLI > > EFLAGS: 00210256 (2.6.11-rc3-bk8) > > EIP is at skb_release_data+0x92/0xa0 > > eax: 00000000 ebx: 00000000 ecx: cca36f80 edx: c11a97c0 > > esi: c4205f20 edi: c4205f20 ebp: cd149dcc esp: cd149dc4 > > ds: 007b es: 007b ss: 0068 > > Process metacity (pid: 2109, threadinfo=cd148000 task=ce8935d0) > > Stack: c4205f20 00000000 cd149dd8 c02da6bb c6e9a0c0 cd149df8 c02da737 c5134250 > > 00000000 c4205f20 c5134250 c4205f20 c5134250 cd149e4c c02feba6 00000000 > > 00000040 cc68c454 00000000 00000001 cc68c444 cd148000 00000001 00000000 > > Call Trace: > > [] show_stack+0x7a/0x90 > > [] show_registers+0x14d/0x1c0 > > [] die+0xe4/0x180 > > [] do_invalid_op+0xa3/0xb0 > > [] error_code+0x2b/0x30 > > [] kfree_skbmem+0xb/0x20 > > [] __kfree_skb+0x67/0xf0 > > [] tcp_recvmsg+0x5f6/0x710 > > [] sock_common_recvmsg+0x46/0x60 > > [] sock_aio_read+0xee/0x100 > > [] do_sync_read+0x97/0xf0 > > [] vfs_read+0x91/0x120 > > [] sys_read+0x3d/0x70 > > [] sysenter_past_esp+0x52/0x75 > > Code: c9 e9 03 e5 e5 ff 8d 76 00 5b 5e c9 c3 89 d0 e8 c5 f2 e5 ff eb > > cf 89 f0 e8 0c ff ff ff 5b 8b 86 98 00 00 00 5e c9 e9 de e4 e5 ff <0f> > > 0b 57 01 ab c5 35 c0 eb a5 8d 74 26 00 55 89 e5 53 89 c3 e8 > > --alessandro > > "I want to know if it's you I don't trust > 'cause I damn sure don't trust myself" > > (Bruce Springsteen, "Brilliant Disguise") > - > 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/ From jgarzik@pobox.com Wed May 25 22:27:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 22:27:16 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q5RCXq002166 for ; Wed, 25 May 2005 22:27:12 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DbAsr-0002iW-Vo; Thu, 26 May 2005 05:26:18 +0000 Message-ID: <42955DF7.4000805@pobox.com> Date: Thu, 26 May 2005 01:26:15 -0400 From: Jeff Garzik Reply-To: Linux Kernel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux Kernel , Netdev , "linux-ide@vger.kernel.org" CC: Andrew Morton , Git Mailing List Subject: [doc][git] playing with git, and netdev/libata-dev trees Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 5140 Lines: 172 Hopefully, this email can quick-start some people on git. One of the things Linus's new 'git' tool allows me to do is make public the 50+ repositories that were previously only available on my local workstation. This should make it a lot easier for developers to see precisely what I have merged, and makes generating follow-up patches a whole lot easier. When I merge a patch for drivers/net/forcedeth.c, I merge it into a brand new 'forcedeth' repository, a peer to the 40+ other such repository. Under BitKeeper, I made these repositories available merged together into one big "netdev-2.6" repository because it was too time consuming to make the individual 50+ trees publicly available. With git, developers have direct access to the individual trees. I thought I would write up a quick guide describing how to mess around with the netdev and libata-dev trees, and with git in general. 1) installing git git requires bootstrapping, since you must have git installed in order to check out git.git (git repo), and linux-2.6.git (kernel repo). I have put together a bootstrap tarball of today's git repository. Download tarball from: http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050526.tar.bz2 tarball build-deps: zlib, libcurl install tarball: unpack && make && sudo make prefix=/usr/local install jgarzik helper scripts, not in official git distribution: http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-switch-tree http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script After reading the rest of this document, come back and update your copy of git to the latest: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git 2) download a linux kernel tree for the very first time mkdir -p linux-2.6/.git cd linux-2.6 rsync -a --delete --verbose --stats --progress \ rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \ <- word-wrapped backslash; sigh .git/ 3) download latest changes to on-disk local tree cd linux-2.6 git-pull-script \ rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 4) check out files from the git repository into the working directory cd linux-2.6 git-read-tree -m HEAD && git-checkout-cache -q -f -u -a 5) check in your own modifications (e.g. apply a patch) # go to repo cd linux-2.6 # make some modifications patch -sp1 < /tmp/my.patch diffstat -p1 < /tmp/my.patch # NOTE: add '--add' and/or '--remove' if files were added or removed git-update-cache # commit changes GIT_AUTHOR_NAME="John Doe" \ GIT_AUTHOR_EMAIL="jdoe@foo.com" \ GIT_COMMITTER_NAME="Jeff Garzik" \ GIT_COMMITTER_EMAIL="jgarzik@pobox.com" \ git-commit-tree `git-write-tree` \ -p $(cat .git/HEAD ) \ < changelog.txt \ > .git/HEAD 6) List all changes in working dir, in diff format. git-diff-cache -p HEAD 7) List all changesets (i.e. show each cset's description text) in local tree that are not present in remote tree. cd my-kernel-tree-2.6 git-changes-script -L ../linux-2.6 | less 8) List all changesets: git-whatchanged 9) apply all patches in a Berkeley mbox-format file First, download and add to your PATH Linus's git tools: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git cd my-kernel-tree-2.6 dotest /path/to/mbox # yes, Linus has no taste in naming useful scripts 10) don't forget to download tags from time to time. git-pull-script only downloads sha1-indexed object data, and the requested remote head. This misses updates to the .git/refs/tags/ and .git/refs/heads directories. It is advisable to update your kernel .git directories periodically with a full rsync command, to make sure you got everything: cd linux-2.6 rsync -a --delete --verbose --stats --progress \ rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \ <- word-wrapped backslash; sigh .git/ 11) [jg-specific] list all branches found in netdev-2.6 or libata-dev trees. Download rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git or rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git cd netdev-2.6 ls .git/refs/heads/ { these are the current netdev-2.6 branches } > 8139cp forcedeth master qeth smc91x we18 > 8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi > airo hdlc ns83820 register-netdev starfire > atmel ieee80211 orinoco remove-drivers tlan > chelsio iff-running orinoco-hch sis900 veth > dm9000 janitor ppp skge viro 12) [jg-specific] make desired branch current in working directory git-switch-tree $branch 13) [jg-specific] create a new branch, and make it current git-new-branch $branch 14) [jg-specific] examine which branch is current ls -l .git/HEAD 15) undo all local modifications (same as checkout): git-read-tree -m HEAD && git-checkout-cache -q -f -u -a From davem@davemloft.net Wed May 25 22:34:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 22:34:13 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q5YAXq002820 for ; Wed, 25 May 2005 22:34:10 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbAzN-00082U-4W; Wed, 25 May 2005 22:33:01 -0700 Date: Wed, 25 May 2005 22:33:00 -0700 (PDT) Message-Id: <20050525.223300.15266472.davem@davemloft.net> To: imcdnzl@gmail.com Cc: acme@ghostprotocols.net, netdev@oss.sgi.com Subject: Re: [PATCH 2/2][NET] rename struct tcp_listen_opt to struct listen_sock From: "David S. Miller" In-Reply-To: References: <20050524011758.GJ26989@conectiva.com.br> <20050525.163716.88475834.davem@davemloft.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 364 Lines: 10 From: Ian McDonald Date: Thu, 26 May 2005 11:52:00 +1200 > Maybe I am looking at the wrong place but when I look at: > http://kernel.org/git/?p=linux/kernel/git/acme/net-2.6.13.git;a=summary > > it shows non-network related patches in there as well. Is this intentional? It shows activity in the tree it is derived from, so yes it's normal. From util@deuroconsult.ro Wed May 25 22:50:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 22:50:37 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q5oVXq004518 for ; Wed, 25 May 2005 22:50:32 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4Q5nPD5016135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2005 08:49:26 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4Q5nN0Z016109; Thu, 26 May 2005 08:49:23 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Thu, 26 May 2005 08:49:23 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Stephen Hemminger cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] In-Reply-To: <20050525091427.35621a21@dxpl.pdx.osdl.net> Message-ID: References: <20050525091427.35621a21@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 626 Lines: 24 On Wed, 25 May 2005, Stephen Hemminger wrote: > On Tue, 24 May 2005 10:29:25 +0300 (EEST) > "Catalin(ux aka Dino) BOIE" wrote: > >> Hello! >> >> This patch set bridge device features using the common features of all >> slaves. Also, it reacts to features change using ethtool on the slaves. >> >> This patch depends on NETDEV_FEAT_CHANGE.patch. >> > > I will add it to the next set of patches for bridging. Hold off until > 2.6.13 Thanks, Stephen! P.S. This patch needs NETDEV_FEAT_CHANGE.patch. Do you include both? --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From util@deuroconsult.ro Wed May 25 23:04:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 23:04:25 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q64JXq005761 for ; Wed, 25 May 2005 23:04:20 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4Q63UNF021733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2005 09:03:30 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4Q63TjO021726; Thu, 26 May 2005 09:03:29 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Thu, 26 May 2005 09:03:29 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: [PATCH] dummy: improve performance In-Reply-To: <20050525.151149.08323692.davem@davemloft.net> Message-ID: References: <20050525.151149.08323692.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1653 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 881 Lines: 28 On Wed, 25 May 2005, David S. Miller wrote: > From: "Catalin(ux aka Dino) BOIE" > Date: Fri, 20 May 2005 13:11:24 +0300 (EEST) > >> I tested the speed and seems very low (both old version and the new one). >> Something like 37Mbits/s. It is normal? >> I can easily get 80Mbit/s on the same machine on ethernet. > > How are you receiving packets on the dummy device for > performance testing? This device is a transmit blackhole > and receives no packets :-) I only test the output part. I measure how time it takes to send an amount of data (icmp or udp). > I really don't see a real need for your patch, dummy device > performance cannot be claimed to be important at all. Of course it's not very important. But if someone is using it, why not at full speed? Thanks. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From davem@davemloft.net Wed May 25 23:16:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 23:16:56 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q6GoXq006507 for ; Wed, 25 May 2005 23:16:51 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbBew-0000pB-Mm; Wed, 25 May 2005 23:15:58 -0700 Date: Wed, 25 May 2005 23:15:58 -0700 (PDT) Message-Id: <20050525.231558.104645147.davem@davemloft.net> To: shemminger@osdl.org Cc: netem@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] netem update for 2.4 From: "David S. Miller" In-Reply-To: <20050525135920.659f3a00@dxpl.pdx.osdl.net> References: <20050525135920.659f3a00@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 415 Lines: 11 From: Stephen Hemminger Date: Wed, 25 May 2005 13:59:20 -0700 > This includes the netem changes for 2.6 retargeted for 2.4 > It covers: > * make duplication reinsert from root to fix qlen issues > * just use embedded qdisc for queueing to avoid qlen issues > * probabilistic reordering support Let's keep 2.4.x to pure bug fixes, so the new reordering support should be omitted. Thanks. From util@deuroconsult.ro Wed May 25 23:37:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 25 May 2005 23:38:01 -0700 (PDT) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q6bvXq007498 for ; Wed, 25 May 2005 23:37:58 -0700 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j4Q6b0Ew003109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2005 09:37:00 +0300 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j4Q6axLb003106; Thu, 26 May 2005 09:36:59 +0300 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Thu, 26 May 2005 09:36:59 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Stephen Hemminger cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] [BRIDGE] In-Reply-To: <20050525144633.3a6f253e@dxpl.pdx.osdl.net> Message-ID: References: <20050525091427.35621a21@dxpl.pdx.osdl.net> <20050525144633.3a6f253e@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 3999 Lines: 138 On Wed, 25 May 2005, Stephen Hemminger wrote: > Here is the revised version, it deals with checksum mixtures better and > ignores stuff until bridge is up. This patch missing the case when we have HW_CSUM (for example) on the bridge device, and a new device that has no HW_CSUM is added. The fix is to call br_features_recompute(br) also in br_add_if(). Thanks. > Index: bridge/net/bridge/br_private.h > =================================================================== > --- bridge.orig/net/bridge/br_private.h > +++ bridge/net/bridge/br_private.h > @@ -174,6 +174,7 @@ extern int br_add_if(struct net_bridge * > extern int br_del_if(struct net_bridge *br, > struct net_device *dev); > extern int br_min_mtu(const struct net_bridge *br); > +extern void br_features_recompute(struct net_bridge *br); > > /* br_input.c */ > extern int br_handle_frame_finish(struct sk_buff *skb); > Index: bridge/net/bridge/br_notify.c > =================================================================== > --- bridge.orig/net/bridge/br_notify.c > +++ bridge/net/bridge/br_notify.c > @@ -65,6 +65,15 @@ static int br_device_event(struct notifi > } > break; > > + case NETDEV_FEAT_CHANGE: > + if (br->dev->flags & IFF_UP) > + br_features_recompute(br); > + > + /* could do recursive feature change notification > + * but who would care?? > + */ > + break; > + > case NETDEV_DOWN: > if (br->dev->flags & IFF_UP) > br_stp_disable_port(p); > Index: bridge/net/bridge/br_device.c > =================================================================== > --- bridge.orig/net/bridge/br_device.c > +++ bridge/net/bridge/br_device.c > @@ -21,10 +21,7 @@ > > static struct net_device_stats *br_dev_get_stats(struct net_device *dev) > { > - struct net_bridge *br; > - > - br = dev->priv; > - > + struct net_bridge *br = netdev_priv(dev); > return &br->statistics; > } > > @@ -54,9 +51,11 @@ int br_dev_xmit(struct sk_buff *skb, str > > static int br_dev_open(struct net_device *dev) > { > - netif_start_queue(dev); > + struct net_bridge *br = netdev_priv(dev); > > - br_stp_enable_bridge(dev->priv); > + br_features_recompute(br); > + netif_start_queue(dev); > + br_stp_enable_bridge(br); > > return 0; > } > @@ -67,7 +66,7 @@ static void br_dev_set_multicast_list(st > > static int br_dev_stop(struct net_device *dev) > { > - br_stp_disable_bridge(dev->priv); > + br_stp_disable_bridge(netdev_priv(dev)); > > netif_stop_queue(dev); > > @@ -76,7 +75,7 @@ static int br_dev_stop(struct net_device > > static int br_change_mtu(struct net_device *dev, int new_mtu) > { > - if ((new_mtu < 68) || new_mtu > br_min_mtu(dev->priv)) > + if (new_mtu < 68 || new_mtu > br_min_mtu(netdev_priv(dev))) > return -EINVAL; > > dev->mtu = new_mtu; > Index: bridge/net/bridge/br_if.c > =================================================================== > --- bridge.orig/net/bridge/br_if.c > +++ bridge/net/bridge/br_if.c > @@ -314,6 +314,28 @@ int br_min_mtu(const struct net_bridge * > return mtu; > } > > +/* > + * Recomputes features using slave's features > + */ > +void br_features_recompute(struct net_bridge *br) > +{ > + struct net_bridge_port *p; > + unsigned long features, checksum; > + > + features = NETIF_F_SG | NETIF_F_FRAGLIST > + | NETIF_F_HIGHDMA | NETIF_F_TSO; > + checksum = NETIF_F_IP_CSUM; /* least commmon subset */ > + > + list_for_each_entry(p, &br->port_list, list) { > + if (!(p->dev->features > + & (NETIF_F_IP_CSUM|NETIF_F_NO_CSUM|NETIF_F_HW_CSUM))) > + checksum = 0; > + features &= p->dev->features; > + } > + > + br->dev->features = features | checksum | NETIF_F_LLTX; > +} > + > /* called with RTNL */ > int br_add_if(struct net_bridge *br, struct net_device *dev) > { > @@ -368,6 +390,7 @@ int br_del_if(struct net_bridge *br, str > > spin_lock_bh(&br->lock); > br_stp_recalculate_bridge_id(br); > + br_features_recompute(br); > spin_unlock_bh(&br->lock); > > return 0; > --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From akpm@osdl.org Thu May 26 00:41:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 00:41:26 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q7fKXq014820 for ; Thu, 26 May 2005 00:41:21 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4Q7dIjA005570 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 May 2005 00:39:18 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4Q7dGXW009502; Thu, 26 May 2005 00:39:16 -0700 Date: Thu, 26 May 2005 00:38:28 -0700 From: Andrew Morton To: Jian Jun He , john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Cc: ganesh.venkatesan@gmail.com, anton@samba.org, herbert@gondor.apana.org.au, jgarzik@pobox.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com, rende@cn.ibm.com, wangjs@cn.ibm.com, cdlwangl@cn.ibm.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-Id: <20050526003828.213ad052.akpm@osdl.org> In-Reply-To: References: <5fc59ff3050516104367a8d5cd@mail.gmail.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1060 Lines: 38 Jian Jun He wrote: > > I download e100-3.4.8 and installed in the test machine (both client and > server). But the server still hang while running rhr (network) test. :( e100 is one of those drivers which we'd rather like to have working properly. Can we please confirm that a) this bug is not fixed in 2.6.12-rc5 and b) nobody has seen a patch which fixes it? For reference: Herbert Xu wrote: > > Andrew Morton wrote: > > > > Might be a bug in the e100 driver, might not be. > > > > I assume this is the > > > > BUG_ON(skb->list != NULL); > > It certainly is a bug in e100. > > e100_tx_timeout -> e100_down -> e100_rx_clean_list > > is racing against > > e100_poll -> e100_rx_clean -> e100_rx_indicate > > e100_rx_clean/e100_rx_indicate takes an skb off the RX ring and > while it's being processed e100_rx_clean_list comes along and > frees it. > > >From a quick check similar problems may exist in other drivers that > have lockless ->poll() functions with RX rings. From jgarzik@pobox.com Thu May 26 00:54:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 00:54:12 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4Q7s7Xq015514 for ; Thu, 26 May 2005 00:54:09 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DbDAu-0002mj-VI; Thu, 26 May 2005 07:53:06 +0000 Message-ID: <4295805E.3060809@pobox.com> Date: Thu, 26 May 2005 03:53:02 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: Jian Jun He , john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com, ganesh.venkatesan@gmail.com, anton@samba.org, herbert@gondor.apana.org.au, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com, rende@cn.ibm.com, wangjs@cn.ibm.com, cdlwangl@cn.ibm.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 References: <5fc59ff3050516104367a8d5cd@mail.gmail.com> <20050526003828.213ad052.akpm@osdl.org> In-Reply-To: <20050526003828.213ad052.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 482 Lines: 15 Andrew Morton wrote: > Jian Jun He wrote: > >>I download e100-3.4.8 and installed in the test machine (both client and >> server). But the server still hang while running rhr (network) test. :( > > > e100 is one of those drivers which we'd rather like to have working properly. > > Can we please confirm that a) this bug is not fixed in 2.6.12-rc5 and b) > nobody has seen a patch which fixes it? 2.6.12-rc5-git1 should have an e100 update in it, too... From ganesh.venkatesan@intel.com Thu May 26 06:01:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 06:02:05 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QD1vXq005618 for ; Thu, 26 May 2005 06:01:58 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4QD0AQQ017053; Thu, 26 May 2005 13:00:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4QD0AOe004257; Thu, 26 May 2005 13:00:10 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052606001009649 ; Thu, 26 May 2005 06:00:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 06:00:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Date: Thu, 26 May 2005 06:00:00 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E056B8C25@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Thread-Index: AcVhxjQcODcPiQc5RpaEqaUBamjWqQALGERQ From: "Venkatesan, Ganesh" To: "Andrew Morton" , "Jian Jun He" , "Ronciak, John" , "Brandeburg, Jesse" Cc: , , , , , , , , X-OriginalArrivalTime: 26 May 2005 13:00:02.0670 (UTC) FILETIME=[D498F0E0:01C561F2] X-Scanned-By: MIMEDefang 2.44 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4QD1vXq005618 X-archive-position: 1658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1861 Lines: 64 Jian: We need more information on the test you run to get this hang. We have not seen a hang similar to the one you describe. We have a p-series machine in our lab and all we need is details on the test to run. Thanks, Ganesh. >-----Original Message----- >From: Andrew Morton [mailto:akpm@osdl.org] >Sent: Thursday, May 26, 2005 12:38 AM >To: Jian Jun He; Ronciak, John; Venkatesan, Ganesh; Brandeburg, Jesse >Cc: ganesh.venkatesan@gmail.com; anton@samba.org; >herbert@gondor.apana.org.au; jgarzik@pobox.com; linuxppc64- >dev@lists.linuxppc.org.sgi.com; netdev@oss.sgi.com; rende@cn.ibm.com; >wangjs@cn.ibm.com; cdlwangl@cn.ibm.com >Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running >rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 > >Jian Jun He wrote: >> >> I download e100-3.4.8 and installed in the test machine (both client and >> server). But the server still hang while running rhr (network) test. :( > >e100 is one of those drivers which we'd rather like to have working >properly. > >Can we please confirm that a) this bug is not fixed in 2.6.12-rc5 and b) >nobody has seen a patch which fixes it? > > > >For reference: > >Herbert Xu wrote: >> >> Andrew Morton wrote: >> > >> > Might be a bug in the e100 driver, might not be. >> > >> > I assume this is the >> > >> > BUG_ON(skb->list != NULL); >> >> It certainly is a bug in e100. >> >> e100_tx_timeout -> e100_down -> e100_rx_clean_list >> >> is racing against >> >> e100_poll -> e100_rx_clean -> e100_rx_indicate >> >> e100_rx_clean/e100_rx_indicate takes an skb off the RX ring and >> while it's being processed e100_rx_clean_list comes along and >> frees it. >> >> >From a quick check similar problems may exist in other drivers that >> have lockless ->poll() functions with RX rings. From laforge@netfilter.org Thu May 26 07:25:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 07:25:21 -0700 (PDT) Received: from ganesha.gnumonks.org (ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QEPEXq008568 for ; Thu, 26 May 2005 07:25:14 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1DbJHa-0006hR-9y; Thu, 26 May 2005 16:24:22 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DbJHZ-000860-17; Thu, 26 May 2005 16:24:21 +0200 Date: Thu, 26 May 2005 16:24:21 +0200 From: Harald Welte To: Netfilter Development Mailinglist Cc: Linux Netdev List , James Morris Subject: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path Message-ID: <20050526142420.GD13114@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , Netfilter Development Mailinglist , Linux Netdev List , James Morris Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r3Mh/mGWsojp83Sz" Content-Disposition: inline User-Agent: mutt-ng 1.5.8-r168i (Debian) X-archive-position: 1659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 13159 Lines: 436 --r3Mh/mGWsojp83Sz Content-Type: multipart/mixed; boundary="moLig8uJibGkz5Yz" Content-Disposition: inline --moLig8uJibGkz5Yz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! When we have ip_queue being used from LOCAL_IN, then we end up with a situation where the verdicts coming back from userspace traverse the TCP input path from syscall context. While this seems to work most of the time, there's an ungly deadlock: syscall context is interrupted by the timer interrupt. When the timer interrupt leaves, the timer softirq get's scheduled and calls tcp_delack_timer() and alike. They themselves do bh_lock_sock(sk), which is already held from somewhere else[1] -> boom. The patch below adds an additional queue for ip_queue verdicts. They come up from userspace, are appended to a queue which is then processed by a tasklet. The tasklet itself runs in softirq context, so when timer hardirq leaves, no tcp_delack_timer() will be executed until nf_reinject() has finished. Dave: Please don't apply yet, I want to receive feedback from the netfilter developers first. I'm just Cc'ing netdev in case somebody wants an intermediate fix to fix the problem. [1] i didn't actually find from where that lock was held. In any case, it didn't seem nice to traverse the IP input codepath from syscall context. There might be a number of places which just assume to run in softirq. Comments welcome! --=20 - Harald Welte http://netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --moLig8uJibGkz5Yz Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="2.6.12-rc5-ip_queue-local-reinject-smp-deadlock-fix.patch" Content-Transfer-Encoding: quoted-printable Fix ip_queue when used from LOCAL_IN hook. Without this patch, packets are nf_reinject()ed from syscall context. Syscall context will be interupted =66rom timer interrupt, and timer interrupt will call TCP timer code such as tcp_delack_timer(), which in turn tries to bh_lock_sock() and deadlocks at = that point. Thanks to Holger Eitzenberger and=20 Stephan Scholz for providing me with backtraces. Signed-off-by: Harald Welte Index: linux-2.6.12-rc5/net/ipv4/netfilter/ip_queue.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.12-rc5.orig/net/ipv4/netfilter/ip_queue.c 2005-05-26 15:50:01= =2E000000000 +0200 +++ linux-2.6.12-rc5/net/ipv4/netfilter/ip_queue.c 2005-05-26 16:09:08.0000= 00000 +0200 @@ -3,6 +3,8 @@ * communicating with userspace via netlink. * * (C) 2000-2002 James Morris + * (C) 2003-2004 Netfilter Core Team + * (C) 2005 Harald Welte * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -17,6 +19,9 @@ * 2005-01-10: Added /proc counter for dropped packets; fixed so * packets aren't delivered to user space if they're going=20 * to be dropped.=20 + * 2005-05-25: Issue verdict from tasklet context, not from syscall (netli= nk + * sendmsg) to avoid deadlocks in TCP input path with timer + * softirq. * */ #include @@ -40,6 +45,7 @@ #define IPQ_PROC_FS_NAME "ip_queue" #define NET_IPQ_QMAX 2088 #define NET_IPQ_QMAX_NAME "ip_queue_maxlen" +#define IPQ_VERDICT_BATCH 10 =20 struct ipq_rt_info { __u8 tos; @@ -52,6 +58,16 @@ struct nf_info *info; struct sk_buff *skb; struct ipq_rt_info rt_info; + + /* only used in verdict_queue */ + int verdict; +}; + +struct ipq_queue { + struct list_head list; + unsigned int total; + unsigned int dropped; + unsigned int user_dropped; }; =20 typedef int (*ipq_cmpfn)(struct ipq_queue_entry *, unsigned long); @@ -61,14 +77,16 @@ static DEFINE_RWLOCK(queue_lock); static int peer_pid; static unsigned int copy_range; -static unsigned int queue_total; -static unsigned int queue_dropped =3D 0; -static unsigned int queue_user_dropped =3D 0; static struct sock *ipqnl; -static LIST_HEAD(queue_list); static DECLARE_MUTEX(ipqnl_sem); =20 -static void +static struct ipq_queue pkt_queue; /* queue of packets to userspace */ +static struct ipq_queue verdict_queue; /* queue of verdicst from userspace= */ + +static void ipq_verdict_task(unsigned long arg); +static DECLARE_TASKLET(ipq_verdict_tasklet, ipq_verdict_task, 0); + +static inline void ipq_issue_verdict(struct ipq_queue_entry *entry, int verdict) { nf_reinject(entry->skb, entry->info, verdict); @@ -76,10 +94,10 @@ } =20 static inline void -__ipq_enqueue_entry(struct ipq_queue_entry *entry) +__ipq_enqueue_entry(struct ipq_queue *queue, struct ipq_queue_entry *entry) { - list_add(&entry->list, &queue_list); - queue_total++; + list_add(&entry->list, &queue->list); + queue->total++; } =20 /* @@ -87,11 +105,11 @@ * entry if cmpfn is NULL. */ static inline struct ipq_queue_entry * -__ipq_find_entry(ipq_cmpfn cmpfn, unsigned long data) +__ipq_find_entry(struct ipq_queue *queue, ipq_cmpfn cmpfn, unsigned long d= ata) { struct list_head *p; =20 - list_for_each_prev(p, &queue_list) { + list_for_each_prev(p, &queue->list) { struct ipq_queue_entry *entry =3D (struct ipq_queue_entry *)p; =09 if (!cmpfn || cmpfn(entry, data)) @@ -101,33 +119,49 @@ } =20 static inline void -__ipq_dequeue_entry(struct ipq_queue_entry *entry) +__ipq_dequeue_entry(struct ipq_queue *queue, struct ipq_queue_entry *entry) { list_del(&entry->list); - queue_total--; + queue->total--; } =20 static inline struct ipq_queue_entry * -__ipq_find_dequeue_entry(ipq_cmpfn cmpfn, unsigned long data) +__ipq_find_dequeue_entry(struct ipq_queue *queue, ipq_cmpfn cmpfn,=20 + unsigned long data) { struct ipq_queue_entry *entry; =20 - entry =3D __ipq_find_entry(cmpfn, data); + entry =3D __ipq_find_entry(queue, cmpfn, data); if (entry =3D=3D NULL) return NULL; =20 - __ipq_dequeue_entry(entry); + __ipq_dequeue_entry(queue, entry); return entry; } =20 +static void +ipq_enqueue_verdict(struct ipq_queue_entry *entry, int verdict) +{ + entry->verdict =3D verdict; + + write_lock_bh(&queue_lock); + if (verdict_queue.total >=3D queue_maxlen) { + verdict_queue.dropped++; + write_unlock_bh(&queue_lock); + } + __ipq_enqueue_entry(&verdict_queue, entry); + write_unlock_bh(&queue_lock); + + tasklet_schedule(&ipq_verdict_tasklet); +} =20 static inline void __ipq_flush(int verdict) { struct ipq_queue_entry *entry; =09 - while ((entry =3D __ipq_find_dequeue_entry(NULL, 0))) - ipq_issue_verdict(entry, verdict); + while ((entry =3D __ipq_find_dequeue_entry(&pkt_queue, NULL, 0))) + ipq_enqueue_verdict(entry, verdict); } =20 static inline int @@ -166,12 +200,13 @@ } =20 static struct ipq_queue_entry * -ipq_find_dequeue_entry(ipq_cmpfn cmpfn, unsigned long data) +ipq_find_dequeue_entry(struct ipq_queue *queue, ipq_cmpfn cmpfn,=20 + unsigned long data) { struct ipq_queue_entry *entry; =09 write_lock_bh(&queue_lock); - entry =3D __ipq_find_dequeue_entry(cmpfn, data); + entry =3D __ipq_find_dequeue_entry(queue, cmpfn, data); write_unlock_bh(&queue_lock); return entry; } @@ -182,6 +217,7 @@ write_lock_bh(&queue_lock); __ipq_flush(verdict); write_unlock_bh(&queue_lock); + } =20 static struct sk_buff * @@ -306,24 +342,24 @@ if (!peer_pid) goto err_out_free_nskb;=20 =20 - if (queue_total >=3D queue_maxlen) { - queue_dropped++; + if (pkt_queue.total >=3D queue_maxlen) { + pkt_queue.dropped++; status =3D -ENOSPC; if (net_ratelimit()) printk (KERN_WARNING "ip_queue: full at %d entries, " - "dropping packets(s). Dropped: %d\n", queue_total, - queue_dropped); + "dropping packets(s). Dropped: %d\n",=20 + pkt_queue.total, pkt_queue.dropped); goto err_out_free_nskb; } =20 /* netlink_unicast will either free the nskb or attach it to a socket */= =20 status =3D netlink_unicast(ipqnl, nskb, peer_pid, MSG_DONTWAIT); if (status < 0) { - queue_user_dropped++; + pkt_queue.user_dropped++; goto err_out_unlock; } =20 - __ipq_enqueue_entry(entry); + __ipq_enqueue_entry(&pkt_queue, entry); =20 write_unlock_bh(&queue_lock); return status; @@ -406,7 +442,7 @@ if (vmsg->value > NF_MAX_VERDICT) return -EINVAL; =20 - entry =3D ipq_find_dequeue_entry(id_cmp, vmsg->id); + entry =3D ipq_find_dequeue_entry(&pkt_queue, id_cmp, vmsg->id); if (entry =3D=3D NULL) return -ENOENT; else { @@ -416,7 +452,11 @@ if (ipq_mangle_ipv4(vmsg, entry) < 0) verdict =3D NF_DROP; =09 - ipq_issue_verdict(entry, verdict); + /* instead of issuing the verdict herer from syscall + * context, we enqueue the verdict to the verdict_queue, + * which is later processed by softirq context */ + ipq_enqueue_verdict(entry, verdict); + return 0; } } @@ -479,8 +519,9 @@ { struct ipq_queue_entry *entry; =09 - while ((entry =3D ipq_find_dequeue_entry(dev_cmp, ifindex)) !=3D NULL) - ipq_issue_verdict(entry, NF_DROP); + while ((entry =3D ipq_find_dequeue_entry(&pkt_queue, + dev_cmp, ifindex)) !=3D NULL) + ipq_enqueue_verdict(entry, NF_DROP); } =20 #define RCV_SKB_FAIL(err) do { netlink_ack(skb, nlh, (err)); return; } whi= le (0) @@ -630,6 +671,29 @@ { .ctl_name =3D 0 } }; =20 +/* This tasklet feeds queued verdicts through the network stack. Since it= runs + * in tasklet softirq context, this makes the TCP local input path happy -= HW */ +static void +ipq_verdict_task(unsigned long arg) +{ + struct ipq_queue_entry *entry; + unsigned int num =3D 0; + + /* we want to stall other processing for too long. */ + for (num =3D 0; num < IPQ_VERDICT_BATCH; num++) { + entry =3D ipq_find_dequeue_entry(&verdict_queue, NULL, 0); + if (!entry) { + break; + } + ipq_issue_verdict(entry, entry->verdict); + } + + if (verdict_queue.total) { + /* more work to be done, schedule us again */ + tasklet_schedule(&ipq_verdict_tasklet); + } +} + #ifdef CONFIG_PROC_FS static int ipq_get_info(char *buffer, char **start, off_t offset, int length) @@ -639,20 +703,24 @@ read_lock_bh(&queue_lock); =09 len =3D sprintf(buffer, - "Peer PID : %d\n" - "Copy mode : %hu\n" - "Copy range : %u\n" - "Queue length : %u\n" - "Queue max. length : %u\n" - "Queue dropped : %u\n" - "Netlink dropped : %u\n", + "Peer PID : %d\n" + "Copy mode : %hu\n" + "Copy range : %u\n" + "Queue length : %u\n" + "Queue max. length : %u\n" + "Queue dropped : %u\n" + "Netlink dropped : %u\n" + "Verdict queue len : %u\n" + "Verdict queue dropped : %u\n", peer_pid, copy_mode, copy_range, - queue_total, + pkt_queue.total, queue_maxlen, - queue_dropped, - queue_user_dropped); + pkt_queue.dropped, + pkt_queue.user_dropped, + verdict_queue.total, + verdict_queue.dropped); =20 read_unlock_bh(&queue_lock); =09 @@ -675,6 +743,16 @@ if (!init) goto cleanup; =20 + INIT_LIST_HEAD(&pkt_queue.list); + pkt_queue.total =3D 0; + pkt_queue.dropped =3D 0; + pkt_queue.user_dropped =3D 0; + + INIT_LIST_HEAD(&verdict_queue.list); + verdict_queue.total =3D 0; + verdict_queue.dropped =3D 0; + verdict_queue.user_dropped =3D 0; + netlink_register_notifier(&ipq_nl_notifier); ipqnl =3D netlink_kernel_create(NETLINK_FIREWALL, ipq_rcv_sk); if (ipqnl =3D=3D NULL) { @@ -704,6 +782,14 @@ nf_unregister_queue_handler(PF_INET); synchronize_net(); ipq_flush(NF_DROP); + + while (verdict_queue.total !=3D 0) { + printk(KERN_INFO "ip_queue: verdict queue not empty while " + "module unload, scheduling\n"); + tasklet_schedule(&ipq_verdict_tasklet); + schedule(); + } + tasklet_disable(&ipq_verdict_tasklet); =09 cleanup_sysctl: unregister_sysctl_table(ipq_sysctl_header); --moLig8uJibGkz5Yz-- --r3Mh/mGWsojp83Sz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCldwUXaXGVTD0i/8RAiacAJ9VwFtQlrTRw5Q+4VOhi3gIBXK2HgCglnst cKqDqvL40obw2X/wjkCjdEs= =tE3A -----END PGP SIGNATURE----- --r3Mh/mGWsojp83Sz-- From cranium2003@yahoo.com Thu May 26 07:41:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 07:41:48 -0700 (PDT) Received: from web33004.mail.mud.yahoo.com (web33004.mail.mud.yahoo.com [68.142.206.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4QEfjXq009448 for ; Thu, 26 May 2005 07:41:45 -0700 Received: (qmail 11892 invoked by uid 60001); 26 May 2005 14:40:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=r9KkpEgaBH2utF07P4KAWtg1+9oCf6yHkKGIS0X47svs57/FMJEOh0cpsAxyv+DeS5spJ+kVumQV/RJwwRZLvABdFbnOSNc23/iOtZW+4F6ozvNkIfcsddTgtWdF+UK5QrynsGcLCZKocLy1wUUyAuO2rVqXh+PUBHdMJ8q9lGk= ; Message-ID: <20050526144058.11890.qmail@web33004.mail.mud.yahoo.com> Received: from [203.145.159.37] by web33004.mail.mud.yahoo.com via HTTP; Thu, 26 May 2005 07:40:57 PDT Date: Thu, 26 May 2005 07:40:57 -0700 (PDT) From: cranium2003 Subject: getting eth1: Memory squeeze, dropping packet message To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 531 Lines: 20 Hello, While transmitting packets through linux Router host from one network to another Redhat linux 9 kernel 2.4.20-8 caught kernel oops following there are 2 statements which are __alloc_pages: 0 order allocation failed (gfp = 0x20/1) eth1: Memory squeeze, dropping packet What this means? where is the wrong thing in kenrel? How to solve this problem? regards, cranium. __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From jdmason@us.ibm.com Thu May 26 09:23:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 09:23:10 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QGN1Xq024755 for ; Thu, 26 May 2005 09:23:08 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4QGMDua185578 for ; Thu, 26 May 2005 12:22:13 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4QGMC0D114034 for ; Thu, 26 May 2005 10:22:12 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4QGMCRS030043 for ; Thu, 26 May 2005 10:22:12 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4QGMCBV030016; Thu, 26 May 2005 10:22:12 -0600 From: Jon Mason Organization: IBM To: cranium2003 Subject: Re: getting eth1: Memory squeeze, dropping packet message Date: Thu, 26 May 2005 11:22:11 -0500 User-Agent: KMail/1.7.2 Cc: net dev References: <20050526144058.11890.qmail@web33004.mail.mud.yahoo.com> In-Reply-To: <20050526144058.11890.qmail@web33004.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505261122.11552.jdmason@us.ibm.com> X-archive-position: 1663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 686 Lines: 22 On Thursday 26 May 2005 09:40 am, cranium2003 wrote: > Hello, > While transmitting packets through linux Router > host from one network to another Redhat linux 9 kernel > 2.4.20-8 caught kernel oops following there are 2 > statements which are > __alloc_pages: 0 order allocation failed (gfp = > 0x20/1) > eth1: Memory squeeze, dropping packet > What this means? The driver was trying to alloc a rx skb and couldn't. The incoming packet was dropped. Assuming that the error logged is the only problem you saw, this isn't a driver or kernel bug. It means you were out of free kernel memory. You can see if you have any processes consuming lots of memory. Thanks, Jon From laforge@gnumonks.org Thu May 26 11:12:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:12:20 -0700 (PDT) Received: from ganesha.gnumonks.org (ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIC8Xq031143 for ; Thu, 26 May 2005 11:12:14 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1DbMpE-0001Se-40; Thu, 26 May 2005 20:11:20 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DbMpC-0008Jb-Id; Thu, 26 May 2005 20:11:18 +0200 Date: Thu, 26 May 2005 20:11:18 +0200 From: Harald Welte To: David Miller Cc: Hasso Tepper , netdev@oss.sgi.com Subject: Re: primary and secondary ip addresses Message-ID: <20050526181118.GK13114@sunbeam.de.gnumonks.org> References: <1103550901.1050.292.camel@jzny.localdomain> <20050412105442.GV7510@sunbeam.de.gnumonks.org> <200505081531.16106.hasso@estpak.ee> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rJP+s0P3Mdby0EAF" Content-Disposition: inline In-Reply-To: <200505081531.16106.hasso@estpak.ee> User-Agent: mutt-ng 1.5.8-r168i (Debian) X-archive-position: 1670 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 5746 Lines: 186 --rJP+s0P3Mdby0EAF Content-Type: multipart/mixed; boundary="tOe3bw3OA0Dbc3H7" Content-Disposition: inline --tOe3bw3OA0Dbc3H7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable David, would you consider applying that patch to mainline? I think there was concensus on this solution, and it has now received some amount of testing by Hasso and me. Thanks! On Sun, May 08, 2005 at 03:31:15PM +0300, Hasso Tepper wrote: > Harald Welte wrote: > > On Mon, Dec 20, 2004 at 08:55:02AM -0500, jamal wrote: > >=20 > > > Didnt boot ;-> > > > A small silly magic number i missed. Now boots - but doesnt mean it > > > works. And i dont have much time to spare chasing it. > >=20 > > Due to a customer having again trouble with this issue, I was forced to > > actually spend some time testing it (and merging it to a current > > kernel). At least in my simple tests, it worked like a charm :) >=20 > I'm using it for some weeks in production and haven't noticed any issues > either. Would be really good to see it kernel. >=20 >=20 > regards, >=20 > --=20 > Hasso Tepper > Elion Enterprises Ltd. > WAN administrator >=20 --=20 - Harald Welte http://gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) --tOe3bw3OA0Dbc3H7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="linux-2.6.12-rc2-promote_secondaries.patch" Content-Transfer-Encoding: quoted-printable Signed-off-by: Harald Welte diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E12-rc2/include/linux/inetdevice.h linux-2.6.12-rc2-propag/include/linux/= inetdevice.h --- linux-2.6.12-rc2/include/linux/inetdevice.h 2005-03-02 08:38:13.0000000= 00 +0100 +++ linux-2.6.12-rc2-propag/include/linux/inetdevice.h 2005-04-12 10:21:45.= 000000000 +0200 @@ -29,6 +29,7 @@ int no_xfrm; int no_policy; int force_igmp_version; + int promote_secondaries; void *sysctl; }; =20 @@ -71,6 +72,7 @@ #define IN_DEV_SEC_REDIRECTS(in_dev) (ipv4_devconf.secure_redirects || (in= _dev)->cnf.secure_redirects) #define IN_DEV_IDTAG(in_dev) ((in_dev)->cnf.tag) #define IN_DEV_MEDIUM_ID(in_dev) ((in_dev)->cnf.medium_id) +#define IN_DEV_PROMOTE_SECONDARIES(in_dev) (ipv4_devconf.promote_secondari= es || (in_dev)->cnf.promote_secondaries) =20 #define IN_DEV_RX_REDIRECTS(in_dev) \ ((IN_DEV_FORWARD(in_dev) && \ diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E12-rc2/include/linux/sysctl.h linux-2.6.12-rc2-propag/include/linux/sysc= tl.h --- linux-2.6.12-rc2/include/linux/sysctl.h 2005-04-09 12:59:20.000000000 += 0200 +++ linux-2.6.12-rc2-propag/include/linux/sysctl.h 2005-04-12 10:18:38.0000= 00000 +0200 @@ -399,6 +399,7 @@ NET_IPV4_CONF_FORCE_IGMP_VERSION=3D17, NET_IPV4_CONF_ARP_ANNOUNCE=3D18, NET_IPV4_CONF_ARP_IGNORE=3D19, + NET_IPV4_CONF_PROMOTE_SECONDARIES=3D20, __NET_IPV4_CONF_MAX }; =20 diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E12-rc2/net/ipv4/devinet.c linux-2.6.12-rc2-propag/net/ipv4/devinet.c --- linux-2.6.12-rc2/net/ipv4/devinet.c 2005-04-09 12:59:21.000000000 +0200 +++ linux-2.6.12-rc2-propag/net/ipv4/devinet.c 2005-04-12 10:19:53.00000000= 0 +0200 @@ -233,11 +233,14 @@ static void inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap, int destroy) { + struct in_ifaddr *promote =3D NULL; struct in_ifaddr *ifa1 =3D *ifap; =20 ASSERT_RTNL(); =20 - /* 1. Deleting primary ifaddr forces deletion all secondaries */ + /* 1. Deleting primary ifaddr forces deletion all secondaries=20 + * unless alias promotion is set + **/ =20 if (!(ifa1->ifa_flags & IFA_F_SECONDARY)) { struct in_ifaddr *ifa; @@ -251,11 +254,16 @@ continue; } =20 - *ifap1 =3D ifa->ifa_next; + if (!IN_DEV_PROMOTE_SECONDARIES(in_dev)) { + *ifap1 =3D ifa->ifa_next; =20 - rtmsg_ifa(RTM_DELADDR, ifa); - notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa); - inet_free_ifa(ifa); + rtmsg_ifa(RTM_DELADDR, ifa); + notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa); + inet_free_ifa(ifa); + } else { + promote =3D ifa; + break; + } } } =20 @@ -281,6 +289,13 @@ if (!in_dev->ifa_list) inetdev_destroy(in_dev); } + + if (promote && IN_DEV_PROMOTE_SECONDARIES(in_dev)) { + /* not sure if we should send a delete notify first? */ + promote->ifa_flags &=3D ~IFA_F_SECONDARY; + rtmsg_ifa(RTM_NEWADDR, promote); + notifier_call_chain(&inetaddr_chain, NETDEV_UP, promote); + } } =20 static int inet_insert_ifa(struct in_ifaddr *ifa) @@ -1383,6 +1398,15 @@ .proc_handler =3D &ipv4_doint_and_flush, .strategy =3D &ipv4_doint_and_flush_strategy, }, + { + .ctl_name =3D NET_IPV4_CONF_PROMOTE_SECONDARIES, + .procname =3D "promote_secondaries", + .data =3D &ipv4_devconf.promote_secondaries, + .maxlen =3D sizeof(int), + .mode =3D 0644, + .proc_handler =3D &ipv4_doint_and_flush, + .strategy =3D &ipv4_doint_and_flush_strategy, + }, }, .devinet_dev =3D { { --tOe3bw3OA0Dbc3H7-- --rJP+s0P3Mdby0EAF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFClhFGXaXGVTD0i/8RAieuAKCGQk9ghRjS3KHBAwh2eaAtdnyMcgCfTATK L/U/7TetWDveEfoV/9Yz8Ho= =PiZp -----END PGP SIGNATURE----- --rJP+s0P3Mdby0EAF-- From tgraf@suug.ch Thu May 26 11:22:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:22:31 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIMOXq031783 for ; Thu, 26 May 2005 11:22:24 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id D2A551C0EB; Thu, 26 May 2005 20:21:46 +0200 (CEST) Date: Thu, 26 May 2005 20:21:46 +0200 From: Thomas Graf To: Harald Welte Cc: David Miller , Hasso Tepper , netdev@oss.sgi.com Subject: Re: primary and secondary ip addresses Message-ID: <20050526182146.GV15391@postel.suug.ch> References: <1103550901.1050.292.camel@jzny.localdomain> <20050412105442.GV7510@sunbeam.de.gnumonks.org> <200505081531.16106.hasso@estpak.ee> <20050526181118.GK13114@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526181118.GK13114@sunbeam.de.gnumonks.org> X-archive-position: 1671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 914 Lines: 25 * Harald Welte <20050526181118.GK13114@sunbeam.de.gnumonks.org> 2005-05-26 20:11 > David, would you consider applying that patch to mainline? I think > there was concensus on this solution, and it has now received some > amount of testing by Hasso and me. I agree, I've been running this patch for 3 weeks now without any problems. Two comments below. > @@ -281,6 +289,13 @@ > if (!in_dev->ifa_list) > inetdev_destroy(in_dev); > } > + > + if (promote && IN_DEV_PROMOTE_SECONDARIES(in_dev)) { promote can only be !=NULL if promotion is enabled, no? > + /* not sure if we should send a delete notify first? */ > + promote->ifa_flags &= ~IFA_F_SECONDARY; > + rtmsg_ifa(RTM_NEWADDR, promote); This can be improved, however sending a delete/add seems inappropriate. I've patch prepared to add a change mask which will give us the proper methods to do this right but for now this is just fine I guess. From mchan@broadcom.com Thu May 26 11:31:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:31:55 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIVrXq032721 for ; Thu, 26 May 2005 11:31:53 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:30:53 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:30:52 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO49928; Thu, 26 May 2005 11:30:52 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA19740; Thu, 26 May 2005 11:30:51 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:30:51 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 10:33:15 -0700 Subject: [PATCH 2.6.12-rc5 0/9] tg3: Add ethtool selftest From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com Date: Thu, 26 May 2005 10:33:15 -0700 Message-ID: <1117128795.3744.22.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88CA571VO2246899-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 112 Lines: 3 I tried to keep these patches reasonably small. The total added size is about 5K on i386. Patches will follow. From shemminger@osdl.org Thu May 26 11:33:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:33:12 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIX9Xq000595 for ; Thu, 26 May 2005 11:33:09 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4QIWJjA022465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 May 2005 11:32:19 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4QIWIcg005184; Thu, 26 May 2005 11:32:18 -0700 Date: Thu, 26 May 2005 11:32:18 -0700 From: Stephen Hemminger To: Andy Fleming Cc: Netdev , Embedded PPC Linux list , Kumar Gala Subject: Re: RFC: PHY Abstraction Layer II Message-ID: <20050526113218.23e44164@dxpl.pdx.osdl.net> In-Reply-To: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 297 Lines: 7 I finally got around to looking at this for the new skge driver. The Marvell phy code has several issues: * hard coded hex values rather than constants * doesn't handle restricted autonegotiation * it doesn't really help the driver that much there are too many other warts in the hardware. From afleming@freescale.com Thu May 26 11:46:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:46:21 -0700 (PDT) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIkHXq001696 for ; Thu, 26 May 2005 11:46:17 -0700 Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j4QIoWoB004865; Thu, 26 May 2005 11:50:32 -0700 (MST) Received: from [192.168.1.102] ([10.214.72.124]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id j4QIkhRf002451; Thu, 26 May 2005 13:46:44 -0500 (CDT) In-Reply-To: <20050526113218.23e44164@dxpl.pdx.osdl.net> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050526113218.23e44164@dxpl.pdx.osdl.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <615E3662-7F4F-4277-A5F0-83086150F0FE@freescale.com> Cc: Netdev , Embedded PPC Linux list , Kumar Gala Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Thu, 26 May 2005 13:45:20 -0500 To: Stephen Hemminger X-Mailer: Apple Mail (2.730) X-archive-position: 1674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 1036 Lines: 32 On May 26, 2005, at 13:32, Stephen Hemminger wrote: > I finally got around to looking at this for the new skge driver. > The Marvell phy code has several issues: > * hard coded hex values rather than constants These are hard-coded because it's errata. The errata doesn't name the registers, nor the bits being set, so the best I could do is something like: phy_write(phydev, M88E1101_ERRATA_REGISTER1, M88E1101_ERRATA_REG1_VALUE1); I'm not sure that's more useful. > * doesn't handle restricted autonegotiation I'm not quite sure what you mean by this one. ALL the PHYs support restricting auto-negotiation to certain values. See drivers/net/phy/ phy_device.c:genphy_config_advert(), which is called by marvell's config_aneg function (eventually). > * it doesn't really help the driver that much there are too > many other warts in the hardware. Err... the skge hardware, or the Marvell hardware? Could you specify some warts, so I can look into what changes might need to be made? Andy From tgraf@suug.ch Thu May 26 11:53:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:53:38 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIrXXq002465 for ; Thu, 26 May 2005 11:53:36 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 439801C0EB; Thu, 26 May 2005 20:53:06 +0200 (CEST) Date: Thu, 26 May 2005 20:53:06 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCHSET] neighbour tables access via rtnetlink Message-ID: <20050526185306.GW15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 1675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 729 Lines: 18 Dave, This patchset adds neighbour table configuration and statistics access via rtnetlink. Patches 1-2 add some new macros to make netlink message construction simpler and more readable, patch 3 adds the actual neighbour table code and patch 4 removes a few unused fields discovered while writing patch 3 ;-> include/linux/netlink.h | 17 ++ include/linux/rtnetlink.h | 45 ++++++ include/net/neighbour.h | 3 include/linux/rtnetlink.h | 107 ++++++++++++++ include/net/neighbour.h | 4 net/core/neighbour.c | 317 +++++++++++++++++++++++++++++++++++++++++++- net/core/rtnetlink.c | 20 +- security/selinux/nlmsgtab.c | 2 8 files changed, 499 insertions(+), 16 deletions(-) From tgraf@suug.ch Thu May 26 11:54:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:54:34 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIsSXq002779 for ; Thu, 26 May 2005 11:54:28 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 92B9A1C0EB; Thu, 26 May 2005 20:54:02 +0200 (CEST) Date: Thu, 26 May 2005 20:54:02 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 1/4] [NETLINK] New message building macros Message-ID: <20050526185402.GX15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526185306.GW15391@postel.suug.ch> X-archive-position: 1676 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1805 Lines: 52 NLMSG_PUT_ANSWER(skb, nlcb, type, length) Start a new netlink message as answer to a request, returns the message header. NLMSG_END(skb, nlh) End a netlink message, fixes total message length, returns skb->len. NLMSG_CANCEL(skb, nlh) Cancel the building process and trim whole message from skb again, returns -1. Signed-off-by: Thomas Graf --- commit 88e04e26d887e806372014a2f7b33c6a7ea64741 tree 031c0e0d63096ca2dff2203940b90460f1db5c68 parent d1faeaeb95a05275cf0c5b51b88f2fa833434625 author Thomas Graf Thu, 26 May 2005 18:21:36 +0200 committer Thomas Graf Thu, 26 May 2005 18:21:36 +0200 include/linux/netlink.h | 17 +++++++++++++++-- 1 files changed, 15 insertions(+), 2 deletions(-) Index: include/linux/netlink.h =================================================================== --- c6f827347b3c6c28bc55a8eb1e62ea2659202cab/include/linux/netlink.h (mode:100644) +++ 031c0e0d63096ca2dff2203940b90460f1db5c68/include/linux/netlink.h (mode:100644) @@ -171,8 +171,21 @@ } #define NLMSG_PUT(skb, pid, seq, type, len) \ -({ if (skb_tailroom(skb) < (int)NLMSG_SPACE(len)) goto nlmsg_failure; \ - __nlmsg_put(skb, pid, seq, type, len); }) +({ if (skb_tailroom(skb) < (int)NLMSG_SPACE(len)) \ + goto nlmsg_failure; \ + __nlmsg_put(skb, pid, seq, type, len); }) + +#define NLMSG_PUT_ANSWER(skb, cb, type, len) \ + NLMSG_PUT(skb, NETLINK_CB((cb)->skb).pid, \ + (cb)->nlh->nlmsg_seq, type, len) + +#define NLMSG_END(skb, nlh) \ +({ (nlh)->nlmsg_len = (skb)->tail - (unsigned char *) (nlh); \ + (skb)->len; }) + +#define NLMSG_CANCEL(skb, nlh) \ +({ skb_trim(skb, (unsigned char *) (nlh) - (skb)->data); \ + -1; }) extern int netlink_dump_start(struct sock *ssk, struct sk_buff *skb, struct nlmsghdr *nlh, From mchan@broadcom.com Thu May 26 11:55:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:55:11 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIt2Xq003229 for ; Thu, 26 May 2005 11:55:04 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:53:40 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:54:01 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO56199; Thu, 26 May 2005 11:54:01 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA26901; Thu, 26 May 2005 11:54:01 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:54:00 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 10:56:24 -0700 Subject: [PATCH 2.6.12-rc5 1/9] tg3: Add basic selftest infrastructure From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1117128795.3744.22.camel@rh4> References: <1117128795.3744.22.camel@rh4> Date: Thu, 26 May 2005 10:56:24 -0700 Message-ID: <1117130184.3744.52.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88C4BE2V42018487-01-01 Content-Type: multipart/mixed; boundary="=-/CRopC1JEawlr+QW2P2U" X-archive-position: 1677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 3192 Lines: 56 --=-/CRopC1JEawlr+QW2P2U Content-Type: text/plain Content-Transfer-Encoding: 7bit Signed-off-by: Michael Chan --=-/CRopC1JEawlr+QW2P2U Content-Disposition: attachment; filename=tg3-d1.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-d1.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGQwL2RyaXZlcnMvbmV0L3RnMy5jIGQxL2RyaXZlcnMvbmV0L3RnMy5jDQotLS0g ZDAvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yNSAxMjo1NzozNi4wMDAwMDAwMDAgLTA3MDAN CisrKyBkMS9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTA1LTI1IDEyOjU4OjUwLjAwMDAwMDAwMCAt MDcwMA0KQEAgLTEzMyw2ICsxMzMsOCBAQA0KIC8qIG51bWJlciBvZiBFVEhUT09MX0dTVEFUUyB1 NjQncyAqLw0KICNkZWZpbmUgVEczX05VTV9TVEFUUwkJKHNpemVvZihzdHJ1Y3QgdGczX2V0aHRv b2xfc3RhdHMpL3NpemVvZih1NjQpKQ0KIA0KKyNkZWZpbmUgVEczX05VTV9URVNUCQk2DQorDQog c3RhdGljIGNoYXIgdmVyc2lvbltdIF9fZGV2aW5pdGRhdGEgPQ0KIAlEUlZfTU9EVUxFX05BTUUg Ii5jOnYiIERSVl9NT0RVTEVfVkVSU0lPTiAiICgiIERSVl9NT0RVTEVfUkVMREFURSAiKVxuIjsN CiANCkBAIC0zMTYsNiArMzE4LDE3IEBADQogCXsgIm5pY190eF90aHJlc2hvbGRfaGl0IiB9DQog fTsNCiANCitzdGF0aWMgc3RydWN0IHsNCisJY29uc3QgY2hhciBzdHJpbmdbRVRIX0dTVFJJTkdf TEVOXTsNCit9IGV0aHRvb2xfdGVzdF9rZXlzW1RHM19OVU1fVEVTVF0gPSB7DQorCXsgIm52cmFt IHRlc3QgICAgIChvbmxpbmUpICIgfSwNCisJeyAibGluayB0ZXN0ICAgICAgKG9ubGluZSkgIiB9 LA0KKwl7ICJyZWdpc3RlciB0ZXN0ICAob2ZmbGluZSkiIH0sDQorCXsgIm1lbW9yeSB0ZXN0ICAg IChvZmZsaW5lKSIgfSwNCisJeyAibG9vcGJhY2sgdGVzdCAgKG9mZmxpbmUpIiB9LA0KKwl7ICJp bnRlcnJ1cHQgdGVzdCAob2ZmbGluZSkiIH0sDQorfTsNCisNCiBzdGF0aWMgdm9pZCB0ZzNfd3Jp dGVfaW5kaXJlY3RfcmVnMzIoc3RydWN0IHRnMyAqdHAsIHUzMiBvZmYsIHUzMiB2YWwpDQogew0K IAlpZiAoKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxBR19QQ0lYX1RBUkdFVF9IV0JVRykgIT0gMCkg ew0KQEAgLTcxOTksMTIgKzcyMTIsMjAgQEANCiAJcmV0dXJuIFRHM19OVU1fU1RBVFM7DQogfQ0K IA0KK3N0YXRpYyBpbnQgdGczX2dldF90ZXN0X2NvdW50IChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 KQ0KK3sNCisJcmV0dXJuIFRHM19OVU1fVEVTVDsNCit9DQorDQogc3RhdGljIHZvaWQgdGczX2dl dF9zdHJpbmdzIChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCB1MzIgc3RyaW5nc2V0LCB1OCAqYnVm KQ0KIHsNCiAJc3dpdGNoIChzdHJpbmdzZXQpIHsNCiAJY2FzZSBFVEhfU1NfU1RBVFM6DQogCQlt ZW1jcHkoYnVmLCAmZXRodG9vbF9zdGF0c19rZXlzLCBzaXplb2YoZXRodG9vbF9zdGF0c19rZXlz KSk7DQogCQlicmVhazsNCisJY2FzZSBFVEhfU1NfVEVTVDoNCisJCW1lbWNweShidWYsICZldGh0 b29sX3Rlc3Rfa2V5cywgc2l6ZW9mKGV0aHRvb2xfdGVzdF9rZXlzKSk7DQorCQlicmVhazsNCiAJ ZGVmYXVsdDoNCiAJCVdBUk5fT04oMSk7CS8qIHdlIG5lZWQgYSBXQVJOKCkgKi8NCiAJCWJyZWFr Ow0KQEAgLTcyMTgsNiArNzIzOSwxMSBAQA0KIAltZW1jcHkodG1wX3N0YXRzLCB0ZzNfZ2V0X2Vz dGF0cyh0cCksIHNpemVvZih0cC0+ZXN0YXRzKSk7DQogfQ0KIA0KK3N0YXRpYyB2b2lkIHRnM19z ZWxmX3Rlc3Qoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGV0aHRvb2xfdGVzdCAqZXRl c3QsDQorCQkJICB1NjQgKmRhdGEpDQorew0KK30NCisNCiBzdGF0aWMgaW50IHRnM19pb2N0bChz dHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgaWZyZXEgKmlmciwgaW50IGNtZCkNCiB7DQog CXN0cnVjdCBtaWlfaW9jdGxfZGF0YSAqZGF0YSA9IGlmX21paShpZnIpOw0KQEAgLTczMzEsNiAr NzM1Nyw4IEBADQogCS5nZXRfdHNvCQk9IGV0aHRvb2xfb3BfZ2V0X3RzbywNCiAJLnNldF90c28J CT0gdGczX3NldF90c28sDQogI2VuZGlmDQorCS5zZWxmX3Rlc3RfY291bnQJPSB0ZzNfZ2V0X3Rl c3RfY291bnQsDQorCS5zZWxmX3Rlc3QJCT0gdGczX3NlbGZfdGVzdCwNCiAJLmdldF9zdHJpbmdz CQk9IHRnM19nZXRfc3RyaW5ncywNCiAJLmdldF9zdGF0c19jb3VudAk9IHRnM19nZXRfc3RhdHNf Y291bnQsDQogCS5nZXRfZXRodG9vbF9zdGF0cwk9IHRnM19nZXRfZXRodG9vbF9zdGF0cywNCg== --=-/CRopC1JEawlr+QW2P2U-- From tgraf@suug.ch Thu May 26 11:55:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:55:20 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QItFXq003322 for ; Thu, 26 May 2005 11:55:16 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id BFC1A1C0EB; Thu, 26 May 2005 20:54:49 +0200 (CEST) Date: Thu, 26 May 2005 20:54:49 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2/4] [RTNETLINK] Routing attribute related shortcuts Message-ID: <20050526185449.GY15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526185306.GW15391@postel.suug.ch> X-archive-position: 1678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3236 Lines: 96 RTA_GET_U(32|64)(tlv) Assumes TLV is a u32/u64 field and returns its value. RTA_GET_[M]SECS(tlv) Assumes TLV is a u64 and transports jiffies converted to seconds or milliseconds and returns its value. RTA_PUT_U(32|64)(skb, type, value) Appends %value as fixed u32/u64 to %skb as TLV %type. RTA_PUT_[M]SECS(skb, type, jiffies) Converts %jiffies to secs/msecs and appends it as u64 to %skb as TLV %type. RTA_PUT_STRING(skb, type, string) Appends %NUL terminated %string to %skb as TLV %type. RTA_NEST(skb, type) Starts a nested TLV %type and returns the nesting handle. RTA_NEST_END(skb, nesting_handle) Finishes the nested TLV %nesting_handle, must be called symmetric to RTA_NEST(). Returns skb->len RTA_NEST_CANCEL(skb, nesting_handle) Cancel the nested TLV %nesting_handle and trim nested TLV from skb again, returns -1. Signed-off-by: Thomas Graf --- commit d24c37db15b6cd790459d9d91ee6331ce17264b4 tree 52e7990f6dee710624f823014c40c14e0e5ccf39 parent 88e04e26d887e806372014a2f7b33c6a7ea64741 author Thomas Graf Thu, 26 May 2005 18:22:23 +0200 committer Thomas Graf Thu, 26 May 2005 18:22:23 +0200 include/linux/rtnetlink.h | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 45 insertions(+) Index: include/linux/rtnetlink.h =================================================================== --- 031c0e0d63096ca2dff2203940b90460f1db5c68/include/linux/rtnetlink.h (mode:100644) +++ 52e7990f6dee710624f823014c40c14e0e5ccf39/include/linux/rtnetlink.h (mode:100644) @@ -789,6 +789,51 @@ ({ if (unlikely(skb_tailroom(skb) < (int)(attrlen))) \ goto rtattr_failure; \ memcpy(skb_put(skb, RTA_ALIGN(attrlen)), data, attrlen); }) + +#define RTA_PUT_U32(skb, attrtype, value) \ +({ u32 _tmp = (value); \ + RTA_PUT(skb, attrtype, sizeof(u32), &_tmp); }) + +#define RTA_PUT_U64(skb, attrtype, value) \ +({ u64 _tmp = (value); \ + RTA_PUT(skb, attrtype, sizeof(u64), &_tmp); }) + +#define RTA_PUT_SECS(skb, attrtype, value) \ + RTA_PUT_U64(skb, attrtype, (value) / HZ) + +#define RTA_PUT_MSECS(skb, attrtype, value) \ + RTA_PUT_U64(skb, attrtype, jiffies_to_msecs(value)) + +#define RTA_PUT_STRING(skb, attrtype, value) \ + RTA_PUT(skb, attrtype, strlen(value) + 1, value) + +#define RTA_NEST(skb, type) \ +({ struct rtattr *__start = (struct rtattr *) (skb)->tail; \ + RTA_PUT(skb, type, 0, NULL); \ + __start; }) + +#define RTA_NEST_END(skb, start) \ +({ (start)->rta_len = ((skb)->tail - (unsigned char *) (start)); \ + (skb)->len; }) + +#define RTA_NEST_CANCEL(skb, start) \ +({ skb_trim(skb, (unsigned char *) (start) - (skb)->data); \ + -1; }) + +#define RTA_GET_U32(rta) \ +({ if (!rta || RTA_PAYLOAD(rta) < sizeof(u32)) \ + goto rtattr_failure; \ + *(u32 *) RTA_DATA(rta); }) + +#define RTA_GET_U64(rta) \ +({ u64 _tmp; \ + if (!rta || RTA_PAYLOAD(rta) < sizeof(u64)) \ + goto rtattr_failure; \ + memcpy(&_tmp, RTA_DATA(rta), sizeof(_tmp)); \ + _tmp; }) + +#define RTA_GET_SECS(rta) ((unsigned long) RTA_GET_U64(rta) * HZ) +#define RTA_GET_MSECS(rta) (msecs_to_jiffies((unsigned long) RTA_GET_U64(rta))) static inline struct rtattr * __rta_reserve(struct sk_buff *skb, int attrtype, int attrlen) From mchan@broadcom.com Thu May 26 11:55:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:55:46 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QItgXq003726 for ; Thu, 26 May 2005 11:55:42 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:54:21 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:54:41 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO56354; Thu, 26 May 2005 11:54:41 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA27068; Thu, 26 May 2005 11:54:40 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:54:40 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 10:57:04 -0700 Subject: [PATCH 2.6.12-rc5 2/9] tg3: Add nvram test From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1117128795.3744.22.camel@rh4> References: <1117128795.3744.22.camel@rh4> Date: Thu, 26 May 2005 10:57:04 -0700 Message-ID: <1117130224.3744.53.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88C4D72V42018628-01-01 Content-Type: multipart/mixed; boundary="=-/GEGHaZ60nGmeZ+vyahE" X-archive-position: 1679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 2439 Lines: 47 --=-/GEGHaZ60nGmeZ+vyahE Content-Type: text/plain Content-Transfer-Encoding: 7bit Signed-off-by: Michael Chan --=-/GEGHaZ60nGmeZ+vyahE Content-Disposition: attachment; filename=tg3-d2.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-d2.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGQxL2RyaXZlcnMvbmV0L3RnMy5jIGQyL2RyaXZlcnMvbmV0L3RnMy5jDQotLS0g ZDEvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yNSAxMjo1ODo1MC4wMDAwMDAwMDAgLTA3MDAN CisrKyBkMi9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTA1LTI1IDEyOjU5OjAwLjAwMDAwMDAwMCAt MDcwMA0KQEAgLTcyMzksOSArNzIzOSw1OSBAQA0KIAltZW1jcHkodG1wX3N0YXRzLCB0ZzNfZ2V0 X2VzdGF0cyh0cCksIHNpemVvZih0cC0+ZXN0YXRzKSk7DQogfQ0KIA0KKyNkZWZpbmUgTlZSQU1f VEVTVF9TSVpFIDB4MTAwDQorDQorc3RhdGljIGludCB0ZzNfdGVzdF9udnJhbShzdHJ1Y3QgdGcz ICp0cCkNCit7DQorCXUzMiAqYnVmLCBjc3VtOw0KKwlpbnQgaSwgaiwgZXJyID0gMDsNCisNCisJ YnVmID0ga21hbGxvYyhOVlJBTV9URVNUX1NJWkUsIEdGUF9LRVJORUwpOw0KKwlpZiAoYnVmID09 IE5VTEwpDQorCQlyZXR1cm4gLUVOT01FTTsNCisNCisJZm9yIChpID0gMCwgaiA9IDA7IGkgPCBO VlJBTV9URVNUX1NJWkU7IGkgKz0gNCwgaisrKSB7DQorCQl1MzIgdmFsOw0KKw0KKwkJaWYgKChl cnIgPSB0ZzNfbnZyYW1fcmVhZCh0cCwgaSwgJnZhbCkpICE9IDApDQorCQkJYnJlYWs7DQorCQli dWZbal0gPSBjcHVfdG9fbGUzMih2YWwpOw0KKwl9DQorCWlmIChpIDwgTlZSQU1fVEVTVF9TSVpF KQ0KKwkJZ290byBvdXQ7DQorDQorCWVyciA9IC1FSU87DQorCWlmIChjcHVfdG9fYmUzMihidWZb MF0pICE9IFRHM19FRVBST01fTUFHSUMpDQorCQlnb3RvIG91dDsNCisNCisJLyogQm9vdHN0cmFw IGNoZWNrc3VtIGF0IG9mZnNldCAweDEwICovDQorCWNzdW0gPSBjYWxjX2NyYygodW5zaWduZWQg Y2hhciAqKSBidWYsIDB4MTApOw0KKwlpZihjc3VtICE9IGNwdV90b19sZTMyKGJ1ZlsweDEwLzRd KSkNCisJCWdvdG8gb3V0Ow0KKw0KKwkvKiBNYW51ZmFjdHVyaW5nIGJsb2NrIHN0YXJ0cyBhdCBv ZmZzZXQgMHg3NCwgY2hlY2tzdW0gYXQgMHhmYyAqLw0KKwljc3VtID0gY2FsY19jcmMoKHVuc2ln bmVkIGNoYXIgKikgJmJ1ZlsweDc0LzRdLCAweDg4KTsNCisJaWYgKGNzdW0gIT0gY3B1X3RvX2xl MzIoYnVmWzB4ZmMvNF0pKQ0KKwkJIGdvdG8gb3V0Ow0KKw0KKwllcnIgPSAwOw0KKw0KK291dDoN CisJa2ZyZWUoYnVmKTsNCisJcmV0dXJuIGVycjsNCit9DQorDQogc3RhdGljIHZvaWQgdGczX3Nl bGZfdGVzdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgZXRodG9vbF90ZXN0ICpldGVz dCwNCiAJCQkgIHU2NCAqZGF0YSkNCiB7DQorCXN0cnVjdCB0ZzMgKnRwID0gbmV0ZGV2X3ByaXYo ZGV2KTsNCisNCisJbWVtc2V0KGRhdGEsIDAsIHNpemVvZih1NjQpICogVEczX05VTV9URVNUKTsN CisNCisJaWYgKHRnM190ZXN0X252cmFtKHRwKSAhPSAwKSB7DQorCQlldGVzdC0+ZmxhZ3MgfD0g RVRIX1RFU1RfRkxfRkFJTEVEOw0KKwkJZGF0YVswXSA9IDE7DQorCX0NCiB9DQogDQogc3RhdGlj IGludCB0ZzNfaW9jdGwoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlmcmVxICppZnIs IGludCBjbWQpDQo= --=-/GEGHaZ60nGmeZ+vyahE-- From tgraf@suug.ch Thu May 26 11:55:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:55:59 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QItqXq004046 for ; Thu, 26 May 2005 11:55:53 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id D22841C0EB; Thu, 26 May 2005 20:55:26 +0200 (CEST) Date: Thu, 26 May 2005 20:55:26 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050526185526.GZ15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526185306.GW15391@postel.suug.ch> X-archive-position: 1680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 19007 Lines: 591 To retrieve the neighbour tables send RTM_GETNEIGHTBL with the NLM_F_DUMP flag set. Every neighbour table configuration is spread over multiple messages to avoid running into message size limits on systems with many interfaces. The first message in the sequence transports all not device specific data such as statistics, configuration, and the default parameter set. This message is followed by 0..n messages carrying device specific parameter sets. They all share the same value for Although the ordering should be sufficient, NDTA_NAME can be used to identify sequences. The initial message can be identified by checking for NDTA_CONFIG. The device specific messages do no contain this TLV but have NDTPA_IFINDEX set to the corresponding interface index. To change neighbour table attributes, send RTM_SETNEIGHTBL with NDTA_NAME set. Changeable attribute include NDTA_THRESH[1-3], NDTA_GC_INTERVAL, and all TLVs in NDTA_PARMS unless marked otherwise. Device specific parameter sets can be changed by setting NDTPA_IFINDEX to the interface index of the corresponding device. Signed-off-by: Thomas Graf --- commit 6769b3b0603c632bda062e427178de8986900a52 tree 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b parent 98c3bc2e6320127cd96ef46d33f89ae127ce48fe author Thomas Graf Wed, 25 May 2005 20:30:09 +0200 committer Thomas Graf Wed, 25 May 2005 20:30:09 +0200 include/linux/rtnetlink.h | 107 ++++++++++++++ include/net/neighbour.h | 4 net/core/neighbour.c | 317 +++++++++++++++++++++++++++++++++++++++++++- net/core/rtnetlink.c | 20 +- security/selinux/nlmsgtab.c | 2 5 files changed, 439 insertions(+), 11 deletions(-) Index: include/linux/rtnetlink.h =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/include/linux/rtnetlink.h (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/include/linux/rtnetlink.h (mode:100644) @@ -89,6 +89,13 @@ RTM_GETANYCAST = 62, #define RTM_GETANYCAST RTM_GETANYCAST + RTM_NEWNEIGHTBL = 64, +#define RTM_NEWNEIGHTBL RTM_NEWNEIGHTBL + RTM_GETNEIGHTBL = 66, +#define RTM_GETNEIGHTBL RTM_GETNEIGHTBL + RTM_SETNEIGHTBL, +#define RTM_SETNEIGHTBL RTM_SETNEIGHTBL + __RTM_MAX, #define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1) }; @@ -493,6 +500,106 @@ __u32 ndm_refcnt; }; + +/***************************************************************** + * Neighbour tables specific messages. + * + * To retrieve the neighbour tables send RTM_GETNEIGHTBL with the + * NLM_F_DUMP flag set. Every neighbour table configuration is + * spread over multiple messages to avoid running into message + * size limits on systems with many interfaces. The first message + * in the sequence transports all not device specific data such as + * statistics, configuration, and the default parameter set. + * This message is followed by 0..n messages carrying device + * specific parameter sets. They all share the same value for + * Although the ordering should be sufficient, NDTA_NAME can be + * used to identify sequences. The initial message can be identified + * by checking for NDTA_CONFIG. The device specific messages do + * no contain this TLV but have NDTPA_IFINDEX set to the + * corresponding interface index. + * + * To change neighbour table attributes, send RTM_SETNEIGHTBL + * with NDTA_NAME set. Changeable attribute include NDTA_THRESH[1-3], + * NDTA_GC_INTERVAL, and all TLVs in NDTA_PARMS unless marked + * otherwise. Device specific parameter sets can be changed by + * setting NDTPA_IFINDEX to the interface index of the corresponding + * device. + ****/ + +struct ndt_stats +{ + __u64 ndts_allocs; + __u64 ndts_destroys; + __u64 ndts_hash_grows; + __u64 ndts_res_failed; + __u64 ndts_lookups; + __u64 ndts_hits; + __u64 ndts_rcv_probes_mcast; + __u64 ndts_rcv_probes_ucast; + __u64 ndts_periodic_gc_runs; + __u64 ndts_forced_gc_runs; +}; + +enum { + NDTPA_UNSPEC, + NDTPA_IFINDEX, /* u32, unchangeable */ + NDTPA_REFCNT, /* u32, read-only */ + NDTPA_REACHABLE_TIME, /* u64, read-only, msecs */ + NDTPA_BASE_REACHABLE_TIME, /* u64, msecs */ + NDTPA_RETRANS_TIME, /* u64, msecs */ + NDTPA_GC_STALETIME, /* u64, msecs */ + NDTPA_DELAY_PROBE_TIME, /* u64, msecs */ + NDTPA_QUEUE_LEN, /* u32 */ + NDTPA_APP_PROBES, /* u32 */ + NDTPA_UCAST_PROBES, /* u32 */ + NDTPA_MCAST_PROBES, /* u32 */ + NDTPA_ANYCAST_DELAY, /* u64, msecs */ + NDTPA_PROXY_DELAY, /* u64, msecs */ + NDTPA_PROXY_QLEN, /* u32 */ + NDTPA_LOCKTIME, /* u64, msecs */ + __NDTPA_MAX +}; +#define NDTPA_MAX (__NDTPA_MAX - 1) + +struct ndtmsg +{ + __u8 ndtm_family; + __u8 ndtm_pad1; + __u16 ndtm_pad2; +}; + +struct ndt_config +{ + __u16 ndtc_key_len; + __u16 ndtc_entry_size; + __u32 ndtc_entries; + __u32 ndtc_last_flush; /* delta to now in msecs */ + __u32 ndtc_last_rand; /* delta to now in msecs */ + __u32 ndtc_hash_rnd; + __u32 ndtc_hash_mask; + __u32 ndtc_hash_chain_gc; + __u32 ndtc_proxy_qlen; +}; + +enum { + NDTA_UNSPEC, + NDTA_NAME, /* char *, unchangeable */ + NDTA_THRESH1, /* u32 */ + NDTA_THRESH2, /* u32 */ + NDTA_THRESH3, /* u32 */ + NDTA_CONFIG, /* struct ndt_config, read-only */ + NDTA_PARMS, /* nested TLV NDTPA_* */ + NDTA_STATS, /* struct ndt_stats, read-only */ + NDTA_GC_INTERVAL, /* u64, msecs */ + __NDTA_MAX +}; +#define NDTA_MAX (__NDTA_MAX - 1) + +#define NDTA_RTA(r) ((struct rtattr*)(((char*)(r)) + \ + NLMSG_ALIGN(sizeof(struct ndtmsg)))) +#define NDTA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ndtmsg)) + + /**** * General form of address family dependent message. ****/ Index: include/net/neighbour.h =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/include/net/neighbour.h (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/include/net/neighbour.h (mode:100644) @@ -65,6 +65,7 @@ struct neigh_parms { + struct net_device *dev; struct neigh_parms *next; int (*neigh_setup)(struct neighbour *); struct neigh_table *tbl; @@ -252,6 +253,9 @@ extern int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); extern void neigh_app_ns(struct neighbour *n); +extern int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb); +extern int neightbl_set(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); + extern void neigh_for_each(struct neigh_table *tbl, void (*cb)(struct neighbour *, void *), void *cookie); extern void __neigh_for_each_release(struct neigh_table *tbl, int (*cb)(struct neighbour *)); extern void pneigh_for_each(struct neigh_table *tbl, void (*cb)(struct pneigh_entry *)); Index: net/core/neighbour.c =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/net/core/neighbour.c (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/net/core/neighbour.c (mode:100644) @@ -1276,9 +1276,14 @@ INIT_RCU_HEAD(&p->rcu_head); p->reachable_time = neigh_rand_reach_time(p->base_reachable_time); - if (dev && dev->neigh_setup && dev->neigh_setup(dev, p)) { - kfree(p); - return NULL; + if (dev) { + if (dev->neigh_setup && dev->neigh_setup(dev, p)) { + kfree(p); + return NULL; + } + + dev_hold(dev); + p->dev = dev; } p->sysctl_table = NULL; write_lock_bh(&tbl->lock); @@ -1309,6 +1314,8 @@ *p = parms->next; parms->dead = 1; write_unlock_bh(&tbl->lock); + if (parms->dev) + dev_put(parms->dev); call_rcu(&parms->rcu_head, neigh_rcu_free_parms); return; } @@ -1546,6 +1553,308 @@ return err; } +static int neightbl_fill_parms(struct sk_buff *skb, struct neigh_parms *parms) +{ + struct rtattr *nest = RTA_NEST(skb, NDTA_PARMS); + + if (parms->dev) + RTA_PUT_U32(skb, NDTPA_IFINDEX, parms->dev->ifindex); + + RTA_PUT_U32(skb, NDTPA_REFCNT, atomic_read(&parms->refcnt)); + RTA_PUT_U32(skb, NDTPA_QUEUE_LEN, parms->queue_len); + RTA_PUT_U32(skb, NDTPA_PROXY_QLEN, parms->proxy_qlen); + RTA_PUT_U32(skb, NDTPA_APP_PROBES, parms->app_probes); + RTA_PUT_U32(skb, NDTPA_UCAST_PROBES, parms->ucast_probes); + RTA_PUT_U32(skb, NDTPA_MCAST_PROBES, parms->mcast_probes); + RTA_PUT_MSECS(skb, NDTPA_REACHABLE_TIME, parms->reachable_time); + RTA_PUT_MSECS(skb, NDTPA_BASE_REACHABLE_TIME, + parms->base_reachable_time); + RTA_PUT_MSECS(skb, NDTPA_GC_STALETIME, parms->gc_staletime); + RTA_PUT_MSECS(skb, NDTPA_DELAY_PROBE_TIME, parms->delay_probe_time); + RTA_PUT_MSECS(skb, NDTPA_RETRANS_TIME, parms->retrans_time); + RTA_PUT_MSECS(skb, NDTPA_ANYCAST_DELAY, parms->anycast_delay); + RTA_PUT_MSECS(skb, NDTPA_PROXY_DELAY, parms->proxy_delay); + RTA_PUT_MSECS(skb, NDTPA_LOCKTIME, parms->locktime); + + return RTA_NEST_END(skb, nest); + +rtattr_failure: + return RTA_NEST_CANCEL(skb, nest); +} + +static int neightbl_fill_info(struct neigh_table *tbl, struct sk_buff *skb, + struct netlink_callback *cb) +{ + struct nlmsghdr *nlh; + struct ndtmsg *ndtmsg; + + nlh = NLMSG_PUT_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg)); + ndtmsg = NLMSG_DATA(nlh); + + NLMSG_SET_MULTIPART(nlh); + + read_lock_bh(&tbl->lock); + ndtmsg->ndtm_family = tbl->family; + + RTA_PUT_STRING(skb, NDTA_NAME, tbl->id); + RTA_PUT_MSECS(skb, NDTA_GC_INTERVAL, tbl->gc_interval); + RTA_PUT_U32(skb, NDTA_THRESH1, tbl->gc_thresh1); + RTA_PUT_U32(skb, NDTA_THRESH2, tbl->gc_thresh2); + RTA_PUT_U32(skb, NDTA_THRESH3, tbl->gc_thresh3); + + { + unsigned long now = jiffies; + unsigned int flush_delta = now - tbl->last_flush; + unsigned int rand_delta = now - tbl->last_rand; + + struct ndt_config ndc = { + .ndtc_key_len = tbl->key_len, + .ndtc_entry_size = tbl->entry_size, + .ndtc_entries = atomic_read(&tbl->entries), + .ndtc_last_flush = jiffies_to_msecs(flush_delta), + .ndtc_last_rand = jiffies_to_msecs(rand_delta), + .ndtc_hash_rnd = tbl->hash_rnd, + .ndtc_hash_mask = tbl->hash_mask, + .ndtc_hash_chain_gc = tbl->hash_chain_gc, + .ndtc_proxy_qlen = tbl->proxy_queue.qlen, + }; + + RTA_PUT(skb, NDTA_CONFIG, sizeof(ndc), &ndc); + } + + { + int cpu; + struct ndt_stats ndst; + + memset(&ndst, 0, sizeof(ndst)); + + for (cpu = 0; cpu < NR_CPUS; cpu++) { + struct neigh_statistics *st; + + if (!cpu_possible(cpu)) + continue; + + st = per_cpu_ptr(tbl->stats, cpu); + ndst.ndts_allocs += st->allocs; + ndst.ndts_destroys += st->destroys; + ndst.ndts_hash_grows += st->hash_grows; + ndst.ndts_res_failed += st->res_failed; + ndst.ndts_lookups += st->lookups; + ndst.ndts_hits += st->hits; + ndst.ndts_rcv_probes_mcast += st->rcv_probes_mcast; + ndst.ndts_rcv_probes_ucast += st->rcv_probes_ucast; + ndst.ndts_periodic_gc_runs += st->periodic_gc_runs; + ndst.ndts_forced_gc_runs += st->forced_gc_runs; + } + + RTA_PUT(skb, NDTA_STATS, sizeof(ndst), &ndst); + } + + BUG_ON(tbl->parms.dev); + if (neightbl_fill_parms(skb, &tbl->parms) < 0) + goto rtattr_failure; + + read_unlock_bh(&tbl->lock); + return NLMSG_END(skb, nlh); + +rtattr_failure: + read_unlock_bh(&tbl->lock); + return NLMSG_CANCEL(skb, nlh); + +nlmsg_failure: + return -1; +} + +static int neightbl_fill_param_info(struct neigh_table *tbl, + struct neigh_parms *parms, + struct sk_buff *skb, + struct netlink_callback *cb) +{ + struct ndtmsg *ndtmsg; + struct nlmsghdr *nlh; + + nlh = NLMSG_PUT_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg)); + ndtmsg = NLMSG_DATA(nlh); + + NLMSG_SET_MULTIPART(nlh); + + read_lock_bh(&tbl->lock); + ndtmsg->ndtm_family = tbl->family; + RTA_PUT_STRING(skb, NDTA_NAME, tbl->id); + + if (neightbl_fill_parms(skb, parms) < 0) + goto rtattr_failure; + + read_unlock_bh(&tbl->lock); + return NLMSG_END(skb, nlh); + +rtattr_failure: + read_unlock_bh(&tbl->lock); + return NLMSG_CANCEL(skb, nlh); + +nlmsg_failure: + return -1; +} + +static inline struct neigh_parms *lookup_neigh_params(struct neigh_table *tbl, + int ifindex) +{ + struct neigh_parms *p; + + for (p = &tbl->parms; p; p = p->next) + if ((p->dev && p->dev->ifindex == ifindex) || + (!p->dev && !ifindex)) + return p; + + return NULL; +} + +int neightbl_set(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg) +{ + struct neigh_table *tbl; + struct ndtmsg *ndtmsg = NLMSG_DATA(nlh); + struct rtattr **tb = arg; + int err = -EINVAL; + + if (!tb[NDTA_NAME - 1] || !RTA_PAYLOAD(tb[NDTA_NAME - 1])) + return -EINVAL; + + read_lock(&neigh_tbl_lock); + for (tbl = neigh_tables; tbl; tbl = tbl->next) { + if (ndtmsg->ndtm_family && tbl->family != ndtmsg->ndtm_family) + continue; + + if (!rtattr_strcmp(tb[NDTA_NAME - 1], tbl->id)) + break; + } + + if (tbl == NULL) { + err = -ENOENT; + goto errout; + } + + /* + * We acquire tbl->lock to be nice to the periodic timers and + * make sure they always see a consistent set of values. + */ + write_lock_bh(&tbl->lock); + + if (tb[NDTA_THRESH1 - 1]) + tbl->gc_thresh1 = RTA_GET_U32(tb[NDTA_THRESH1 - 1]); + + if (tb[NDTA_THRESH2 - 1]) + tbl->gc_thresh2 = RTA_GET_U32(tb[NDTA_THRESH2 - 1]); + + if (tb[NDTA_THRESH3 - 1]) + tbl->gc_thresh3 = RTA_GET_U32(tb[NDTA_THRESH3 - 1]); + + if (tb[NDTA_GC_INTERVAL - 1]) + tbl->gc_interval = RTA_GET_MSECS(tb[NDTA_GC_INTERVAL - 1]); + + if (tb[NDTA_PARMS - 1]) { + struct rtattr *tbp[NDTPA_MAX]; + struct neigh_parms *p; + u32 ifindex = 0; + + if (rtattr_parse_nested(tbp, NDTPA_MAX, tb[NDTA_PARMS - 1]) < 0) + goto rtattr_failure; + + if (tbp[NDTPA_IFINDEX - 1]) + ifindex = RTA_GET_U32(tbp[NDTPA_IFINDEX - 1]); + + p = lookup_neigh_params(tbl, ifindex); + if (p == NULL) { + err = -ENOENT; + goto rtattr_failure; + } + + if (tbp[NDTPA_QUEUE_LEN - 1]) + p->queue_len = RTA_GET_U32(tbp[NDTPA_QUEUE_LEN - 1]); + + if (tbp[NDTPA_PROXY_QLEN - 1]) + p->proxy_qlen = RTA_GET_U32(tbp[NDTPA_PROXY_QLEN - 1]); + + if (tbp[NDTPA_APP_PROBES - 1]) + p->app_probes = RTA_GET_U32(tbp[NDTPA_APP_PROBES - 1]); + + if (tbp[NDTPA_UCAST_PROBES - 1]) + p->ucast_probes = + RTA_GET_U32(tbp[NDTPA_UCAST_PROBES - 1]); + + if (tbp[NDTPA_MCAST_PROBES - 1]) + p->mcast_probes = + RTA_GET_U32(tbp[NDTPA_MCAST_PROBES - 1]); + + if (tbp[NDTPA_BASE_REACHABLE_TIME - 1]) + p->base_reachable_time = + RTA_GET_MSECS(tbp[NDTPA_BASE_REACHABLE_TIME - 1]); + + if (tbp[NDTPA_GC_STALETIME - 1]) + p->gc_staletime = + RTA_GET_MSECS(tbp[NDTPA_GC_STALETIME - 1]); + + if (tbp[NDTPA_DELAY_PROBE_TIME - 1]) + p->delay_probe_time = + RTA_GET_MSECS(tbp[NDTPA_DELAY_PROBE_TIME - 1]); + + if (tbp[NDTPA_RETRANS_TIME - 1]) + p->retrans_time = + RTA_GET_MSECS(tbp[NDTPA_RETRANS_TIME - 1]); + + if (tbp[NDTPA_ANYCAST_DELAY - 1]) + p->anycast_delay = + RTA_GET_MSECS(tbp[NDTPA_ANYCAST_DELAY - 1]); + + if (tbp[NDTPA_PROXY_DELAY - 1]) + p->proxy_delay = + RTA_GET_MSECS(tbp[NDTPA_PROXY_DELAY - 1]); + + if (tbp[NDTPA_LOCKTIME - 1]) + p->locktime = RTA_GET_MSECS(tbp[NDTPA_LOCKTIME - 1]); + } + + err = 0; + +rtattr_failure: + write_unlock_bh(&tbl->lock); +errout: + read_unlock(&neigh_tbl_lock); + return err; +} + +int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb) +{ + int idx, family; + int s_idx = cb->args[0]; + struct neigh_table *tbl; + + family = ((struct rtgenmsg *)NLMSG_DATA(cb->nlh))->rtgen_family; + + read_lock(&neigh_tbl_lock); + for (tbl = neigh_tables, idx = 0; tbl; tbl = tbl->next) { + struct neigh_parms *p; + + if (idx < s_idx || (family && tbl->family != family)) + continue; + + if (neightbl_fill_info(tbl, skb, cb) <= 0) + break; + + for (++idx, p = tbl->parms.next; p; p = p->next, idx++) { + if (idx < s_idx) + continue; + + if (neightbl_fill_param_info(tbl, p, skb, cb) <= 0) + goto out; + } + + } +out: + read_unlock(&neigh_tbl_lock); + cb->args[0] = idx; + + return skb->len; +} static int neigh_fill_info(struct sk_buff *skb, struct neighbour *n, u32 pid, u32 seq, int event) @@ -2352,6 +2661,8 @@ EXPORT_SYMBOL(neigh_update_hhs); EXPORT_SYMBOL(pneigh_enqueue); EXPORT_SYMBOL(pneigh_lookup); +EXPORT_SYMBOL(neightbl_dump_info); +EXPORT_SYMBOL(neightbl_set); #ifdef CONFIG_ARPD EXPORT_SYMBOL(neigh_app_ns); Index: net/core/rtnetlink.c =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/net/core/rtnetlink.c (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/net/core/rtnetlink.c (mode:100644) @@ -100,6 +100,7 @@ [RTM_FAM(RTM_NEWPREFIX)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)), [RTM_FAM(RTM_GETMULTICAST)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)), [RTM_FAM(RTM_GETANYCAST)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)), + [RTM_FAM(RTM_NEWNEIGHTBL)] = NLMSG_LENGTH(sizeof(struct ndtmsg)), }; static const int rta_max[RTM_NR_FAMILIES] = @@ -113,6 +114,7 @@ [RTM_FAM(RTM_NEWTCLASS)] = TCA_MAX, [RTM_FAM(RTM_NEWTFILTER)] = TCA_MAX, [RTM_FAM(RTM_NEWACTION)] = TCAA_MAX, + [RTM_FAM(RTM_NEWNEIGHTBL)] = NDTA_MAX, }; void __rta_fill(struct sk_buff *skb, int attrtype, int attrlen, const void *data) @@ -649,14 +651,16 @@ static struct rtnetlink_link link_rtnetlink_table[RTM_NR_MSGTYPES] = { - [RTM_GETLINK - RTM_BASE] = { .dumpit = rtnetlink_dump_ifinfo }, - [RTM_SETLINK - RTM_BASE] = { .doit = do_setlink }, - [RTM_GETADDR - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, - [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, - [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, - [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, - [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_GETLINK - RTM_BASE] = { .dumpit = rtnetlink_dump_ifinfo }, + [RTM_SETLINK - RTM_BASE] = { .doit = do_setlink }, + [RTM_GETADDR - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, + [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_GETNEIGHTBL - RTM_BASE] = { .dumpit = neightbl_dump_info }, + [RTM_SETNEIGHTBL - RTM_BASE] = { .doit = neightbl_set }, }; static int rtnetlink_event(struct notifier_block *this, unsigned long event, void *ptr) Index: security/selinux/nlmsgtab.c =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/security/selinux/nlmsgtab.c (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/security/selinux/nlmsgtab.c (mode:100644) @@ -63,6 +63,8 @@ { RTM_GETPREFIX, NETLINK_ROUTE_SOCKET__NLMSG_READ }, { RTM_GETMULTICAST, NETLINK_ROUTE_SOCKET__NLMSG_READ }, { RTM_GETANYCAST, NETLINK_ROUTE_SOCKET__NLMSG_READ }, + { RTM_GETNEIGHTBL, NETLINK_ROUTE_SOCKET__NLMSG_READ }, + { RTM_SETNEIGHTBL, NETLINK_ROUTE_SOCKET__NLMSG_WRITE }, }; static struct nlmsg_perm nlmsg_firewall_perms[] = From mchan@broadcom.com Thu May 26 11:56:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:56:03 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QItgXr003726 for ; Thu, 26 May 2005 11:55:59 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:54:35 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:54:56 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO56419; Thu, 26 May 2005 11:54:56 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA27112; Thu, 26 May 2005 11:54:56 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:54:56 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 10:57:20 -0700 Subject: [PATCH 2.6.12-rc5 3/9] tg3: Add link test From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1117128795.3744.22.camel@rh4> References: <1117128795.3744.22.camel@rh4> Date: Thu, 26 May 2005 10:57:20 -0700 Message-ID: <1117130240.3744.54.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88C4E12V42018684-01-01 Content-Type: multipart/mixed; boundary="=-rCDzqlbi4BK20FWmH76S" X-archive-position: 1681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1786 Lines: 38 --=-rCDzqlbi4BK20FWmH76S Content-Type: text/plain Content-Transfer-Encoding: 7bit Signed-off-by: Michael Chan --=-rCDzqlbi4BK20FWmH76S Content-Disposition: attachment; filename=tg3-d3.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-d3.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGQyL2RyaXZlcnMvbmV0L3RnMy5jIGQzL2RyaXZlcnMvbmV0L3RnMy5jDQotLS0g ZDIvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yNSAxMjo1OTowMC4wMDAwMDAwMDAgLTA3MDAN CisrKyBkMy9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTA1LTI1IDEyOjU5OjA5LjAwMDAwMDAwMCAt MDcwMA0KQEAgLTcyODEsNiArNzI4MSwzMiBAQA0KIAlyZXR1cm4gZXJyOw0KIH0NCiANCisjZGVm aW5lIFRHM19TRVJERVNfVElNRU9VVF9TRUMJMg0KKyNkZWZpbmUgVEczX0NPUFBFUl9USU1FT1VU X1NFQwk2DQorDQorc3RhdGljIGludCB0ZzNfdGVzdF9saW5rKHN0cnVjdCB0ZzMgKnRwKQ0KK3sN CisJaW50IGksIG1heDsNCisNCisJaWYgKCFuZXRpZl9ydW5uaW5nKHRwLT5kZXYpKQ0KKwkJcmV0 dXJuIC1FTk9ERVY7DQorDQorCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyX1BIWV9TRVJE RVMpDQorCQltYXggPSBURzNfU0VSREVTX1RJTUVPVVRfU0VDOw0KKwllbHNlDQorCQltYXggPSBU RzNfQ09QUEVSX1RJTUVPVVRfU0VDOw0KKw0KKwlmb3IgKGkgPSAwOyBpIDwgbWF4OyBpKyspIHsN CisJCWlmIChuZXRpZl9jYXJyaWVyX29rKHRwLT5kZXYpKQ0KKwkJCXJldHVybiAwOw0KKw0KKwkJ aWYgKG1zbGVlcF9pbnRlcnJ1cHRpYmxlKDEwMDApKQ0KKwkJCWJyZWFrOw0KKwl9DQorDQorCXJl dHVybiAtRUlPOw0KK30NCisNCiBzdGF0aWMgdm9pZCB0ZzNfc2VsZl90ZXN0KHN0cnVjdCBuZXRf ZGV2aWNlICpkZXYsIHN0cnVjdCBldGh0b29sX3Rlc3QgKmV0ZXN0LA0KIAkJCSAgdTY0ICpkYXRh KQ0KIHsNCkBAIC03MjkyLDYgKzczMTgsMTAgQEANCiAJCWV0ZXN0LT5mbGFncyB8PSBFVEhfVEVT VF9GTF9GQUlMRUQ7DQogCQlkYXRhWzBdID0gMTsNCiAJfQ0KKwlpZiAodGczX3Rlc3RfbGluayh0 cCkgIT0gMCkgew0KKwkJZXRlc3QtPmZsYWdzIHw9IEVUSF9URVNUX0ZMX0ZBSUxFRDsNCisJCWRh dGFbMV0gPSAxOw0KKwl9DQogfQ0KIA0KIHN0YXRpYyBpbnQgdGczX2lvY3RsKHN0cnVjdCBuZXRf ZGV2aWNlICpkZXYsIHN0cnVjdCBpZnJlcSAqaWZyLCBpbnQgY21kKQ0K --=-rCDzqlbi4BK20FWmH76S-- From tgraf@suug.ch Thu May 26 11:56:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:56:46 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIuMXq004795 for ; Thu, 26 May 2005 11:56:23 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 1E6F31C0EB; Thu, 26 May 2005 20:55:57 +0200 (CEST) Date: Thu, 26 May 2005 20:55:56 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [NEIGH] Remove unused fields in struct neigh_parms and neigh_table Message-ID: <20050526185556.GA15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526185306.GW15391@postel.suug.ch> X-archive-position: 1682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1056 Lines: 34 Signed-off-by: Thomas Graf --- commit 45b866033b439e510f3638ce9ac0990446b8b3cd tree 72baef0bb9b97ac2990bcca05b8f831b30303008 parent 3688d656f38445cc120b0970cd437cad1bb929dd author Thomas Graf Thu, 26 May 2005 20:42:10 +0200 committer Thomas Graf Thu, 26 May 2005 20:42:10 +0200 include/net/neighbour.h | 3 --- 1 files changed, 3 deletions(-) Index: include/net/neighbour.h =================================================================== --- 2fbcbf92bed82aaef81b2bcc9baecafd61dfb0ce/include/net/neighbour.h (mode:100644) +++ 72baef0bb9b97ac2990bcca05b8f831b30303008/include/net/neighbour.h (mode:100644) @@ -69,8 +69,6 @@ struct neigh_parms *next; int (*neigh_setup)(struct neighbour *); struct neigh_table *tbl; - int entries; - void *priv; void *sysctl_table; @@ -193,7 +191,6 @@ atomic_t entries; rwlock_t lock; unsigned long last_rand; - struct neigh_parms *parms_list; kmem_cache_t *kmem_cachep; struct neigh_statistics *stats; struct neighbour **hash_buckets; From mchan@broadcom.com Thu May 26 11:56:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:57:02 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIuwXq005489 for ; Thu, 26 May 2005 11:56:58 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:55:56 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:55:55 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO56727; Thu, 26 May 2005 11:55:55 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA27418; Thu, 26 May 2005 11:55:55 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:55:55 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 10:58:18 -0700 Subject: [PATCH 2.6.12-rc5 4/9] tg3: Add parameter to tg3_halt From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1117128795.3744.22.camel@rh4> References: <1117128795.3744.22.camel@rh4> Date: Thu, 26 May 2005 10:58:18 -0700 Message-ID: <1117130298.3744.55.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88C4362U42361795-01-01 Content-Type: multipart/mixed; boundary="=-ADm/QKBxizVw3JF02nx2" X-archive-position: 1683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 4797 Lines: 81 --=-ADm/QKBxizVw3JF02nx2 Content-Type: text/plain Content-Transfer-Encoding: 7bit Add a reset kind parameter to tg3_halt() so that the RESET_KIND_SUSPEND parameter can be passed to tg3_halt() before doing offline tests. All other calls to tg3_halt() will use the RESET_KIND_SHUTDOWN parameter. Signed-off-by: Michael Chan --=-ADm/QKBxizVw3JF02nx2 Content-Disposition: attachment; filename=tg3-d4.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-d4.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGQzL2RyaXZlcnMvbmV0L3RnMy5jIGQ0L2RyaXZlcnMvbmV0L3RnMy5jDQotLS0g ZDMvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yNSAxMjo1OTowOS4wMDAwMDAwMDAgLTA3MDAN CisrKyBkNC9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTA1LTI1IDEyOjU5OjE3LjAwMDAwMDAwMCAt MDcwMA0KQEAgLTMwODMsNyArMzA4Myw3IEBADQogfQ0KIA0KIHN0YXRpYyBpbnQgdGczX2luaXRf aHcoc3RydWN0IHRnMyAqKTsNCi1zdGF0aWMgaW50IHRnM19oYWx0KHN0cnVjdCB0ZzMgKiwgaW50 KTsNCitzdGF0aWMgaW50IHRnM19oYWx0KHN0cnVjdCB0ZzMgKiwgaW50LCBpbnQpOw0KIA0KICNp ZmRlZiBDT05GSUdfTkVUX1BPTExfQ09OVFJPTExFUg0KIHN0YXRpYyB2b2lkIHRnM19wb2xsX2Nv bnRyb2xsZXIoc3RydWN0IG5ldF9kZXZpY2UgKmRldikNCkBAIC0zMTA3LDcgKzMxMDcsNyBAQA0K IAlyZXN0YXJ0X3RpbWVyID0gdHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl9SRVNUQVJUX1RJTUVS Ow0KIAl0cC0+dGczX2ZsYWdzMiAmPSB+VEczX0ZMRzJfUkVTVEFSVF9USU1FUjsNCiANCi0JdGcz X2hhbHQodHAsIDApOw0KKwl0ZzNfaGFsdCh0cCwgUkVTRVRfS0lORF9TSFVURE9XTiwgMCk7DQog CXRnM19pbml0X2h3KHRwKTsNCiANCiAJdGczX25ldGlmX3N0YXJ0KHRwKTsNCkBAIC0zNDUzLDcg KzM0NTMsNyBAQA0KIAlzcGluX2xvY2tfaXJxKCZ0cC0+bG9jayk7DQogCXNwaW5fbG9jaygmdHAt PnR4X2xvY2spOw0KIA0KLQl0ZzNfaGFsdCh0cCwgMSk7DQorCXRnM19oYWx0KHRwLCBSRVNFVF9L SU5EX1NIVVRET1dOLCAxKTsNCiANCiAJdGczX3NldF9tdHUoZGV2LCB0cCwgbmV3X210dSk7DQog DQpAQCAtNDE0NCwxOSArNDE0NCwxOSBAQA0KIH0NCiANCiAvKiB0cC0+bG9jayBpcyBoZWxkLiAq Lw0KLXN0YXRpYyBpbnQgdGczX2hhbHQoc3RydWN0IHRnMyAqdHAsIGludCBzaWxlbnQpDQorc3Rh dGljIGludCB0ZzNfaGFsdChzdHJ1Y3QgdGczICp0cCwgaW50IGtpbmQsIGludCBzaWxlbnQpDQog ew0KIAlpbnQgZXJyOw0KIA0KIAl0ZzNfc3RvcF9mdyh0cCk7DQogDQotCXRnM193cml0ZV9zaWdf cHJlX3Jlc2V0KHRwLCBSRVNFVF9LSU5EX1NIVVRET1dOKTsNCisJdGczX3dyaXRlX3NpZ19wcmVf cmVzZXQodHAsIGtpbmQpOw0KIA0KIAl0ZzNfYWJvcnRfaHcodHAsIHNpbGVudCk7DQogCWVyciA9 IHRnM19jaGlwX3Jlc2V0KHRwKTsNCiANCi0JdGczX3dyaXRlX3NpZ19sZWdhY3kodHAsIFJFU0VU X0tJTkRfU0hVVERPV04pOw0KLQl0ZzNfd3JpdGVfc2lnX3Bvc3RfcmVzZXQodHAsIFJFU0VUX0tJ TkRfU0hVVERPV04pOw0KKwl0ZzNfd3JpdGVfc2lnX2xlZ2FjeSh0cCwga2luZCk7DQorCXRnM193 cml0ZV9zaWdfcG9zdF9yZXNldCh0cCwga2luZCk7DQogDQogCWlmIChlcnIpDQogCQlyZXR1cm4g ZXJyOw0KQEAgLTU5OTcsNyArNTk5Nyw3IEBADQogCXNwaW5fbG9ja19pcnEoJnRwLT5sb2NrKTsN CiAJc3Bpbl9sb2NrKCZ0cC0+dHhfbG9jayk7DQogDQotCXRnM19oYWx0KHRwLCAxKTsNCisJdGcz X2hhbHQodHAsIFJFU0VUX0tJTkRfU0hVVERPV04sIDEpOw0KIAllcnIgPSB0ZzNfaW5pdF9odyh0 cCk7DQogDQogCXNwaW5fdW5sb2NrKCZ0cC0+dHhfbG9jayk7DQpAQCAtNjA3Myw3ICs2MDczLDcg QEANCiANCiAJZXJyID0gdGczX2luaXRfaHcodHApOw0KIAlpZiAoZXJyKSB7DQotCQl0ZzNfaGFs dCh0cCwgMSk7DQorCQl0ZzNfaGFsdCh0cCwgUkVTRVRfS0lORF9TSFVURE9XTiwgMSk7DQogCQl0 ZzNfZnJlZV9yaW5ncyh0cCk7DQogCX0gZWxzZSB7DQogCQlpZiAodHAtPnRnM19mbGFncyAmIFRH M19GTEFHX1RBR0dFRF9TVEFUVVMpDQpAQCAtNjExNyw3ICs2MTE3LDcgQEANCiAJCQkJcGNpX2Rp c2FibGVfbXNpKHRwLT5wZGV2KTsNCiAJCQkJdHAtPnRnM19mbGFnczIgJj0gflRHM19GTEcyX1VT SU5HX01TSTsNCiAJCQl9DQotCQkJdGczX2hhbHQodHAsIDEpOw0KKwkJCXRnM19oYWx0KHRwLCBS RVNFVF9LSU5EX1NIVVRET1dOLCAxKTsNCiAJCQl0ZzNfZnJlZV9yaW5ncyh0cCk7DQogCQkJdGcz X2ZyZWVfY29uc2lzdGVudCh0cCk7DQogDQpAQCAtNjM5MCw3ICs2MzkwLDcgQEANCiANCiAJdGcz X2Rpc2FibGVfaW50cyh0cCk7DQogDQotCXRnM19oYWx0KHRwLCAxKTsNCisJdGczX2hhbHQodHAs IFJFU0VUX0tJTkRfU0hVVERPV04sIDEpOw0KIAl0ZzNfZnJlZV9yaW5ncyh0cCk7DQogCXRwLT50 ZzNfZmxhZ3MgJj0NCiAJCX4oVEczX0ZMQUdfSU5JVF9DT01QTEVURSB8DQpAQCAtNzExMCw3ICs3 MTEwLDcgQEANCiAJdHAtPnR4X3BlbmRpbmcgPSBlcmluZy0+dHhfcGVuZGluZzsNCiANCiAJaWYg KG5ldGlmX3J1bm5pbmcoZGV2KSkgew0KLQkJdGczX2hhbHQodHAsIDEpOw0KKwkJdGczX2hhbHQo dHAsIFJFU0VUX0tJTkRfU0hVVERPV04sIDEpOw0KIAkJdGczX2luaXRfaHcodHApOw0KIAkJdGcz X25ldGlmX3N0YXJ0KHRwKTsNCiAJfQ0KQEAgLTcxNTMsNyArNzE1Myw3IEBADQogCQl0cC0+dGcz X2ZsYWdzICY9IH5URzNfRkxBR19UWF9QQVVTRTsNCiANCiAJaWYgKG5ldGlmX3J1bm5pbmcoZGV2 KSkgew0KLQkJdGczX2hhbHQodHAsIDEpOw0KKwkJdGczX2hhbHQodHAsIFJFU0VUX0tJTkRfU0hV VERPV04sIDEpOw0KIAkJdGczX2luaXRfaHcodHApOw0KIAkJdGczX25ldGlmX3N0YXJ0KHRwKTsN CiAJfQ0KQEAgLTk1ODYsNyArOTU4Niw3IEBADQogCSAgICAodHIzMihXRE1BQ19NT0RFKSAmIFdE TUFDX01PREVfRU5BQkxFKSkgew0KIAkJcGNpX3NhdmVfc3RhdGUodHAtPnBkZXYpOw0KIAkJdHcz MihNRU1BUkJfTU9ERSwgTUVNQVJCX01PREVfRU5BQkxFKTsNCi0JCXRnM19oYWx0KHRwLCAxKTsN CisJCXRnM19oYWx0KHRwLCBSRVNFVF9LSU5EX1NIVVRET1dOLCAxKTsNCiAJfQ0KIA0KIAllcnIg PSB0ZzNfdGVzdF9kbWEodHApOw0KQEAgLTk3MTMsNyArOTcxMyw3IEBADQogDQogCXNwaW5fbG9j a19pcnEoJnRwLT5sb2NrKTsNCiAJc3Bpbl9sb2NrKCZ0cC0+dHhfbG9jayk7DQotCXRnM19oYWx0 KHRwLCAxKTsNCisJdGczX2hhbHQodHAsIFJFU0VUX0tJTkRfU0hVVERPV04sIDEpOw0KIAlzcGlu X3VubG9jaygmdHAtPnR4X2xvY2spOw0KIAlzcGluX3VubG9ja19pcnEoJnRwLT5sb2NrKTsNCiAN Cg== --=-ADm/QKBxizVw3JF02nx2-- From mchan@broadcom.com Thu May 26 11:57:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:57:12 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIuwXr005489 for ; Thu, 26 May 2005 11:57:09 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:56:12 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:56:11 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO56790; Thu, 26 May 2005 11:56:09 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA27493; Thu, 26 May 2005 11:56:09 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:56:09 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 10:58:33 -0700 Subject: [PATCH 2.6.12-rc5 5/9] tg3: Add register test From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1117128795.3744.22.camel@rh4> References: <1117128795.3744.22.camel@rh4> Date: Thu, 26 May 2005 10:58:32 -0700 Message-ID: <1117130312.3744.57.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88C4462U42361847-01-01 Content-Type: multipart/mixed; boundary="=-pKwGCt3vaQes1MCKUNUs" X-archive-position: 1684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 10937 Lines: 157 --=-pKwGCt3vaQes1MCKUNUs Content-Type: text/plain Content-Transfer-Encoding: 7bit Signed-off-by: Michael Chan --=-pKwGCt3vaQes1MCKUNUs Content-Disposition: attachment; filename=tg3-d5.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-d5.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGQ0L2RyaXZlcnMvbmV0L3RnMy5jIGQ1L2RyaXZlcnMvbmV0L3RnMy5jDQotLS0g ZDQvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yNSAxMjo1OToxNy4wMDAwMDAwMDAgLTA3MDAN CisrKyBkNS9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTA1LTI1IDEyOjU5OjI0LjAwMDAwMDAwMCAt MDcwMA0KQEAgLTczMDcsNiArNzMwNywyMTkgQEANCiAJcmV0dXJuIC1FSU87DQogfQ0KIA0KKy8q IE9ubHkgdGVzdCB0aGUgY29tbW9ubHkgdXNlZCByZWdpc3RlcnMgKi8NCitzdGF0aWMgaW50IHRn M190ZXN0X3JlZ2lzdGVycyhzdHJ1Y3QgdGczICp0cCkNCit7DQorCWludCBpLCBpc181NzA1Ow0K Kwl1MzIgb2Zmc2V0LCByZWFkX21hc2ssIHdyaXRlX21hc2ssIHZhbCwgc2F2ZV92YWwsIHJlYWRf dmFsOw0KKwlzdGF0aWMgc3RydWN0IHsNCisJCXUxNiBvZmZzZXQ7DQorCQl1MTYgZmxhZ3M7DQor I2RlZmluZSBURzNfRkxfNTcwNQkweDENCisjZGVmaW5lIFRHM19GTF9OT1RfNTcwNQkweDINCisj ZGVmaW5lIFRHM19GTF9OT1RfNTc4OAkweDQNCisJCXUzMiByZWFkX21hc2s7DQorCQl1MzIgd3Jp dGVfbWFzazsNCisJfSByZWdfdGJsW10gPSB7DQorCQkvKiBNQUMgQ29udHJvbCBSZWdpc3RlcnMg Ki8NCisJCXsgTUFDX01PREUsIFRHM19GTF9OT1RfNTcwNSwNCisJCQkweDAwMDAwMDAwLCAweDAw ZWY2ZjhjIH0sDQorCQl7IE1BQ19NT0RFLCBURzNfRkxfNTcwNSwNCisJCQkweDAwMDAwMDAwLCAw eDAxZWY2YjhjIH0sDQorCQl7IE1BQ19TVEFUVVMsIFRHM19GTF9OT1RfNTcwNSwNCisJCQkweDAz ODAwMTA3LCAweDAwMDAwMDAwIH0sDQorCQl7IE1BQ19TVEFUVVMsIFRHM19GTF81NzA1LA0KKwkJ CTB4MDM4MDAxMDAsIDB4MDAwMDAwMDAgfSwNCisJCXsgTUFDX0FERFJfMF9ISUdILCAweDAwMDAs DQorCQkJMHgwMDAwMDAwMCwgMHgwMDAwZmZmZiB9LA0KKwkJeyBNQUNfQUREUl8wX0xPVywgMHgw MDAwLA0KKwkJICAgICAgIAkweDAwMDAwMDAwLCAweGZmZmZmZmZmIH0sDQorCQl7IE1BQ19SWF9N VFVfU0laRSwgMHgwMDAwLA0KKwkJCTB4MDAwMDAwMDAsIDB4MDAwMGZmZmYgfSwNCisJCXsgTUFD X1RYX01PREUsIDB4MDAwMCwNCisJCQkweDAwMDAwMDAwLCAweDAwMDAwMDcwIH0sDQorCQl7IE1B Q19UWF9MRU5HVEhTLCAweDAwMDAsDQorCQkJMHgwMDAwMDAwMCwgMHgwMDAwM2ZmZiB9LA0KKwkJ eyBNQUNfUlhfTU9ERSwgVEczX0ZMX05PVF81NzA1LA0KKwkJCTB4MDAwMDAwMDAsIDB4MDAwMDA3 ZmMgfSwNCisJCXsgTUFDX1JYX01PREUsIFRHM19GTF81NzA1LA0KKwkJCTB4MDAwMDAwMDAsIDB4 MDAwMDA3ZGMgfSwNCisJCXsgTUFDX0hBU0hfUkVHXzAsIDB4MDAwMCwNCisJCQkweDAwMDAwMDAw LCAweGZmZmZmZmZmIH0sDQorCQl7IE1BQ19IQVNIX1JFR18xLCAweDAwMDAsDQorCQkJMHgwMDAw MDAwMCwgMHhmZmZmZmZmZiB9LA0KKwkJeyBNQUNfSEFTSF9SRUdfMiwgMHgwMDAwLA0KKwkJCTB4 MDAwMDAwMDAsIDB4ZmZmZmZmZmYgfSwNCisJCXsgTUFDX0hBU0hfUkVHXzMsIDB4MDAwMCwNCisJ CQkweDAwMDAwMDAwLCAweGZmZmZmZmZmIH0sDQorDQorCQkvKiBSZWNlaXZlIERhdGEgYW5kIFJl Y2VpdmUgQkQgSW5pdGlhdG9yIENvbnRyb2wgUmVnaXN0ZXJzLiAqLw0KKwkJeyBSQ1ZEQkRJX0pV TUJPX0JEKzAsIFRHM19GTF9OT1RfNTcwNSwNCisJCQkweDAwMDAwMDAwLCAweGZmZmZmZmZmIH0s DQorCQl7IFJDVkRCRElfSlVNQk9fQkQrNCwgVEczX0ZMX05PVF81NzA1LA0KKwkJCTB4MDAwMDAw MDAsIDB4ZmZmZmZmZmYgfSwNCisJCXsgUkNWREJESV9KVU1CT19CRCs4LCBURzNfRkxfTk9UXzU3 MDUsDQorCQkJMHgwMDAwMDAwMCwgMHgwMDAwMDAwMyB9LA0KKwkJeyBSQ1ZEQkRJX0pVTUJPX0JE KzB4YywgVEczX0ZMX05PVF81NzA1LA0KKwkJCTB4MDAwMDAwMDAsIDB4ZmZmZmZmZmYgfSwNCisJ CXsgUkNWREJESV9TVERfQkQrMCwgMHgwMDAwLA0KKwkJCTB4MDAwMDAwMDAsIDB4ZmZmZmZmZmYg fSwNCisJCXsgUkNWREJESV9TVERfQkQrNCwgMHgwMDAwLA0KKwkJCTB4MDAwMDAwMDAsIDB4ZmZm ZmZmZmYgfSwNCisJCXsgUkNWREJESV9TVERfQkQrOCwgMHgwMDAwLA0KKwkJCTB4MDAwMDAwMDAs IDB4ZmZmZjAwMDIgfSwNCisJCXsgUkNWREJESV9TVERfQkQrMHhjLCAweDAwMDAsDQorCQkJMHgw MDAwMDAwMCwgMHhmZmZmZmZmZiB9LA0KKwkNCisJCS8qIFJlY2VpdmUgQkQgSW5pdGlhdG9yIENv bnRyb2wgUmVnaXN0ZXJzLiAqLw0KKwkJeyBSQ1ZCRElfU1REX1RIUkVTSCwgVEczX0ZMX05PVF81 NzA1LA0KKwkJCTB4MDAwMDAwMDAsIDB4ZmZmZmZmZmYgfSwNCisJCXsgUkNWQkRJX1NURF9USFJF U0gsIFRHM19GTF81NzA1LA0KKwkJCTB4MDAwMDAwMDAsIDB4MDAwMDAzZmYgfSwNCisJCXsgUkNW QkRJX0pVTUJPX1RIUkVTSCwgVEczX0ZMX05PVF81NzA1LA0KKwkJCTB4MDAwMDAwMDAsIDB4ZmZm ZmZmZmYgfSwNCisJDQorCQkvKiBIb3N0IENvYWxlc2NpbmcgQ29udHJvbCBSZWdpc3RlcnMuICov DQorCQl7IEhPU1RDQ19NT0RFLCBURzNfRkxfTk9UXzU3MDUsDQorCQkJMHgwMDAwMDAwMCwgMHgw MDAwMDAwNCB9LA0KKwkJeyBIT1NUQ0NfTU9ERSwgVEczX0ZMXzU3MDUsDQorCQkJMHgwMDAwMDAw MCwgMHgwMDAwMDBmNiB9LA0KKwkJeyBIT1NUQ0NfUlhDT0xfVElDS1MsIFRHM19GTF9OT1RfNTcw NSwNCisJCQkweDAwMDAwMDAwLCAweGZmZmZmZmZmIH0sDQorCQl7IEhPU1RDQ19SWENPTF9USUNL UywgVEczX0ZMXzU3MDUsDQorCQkJMHgwMDAwMDAwMCwgMHgwMDAwMDNmZiB9LA0KKwkJeyBIT1NU Q0NfVFhDT0xfVElDS1MsIFRHM19GTF9OT1RfNTcwNSwNCisJCQkweDAwMDAwMDAwLCAweGZmZmZm ZmZmIH0sDQorCQl7IEhPU1RDQ19UWENPTF9USUNLUywgVEczX0ZMXzU3MDUsDQorCQkJMHgwMDAw MDAwMCwgMHgwMDAwMDNmZiB9LA0KKwkJeyBIT1NUQ0NfUlhNQVhfRlJBTUVTLCBURzNfRkxfTk9U XzU3MDUsDQorCQkJMHgwMDAwMDAwMCwgMHhmZmZmZmZmZiB9LA0KKwkJeyBIT1NUQ0NfUlhNQVhf RlJBTUVTLCBURzNfRkxfNTcwNSB8IFRHM19GTF9OT1RfNTc4OCwNCisJCQkweDAwMDAwMDAwLCAw eDAwMDAwMGZmIH0sDQorCQl7IEhPU1RDQ19UWE1BWF9GUkFNRVMsIFRHM19GTF9OT1RfNTcwNSwN CisJCQkweDAwMDAwMDAwLCAweGZmZmZmZmZmIH0sDQorCQl7IEhPU1RDQ19UWE1BWF9GUkFNRVMs IFRHM19GTF81NzA1IHwgVEczX0ZMX05PVF81Nzg4LA0KKwkJCTB4MDAwMDAwMDAsIDB4MDAwMDAw ZmYgfSwNCisJCXsgSE9TVENDX1JYQ09BTF9USUNLX0lOVCwgVEczX0ZMX05PVF81NzA1LA0KKwkJ CTB4MDAwMDAwMDAsIDB4ZmZmZmZmZmYgfSwNCisJCXsgSE9TVENDX1RYQ09BTF9USUNLX0lOVCwg VEczX0ZMX05PVF81NzA1LA0KKwkJCTB4MDAwMDAwMDAsIDB4ZmZmZmZmZmYgfSwNCisJCXsgSE9T VENDX1JYQ09BTF9NQVhGX0lOVCwgVEczX0ZMX05PVF81NzA1LA0KKwkJCTB4MDAwMDAwMDAsIDB4 ZmZmZmZmZmYgfSwNCisJCXsgSE9TVENDX1JYQ09BTF9NQVhGX0lOVCwgVEczX0ZMXzU3MDUgfCBU RzNfRkxfTk9UXzU3ODgsDQorCQkJMHgwMDAwMDAwMCwgMHgwMDAwMDBmZiB9LA0KKwkJeyBIT1NU Q0NfVFhDT0FMX01BWEZfSU5ULCBURzNfRkxfTk9UXzU3MDUsDQorCQkJMHgwMDAwMDAwMCwgMHhm ZmZmZmZmZiB9LA0KKwkJeyBIT1NUQ0NfVFhDT0FMX01BWEZfSU5ULCBURzNfRkxfNTcwNSB8IFRH M19GTF9OT1RfNTc4OCwNCisJCQkweDAwMDAwMDAwLCAweDAwMDAwMGZmIH0sDQorCQl7IEhPU1RD Q19TVEFUX0NPQUxfVElDS1MsIFRHM19GTF9OT1RfNTcwNSwNCisJCQkweDAwMDAwMDAwLCAweGZm ZmZmZmZmIH0sDQorCQl7IEhPU1RDQ19TVEFUU19CTEtfSE9TVF9BRERSLCBURzNfRkxfTk9UXzU3 MDUsDQorCQkJMHgwMDAwMDAwMCwgMHhmZmZmZmZmZiB9LA0KKwkJeyBIT1NUQ0NfU1RBVFNfQkxL X0hPU1RfQUREUis0LCBURzNfRkxfTk9UXzU3MDUsDQorCQkJMHgwMDAwMDAwMCwgMHhmZmZmZmZm ZiB9LA0KKwkJeyBIT1NUQ0NfU1RBVFVTX0JMS19IT1NUX0FERFIsIDB4MDAwMCwNCisJCQkweDAw MDAwMDAwLCAweGZmZmZmZmZmIH0sDQorCQl7IEhPU1RDQ19TVEFUVVNfQkxLX0hPU1RfQUREUis0 LCAweDAwMDAsDQorCQkJMHgwMDAwMDAwMCwgMHhmZmZmZmZmZiB9LA0KKwkJeyBIT1NUQ0NfU1RB VFNfQkxLX05JQ19BRERSLCAweDAwMDAsDQorCQkJMHhmZmZmZmZmZiwgMHgwMDAwMDAwMCB9LA0K KwkJeyBIT1NUQ0NfU1RBVFVTX0JMS19OSUNfQUREUiwgMHgwMDAwLA0KKwkJCTB4ZmZmZmZmZmYs IDB4MDAwMDAwMDAgfSwNCisNCisJCS8qIEJ1ZmZlciBNYW5hZ2VyIENvbnRyb2wgUmVnaXN0ZXJz LiAqLw0KKwkJeyBCVUZNR1JfTUJfUE9PTF9BRERSLCAweDAwMDAsDQorCQkJMHgwMDAwMDAwMCwg MHgwMDdmZmY4MCB9LA0KKwkJeyBCVUZNR1JfTUJfUE9PTF9TSVpFLCAweDAwMDAsDQorCQkJMHgw MDAwMDAwMCwgMHgwMDdmZmZmZiB9LA0KKwkJeyBCVUZNR1JfTUJfUkRNQV9MT1dfV0FURVIsIDB4 MDAwMCwNCisJCQkweDAwMDAwMDAwLCAweDAwMDAwMDNmIH0sDQorCQl7IEJVRk1HUl9NQl9NQUNS WF9MT1dfV0FURVIsIDB4MDAwMCwNCisJCQkweDAwMDAwMDAwLCAweDAwMDAwMWZmIH0sDQorCQl7 IEJVRk1HUl9NQl9ISUdIX1dBVEVSLCAweDAwMDAsDQorCQkJMHgwMDAwMDAwMCwgMHgwMDAwMDFm ZiB9LA0KKwkJeyBCVUZNR1JfRE1BX0RFU0NfUE9PTF9BRERSLCBURzNfRkxfTk9UXzU3MDUsDQor CQkJMHhmZmZmZmZmZiwgMHgwMDAwMDAwMCB9LA0KKwkJeyBCVUZNR1JfRE1BX0RFU0NfUE9PTF9T SVpFLCBURzNfRkxfTk9UXzU3MDUsDQorCQkJMHhmZmZmZmZmZiwgMHgwMDAwMDAwMCB9LA0KKwkN CisJCS8qIE1haWxib3ggUmVnaXN0ZXJzICovDQorCQl7IEdSQ01CT1hfUkNWU1REX1BST0RfSURY KzQsIDB4MDAwMCwNCisJCQkweDAwMDAwMDAwLCAweDAwMDAwMWZmIH0sDQorCQl7IEdSQ01CT1hf UkNWSlVNQk9fUFJPRF9JRFgrNCwgVEczX0ZMX05PVF81NzA1LA0KKwkJCTB4MDAwMDAwMDAsIDB4 MDAwMDAxZmYgfSwNCisJCXsgR1JDTUJPWF9SQ1ZSRVRfQ09OX0lEWF8wKzQsIDB4MDAwMCwNCisJ CQkweDAwMDAwMDAwLCAweDAwMDAwN2ZmIH0sDQorCQl7IEdSQ01CT1hfU05ESE9TVF9QUk9EX0lE WF8wKzQsIDB4MDAwMCwNCisJCQkweDAwMDAwMDAwLCAweDAwMDAwMWZmIH0sDQorDQorCQl7IDB4 ZmZmZiwgMHgwMDAwLCAweDAwMDAwMDAwLCAweDAwMDAwMDAwIH0sDQorCX07DQorDQorCWlmICh0 cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExVUykNCisJCWlzXzU3MDUgPSAxOw0KKwll bHNlDQorCQlpc181NzA1ID0gMDsNCisNCisJZm9yIChpID0gMDsgcmVnX3RibFtpXS5vZmZzZXQg IT0gMHhmZmZmOyBpKyspIHsNCisJCWlmIChpc181NzA1ICYmIChyZWdfdGJsW2ldLmZsYWdzICYg VEczX0ZMX05PVF81NzA1KSkNCisJCQljb250aW51ZTsNCisNCisJCWlmICghaXNfNTcwNSAmJiAo cmVnX3RibFtpXS5mbGFncyAmIFRHM19GTF81NzA1KSkNCisJCQljb250aW51ZTsNCisNCisJCWlm ICgodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl9JU181Nzg4KSAmJg0KKwkJICAgIChyZWdfdGJs W2ldLmZsYWdzICYgVEczX0ZMX05PVF81Nzg4KSkNCisJCQljb250aW51ZTsNCisNCisJCW9mZnNl dCA9ICh1MzIpIHJlZ190YmxbaV0ub2Zmc2V0Ow0KKwkJcmVhZF9tYXNrID0gcmVnX3RibFtpXS5y ZWFkX21hc2s7DQorCQl3cml0ZV9tYXNrID0gcmVnX3RibFtpXS53cml0ZV9tYXNrOw0KKw0KKwkJ LyogU2F2ZSB0aGUgb3JpZ2luYWwgcmVnaXN0ZXIgY29udGVudCAqLw0KKwkJc2F2ZV92YWwgPSB0 cjMyKG9mZnNldCk7DQorDQorCQkvKiBEZXRlcm1pbmUgdGhlIHJlYWQtb25seSB2YWx1ZS4gKi8N CisJCXJlYWRfdmFsID0gc2F2ZV92YWwgJiByZWFkX21hc2s7DQorDQorCQkvKiBXcml0ZSB6ZXJv IHRvIHRoZSByZWdpc3RlciwgdGhlbiBtYWtlIHN1cmUgdGhlIHJlYWQtb25seSBiaXRzDQorCQkg KiBhcmUgbm90IGNoYW5nZWQgYW5kIHRoZSByZWFkL3dyaXRlIGJpdHMgYXJlIGFsbCB6ZXJvcy4N CisJCSAqLw0KKwkJdHczMihvZmZzZXQsIDApOw0KKw0KKwkJdmFsID0gdHIzMihvZmZzZXQpOw0K Kw0KKwkJLyogVGVzdCB0aGUgcmVhZC1vbmx5IGFuZCByZWFkL3dyaXRlIGJpdHMuICovDQorCQlp ZiAoKCh2YWwgJiByZWFkX21hc2spICE9IHJlYWRfdmFsKSB8fCAodmFsICYgd3JpdGVfbWFzaykp DQorCQkJZ290byBvdXQ7DQorDQorCQkvKiBXcml0ZSBvbmVzIHRvIGFsbCB0aGUgYml0cyBkZWZp bmVkIGJ5IFJkTWFzayBhbmQgV3JNYXNrLCB0aGVuDQorCQkgKiBtYWtlIHN1cmUgdGhlIHJlYWQt b25seSBiaXRzIGFyZSBub3QgY2hhbmdlZCBhbmQgdGhlDQorCQkgKiByZWFkL3dyaXRlIGJpdHMg YXJlIGFsbCBvbmVzLg0KKwkJICovDQorCQl0dzMyKG9mZnNldCwgcmVhZF9tYXNrIHwgd3JpdGVf bWFzayk7DQorDQorCQl2YWwgPSB0cjMyKG9mZnNldCk7DQorDQorCQkvKiBUZXN0IHRoZSByZWFk LW9ubHkgYml0cy4gKi8NCisJCWlmICgodmFsICYgcmVhZF9tYXNrKSAhPSByZWFkX3ZhbCkNCisJ CQlnb3RvIG91dDsNCisNCisJCS8qIFRlc3QgdGhlIHJlYWQvd3JpdGUgYml0cy4gKi8NCisJCWlm ICgodmFsICYgd3JpdGVfbWFzaykgIT0gd3JpdGVfbWFzaykNCisJCQlnb3RvIG91dDsNCisNCisJ CXR3MzIob2Zmc2V0LCBzYXZlX3ZhbCk7DQorCX0NCisNCisJcmV0dXJuIDA7DQorDQorb3V0Og0K KwlwcmludGsoS0VSTl9FUlIgUEZYICJSZWdpc3RlciB0ZXN0IGZhaWxlZCBhdCBvZmZzZXQgJXhc biIsIG9mZnNldCk7DQorCXR3MzIob2Zmc2V0LCBzYXZlX3ZhbCk7DQorCXJldHVybiAtRUlPOw0K K30NCisNCiBzdGF0aWMgdm9pZCB0ZzNfc2VsZl90ZXN0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYs IHN0cnVjdCBldGh0b29sX3Rlc3QgKmV0ZXN0LA0KIAkJCSAgdTY0ICpkYXRhKQ0KIHsNCkBAIC03 MzIyLDYgKzc1MzUsMzQgQEANCiAJCWV0ZXN0LT5mbGFncyB8PSBFVEhfVEVTVF9GTF9GQUlMRUQ7 DQogCQlkYXRhWzFdID0gMTsNCiAJfQ0KKwlpZiAoZXRlc3QtPmZsYWdzICYgRVRIX1RFU1RfRkxf T0ZGTElORSkgew0KKwkJaWYgKG5ldGlmX3J1bm5pbmcoZGV2KSkNCisJCQl0ZzNfbmV0aWZfc3Rv cCh0cCk7DQorDQorCQlzcGluX2xvY2tfaXJxKCZ0cC0+bG9jayk7DQorCQlzcGluX2xvY2soJnRw LT50eF9sb2NrKTsNCisNCisJCXRnM19oYWx0KHRwLCBSRVNFVF9LSU5EX1NVU1BFTkQsIDEpOw0K KwkJdGczX252cmFtX2xvY2sodHApOw0KKwkJdGczX2hhbHRfY3B1KHRwLCBSWF9DUFVfQkFTRSk7 DQorCQlpZiAoISh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExVUykpDQorCQkJdGcz X2hhbHRfY3B1KHRwLCBUWF9DUFVfQkFTRSk7DQorCQl0ZzNfbnZyYW1fdW5sb2NrKHRwKTsNCisN CisJCWlmICh0ZzNfdGVzdF9yZWdpc3RlcnModHApICE9IDApIHsNCisJCQlldGVzdC0+ZmxhZ3Mg fD0gRVRIX1RFU1RfRkxfRkFJTEVEOw0KKwkJCWRhdGFbMl0gPSAxOw0KKwkJfQ0KKw0KKwkJdGcz X2hhbHQodHAsIFJFU0VUX0tJTkRfU0hVVERPV04sIDEpOw0KKwkJaWYgKG5ldGlmX3J1bm5pbmco ZGV2KSkgew0KKwkJCXRwLT50ZzNfZmxhZ3MgfD0gVEczX0ZMQUdfSU5JVF9DT01QTEVURTsNCisJ CQl0ZzNfaW5pdF9odyh0cCk7DQorCQkJdGczX25ldGlmX3N0YXJ0KHRwKTsNCisJCX0NCisJCXNw aW5fdW5sb2NrKCZ0cC0+dHhfbG9jayk7DQorCQlzcGluX3VubG9ja19pcnEoJnRwLT5sb2NrKTsN CisJfQ0KIH0NCiANCiBzdGF0aWMgaW50IHRnM19pb2N0bChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 LCBzdHJ1Y3QgaWZyZXEgKmlmciwgaW50IGNtZCkNCg== --=-pKwGCt3vaQes1MCKUNUs-- From mchan@broadcom.com Thu May 26 11:57:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:57:41 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIvYXq006448 for ; Thu, 26 May 2005 11:57:35 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:56:24 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:56:22 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO56833; Thu, 26 May 2005 11:56:21 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA27521; Thu, 26 May 2005 11:56:21 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:56:21 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 10:58:45 -0700 Subject: [PATCH 2.6.12-rc5 6/9] tg3: Add memory test From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1117128795.3744.22.camel@rh4> References: <1117128795.3744.22.camel@rh4> Date: Thu, 26 May 2005 10:58:45 -0700 Message-ID: <1117130325.3744.58.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88C4521VO2252452-01-01 Content-Type: multipart/mixed; boundary="=-Qaxjim3ius6F+HrSKR0b" X-archive-position: 1685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 2864 Lines: 52 --=-Qaxjim3ius6F+HrSKR0b Content-Type: text/plain Content-Transfer-Encoding: 7bit Signed-off-by: Michael Chan --=-Qaxjim3ius6F+HrSKR0b Content-Disposition: attachment; filename=tg3-d6.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-d6.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGQ1L2RyaXZlcnMvbmV0L3RnMy5jIGQ2L2RyaXZlcnMvbmV0L3RnMy5jDQotLS0g ZDUvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yNSAxMjo1OToyNC4wMDAwMDAwMDAgLTA3MDAN CisrKyBkNi9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTA1LTI1IDEyOjU5OjMxLjAwMDAwMDAwMCAt MDcwMA0KQEAgLTc1MjAsNiArNzUyMCw2MiBAQA0KIAlyZXR1cm4gLUVJTzsNCiB9DQogDQorc3Rh dGljIGludCB0ZzNfZG9fbWVtX3Rlc3Qoc3RydWN0IHRnMyAqdHAsIHUzMiBvZmZzZXQsIHUzMiBs ZW4pDQorew0KKwlzdGF0aWMgdTMyIHRlc3RfcGF0dGVybltdID0geyAweDAwMDAwMDAwLCAweGZm ZmZmZmZmLCAweGFhNTVhNTVhIH07DQorCWludCBpOw0KKwl1MzIgajsNCisNCisJZm9yIChpID0g MDsgaSA8IHNpemVvZih0ZXN0X3BhdHRlcm4pL3NpemVvZih1MzIpOyBpKyspIHsNCisJCWZvciAo aiA9IDA7IGogPCBsZW47IGogKz0gNCkgew0KKwkJCXUzMiB2YWw7DQorDQorCQkJdGczX3dyaXRl X21lbSh0cCwgb2Zmc2V0ICsgaiwgdGVzdF9wYXR0ZXJuW2ldKTsNCisJCQl0ZzNfcmVhZF9tZW0o dHAsIG9mZnNldCArIGosICZ2YWwpOw0KKwkJCWlmICh2YWwgIT0gdGVzdF9wYXR0ZXJuW2ldKQ0K KwkJCQlyZXR1cm4gLUVJTzsNCisJCX0NCisJfQ0KKwlyZXR1cm4gMDsNCit9DQorDQorc3RhdGlj IGludCB0ZzNfdGVzdF9tZW1vcnkoc3RydWN0IHRnMyAqdHApDQorew0KKwlzdGF0aWMgc3RydWN0 IG1lbV9lbnRyeSB7DQorCQl1MzIgb2Zmc2V0Ow0KKwkJdTMyIGxlbjsNCisJfSBtZW1fdGJsXzU3 MHhbXSA9IHsNCisJCXsgMHgwMDAwMDAwMCwgMHgwMTAwMH0sDQorCQl7IDB4MDAwMDIwMDAsIDB4 MWMwMDB9LA0KKwkJeyAweGZmZmZmZmZmLCAweDAwMDAwfQ0KKwl9LCBtZW1fdGJsXzU3MDVbXSA9 IHsNCisJCXsgMHgwMDAwMDEwMCwgMHgwMDAwY30sDQorCQl7IDB4MDAwMDAyMDAsIDB4MDAwMDh9 LA0KKwkJeyAweDAwMDAwYjUwLCAweDAwNDAwfSwNCisJCXsgMHgwMDAwNDAwMCwgMHgwMDgwMH0s DQorCQl7IDB4MDAwMDYwMDAsIDB4MDEwMDB9LA0KKwkJeyAweDAwMDA4MDAwLCAweDAyMDAwfSwN CisJCXsgMHgwMDAxMDAwMCwgMHgwZTAwMH0sDQorCQl7IDB4ZmZmZmZmZmYsIDB4MDAwMDB9DQor CX07DQorCXN0cnVjdCBtZW1fZW50cnkgKm1lbV90Ymw7DQorCWludCBlcnIgPSAwOw0KKwlpbnQg aTsNCisNCisJaWYgKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfNTcwNV9QTFVTKQ0KKwkJbWVt X3RibCA9IG1lbV90YmxfNTcwNTsNCisJZWxzZQ0KKwkJbWVtX3RibCA9IG1lbV90YmxfNTcweDsN CisNCisJZm9yIChpID0gMDsgbWVtX3RibFtpXS5vZmZzZXQgIT0gMHhmZmZmZmZmZjsgaSsrKSB7 DQorCQlpZiAoKGVyciA9IHRnM19kb19tZW1fdGVzdCh0cCwgbWVtX3RibFtpXS5vZmZzZXQsDQor CQkgICAgbWVtX3RibFtpXS5sZW4pKSAhPSAwKQ0KKwkJCWJyZWFrOw0KKwl9DQorCQ0KKwlyZXR1 cm4gZXJyOw0KK30NCisNCiBzdGF0aWMgdm9pZCB0ZzNfc2VsZl90ZXN0KHN0cnVjdCBuZXRfZGV2 aWNlICpkZXYsIHN0cnVjdCBldGh0b29sX3Rlc3QgKmV0ZXN0LA0KIAkJCSAgdTY0ICpkYXRhKQ0K IHsNCkBAIC03NTUzLDYgKzc2MDksMTAgQEANCiAJCQlldGVzdC0+ZmxhZ3MgfD0gRVRIX1RFU1Rf RkxfRkFJTEVEOw0KIAkJCWRhdGFbMl0gPSAxOw0KIAkJfQ0KKwkJaWYgKHRnM190ZXN0X21lbW9y eSh0cCkgIT0gMCkgew0KKwkJCWV0ZXN0LT5mbGFncyB8PSBFVEhfVEVTVF9GTF9GQUlMRUQ7DQor CQkJZGF0YVszXSA9IDE7DQorCQl9DQogDQogCQl0ZzNfaGFsdCh0cCwgUkVTRVRfS0lORF9TSFVU RE9XTiwgMSk7DQogCQlpZiAobmV0aWZfcnVubmluZyhkZXYpKSB7DQo= --=-Qaxjim3ius6F+HrSKR0b-- From mchan@broadcom.com Thu May 26 11:57:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:58:00 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIvsXq006976 for ; Thu, 26 May 2005 11:57:55 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:56:44 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:56:43 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO56898; Thu, 26 May 2005 11:56:43 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA27588; Thu, 26 May 2005 11:56:43 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:56:42 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 10:59:06 -0700 Subject: [PATCH 2.6.12-rc5 7/9] tg3: Add loopback test From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1117128795.3744.22.camel@rh4> References: <1117128795.3744.22.camel@rh4> Date: Thu, 26 May 2005 10:59:06 -0700 Message-ID: <1117130346.3744.59.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88C4662U42361923-01-01 Content-Type: multipart/mixed; boundary="=-P5yCdBPMUvA8vMQ84ek5" X-archive-position: 1686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 5064 Lines: 83 --=-P5yCdBPMUvA8vMQ84ek5 Content-Type: text/plain Content-Transfer-Encoding: 7bit The test will loopback one packet in MAC loopback mode and verify the packet data. Signed-off-by: Michael Chan --=-P5yCdBPMUvA8vMQ84ek5 Content-Disposition: attachment; filename=tg3-d7.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-d7.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGQ2L2RyaXZlcnMvbmV0L3RnMy5jIGQ3L2RyaXZlcnMvbmV0L3RnMy5jDQotLS0g ZDYvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yNSAxMjo1OTozMS4wMDAwMDAwMDAgLTA3MDAN CisrKyBkNy9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTA1LTI1IDEyOjU5OjM4LjAwMDAwMDAwMCAt MDcwMA0KQEAgLTc1NzYsNiArNzU3NiwxMTcgQEANCiAJcmV0dXJuIGVycjsNCiB9DQogDQorc3Rh dGljIGludCB0ZzNfdGVzdF9sb29wYmFjayhzdHJ1Y3QgdGczICp0cCkNCit7DQorCXUzMiBtYWNf bW9kZSwgc2VuZF9pZHgsIHJ4X3N0YXJ0X2lkeCwgcnhfaWR4LCB0eF9pZHgsIG9wYXF1ZV9rZXk7 DQorCXUzMiBkZXNjX2lkeDsNCisJc3RydWN0IHNrX2J1ZmYgKnNrYiwgKnJ4X3NrYjsNCisJdTgg KnR4X2RhdGE7DQorCWRtYV9hZGRyX3QgbWFwOw0KKwlpbnQgbnVtX3BrdHMsIHR4X2xlbiwgcnhf bGVuLCBpLCBlcnI7DQorCXN0cnVjdCB0ZzNfcnhfYnVmZmVyX2Rlc2MgKmRlc2M7DQorDQorCWlm ICghbmV0aWZfcnVubmluZyh0cC0+ZGV2KSkNCisJCXJldHVybiAtRU5PREVWOw0KKw0KKwllcnIg PSAtRUlPOw0KKw0KKwl0ZzNfYWJvcnRfaHcodHAsIDEpOw0KKw0KKwkvKiBDbGVhcmluZyB0aGlz IGZsYWcgdG8ga2VlcCBpbnRlcnJ1cHRzIGRpc2FibGVkICovDQorCXRwLT50ZzNfZmxhZ3MgJj0g flRHM19GTEFHX0lOSVRfQ09NUExFVEU7DQorCXRnM19yZXNldF9odyh0cCk7DQorDQorCW1hY19t b2RlID0gKHRwLT5tYWNfbW9kZSAmIH5NQUNfTU9ERV9QT1JUX01PREVfTUFTSykgfA0KKwkJICAg TUFDX01PREVfUE9SVF9JTlRfTFBCQUNLIHwgTUFDX01PREVfTElOS19QT0xBUklUWSB8DQorCQkg ICBNQUNfTU9ERV9QT1JUX01PREVfR01JSTsNCisJdHczMihNQUNfTU9ERSwgbWFjX21vZGUpOw0K Kw0KKwl0eF9sZW4gPSAxNTE0Ow0KKwlza2IgPSBkZXZfYWxsb2Nfc2tiKHR4X2xlbik7DQorCXR4 X2RhdGEgPSBza2JfcHV0KHNrYiwgdHhfbGVuKTsNCisJbWVtY3B5KHR4X2RhdGEsIHRwLT5kZXYt PmRldl9hZGRyLCA2KTsNCisJbWVtc2V0KHR4X2RhdGEgKyA2LCAweDAsIDgpOw0KKw0KKwl0dzMy KE1BQ19SWF9NVFVfU0laRSwgdHhfbGVuICsgNCk7DQorDQorCWZvciAoaSA9IDE0OyBpIDwgdHhf bGVuOyBpKyspDQorCQl0eF9kYXRhW2ldID0gKHU4KSAoaSAmIDB4ZmYpOw0KKw0KKwltYXAgPSBw Y2lfbWFwX3NpbmdsZSh0cC0+cGRldiwgc2tiLT5kYXRhLCB0eF9sZW4sIFBDSV9ETUFfVE9ERVZJ Q0UpOw0KKw0KKwl0dzMyX2YoSE9TVENDX01PREUsIHRwLT5jb2FsZXNjZV9tb2RlIHwgSE9TVEND X01PREVfRU5BQkxFIHwNCisJICAgICBIT1NUQ0NfTU9ERV9OT1cpOw0KKw0KKwl1ZGVsYXkoMTAp Ow0KKw0KKwlyeF9zdGFydF9pZHggPSB0cC0+aHdfc3RhdHVzLT5pZHhbMF0ucnhfcHJvZHVjZXI7 DQorDQorCXNlbmRfaWR4ID0gMDsNCisJbnVtX3BrdHMgPSAwOw0KKw0KKwl0ZzNfc2V0X3R4ZCh0 cCwgc2VuZF9pZHgsIG1hcCwgdHhfbGVuLCAwLCAxKTsNCisNCisJc2VuZF9pZHgrKzsNCisJbnVt X3BrdHMrKzsNCisNCisJdHczMl90eF9tYm94KE1BSUxCT1hfU05ESE9TVF9QUk9EX0lEWF8wICsg VEczXzY0QklUX1JFR19MT1csIHNlbmRfaWR4KTsNCisJdHIzMihNQUlMQk9YX1NOREhPU1RfUFJP RF9JRFhfMCArIFRHM182NEJJVF9SRUdfTE9XKTsNCisNCisJdWRlbGF5KDEwKTsNCisNCisJZm9y IChpID0gMDsgaSA8IDEwOyBpKyspIHsNCisJCXR3MzJfZihIT1NUQ0NfTU9ERSwgdHAtPmNvYWxl c2NlX21vZGUgfCBIT1NUQ0NfTU9ERV9FTkFCTEUgfA0KKwkJICAgICAgIEhPU1RDQ19NT0RFX05P Vyk7DQorDQorCQl1ZGVsYXkoMTApOw0KKw0KKwkJdHhfaWR4ID0gdHAtPmh3X3N0YXR1cy0+aWR4 WzBdLnR4X2NvbnN1bWVyOw0KKwkJcnhfaWR4ID0gdHAtPmh3X3N0YXR1cy0+aWR4WzBdLnJ4X3By b2R1Y2VyOw0KKwkJaWYgKCh0eF9pZHggPT0gc2VuZF9pZHgpICYmDQorCQkgICAgKHJ4X2lkeCA9 PSAocnhfc3RhcnRfaWR4ICsgbnVtX3BrdHMpKSkNCisJCQlicmVhazsNCisJfQ0KKw0KKwlwY2lf dW5tYXBfc2luZ2xlKHRwLT5wZGV2LCBtYXAsIHR4X2xlbiwgUENJX0RNQV9UT0RFVklDRSk7DQor CWRldl9rZnJlZV9za2Ioc2tiKTsNCisNCisJaWYgKHR4X2lkeCAhPSBzZW5kX2lkeCkNCisJCWdv dG8gb3V0Ow0KKw0KKwlpZiAocnhfaWR4ICE9IHJ4X3N0YXJ0X2lkeCArIG51bV9wa3RzKQ0KKwkJ Z290byBvdXQ7DQorDQorCWRlc2MgPSAmdHAtPnJ4X3JjYltyeF9zdGFydF9pZHhdOw0KKwlkZXNj X2lkeCA9IGRlc2MtPm9wYXF1ZSAmIFJYRF9PUEFRVUVfSU5ERVhfTUFTSzsNCisJb3BhcXVlX2tl eSA9IGRlc2MtPm9wYXF1ZSAmIFJYRF9PUEFRVUVfUklOR19NQVNLOw0KKwlpZiAob3BhcXVlX2tl eSAhPSBSWERfT1BBUVVFX1JJTkdfU1REKQ0KKwkJZ290byBvdXQ7DQorDQorCWlmICgoZGVzYy0+ ZXJyX3ZsYW4gJiBSWERfRVJSX01BU0spICE9IDAgJiYNCisJICAgIChkZXNjLT5lcnJfdmxhbiAh PSBSWERfRVJSX09ERF9OSUJCTEVfUkNWRF9NSUkpKQ0KKwkJZ290byBvdXQ7DQorDQorCXJ4X2xl biA9ICgoZGVzYy0+aWR4X2xlbiAmIFJYRF9MRU5fTUFTSykgPj4gUlhEX0xFTl9TSElGVCkgLSA0 Ow0KKwlpZiAocnhfbGVuICE9IHR4X2xlbikNCisJCWdvdG8gb3V0Ow0KKw0KKwlyeF9za2IgPSB0 cC0+cnhfc3RkX2J1ZmZlcnNbZGVzY19pZHhdLnNrYjsNCisNCisJbWFwID0gcGNpX3VubWFwX2Fk ZHIoJnRwLT5yeF9zdGRfYnVmZmVyc1tkZXNjX2lkeF0sIG1hcHBpbmcpOw0KKwlwY2lfZG1hX3N5 bmNfc2luZ2xlX2Zvcl9jcHUodHAtPnBkZXYsIG1hcCwgcnhfbGVuLCBQQ0lfRE1BX0ZST01ERVZJ Q0UpOw0KKw0KKwlmb3IgKGkgPSAxNDsgaSA8IHR4X2xlbjsgaSsrKSB7DQorCQlpZiAoKihyeF9z a2ItPmRhdGEgKyBpKSAhPSAodTgpIChpICYgMHhmZikpDQorCQkJZ290byBvdXQ7DQorCX0NCisJ ZXJyID0gMDsNCisJDQorCS8qIHRnM19mcmVlX3JpbmdzIHdpbGwgdW5tYXAgYW5kIGZyZWUgdGhl IHJ4X3NrYiAqLw0KK291dDoNCisJcmV0dXJuIGVycjsNCit9DQorDQogc3RhdGljIHZvaWQgdGcz X3NlbGZfdGVzdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgZXRodG9vbF90ZXN0ICpl dGVzdCwNCiAJCQkgIHU2NCAqZGF0YSkNCiB7DQpAQCAtNzYxMyw2ICs3NzI0LDEwIEBADQogCQkJ ZXRlc3QtPmZsYWdzIHw9IEVUSF9URVNUX0ZMX0ZBSUxFRDsNCiAJCQlkYXRhWzNdID0gMTsNCiAJ CX0NCisJCWlmICh0ZzNfdGVzdF9sb29wYmFjayh0cCkgIT0gMCkgew0KKwkJCWV0ZXN0LT5mbGFn cyB8PSBFVEhfVEVTVF9GTF9GQUlMRUQ7DQorCQkJZGF0YVs0XSA9IDE7DQorCQl9DQogDQogCQl0 ZzNfaGFsdCh0cCwgUkVTRVRfS0lORF9TSFVURE9XTiwgMSk7DQogCQlpZiAobmV0aWZfcnVubmlu ZyhkZXYpKSB7DQo= --=-P5yCdBPMUvA8vMQ84ek5-- From mchan@broadcom.com Thu May 26 11:58:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:58:12 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIvYXr006448 for ; Thu, 26 May 2005 11:58:05 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:57:08 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:57:06 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO56973; Thu, 26 May 2005 11:57:06 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA27671; Thu, 26 May 2005 11:57:06 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:57:05 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 10:59:29 -0700 Subject: [PATCH 2.6.12-rc5 8/9] tg3: Add interrupt test From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1117128795.3744.22.camel@rh4> References: <1117128795.3744.22.camel@rh4> Date: Thu, 26 May 2005 10:59:29 -0700 Message-ID: <1117130369.3744.60.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88C38E1VO2252564-01-01 Content-Type: multipart/mixed; boundary="=-xExx4ZEVLFBGOZNm0WqK" X-archive-position: 1687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1436 Lines: 36 --=-xExx4ZEVLFBGOZNm0WqK Content-Type: text/plain Content-Transfer-Encoding: 7bit This test uses the previously added tg3_test_interrupt() to perform the test. Signed-off-by: Michael Chan --=-xExx4ZEVLFBGOZNm0WqK Content-Disposition: attachment; filename=tg3-d8.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-d8.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGQ3L2RyaXZlcnMvbmV0L3RnMy5jIGQ4L2RyaXZlcnMvbmV0L3RnMy5jDQotLS0g ZDcvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yNSAxMjo1OTozOC4wMDAwMDAwMDAgLTA3MDAN CisrKyBkOC9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTA1LTI1IDEyOjU5OjQ2LjAwMDAwMDAwMCAt MDcwMA0KQEAgLTU4OTQsNiArNTg5NCw5IEBADQogCWludCBlcnIsIGk7DQogCXUzMiBpbnRfbWJv eCA9IDA7DQogDQorCWlmICghbmV0aWZfcnVubmluZyhkZXYpKQ0KKwkJcmV0dXJuIC1FTk9ERVY7 DQorDQogCXRnM19kaXNhYmxlX2ludHModHApOw0KIA0KIAlmcmVlX2lycSh0cC0+cGRldi0+aXJx LCBkZXYpOw0KQEAgLTc3MjksNiArNzczMiwxNSBAQA0KIAkJCWRhdGFbNF0gPSAxOw0KIAkJfQ0K IA0KKwkJc3Bpbl91bmxvY2soJnRwLT50eF9sb2NrKTsNCisJCXNwaW5fdW5sb2NrX2lycSgmdHAt PmxvY2spOw0KKwkJaWYgKHRnM190ZXN0X2ludGVycnVwdCh0cCkgIT0gMCkgew0KKwkJCWV0ZXN0 LT5mbGFncyB8PSBFVEhfVEVTVF9GTF9GQUlMRUQ7DQorCQkJZGF0YVs1XSA9IDE7DQorCQl9DQor CQlzcGluX2xvY2tfaXJxKCZ0cC0+bG9jayk7DQorCQlzcGluX2xvY2soJnRwLT50eF9sb2NrKTsN CisNCiAJCXRnM19oYWx0KHRwLCBSRVNFVF9LSU5EX1NIVVRET1dOLCAxKTsNCiAJCWlmIChuZXRp Zl9ydW5uaW5nKGRldikpIHsNCiAJCQl0cC0+dGczX2ZsYWdzIHw9IFRHM19GTEFHX0lOSVRfQ09N UExFVEU7DQo= --=-xExx4ZEVLFBGOZNm0WqK-- From mchan@broadcom.com Thu May 26 11:58:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 11:59:05 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QIwuXq008540 for ; Thu, 26 May 2005 11:58:57 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 26 May 2005 11:57:57 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 26 May 2005 11:57:56 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAO57145; Thu, 26 May 2005 11:57:48 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA27931; Thu, 26 May 2005 11:57:48 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 18:57:47 +0000 Received: from rh4 by nt-irva-0741; 26 May 2005 11:00:11 -0700 Subject: [PATCH 2.6.12-rc5 9/9] tg3: Fix bug in tg3_load_firmware_cpu From: "Michael Chan" To: davem@davemloft.net cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <1117128795.3744.22.camel@rh4> References: <1117128795.3744.22.camel@rh4> Date: Thu, 26 May 2005 11:00:11 -0700 Message-ID: <1117130411.3744.61.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E88C3BF2U42362171-01-01 Content-Type: multipart/mixed; boundary="=-AMuu51w9sS0rynMEQ8qb" X-archive-position: 1688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1350 Lines: 34 --=-AMuu51w9sS0rynMEQ8qb Content-Type: text/plain Content-Transfer-Encoding: 7bit Add tg3_nvram_lock() and tg3_nvram_unlock() calls around tg3_halt_cpu(). It is possible that the bootcode may be loading code from nvram during this call and stopping the cpu without getting the lock may cause uncompleted nvram data to be left in the nvram data register. Subsequent calls to read/write nvram data will fail. Signed-off-by: Michael Chan --=-AMuu51w9sS0rynMEQ8qb Content-Disposition: attachment; filename=tg3-d9.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-d9.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IGQ4L2RyaXZlcnMvbmV0L3RnMy5jIGQ5L2RyaXZlcnMvbmV0L3RnMy5jDQotLS0g ZDgvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNS0yNSAxMjo1OTo0Ni4wMDAwMDAwMDAgLTA3MDAN CisrKyBkOS9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTA1LTI1IDEyOjU5OjU1LjAwMDAwMDAwMCAt MDcwMA0KQEAgLTQzNzAsNyArNDM3MCwxMiBAQA0KIAkgKi8NCiAJdHAtPnRnM19mbGFncyB8PSBU RzNfRkxBR19QQ0lYX1RBUkdFVF9IV0JVRzsNCiANCisJLyogSXQgaXMgcG9zc2libGUgdGhhdCBi b290Y29kZSBpcyBzdGlsbCBsb2FkaW5nIGF0IHRoaXMgcG9pbnQuDQorCSAqIEdldCB0aGUgbnZy YW0gbG9jayBmaXJzdCBiZWZvcmUgaGFsdGluZyB0aGUgY3B1Lg0KKwkgKi8NCisJdGczX252cmFt X2xvY2sodHApOw0KIAllcnIgPSB0ZzNfaGFsdF9jcHUodHAsIGNwdV9iYXNlKTsNCisJdGczX252 cmFtX3VubG9jayh0cCk7DQogCWlmIChlcnIpDQogCQlnb3RvIG91dDsNCiANCg== --=-AMuu51w9sS0rynMEQ8qb-- From tgraf@suug.ch Thu May 26 12:01:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 12:01:25 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QJ1MXq009745 for ; Thu, 26 May 2005 12:01:22 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id EB81D1C0EB; Thu, 26 May 2005 21:00:55 +0200 (CEST) Date: Thu, 26 May 2005 21:00:55 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [NEIGH] Remove unused fields in struct neigh_parms and neigh_table Message-ID: <20050526190055.GB15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185556.GA15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526185556.GA15391@postel.suug.ch> X-archive-position: 1689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 556 Lines: 13 * Thomas Graf <20050526185556.GA15391@postel.suug.ch> 2005-05-26 20:55 > > Signed-off-by: Thomas Graf > > --- > commit 45b866033b439e510f3638ce9ac0990446b8b3cd > tree 72baef0bb9b97ac2990bcca05b8f831b30303008 > parent 3688d656f38445cc120b0970cd437cad1bb929dd > author Thomas Graf Thu, 26 May 2005 20:42:10 +0200 > committer Thomas Graf Thu, 26 May 2005 20:42:10 +0200 This is patch 4 if it's not clear. I took the wrong patch and my script couldn't find the parent sha1 and ommited the [PATCH 4/4]. Sorry. From jgarzik@pobox.com Thu May 26 12:10:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 12:10:13 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QJA8Xq010428 for ; Thu, 26 May 2005 12:10:10 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DbNjL-000308-C2 for netdev@oss.sgi.com; Thu, 26 May 2005 19:09:20 +0000 Message-ID: <42961EDB.7000407@pobox.com> Date: Thu, 26 May 2005 15:09:15 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: [NET] 2.6.x build warning Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1690 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 211 Lines: 8 from current git tree: net/ipv6/ip6_flowlabel.c: In function `ipv6_flowlabel_opt': net/ipv6/ip6_flowlabel.c:540: warning: ignoring return value of `copy_to_user', declared with attribute warn_unused_result From jgarzik@pobox.com Thu May 26 12:14:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 12:14:41 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QJEcXq011014 for ; Thu, 26 May 2005 12:14:38 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DbNnh-00030G-6r; Thu, 26 May 2005 19:13:49 +0000 Message-ID: <42961FEB.801@pobox.com> Date: Thu, 26 May 2005 15:13:47 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc5 9/9] tg3: Fix bug in tg3_load_firmware_cpu References: <1117128795.3744.22.camel@rh4> <1117130411.3744.61.camel@rh4> In-Reply-To: <1117130411.3744.61.camel@rh4> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 798 Lines: 24 Michael Chan wrote: > Add tg3_nvram_lock() and tg3_nvram_unlock() calls around tg3_halt_cpu(). > It is possible that the bootcode may be loading code from nvram during > this call and stopping the cpu without getting the lock may cause > uncompleted nvram data to be left in the nvram data register. Subsequent > calls to read/write nvram data will fail. > > Signed-off-by: Michael Chan All the patches seem sane to me. To touch a bit on patch order, I would suggest ordering bug fixes before feature patches. Your patch #9 could have been better ordered as patch #1. The patch order did not matter today, but sometime in the future, if an add-a-feature patch is rejected or delayed, you would still likely want DaveM to apply other bugfix patches. Regards, Jeff From shemminger@osdl.org Thu May 26 12:48:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 12:48:58 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QJmpXq016377 for ; Thu, 26 May 2005 12:48:52 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4QJlQjA028487 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 May 2005 12:47:26 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4QJlOZg009211; Thu, 26 May 2005 12:47:26 -0700 Date: Thu, 26 May 2005 12:47:24 -0700 From: Stephen Hemminger To: raz ben jehuda Cc: netdev@oss.sgi.com Subject: Re: user space checksum Message-ID: <20050526124724.57e9bafa@dxpl.pdx.osdl.net> In-Reply-To: <1116744708.3021.12.camel@raz-laptop> References: <1116744708.3021.12.camel@raz-laptop> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 952 Lines: 21 On Sun, 22 May 2005 09:51:48 +0300 raz ben jehuda wrote: > I do not know if this was ever suggested.so i'll try any way. > Why not give the user the chance to supply the kernel/card with the > checksums instead of having the kernel/network card do the work ? A bad idea for two reasons: * application data units (APDU) do not match transport data units for a stream oriented protocol. * computing checksum is done for almost nothing as part of the copy from user to kernel space. Modern CPU cache's make computation cost << memory access cost. > This is because a user is aware to the data he sends and he can optimize > the data checksum calculations more than anyone else. for instance a web > server sends its html pages, which are static data. it can pre-calculate > the checksums. Tcp will compute different transfer size's based on the congestion window of the connection, and header part will be different. From akpm@osdl.org Thu May 26 13:33:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 13:33:46 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QKXgXq017985 for ; Thu, 26 May 2005 13:33:42 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4QKWEjA000323 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 May 2005 13:32:15 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4QKWBUB011570; Thu, 26 May 2005 13:32:12 -0700 Date: Thu, 26 May 2005 13:31:23 -0700 From: Andrew Morton To: Jian Jun He Cc: ganesh.venkatesan@intel.com, anton@samba.org, rende@cn.ibm.com, ganesh.venkatesan@gmail.com, herbert@gondor.apana.org.au, jesse.brandeburg@intel.com, jgarzik@pobox.com, wangjs@cn.ibm.com, john.ronciak@intel.com, cdlwangl@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-Id: <20050526133123.47824405.akpm@osdl.org> In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07E056B8C25@orsmsx408> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1485 Lines: 56 Jian Jun He wrote: > > 2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and install > it on > the test machine. > 3. Configure and run the rhr test via invoking redhat-ready. This is the problematic bit. - Please provide a full URL which can be used to obtain rhr. rhn.redhat.com is subscription-based. - Please describe the hardware setup - surely the test requires at least two machines. How are they configured? - Provide an exact transcript of the commands which are to be used. Is it just redhat-ready with no arguments? All that begin said, we already have a quite specific diagnosis via code inspection, from Herbert: Herbert Xu wrote: > > Andrew Morton wrote: > > > > Might be a bug in the e100 driver, might not be. > > > > I assume this is the > > > > BUG_ON(skb->list != NULL); > > It certainly is a bug in e100. > > e100_tx_timeout -> e100_down -> e100_rx_clean_list > > is racing against > > e100_poll -> e100_rx_clean -> e100_rx_indicate > > e100_rx_clean/e100_rx_indicate takes an skb off the RX ring and > while it's being processed e100_rx_clean_list comes along and > frees it. > > From a quick check similar problems may exist in other drivers that > have lockless ->poll() functions with RX rings. Do the e100 maintainers agree with this diagnosis? If so then more testing isn't required at this stage - the next step is to fix the above bug, no? From davem@davemloft.net Thu May 26 13:39:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 13:39:19 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QKdDXq018537 for ; Thu, 26 May 2005 13:39:13 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbP7P-0007Ie-B3; Thu, 26 May 2005 13:38:15 -0700 Date: Thu, 26 May 2005 13:38:15 -0700 (PDT) Message-Id: <20050526.133815.62342715.davem@davemloft.net> To: Robert.Olsson@data.slu.se Cc: netdev@oss.sgi.com Subject: Re: LC-trie FIB major rework From: "David S. Miller" In-Reply-To: <17045.56331.653873.256686@robur.slu.se> References: <17045.56331.653873.256686@robur.slu.se> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 880 Lines: 17 From: Robert Olsson Date: Thu, 26 May 2005 16:24:11 +0200 > Below much reworked version of the LC-trie for FIB lookup's. Much closer > to current FIB anatomy and locking. Parent pointers in the trie to avoid > own stacks etc. The option to merge tables has been removed and much things > to keep things as simple and clean as possible. Although it's somewhat > complex. > > Performance. We now perform about 25-30% better than current FIB in > heavy lookup situations (we test with full rDoS) The test below illustrates > this 123 kroutes in the routing table and rDoS is injected into eth0 at > 720 kpps routed traffic on eth1/eth3. route hash is not used and both > dst and src are looked up. LC-trie should work fine any size of routing table.. Very nice work Robert. Once TSO becomes less of a time sink I intend to help you out a bit. From ganesh.venkatesan@intel.com Thu May 26 13:43:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 13:43:35 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QKhVXq019229 for ; Thu, 26 May 2005 13:43:31 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4QKfuQQ002752; Thu, 26 May 2005 20:41:56 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4QKeQjQ026361; Thu, 26 May 2005 20:41:55 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052613415512105 ; Thu, 26 May 2005 13:41:55 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 13:41:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Date: Thu, 26 May 2005 13:41:53 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E056F6B37@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Thread-Index: AcViMig1KCQsma4eQ5CKxhlgMWr2RQAAJVPw From: "Venkatesan, Ganesh" To: "Andrew Morton" , "Jian Jun He" Cc: , , , , "Brandeburg, Jesse" , , , "Ronciak, John" , , , X-OriginalArrivalTime: 26 May 2005 20:41:55.0590 (UTC) FILETIME=[5AC8F260:01C56233] X-Scanned-By: MIMEDefang 2.44 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4QKhVXq019229 X-archive-position: 1695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2553 Lines: 88 Andrew: I already responded to this analysis before. In any case, here it is: Later versions of e100 (3.4.8 for instance) includes a call to netif_poll_disable in e100_down. This is supposed to wait and when it returns we are guaranteed that e100_poll will no longer be called. In addition, if there happens to be an interrupt, our call to netif_rx_schedule() will not add our poll routine to the poll-list since poll is disabled. So this race can never happen. Ganesh. >-----Original Message----- >From: Andrew Morton [mailto:akpm@osdl.org] >Sent: Thursday, May 26, 2005 1:31 PM >To: Jian Jun He >Cc: Venkatesan, Ganesh; anton@samba.org; rende@cn.ibm.com; >ganesh.venkatesan@gmail.com; herbert@gondor.apana.org.au; Brandeburg, >Jesse; jgarzik@pobox.com; wangjs@cn.ibm.com; Ronciak, John; >cdlwangl@cn.ibm.com; linuxppc64-dev@lists.linuxppc.org.sgi.com; >netdev@oss.sgi.com >Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running >rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 > >Jian Jun He wrote: >> >> 2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and >install >> it on >> the test machine. >> 3. Configure and run the rhr test via invoking redhat-ready. > >This is the problematic bit. > >- Please provide a full URL which can be used to obtain rhr. > rhn.redhat.com is subscription-based. > >- Please describe the hardware setup - surely the test requires at least > two machines. How are they configured? > >- Provide an exact transcript of the commands which are to be used. Is > it just > > redhat-ready > > with no arguments? > > > >All that begin said, we already have a quite specific diagnosis via code >inspection, from Herbert: > > >Herbert Xu wrote: >> >> Andrew Morton wrote: >> > >> > Might be a bug in the e100 driver, might not be. >> > >> > I assume this is the >> > >> > BUG_ON(skb->list != NULL); >> >> It certainly is a bug in e100. >> >> e100_tx_timeout -> e100_down -> e100_rx_clean_list >> >> is racing against >> >> e100_poll -> e100_rx_clean -> e100_rx_indicate >> >> e100_rx_clean/e100_rx_indicate takes an skb off the RX ring and >> while it's being processed e100_rx_clean_list comes along and >> frees it. >> >> From a quick check similar problems may exist in other drivers that >> have lockless ->poll() functions with RX rings. > >Do the e100 maintainers agree with this diagnosis? If so then more testing >isn't required at this stage - the next step is to fix the above bug, no? From davem@davemloft.net Thu May 26 13:53:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 13:53:28 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QKrNXq019930 for ; Thu, 26 May 2005 13:53:23 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbPLB-0003MZ-E7; Thu, 26 May 2005 13:52:29 -0700 Date: Thu, 26 May 2005 13:52:29 -0700 (PDT) Message-Id: <20050526.135229.111208218.davem@davemloft.net> To: laforge@netfilter.org Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path From: "David S. Miller" In-Reply-To: <20050526142420.GD13114@sunbeam.de.gnumonks.org> References: <20050526142420.GD13114@sunbeam.de.gnumonks.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 274 Lines: 8 From: Harald Welte Date: Thu, 26 May 2005 16:24:21 +0200 > Dave: Please don't apply yet, I want to receive feedback from the > netfilter developers first. I'm just Cc'ing netdev in case somebody > wants an intermediate fix to fix the problem. OK. From laforge@netfilter.org Thu May 26 13:59:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 13:59:27 -0700 (PDT) Received: from ganesha.gnumonks.org (ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QKxMXq020772 for ; Thu, 26 May 2005 13:59:23 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1DbPR4-0003fd-63; Thu, 26 May 2005 22:58:34 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DbPR2-0008Rw-1D; Thu, 26 May 2005 22:58:32 +0200 Date: Thu, 26 May 2005 22:58:31 +0200 From: Harald Welte To: "David S. Miller" Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path Message-ID: <20050526205831.GL13114@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , "David S. Miller" , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com References: <20050526142420.GD13114@sunbeam.de.gnumonks.org> <20050526.135229.111208218.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm9/qCh+74CdNMXJ" Content-Disposition: inline In-Reply-To: <20050526.135229.111208218.davem@davemloft.net> User-Agent: mutt-ng 1.5.8-r168i (Debian) X-archive-position: 1697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1514 Lines: 46 --sm9/qCh+74CdNMXJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 26, 2005 at 01:52:29PM -0700, David S. Miller wrote: =20 > > Dave: Please don't apply yet, I want to receive feedback from the > > netfilter developers first. I'm just Cc'ing netdev in case somebody > > wants an intermediate fix to fix the problem. >=20 > OK. Do you have any feedback on why or how bh_lock_sock() might be called in the problem I've described? I think it has to be a different skb for the same socket. Is my general line of thought correct that we shouldn't traverse the local input path from sysirq context ? Thanks. --=20 - Harald Welte http://netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --sm9/qCh+74CdNMXJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCljh3XaXGVTD0i/8RAmsoAJ9KCcdyOkOZsYLoLgIRG0tKJheAGwCeJ2/U GMGN0Ik72ChVZKZIiR7igxE= =y61k -----END PGP SIGNATURE----- --sm9/qCh+74CdNMXJ-- From davem@davemloft.net Thu May 26 14:02:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 14:02:53 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QL2pXq021418 for ; Thu, 26 May 2005 14:02:51 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbPUM-0000aj-6C; Thu, 26 May 2005 14:01:58 -0700 Date: Thu, 26 May 2005 14:01:57 -0700 (PDT) Message-Id: <20050526.140157.74747743.davem@davemloft.net> To: laforge@netfilter.org Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path From: "David S. Miller" In-Reply-To: <20050526205831.GL13114@sunbeam.de.gnumonks.org> References: <20050526142420.GD13114@sunbeam.de.gnumonks.org> <20050526.135229.111208218.davem@davemloft.net> <20050526205831.GL13114@sunbeam.de.gnumonks.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 861 Lines: 21 From: Harald Welte Subject: Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path Date: Thu, 26 May 2005 22:58:31 +0200 > On Thu, May 26, 2005 at 01:52:29PM -0700, David S. Miller wrote: > > > > Dave: Please don't apply yet, I want to receive feedback from the > > > netfilter developers first. I'm just Cc'ing netdev in case somebody > > > wants an intermediate fix to fix the problem. > > > > OK. > > Do you have any feedback on why or how bh_lock_sock() might be called in > the problem I've described? I think it has to be a different skb for > the same socket. When we hit a listening socket, and hung off of that listening socket we find a child socket, we bh_lock_sock() the child socket then process the SKB against it instead of the listening socket. Is this the kind of scenerio you are concerned about? From herbert@gondor.apana.org.au Thu May 26 14:35:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 14:36:01 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QLZsXq022771 for ; Thu, 26 May 2005 14:35:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DbPzv-0003SM-00; Fri, 27 May 2005 07:34:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DbPzh-00026Z-00; Fri, 27 May 2005 07:34:21 +1000 Date: Fri, 27 May 2005 07:34:21 +1000 To: "Venkatesan, Ganesh" Cc: Andrew Morton , Jian Jun He , anton@samba.org, rende@cn.ibm.com, ganesh.venkatesan@gmail.com, "Brandeburg, Jesse" , jgarzik@pobox.com, wangjs@cn.ibm.com, "Ronciak, John" , cdlwangl@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-ID: <20050526213421.GA8077@gondor.apana.org.au> References: <468F3FDA28AA87429AD807992E22D07E056F6B37@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <468F3FDA28AA87429AD807992E22D07E056F6B37@orsmsx408> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 679 Lines: 17 On Thu, May 26, 2005 at 01:41:53PM -0700, Venkatesan, Ganesh wrote: > > I already responded to this analysis before. In any case, here it is: > > Later versions of e100 (3.4.8 for instance) includes a call to > netif_poll_disable in e100_down. This is supposed to wait and when it As I said last time, this is broken since the code path in question starts from tx_timeout which is called in softirq context. You'll need to schedule a work struct at least. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mitch.a.williams@intel.com Thu May 26 14:37:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 14:37:14 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QLbAXq022942 for ; Thu, 26 May 2005 14:37:10 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4QLaMfu028522 for ; Thu, 26 May 2005 21:36:22 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j4QLaMOd003778 for ; Thu, 26 May 2005 21:36:22 GMT Received: from mawilli1-desk2.amr.corp.intel.com (mawilli1-desk2.amr.corp.intel.com [134.134.3.124]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j4QLaMSL014184; Thu, 26 May 2005 14:36:22 -0700 Date: Thu, 26 May 2005 14:36:22 -0700 From: Mitch Williams X-X-Sender: mawilli1@mawilli1-desk2.amr.corp.intel.com To: netdev@oss.sgi.com cc: john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: RFC: NAPI packet weighting patch Message-ID: ReplyTo: "Mitch Williams" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch.a.williams@intel.com Precedence: bulk X-list: netdev Content-Length: 5849 Lines: 146 The following patch (which applies to 2.6.12rc4) adds a new sysctl parameter called 'netdev_packet_weight'. This parameter controls how many backlog work units each RX packet is worth. With the parameter set to 0 (the default), NAPI polling works exactly as it does today: each packet is worth one backlog work unit, and the maximum number of received packets that will be processed in any given softirq is controlled by the 'netdev_max_backlog' parameter. By setting the netdev_packet_weight to a nonzero value, we make each packet worth more than one backlog work unit. Since it's a shift value, a setting of 1 makes each packet worth 2 work units, a setting of 2 makes each packet worth 4 units, etc. Under normal circumstances you would never use a value higher than 3, though 4 might work for Gigabit and 10 Gigabit networks. By increasing the packet weight, we accomplish two things: first, we cause the individual NAPI RX loops in each driver to process fewer packets. This means that they will free up RX resources to the hardware more often, which reduces the possibility of dropped packets. Second, it shortens the total time spent in the NAPI softirq, which can free the CPU to handle other tasks more often, thus reducing overall latency. Performance tests in our lab have shown that tweaking this parameter, along with the netdev_max_backlog parameter, can provide significant performance increase -- greater than 100Mbps improvement -- over default settings. I tested with both e1000 and tg3 drivers and saw improvement in both cases. I did not see higher CPU utilization, even with the increased throughput. The caveat, of course, is that different systems and network configurations require different settings. On the other hand, that's really no different than what we see with the max_backlog parameter today. On some systems neither parameter makes any difference. Still, we feel that there is value to having this in the kernel. Please test and comment as you have time available. Thanks! -Mitch Williams mitch.a.williams@intel.com diff -urpN -x dontdiff rc4-clean/Documentation/filesystems/proc.txt linux-2.6.12-rc4/Documentation/filesystems/proc.txt --- rc4-clean/Documentation/filesystems/proc.txt 2005-05-18 16:35:43.000000000 -0700 +++ linux-2.6.12-rc4/Documentation/filesystems/proc.txt 2005-05-19 11:16:10.000000000 -0700 @@ -1378,7 +1378,13 @@ netdev_max_backlog ------------------ Maximum number of packets, queued on the INPUT side, when the interface -receives packets faster than kernel can process them. +receives packets faster than kernel can process them. This is also the +maximum number of packets handled in a single softirq under NAPI. + +netdev_packet_weight +-------------------- +The value, in netdev_max_backlog unit, of each received packet. This is a +shift value, and should be set no higher than 3. optmem_max ---------- diff -urpN -x dontdiff rc4-clean/include/linux/sysctl.h linux-2.6.12-rc4/include/linux/sysctl.h --- rc4-clean/include/linux/sysctl.h 2005-05-18 16:36:06.000000000 -0700 +++ linux-2.6.12-rc4/include/linux/sysctl.h 2005-05-18 16:44:07.000000000 -0700 @@ -242,6 +242,7 @@ enum NET_CORE_MOD_CONG=16, NET_CORE_DEV_WEIGHT=17, NET_CORE_SOMAXCONN=18, + NET_CORE_PACKET_WEIGHT=19, }; /* /proc/sys/net/ethernet */ diff -urpN -x dontdiff rc4-clean/net/core/dev.c linux-2.6.12-rc4/net/core/dev.c --- rc4-clean/net/core/dev.c 2005-05-18 16:36:07.000000000 -0700 +++ linux-2.6.12-rc4/net/core/dev.c 2005-05-19 11:16:57.000000000 -0700 @@ -1352,6 +1352,7 @@ out: =======================================================================*/ int netdev_max_backlog = 300; +int netdev_packet_weight = 0; /* each packet is worth 1 backlog unit */ int weight_p = 64; /* old backlog weight */ /* These numbers are selected based on intuition and some * experimentatiom, if you have more scientific way of doing this @@ -1778,6 +1779,7 @@ static void net_rx_action(struct softirq struct softnet_data *queue = &__get_cpu_var(softnet_data); unsigned long start_time = jiffies; int budget = netdev_max_backlog; + int budget_temp; local_irq_disable(); @@ -1793,21 +1795,22 @@ static void net_rx_action(struct softirq dev = list_entry(queue->poll_list.next, struct net_device, poll_list); netpoll_poll_lock(dev); - - if (dev->quota <= 0 || dev->poll(dev, &budget)) { + budget_temp = budget; + if (dev->quota <= 0 || dev->poll(dev, &budget_temp)) { netpoll_poll_unlock(dev); local_irq_disable(); list_del(&dev->poll_list); list_add_tail(&dev->poll_list, &queue->poll_list); if (dev->quota < 0) - dev->quota += dev->weight; + dev->quota += dev->weight >> netdev_packet_weight; else - dev->quota = dev->weight; + dev->quota = dev->weight >> netdev_packet_weight; } else { netpoll_poll_unlock(dev); dev_put(dev); local_irq_disable(); } + budget -= (budget - budget_temp) << netdev_packet_weight; } out: local_irq_enable(); diff -urpN -x dontdiff rc4-clean/net/core/sysctl_net_core.c linux-2.6.12-rc4/net/core/sysctl_net_core.c --- rc4-clean/net/core/sysctl_net_core.c 2005-03-01 23:38:03.000000000 -0800 +++ linux-2.6.12-rc4/net/core/sysctl_net_core.c 2005-05-18 16:44:09.000000000 -0700 @@ -13,6 +13,7 @@ #ifdef CONFIG_SYSCTL extern int netdev_max_backlog; +extern int netdev_packet_weight; extern int weight_p; extern int no_cong_thresh; extern int no_cong; @@ -91,6 +92,14 @@ ctl_table core_table[] = { .proc_handler = &proc_dointvec }, { + .ctl_name = NET_CORE_PACKET_WEIGHT, + .procname = "netdev_packet_weight", + .data = &netdev_packet_weight, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec + }, + { .ctl_name = NET_CORE_MAX_BACKLOG, .procname = "netdev_max_backlog", .data = &netdev_max_backlog, From herbert@gondor.apana.org.au Thu May 26 14:40:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 14:40:05 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QLdxXq023885 for ; Thu, 26 May 2005 14:40:00 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DbQ4D-0003VT-00; Fri, 27 May 2005 07:39:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DbQ49-00027X-00; Fri, 27 May 2005 07:38:57 +1000 From: Herbert Xu To: laforge@netfilter.org (Harald Welte) Subject: Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, jmorris@redhat.com Organization: Core In-Reply-To: <20050526142420.GD13114@sunbeam.de.gnumonks.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 27 May 2005 07:38:57 +1000 X-archive-position: 1701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 709 Lines: 15 Harald Welte wrote: > > The patch below adds an additional queue for ip_queue verdicts. They > come up from userspace, are appended to a queue which is then processed > by a tasklet. The tasklet itself runs in softirq context, so when timer > hardirq leaves, no tcp_delack_timer() will be executed until > nf_reinject() has finished. This seems to be overly complicated if all you want is to do this in softirq context. What's wrong with simply alling local_bh_disable? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Thu May 26 14:47:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 14:47:37 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QLlXXq024518 for ; Thu, 26 May 2005 14:47:33 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbQBa-0001Ck-7I; Thu, 26 May 2005 14:46:38 -0700 Date: Thu, 26 May 2005 14:46:38 -0700 (PDT) Message-Id: <20050526.144638.71091166.davem@davemloft.net> To: shemminger@osdl.org Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (6/6) bridge: receive path optimization From: "David S. Miller" In-Reply-To: <20050526110425.27590eb8@dxpl.pdx.osdl.net> References: <20050526110425.27590eb8@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 646 Lines: 17 From: Stephen Hemminger Date: Thu, 26 May 2005 11:04:25 -0700 > This improves the bridge local receive path by avoiding going > through another softirq. The bridge receive path is already being called > from a netif_receive_skb() there is no point in going through another > receiveq round trip. > > Recursion is limited because bridge can never be a port of a bridge > so handle_bridge() always returns. I applied all 6 patches, but this one in particular I'd like to comment on. Remember all of those bridge netfilter stack usage issues we have a few months ago? This could edge us back into those problems again. From davem@davemloft.net Thu May 26 14:59:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 14:59:43 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QLxbXq025323 for ; Thu, 26 May 2005 14:59:37 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbQMh-0001G1-Lw; Thu, 26 May 2005 14:58:07 -0700 Date: Thu, 26 May 2005 14:58:07 -0700 (PDT) Message-Id: <20050526.145807.130847153.davem@davemloft.net> To: laforge@gnumonks.org Cc: hasso@estpak.ee, netdev@oss.sgi.com Subject: Re: primary and secondary ip addresses From: "David S. Miller" In-Reply-To: <20050526181118.GK13114@sunbeam.de.gnumonks.org> References: <20050412105442.GV7510@sunbeam.de.gnumonks.org> <200505081531.16106.hasso@estpak.ee> <20050526181118.GK13114@sunbeam.de.gnumonks.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 367 Lines: 9 From: Harald Welte Date: Thu, 26 May 2005 20:11:18 +0200 > David, would you consider applying that patch to mainline? I think > there was concensus on this solution, and it has now received some > amount of testing by Hasso and me. Since it retains the default behavior by default, this change seems fine. I've added it to my tree, thanks. From davem@davemloft.net Thu May 26 15:11:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 15:11:23 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QMBKXq026130 for ; Thu, 26 May 2005 15:11:21 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbQYe-0001KL-SC; Thu, 26 May 2005 15:10:28 -0700 Date: Thu, 26 May 2005 15:10:28 -0700 (PDT) Message-Id: <20050526.151028.122618599.davem@davemloft.net> To: mchan@broadcom.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc5 9/9] tg3: Fix bug in tg3_load_firmware_cpu From: "David S. Miller" In-Reply-To: <1117130411.3744.61.camel@rh4> References: <1117128795.3744.22.camel@rh4> <1117130411.3744.61.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 40 Lines: 2 All 9 patches applied, thanks Michael. From davem@davemloft.net Thu May 26 15:14:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 15:14:38 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QMEVXq026555 for ; Thu, 26 May 2005 15:14:31 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbQbZ-0001LG-T5; Thu, 26 May 2005 15:13:29 -0700 Date: Thu, 26 May 2005 15:13:29 -0700 (PDT) Message-Id: <20050526.151329.21592585.davem@davemloft.net> To: pravins@calsoftinc.com Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] : bug fix in multipath drr code. From: "David S. Miller" In-Reply-To: <4292FA7C.80308@calsoftinc.com> References: <4292CDCE.2090600@calsoftinc.com> <20050524071146.GA30995@gondor.apana.org.au> <4292FA7C.80308@calsoftinc.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 286 Lines: 9 From: pravin b shelar Date: Tue, 24 May 2005 15:27:16 +0530 > So I think we should ignore MULTIPATHOLDROUTE flag > in drr and rr multipath algorithms as done in random multipath algorithm. > > Attached patch does same thing. I've applied this patch, thanks. From davem@davemloft.net Thu May 26 15:18:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 15:18:35 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QMIVXq027289 for ; Thu, 26 May 2005 15:18:31 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbQfO-0001MC-GM; Thu, 26 May 2005 15:17:26 -0700 Date: Thu, 26 May 2005 15:17:26 -0700 (PDT) Message-Id: <20050526.151726.85409972.davem@davemloft.net> To: tgraf@suug.ch Cc: netdev@oss.sgi.com Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: "David S. Miller" In-Reply-To: <20050526185526.GZ15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 381 Lines: 12 From: Thomas Graf Date: Thu, 26 May 2005 20:55:26 +0200 > This message is followed by 0..n messages carrying device > specific parameter sets. They all share the same value for > Although the ordering should be sufficient, NDTA_NAME can be It seems a sentence is chopped off here mid-stream, please provide a fixed changelog so I can apply your patches. Thanks. From tgraf@suug.ch Thu May 26 15:24:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 15:24:50 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QMOjXq028185 for ; Thu, 26 May 2005 15:24:45 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B86C21C0EB; Fri, 27 May 2005 00:24:15 +0200 (CEST) Date: Fri, 27 May 2005 00:24:15 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050526222415.GC15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> <20050526.151726.85409972.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526.151726.85409972.davem@davemloft.net> X-archive-position: 1707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 18942 Lines: 592 To retrieve the neighbour tables send RTM_GETNEIGHTBL with the NLM_F_DUMP flag set. Every neighbour table configuration is spread over multiple messages to avoid running into message size limits on systems with many interfaces. The first message in the sequence transports all not device specific data such as statistics, configuration, and the default parameter set. This message is followed by 0..n messages carrying device specific parameter sets. Although the ordering should be sufficient, NDTA_NAME can be used to identify sequences. The initial message can be identified by checking for NDTA_CONFIG. The device specific messages do not contain this TLV but have NDTPA_IFINDEX set to the corresponding interface index. To change neighbour table attributes, send RTM_SETNEIGHTBL with NDTA_NAME set. Changeable attribute include NDTA_THRESH[1-3], NDTA_GC_INTERVAL, and all TLVs in NDTA_PARMS unless marked otherwise. Device specific parameter sets can be changed by setting NDTPA_IFINDEX to the interface index of the corresponding device. Signed-off-by: Thomas Graf --- commit 6769b3b0603c632bda062e427178de8986900a52 tree 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b parent 98c3bc2e6320127cd96ef46d33f89ae127ce48fe author Thomas Graf Wed, 25 May 2005 20:30:09 +0200 committer Thomas Graf Wed, 25 May 2005 20:30:09 +0200 include/linux/rtnetlink.h | 107 ++++++++++++++ include/net/neighbour.h | 4 net/core/neighbour.c | 317 +++++++++++++++++++++++++++++++++++++++++++- net/core/rtnetlink.c | 20 +- security/selinux/nlmsgtab.c | 2 5 files changed, 439 insertions(+), 11 deletions(-) Index: include/linux/rtnetlink.h =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/include/linux/rtnetlink.h (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/include/linux/rtnetlink.h (mode:100644) @@ -89,6 +89,13 @@ RTM_GETANYCAST = 62, #define RTM_GETANYCAST RTM_GETANYCAST + RTM_NEWNEIGHTBL = 64, +#define RTM_NEWNEIGHTBL RTM_NEWNEIGHTBL + RTM_GETNEIGHTBL = 66, +#define RTM_GETNEIGHTBL RTM_GETNEIGHTBL + RTM_SETNEIGHTBL, +#define RTM_SETNEIGHTBL RTM_SETNEIGHTBL + __RTM_MAX, #define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1) }; @@ -493,6 +500,106 @@ __u32 ndm_refcnt; }; + +/***************************************************************** + * Neighbour tables specific messages. + * + * To retrieve the neighbour tables send RTM_GETNEIGHTBL with the + * NLM_F_DUMP flag set. Every neighbour table configuration is + * spread over multiple messages to avoid running into message + * size limits on systems with many interfaces. The first message + * in the sequence transports all not device specific data such as + * statistics, configuration, and the default parameter set. + * This message is followed by 0..n messages carrying device + * specific parameter sets. + * Although the ordering should be sufficient, NDTA_NAME can be + * used to identify sequences. The initial message can be identified + * by checking for NDTA_CONFIG. The device specific messages do + * not contain this TLV but have NDTPA_IFINDEX set to the + * corresponding interface index. + * + * To change neighbour table attributes, send RTM_SETNEIGHTBL + * with NDTA_NAME set. Changeable attribute include NDTA_THRESH[1-3], + * NDTA_GC_INTERVAL, and all TLVs in NDTA_PARMS unless marked + * otherwise. Device specific parameter sets can be changed by + * setting NDTPA_IFINDEX to the interface index of the corresponding + * device. + ****/ + +struct ndt_stats +{ + __u64 ndts_allocs; + __u64 ndts_destroys; + __u64 ndts_hash_grows; + __u64 ndts_res_failed; + __u64 ndts_lookups; + __u64 ndts_hits; + __u64 ndts_rcv_probes_mcast; + __u64 ndts_rcv_probes_ucast; + __u64 ndts_periodic_gc_runs; + __u64 ndts_forced_gc_runs; +}; + +enum { + NDTPA_UNSPEC, + NDTPA_IFINDEX, /* u32, unchangeable */ + NDTPA_REFCNT, /* u32, read-only */ + NDTPA_REACHABLE_TIME, /* u64, read-only, msecs */ + NDTPA_BASE_REACHABLE_TIME, /* u64, msecs */ + NDTPA_RETRANS_TIME, /* u64, msecs */ + NDTPA_GC_STALETIME, /* u64, msecs */ + NDTPA_DELAY_PROBE_TIME, /* u64, msecs */ + NDTPA_QUEUE_LEN, /* u32 */ + NDTPA_APP_PROBES, /* u32 */ + NDTPA_UCAST_PROBES, /* u32 */ + NDTPA_MCAST_PROBES, /* u32 */ + NDTPA_ANYCAST_DELAY, /* u64, msecs */ + NDTPA_PROXY_DELAY, /* u64, msecs */ + NDTPA_PROXY_QLEN, /* u32 */ + NDTPA_LOCKTIME, /* u64, msecs */ + __NDTPA_MAX +}; +#define NDTPA_MAX (__NDTPA_MAX - 1) + +struct ndtmsg +{ + __u8 ndtm_family; + __u8 ndtm_pad1; + __u16 ndtm_pad2; +}; + +struct ndt_config +{ + __u16 ndtc_key_len; + __u16 ndtc_entry_size; + __u32 ndtc_entries; + __u32 ndtc_last_flush; /* delta to now in msecs */ + __u32 ndtc_last_rand; /* delta to now in msecs */ + __u32 ndtc_hash_rnd; + __u32 ndtc_hash_mask; + __u32 ndtc_hash_chain_gc; + __u32 ndtc_proxy_qlen; +}; + +enum { + NDTA_UNSPEC, + NDTA_NAME, /* char *, unchangeable */ + NDTA_THRESH1, /* u32 */ + NDTA_THRESH2, /* u32 */ + NDTA_THRESH3, /* u32 */ + NDTA_CONFIG, /* struct ndt_config, read-only */ + NDTA_PARMS, /* nested TLV NDTPA_* */ + NDTA_STATS, /* struct ndt_stats, read-only */ + NDTA_GC_INTERVAL, /* u64, msecs */ + __NDTA_MAX +}; +#define NDTA_MAX (__NDTA_MAX - 1) + +#define NDTA_RTA(r) ((struct rtattr*)(((char*)(r)) + \ + NLMSG_ALIGN(sizeof(struct ndtmsg)))) +#define NDTA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ndtmsg)) + + /**** * General form of address family dependent message. ****/ Index: include/net/neighbour.h =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/include/net/neighbour.h (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/include/net/neighbour.h (mode:100644) @@ -65,6 +65,7 @@ struct neigh_parms { + struct net_device *dev; struct neigh_parms *next; int (*neigh_setup)(struct neighbour *); struct neigh_table *tbl; @@ -252,6 +253,9 @@ extern int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); extern void neigh_app_ns(struct neighbour *n); +extern int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb); +extern int neightbl_set(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); + extern void neigh_for_each(struct neigh_table *tbl, void (*cb)(struct neighbour *, void *), void *cookie); extern void __neigh_for_each_release(struct neigh_table *tbl, int (*cb)(struct neighbour *)); extern void pneigh_for_each(struct neigh_table *tbl, void (*cb)(struct pneigh_entry *)); Index: net/core/neighbour.c =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/net/core/neighbour.c (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/net/core/neighbour.c (mode:100644) @@ -1276,9 +1276,14 @@ INIT_RCU_HEAD(&p->rcu_head); p->reachable_time = neigh_rand_reach_time(p->base_reachable_time); - if (dev && dev->neigh_setup && dev->neigh_setup(dev, p)) { - kfree(p); - return NULL; + if (dev) { + if (dev->neigh_setup && dev->neigh_setup(dev, p)) { + kfree(p); + return NULL; + } + + dev_hold(dev); + p->dev = dev; } p->sysctl_table = NULL; write_lock_bh(&tbl->lock); @@ -1309,6 +1314,8 @@ *p = parms->next; parms->dead = 1; write_unlock_bh(&tbl->lock); + if (parms->dev) + dev_put(parms->dev); call_rcu(&parms->rcu_head, neigh_rcu_free_parms); return; } @@ -1546,6 +1553,308 @@ return err; } +static int neightbl_fill_parms(struct sk_buff *skb, struct neigh_parms *parms) +{ + struct rtattr *nest = RTA_NEST(skb, NDTA_PARMS); + + if (parms->dev) + RTA_PUT_U32(skb, NDTPA_IFINDEX, parms->dev->ifindex); + + RTA_PUT_U32(skb, NDTPA_REFCNT, atomic_read(&parms->refcnt)); + RTA_PUT_U32(skb, NDTPA_QUEUE_LEN, parms->queue_len); + RTA_PUT_U32(skb, NDTPA_PROXY_QLEN, parms->proxy_qlen); + RTA_PUT_U32(skb, NDTPA_APP_PROBES, parms->app_probes); + RTA_PUT_U32(skb, NDTPA_UCAST_PROBES, parms->ucast_probes); + RTA_PUT_U32(skb, NDTPA_MCAST_PROBES, parms->mcast_probes); + RTA_PUT_MSECS(skb, NDTPA_REACHABLE_TIME, parms->reachable_time); + RTA_PUT_MSECS(skb, NDTPA_BASE_REACHABLE_TIME, + parms->base_reachable_time); + RTA_PUT_MSECS(skb, NDTPA_GC_STALETIME, parms->gc_staletime); + RTA_PUT_MSECS(skb, NDTPA_DELAY_PROBE_TIME, parms->delay_probe_time); + RTA_PUT_MSECS(skb, NDTPA_RETRANS_TIME, parms->retrans_time); + RTA_PUT_MSECS(skb, NDTPA_ANYCAST_DELAY, parms->anycast_delay); + RTA_PUT_MSECS(skb, NDTPA_PROXY_DELAY, parms->proxy_delay); + RTA_PUT_MSECS(skb, NDTPA_LOCKTIME, parms->locktime); + + return RTA_NEST_END(skb, nest); + +rtattr_failure: + return RTA_NEST_CANCEL(skb, nest); +} + +static int neightbl_fill_info(struct neigh_table *tbl, struct sk_buff *skb, + struct netlink_callback *cb) +{ + struct nlmsghdr *nlh; + struct ndtmsg *ndtmsg; + + nlh = NLMSG_PUT_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg)); + ndtmsg = NLMSG_DATA(nlh); + + NLMSG_SET_MULTIPART(nlh); + + read_lock_bh(&tbl->lock); + ndtmsg->ndtm_family = tbl->family; + + RTA_PUT_STRING(skb, NDTA_NAME, tbl->id); + RTA_PUT_MSECS(skb, NDTA_GC_INTERVAL, tbl->gc_interval); + RTA_PUT_U32(skb, NDTA_THRESH1, tbl->gc_thresh1); + RTA_PUT_U32(skb, NDTA_THRESH2, tbl->gc_thresh2); + RTA_PUT_U32(skb, NDTA_THRESH3, tbl->gc_thresh3); + + { + unsigned long now = jiffies; + unsigned int flush_delta = now - tbl->last_flush; + unsigned int rand_delta = now - tbl->last_rand; + + struct ndt_config ndc = { + .ndtc_key_len = tbl->key_len, + .ndtc_entry_size = tbl->entry_size, + .ndtc_entries = atomic_read(&tbl->entries), + .ndtc_last_flush = jiffies_to_msecs(flush_delta), + .ndtc_last_rand = jiffies_to_msecs(rand_delta), + .ndtc_hash_rnd = tbl->hash_rnd, + .ndtc_hash_mask = tbl->hash_mask, + .ndtc_hash_chain_gc = tbl->hash_chain_gc, + .ndtc_proxy_qlen = tbl->proxy_queue.qlen, + }; + + RTA_PUT(skb, NDTA_CONFIG, sizeof(ndc), &ndc); + } + + { + int cpu; + struct ndt_stats ndst; + + memset(&ndst, 0, sizeof(ndst)); + + for (cpu = 0; cpu < NR_CPUS; cpu++) { + struct neigh_statistics *st; + + if (!cpu_possible(cpu)) + continue; + + st = per_cpu_ptr(tbl->stats, cpu); + ndst.ndts_allocs += st->allocs; + ndst.ndts_destroys += st->destroys; + ndst.ndts_hash_grows += st->hash_grows; + ndst.ndts_res_failed += st->res_failed; + ndst.ndts_lookups += st->lookups; + ndst.ndts_hits += st->hits; + ndst.ndts_rcv_probes_mcast += st->rcv_probes_mcast; + ndst.ndts_rcv_probes_ucast += st->rcv_probes_ucast; + ndst.ndts_periodic_gc_runs += st->periodic_gc_runs; + ndst.ndts_forced_gc_runs += st->forced_gc_runs; + } + + RTA_PUT(skb, NDTA_STATS, sizeof(ndst), &ndst); + } + + BUG_ON(tbl->parms.dev); + if (neightbl_fill_parms(skb, &tbl->parms) < 0) + goto rtattr_failure; + + read_unlock_bh(&tbl->lock); + return NLMSG_END(skb, nlh); + +rtattr_failure: + read_unlock_bh(&tbl->lock); + return NLMSG_CANCEL(skb, nlh); + +nlmsg_failure: + return -1; +} + +static int neightbl_fill_param_info(struct neigh_table *tbl, + struct neigh_parms *parms, + struct sk_buff *skb, + struct netlink_callback *cb) +{ + struct ndtmsg *ndtmsg; + struct nlmsghdr *nlh; + + nlh = NLMSG_PUT_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg)); + ndtmsg = NLMSG_DATA(nlh); + + NLMSG_SET_MULTIPART(nlh); + + read_lock_bh(&tbl->lock); + ndtmsg->ndtm_family = tbl->family; + RTA_PUT_STRING(skb, NDTA_NAME, tbl->id); + + if (neightbl_fill_parms(skb, parms) < 0) + goto rtattr_failure; + + read_unlock_bh(&tbl->lock); + return NLMSG_END(skb, nlh); + +rtattr_failure: + read_unlock_bh(&tbl->lock); + return NLMSG_CANCEL(skb, nlh); + +nlmsg_failure: + return -1; +} + +static inline struct neigh_parms *lookup_neigh_params(struct neigh_table *tbl, + int ifindex) +{ + struct neigh_parms *p; + + for (p = &tbl->parms; p; p = p->next) + if ((p->dev && p->dev->ifindex == ifindex) || + (!p->dev && !ifindex)) + return p; + + return NULL; +} + +int neightbl_set(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg) +{ + struct neigh_table *tbl; + struct ndtmsg *ndtmsg = NLMSG_DATA(nlh); + struct rtattr **tb = arg; + int err = -EINVAL; + + if (!tb[NDTA_NAME - 1] || !RTA_PAYLOAD(tb[NDTA_NAME - 1])) + return -EINVAL; + + read_lock(&neigh_tbl_lock); + for (tbl = neigh_tables; tbl; tbl = tbl->next) { + if (ndtmsg->ndtm_family && tbl->family != ndtmsg->ndtm_family) + continue; + + if (!rtattr_strcmp(tb[NDTA_NAME - 1], tbl->id)) + break; + } + + if (tbl == NULL) { + err = -ENOENT; + goto errout; + } + + /* + * We acquire tbl->lock to be nice to the periodic timers and + * make sure they always see a consistent set of values. + */ + write_lock_bh(&tbl->lock); + + if (tb[NDTA_THRESH1 - 1]) + tbl->gc_thresh1 = RTA_GET_U32(tb[NDTA_THRESH1 - 1]); + + if (tb[NDTA_THRESH2 - 1]) + tbl->gc_thresh2 = RTA_GET_U32(tb[NDTA_THRESH2 - 1]); + + if (tb[NDTA_THRESH3 - 1]) + tbl->gc_thresh3 = RTA_GET_U32(tb[NDTA_THRESH3 - 1]); + + if (tb[NDTA_GC_INTERVAL - 1]) + tbl->gc_interval = RTA_GET_MSECS(tb[NDTA_GC_INTERVAL - 1]); + + if (tb[NDTA_PARMS - 1]) { + struct rtattr *tbp[NDTPA_MAX]; + struct neigh_parms *p; + u32 ifindex = 0; + + if (rtattr_parse_nested(tbp, NDTPA_MAX, tb[NDTA_PARMS - 1]) < 0) + goto rtattr_failure; + + if (tbp[NDTPA_IFINDEX - 1]) + ifindex = RTA_GET_U32(tbp[NDTPA_IFINDEX - 1]); + + p = lookup_neigh_params(tbl, ifindex); + if (p == NULL) { + err = -ENOENT; + goto rtattr_failure; + } + + if (tbp[NDTPA_QUEUE_LEN - 1]) + p->queue_len = RTA_GET_U32(tbp[NDTPA_QUEUE_LEN - 1]); + + if (tbp[NDTPA_PROXY_QLEN - 1]) + p->proxy_qlen = RTA_GET_U32(tbp[NDTPA_PROXY_QLEN - 1]); + + if (tbp[NDTPA_APP_PROBES - 1]) + p->app_probes = RTA_GET_U32(tbp[NDTPA_APP_PROBES - 1]); + + if (tbp[NDTPA_UCAST_PROBES - 1]) + p->ucast_probes = + RTA_GET_U32(tbp[NDTPA_UCAST_PROBES - 1]); + + if (tbp[NDTPA_MCAST_PROBES - 1]) + p->mcast_probes = + RTA_GET_U32(tbp[NDTPA_MCAST_PROBES - 1]); + + if (tbp[NDTPA_BASE_REACHABLE_TIME - 1]) + p->base_reachable_time = + RTA_GET_MSECS(tbp[NDTPA_BASE_REACHABLE_TIME - 1]); + + if (tbp[NDTPA_GC_STALETIME - 1]) + p->gc_staletime = + RTA_GET_MSECS(tbp[NDTPA_GC_STALETIME - 1]); + + if (tbp[NDTPA_DELAY_PROBE_TIME - 1]) + p->delay_probe_time = + RTA_GET_MSECS(tbp[NDTPA_DELAY_PROBE_TIME - 1]); + + if (tbp[NDTPA_RETRANS_TIME - 1]) + p->retrans_time = + RTA_GET_MSECS(tbp[NDTPA_RETRANS_TIME - 1]); + + if (tbp[NDTPA_ANYCAST_DELAY - 1]) + p->anycast_delay = + RTA_GET_MSECS(tbp[NDTPA_ANYCAST_DELAY - 1]); + + if (tbp[NDTPA_PROXY_DELAY - 1]) + p->proxy_delay = + RTA_GET_MSECS(tbp[NDTPA_PROXY_DELAY - 1]); + + if (tbp[NDTPA_LOCKTIME - 1]) + p->locktime = RTA_GET_MSECS(tbp[NDTPA_LOCKTIME - 1]); + } + + err = 0; + +rtattr_failure: + write_unlock_bh(&tbl->lock); +errout: + read_unlock(&neigh_tbl_lock); + return err; +} + +int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb) +{ + int idx, family; + int s_idx = cb->args[0]; + struct neigh_table *tbl; + + family = ((struct rtgenmsg *)NLMSG_DATA(cb->nlh))->rtgen_family; + + read_lock(&neigh_tbl_lock); + for (tbl = neigh_tables, idx = 0; tbl; tbl = tbl->next) { + struct neigh_parms *p; + + if (idx < s_idx || (family && tbl->family != family)) + continue; + + if (neightbl_fill_info(tbl, skb, cb) <= 0) + break; + + for (++idx, p = tbl->parms.next; p; p = p->next, idx++) { + if (idx < s_idx) + continue; + + if (neightbl_fill_param_info(tbl, p, skb, cb) <= 0) + goto out; + } + + } +out: + read_unlock(&neigh_tbl_lock); + cb->args[0] = idx; + + return skb->len; +} static int neigh_fill_info(struct sk_buff *skb, struct neighbour *n, u32 pid, u32 seq, int event) @@ -2352,6 +2661,8 @@ EXPORT_SYMBOL(neigh_update_hhs); EXPORT_SYMBOL(pneigh_enqueue); EXPORT_SYMBOL(pneigh_lookup); +EXPORT_SYMBOL(neightbl_dump_info); +EXPORT_SYMBOL(neightbl_set); #ifdef CONFIG_ARPD EXPORT_SYMBOL(neigh_app_ns); Index: net/core/rtnetlink.c =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/net/core/rtnetlink.c (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/net/core/rtnetlink.c (mode:100644) @@ -100,6 +100,7 @@ [RTM_FAM(RTM_NEWPREFIX)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)), [RTM_FAM(RTM_GETMULTICAST)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)), [RTM_FAM(RTM_GETANYCAST)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)), + [RTM_FAM(RTM_NEWNEIGHTBL)] = NLMSG_LENGTH(sizeof(struct ndtmsg)), }; static const int rta_max[RTM_NR_FAMILIES] = @@ -113,6 +114,7 @@ [RTM_FAM(RTM_NEWTCLASS)] = TCA_MAX, [RTM_FAM(RTM_NEWTFILTER)] = TCA_MAX, [RTM_FAM(RTM_NEWACTION)] = TCAA_MAX, + [RTM_FAM(RTM_NEWNEIGHTBL)] = NDTA_MAX, }; void __rta_fill(struct sk_buff *skb, int attrtype, int attrlen, const void *data) @@ -649,14 +651,16 @@ static struct rtnetlink_link link_rtnetlink_table[RTM_NR_MSGTYPES] = { - [RTM_GETLINK - RTM_BASE] = { .dumpit = rtnetlink_dump_ifinfo }, - [RTM_SETLINK - RTM_BASE] = { .doit = do_setlink }, - [RTM_GETADDR - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, - [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, - [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, - [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, - [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_GETLINK - RTM_BASE] = { .dumpit = rtnetlink_dump_ifinfo }, + [RTM_SETLINK - RTM_BASE] = { .doit = do_setlink }, + [RTM_GETADDR - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, + [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, + [RTM_GETNEIGHTBL - RTM_BASE] = { .dumpit = neightbl_dump_info }, + [RTM_SETNEIGHTBL - RTM_BASE] = { .doit = neightbl_set }, }; static int rtnetlink_event(struct notifier_block *this, unsigned long event, void *ptr) Index: security/selinux/nlmsgtab.c =================================================================== --- 0ad944fa24c79b3eeaf06f85f5dd6d91ae1adbc9/security/selinux/nlmsgtab.c (mode:100644) +++ 7e955d0e3c8fdef048336d0d7ba24a0539f28f9b/security/selinux/nlmsgtab.c (mode:100644) @@ -63,6 +63,8 @@ { RTM_GETPREFIX, NETLINK_ROUTE_SOCKET__NLMSG_READ }, { RTM_GETMULTICAST, NETLINK_ROUTE_SOCKET__NLMSG_READ }, { RTM_GETANYCAST, NETLINK_ROUTE_SOCKET__NLMSG_READ }, + { RTM_GETNEIGHTBL, NETLINK_ROUTE_SOCKET__NLMSG_READ }, + { RTM_SETNEIGHTBL, NETLINK_ROUTE_SOCKET__NLMSG_WRITE }, }; static struct nlmsg_perm nlmsg_firewall_perms[] = From tgraf@suug.ch Thu May 26 15:27:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 15:27:26 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QMRMXq028827 for ; Thu, 26 May 2005 15:27:23 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 888A61C0EB; Fri, 27 May 2005 00:26:56 +0200 (CEST) Date: Fri, 27 May 2005 00:26:56 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050526222656.GD15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> <20050526.151726.85409972.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526.151726.85409972.davem@davemloft.net> X-archive-position: 1708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 619 Lines: 15 * David S. Miller <20050526.151726.85409972.davem@davemloft.net> 2005-05-26 15:17 > From: Thomas Graf > Date: Thu, 26 May 2005 20:55:26 +0200 > > > This message is followed by 0..n messages carrying device > > specific parameter sets. They all share the same value for > > Although the ordering should be sufficient, NDTA_NAME can be > > It seems a sentence is chopped off here mid-stream, > please provide a fixed changelog so I can apply your > patches. Sorry, it's what happens if one gets interrupted in the middle of writing a longer comment. ;-> Patch edited by hand but it should still apply. From davem@davemloft.net Thu May 26 15:38:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 15:38:25 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QMcMXq029574 for ; Thu, 26 May 2005 15:38:22 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbQyr-00027C-Q9; Thu, 26 May 2005 15:37:33 -0700 Date: Thu, 26 May 2005 15:37:33 -0700 (PDT) Message-Id: <20050526.153733.07456079.davem@davemloft.net> To: tgraf@suug.ch Cc: netdev@oss.sgi.com Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: "David S. Miller" In-Reply-To: <20050526222656.GD15391@postel.suug.ch> References: <20050526185526.GZ15391@postel.suug.ch> <20050526.151726.85409972.davem@davemloft.net> <20050526222656.GD15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 232 Lines: 8 From: Thomas Graf Date: Fri, 27 May 2005 00:26:56 +0200 > Sorry, it's what happens if one gets interrupted in the middle > of writing a longer comment. ;-> Patch edited by hand but > it should still apply. Thanks. From shemminger@osdl.org Thu May 26 15:49:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 15:50:00 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QMnuXq030395 for ; Thu, 26 May 2005 15:49:57 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4QMmvjA010920 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 May 2005 15:48:58 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4QMmvbX019052; Thu, 26 May 2005 15:48:57 -0700 Date: Thu, 26 May 2005 15:48:57 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: Re: [Bridge] Re: [PATCH] (6/6) bridge: receive path optimization Message-ID: <20050526154857.3cb34d11@dxpl.pdx.osdl.net> In-Reply-To: <20050526.144638.71091166.davem@davemloft.net> References: <20050526110425.27590eb8@dxpl.pdx.osdl.net> <20050526.144638.71091166.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1142 Lines: 34 On Thu, 26 May 2005 14:46:38 -0700 (PDT) "David S. Miller" wrote: > From: Stephen Hemminger > Date: Thu, 26 May 2005 11:04:25 -0700 > > > This improves the bridge local receive path by avoiding going > > through another softirq. The bridge receive path is already being called > > from a netif_receive_skb() there is no point in going through another > > receiveq round trip. > > > > Recursion is limited because bridge can never be a port of a bridge > > so handle_bridge() always returns. > > I applied all 6 patches, but this one in particular I'd like > to comment on. > > Remember all of those bridge netfilter stack usage issues > we have a few months ago? This could edge us back into > those problems again. no, because the br_frame_finish is called after the netfilter decision: netif_receive_skb handle_bridge br_handle_frame br_handle_frame_finish br_pass_frame_up br_pass_frame_up_finish netif_receive_skb <---- change (normal receive path) So the call chain is bounded (ie not related to number of filters) but slightly longer. From davem@davemloft.net Thu May 26 15:54:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 15:54:57 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QMssXq030968 for ; Thu, 26 May 2005 15:54:54 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbREn-0004g5-Cc; Thu, 26 May 2005 15:54:01 -0700 Date: Thu, 26 May 2005 15:54:01 -0700 (PDT) Message-Id: <20050526.155401.18310361.davem@davemloft.net> To: shemminger@osdl.org Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: Re: [Bridge] Re: [PATCH] (6/6) bridge: receive path optimization From: "David S. Miller" In-Reply-To: <20050526154857.3cb34d11@dxpl.pdx.osdl.net> References: <20050526110425.27590eb8@dxpl.pdx.osdl.net> <20050526.144638.71091166.davem@davemloft.net> <20050526154857.3cb34d11@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 228 Lines: 7 From: Stephen Hemminger Date: Thu, 26 May 2005 15:48:57 -0700 > So the call chain is bounded (ie not related to number of filters) > but slightly longer. You're right, thanks for the explanation Stephen. From davem@davemloft.net Thu May 26 16:00:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 16:01:05 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QN0uXq031635 for ; Thu, 26 May 2005 16:00:56 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbRKe-0005KY-HO; Thu, 26 May 2005 16:00:04 -0700 Date: Thu, 26 May 2005 16:00:04 -0700 (PDT) Message-Id: <20050526.160004.18577501.davem@davemloft.net> To: shemminger@osdl.org Cc: jdmason@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH linux-2.6.12-rc4-mm1] ethtool: Add NETIF_F_HW_CSUM support From: "David S. Miller" In-Reply-To: <20050523145321.49899042@dxpl.pdx.osdl.net> References: <20050523210757.GB5910@us.ibm.com> <20050523.142009.74748115.davem@davemloft.net> <20050523145321.49899042@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 310 Lines: 10 From: Stephen Hemminger Date: Mon, 23 May 2005 14:53:21 -0700 > This patch makes perfect sense because it allows for common code to be > used by device drivers in their ethtool_ops. So this is the logical way to handle > this. You're right, of course. I've applied the patch. Thanks. From davem@davemloft.net Thu May 26 16:07:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 16:07:34 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QN7UXq032181 for ; Thu, 26 May 2005 16:07:31 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbRR2-0005Se-Sx; Thu, 26 May 2005 16:06:40 -0700 Date: Thu, 26 May 2005 16:06:40 -0700 (PDT) Message-Id: <20050526.160640.45179958.davem@davemloft.net> To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: Re: [NET] 2.6.x build warning From: "David S. Miller" In-Reply-To: <42961EDB.7000407@pobox.com> References: <42961EDB.7000407@pobox.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 345 Lines: 10 From: Jeff Garzik Date: Thu, 26 May 2005 15:09:15 -0400 > from current git tree: > > net/ipv6/ip6_flowlabel.c: In function `ipv6_flowlabel_opt': > net/ipv6/ip6_flowlabel.c:540: warning: ignoring return value of > `copy_to_user', declared with attribute warn_unused_result I've fixed this warning in my tree, thanks Jeff. From ganesh.venkatesan@gmail.com Thu May 26 16:09:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 16:09:11 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QN95Xq032741 for ; Thu, 26 May 2005 16:09:05 -0700 Received: by zproxy.gmail.com with SMTP id 34so599052nzf for ; Thu, 26 May 2005 16:08:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Za1tN+o7B8ceBG8jx2iAeC/GHgB9aZEOvslcBRi2cIkGLMdrSK+mLH6qR9oPSde4HcxadQMeqekyTYCmzFI/NXWCvoMTMT3FMDwLLA4OipPDTkZBaoUxif1ymwuqw2lCTnlrVi28QK0I21WgXEe+frPZwa9UkFm6xPlUtq+Uhpk= Received: by 10.36.3.12 with SMTP id 12mr874278nzc; Thu, 26 May 2005 16:08:17 -0700 (PDT) Received: by 10.36.61.20 with HTTP; Thu, 26 May 2005 16:08:17 -0700 (PDT) Message-ID: <5fc59ff30505261608541b74fb@mail.gmail.com> Date: Thu, 26 May 2005 16:08:17 -0700 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: Herbert Xu Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Cc: "Venkatesan, Ganesh" , Andrew Morton , Jian Jun He , anton@samba.org, rende@cn.ibm.com, "Brandeburg, Jesse" , jgarzik@pobox.com, wangjs@cn.ibm.com, "Ronciak, John" , cdlwangl@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com In-Reply-To: <20050526213421.GA8077@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <468F3FDA28AA87429AD807992E22D07E056F6B37@orsmsx408> <20050526213421.GA8077@gondor.apana.org.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4QN95Xq032741 X-archive-position: 1714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 1064 Lines: 33 Herbert: I do not get it. Bear with my ignorance. e100_tx_timeout does not call e100_down. It is called from e100_tx_timeout_task which is invoked as a result of schedule_work. Are you saying that it would still not have the right context to call netif_disable_poll()? thanks, ganesh. On 5/26/05, Herbert Xu wrote: > On Thu, May 26, 2005 at 01:41:53PM -0700, Venkatesan, Ganesh wrote: > > > > I already responded to this analysis before. In any case, here it is: > > > > Later versions of e100 (3.4.8 for instance) includes a call to > > netif_poll_disable in e100_down. This is supposed to wait and when it > > As I said last time, this is broken since the code path in question > starts from tx_timeout which is called in softirq context. You'll > need to schedule a work struct at least. > > Cheers, > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > From ravinandan.arakali@neterion.com Thu May 26 16:27:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 16:27:10 -0700 (PDT) Received: from linux.site (adsl-67-120-213-161.dsl.sntc01.pacbell.net [67.120.213.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QNR4Xq005108 for ; Thu, 26 May 2005 16:27:04 -0700 Received: by linux.site (Postfix, from userid 0) id 60E6365005; Thu, 26 May 2005 16:20:06 -0700 (PDT) To: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com Cc: raghavendra.koushik@neterion.com, ravinandan.arakali@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com From: ravinandan.arakali@neterion.com Subject: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature Message-Id: <20050526232006.60E6365005@linux.site> Date: Thu, 26 May 2005 16:20:06 -0700 (PDT) X-archive-position: 1715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev Content-Length: 10782 Lines: 308 Hi, Attached below is a kernel patch to provide UDP LSO(Large Send Offload) feature. This is the UDP counterpart of TSO. Basically, an oversized packet (less than or equal to 65535) is handed to the NIC. The adapter then produces IP fragments in conformance with RFC791(IPv4) or RFC2460(IPv6). Very much like TCP TSO, UDP LSO provides significant reduction in CPU utilization, especially with 1500 MTU frames. For 10GbE traffic, these extra CPU cycles translate into significant throughput increase on most server platforms. Reasonable amount of testing has been done on the patch using Neterion's 10G Xframe-II adapter to ensure code stability. Please review the patch. Also, below is a "how-to" on changes required in network drivers to use the UDP LSO interface. UDP Large Send Offload (ULSO) Interface: ---------------------------------------- ULSO is a feature wherein the Linux kernel network stack will offload the IP fragmentation functionality of large UDP datagram to hardware. This will reduce the overhead of stack in fragmenting the large UDP datagram to MTU sized packets. 1) Drivers indicate their capability of ULSO using dev->features |= NETIF_F_UDP_LSO | NETIF_F_HW_CSUM NETIF_F_HW_CSUM is required for ULSO over ipv6. 2) ULSO packet will be submitted for transmission using driver xmit routine. ULSO packet will have a non zero value for "skb_shinfo(skb)->ulso_size" skb_shinfo(skb)->ulso_size will indicate the length of data in each IP fragment going out of the adapter after IP fragmentation by hardware. skb->data will contain MAC/IP/UDP header and skb_shinfo(skb)->frags[] contains the data payload. The skb->ip_summed will be set to CHECKSUM_HW indicating that hardware has to perform checksum calculation. Hardware should compute the UDP checksum of complete UDP datagram and also the IP header checksum of each fragmented IP packet. For IPV6 the ULSO provides the fragment identification id in skb_shinfo(skb)->ip6_id. The adapter should use this ID for generating IPv6 fragments. Signed-off-by: Ananda Raju Signed-off-by: Ravinandan Arakali --- diff -uNr linux-2.6.12-rc4.org/include/linux/netdevice.h linux-2.6.12-rc4/include/linux/netdevice.h --- linux-2.6.12-rc4.org/include/linux/netdevice.h 2005-05-25 17:18:11.000000000 +0545 +++ linux-2.6.12-rc4/include/linux/netdevice.h 2005-05-25 20:28:25.000000000 +0545 @@ -414,6 +414,7 @@ #define NETIF_F_VLAN_CHALLENGED 1024 /* Device cannot handle VLAN packets */ #define NETIF_F_TSO 2048 /* Can offload TCP/IP segmentation */ #define NETIF_F_LLTX 4096 /* LockLess TX */ +#define NETIF_F_UDP_LSO 8192 /* Can offload UDP Large Send*/ /* Called after device is detached from network. */ void (*uninit)(struct net_device *dev); diff -uNr linux-2.6.12-rc4.org/include/linux/skbuff.h linux-2.6.12-rc4/include/linux/skbuff.h --- linux-2.6.12-rc4.org/include/linux/skbuff.h 2005-05-25 17:18:20.000000000 +0545 +++ linux-2.6.12-rc4/include/linux/skbuff.h 2005-05-26 17:04:50.000000000 +0545 @@ -135,6 +135,8 @@ atomic_t dataref; unsigned int nr_frags; unsigned short tso_size; + unsigned short ulso_size; + unsigned int ip6_id; unsigned short tso_segs; struct sk_buff *frag_list; skb_frag_t frags[MAX_SKB_FRAGS]; diff -uNr linux-2.6.12-rc4.org/include/net/sock.h linux-2.6.12-rc4/include/net/sock.h --- linux-2.6.12-rc4.org/include/net/sock.h 2005-05-25 17:18:44.000000000 +0545 +++ linux-2.6.12-rc4/include/net/sock.h 2005-05-25 20:28:14.000000000 +0545 @@ -1296,5 +1296,11 @@ return -ENODEV; } #endif +struct sk_buff *sock_append_data(struct sock *sk, + int getfrag(void *from, char *to, int offset, int len, + int odd, struct sk_buff *skb), + void *from, int length, int transhdrlen, + int hh_len, int fragheaderlen, + unsigned int flags,int *err); #endif /* _SOCK_H */ diff -uNr linux-2.6.12-rc4.org/net/core/skbuff.c linux-2.6.12-rc4/net/core/skbuff.c --- linux-2.6.12-rc4.org/net/core/skbuff.c 2005-05-25 20:25:35.000000000 +0545 +++ linux-2.6.12-rc4/net/core/skbuff.c 2005-05-25 20:46:04.000000000 +0545 @@ -159,6 +159,8 @@ skb_shinfo(skb)->tso_size = 0; skb_shinfo(skb)->tso_segs = 0; skb_shinfo(skb)->frag_list = NULL; + skb_shinfo(skb)->ulso_size = 0; + skb_shinfo(skb)->ip6_id = 0; out: return skb; nodata: diff -uNr linux-2.6.12-rc4.org/net/core/sock.c linux-2.6.12-rc4/net/core/sock.c --- linux-2.6.12-rc4.org/net/core/sock.c 2005-05-25 20:25:47.000000000 +0545 +++ linux-2.6.12-rc4/net/core/sock.c 2005-05-26 17:19:39.000000000 +0545 @@ -1401,6 +1401,107 @@ EXPORT_SYMBOL(proto_unregister); +/* + * sock_append_data - append the user data to a skb, + * sk - sock structure which contains skbs for transmission + * getfrag - The function to be called to get the data from the user. + * from - pointer to user message iov + * length - length of the iov message + * transhdrlen - transport header length + * hh_len - hardware header length + * fragheaderlen - length of the IP header + * flags - iov message flags + * err - Error code returned + * + * This procedure will allocate a skb enough to hold protocol headers and + * append the user data in the fragment part of the skb and add the skb to + * socket write queue + */ +struct sk_buff *sock_append_data(struct sock *sk, + int getfrag(void *from, char *to, int offset, int len, + int odd, struct sk_buff *skb), + void *from, int length, int transhdrlen, + int hh_len, int fragheaderlen, + unsigned int flags,int *err) +{ + struct sk_buff *skb; + int frg_cnt = 0; + skb_frag_t *frag = NULL; + struct page *page = NULL; + int copy, left; + int offset = 0; + + if (!((sk->sk_route_caps & NETIF_F_SG) && + (sk->sk_route_caps & (NETIF_F_IP_CSUM | NETIF_F_HW_CSUM)))) { + *err = -EOPNOTSUPP; + return NULL; + } + if (skb_queue_len(&sk->sk_write_queue)) { + *err = -EOPNOTSUPP; + return NULL; + } + + skb = sock_alloc_send_skb(sk, + hh_len + fragheaderlen + transhdrlen + 20, + (flags & MSG_DONTWAIT), err); + if (skb == NULL) { + *err = -ENOMEM; + return NULL; + } + /* reserve space for Hardware header */ + skb_reserve(skb, hh_len); + /* create space for UDP/IP header */ + skb_put(skb,fragheaderlen + transhdrlen); + /* initialize network header pointer */ + skb->nh.raw = skb->data; + /* initialize protocol header pointer */ + skb->h.raw = skb->data + fragheaderlen; + skb->ip_summed = CHECKSUM_HW; + skb->csum = 0; + do { + copy = length; + if (frg_cnt >= MAX_SKB_FRAGS) { + *err = -EFAULT; + kfree_skb(skb); + return NULL; + } + page = alloc_pages(sk->sk_allocation, 0); + if (page == NULL) { + *err = -ENOMEM; + kfree_skb(skb); + return NULL; + } + sk->sk_sndmsg_page = page; + sk->sk_sndmsg_off = 0; + skb_fill_page_desc(skb, frg_cnt, page, 0, 0); + skb->truesize += PAGE_SIZE; + atomic_add(PAGE_SIZE, &sk->sk_wmem_alloc); + frg_cnt = skb_shinfo(skb)->nr_frags; + frag = &skb_shinfo(skb)->frags[frg_cnt - 1]; + left = PAGE_SIZE - frag->page_offset; + if (copy > left) + copy = left; + if (getfrag(from, page_address(frag->page)+ + frag->page_offset+frag->size, + offset, copy, 0, skb) < 0) { + *err = -EFAULT; + kfree_skb(skb); + return NULL; + } + sk->sk_sndmsg_off += copy; + frag->size += copy; + skb->len += copy; + skb->data_len += copy; + offset += copy; + length -= copy; + page = NULL; + } while (length > 0); + __skb_queue_tail(&sk->sk_write_queue, skb); + *err = 0; + return skb; +} +EXPORT_SYMBOL(sock_append_data); + #ifdef CONFIG_PROC_FS static inline struct proto *__proto_head(void) { diff -uNr linux-2.6.12-rc4.org/net/ipv4/ip_output.c linux-2.6.12-rc4/net/ipv4/ip_output.c --- linux-2.6.12-rc4.org/net/ipv4/ip_output.c 2005-05-25 20:26:07.000000000 +0545 +++ linux-2.6.12-rc4/net/ipv4/ip_output.c 2005-05-25 20:27:20.000000000 +0545 @@ -291,7 +291,8 @@ { IP_INC_STATS(IPSTATS_MIB_OUTREQUESTS); - if (skb->len > dst_mtu(skb->dst) && !skb_shinfo(skb)->tso_size) + if (skb->len > dst_mtu(skb->dst) && + !(skb_shinfo(skb)->ulso_size || skb_shinfo(skb)->tso_size)) return ip_fragment(skb, ip_finish_output); else return ip_finish_output(skb); @@ -789,6 +790,29 @@ inet->cork.length += length; + sk->sk_route_caps |= rt->u.dst.dev->features; + if (((length > mtu) && (sk->sk_protocol == IPPROTO_UDP)) && + (sk->sk_route_caps & NETIF_F_UDP_LSO)) { + /* There is support for UDP large send offload by network + * device, so create one single skb packet containing complete + * udp datagram + */ + skb = sock_append_data(sk, getfrag, from, + (length - transhdrlen), transhdrlen, + hh_len, fragheaderlen, flags, &err); + if (skb != NULL) { + /* specify the length of each IP datagram fragment*/ + skb_shinfo(skb)->ulso_size = (mtu - fragheaderlen); + return 0; + } else if (err == -EOPNOTSUPP) { + /* There is not enough support do UPD LSO, + * so follow normal path + */ + err = 0; + } else + goto error; + } + /* So, what's going on in the loop below? * * We use calculated fragment length to generate chained skb, diff -uNr linux-2.6.12-rc4.org/net/ipv6/ip6_output.c linux-2.6.12-rc4/net/ipv6/ip6_output.c --- linux-2.6.12-rc4.org/net/ipv6/ip6_output.c 2005-05-25 20:26:17.000000000 +0545 +++ linux-2.6.12-rc4/net/ipv6/ip6_output.c 2005-05-26 17:05:06.000000000 +0545 @@ -147,7 +147,8 @@ int ip6_output(struct sk_buff *skb) { - if (skb->len > dst_mtu(skb->dst) || dst_allfrag(skb->dst)) + if ((skb->len > dst_mtu(skb->dst) && !skb_shinfo(skb)->ulso_size) || + dst_allfrag(skb->dst)) return ip6_fragment(skb, ip6_output2); else return ip6_output2(skb); @@ -898,6 +899,35 @@ */ inet->cork.length += length; + sk->sk_route_caps |= rt->u.dst.dev->features; + if (((length > mtu) && (sk->sk_protocol == IPPROTO_UDP)) && + ((sk->sk_route_caps & (NETIF_F_UDP_LSO | NETIF_F_HW_CSUM)) == + (NETIF_F_UDP_LSO | NETIF_F_HW_CSUM))) { + + /* There is support for UDP large send offload by network + * device, so create one single skb packet containing complete + * udp datagram + */ + skb = sock_append_data(sk, getfrag, from, + (length - transhdrlen), transhdrlen, + hh_len, fragheaderlen, flags, &err); + if (skb != NULL) { + struct frag_hdr fhdr; + + /* specify the length of each IP datagram fragment*/ + skb_shinfo(skb)->ulso_size = (mtu - fragheaderlen - + sizeof(struct frag_hdr)); + ipv6_select_ident(skb, &fhdr); + skb_shinfo(skb)->ip6_id = fhdr.identification; + return 0; + } else if (err == -EOPNOTSUPP){ + /* There is not enough support for UDP LSO, + * so follow normal path + */ + err = 0; + } else + goto error; + } if ((skb = skb_peek_tail(&sk->sk_write_queue)) == NULL) goto alloc_new_skb; From davem@davemloft.net Thu May 26 16:38:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 16:38:30 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QNcSXq005768 for ; Thu, 26 May 2005 16:38:28 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbRv0-0005Vd-QK; Thu, 26 May 2005 16:37:38 -0700 Date: Thu, 26 May 2005 16:37:38 -0700 (PDT) Message-Id: <20050526.163738.69020927.davem@davemloft.net> To: ravinandan.arakali@neterion.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, raghavendra.koushik@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature From: "David S. Miller" In-Reply-To: <20050526232006.60E6365005@linux.site> References: <20050526232006.60E6365005@linux.site> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1400 Lines: 39 From: ravinandan.arakali@neterion.com Date: Thu, 26 May 2005 16:20:06 -0700 (PDT) > Attached below is a kernel patch to provide UDP LSO(Large Send Offload) > feature. Interesting patch, thanks a lot. Some quick review: 1) I think you can use skb_shinfo(skb)->tso_size, and UDP packet with this non-zero will never be sent unless the driver indicates the capability. 2) I think NETIF_F_USO is a nicer name and consistent with the existing NETIF_F_TSO macro name. Please change it. 3) Make NETIF_F_USO require both NETIF_F_SG and checksumming capability. Check this at device registry, and ethtool operation time, so that you need not verify it during packet send. For #3, it should be a simple change to net/core/dev.c and net/core/ethtool.c, for example see this test we have in net/core/dev.c:register_netdevice() /* TSO requires that SG is present as well. */ if ((dev->features & NETIF_F_TSO) && !(dev->features & NETIF_F_SG)) { printk("%s: Dropping NETIF_F_TSO since no SG feature.\n", dev->name); dev->features &= ~NETIF_F_TSO; } Just make the same exact check for NETIF_F_USO. Similarly, you'll need to add the necessary ethtool machinery (missing from your patch, but really needed) then do something similar to net/core/ethtool.c:ethtool_set_tso() for ethtool setting of NETIF_F_USO. Probably you'll name this function ethtool_set_uso() :-) From davem@davemloft.net Thu May 26 16:43:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 16:43:11 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4QNh8Xq006304 for ; Thu, 26 May 2005 16:43:08 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbRzW-0005WM-4J; Thu, 26 May 2005 16:42:18 -0700 Date: Thu, 26 May 2005 16:42:17 -0700 (PDT) Message-Id: <20050526.164217.45745005.davem@davemloft.net> To: ravinandan.arakali@neterion.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, raghavendra.koushik@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature From: "David S. Miller" In-Reply-To: <20050526232006.60E6365005@linux.site> References: <20050526232006.60E6365005@linux.site> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 516 Lines: 16 sock_append_data() seems like a lot of wasted work. We already pass around the fragmented SKB as a list chained by skb_shinfo(skb)->fraglist, just pass this thing to the device and in this way you'll avoid all of that work sock_append_data() does entirely. Or is there a reason you did not implement it this way? This is one of the uses the skb_shinfo(skb)->fraglist was intended for. IN FACT, this fragmentation offload you are implementing here is what the feature bit NETIF_F_FRAGLIST was meant to indicate. From herbert@gondor.apana.org.au Thu May 26 17:13:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 17:13:24 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R0DGXq007838 for ; Thu, 26 May 2005 17:13:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DbSRs-0004k5-00; Fri, 27 May 2005 10:11:37 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DbSRf-0004Jv-00; Fri, 27 May 2005 10:11:23 +1000 Date: Fri, 27 May 2005 10:11:23 +1000 To: Ganesh Venkatesan Cc: "Venkatesan, Ganesh" , Andrew Morton , Jian Jun He , anton@samba.org, rende@cn.ibm.com, "Brandeburg, Jesse" , jgarzik@pobox.com, wangjs@cn.ibm.com, "Ronciak, John" , cdlwangl@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-ID: <20050527001123.GA16594@gondor.apana.org.au> References: <468F3FDA28AA87429AD807992E22D07E056F6B37@orsmsx408> <20050526213421.GA8077@gondor.apana.org.au> <5fc59ff30505261608541b74fb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fc59ff30505261608541b74fb@mail.gmail.com> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 683 Lines: 19 On Thu, May 26, 2005 at 04:08:17PM -0700, Ganesh Venkatesan wrote: > > I do not get it. Bear with my ignorance. > > e100_tx_timeout does not call e100_down. > > It is called from e100_tx_timeout_task which is invoked as a result of > schedule_work. Are you saying that it would still not have the right > context to call netif_disable_poll()? Sorry, I was not aware that you've already added the sched work in the driver. With that it should work correctly. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu May 26 17:22:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 17:22:41 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R0MYXq008700 for ; Thu, 26 May 2005 17:22:34 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DbSax-0004o1-00; Fri, 27 May 2005 10:20:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DbSau-0004Ld-00; Fri, 27 May 2005 10:20:56 +1000 Date: Fri, 27 May 2005 10:20:56 +1000 To: Ganesh Venkatesan Cc: "Venkatesan, Ganesh" , Andrew Morton , Jian Jun He , anton@samba.org, rende@cn.ibm.com, "Brandeburg, Jesse" , jgarzik@pobox.com, wangjs@cn.ibm.com, "Ronciak, John" , cdlwangl@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-ID: <20050527002056.GA16644@gondor.apana.org.au> References: <468F3FDA28AA87429AD807992E22D07E056F6B37@orsmsx408> <20050526213421.GA8077@gondor.apana.org.au> <5fc59ff30505261608541b74fb@mail.gmail.com> <20050527001123.GA16594@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527001123.GA16594@gondor.apana.org.au> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 648 Lines: 16 On Fri, May 27, 2005 at 10:11:23AM +1000, herbert wrote: > > Sorry, I was not aware that you've already added the sched work > in the driver. With that it should work correctly. BTW, I was just checking out your sched work code. There needs to be synchronisation between the tx_timeout task and the stop method. Otherwise they can race against each other or worse tx_timeout could keep running even after stop has finished. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ganesh.venkatesan@intel.com Thu May 26 17:30:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 17:30:40 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R0UXXq009320 for ; Thu, 26 May 2005 17:30:34 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4R0SvwC031951; Fri, 27 May 2005 00:28:57 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4R0SiiY029399; Fri, 27 May 2005 00:28:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052617285713247 ; Thu, 26 May 2005 17:28:57 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 17:28:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Date: Thu, 26 May 2005 17:28:55 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E056F70D4@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Thread-Index: AcViUgGc4320Xno5QAKI+pMsZKMRbAAALDWQ From: "Venkatesan, Ganesh" To: "Herbert Xu" , "Ganesh Venkatesan" Cc: "Andrew Morton" , "Jian Jun He" , , , "Brandeburg, Jesse" , , , "Ronciak, John" , , , X-OriginalArrivalTime: 27 May 2005 00:28:57.0180 (UTC) FILETIME=[11E2A1C0:01C56253] X-Scanned-By: MIMEDefang 2.44 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4R0UXXq009320 X-archive-position: 1720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1256 Lines: 34 Would adding flush_sheduled_tasks() to e100_down, do it? Ganesh. >-----Original Message----- >From: Herbert Xu [mailto:herbert@gondor.apana.org.au] >Sent: Thursday, May 26, 2005 5:21 PM >To: Ganesh Venkatesan >Cc: Venkatesan, Ganesh; Andrew Morton; Jian Jun He; anton@samba.org; >rende@cn.ibm.com; Brandeburg, Jesse; jgarzik@pobox.com; wangjs@cn.ibm.com; >Ronciak, John; cdlwangl@cn.ibm.com; linuxppc64- >dev@lists.linuxppc.org.sgi.com; netdev@oss.sgi.com >Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running >rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 > >On Fri, May 27, 2005 at 10:11:23AM +1000, herbert wrote: >> >> Sorry, I was not aware that you've already added the sched work >> in the driver. With that it should work correctly. > >BTW, I was just checking out your sched work code. There needs >to be synchronisation between the tx_timeout task and the stop >method. Otherwise they can race against each other or worse >tx_timeout could keep running even after stop has finished. > >Cheers, >-- >Visit Openswan at http://www.openswan.org/ >Email: Herbert Xu ~{PmV>HI~} >Home Page: http://gondor.apana.org.au/~herbert/ >PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Thu May 26 17:52:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 17:52:27 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R0qMXq010697 for ; Thu, 26 May 2005 17:52:23 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id EA53033CC2; Fri, 27 May 2005 09:54:26 +0900 (JST) Date: Fri, 27 May 2005 09:54:26 +0900 (JST) Message-Id: <20050527.095426.115036280.yoshfuji@linux-ipv6.org> To: davem@davemloft.net, jgarzik@pobox.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [NET] 2.6.x build warning From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <42961EDB.7000407@pobox.com> References: <42961EDB.7000407@pobox.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1324 Lines: 37 In article <42961EDB.7000407@pobox.com> (at Thu, 26 May 2005 15:09:15 -0400), Jeff Garzik says: > from current git tree: > > net/ipv6/ip6_flowlabel.c: In function `ipv6_flowlabel_opt': > net/ipv6/ip6_flowlabel.c:540: warning: ignoring return value of > `copy_to_user', declared with attribute warn_unused_result As before, it is intentional. Okay, let's just waste the result for avoiding the warning. Signed-off-by: YOSHIFUJI Hideaki Index: net/ipv6/ip6_flowlabel.c =================================================================== --- 30b3bda5e47d088b46ab8eab4d69d059a71197e1/net/ipv6/ip6_flowlabel.c (mode:100644) +++ uncommitted/net/ipv6/ip6_flowlabel.c (mode:100644) @@ -535,10 +535,11 @@ if (err) goto done; - /* Do not check for fault */ - if (!freq.flr_label) - copy_to_user(&((struct in6_flowlabel_req __user *) optval)->flr_label, - &fl->label, sizeof(fl->label)); + if (!freq.flr_label) { + /* Do not check for fault */ + int dummy = copy_to_user(&((struct in6_flowlabel_req __user *) optval)->flr_label, + &fl->label, sizeof(fl->label)); + } sfl1->fl = fl; sfl1->next = np->ipv6_fl_list; -- YOSHIFUJI Hideaki @ USAGI Project GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From john.ronciak@intel.com Thu May 26 18:05:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 18:06:03 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R15qXq011944 for ; Thu, 26 May 2005 18:05:55 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4R155Wx014048 for ; Fri, 27 May 2005 01:05:05 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4R153iI015099 for ; Fri, 27 May 2005 01:05:04 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052618050416925 for ; Thu, 26 May 2005 18:05:04 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 18:05:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: NAPI packet weighting patch Date: Thu, 26 May 2005 18:05:02 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0450BF67@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NAPI packet weighting patch Thread-Index: AcViOvhx71tBCIJCTmOI9av9cWiRZwAHOOGw From: "Ronciak, John" To: "Williams, Mitch A" , Cc: "Venkatesan, Ganesh" , "Brandeburg, Jesse" X-OriginalArrivalTime: 27 May 2005 01:05:04.0692 (UTC) FILETIME=[1DD2B740:01C56258] X-Scanned-By: MIMEDefang 2.44 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4R15qXq011944 X-archive-position: 1722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: john.ronciak@intel.com Precedence: bulk X-list: netdev Content-Length: 6779 Lines: 202 Are the systems that don't see any difference slower (older?) machines? I'm wondering what could be the cause of this. It seems like it should always work. I think we need to figure out why there is no difference on some systems. Just my 2 cents. Cheers, John > -----Original Message----- > From: Mitch Williams [mailto:mitch.a.williams@intel.com] > Sent: Thursday, May 26, 2005 2:36 PM > To: netdev@oss.sgi.com > Cc: Ronciak, John; Venkatesan, Ganesh; Brandeburg, Jesse > Subject: RFC: NAPI packet weighting patch > > > The following patch (which applies to 2.6.12rc4) adds a new sysctl > parameter called 'netdev_packet_weight'. This parameter > controls how many > backlog work units each RX packet is worth. > > With the parameter set to 0 (the default), NAPI polling works > exactly as > it does today: each packet is worth one backlog work unit, and the > maximum number of received packets that will be processed in any given > softirq is controlled by the 'netdev_max_backlog' parameter. > > By setting the netdev_packet_weight to a nonzero value, we make each > packet worth more than one backlog work unit. Since it's a > shift value, a > setting of 1 makes each packet worth 2 work units, a setting > of 2 makes > each packet worth 4 units, etc. Under normal circumstances you would > never use a value higher than 3, though 4 might work for > Gigabit and 10 > Gigabit networks. > > By increasing the packet weight, we accomplish two things: first, we > cause the individual NAPI RX loops in each driver to process fewer > packets. This means that they will free up RX resources to > the hardware > more often, which reduces the possibility of dropped packets. > Second, it > shortens the total time spent in the NAPI softirq, which can > free the CPU > to handle other tasks more often, thus reducing overall latency. > > Performance tests in our lab have shown that tweaking this parameter, > along with the netdev_max_backlog parameter, can provide significant > performance increase -- greater than 100Mbps improvement -- > over default > settings. I tested with both e1000 and tg3 drivers and saw > improvement in > both cases. I did not see higher CPU utilization, even with > the increased > throughput. > > The caveat, of course, is that different systems and network > configurations require different settings. On the other hand, that's > really no different than what we see with the max_backlog > parameter today. > On some systems neither parameter makes any difference. > > Still, we feel that there is value to having this in the > kernel. Please > test and comment as you have time available. > > Thanks! > -Mitch Williams > mitch.a.williams@intel.com > > > > > diff -urpN -x dontdiff > rc4-clean/Documentation/filesystems/proc.txt > linux-2.6.12-rc4/Documentation/filesystems/proc.txt > --- rc4-clean/Documentation/filesystems/proc.txt > 2005-05-18 16:35:43.000000000 -0700 > +++ linux-2.6.12-rc4/Documentation/filesystems/proc.txt > 2005-05-19 11:16:10.000000000 -0700 > @@ -1378,7 +1378,13 @@ netdev_max_backlog > ------------------ > > Maximum number of packets, queued on the INPUT side, > when the interface > -receives packets faster than kernel can process them. > +receives packets faster than kernel can process them. This > is also the > +maximum number of packets handled in a single softirq under NAPI. > + > +netdev_packet_weight > +-------------------- > +The value, in netdev_max_backlog unit, of each received > packet. This is a > +shift value, and should be set no higher than 3. > > optmem_max > ---------- > diff -urpN -x dontdiff rc4-clean/include/linux/sysctl.h > linux-2.6.12-rc4/include/linux/sysctl.h > --- rc4-clean/include/linux/sysctl.h 2005-05-18 > 16:36:06.000000000 -0700 > +++ linux-2.6.12-rc4/include/linux/sysctl.h 2005-05-18 > 16:44:07.000000000 -0700 > @@ -242,6 +242,7 @@ enum > NET_CORE_MOD_CONG=16, > NET_CORE_DEV_WEIGHT=17, > NET_CORE_SOMAXCONN=18, > + NET_CORE_PACKET_WEIGHT=19, > }; > > /* /proc/sys/net/ethernet */ > diff -urpN -x dontdiff rc4-clean/net/core/dev.c > linux-2.6.12-rc4/net/core/dev.c > --- rc4-clean/net/core/dev.c 2005-05-18 16:36:07.000000000 -0700 > +++ linux-2.6.12-rc4/net/core/dev.c 2005-05-19 > 11:16:57.000000000 -0700 > @@ -1352,6 +1352,7 @@ out: > > ============================================================== > =========*/ > > int netdev_max_backlog = 300; > +int netdev_packet_weight = 0; /* each packet is worth 1 > backlog unit */ > int weight_p = 64; /* old backlog weight */ > /* These numbers are selected based on intuition and some > * experimentatiom, if you have more scientific way of doing this > @@ -1778,6 +1779,7 @@ static void net_rx_action(struct softirq > struct softnet_data *queue = &__get_cpu_var(softnet_data); > unsigned long start_time = jiffies; > int budget = netdev_max_backlog; > + int budget_temp; > > > local_irq_disable(); > @@ -1793,21 +1795,22 @@ static void net_rx_action(struct softirq > dev = list_entry(queue->poll_list.next, > struct net_device, poll_list); > netpoll_poll_lock(dev); > - > - if (dev->quota <= 0 || dev->poll(dev, &budget)) { > + budget_temp = budget; > + if (dev->quota <= 0 || dev->poll(dev, &budget_temp)) { > netpoll_poll_unlock(dev); > local_irq_disable(); > list_del(&dev->poll_list); > list_add_tail(&dev->poll_list, > &queue->poll_list); > if (dev->quota < 0) > - dev->quota += dev->weight; > + dev->quota += dev->weight >> > netdev_packet_weight; > else > - dev->quota = dev->weight; > + dev->quota = dev->weight >> > netdev_packet_weight; > } else { > netpoll_poll_unlock(dev); > dev_put(dev); > local_irq_disable(); > } > + budget -= (budget - budget_temp) << > netdev_packet_weight; > } > out: > local_irq_enable(); > diff -urpN -x dontdiff rc4-clean/net/core/sysctl_net_core.c > linux-2.6.12-rc4/net/core/sysctl_net_core.c > --- rc4-clean/net/core/sysctl_net_core.c 2005-03-01 > 23:38:03.000000000 -0800 > +++ linux-2.6.12-rc4/net/core/sysctl_net_core.c > 2005-05-18 16:44:09.000000000 -0700 > @@ -13,6 +13,7 @@ > #ifdef CONFIG_SYSCTL > > extern int netdev_max_backlog; > +extern int netdev_packet_weight; > extern int weight_p; > extern int no_cong_thresh; > extern int no_cong; > @@ -91,6 +92,14 @@ ctl_table core_table[] = { > .proc_handler = &proc_dointvec > }, > { > + .ctl_name = NET_CORE_PACKET_WEIGHT, > + .procname = "netdev_packet_weight", > + .data = &netdev_packet_weight, > + .maxlen = sizeof(int), > + .mode = 0644, > + .proc_handler = &proc_dointvec > + }, > + { > .ctl_name = NET_CORE_MAX_BACKLOG, > .procname = "netdev_max_backlog", > .data = &netdev_max_backlog, > From herbert@gondor.apana.org.au Thu May 26 18:28:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 18:28:48 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R1ScXq012832 for ; Thu, 26 May 2005 18:28:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DbTcT-0005BW-00; Fri, 27 May 2005 11:26:37 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DbTcI-0004VE-00; Fri, 27 May 2005 11:26:26 +1000 Date: Fri, 27 May 2005 11:26:26 +1000 To: "Venkatesan, Ganesh" Cc: Ganesh Venkatesan , Andrew Morton , Jian Jun He , anton@samba.org, rende@cn.ibm.com, "Brandeburg, Jesse" , jgarzik@pobox.com, wangjs@cn.ibm.com, "Ronciak, John" , cdlwangl@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-ID: <20050527012626.GA17294@gondor.apana.org.au> References: <468F3FDA28AA87429AD807992E22D07E056F70D4@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <468F3FDA28AA87429AD807992E22D07E056F70D4@orsmsx408> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 520 Lines: 14 On Thu, May 26, 2005 at 05:28:55PM -0700, Venkatesan, Ganesh wrote: > Would adding flush_sheduled_tasks() to e100_down, do it? Even though it might be OK it's probably not a good idea to have the task flush itself while it's running. If you put it in the e100_close function then it should be fine. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From akpm@osdl.org Thu May 26 18:47:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 18:47:09 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R1l4Xq014011 for ; Thu, 26 May 2005 18:47:05 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4R1jQjA023560 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 May 2005 18:45:27 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4R1jP5O026853; Thu, 26 May 2005 18:45:25 -0700 Date: Thu, 26 May 2005 18:44:36 -0700 From: Andrew Morton To: Herbert Xu Cc: ganesh.venkatesan@intel.com, ganesh.venkatesan@gmail.com, hejianj@cn.ibm.com, anton@samba.org, rende@cn.ibm.com, jesse.brandeburg@intel.com, jgarzik@pobox.com, wangjs@cn.ibm.com, john.ronciak@intel.com, cdlwangl@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-Id: <20050526184436.161a6af0.akpm@osdl.org> In-Reply-To: <20050527012626.GA17294@gondor.apana.org.au> References: <468F3FDA28AA87429AD807992E22D07E056F70D4@orsmsx408> <20050527012626.GA17294@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 337 Lines: 9 Herbert Xu wrote: > > On Thu, May 26, 2005 at 05:28:55PM -0700, Venkatesan, Ganesh wrote: > > Would adding flush_sheduled_tasks() to e100_down, do it? > > Even though it might be OK it's probably not a good idea to have > the task flush itself while it's running. flush_workqueue() handles that case. From jgarzik@pobox.com Thu May 26 19:17:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 19:17:47 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R2HhXq015111 for ; Thu, 26 May 2005 19:17:44 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DbUP6-000384-AY; Fri, 27 May 2005 02:16:52 +0000 Message-ID: <42968312.90901@pobox.com> Date: Thu, 26 May 2005 22:16:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Grant Grundler , akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> <20050521223959.GA4337@electric-eye.fr.zoreil.com> In-Reply-To: <20050521223959.GA4337@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 818 Lines: 28 Francois Romieu wrote: > Jeff Garzik : > [tulip_media_select] > >>1) called from timer context, from the media poll timer >> >>2) called from spin_lock_irqsave() context, in the ->tx_timeout hook. >> >>The first case can be fixed by moved all the timer code to a workqueue. >> Then when the existing timer fires, kick the workqueue. >> >>The second case can be fixed by kicking the workqueue upon tx_timeout >>(which is the reason why I did not suggest queue_delayed_work() use). > > > First try below. It only moves tulip_select_media() to process context. > The original patch (with s/udelay/msleep/ or such) is not included. > > Patch applies/compiles against 2.6.12-rc4. Looks pretty good to me, at first look. I'll give it some thought, and probably apply it, in a few days. Jeff From leonid.grossman@neterion.com Thu May 26 20:03:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 20:03:45 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R33fXq017804 for ; Thu, 26 May 2005 20:03:42 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j4R32oOC010085; Thu, 26 May 2005 23:02:50 -0400 (EDT) Received: from lgt40 ([10.16.16.164]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j4R32lVG027513; Thu, 26 May 2005 23:02:48 -0400 (EDT) Message-Id: <200505270302.j4R32lVG027513@guinness.s2io.com> From: "Leonid Grossman" To: Cc: , Subject: [ANNOUNCE] Neterion(S2io) 10GbE Xframe Programming Manual posted Date: Thu, 26 May 2005 20:02:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050316123828.0eb78fd3@dxpl.pdx.osdl.net> Thread-index: AcUqaCoHOAO/D8XARRqfYUJtF8+jWg39dEOQ X-Scanned-By: MIMEDefang 2.34 X-archive-position: 1726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 450 Lines: 10 For people interested in "s2io" 10GbE driver, the programming manual for Xframe-I 10GbE Adapter is now available at ftp: ns1.s2io.com user: "linuxdocs" password: "HALdocs" The relatively small delta between sw-compatible Xframe-II and Xframe-I is not covered in the document, but the current driver supports both adapters. Patches for the extra Xframe-II features will be added over time; One of them (UDP Send Offload) was posted earlier today. From iamatul@comcast.net Thu May 26 22:58:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 22:58:24 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R5w3Xq028804 for ; Thu, 26 May 2005 22:58:21 -0700 Received: from ATULSPC (unknown[67.189.61.219](misconfigured sender)) by comcast.net (rwcrmhc14) with SMTP id <2005052705571101400qq27re>; Fri, 27 May 2005 05:57:12 +0000 Message-ID: <009201c56280$e9b7cd00$0202a8c0@ATULSPC> From: "Atul Sabharwal" To: , "David S. Miller" Cc: , References: <20050526110425.27590eb8@dxpl.pdx.osdl.net><20050526.144638.71091166.davem@davemloft.net><20050526154857.3cb34d11@dxpl.pdx.osdl.net> <20050526.155401.18310361.davem@davemloft.net> Subject: Re: [Bridge] Re: [PATCH] (6/6) bridge: receive path optimization Date: Thu, 26 May 2005 22:57:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-archive-position: 1727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: iamatul@comcast.net Precedence: bulk X-list: netdev Content-Length: 1247 Lines: 37 I have a question about using the 802.1d driver with a switch. I have a managed switch which connects to the Xscale MAC using a Reverse MII interface. It seems that the 802.1d bridge puts the interface into promiscuous mode and needs multiple ethernet devices to work with. Can it work with a single ethernet device which is connected to a BCM5338 ( broadcomm 8 port switch chip ). I understand that I would have to change the STP configuration component to write to the broadcomm chip. The chip supports direct memory mapped I/O of BPDU's using polled xmite/recieve using a SPI interface. Since I use a soft SPI stack, I cannot go faster than 2MHz. Besides this is a serial interface. Suggestion, comments on both choices are highly appreciated. I am working in a custom enviornment with main objective of detecting loops in a cascade of switches. The physical interconnect of the switches could be linear, tree, star or graph topology. Also, the spanning tree needs to reconverge when switches are connected/disconnected. Since there are no interrupts from the BCM5338, most of the implementation would be based of polling. Maybe, a forwarding delay of 5s should work as this is a LAN environment. -- Atul Linux Engineer From netdev@nospam.otaku42.de Thu May 26 23:15:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 26 May 2005 23:15:38 -0700 (PDT) Received: from legolas.otaku42.de (legolas.otaku42.de [217.24.0.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R6FZXq029618 for ; Thu, 26 May 2005 23:15:36 -0700 Received: from dsl-084-058-128-158.arcor-ip.net ([84.58.128.158] helo=[192.168.2.42] ident=otaku) by legolas.otaku42.de with asmtp (Exim 4.20 and XAMS 0.0.11) id 1DbY7E-0008Rd-WD for netdev@oss.sgi.com; Fri, 27 May 2005 08:14:41 +0200 Message-ID: <4296BACF.7030202@otaku42.de> Date: Fri, 27 May 2005 08:14:39 +0200 From: Michael Renzmann User-Agent: Mozilla Thunderbird 1.0 (X11/20050205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Network driver test suite (part 2) X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: netdev@nospam.otaku42.de Precedence: bulk X-list: netdev Content-Length: 519 Lines: 13 Hi all. I vaguely remembered there was a discussion about a test suite which allows to check whether a network driver works as intended. After digging my local message archives I found the thread with the above title, but it seems the thread ceased without any result (apart from a wishlist for such a test suite). Hence my question: is there such a test suite available now? If not, did anyone at least start working on such a project? What do you others usually use to test-drive a network driver? Bye, Mike From romieu@fr.zoreil.com Fri May 27 00:21:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 00:22:01 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R7LuXq004985 for ; Fri, 27 May 2005 00:21:57 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4R7HibI017316; Fri, 27 May 2005 09:17:44 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4R7HaVl017315; Fri, 27 May 2005 09:17:36 +0200 Date: Fri, 27 May 2005 09:17:36 +0200 From: Francois Romieu To: Jeff Garzik Cc: Francois Romieu , Grant Grundler , akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree Message-ID: <20050527071736.GA17185@electric-eye.fr.zoreil.com> References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> <20050521223959.GA4337@electric-eye.fr.zoreil.com> <42968312.90901@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42968312.90901@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 195 Lines: 10 Jeff Garzik : [...] > Looks pretty good to me, at first look. > > I'll give it some thought, and probably apply it, in a few days. An updated version is cooking. -- Ueimor From hejianj@cn.ibm.com Fri May 27 00:33:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 00:33:24 -0700 (PDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.com [202.81.18.186]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R7WtXq005681 for ; Fri, 27 May 2005 00:33:07 -0700 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id j4R7Nbjl249376 for ; Fri, 27 May 2005 17:34:36 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4R6JcgG149404 for ; Fri, 27 May 2005 16:19:39 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11/8.13.3) with ESMTP id j4R6Gglo012248 for ; Fri, 27 May 2005 16:16:43 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av01.au.ibm.com (8.12.11/8.12.11) with ESMTP id j4R6GZhl012125; Fri, 27 May 2005 16:16:37 +1000 In-Reply-To: <20050526133123.47824405.akpm@osdl.org> Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 To: Andrew Morton Cc: anton@samba.org, Dang En Ren , ganesh.venkatesan@gmail.com, ganesh.venkatesan@intel.com, herbert@gondor.apana.org.au, jesse.brandeburg@intel.com, jgarzik@pobox.com, Jia Sen Wang , john.ronciak@intel.com, Lei CDL Wang , linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Jian Jun He Date: Fri, 27 May 2005 14:18:07 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 05/27/2005 14:18:11 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85" X-archive-position: 1730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hejianj@cn.ibm.com Precedence: bulk X-list: netdev Content-Length: 20003 Lines: 505 --0__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: multipart/related; Boundary="1__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85" --1__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: multipart/alternative; Boundary="2__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85" --2__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable hello, I verified the problem on 2.6.12-rc5 with mm1 patch. The test server wo= rks find during the test procedure. So I will close this defect in bugme. Thanks all of your attention on this defect. to Andrew Morton: 1)If you are a register in rhn.redhat.com, you can search the package "rhr2", then you can download rhr2. Also you could download rhr2 from the following links http://people.redhat.com/rlandry/rhr2/test/1.0-17beta/rhr2-1.0-17beta.n= oarch.rpm 2)The attachments are the conf files that I used for rhr2 test. (See attached file: hardware.conf)(See attached file: rhr.conf)(See attached file: system.conf)(See attached file: tests.conf) 3) invoke redhat-ready is ok, no arguments. Best Regards! Jian Jun He CSDL, Beijing Email: hejianj@cn.ibm.com = Andrew Morton = = = To 2005-05-27 04:31 Jian Jun He/China/Contr/IBM@IBMC= N = cc ganesh.venkatesan@intel.com, = anton@samba.org, Dang En = Ren/China/IBM@IBMCN, = ganesh.venkatesan@gmail.com, = herbert@gondor.apana.org.au, = jesse.brandeburg@intel.com, = jgarzik@pobox.com, Jia Sen = Wang/China/IBM@IBMCN, = john.ronciak@intel.com, Lei CDL = Wang/China/Contr/IBM@IBMCN, = linuxppc64-dev@lists.linuxppc.or= g.s gi.com, netdev@oss.sgi.com = Subj= ect Re: Fw: [Bugme-new] [Bug 4628] N= ew: Test server hang while running r= hr (network) test on RHEL4 with ker= nel 2.6.12-rc1-mm4 = = = = = = = Jian Jun He wrote: > > 2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and install > it on > the test machine. > 3. Configure and run the rhr test via invoking redhat-ready. This is the problematic bit. - Please provide a full URL which can be used to obtain rhr. rhn.redhat.com is subscription-based. - Please describe the hardware setup - surely the test requires at leas= t two machines. How are they configured? - Provide an exact transcript of the commands which are to be used. Is= it just redhat-ready with no arguments? All that begin said, we already have a quite specific diagnosis via cod= e inspection, from Herbert: Herbert Xu wrote: > > Andrew Morton wrote: > > > > Might be a bug in the e100 driver, might not be. > > > > I assume this is the > > > > BUG_ON(skb->list !=3D NULL); > > It certainly is a bug in e100. > > e100_tx_timeout -> e100_down -> e100_rx_clean_list > > is racing against > > e100_poll -> e100_rx_clean -> e100_rx_indicate > > e100_rx_clean/e100_rx_indicate takes an skb off the RX ring and > while it's being processed e100_rx_clean_list comes along and > frees it. > > From a quick check similar problems may exist in other drivers that > have lockless ->poll() functions with RX rings. Do the e100 maintainers agree with this diagnosis? If so then more tes= ting isn't required at this stage - the next step is to fix the above bug, n= o? = --2__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

hello,

I verified the problem on 2.6.12-rc5 with mm1 patch. The test server wo= rks find during the test procedure.
So I will close this defect in bugme.

Thanks all of your attention on this defect.


to Andrew Morton:

1)If you are a register in rhn.redhat.com, you can search the package &= quot;rhr2", then you can download rhr2.
Also you could download rhr2 from the following links http://people.redhat.com/rlandry/rhr2/test/1.0-17beta/rhr2-1.0-17b= eta.noarch.rpm

2)The attachments are the conf files that I used for rhr2 test.


(See attached file: hardware.conf)(See attached file: rhr.con= f)(See attached file: system.conf)(See attached file: tes= ts.conf)
3) invoke redhat-ready is ok, no arguments.

Best Regards!

Jian Jun He

CSDL, Beijing
Email: hejianj@cn.ibm.com

3D"InactiveAndrew Morton <akpm@osdl.org>
=

=
          Andrew Morton <akpm@osdl.org><= font size=3D"2">

          2005-05-27 04:31

 =
3D""
To
3D""
Jian Jun He/China/Contr/IBM@IBMCN
3D""
cc
3D""
ganesh.venkatesan@intel.com, anton@samba.org, Dang En = Ren/China/IBM@IBMCN, ganesh.venkatesan@gmail.com, herbert@gondor.apana.= org.au, jesse.brandeburg@intel.com, jgarzik@pobox.com, Jia Sen Wang/Chi= na/IBM@IBMCN, john.ronciak@intel.com, Lei CDL Wang/China/Contr/IBM@IBMC= N, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com=
3D""
Subject
3D""
Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang w= hile running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
3D=3D""

Jian Jun He <hejianj@cn.ibm.com> wrote:
>
>  2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.co= m and install
>  it on
>  the test machine.
>  3. Configure and run the rhr test via invoking redhat-ready.=

This is the problematic bit.

- Please provide a full URL which can be used to obtain rhr.
 rhn.redhat.com is subscription-based.

- Please describe the hardware setup - surely the test requires at leas= t
 two machines.  How are they configured?

- Provide an exact transcript of the commands which are to be used. &nb= sp;Is
 it just

redhat-ready

 with no arguments?



All that begin said, we already have a quite specific diagnosis via cod= e
inspection, from Herbert:


Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > Might be a bug in the e100 driver, might not be.
> >
> > I assume this is the
> >
> >        BUG_ON(skb->list !=3D NULL); >
> It certainly is a bug in e100.
>
> e100_tx_timeout -> e100_down -> e100_rx_clean_list
>
> is racing against
>
> e100_poll -> e100_rx_clean -> e100_rx_indicate
>
> e100_rx_clean/e100_rx_indicate takes an skb off the RX ring and > while it's being processed e100_rx_clean_list comes along and
> frees it.
>
> From a quick check similar problems may exist in other drivers tha= t
> have lockless ->poll() functions with RX rings.

Do the e100 maintainers agree with this diagnosis?  If so then mor= e testing
isn't required at this stage - the next step is to fix the above bug, n= o?


= --2__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85-- --1__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <5__=C7BBFA9DDF8DBA858f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --1__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: image/gif; name="pic09902.gif" Content-Disposition: inline; filename="pic09902.gif" Content-ID: <6__=C7BBFA9DDF8DBA858f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --1__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <7__=C7BBFA9DDF8DBA858f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --1__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85-- --0__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: application/octet-stream; name="hardware.conf" Content-Disposition: attachment; filename="hardware.conf" Content-ID: <1__=C7BBFA9DDF8DBA858f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 IwojIGhhcmR3YXJlLmNvbmYgLSBnZW5lcmF0ZWQgb24gRnJpIE1heSAyNyAwMDo0MTo0NiBFRFQg MjAwNQojCgojIERFU0NSSVBUSU9OOiAgVGhpcyBmaWxlIGNvbnRhaW5zIHRoZSBoYXJkd2FyZSBj bGFzcyBmb2xsb3dlZCBieSBhbnkgb3B0aW9ucwojIHJlcXVpcmVkIGJ5IHRoYXQgY2xhc3MgdGVz dHM7IHVzdWFsbHkgdG8gaW5jbHVkZSB0aGUgZGV2aWNlIG9yIG51bWJlciBvZgojIGRldmljZXMg dG8gdGVzdHMuCiMKIyBDSEFOR0VTOiAgVGhlIGxhcmdlc3QgY2hhbmdlIGlzIHRoYXQgdGhpcyBm aWxlIGlzIG5vdyBnZW5lcmF0ZWQgaW5zdGVhZCBvZgojIG1hbnVhbGx5IHBvcHVsYXRlZC4gIFdp dGggYW55IGx1Y2sgdGhpcyBzaG91bGQgYXZvaWQgdGhlIG5lZWQgZm9yIGEgcGVyc29uCiMgdG8g ZmlndXJlIGl0IG91dC4gIFRoZSBmb3JtYXQgaXMgbGFyZ2VseSBpbiB0YWN0IChjb21wYXJlZCB3 aXRoIHJoci5jb25mKSAKIyB3aXRoIHR3byBleGNlcHRpb25zOyB0aGUgcmVxdWlyZW1lbnQgdG8g bGlzdCB0aGUgc2FtZSBkZXZpY2UgbXVsdGlwbGUgdGltZXMKIyBoYXMgYmVlbiBsaWZ0ZWQgKHlv dSBtYXkgbm93IGFzc3VtZSB0aGUgdGVzdHMgd2lsbCBkbyB0aGUgcmlnaHQgdGhpbmcpIGFuZAoj IHRoZSB0ZXN0IHNwZWNpZmljIGNvbmZpZ3VyYXRpb24gZGF0YSBpcyBub3cgaW4gL2V0Yy9yaHIv dGVzdHMuY29uZjsgbW9yZSBha2luCiMgdG8gcmhyLWNydXNoIGFuZCBpdHMgL2V0Yy9yaHIva2Vy bmVsLgoKIyBORVRXT1JLIGlmMSBbLi4uaWZOXQojICAgUmVxdWlyZXMgYSBzZXJ2ZXIgYW5kIHJl bW90ZSB1c2VyIGFzIGNvbmZpZ3VyZWQgaW4gL2V0Yy9yaHIvdGVzdHMuY29uZi4KIyAgIFRoZSBy ZW1vdGUgdXNlciB3aWxsIG5lZWQgYWIgYW5kIG1vdW50IHByaXZpbGVnZXM7IHRoZSBzZXJ2ZXIg aXMgZXhwZWN0ZWQKIyAgIHRvIE5PVCBiZSBpbiBhIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQgYXMg bm8gcGFzc3dvcmQgbG9naW5zIGFyZSBlbmFibGVkCiMgICBkdXJpbmcgdGVzdGluZy4KIwojICpO T1RFOiBPbiBzMzkwL3MzOTB4IHlvdSBtYXkgbmVlZCB0byBtYW51YWxseSBjcmVhdGUgdGhlIG5l dHdvcmsgc2NyaXB0cy4KIyAgICAgICAgU2VlIHRoZSBSRUxFQVNFLU5PVEVTIGZvciBkZXRhaWxz LgpORVRXT1JLIGV0aDAoMTAwKQoKIyBTVE9SQUdFIC0gbGlzdCBkZXZpY2VzOyBpbmNsdWRlcyBi b3RoIGZpeGVkIGRpc2tzLCByZW1vdmFibGUsIGFuZCBNVEQncy4KU1RPUkFHRSBzZGMKCiMgQ09S RSAobm8gcGFyYW1ldGVycykKIyAgIFdoaWxlIHRoZXJlIG5vIHBhcmFtZXRlcnMgaGVyZTsgYSBr ZXJuZWwgc291cmNlIFJQTSBwYWNrYWdlIGlzIHJlcXVpcmVkIGZvciAjICAgdGVzdGluZy4gIFRo ZSBwYWNrYWdlIGxvY2F0aW9uIGlzIGNvbmZpZ3VyZWQgaW4gL2V0Yy9yaHIvdGVzdHMuY29uZiBh bmQgaXMKIyAgIHNoYXJlZCBieSBNRU1PUlkKQ09SRSAKCiMgTUVNT1JZIChubyBwYXJhbWV0ZXJz KQojICAgV2hpbGUgdGhlcmUgbm8gcGFyYW1ldGVycyBoZXJlOyBhIGtlcm5lbCBzb3VyY2UgUlBN IHBhY2thZ2UgaXMgcmVxdWlyZWQgZm9yICMgICB0ZXN0aW5nLiAgVGhlIHBhY2thZ2UgbG9jYXRp b24gaXMgY29uZmlndXJlZCBpbiAvZXRjL3Joci90ZXN0cy5jb25mIGFuZCBpcwojICAgc2hhcmVk IGJ5IENPUkUuCk1FTU9SWSAKCg== --0__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: application/octet-stream; name="rhr.conf" Content-Disposition: attachment; filename="rhr.conf" Content-ID: <2__=C7BBFA9DDF8DBA858f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 IwojIHJoci5jb25mIC0gZ2VuZXJhdGVkIFN1biBBdWcgMTAgMjM6MDQ6NDUgRURUIDIwMDMKIwoK IyBEZXNjcmlwdGlvbjogIEFsbG93cyBmb3IgdGhlIHVzZSBvZiBhbHRlcm5hdGUgbG9jYXRpb25z IGZvciB0aGUgc2NyYXRjaCBhbmQKIyByZXN1bHQgZmlsZXMuICBUaGlzIHByZXZlbnRzIHRoZSBu ZWVkIGZvciBiaW5kLW1vdW50cyBhbmQgYW55IG90aGVyIHZvb2RvbwojIHRoYXQgY291bGQgYWR2 ZXJzZWx5IGVmZmVjdCB0aGUgdGVzdHMuICBEZWZhdWx0cyBoYXZlIGJlZW4gY29kZWQgaW50byB0 aGUKIyBhcHBsaWNhdGlvbiBzbyBjb25maWd1cmF0aW9uIGlzIG5vdCByZXF1aXJlZC4gIFRvIG92 ZXJyaWRlIHRoZXNlIHZhbHVlcywKIyB1bmNvbW1lbnQgdGhlIHNldHRpbmcgbGluZSBhbmQgbW9k aWZ5IGFzIG5lZWRlZC4KCiMgcnVudGltZSB0ZW1wb3JhcnkgZmlsZXMuClNDUkFUQ0g9L3RtcC9y aHIKCiMgcmVzdWx0cyBwYWNrYWdlIGxvY2F0aW9uLgpSRVNVTFRTPS9yZWRoYXRyZWFkeQo= --0__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: application/octet-stream; name="system.conf" Content-Disposition: attachment; filename="system.conf" Content-ID: <3__=C7BBFA9DDF8DBA858f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 IwojIHN5c3RlbS5jb25mIC0gZ2VuZXJhdGVkIG9uIEZyaSBNYXkgMjcgMDA6NDE6MzUgRURUIDIw MDUKIyAKCiMgREVTQ1JJUFRJT046ICBDb250YWlucyB0aGUgbWFrZS9tb2RlbC9yZWxlYXNlIGNv bWJpbmF0aW9uIGZvciBIQ0wgbGlzdGluZwojIGFuZCByZXN1bHRzIHBhY2thZ2UgY3JlYXRpb24u IAoKTUFLRT0ibWFrZSIKTU9ERUw9IklCTSw5MTI0LTcyMCIKUkhSRUxFQVNFPSJOYWhhbnQiCg== --0__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85 Content-type: application/octet-stream; name="tests.conf" Content-Disposition: attachment; filename="tests.conf" Content-ID: <4__=C7BBFA9DDF8DBA858f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 IwojIHRlc3RzLmNvbmYgLSB0ZXN0IHNwZWNpZmljIGNvbmZpZ3VyYXRpb24gZmlsZQojCgoKIwoj IENPUkUKIwojICBTUlBNIC0gUmVxdWlyZWQga2VybmVsIHNvdXJjZSBycG0gcGFja2FnZTsgaWYg bm90IHNldCwgQ09SRSB3aWxsIGF0dGVtcHQKIyAgICAgICAgIHRvIGxvY2F0ZSBhbmQgdXNlIHRo ZSBmaXJzdCBrZXJuZWwtKi5zcmMucnBtIGZpbGUgaXQgZmluZCBpbiAvdG1wLgojClNSUE09Ii90 bXAva2VybmVsLTIuNi45LTEuOTA2LjIuMV9FTC5wYXRjaHRlc3QuMTUuc3JjLnJwbSIKCiMKIyBD RFJPTQojCiMgIElTTyAtIFVzZWQgZm9yIGNkLXIgYW5kIGNkLXJ3IHRlc3Rpbmc7IGNkcm9tIHRl c3RpbmcgcmVxdWlyZXMgYSBwaHlzaWNhbCBDRC4KIyAgICAgICAgV2UncmUgbm90IHNwZWNpZmlj IG9uIHdoYXQgaGFzIHRvIGJlIG9uIHRoZSBpc287IGhvd2V2ZXIgaXQgc2hvdWxkIGJlCiMgICAg ICAgIG9mIGEgcmVhc29uYWJsZSBzaXplLiAgR2VuZXJhbGx5IHdlIHJlY29tZW5kIGRpc2MgMSBv ZiB0aGUgaW5zdGFsbCBzZXQuCiMgICAgICAgIExpa2UgU1JQTSBhYm92ZTsgaWYgbm90IHNldCB3 ZSdsbCBzZXR0bGUgZm9yIHdoYXQgd2UgY2FuIGZpbmQgaW4gL3RtcC4KIwojICBOT1RFOiBJRiBj ZC1yKHcpIGFuZCBkdmQtcih3KSBhcmUgdG8gYmUgcnVuIGluIHRoZSBzYW1lIHBhc3MsIGVhY2gg aXNvCiMgICAgICAgIG11c3QgYmUgc3BlY2lmaWVkIGJlbG93LgojCiNDRElTTz0iL3RtcC90YXJv b24taTM4Ni1hcy1kaXNjMS5pc28iCiNEVkRJU089Ii90bXAvdGFyb29uLWkzODYtYXMtZGlzYzEu aXNvIgoKCiMKIyBORVRXT1JLOgojCiMgIFJIUlVTRVIgLSBUaGUgdXNlciB1c2VkIHRvIGxvZyBp bnRvIHRoZSByZW1vdGUgbWFjaGluZTsgc2hvdWxkIGhhdmUKIyAgICAgICAgICAgIGFuIHNzaCBz aGVsbCBhY2NvdW50IGFuZCBwZXJtaXNzaW9ucyB0byBleGVjdXRlIGFiIChhcGFjaGUgYmVuY2gp LAojICAgICAgICAgICAgYW5kIG1vdW50IGZpbGUgc3lzdGVtcy4gIFRoZSBkZWZhdWx0IHVzZXIg aXMgcm9vdC4KIwpSSFJVU0VSPSJyb290IgojCiMgIFNFUlZFUiAtIFRoZSByZW1vdGUgbWFjaGlu ZSB0byBiZSBjb250YWN0ZWQ7IHNob3VsZCBjb250YWluIHRoZSBSSFJVU0VSIGFuZAojICAgICAg ICAgICBoYXZlIGFwYWNoZSBiZW5jaCAoYWIpIGFuZCBiZSBhYmxlIHRvIG1vdW50IE5GUzsgZGVm YXVsdHMgdG8KIyAgICAgICAgICAgMTkyLjE2OC4wLjEuCiMKU0VSVkVSPSI5LjMuMTg5LjYxIgo= --0__=C7BBFA9DDF8DBA858f9e8a93df938690918cC7BBFA9DDF8DBA85-- From laforge@netfilter.org Fri May 27 00:38:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 00:39:00 -0700 (PDT) Received: from ganesha.gnumonks.org (ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R7cqXq006359 for ; Fri, 27 May 2005 00:38:53 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1DbZPs-0003IX-Qh; Fri, 27 May 2005 09:38:00 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DbZPq-0000iE-By; Fri, 27 May 2005 09:37:58 +0200 Date: Fri, 27 May 2005 09:37:58 +0200 From: Harald Welte To: Herbert Xu Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, jmorris@redhat.com Subject: Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path Message-ID: <20050527073758.GP13114@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , Herbert Xu , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, jmorris@redhat.com References: <20050526142420.GD13114@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jZB9q6GuZX3GwDM8" Content-Disposition: inline In-Reply-To: User-Agent: mutt-ng 1.5.8-r168i (Debian) X-archive-position: 1731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1882 Lines: 49 --jZB9q6GuZX3GwDM8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2005 at 07:38:57AM +1000, Herbert Xu wrote: > Harald Welte wrote: > >=20 > > The patch below adds an additional queue for ip_queue verdicts. They > > come up from userspace, are appended to a queue which is then processed > > by a tasklet. The tasklet itself runs in softirq context, so when timer > > hardirq leaves, no tcp_delack_timer() will be executed until > > nf_reinject() has finished. >=20 > This seems to be overly complicated if all you want is to do this in > softirq context. What's wrong with simply alling local_bh_disable? Patrick just pointed this out, too. I wasn't sure whether local_bh_disable() would make the context really look like softirq in every way. If yes, it would certainly solve the problem, because in_interrupt() at hardirq-exit would be true and therefore the timer softirq not scheduled immediately. I'll have Astaro test this variant. --=20 - Harald Welte http://netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --jZB9q6GuZX3GwDM8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCls5WXaXGVTD0i/8RAirAAJ0eBAjVnXz0+Zp8gWdE+PhO4eo/8QCgkCDe 4Ebn9SthXHgUo8ru+LcvF6o= =jQus -----END PGP SIGNATURE----- --jZB9q6GuZX3GwDM8-- From SRS0+2be871c1938b6cbd8bec+642+infradead.org+hch@pentafluge.srs.infradead.org Fri May 27 00:42:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 00:42:18 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R7gAXq006912 for ; Fri, 27 May 2005 00:42:15 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DbZT1-0007M0-5l; Fri, 27 May 2005 08:41:15 +0100 Date: Fri, 27 May 2005 08:41:15 +0100 From: Christoph Hellwig To: Michael Chan Cc: davem@davemloft.net, jgarzik@redhat.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 Message-ID: <20050527074115.GA28208@infradead.org> References: <1116609329.31523.16.camel@rh4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116609329.31523.16.camel@rh4> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 1732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 530 Lines: 13 On Fri, May 20, 2005 at 10:15:29AM -0700, Michael Chan wrote: > A new driver bnx2 for Broadcom bcm5706 is available. Since the patch is > over 500K, I've put it on the ftp server: > > ftp://Net_sys_anon@ftp1.broadcom.com/bnx2-2.patch > > The patch also includes new 1000BASE-X advertisement bit definitions in > mii.h These defintions overlap older 10MB/s defintions. I don't think the number space is scare enough to need this hack. If we absolutely want to keep it you should at least add some big comments explaining it. From akpm@osdl.org Fri May 27 01:22:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 01:23:07 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R8MwXq008647 for ; Fri, 27 May 2005 01:22:59 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4R8LpjA017778 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 01:21:52 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4R8Lokx009686; Fri, 27 May 2005 01:21:50 -0700 Date: Fri, 27 May 2005 01:21:01 -0700 From: Andrew Morton To: Jian Jun He Cc: anton@samba.org, rende@cn.ibm.com, ganesh.venkatesan@gmail.com, ganesh.venkatesan@intel.com, herbert@gondor.apana.org.au, jesse.brandeburg@intel.com, jgarzik@pobox.com, wangjs@cn.ibm.com, john.ronciak@intel.com, cdlwangl@cn.ibm.com, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 Message-Id: <20050527012101.4b80c005.akpm@osdl.org> In-Reply-To: References: <20050526133123.47824405.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 433 Lines: 14 Jian Jun He wrote: > > I verified the problem on 2.6.12-rc5 with mm1 patch. The test server works > find during the test procedure. Great, thanks. > So I will close this defect in bugme. Well we should verify that the e100 patches which Linus merged a few hours ago did contain the fix. So please test 2.6.12-rc5-git2, which should be at ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots in ~8 hours. From Robert.Olsson@data.slu.se Fri May 27 01:22:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 01:22:09 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R8M4Xq008599 for ; Fri, 27 May 2005 01:22:07 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j4R8LBpD009347; Fri, 27 May 2005 10:21:12 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id B9DE6906CE; Fri, 27 May 2005 10:21:11 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17046.55415.729135.240047@robur.slu.se> Date: Fri, 27 May 2005 10:21:11 +0200 To: Mitch Williams Cc: netdev@oss.sgi.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: RFC: NAPI packet weighting patch In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-archive-position: 1733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1444 Lines: 35 Hello! Some comments below. Mitch Williams writes: > With the parameter set to 0 (the default), NAPI polling works exactly as > it does today: each packet is worth one backlog work unit, and the > maximum number of received packets that will be processed in any given > softirq is controlled by the 'netdev_max_backlog' parameter. You should be able to accomplish on per-device basis with dev->weight > By increasing the packet weight, we accomplish two things: first, we > cause the individual NAPI RX loops in each driver to process fewer > packets. This means that they will free up RX resources to the hardware > more often, which reduces the possibility of dropped packets. I kind of interesting area and complex as weight setting should consider coalicing etc.as we try find an acceptable balance of interrupts, polls. and packtets per poll. Again to me this indicates that this should be done on driver level. Do you have more details about the cases your were able to improve and how your thingking was here. It's kind of unresearched area. > Second, it shortens the total time spent in the NAPI softirq, which can > free the CPU to handle other tasks more often, thus reducing overall latency. At high packet load from several dev's we still only break the RX softirq when exhausting the total budget or a jiffie. Generally the RX softirq is very well-behaved due to this. Cheers. --ro From Robert.Olsson@data.slu.se Fri May 27 02:05:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 02:05:39 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4R95YXq011422 for ; Fri, 27 May 2005 02:05:35 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j4R94eTj016654; Fri, 27 May 2005 11:04:40 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 0EA30906CE; Fri, 27 May 2005 11:04:40 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9ZhDeeIJxN" Content-Transfer-Encoding: 7bit Message-ID: <17046.58024.10877.5493@robur.slu.se> Date: Fri, 27 May 2005 11:04:40 +0200 To: "David S. Miller" Cc: Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: LC-trie FIB major rework In-Reply-To: <20050526.133815.62342715.davem@davemloft.net> References: <17045.56331.653873.256686@robur.slu.se> <20050526.133815.62342715.davem@davemloft.net> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-archive-position: 1735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 24396 Lines: 341 --9ZhDeeIJxN Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit David S. Miller writes: > > Below much reworked version of the LC-trie for FIB lookup's. Much closer > > to current FIB anatomy and locking. Parent pointers in the trie to avoid > > own stacks etc. The option to merge tables has been removed and much things > > to keep things as simple and clean as possible. Although it's somewhat > > complex. > > > > Performance. We now perform about 25-30% better than current FIB in > > heavy lookup situations (we test with full rDoS) The test below illustrates > > this 123 kroutes in the routing table and rDoS is injected into eth0 at > > 720 kpps routed traffic on eth1/eth3. route hash is not used and both > > dst and src are looked up. LC-trie should work fine any size of routing table.. > > Very nice work Robert. Once TSO becomes less of a time sink I > intend to help you out a bit. Thanks! Appreciate that.. take your time. Seems the patch wasn't distributed on the list probably due to size. So below is a gzipped version. Cheers. --ro --9ZhDeeIJxN Content-Type: application/octet-stream Content-Disposition: attachment; filename="trie.pat.gz" Content-Transfer-Encoding: base64 H4sICEqVlUIAA3RyaWUucGF0AOxb63caR7L/jP+KsvIwIECAJD+wpLUiS7ZiRfax8N7cs9nLGQ0N dBhmyDyElU3u335/Vd3zgpHsxLn7aXWEBN3VVdVV1fXqod1uk6/iHb282dt54wb+RE87QaintX63 u9/u7rV7+9TbHez1Bvv9Tjf9oe0u5h9sb29vrLYL99v9x9R9Oth/PNh/urHwxQtq91qPabvX2u3T ixcP6Cv80vk7MkiS0Il14PPwtjsLtKvowXZtGQaLZUxbJ7MgiBSgB3R2/h15QTBPlltbgBirpfLH EQU+nV+eDmVk4iReDOARYEevj69eP9gGUiFTHq1dB4FHW+kA42u32zPlLfEPH06SMFR+LDR1RDcq vCWwdKN8cvwxTYNgTMoPkumMJkFIiyCKKYlUGHU2KQ7fn5+WKPLABsUP2KWvVqQ+LlWoFyDueHRx 0o5DrciJCrsnx5tCbfGiA0GR/RnOwKZeCI9RCghM4G7h+K4CBfym+AA7VpEb6ms1Ju0PZJZq5+/a zngcqijDkETan6ZsRB26iiFjny61F0WBkcWrxPedkN44oYwJntPTU/o+SEIfewDYlfKUG4PUcaiw Fe3TSbBYJL52RfVRi3pP6o8bg1736W67133Wb9H3ia+o9+zZM7B27JelEsXJ+JaCCQwIGwa3wEEL Fc8CmAOrY3zrOwvtkjDNDFWw/YMTx5qGej53fOV36NgIdYZ1Tot2d+s98POsvbvbIlhxv8NoZnG8 HOzsrFarju+Mnc48nnUitfO/kW8Q7yyTa0+7O0sH3EY7YIM56O9kanqwDZM1Rg47odxOfvhwMTw/ Ob4aPiBrKGzxC1gz2IliKGELM+sm3y6e6B+cuZpoT1Ue6f6g94kjnS5fO9O7Twd71Wf6SespbT9p 9bpypmuyP70cBUm8TOJOwO+jwJ1PvQQs0U8pSOwu8RF/R9o3gPw+W8UfYig6TIHAm3270L5mjFER 3diJnWnoLDAWOiv8TcaM3wn5r3YX/G+sbjT2ycOTkX2npzL104O2wRPdRm7sjTCZkpzo69EkDPwY IrcfI4WzBI1E9vPMiWadABb6p1A8gDkE1z+3v66fvL08O381KnioBm0flkhUAbIfyQDZ0hhnCfDd +7cno7MrAYJrcDcAUtN7d3E6Gh5/d3F6lSEME09FlQvev/0wNIT1cgFFle0wlbFbNMTMnPYG/U8Y Yra+uLTXHfSfVNmwRJde/6kEGP5v7fErPUE4oLIcHsCPxCr04YFikk2yUEBOx/WbQI8bzzMI/phD qI85xHYZdcnJr6OPYifepLG9TiMHKxOC2ehJmWnN5yBy72ZcoHAUPrG1DKJI0QhzD0LssTT3+63e M3O6a9MgDgindITzBVQ1PaF6WYCNRgkOk/fLKo1cKaY1WQFdBpL+FJELfEFIwtGmdNa44lmwj7cD jIcqRoyi0A7J7OBepmsV6mJVFZkaFJgqW1DD0sEok4co98qzfJB24K52/MTzch++R739QXd/sPu4 82y3+3Tvcf/xXtXRyfxA+ez0cHAGu9Vnp9vqcmbW39t7wpre3mlC7M00oQBz7Fw5X5iESlEUTOKV E6rndBsk5CKkhmqsI9C8TmKkFTGH1p0gtDgWAaRwy8OJP1YhxTNFMMFFxMGbP7y6/ECvlK9CRPV3 EjvpArHRj5TFgGxBYmo0Q/ZwfSuLzpiTK8sJnQXALWnEc1KI3yCDbI1TAouinxKzmFuEDKHuxLyF kIIlL22A71vynDhfzQE/lcX74FqFMb012cNBKB87gXx8oeOokyTIA47ow3IZOZ5DH3wtWGIVWwxE 39LVimU1y2clhzmehtpFnE9YBleuVkjWoiLx78E0XTiQxMHPeNvx8PYFh71O5Bmy1YgzyndTSGFe O0xCI+07mDlMAm+L+7prY7JcDGUVhHO2kmsngqIgJBH4O5turmbanfE0RwSNpNC7lfwzTz9TXr44 1WtWpah/Itdr0hcke81MOH9RRg1Ef2lKbbn7uzH1Qe3r8/EgzyLc1g31Or3uPktjfwe/PXiRp4Me gvcuGeun049L+rq015NgrOAmgkWWuBD+0LVS7CYSNgxrCL7rJdC/GMkk8LxgxTKZKQdOYlCWH9Lc GhcAKG08JUbB20uP9PDk3Q4KSbipOHCRNUcJTFPsQuzv/PLDj4ymVgugI4fTaM7SYoXSSVCTKZoM ZvBnlMNr6burl3Ay7txYeq2GuIpqynGlGGOIheJTY0wzFzytYFcyz+UgeepGedlprqHCutnjUm6Q moPycSCUqH3hMA2fqzUIOQG3BUdgTkcCww+jQe3YUx/VLb1JfoXvj4KbFh3M5f2LRdTvaD/sOG4n TI5ywl/szmu1L/TmtdqXOvNa7Ut8+Q5X5l8hsLO8/376/ur87SVtdTu7/e6WTFmzpANP+8nHHdsg mR0Vp5xosZM4LhxoVDFjbWtz4lrHwXJ9hSET3y5V9cwcyRqMp2oqciHCypnFOnm7ADr11zdjp8TI 75zSQTV3Kgz9oHJG+3cM30EF41yhuap62WTExVzVlKROk2r2ovl1MpncRQ9v5ncwqauZhNWuT5i0 q2IwdUcVU3yu1/fJ41wVb46y/CuJcgZZnthin2t8Smdm7JlPaVUWO7oaHg+v8rPww/GPo5PX5xcv r6j3ePfpXj4zHA0v3748pW5x6OL0+Iyolw+dXxmwOo5e3W8fsUXT4WG6ulGC5NWbgDzaKJ7P0x+H 749PhvVli/wWsoAQK+r87+CgvmwcHdV3+22gaRSQvzn974vTy1fD11R/2oz0ryqY1OPRXN0WgX44 vnozenf2Y33eIo9x1r3G4WG38bfuoD6noyOqZ2jaXqNBBwdrIwVJYHz06nQ4Ypz1YDKJVNwinPRI 8MqbFLVlpN7uraGktl0B0gZFQ+TAdQTc58vTM4Sp0fv/unh78qZuVOzOueB4sM3SYwUnfqSnviRS MQmd5wZDmLgx+RyU/5WXUgJABqhmYWIBai4dbnk+z2EzzBGiDsBAcNB/bid3mtRj3lF9gI2x+Nff i5Q95Uz+bZRThDM+pyPOJIjfPa/gCXXhJGDGymuEk5ldxNGekBb4BV5zzBPHm61jjv+tgr5j4TKI BvvpOl7Y94JpbmwNsbXPwMNgOaI/j2eCKnbkzrSHDBgRnTHllv+ZONRiGd8WkHwWjqLxN2XtP7r/ zFR2Z32fesZUXUiGR0jjpKqPxGRKh22K3Ov5+uC1487jEH82ZtLW32jhxO5stHQipMSfglqgFNuA 4e6AGOxoplMbty2H7TL3zPkm43GAiLuMZxuIF87H6gmx3E1GcJ5uKoaZv2UgGXPFJGOCe47+kQce oxvW3NoGiieqpFSevK+/lKqyVq1L+VuQWkpDNADmNrgOkaFwKlk49+KhRTiMe6yukykdUndjVhTF R6FedgOxiWz5nnx27HalNOmWSWwsv14USTPO1hUwMSn9KYSGlwztKFRBOK1gqxKZGV45Ee+lgDnf pEEKtzmNZxtYCytKeEOxhk/ucHO5nYI752T/zyOYOd7NH1peECWXUfft1ICKfSSL5ShSv6TQeDvi +xZq4l1OzpAvNIntBMd+x9MooZpyq6D9sflc3whPzYkza1HyFMc8wv/dPuo+HRRQssIYyVjFyo3x z8nVxeMSIEHGKDwIUey1NpuxxZ+NxU3PATtQLVy4QWNG9Pij/TieeLFJZEpt6XgRTTm7rTMQimc/ NltAIG1VycIx6H41/2LQH2/ymtqbB+SzcSi2nI6ZYmCEegEemYtZGOQvjeIhni/UYuQ6KLlG4Hvi G9ojHt40KaM/VjgyNdTBh3T54eKiZce4xLdDRQq5lcCH1N2ZAxZRXyET/JdchWNr8/rWkHF/l0wH 9E30k7/VIgZhR/Xdh1fShP695Hk8TlLLPlNMFlFrzamsnfsGCd3MJXJfnY4OkfMfHMRI203CumkQ 2Qa21ghtGXGmcLbrzqhMaNb/rGb+cx1LiV2LvcBrilxa2zT60h9G8hvpe16XhddVxeuEfmMk7S/9 MZvu4tUj7nMT7eK1h9c+Xo/xeoLXU7yeAQRwPcD1ANcDXA9wvX0yivmLhHJSeCV//PXXCaWHzfew +R4238Pm+9h8H5vvY/N9bL6PzfchpD7g+oDrA64PuF3A7faMTOJl+wgJNY7rk/SjpJuHtMuf/XS2 t28/8uzhHn/IEtTD3f6DbdN5Kpu2qQ5i/BnB/SFdjEe83NSJZJ1aWlNKWsmHbuNcGgg6yCkCppbe a2Vlp8NFZ1pelqvctAAtVCPK44ZdhqV7z+EU/n9JHK/AuXlznTJrsThc6F9/AlWUXG+gqxLEBhEr DqMf5GD02292ETuuonCKDit1FYW9Ww3Lv6NCofG3wvsBWa+yhqcOOf8PeCoIu1rWwiKLonaPLJD4 SwVQLYnS/mvmExLZCXgXJtIaVmPArBEXXNOT+kOGY/9dyzhnZmor+FhVrwsW7ECvMc+tC+ZbDExv b/MSu1znHpZOHCTUjm3Clx54oNI5MHffviRQ5USmFN3tBuV5BIVqAwk8Jxj1idM+mjjyXkJgIUZL SlaK0i1U7I1yFBgGpokNbnyEXm6OR3EymbTI8QszfBsQTDj5iKRF73get591aCwEq+TsK+4HO+Ft h07lSTGJTNpcgklGwPcgDokeoyhwWUBjc1OguWeUcISOBRdTsD1uQ4KxoIaTtSECOkoSPdEuZNox fuokQJ3C/XjH0H3kPxJeebXpNNCjePnIQp9PyGe+HemFtDjFAsPcXgAlXsKEWBoFOnTOqJDM8c1h edM6dsammb9EElm8pUOGpRl8nHDnGfRi7vTD1XFPHolRfTVTvmCKlBMiwAOIbcYwhqOS+B5fm62U 7HscCBZOXiMVmj4/plYa8mKqHnJZ71bwgfMAK1iS0Vwvl8wf7wzg2ECQcFnaoeEskSHuHiBT5qsC PUGOCVmz8FEX2ktUcLQMYohRy71llEj3HzWQZbxlFLRiLd+w2seMUW69Vo43Ty+UGJMbhCEybpEx y8vq5BLoMyR8C+OzVmiLa/8tWVxcmNkVxAmnZ/QSswoYV36dxkCrMMA7IUXv1hSELUZJKLdwDpcj U74Dy+5ymJKEPZ5kBfBg5CzMwWbZyqEQG3ZoqvnJSGCe6I/GTI3gjW2n20+1AatEIq2jJsFu2TfA HBirwvktnR3EAzk+1wp7MiMWBaODUh+apNPYRL1h1hXv9MydXOzMsU+XGZPtYUttPnEq14yc7GAj DBmURRpWZzo9R1JOKbmWFdbbEMcjyU0f0UyFqiU0bhyUYIkcSCPj9KgxLrGbBd9asfNVcmT5dhFa jCy5048Ob2lA9J8c9j857P9/DssfzzSCYAvuOH4U0c9JFKeeNQtOcpLgUviETtIZG3PipXWMNl5k i+QJgS4ftrplD6kF+2Mb4ZpzP1j5TfEc4oz54jqQ1hOHARN8AnncmpEujEPyb2MOIfa4DEvEUjqN IlHazsXRJiQ3bdq6RFHtXAc3corNduSsw6V/5GMeFDYImUhVCsDQuWX+Za9y3G9NXLqWhwAkunC/ RjiX6Lxgr4yYbFEA3b18F1g1W7B6S9m+2rL8FsOdCQbmll4cU0rj2OQwWUwU7xNxuIrApxOupxlk t22RCI8IGyZdKaYqvC5UEiRZP7YtDxZsSBS9sj8F+3B91Vv2C5ry0937a3o62coVVNSOmEZZMS3J hUQd8qhGEkZsrQVPm0UeWcWPClDKl2yzsMVWicmcsQYF/soJEe6YqUI6kviyackiiqYse9/Mh5G+ uvORBI87uhycwMc+ffuttE/AxHba5UC5sttvSK8/7xjJ7e3p+/dv3wP+8BscSSw5/GZs7inxRvpI 3Pmx6MybtCKs/b5er8Uk3dJRPINsZgGkfAgnVO4F24ZsCWa/1BYv3hA25U7OVyvzEKrZZRkA6+cL 2FXg1u29bmG+2WgRvTp7N3pz+v7y9ELYhpA8KwovvWa2t8w8XTu/PB+OXl+cX+Hv6fHL+reA4v6p LOYl1odlnToWRFrteGtF7MbVYjN7K9tKrxI3t5aC63s3KFBVu/Q0GAVirE6vKmVjxX1pLpO8WaNQ rXm6ugo3FRmXY0y1XlaBZX4uxZV3R7OxjMEUalXbLSPT69iKlt+0DUAWZHajakphsdZya0RKXj/1 qRzXDg5srS5T0a8YK0tY0Df4KGfLmmsg5gQ2Nu9xY7+ouF83NJQe1wYZW0QpikK8zseti/LoV2Nu sV8wUTmx2bAJzvibjRT6E9kYS+UwvWmWkdK9q72TMjPl29SyhAzJKsvnXeR3XEfUlfZB5maOh/TN kuBOEvomyTxKvXh/1qgUe4ux2CbKGnh9UwcNaMay2ygadOyvGdAn72cyV/qQlSO6WW9e80JspVEQ Qfr0CtbYRflpKR+XhrkDqm0KjozkMtGdXbDorMwyYtyBI0PRPFljSMpSc2o+n8DwTgKfs++8ZdKk E45OhLJdnstzrDw5oUFY22KbAxHdUR1+RLCiNBIkHI39IE8YbMrSoSvFQTlyE1OcIk2QJ2oV51tL 0Ft26HH2GN9d9wSfd8uaqd/njhYbOvcL84eTij1UE7fyjmoZeYP8hj2mh2kI5Wxt7eahwk1++dUu 2d5f5ZWuLJNnp5Bcp2zwsxOcijTpeIz0KE2TxJVqKZQ1IfkNV6GO0w4Ch+8bh7/DZVZ+WI4dWzfL MKdHZXfDGi67GbN0I9v5Cy+jqRRbs8c+si6oQGUeueI2q5Q22dwIJPIMyQBiyDrttWOztgux79x5 sEDlQnA+up7Vvy0+x1XDKjosX4ZJW7gGZSVG2CLNkyw87cguqGC9SAcZzUPzsVHt7E3L1roWXv2w vPrw3tXt9nOTGRf4YqGW2CpeTVjVMFqYICPNRoqHlRUMGmm4vAPCt2ldjhZMP9SZ8ivCnjBcK+74 YWHtvUuNpNg/GIBiWESwMeopagzjkn4ZPSd+paYrUpw/9gAE5TmONheqIpGHEtAyh5XdLZdjQzli n/tWwoY2h4iNrB22T8UPchDygG1O5tqa1np5YPUKm7kMyN0w4aqUJFV+6c43j7mFuJ4GwfLO5cSB 4Fu4WuPh/hQ5KTYlyPMj5lqyKPjHgzvAMbe9LSxK+L3vxNcyXjL7SU9utp43kPZqUVwq80UCsxP8 lH3huv8wMGK/5m2tIrEzM/daLANUiDsTuG8+/l7Y8Z2YrFL41qlJL4Pk2pMvUnjcCbFfqMBe+fvO GDDPYsqdiZ8srhH9g4lZ6UMWrEDzFFnenTZdG+mLp6bXkRU71v7M8jMu37fO0+6wuZhIv0KUyluZ ZzG2uKW+9u0cuRFgREzpNTyL9ud67XtXQ+XO/MALprcV3z1igMtgrh2LZ8hf41n74s7SmSp6PDAA W8e2Ix7RWKQ2Zl8m4mJ4xgeZtI1QMquOA2nRGxTZqO2qNy2iZobZkcQ1iunRTE9njzpbstCsNkN5 Z93nizFzDZQ2th1W5qMNZ/CIL44sD4BWH1PpimKR07ncoJ+qFjeeVsp8233pyTdM5F7BinrzvDXM Bdf/VXftXW0cWf5v8SnKnGMsgZCBZGbngEUOxnLMBmMvkEl2Ml6dRg9LsaTWSMI2O/F89q37qrpV XS0JO4/ZObsx6q6u5637qt+9ZbsCeCc7BfIpLKhdtQMwH6CT5N53k0AuIeeckwm9uRNOVq1R1bo+ v+CjXn+xO4D3cOAGn+3v7dmdnBt4OGL3pxuXQY8kHlNRHW6A6cr+tEckK6RRLDS2nQeMv50+OLH7 0BvOuodl/Itq2TUJpjecK2cY+vZklyExAXzTUw0vINFOh/NiQJMNU7Q1mSp8fWQXRJToPcOuOQKY ynkSWAVev5R5OZGzUcgIEi8id9AzEV5S1jORyKgaux7ozcajQHIhA4dFHIaB3AN4bhOsxYnp2A0y s0P6YJfALjhyO9oRH/LbEZz3HeoPFnn7xkpe7luzOFNHws8W7WLZEnmUWMldbo8kcrINbqj3Iaiy vJ1tcxB/2Ldz3e5nnYUVhU0k+m2rQBa6vmMOtoMnNfNY9a/QB54D1EajVqyCXuAnNT3BjUYDt4Xl gEhOOXINXIoxyMzbKR2AIqihBrtmGqxoNrmzS1mnH/cbUWEqj5tqkIVuB62i4WNFzpDQxIf3b395 Y4mV1u1bHkwGeNwQoiD0E/KbIwS/F3XzPvS549e/yCxqyWVecwhRkd+wiyvmu3wb6W7zTJrsbTaU +fwT9zVudKecBQRdjQZSOp3qo1S1qpukLeljCFL6NhgeBJCyQnfB67S1tbEjnrzPGFZxNDzxoMeu Pec1pz+jZ1Zk+kK7vsqGJxriC7BfYs3Ui7NIz2KtSHg5a1Osi8Z6qEyhOrHZDybu/sRbM0/85/HJ TOk0qTki7LubITHwX02slpI7A2rWA+CyILh+P1PKrv6XWlNfbkv9m1pTG94pGZ5TFP3hnxkvEfjU 3Mf2n+JJiCU3+qtJraOTIqezqZJFDj0ZZoW3gjvNnml0v7iq4WxIOoCnIXXjf+Ipkf+J+27H7Lvj Ge8/iV16kIytn9kdK/h1IF9NvTA+TashIclshJB76Qk7EmnjwsePKfeFZy9Mn6gcYV3KPVfp5GC8 3vaY8uBjOnpAKESESEKdOkDC8T7Whxp0wPLLLykXN7wi1/bxBvl/iq5uOpv/J2/IahHZrFYn/XWd dxexQgU2tYTgnOULOls62AbnNvSLNo1AltNFd/aDwmryZCfx9CfmbfEh9ltVhry2yYk6kpm1jE6R nB2Mm570aLi0BCtyX8uGE5Tef1MTFqQYzNAPmQdZPsoxgXcs6STG6w+Lol0P1mndbM+GbwcLZsUc Plc3Px/5Nn9ga23Wm46yDptNdHg0JKCcm2rYdPiZlV6WVdu9+whaIUTrI2zpUZ3gGviNlV99QWi4 7zjJjAfXoC0t1YuhaTuE0Bf5LPPHICAkwMDu387wrKsLwBVBRTrAsHxIiUDQooUymwo7s0lYR+rg cEaYSfmuOu+R9a2OvSbWyiQ3Vj6lzyBXh2VCNfcZ9pzgK+A14L7WObeKmMWbe5ugnchHOIlz1//N fXxL84mPG+YKPSYMt3Vjy9/LSRCCVmWGuOH5ojetCzyGpsB1kyriCjKwmxE8s+uK64MnNydDx7ZB bWB3AjRF+Fg99t7iQ68XDhEHh6Oy48mtjQjdmN9NbCXo58ZKGOyM4C76FEgDaQPWpyFPgWjG2fyd eTR+xBBUmd0MwM1vrTK3abu2KaNx1YEbSEamR8QFHstmRUDDGA7+g1wCQyW6UFIZ2Unfs78G1Dtk pQCSgygH1FLtADRuS7pjaHFy87+9Wd4wvhP2X5w0LUiHjk9vVf81rjlOQ/zaM2nN3HadPEXe/wAq ZXpdJVVFw/uiAfLw7FJEo0NKKBneL+PSsS0dHNZ5z9Eh7SU1IZwqKgnaxc+kXfxstQuMQjY/e004 lAXEe3+OJMHPIjfCwtjnRGk7amhGPvq0RDzxIRW3XFshnnxpmq7V8gn/X70VRWkp0OOz4nhTam1B fw10uVjOid66lpa7UTiIU2otdpmVWtQDF5PmZyq1u0qpJVzLlyi1kNxT0IQBjyhVZePdliy4sy9a ryhdcvIALJ7luHYmk0LsVWHqS2jfwXNuW14YzDXxNAdn8qwX1BLpf0USHj4+ELIl4jTuBDlsZcnn sq21en8N+occX62rYtn1ejqcXCBpahMSyAMPB8o06nrEtnxFa/Ku4uh8FYhfU6yrtNh+MJNlc+2Y herklzEGdLNuc9zGcBExBQWllUPl3WPm0QyV2z3Gsh4GB48kBwQXW5l7gv0yDvi3Bc1A4gnC/4WA uCA/RU2lfw3Ap4s0B1TwSswMUMBfqrw42/BfhlAWYKkqF852ZOoHEE4iECptOUgbNPJ2b7KY3VVH bJrVDTWEhXieaTPAVjIevUrwVUP7SYNU9cB5HcpD3NUAITFLu5/hrwjHWjbuIHsC/tGUlS8B7Ebz LBDiOlXO2BMAIg9pw3G19kuHyuVCPEIukKJkij1aZ1WLnbV7agnyuMnZCSA5QzzimBYgicF4yt7g JR45Gjd9jdyuCn0jVB09zbpdWpwt27vd4wFNHJZyGKV/+uIhgbXnWb+nqMz2KUVqFScbsA0ksWNH dcIEb2a97J3S1GAe7BIR+ZFCBGuYzUXl8wPI+taMtutu37khqPEQA8OhRB9SrEw4dqQJ/50Hja0P JiIK39hx6UHQwR2rQ5xLQ+GlGV4c60kFLWhCK0+YZGSTVlchPhmcEATAMpPIByc4nqQLxa9F0U3P L8S9pKPFJywIXQgDhBXhD0wAJ56XfN5MojTBqZvQXDAwouDJ0hJXxUt4ieXdUY68GP5yms17Luam D8kuOd61AelbwanMQZS9wNkeTKlKogdhICoEHztGM1ELfZI+kCICKvOEq9CGFUy3kISpPevdZCOA hKyrektc+p6o0IzLg59kEncwpqeezp62mAZud63tSiIUIBNCxTNhYEsuOZM/iNHzqtDvMRzLtmF7 fAzxh46UWIm/lNFTgE2AtK4I/N8X942owvJIm4yJ+qf+k6mqfxrUPy3WPw3r/xSN6cCOyU0cR/bj Bp3y/Ll0dXZPUrBVs3RXTGVXTFUUUQnyEzxH8Yazz6iNmgRHpLgEoxZBZYzfydSnwcWF0q69uj5F gWrqOtOVYzwP1GoFO9x1Npwx3vcvCB+E0qW6yKc16YEgE0Okf3rkbuDl495IHgotORNSCgRJDlY1 lsmOgg7lonGsREtLE9mydQ6aiTQNL2AihiUcAiLhbzDV3WcqbDFvWSXL7Jqd9YFTU+TpIufuz+3i NUyLUhP7MHwxVDHWsAeH/QBE2cBjYcQaTSGYFR1YODLItdDH5MUiDGag4CAQIzgEmo/yRd1BVnTl rlrIfKwrBh8nQ12iIWQigusUaQg27RCS/i3szzlWhJ5gn4+AG3aJYMdoAN9w2AZlZLhTx+PsiYD/ PrKT+4iyK2wI1Am+DCJosdDOI/js0YMNDzo6w451c9sr7F2APUMStDwDaO6xDx0FHzhzJIXZI4aF BXh8Vkm4nVONMiyc2Wz0zq1oI9mXySNws/OC2fmU8wzBK9ICc6VRFfE6gAiv4+zjlMIdUvgHzBLV L/kWKEsArsOcQqAbqk91xrINsslbFZZRF4w+DRNaezTnargAuso5gcuiYcoGK/kxioMNBvr491IB v0wDZKF29PuogyKjMWA3UC9c3JkX3VYGGw7S1UqCi6eL1QSv7bDWWa56bnh8y4TSExwzP8Nkzpb4 cFkUxdp5gjM6SzNVblR95j4wGjWEuohWUK1mUtNaGbBg70QRPUO04v1DnZjmt9CHTVohNpFGzAQI /4+GfhjN66x7pxEYsfD1QMvM/UrBlPeOgxH7UfGymm4+6YkCwd4pCksZSZegN8rja0ahDgxFo9jQ JcNxlQwLtZSMZOVA1Noe8NoSzbmAfMopgfVo4ejDNdgLB5sncPri2uignKlaEUB0TBMronysn6nG hv7LJbpkDMkZhd5MmZavHMnLNsyMF0hy5srMmARhg2bHj4ViKvCYj4L6YBqpS4Bidi/7kMyDXyBL n0Pajvm01xlmI8KvW3FOpR06BDJQ1DyrnHLGgalilI7fQAlynlLgFM00aYQy0y6nmefUvD1pfiNQ j7B0qoQ92orPxW3sJWuJq4CTgedqNrYRo+x8Pc6YLMb49T+mnORB1PSC/WMV1libJRQWDangGOfP yyipUH5/130h+1mMwz+G5EVcq8XiWXWu9aKJUlyagtCWPeSkTUyVqTwYnAEDDegoAQaqB82Hex/R oCmGuVEem3hy6qxIijDgXa2Mdcn8hkPwY448Jgux5YHdHx5trHAG29FYK23S1gmpVNa8BQbibC9u nOsF0+ma7Zl7AHeKtGeLzD5bZIh+p/8VM+SO7D+rsuSGR6lkJmqVDp/Ylb2x479pw51Vyj6Lsvhu YwiALrDaxNPJisVU5IwYM6tpLMbt7hxElIMkcp4Ffgm/4A2lSlbPyYZ15i6AQKSG3myWNFNZZLGb 2VLghner7bbOLv56wv4qksjk+4IjxUUGjWbQU+I74964M72rbmHT+nXdfF3TdUwW+WBUZe65ER8z a/o/IxmL9AFhnQ/3/vLxsYQ20+IMuxFN2+8R/NI03JCBC1za4+wdpDGevyPVwfi2oVNb5l/wbsXg qSTPKs2DqVb7dKpy0+5YzXXBeR5nOAWWqRE5bkHK41pwAovaEq0Ka0ehA3xBBsARajLieqhIpyVN jFdy9NnRSG1x+jrKvc0F65Rquw/qEV74N4Trxe4U5hwDYEF01DFzXD7ZJV0IbcK5pFgiIW2rMFg9 qeLuQimxBufmJ1KK69CqNPYGa57fWmMZUV4jO4vduw2OmbBbCW5fC3I5cc4uxo0xRo/VMZBzgKfZ CIxYOwVOi5MPxD7ELChgcWbyMWgxGxw8RvRHjQ84aK8f1+4rn+BlqdRNck+QPtTtwV24lNTPjnJD +0WWdMQFjaEFPRppkxWvn8w8Dl9lFg1XE6iusMKBlz3gaG2AIYrqOYO4qd1W68ezq+sj0a2QpneP kee2+6Ps7dzuiovzl+3n7daPp4wvkJsrj7xOtuS7y9br85NTsa9TbLLdneWkLQPbA7kikNVlZ3r4 nj+GXeDniKpSD3CTBE+Z6Qq3dc/nnVxzY/x5xP2G9XPtSC/Vp1hgq2n+9fykfdU+OT1tXV21noUj KTk647HECWVpcCqkgNswQQsM4bNMSbLNjm7ng+quB1sADeGiYaJQSIHm9SDLBVqzGWREQ4cQJoXD SNg+JPckTxduR9bab+d8SR5ufZygOs4jGVETq8YN8ikXhmHMxrg3Gk6PR84GlIiziT1JndkDX+KC OL9425VlMu/xsT5Vpe1C62plJrgyBNioD1NVscROepDYScuqEPcR/os7taL3KhNSSEmJckSe0LZz vqjtFbhR0IxcttNOXr9uXTwjBweLBrflKcUO7/mLV62La5H2qSq3qMLTy9bJdavmZZrb9L6mp98/ v0JnNapKmHzKpT2mLFRR3uOr85OnYWI0DrXMijLUtUcFihtaPSd1ifUk/Tzc6upN2WbXRXjXM7YG bh1zr636Y/y5gUPGiFfrzEstJGgRNUjHAbOvPmCZXQvFfnz2sSiqQ8v5ozveX1jzEA/3ZVzoFMEd CYLmG7OlnptDUfVrQSvlvCvJeSr+3ozL65fti9YPeEc3j4H6QmMJFD7WqvjCC8ewDr0dAmuBlyWn cnCjm8dS5+GRgrGQKlaS5Z0cujq/XHxY7HA6Jkr3tk297+QTO2si2CDVsZVqo2nduM2ubwmhaHBM scK1+Gs1HIqTYdis5JedHqUgN84vRp6vQrEQR7WxGjAVw1iQFSEehWAryKZYLSetPFLKh3xuilhJ cv9ZZlv1GjefLsYRRFC+WsXZ4c0Q3kPlUwlaiQDTTTNa4zAdZqfbbHwNj9a5mYlgdwB3aySvxkJ/ p9vqzqDYF3m6RgtlDYCzJKz+U0jzpVY3XbFYYnWXEmeaJD/TfhYrFxZhIbZk6Ukqe1KmzgZGR4b4 79wmaxI52d7aZR59jeaofNGxSsa0123n/b7/xjmUHIyDz+faZJz4PAPuCgHk9yAe9EkrmCnI3yIU GYJWvXQipxt+snrd3bLDDW3BOpMp9p/geKaDhm+CM3hJAEf0DBAJxbGUA4zPCibMYLdoOfzG2JrB 5Q9Kg0esz1FxNEh30/JzMDX1MtU+zRaftk0njldwwkg6jMLmOGHk1B9u8cgeqKqFJ5T7CP29mTDe 5ErX6p60RBtOnaJNJw7joY2awMF/L+YR3IYXMw2cbrmTLwj5C2AXvOZyt+eL8/ar19dnL8/+1nKd CZ4VgNqd1BryOSNtGPIhk+EOZOP+hn+da5x1X8A8iCuZtBzU8c/g0DyTjCZs+MKNAd2cHPqUxASJ dk4HAGRqSAWj4TswIXLORAGXsPfomgtMoJzZJ1l3Fy4/uJllk85ABUNBLBaOaziXZCupTNgQCEV0 JJ/asf40bVvaaDTwn50p0tQbjO3RVytQoCqmEweqle+ZUOEeE8ziAoFrPavlLu7UCT+kxrnhxC6Z +3R+e+Nm2epmcukGBEKpix7cIH+gycxGthW4MwB4BKbbWSDOIYihlYRI8i3NzS5dqIGZfzAHSW5w zHilxu3U/kVOCtvV/F3dfSznPeAYkuFiKxwSQWOszvE49D3cJCBf2iXI3s6y6aBGebCg629v7cPJ Avwh0IhcwYDZrFWPO3xxCNx7TnmqZSL8ooc5xbEJXE67ivCg0egQr3kjn5LHnskWvDppqfDESBV1 iRRkjxXf9OFmprO4zUZytQTZyPa9hDtS7KWac0R6uMmxbeClQLsBs6Nk3WYMtGIXgqgB8z0g8cnX tANcFCZeRtGDJc4B/fNhSKFqM9wQVslDYMWw6xunLvP9HA3zAoryds0hvwJhcNStFq5hmFlz2bMm 3E1vJhepCPBE5glpgtLl5kH8a2pX4izDGvs4Vcn/7reXq2Hb1rBN4YJ+WWVNL15dn5inrYvWoTl9 0Tr97uziW/Pq4vy/zdV3Z9Yofmaenl1fmeevLs31i5axpojBI80XrctWQB7Af1cRh7PT8SyyIJU6 ckKYrEfi+fiMo+Oy5qfFFyjKcHEUfQVfPMAGXES2pH9IiBQVYe1YdV/rTc29uk5WP8fcmXdEMZik inm5fI0EIh5N4UGLeDtSfn++dADMvHrIjhrmB75VhrYR8FjO6G8FxnDubiawJp5hgUm4qXnUEvmm GEElHqvRHULYSMKAM1gqEIAUZdjKJ9gIJduTDSzbQ4dY+97f9DrZ7VyEVzcndzPi3kCCGUy5BtcW wH6F0GJFvHSRj0Qto+sb7y3K2TueuXtqgoz8pkjp1xh6jPnaoDovasNrKWgeqVncXp6r31GT8aA7 mKOB7wnyHUInzEyJTRLxw/g6KPbfM98cTuAUnxP2+sa7OWLJwoWD8vD0b63LV3Uag+2LIPNmmOVX WP8tnmgwcXxARufYXWZEXzFVPkbg7VXzg+/qOZGrs9yHmKpPZAqy4DAm2+EYOD49wYis6nAIMhv4 3aOFwZusrFDr9GaQRjy7yVnwTYe9Ti+82EgIHWLQZ/atnU7WmndEVRa+S7shYL03Ou4c2ThksHY3 WWBkiOM33DsuFlSqI+1vrOQD5ZOixjdZIm/GVErr8oG3texmp+8QGJW2DefFvMUSPUj6QPkJmNpk FTbpFCBURuTasQ7gVPQyFniQj8sH1cTaNWp2Z/nt2wGtghKgsuB1Tq905/jFTU913VWTi6M82kYx SSgF2+rizmLxQoIplDi218DhiDOyb4KSgX5Ox5f85f+oJqnseOqjDEgDmlDqr0MQCEkFEvdysFtx jvFuMRMwg5Vr2OgOZ8iXQ20MD6b1IJxYZQvyQfjabJnq/pMnwd1/NQehhEESFK2SmJzw95Mn+1yQ YsvDWV8i0CGmi1dhdyynMhWvC6h6Hvg8MUXR7L9IqxrHzZBxWSM4Va45pjMzNrw/aROTnyWNeIK0 PCMri5eDyycse/cqSFDjQiYD/4ToUF/koeAxhx4KP0Y3keD+1a4IFyMCEdxz4t7dnLicwyGT9gns tsrmPk+AZJLTM/DEuygQxvmAvxFSVGUDYow7pRP6POsBkmDugONtzAcC9h/uP2VWqgDzEjIR6WB2 XD9BkVRWBXWnxAW26mvsOXUb6WBbQgzoyiuYTjaE4CPsctbp5DO6oFJUMJfOJjSaUfQGLIfIExHv ZKOCfkBmgz86ZD9R2SppjxEcxFb34dbQeKFwYAqrBwQ7VYA5HUofu8a8Gfltb2Ew0fyjOWvQzNmW eKymDhDummMQl36gkW4TWSgf75Twv93TOSV76N06jilYPEu/NAV8CgPSCZgo7k96lnX5fChymbL/ etaLo8QR+oTeazjVmPXGeSJRhnMFB5fKunCZJVF4iRR6zsNbgpQqzfWGMg512bi/D6c1BCz5jI0q UEXSE2eR4VJn4IfTNK2hvnA6G4WcWCMJ7urE8/ghRoYM5x7fgptKUO8+ckM8NlQDPUUnFERyZHdF 3VsdQ0b+2xjNHngkYz/jspiJVLhEOo7B1P9t4xiMlz+VsoDVDT4egHx1DzTif8R7nhD/UKU60+Fc HC4L/XeWvHFXSfDLJRIaZ+e2rVGETAjp7PV0zEMczyBQfbx8An7CLglYispkkbhLxm8PAe5+Jm53 bdgusl/8ZDVI1V0dFBb3sbjqhK70AK3bg7vx/h/CVpNw0FK0aQmmtAT7ipAKnhrNNAsI2HKOqrGn mvJ/D/Dp74MUXQruZJYwCiu8ujx9cRRFsZQBPFfjO/dqfrIf4N3kyabQV5kG4j6DFQbpxghcqBfv WREG6TAn3OTCB+E4AlGCV+FXshC4hfNVjvSiUYXYrgRasID1EzW5BAKmo6ERUvBAQa3Zt2oUIkuA XapUjYFbUKoaALpsucvr9tXpq9et9sWrH9ChXKwyCQYLKpU+TWdWBevko6ASB0vjd74ieaTrgqKT AUMkZh5QA5BlQJlpcES0hIzGU4g3Dm3YEEyqLy7n0RD8CknyRy59wpLkPA6VFnCWCCn0rHWukUJr oISgjqUo68p66XHQElyOOEX6tV2vasSUim5RGWYciIone+C/DTOrVCp+Bh2SZGW+ZW6QP2XQX3jR pQt6i5PfuMtF6bOCXhvwML25lgBQS+GnVspiv4R9UfeVEqSBLo5pJW0FrBqnvBSrFWYfCuVqQsQJ EGqIt+5C8hPnKyvN88P8SieUuj/X8qGB9qVVYauyzQmAeXl98aL93O6Fk2eSQt5UllAnpwoqo87K UnIygkBOrlQF58W7MvRyiYdm2WqtRtYp9JtegxS+bTQcrIduc5mhypJleRVx7YxOtvFEQifq8k6z QKKSQ0luu5UFDzaivF9nkXXWpiQfWWeNUyxirXUN1gxw3qtXFsxW+KuWugsxCrdD9ZbLF237qWzS YfejU606UdpFMFLEBNBenMI1dIHvkj+p1Yz7n7XHsJYPDUFv+CjgSpzORKzAAEJWmSZSpUgJbOBq AWmYsUp3/WnyQ6i7o+01wVgpEYzmFqRy8U5Q83woCA67Vuz65AMnNpbFxVjtuIhaQDTvQ+aBoh9c fFfistK2nc8p5sNeUVxS7jL0w+kQXczw2QUbEkBhsKjmCaWiwR8+wyw659zdB92Pb8L76J710IsN x5EuOpNe8iQ530VYiT84SK1TUJY9AhXq7p785H8gwhKSZIzz+cLFUAlMQ7J70igCV8pUoHi+q2Gz +iJNmp6qnkX7OU2UuEJoOiCyiIOzxKf6TdgNqOu4GVf2yy8lrUtSOnYO3nKcjpydJLZCev4kjOF2 esj0eZFTineXdvQtVO9SeBvudswmoPqj0n0y3Y0SHemtbzAcNuveNcxlnlMKdImHjQWYuAZImUl5 Br4s0pQl38i4JEQjZUMFktCKnKOyTBV4e8mguXdkpQpYwMKVIeNBrSZOvCMzcDsqKa3cJ1pK4aWk oda4Wm0cjVTwPA5PErixDbGy2hW1bix11fpB0fxJ8DT+0A7ppYoLMKJ2tz9aNHf3j1QBwCd6r9Ec 7kkEQdzPbkdlQc+/H/w6n3UBmIV9JyFZooeWBizjp7YT+WwRvXdKc/Hz9f1B0jMIHEIzR7Wn6sVx SJmNcjD2RonzZc9BtTn7SBhJVOp08d/paJzw40h78xZeseiXOjpgK7eX2w3auWB3up3J3WP65b0H 2qnxAJwVF+3vL85OT66uC7e2+Jq57ShC7phaSEfJeZcBeqKCGiaDn/beNCaD9tsPqmfpIm40zq1y fnbxXaKvgUH6S9PEQZeBfZXIzi3zKxPXHxbC/VSW7QfQyW5vQRs+WwxsrXXZcluKkIMbY7aE5G2Z kLHUdFfC9oUEIFGge3XEiif+UuGs2SIfDzu2fAd2B81lZwR31Pclf0nQrv0UO03vgkhDlNBYOU8N PsXSZPt94g1AG/QJIRNNYXYLDdJmDxrz4mD9iV1jNguTWT6XhalcOZNLJjIaGrEJ4XbH3t/2Wf2L uLKvnJ7VCnSgXhaHgbmb4pEomQHD4KQfySPdSrmq1L0dTy1DrUZBcuS7S0mLQSAFldDEIfmjlLm1 ZW8BETF/d1M4R+lkoxEcWVuD8kb5ESwRzds6SC4QY8Si4fTkI8QZDRb5RGetsF82O1bCZrO385++ Qg1WZWot5+yDmKvjlUtwcUbbhfcOBacUX/lUEqA8GcTcS3Sda9AFehi73aaSmIsEzp372U8Pu2/M uyb49IMsMsM4Tcx9erRGT7jkr9wTz8pviMwo4ziQw0XrGiRE+/RpFZbMPqs1psMu82Fj4OFkNJDw 5nnvH+5VEJYqD72TWZ4oERo/o/B3ebgFxOR+Id3HdVjDOXoEI6lZEnE+eUV4HLbo7Sxmpbw4ni2r b5pDpeXa2bCqdS9OtFrYtdDXgiensHnTB6Ph7pSta9bcp8AD2oN76pNaC20P/FY9ePN5VpGQ1wC3 6iChbdDbY/9Wrk9QMw83KPjhG7lMQUrA3VFfbUcPEcN/JGcjK/O9UFdCDbUYNptUUdNFTTXm3gJX YHCeO2yEBYcFtqv3pEirB2+agxSlfooJVArej0CXH81/jnwYA92NtZ9xTVsLaQ7ux3JD2n+z3FBB ahwDNY6fNL86sP9EZDdGshuXkN0YyW5cQnYH65DdwTKyKxABMgO7Vb462B2vXPh9YFLjEnXyU7ke oWnC11GkCsOR/isRZrsO4YEJ2z6Sc+ltb9KbWYJ6fvbUTLJxj+JTANFu4O7OGTsMC/C5l9+fX5+9 Pm+1r0+enreugDBjAsS/B9l8QNe5kG+6Bng6RKMkPmhjyfLvCIen7P+A3Iu06m3SIMVG4PuO3ujs HJTTqro5nLadcrSpApTCy2BckZoqssfpPF78cHpy+qLVPjk/+/ZCvSfXluB5QPW8wT5QYpBiAzjY Gl8BFl5EQ80ihX/7/HWcQATqVaMuOPydVAeRihKFn1DsPJgBQTC9KsGJonwJeqBK+PPzAE+kSpBH qhl6FdX70JWkCoYvdJu3Y91r+AlvmT8ollVyr49s/7UYnr+0SI66UbHtMvwB90j7/NXpyTl4Qkz0 P55Wy4ibOALjzeqoipcnZxelNcB1z83FiuY3lC/w7PX7r2HjH5rv4WZEc366iyN835vhjUkP56iH /rV1eXX26kJSmfCdRjeKm6B6ixPev510IBZGMv/qC3GsCTefZh1Ys3/IjNo/23BTphVNVu9EsSYJ 6gVoubtbw2LYa7tEUG7TYCbPwp07WOZmOFnSxO0EbiOkEEzznppkbLRqFeNPd3G2Cm0/tEzAVN8z yp3wlt9s7m8ebu4t6RVCCJePHNB9E39CyEe1LrElqpuWB1JhwQJG/Q8nmWruCm4zCkhIju4XugRR EIOF9zubrioV7FmcpO7jTZ0ygKnOrQ0UkiH4U7JCNYe00AGIsVDoySzPF8dSNLFehw+nxvbGD/2b zXOr7toVO9PX6iqc8jozhTlIuw35P5eDFNaKcOzm+NgcfF03Vf9z/88189Ac/OnPwdO/uIf8DH+5 hVDHmGAfFkCok5rPHUHOhems33ThUROlsZbMczSWx9FwbHVuLPy3Hgg/8qOAB/KnTreazNgRmi7N OBjmSJWJfRQVnxCI76lH/XF4DMrkkDew3Tn9aim0aVjTUIVKuZVVNDvE6+hCnCK7o2BOLLc9EsXL dvPOgTRdWMl/2rVrNBrAjS1P/0SeBKJq+uKefve1erGuZybV4VbBQcN3a1biOamoc9VVnpfylrQD ZlVL/FdxksHXARhQ9G/AH9evruw/ON0bysGd8I2EL7SDJPrExTLymMVgcMrB6rCDZoFTECsuFRJF SfsLdGmzhG38k3gNxE2h/+oxX41kH2+F1yPvuTCFWpk4KCIq3P0Q6mv/V7pLn9ya/nqjpPTTm6ua tnriu+EUqAElmi9vLUwQ3GWfcVZrU3146w77a5/cPVMUEkN4hOjisl9viMiQoBOQ40AoGZvDN23p Fz2DQu6RcPeC3uMt5nK9JzTYUjAofclPxWs+TZfCiobc3JffMNX+bbc3xWg+8k0bU+aFSGkOu/g/ Pw4EREA+cnpBU+TUIYmqidQ9vypWutdZgxPVZ89nfivu5nW3cwXqNE2htp3wUpT70Mjf/46jEm8z lgMoxFf0AOfSI2r8jWxbW5Ja7EmBUINsIC41BxV/49k1/wOBgzngyQiO5ZA5IorK57ZQdzzXrkta aDmMW6FncvkIigZ85gOopTsijFSwZMVd74AcfdtcSE6EhoCxAMEz6r3vjVSxx1HNaq7p96RZ6KJ7 V04ZTBzNNGl8EXU4AtlpfnUUTlTTgcA+aQGmQHDBlNITzsKCkXmY9MglFYA8+0ZePtYqF1Mg055D bYXE5yhLpOy2eQkhY7dTyCg0p6hAaBE0SDAlfLmpxO1CHoxZBoaxtRyRMc1dqYhEhc6jaFlPHsFl arS28QOVUbeMyJbEmDmx6buhAgQTUbSV5DV4acr3pOYujViT1IhadhW1II1j2F2RWMLbkYyeIqcE LWPY7n43pljP+1NO0tQF9eheso/4ykz4E+8mAdlWhCFx0Xmp+84VsipM7KATIwYlSdUZ1Vbu5Qst wPDZOPtYeIbbfq6fWFvnffgEUu5hQhJLxe45W07WcAKL6Yl5efJj+/TF2fmzK/tzZ4csE/gY6rfj mf80fCMfK/ggrPInitVcNY+dfIQuOwy1Tl/yXS7/0xMero+b0mK2S5ZoHEUiyoIuEaoLaWWhUnE+ grk6x55oyEpCmq8TFCx7adlOKojlcH2k9Bu3aSOxfU+5vUpwrxLZ9xCzpXIWG0GCUZISK6b1OjZq XzjYcLxb8F9XdbC9dlJvaQup3nyKRhZyZC331xX8Kcnv97NqetUaV4oag3shrD2tPKRv9PNMfYl2 6VeiQJIVJaH2ChO4TKSpEURMy74xvoKEWC/XG2LF4V6ag29jbd1hTeVBJUKqhBtmqQaRUCGKOkSo RLgpj4n2V9YjShUJv7om6HO5NrFCnRCi2w2ILlIpMDmBHr9SLoqKhYrmLEN3qaTpc9EbwsPR15ev TtvPr4qCUDsv4SjPCi2UWehVhEtkkiYyi8SVl3svqx3wHZ9XOdrxYYVQwRxCc0os+pGl+Takfs/l TIIqeR+ElOEBFZ2rwrkVH2zCGkA5+Nh8Y0oGYvttDs1V678gdwucb736rnVx5Mfxfr1BlM5Knb94 nxrMzs42u9qlNdigUWdSfeclps6XjyzV98T859PlXafe+iM6uw22K5gPOL9dgNFnHk9neefxpLd4 rKufQ0EsfAbp/z5kd3PzIZ+9wzxEABPBLKwduOdzMbwZYkLfMcg4bqBn6EITCaTCnmHCtEWcS5fS TnXxy8JhoWiJlsG254P8Q1kYXYqc8UjsbsHaLwS1vMg/mDFkdqTHIBxubUfqVmmZ9fAKo6/5FSUW J3ykVR34sifLuo/8qWtCCbX/FQ0yey+aBOqr2UIU1FDxlYNibJYM5oI5A5+5LCzqZAqtCK94wk/R VhjtSn1o0hvRcrb39/bMY6OLH4mBFXy2l3YSnryHnJ9Q4tDAMdHeAZ0S8We2atuA//kQfpoSh+PL 7KOr6muqhvrltLgjL68LX59j56EX6kueAPyOFtPqI6ENhqGWZrs4BYUWgoPBuCXSzpa2hEV8U/QF q0x2iKapLC0J5BClBN4DKBrUc/rca3723RvKUIDTY3+ysIssO7brAF0L1o4ZAh7dliarzjg7Ja7f WncPVP6DhLfaTgVMh50MxBAXvpeFcx3aaeJB+dDPhi5+5AVy0eE0KfNXv+bK3cJIa0sXRYLgtvWu TtR+cQuZMRezeN21MlrSset8YYkGmoVvjXn3FL+nDsEGOZCULJV3mFAI9/KR6B2r05QVWjyFfL0w FX+f7Mr/ZOKiwptwtYKlB7lFUN+4kCzvEqGlvnIvk5/K5R2cUItuB0nUkrxFZJ0a4TqQ1fVBqWRt sJZEEIPholhNcD8BVCArY83YS7cYgjasync1jSZyD/F7Rq/RvyCUSlc5HW9Z0AGUVFymA1SsnJ2Z m/5P+wd/eXPkMmrB5k+pLmWAjqfZHHvSzw9xfCDggZ0imSN5191z5Hb+RSPAEiQ4cgF/hczTH414 gJS7CCfSDnyJupn7nCfuY9Axl34LBdyn3sNIczHhmbjpu57e9BnmZza3/754uPeXH+m/dqAHIAS/ 3tvziOQiJGV3/+A/CF1148NOSq6yUWucT3uzjPBVBXrIp7AdoMMNVM8Nx/4VFXfoeANj3pNl4E2d qrEWbEk1+ZSK2AksKWLf2CKfjlbRsR2Tg9YPiUMPKaWEs2yAsOG/oXswIHrRvmYQDg3Xrr1svWQX HjxxDcEHdbOVmj13kDfrBJGNbWTUR3JESKf0TeyWNU1nw/dw8SljAR0Yl5I6dugR1QAvFAI4acON ekvXuK8WOf8w6c0qlaa5fnF21X756tn35xik0YBxKmxgYm2gBBYFKzcoCm/hIb4d2R3Qexe9xWf8 Md4rVpGv6JYxnhC39LAoCteLfQDLg+CSypeOwW74BhKRwUgdAFcPwG6Zq/bZ5fffvkotI3xWC3N8 CSkUthdyyWTXeh/DrrleccB12KGS84OEQf7bmfq/qpn/R5j4v5p5/zua9uVm/fom/W9ozjf+eFNe M/wvUlpWKyxJPSFCoCDKyJdZoiSUfYhFnLb+a+kI6+kHn6shrNQOVmkGK7SCFRrBWtrAH68J/Ptr Ab+CBvBHS//PFfxJof/FAv9+st7LeW/ChS5/4H3/BwkcrHmw9wAA --9ZhDeeIJxN-- From hejianj@cn.ibm.com Fri May 27 03:12:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 03:12:31 -0700 (PDT) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.com [202.81.18.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RACKXq013771 for ; Fri, 27 May 2005 03:12:21 -0700 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id j4RA7G2F112056 for ; Fri, 27 May 2005 20:07:16 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.250.237]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4RAEKgG099002 for ; Fri, 27 May 2005 20:14:20 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11/8.13.3) with ESMTP id j4RABQAj030124 for ; Fri, 27 May 2005 20:11:27 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av04.au.ibm.com (8.12.11/8.12.11) with ESMTP id j4RABPNJ030096; Fri, 27 May 2005 20:11:25 +1000 In-Reply-To: <20050527012101.4b80c005.akpm@osdl.org> Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4 To: Andrew Morton Cc: anton@samba.org, Dang En Ren , ganesh.venkatesan@intel.com, ganesh.venkatesan@gmail.com, herbert@gondor.apana.org.au, jesse.brandeburg@intel.com, jgarzik@pobox.com, Jia Sen Wang , john.ronciak@intel.com, Lei CDL Wang , linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Jian Jun He Date: Fri, 27 May 2005 18:12:57 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 05/27/2005 18:12:59 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6" X-archive-position: 1736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hejianj@cn.ibm.com Precedence: bulk X-list: netdev Content-Length: 9821 Lines: 262 --0__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6 Content-type: multipart/alternative; Boundary="1__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6" --1__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I will verify it on 2.6.12-rc5-git2 when it is ready. Best Regards! Jian Jun He CSDL, Beijing Email: hejianj@cn.ibm.com = Andrew Morton = = = To 2005-05-27 16:21 Jian Jun He/China/Contr/IBM@IBMC= N = cc anton@samba.org, Dang En = Ren/China/IBM@IBMCN, = ganesh.venkatesan@gmail.com, = ganesh.venkatesan@intel.com, = herbert@gondor.apana.org.au, = jesse.brandeburg@intel.com, = jgarzik@pobox.com, Jia Sen = Wang/China/IBM@IBMCN, = john.ronciak@intel.com, Lei CDL = Wang/China/Contr/IBM@IBMCN, = linuxppc64-dev@lists.linuxppc.or= g.s gi.com, netdev@oss.sgi.com = Subj= ect Re: Fw: [Bugme-new] [Bug 4628] N= ew: Test server hang while running r= hr (network) test on RHEL4 with ker= nel 2.6.12-rc1-mm4 = = = = = = = Jian Jun He wrote: > > I verified the problem on 2.6.12-rc5 with mm1 patch. The test server works > find during the test procedure. Great, thanks. > So I will close this defect in bugme. Well we should verify that the e100 patches which Linus merged a few ho= urs ago did contain the fix. So please test 2.6.12-rc5-git2, which should = be at ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots in ~8 hours. = --1__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I will verify it on 2.6.12-rc5-git2 when it is ready.


Best Regards!

Jian Jun He

CSDL, Beijing
Email: hejianj@cn.ibm.com

3D"InactiveAndrew Morton <akpm@osdl.org>
=

=
          Andrew Morton <akpm@osdl.org><= font size=3D"2">

          2005-05-27 16:21

 =
3D""
To
3D""
Jian Jun He/China/Contr/IBM@IBMCN
3D""
cc
3D""
anton@samba.org, Dang En Ren/China/IBM@IBMCN, ganesh.v= enkatesan@gmail.com, ganesh.venkatesan@intel.com, herbert@gondor.apana.= org.au, jesse.brandeburg@intel.com, jgarzik@pobox.com, Jia Sen Wang/Chi= na/IBM@IBMCN, john.ronciak@intel.com, Lei CDL Wang/China/Contr/IBM@IBMC= N, linuxppc64-dev@lists.linuxppc.org.sgi.com, netdev@oss.sgi.com=
3D""
Subject
3D""
Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang w= hile running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
3D=3D""

Jian Jun He <hejianj@cn.ibm.com> wrote:
>
> I verified the problem on 2.6.12-rc5 with mm1 patch. The test serv= er works
>  find during the test procedure.

Great, thanks.

>  So I will close this defect in bugme.

Well we should verify that the e100 patches which Linus merged a few ho= urs
ago did contain the fix.  So please test 2.6.12-rc5-git2, which sh= ould be
at ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots=  in ~8 hours.



= --1__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6-- --0__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=C7BBFA9DDFA47EC68f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6 Content-type: image/gif; name="pic10544.gif" Content-Disposition: inline; filename="pic10544.gif" Content-ID: <2__=C7BBFA9DDFA47EC68f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=C7BBFA9DDFA47EC68f9e8a93df938@cn.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=C7BBFA9DDFA47EC68f9e8a93df938690918cC7BBFA9DDFA47EC6-- From herbert@gondor.apana.org.au Fri May 27 04:16:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 04:16:21 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RBG8Xq018744 for ; Fri, 27 May 2005 04:16:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Dbcnr-0008SP-00; Fri, 27 May 2005 21:14:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Dbcnq-0001DX-00; Fri, 27 May 2005 21:14:58 +1000 Date: Fri, 27 May 2005 21:14:58 +1000 To: "David S. Miller" , jamal , Patrick McHardy , netdev@oss.sgi.com Subject: [7/10] [IPSEC] Fix xfrm_state leaks in error path Message-ID: <20050527111458.GG4545@gondor.apana.org.au> References: <20050527110730.GA4424@gondor.apana.org.au> <20050527110816.GA4545@gondor.apana.org.au> <20050527110852.GB4545@gondor.apana.org.au> <20050527110929.GC4545@gondor.apana.org.au> <20050527111007.GD4545@gondor.apana.org.au> <20050527111037.GE4545@gondor.apana.org.au> <20050527111140.GF4545@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9Iq5ULCa7nGtWwZS" Content-Disposition: inline In-Reply-To: <20050527111140.GF4545@gondor.apana.org.au> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2054 Lines: 77 --9Iq5ULCa7nGtWwZS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Herbert Xu wrote: > @@ -1254,6 +1326,7 @@ static int pfkey_add(struct sock *sk, st > if (IS_ERR(x)) > return PTR_ERR(x); > > + xfrm_state_hold(x); This introduces a leak when xfrm_state_add()/xfrm_state_update() fail. We hold two references (one from xfrm_state_alloc(), one from xfrm_state_hold()), but only drop one. We need to take the reference because the reference from xfrm_state_alloc() can be dropped by __xfrm_state_delete(), so the fix is to drop both references on error. Same problem in xfrm_user.c. Signed-off-by: Patrick McHardy Signed-off-by: Herbert Xu -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --9Iq5ULCa7nGtWwZS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="p9.patch" diff --git a/net/key/af_key.c b/net/key/af_key.c --- a/net/key/af_key.c +++ b/net/key/af_key.c @@ -1333,7 +1333,7 @@ static int pfkey_add(struct sock *sk, st if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); - return err; + goto out; } if (hdr->sadb_msg_type == SADB_ADD) @@ -1343,8 +1343,8 @@ static int pfkey_add(struct sock *sk, st c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; km_state_notify(x, &c); +out: xfrm_state_put(x); - return err; } diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -287,7 +287,7 @@ static int xfrm_add_sa(struct sk_buff *s if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); - return err; + goto out; } c.seq = nlh->nlmsg_seq; @@ -295,8 +295,8 @@ static int xfrm_add_sa(struct sk_buff *s c.event = nlh->nlmsg_type; km_state_notify(x, &c); +out: xfrm_state_put(x); - return err; } --9Iq5ULCa7nGtWwZS-- From hadi@cyberus.ca Fri May 27 04:15:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 04:15:25 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RBFMXq018285 for ; Fri, 27 May 2005 04:15:22 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DbcnM-0007nK-KC for netdev@oss.sgi.com; Fri, 27 May 2005 07:14:28 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbcnL-0001GB-Dl; Fri, 27 May 2005 07:14:27 -0400 Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050526185526.GZ15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 07:14:24 -0400 Message-Id: <1117192464.6688.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1334 Lines: 29 On Thu, 2005-26-05 at 20:55 +0200, Thomas Graf wrote: > To retrieve the neighbour tables send RTM_GETNEIGHTBL with the > NLM_F_DUMP flag set. Every neighbour table configuration is > spread over multiple messages to avoid running into message > size limits on systems with many interfaces. The first message > in the sequence transports all not device specific data such as > statistics, configuration, and the default parameter set. > This message is followed by 0..n messages carrying device > specific parameter sets. They all share the same value for > Although the ordering should be sufficient, NDTA_NAME can be > used to identify sequences. The initial message can be identified > by checking for NDTA_CONFIG. The device specific messages do > no contain this TLV but have NDTPA_IFINDEX set to the > corresponding interface index. > > To change neighbour table attributes, send RTM_SETNEIGHTBL > with NDTA_NAME set. Changeable attribute include NDTA_THRESH[1-3], > NDTA_GC_INTERVAL, and all TLVs in NDTA_PARMS unless marked > otherwise. Device specific parameter sets can be changed by > setting NDTPA_IFINDEX to the interface index of the corresponding > device. It would have been better, IMO, to just work on a generic idev/devinet retrieval and setting instead of one component (as in ARP in this case). cheers, jamal From herbert@gondor.apana.org.au Fri May 27 04:16:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 04:16:57 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RBGYXq018864 for ; Fri, 27 May 2005 04:16:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DbcoR-0008T1-00; Fri, 27 May 2005 21:15:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DbcoQ-0001E0-00; Fri, 27 May 2005 21:15:34 +1000 Date: Fri, 27 May 2005 21:15:34 +1000 To: "David S. Miller" , jamal , Patrick McHardy , netdev@oss.sgi.com Subject: [8/10] [IPSEC] Use NLMSG_LENGTH in xfrm_exp_state_notify Message-ID: <20050527111534.GH4545@gondor.apana.org.au> References: <20050527110730.GA4424@gondor.apana.org.au> <20050527110816.GA4545@gondor.apana.org.au> <20050527110852.GB4545@gondor.apana.org.au> <20050527110929.GC4545@gondor.apana.org.au> <20050527111007.GD4545@gondor.apana.org.au> <20050527111037.GE4545@gondor.apana.org.au> <20050527111140.GF4545@gondor.apana.org.au> <20050527111458.GG4545@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fmEUq8M7S0s+Fl0V" Content-Disposition: inline In-Reply-To: <20050527111458.GG4545@gondor.apana.org.au> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1103 Lines: 36 --fmEUq8M7S0s+Fl0V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Small fixup to use netlink macros instead of hardcoding. Signed-off-by: Jamal Hadi Salim Signed-off-by: Herbert Xu -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --fmEUq8M7S0s+Fl0V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="p10.patch" diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -1114,9 +1114,9 @@ nlmsg_failure: static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c) { struct sk_buff *skb; + int len = NLMSG_LENGTH(sizeof(struct xfrm_user_expire)); - /* fix to do alloc using NLM macros */ - skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC); + skb = alloc_skb(len, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; --fmEUq8M7S0s+Fl0V-- From herbert@gondor.apana.org.au Fri May 27 04:12:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 04:12:54 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RBCkXq017798 for ; Fri, 27 May 2005 04:12:50 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Dbckf-0008Qg-00; Fri, 27 May 2005 21:11:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Dbcke-0001D3-00; Fri, 27 May 2005 21:11:40 +1000 Date: Fri, 27 May 2005 21:11:40 +1000 To: "David S. Miller" , jamal , Patrick McHardy , netdev@oss.sgi.com Subject: [6/10] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* Message-ID: <20050527111140.GF4545@gondor.apana.org.au> References: <20050527110730.GA4424@gondor.apana.org.au> <20050527110816.GA4545@gondor.apana.org.au> <20050527110852.GB4545@gondor.apana.org.au> <20050527110929.GC4545@gondor.apana.org.au> <20050527111007.GD4545@gondor.apana.org.au> <20050527111037.GE4545@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dgjlcl3Tl+kb3YDk" Content-Disposition: inline In-Reply-To: <20050527111037.GE4545@gondor.apana.org.au> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 10881 Lines: 386 --dgjlcl3Tl+kb3YDk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This patch removes XFRM_SAP_* and converts them over to XFRM_MSG_*. The netlink interface is meant to map directly onto the underlying xfrm subsystem. Therefore rather than using a new independent representation for the events we can simply use the existing ones from xfrm_user. Signed-off-by: Herbert Xu -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --dgjlcl3Tl+kb3YDk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="p6.patch" diff --git a/include/net/xfrm.h b/include/net/xfrm.h --- a/include/net/xfrm.h +++ b/include/net/xfrm.h @@ -158,18 +158,6 @@ enum { XFRM_STATE_DEAD }; -/* events that could be sent by kernel */ -enum { - XFRM_SAP_INVALID, - XFRM_SAP_EXPIRED, - XFRM_SAP_ADDED, - XFRM_SAP_UPDATED, - XFRM_SAP_DELETED, - XFRM_SAP_FLUSHED, - __XFRM_SAP_MAX -}; -#define XFRM_SAP_MAX (__XFRM_SAP_MAX - 1) - /* callback structure passed from either netlink or pfkey */ struct km_event { diff --git a/net/key/af_key.c b/net/key/af_key.c --- a/net/key/af_key.c +++ b/net/key/af_key.c @@ -1248,13 +1248,13 @@ static int pfkey_acquire(struct sock *sk static inline int event2poltype(int event) { switch (event) { - case XFRM_SAP_DELETED: + case XFRM_MSG_DELPOLICY: return SADB_X_SPDDELETE; - case XFRM_SAP_ADDED: + case XFRM_MSG_NEWPOLICY: return SADB_X_SPDADD; - case XFRM_SAP_UPDATED: + case XFRM_MSG_UPDPOLICY: return SADB_X_SPDUPDATE; - case XFRM_SAP_EXPIRED: + case XFRM_MSG_POLEXPIRE: // return SADB_X_SPDEXPIRE; default: printk("pfkey: Unknown policy event %d\n", event); @@ -1267,13 +1267,13 @@ static inline int event2poltype(int even static inline int event2keytype(int event) { switch (event) { - case XFRM_SAP_DELETED: + case XFRM_MSG_DELSA: return SADB_DELETE; - case XFRM_SAP_ADDED: + case XFRM_MSG_NEWSA: return SADB_ADD; - case XFRM_SAP_UPDATED: + case XFRM_MSG_UPDSA: return SADB_UPDATE; - case XFRM_SAP_EXPIRED: + case XFRM_MSG_EXPIRE: return SADB_EXPIRE; default: printk("pfkey: Unknown SA event %d\n", event); @@ -1290,7 +1290,7 @@ static int key_notify_sa(struct xfrm_sta struct sadb_msg *hdr; int hsc = 3; - if (c->event == XFRM_SAP_DELETED) + if (c->event == XFRM_MSG_DELSA) hsc = 0; skb = pfkey_xfrm_state2msg(x, 0, hsc); @@ -1337,9 +1337,9 @@ static int pfkey_add(struct sock *sk, st } if (hdr->sadb_msg_type == SADB_ADD) - c.event = XFRM_SAP_ADDED; + c.event = XFRM_MSG_NEWSA; else - c.event = XFRM_SAP_UPDATED; + c.event = XFRM_MSG_UPDSA; c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; km_state_notify(x, &c); @@ -1376,7 +1376,7 @@ static int pfkey_delete(struct sock *sk, c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; - c.event = XFRM_SAP_DELETED; + c.event = XFRM_MSG_DELSA; km_state_notify(x, &c); xfrm_state_put(x); @@ -1552,7 +1552,7 @@ static int pfkey_flush(struct sock *sk, c.data.proto = proto; c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; - c.event = XFRM_SAP_FLUSHED; + c.event = XFRM_MSG_FLUSHSA; km_state_notify(NULL, &c); return 0; @@ -1962,7 +1962,7 @@ static int key_notify_policy(struct xfrm out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = PF_KEY_V2; - if (c->data.byid && c->event == XFRM_SAP_DELETED) + if (c->data.byid && c->event == XFRM_MSG_DELPOLICY) out_hdr->sadb_msg_type = SADB_X_SPDDELETE2; else out_hdr->sadb_msg_type = event2poltype(c->event); @@ -2058,9 +2058,9 @@ static int pfkey_spdadd(struct sock *sk, } if (hdr->sadb_msg_type == SADB_X_SPDUPDATE) - c.event = XFRM_SAP_UPDATED; - else - c.event = XFRM_SAP_ADDED; + c.event = XFRM_MSG_UPDPOLICY; + else + c.event = XFRM_MSG_NEWPOLICY; c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; @@ -2118,7 +2118,7 @@ static int pfkey_spddelete(struct sock * c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; - c.event = XFRM_SAP_DELETED; + c.event = XFRM_MSG_DELPOLICY; km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); xfrm_pol_put(xp); @@ -2174,7 +2174,7 @@ static int pfkey_spdget(struct sock *sk, c.pid = hdr->sadb_msg_pid; if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) { c.data.byid = 1; - c.event = XFRM_SAP_DELETED; + c.event = XFRM_MSG_DELPOLICY; km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); } else { err = key_pol_get_resp(sk, xp, hdr, pol->sadb_x_policy_dir-1); @@ -2238,7 +2238,7 @@ static int pfkey_spdflush(struct sock *s struct km_event c; xfrm_policy_flush(); - c.event = XFRM_SAP_FLUSHED; + c.event = XFRM_MSG_FLUSHPOLICY; c.pid = hdr->sadb_msg_pid; c.seq = hdr->sadb_msg_seq; km_policy_notify(NULL, 0, &c); @@ -2479,13 +2479,13 @@ static int key_notify_sa_expire(struct x static int pfkey_send_notify(struct xfrm_state *x, struct km_event *c) { switch (c->event) { - case XFRM_SAP_EXPIRED: + case XFRM_MSG_EXPIRE: return key_notify_sa_expire(x, c); - case XFRM_SAP_DELETED: - case XFRM_SAP_ADDED: - case XFRM_SAP_UPDATED: + case XFRM_MSG_DELSA: + case XFRM_MSG_NEWSA: + case XFRM_MSG_UPDSA: return key_notify_sa(x, c); - case XFRM_SAP_FLUSHED: + case XFRM_MSG_FLUSHSA: return key_notify_sa_flush(c); default: printk("pfkey: Unknown SA event %d\n", c->event); @@ -2498,13 +2498,13 @@ static int pfkey_send_notify(struct xfrm static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { switch (c->event) { - case XFRM_SAP_EXPIRED: + case XFRM_MSG_POLEXPIRE: return key_notify_policy_expire(xp, c); - case XFRM_SAP_DELETED: - case XFRM_SAP_ADDED: - case XFRM_SAP_UPDATED: + case XFRM_MSG_DELPOLICY: + case XFRM_MSG_NEWPOLICY: + case XFRM_MSG_UPDPOLICY: return key_notify_policy(xp, dir, c); - case XFRM_SAP_FLUSHED: + case XFRM_MSG_FLUSHPOLICY: return key_notify_policy_flush(c); default: printk("pfkey: Unknown policy event %d\n", c->event); diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c @@ -836,7 +836,7 @@ static void km_state_expired(struct xfrm struct km_event c; c.data.hard = hard; - c.event = XFRM_SAP_EXPIRED; + c.event = XFRM_MSG_EXPIRE; km_state_notify(x, &c); if (hard) @@ -884,7 +884,7 @@ void km_policy_expired(struct xfrm_polic struct km_event c; c.data.hard = hard; - c.event = XFRM_SAP_EXPIRED; + c.event = XFRM_MSG_POLEXPIRE; km_policy_notify(pol, dir, &c); if (hard) diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -292,10 +292,7 @@ static int xfrm_add_sa(struct sk_buff *s c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; - if (nlh->nlmsg_type == XFRM_MSG_NEWSA) - c.event = XFRM_SAP_ADDED; - else - c.event = XFRM_SAP_UPDATED; + c.event = nlh->nlmsg_type; km_state_notify(x, &c); xfrm_state_put(x); @@ -327,7 +324,7 @@ static int xfrm_del_sa(struct sk_buff *s c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; - c.event = XFRM_SAP_DELETED; + c.event = nlh->nlmsg_type; km_state_notify(x, &c); xfrm_state_put(x); @@ -719,11 +716,7 @@ static int xfrm_add_policy(struct sk_buf return err; } - if (!excl) - c.event = XFRM_SAP_UPDATED; - else - c.event = XFRM_SAP_ADDED; - + c.event = nlh->nlmsg_type; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; km_policy_notify(xp, p->dir, &c); @@ -875,7 +868,7 @@ static int xfrm_get_policy(struct sk_buf } } else { c.data.byid = p->index; - c.event = XFRM_SAP_DELETED; + c.event = nlh->nlmsg_type; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; km_policy_notify(xp, p->dir, &c); @@ -893,7 +886,7 @@ static int xfrm_flush_sa(struct sk_buff xfrm_state_flush(p->proto); c.data.proto = p->proto; - c.event = XFRM_SAP_FLUSHED; + c.event = nlh->nlmsg_type; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; km_state_notify(NULL, &c); @@ -906,7 +899,7 @@ static int xfrm_flush_policy(struct sk_b struct km_event c; xfrm_policy_flush(); - c.event = XFRM_SAP_FLUSHED; + c.event = nlh->nlmsg_type; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; km_policy_notify(NULL, 0, &c); @@ -1184,7 +1177,6 @@ static int xfrm_notify_sa(struct xfrm_st struct xfrm_usersa_info *p; struct nlmsghdr *nlh; struct sk_buff *skb; - u32 nlt; unsigned char *b; int len = xfrm_sa_len(x); @@ -1193,16 +1185,7 @@ static int xfrm_notify_sa(struct xfrm_st return -ENOMEM; b = skb->tail; - if (c->event == XFRM_SAP_ADDED) - nlt = XFRM_MSG_NEWSA; - else if (c->event == XFRM_SAP_UPDATED) - nlt = XFRM_MSG_UPDSA; - else if (c->event == XFRM_SAP_DELETED) - nlt = XFRM_MSG_DELSA; - else - goto nlmsg_failure; - - nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, sizeof(*p)); nlh->nlmsg_flags = 0; p = NLMSG_DATA(nlh); @@ -1234,13 +1217,13 @@ static int xfrm_send_state_notify(struct { switch (c->event) { - case XFRM_SAP_EXPIRED: + case XFRM_MSG_EXPIRE: return xfrm_exp_state_notify(x, c); - case XFRM_SAP_DELETED: - case XFRM_SAP_UPDATED: - case XFRM_SAP_ADDED: + case XFRM_MSG_DELSA: + case XFRM_MSG_UPDSA: + case XFRM_MSG_NEWSA: return xfrm_notify_sa(x, c); - case XFRM_SAP_FLUSHED: + case XFRM_MSG_FLUSHSA: return xfrm_notify_sa_flush(c); default: printk("xfrm_user: Unknown SA event %d\n", c->event); @@ -1408,7 +1391,6 @@ static int xfrm_notify_policy(struct xfr struct xfrm_userpolicy_info *p; struct nlmsghdr *nlh; struct sk_buff *skb; - u32 nlt = 0 ; unsigned char *b; int len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); len += NLMSG_SPACE(sizeof(struct xfrm_userpolicy_info)); @@ -1418,16 +1400,7 @@ static int xfrm_notify_policy(struct xfr return -ENOMEM; b = skb->tail; - if (c->event == XFRM_SAP_ADDED) - nlt = XFRM_MSG_NEWPOLICY; - else if (c->event == XFRM_SAP_UPDATED) - nlt = XFRM_MSG_UPDPOLICY; - else if (c->event == XFRM_SAP_DELETED) - nlt = XFRM_MSG_DELPOLICY; - else - goto nlmsg_failure; - - nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, sizeof(*p)); p = NLMSG_DATA(nlh); @@ -1474,13 +1447,13 @@ static int xfrm_send_policy_notify(struc { switch (c->event) { - case XFRM_SAP_ADDED: - case XFRM_SAP_UPDATED: - case XFRM_SAP_DELETED: + case XFRM_MSG_NEWPOLICY: + case XFRM_MSG_UPDPOLICY: + case XFRM_MSG_DELPOLICY: return xfrm_notify_policy(xp, dir, c); - case XFRM_SAP_FLUSHED: + case XFRM_MSG_FLUSHPOLICY: return xfrm_notify_policy_flush(c); - case XFRM_SAP_EXPIRED: + case XFRM_MSG_POLEXPIRE: return xfrm_exp_policy_notify(xp, dir, c); default: printk("xfrm_user: Unknown Policy event %d\n", c->event); --dgjlcl3Tl+kb3YDk-- From hadi@cyberus.ca Fri May 27 04:19:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 04:19:47 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RBJgXq023912 for ; Fri, 27 May 2005 04:19:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1Dbcrg-0001Xo-07 for netdev@oss.sgi.com; Fri, 27 May 2005 07:18:56 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dbcrf-0002R6-4l; Fri, 27 May 2005 07:18:55 -0400 Subject: Re: RFC: NAPI packet weighting patch From: jamal Reply-To: hadi@cyberus.ca To: Mitch Williams Cc: netdev@oss.sgi.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com In-Reply-To: References: Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 07:18:52 -0400 Message-Id: <1117192732.6688.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 864 Lines: 24 On Thu, 2005-26-05 at 14:36 -0700, Mitch Williams wrote: > The following patch (which applies to 2.6.12rc4) adds a new sysctl > parameter called 'netdev_packet_weight'. This parameter controls how many > backlog work units each RX packet is worth. > > With the parameter set to 0 (the default), NAPI polling works exactly as > it does today: each packet is worth one backlog work unit, and the > maximum number of received packets that will be processed in any given > softirq is controlled by the 'netdev_max_backlog' parameter. > NAPI uses already using a Weighted Round robin scheduling scheme know as DRR. I am not sure providing a weight scale on the weight is enhancing anything. Did you try to just reduce the weight instead to make it smaller instead? i.e take the resultant weight of you using a shift and set that as the weight. cheers, jamal From herbert@gondor.apana.org.au Fri May 27 04:29:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 04:30:06 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RBTvXq026564 for ; Fri, 27 May 2005 04:29:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Dbd1L-000077-00; Fri, 27 May 2005 21:28:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Dbd1G-0001M4-00; Fri, 27 May 2005 21:28:50 +1000 Date: Fri, 27 May 2005 21:28:50 +1000 To: "David S. Miller" , jamal , Patrick McHardy , netdev@oss.sgi.com Subject: [9/10] Not quite... Message-ID: <20050527112850.GA5195@gondor.apana.org.au> References: <20050527110730.GA4424@gondor.apana.org.au> <20050527110816.GA4545@gondor.apana.org.au> <20050527110852.GB4545@gondor.apana.org.au> <20050527110929.GC4545@gondor.apana.org.au> <20050527111007.GD4545@gondor.apana.org.au> <20050527111037.GE4545@gondor.apana.org.au> <20050527111140.GF4545@gondor.apana.org.au> <20050527111458.GG4545@gondor.apana.org.au> <20050527111534.GH4545@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527111534.GH4545@gondor.apana.org.au> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 296 Lines: 7 Sorry, I incorrectly counted a patch that had been reverted. So that's it for now :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hch@lst.de Fri May 27 04:55:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 04:55:53 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RBtmXq027935 for ; Fri, 27 May 2005 04:55:49 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4RBso6t019508 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 13:54:50 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j4RBsoWV019506; Fri, 27 May 2005 13:54:50 +0200 Date: Fri, 27 May 2005 13:54:50 +0200 From: Christoph Hellwig To: davem@davemloft.net Cc: netdev@oss.sgi.com Subject: [PATCH] shaper.c: fix locking Message-ID: <20050527115450.GA19469@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 4426 Lines: 190 o use a semaphore instead of an opencoded and racy lock o move locking out of shaper_kick and into the callers - most just released the lock before calling shaper_kick o remove in_interrupt() tests. from ->close we can always block, from ->hard_start_xmit and timer context never Signed-off-by: Christoph Hellwig Index: linux-2.6/include/linux/if_shaper.h =================================================================== --- linux-2.6.orig/include/linux/if_shaper.h 2005-04-30 10:17:19.000000000 +0200 +++ linux-2.6/include/linux/if_shaper.h 2005-05-27 13:47:47.000000000 +0200 @@ -23,7 +23,7 @@ __u32 shapeclock; unsigned long recovery; /* Time we can next clock a packet out on an empty queue */ - unsigned long locked; + struct semaphore sem; struct net_device_stats stats; struct net_device *dev; int (*hard_start_xmit) (struct sk_buff *skb, @@ -38,7 +38,6 @@ int (*hard_header_cache)(struct neighbour *neigh, struct hh_cache *hh); void (*header_cache_update)(struct hh_cache *hh, struct net_device *dev, unsigned char * haddr); struct net_device_stats* (*get_stats)(struct net_device *dev); - wait_queue_head_t wait_queue; struct timer_list timer; }; Index: linux-2.6/drivers/net/shaper.c =================================================================== --- linux-2.6.orig/drivers/net/shaper.c 2005-04-30 10:17:15.000000000 +0200 +++ linux-2.6/drivers/net/shaper.c 2005-05-27 13:50:41.000000000 +0200 @@ -100,35 +100,8 @@ #define SHAPER_BANNER "CymruNet Traffic Shaper BETA 0.04 for Linux 2.1\n" -/* - * Locking - */ - -static int shaper_lock(struct shaper *sh) -{ - /* - * Lock in an interrupt must fail - */ - while (test_and_set_bit(0, &sh->locked)) - { - if (!in_interrupt()) - sleep_on(&sh->wait_queue); - else - return 0; - - } - return 1; -} - static void shaper_kick(struct shaper *sh); -static void shaper_unlock(struct shaper *sh) -{ - clear_bit(0, &sh->locked); - wake_up(&sh->wait_queue); - shaper_kick(sh); -} - /* * Compute clocks on a buffer */ @@ -157,17 +130,15 @@ * Throw a frame at a shaper. */ -static int shaper_qframe(struct shaper *shaper, struct sk_buff *skb) + +static int shaper_start_xmit(struct sk_buff *skb, struct net_device *dev) { + struct shaper *shaper = dev->priv; struct sk_buff *ptr; - /* - * Get ready to work on this shaper. Lock may fail if its - * an interrupt and locked. - */ - - if(!shaper_lock(shaper)) - return -1; + if (down_trylock(&shaper->sem)) + return -1; + ptr=shaper->sendq.prev; /* @@ -260,7 +231,8 @@ dev_kfree_skb(ptr); shaper->stats.collisions++; } - shaper_unlock(shaper); + shaper_kick(shaper); + up(&shaper->sem); return 0; } @@ -297,8 +269,13 @@ static void shaper_timer(unsigned long data) { - struct shaper *sh=(struct shaper *)data; - shaper_kick(sh); + struct shaper *shaper = (struct shaper *)data; + + if (!down_trylock(&shaper->sem)) { + shaper_kick(shaper); + up(&shaper->sem); + } else + mod_timer(&shaper->timer, jiffies); } /* @@ -311,19 +288,6 @@ struct sk_buff *skb; /* - * Shaper unlock will kick - */ - - if (test_and_set_bit(0, &shaper->locked)) - { - if(sh_debug) - printk("Shaper locked.\n"); - mod_timer(&shaper->timer, jiffies); - return; - } - - - /* * Walk the list (may be empty) */ @@ -364,8 +328,6 @@ if(skb!=NULL) mod_timer(&shaper->timer, SHAPERCB(skb)->shapeclock); - - clear_bit(0, &shaper->locked); } @@ -376,14 +338,12 @@ static void shaper_flush(struct shaper *shaper) { struct sk_buff *skb; - if(!shaper_lock(shaper)) - { - printk(KERN_ERR "shaper: shaper_flush() called by an irq!\n"); - return; - } + + down(&shaper->sem); while((skb=skb_dequeue(&shaper->sendq))!=NULL) dev_kfree_skb(skb); - shaper_unlock(shaper); + shaper_kick(shaper); + up(&shaper->sem); } /* @@ -426,13 +386,6 @@ * ARP and other resolutions and not before. */ - -static int shaper_start_xmit(struct sk_buff *skb, struct net_device *dev) -{ - struct shaper *sh=dev->priv; - return shaper_qframe(sh, skb); -} - static struct net_device_stats *shaper_get_stats(struct net_device *dev) { struct shaper *sh=dev->priv; @@ -623,7 +576,6 @@ init_timer(&sh->timer); sh->timer.function=shaper_timer; sh->timer.data=(unsigned long)sh; - init_waitqueue_head(&sh->wait_queue); } /* From tgraf@suug.ch Fri May 27 05:15:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 05:15:34 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RCFUXq029070 for ; Fri, 27 May 2005 05:15:31 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 7691C1C0EB; Fri, 27 May 2005 14:15:03 +0200 (CEST) Date: Fri, 27 May 2005 14:15:03 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050527121503.GN15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> <1117192464.6688.3.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117192464.6688.3.camel@localhost.localdomain> X-archive-position: 1750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1044 Lines: 22 * jamal <1117192464.6688.3.camel@localhost.localdomain> 2005-05-27 07:14 > It would have been better, IMO, to just work on a generic idev/devinet > retrieval and setting instead of one component (as in ARP in this > case). I thought about adding a devinet component to allow retrieving/setting device specific parameters (along with other settings) but dropped the idea because I did not want to implement the data structures twice. I think this is cleaner, it allows one request to be sent to see the complete arp/ndisc configuration rather than sending one to retrieve the global configuration/statistics and another one to retrieve device specific parameters. Nevertheless, I'm open for changes so once I've written the devinet component to change rp_filter, forwarding, arp_filter, etc. we can still move the device specific NDTA_PARMS to the devinet component if we still think it would be better. For now, the neightbl component is clean, small, well defined and probably never needs to be touched again. Is that acceptable for you? From hadi@cyberus.ca Fri May 27 05:33:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 05:33:36 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RCXWXq030105 for ; Fri, 27 May 2005 05:33:32 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Dbe14-0000M8-Nm for netdev@oss.sgi.com; Fri, 27 May 2005 06:32:42 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dbe12-00077w-E0; Fri, 27 May 2005 08:32:40 -0400 Subject: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Thomas Graf , netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-WvJ4csN17Q9w9js+PpKh" Organization: unknown Date: Fri, 27 May 2005 08:32:37 -0400 Message-Id: <1117197157.6688.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 1751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 13009 Lines: 430 --=-WvJ4csN17Q9w9js+PpKh Content-Type: text/plain Content-Transfer-Encoding: 7bit I think i may have missed a few spots. Thomas it would be worth creating a macro which takes flags as input as well to replace things along the lines of: nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); nlh->nlmsg_flags = flags; Since theres a sufficient number of them. I will work next on fixing ioctl derived events to contain the proper pid of the process that caused the event cheers, jamal -- This patch rectifies some rtnetlink message builders that derive the flags from the pid. It is now explicit like the other cases which get it right. Signed-off-by: Jamal Hadi Salim --=-WvJ4csN17Q9w9js+PpKh Content-Disposition: attachment; filename=rtnet_info_p Content-Type: text/plain; name=rtnet_info_p; charset=UTF-8 Content-Transfer-Encoding: 7bit net/core/neighbour.c: needs update net/core/rtnetlink.c: needs update net/decnet/dn_route.c: needs update net/ipv4/devinet.c: needs update net/ipv4/route.c: needs update net/ipv6/addrconf.c: needs update Index: net/core/neighbour.c =================================================================== --- 2cbffac3afc093b729781fdc58acfb43acc98bc8/net/core/neighbour.c (mode:100644) +++ uncommitted/net/core/neighbour.c (mode:100644) @@ -1548,7 +1548,7 @@ static int neigh_fill_info(struct sk_buff *skb, struct neighbour *n, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned flags) { unsigned long now = jiffies; unsigned char *b = skb->tail; @@ -1559,7 +1559,7 @@ sizeof(struct ndmsg)); struct ndmsg *ndm = NLMSG_DATA(nlh); - nlh->nlmsg_flags = pid ? NLM_F_MULTI : 0; + nlh->nlmsg_flags = flags; ndm->ndm_family = n->ops->family; ndm->ndm_flags = n->flags; ndm->ndm_type = n->type; @@ -1609,7 +1609,8 @@ continue; if (neigh_fill_info(skb, n, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, - RTM_NEWNEIGH) <= 0) { + RTM_NEWNEIGH, + NLM_F_MULTI) <= 0) { read_unlock_bh(&tbl->lock); rc = -1; goto out; @@ -2018,7 +2019,7 @@ if (!skb) return; - if (neigh_fill_info(skb, n, 0, 0, RTM_GETNEIGH) < 0) { + if (neigh_fill_info(skb, n, 0, 0, RTM_GETNEIGH, 0) < 0) { kfree_skb(skb); return; } @@ -2037,7 +2038,7 @@ if (!skb) return; - if (neigh_fill_info(skb, n, 0, 0, RTM_NEWNEIGH) < 0) { + if (neigh_fill_info(skb, n, 0, 0, RTM_NEWNEIGH, 0) < 0) { kfree_skb(skb); return; } Index: net/core/rtnetlink.c =================================================================== --- 2cbffac3afc093b729781fdc58acfb43acc98bc8/net/core/rtnetlink.c (mode:100644) +++ uncommitted/net/core/rtnetlink.c (mode:100644) @@ -176,14 +176,15 @@ static int rtnetlink_fill_ifinfo(struct sk_buff *skb, struct net_device *dev, - int type, u32 pid, u32 seq, u32 change) + int type, u32 pid, u32 seq, u32 change, + unsigned flags) { struct ifinfomsg *r; struct nlmsghdr *nlh; unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, type, sizeof(*r)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh->nlmsg_flags = flags; r = NLMSG_DATA(nlh); r->ifi_family = AF_UNSPEC; r->ifi_type = dev->type; @@ -273,7 +274,7 @@ for (dev=dev_base, idx=0; dev; dev = dev->next, idx++) { if (idx < s_idx) continue; - if (rtnetlink_fill_ifinfo(skb, dev, RTM_NEWLINK, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, 0) <= 0) + if (rtnetlink_fill_ifinfo(skb, dev, RTM_NEWLINK, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, 0, NLM_F_MULTI) <= 0) break; } read_unlock(&dev_base_lock); @@ -447,7 +448,7 @@ if (!skb) return; - if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change) < 0) { + if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change, 0) < 0) { kfree_skb(skb); return; } Index: net/decnet/dn_route.c =================================================================== --- 2cbffac3afc093b729781fdc58acfb43acc98bc8/net/decnet/dn_route.c (mode:100644) +++ uncommitted/net/decnet/dn_route.c (mode:100644) @@ -1465,7 +1465,7 @@ return dn_route_input_slow(skb); } -static int dn_rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, int event, int nowait) +static int dn_rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, int event, int nowait, unsigned flags) { struct dn_route *rt = (struct dn_route *)skb->dst; struct rtmsg *r; @@ -1475,7 +1475,7 @@ nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r)); r = NLMSG_DATA(nlh); - nlh->nlmsg_flags = (nowait && pid) ? NLM_F_MULTI : 0; + nlh->nlmsg_flags = flags; r->rtm_family = AF_DECnet; r->rtm_dst_len = 16; r->rtm_src_len = 0; @@ -1596,7 +1596,7 @@ NETLINK_CB(skb).dst_pid = NETLINK_CB(in_skb).pid; - err = dn_rt_fill_info(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq, RTM_NEWROUTE, 0); + err = dn_rt_fill_info(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq, RTM_NEWROUTE, 0, 0); if (err == 0) goto out_free; @@ -1644,7 +1644,8 @@ continue; skb->dst = dst_clone(&rt->u.dst); if (dn_rt_fill_info(skb, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWROUTE, 1) <= 0) { + cb->nlh->nlmsg_seq, RTM_NEWROUTE, + 1, NLM_F_MULTI) <= 0) { dst_release(xchg(&skb->dst, NULL)); rcu_read_unlock_bh(); goto done; Index: net/ipv4/devinet.c =================================================================== --- 2cbffac3afc093b729781fdc58acfb43acc98bc8/net/ipv4/devinet.c (mode:100644) +++ uncommitted/net/ipv4/devinet.c (mode:100644) @@ -1015,14 +1015,14 @@ }; static int inet_fill_ifaddr(struct sk_buff *skb, struct in_ifaddr *ifa, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh->nlmsg_flags = flags; ifm = NLMSG_DATA(nlh); ifm->ifa_family = AF_INET; ifm->ifa_prefixlen = ifa->ifa_prefixlen; @@ -1075,7 +1075,7 @@ continue; if (inet_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, - RTM_NEWADDR) <= 0) { + RTM_NEWADDR, NLM_F_MULTI) <= 0) { rcu_read_unlock(); goto done; } @@ -1098,7 +1098,7 @@ if (!skb) netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, ENOBUFS); - else if (inet_fill_ifaddr(skb, ifa, 0, 0, event) < 0) { + else if (inet_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, EINVAL); } else { Index: net/ipv4/route.c =================================================================== --- 2cbffac3afc093b729781fdc58acfb43acc98bc8/net/ipv4/route.c (mode:100644) +++ uncommitted/net/ipv4/route.c (mode:100644) @@ -2581,7 +2581,7 @@ } static int rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, int event, - int nowait) + int nowait, unsigned flags) { struct rtable *rt = (struct rtable*)skb->dst; struct rtmsg *r; @@ -2593,7 +2593,7 @@ #endif nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r)); r = NLMSG_DATA(nlh); - nlh->nlmsg_flags = (nowait && pid) ? NLM_F_MULTI : 0; + nlh->nlmsg_flags = flags; r->rtm_family = AF_INET; r->rtm_dst_len = 32; r->rtm_src_len = 0; @@ -2744,7 +2744,7 @@ NETLINK_CB(skb).dst_pid = NETLINK_CB(in_skb).pid; err = rt_fill_info(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq, - RTM_NEWROUTE, 0); + RTM_NEWROUTE, 0, 0); if (!err) goto out_free; if (err < 0) { @@ -2781,8 +2781,8 @@ continue; skb->dst = dst_clone(&rt->u.dst); if (rt_fill_info(skb, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, - RTM_NEWROUTE, 1) <= 0) { + cb->nlh->nlmsg_seq, RTM_NEWROUTE, + 1, NLM_F_MULTI) <= 0) { dst_release(xchg(&skb->dst, NULL)); rcu_read_unlock_bh(); goto done; Index: net/ipv6/addrconf.c =================================================================== --- 2cbffac3afc093b729781fdc58acfb43acc98bc8/net/ipv6/addrconf.c (mode:100644) +++ uncommitted/net/ipv6/addrconf.c (mode:100644) @@ -2621,7 +2621,7 @@ } static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; @@ -2629,7 +2629,7 @@ unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh->nlmsg_flags = flags; ifm = NLMSG_DATA(nlh); ifm->ifa_family = AF_INET6; ifm->ifa_prefixlen = ifa->prefix_len; @@ -2671,7 +2671,7 @@ } static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; @@ -2679,7 +2679,7 @@ unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh->nlmsg_flags = flags; ifm = NLMSG_DATA(nlh); ifm->ifa_family = AF_INET6; ifm->ifa_prefixlen = 128; @@ -2708,7 +2708,7 @@ } static int inet6_fill_ifacaddr(struct sk_buff *skb, struct ifacaddr6 *ifaca, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; @@ -2716,7 +2716,7 @@ unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh->nlmsg_flags = flags; ifm = NLMSG_DATA(nlh); ifm->ifa_family = AF_INET6; ifm->ifa_prefixlen = 128; @@ -2785,7 +2785,8 @@ continue; if ((err = inet6_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) + cb->nlh->nlmsg_seq, RTM_NEWADDR, + NLM_F_MULTI)) <= 0) goto done; } /* temp addr */ @@ -2796,7 +2797,8 @@ continue; if ((err = inet6_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) + cb->nlh->nlmsg_seq, RTM_NEWADDR, + NLM_F_MULTI)) <= 0) goto done; } #endif @@ -2809,7 +2811,8 @@ continue; if ((err = inet6_fill_ifmcaddr(skb, ifmca, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_GETMULTICAST)) <= 0) + cb->nlh->nlmsg_seq, RTM_GETMULTICAST, + NLM_F_MULTI)) <= 0) goto done; } break; @@ -2821,7 +2824,8 @@ continue; if ((err = inet6_fill_ifacaddr(skb, ifaca, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_GETANYCAST)) <= 0) + cb->nlh->nlmsg_seq, RTM_GETANYCAST, + NLM_F_MULTI)) <= 0) goto done; } break; @@ -2871,7 +2875,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, ENOBUFS); return; } - if (inet6_fill_ifaddr(skb, ifa, 0, 0, event) < 0) { + if (inet6_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, EINVAL); return; @@ -2906,7 +2910,7 @@ } static int inet6_fill_ifinfo(struct sk_buff *skb, struct inet6_dev *idev, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned flags) { struct net_device *dev = idev->dev; __s32 *array = NULL; @@ -2918,7 +2922,7 @@ struct ifla_cacheinfo ci; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh->nlmsg_flags = flags; r = NLMSG_DATA(nlh); r->ifi_family = AF_INET6; r->ifi_type = dev->type; @@ -2985,7 +2989,7 @@ if ((idev = in6_dev_get(dev)) == NULL) continue; err = inet6_fill_ifinfo(skb, idev, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWLINK); + cb->nlh->nlmsg_seq, RTM_NEWLINK, NLM_F_MULTI); in6_dev_put(idev); if (err <= 0) break; @@ -3007,7 +3011,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, ENOBUFS); return; } - if (inet6_fill_ifinfo(skb, idev, 0, 0, event) < 0) { + if (inet6_fill_ifinfo(skb, idev, 0, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, EINVAL); return; @@ -3017,7 +3021,8 @@ } static int inet6_fill_prefix(struct sk_buff *skb, struct inet6_dev *idev, - struct prefix_info *pinfo, u32 pid, u32 seq, int event) + struct prefix_info *pinfo, u32 pid, u32 seq, + int event, unsigned flags) { struct prefixmsg *pmsg; struct nlmsghdr *nlh; @@ -3025,9 +3030,7 @@ struct prefix_cacheinfo ci; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*pmsg)); - - if (pid) - nlh->nlmsg_flags |= NLM_F_MULTI; + nlh->nlmsg_flags = flags; pmsg = NLMSG_DATA(nlh); pmsg->prefix_family = AF_INET6; @@ -3067,7 +3070,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, ENOBUFS); return; } - if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event) < 0) { + if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, EINVAL); return; --=-WvJ4csN17Q9w9js+PpKh-- From tgraf@suug.ch Fri May 27 05:50:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 05:50:41 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RCobXq031090 for ; Fri, 27 May 2005 05:50:38 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id C14351C0EB; Fri, 27 May 2005 14:50:10 +0200 (CEST) Date: Fri, 27 May 2005 14:50:10 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting Message-ID: <20050527125010.GO15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117197157.6688.24.camel@localhost.localdomain> X-archive-position: 1752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2034 Lines: 57 * jamal <1117197157.6688.24.camel@localhost.localdomain> 2005-05-27 08:32 > > I think i may have missed a few spots. > > Thomas it would be worth creating a macro which takes flags as input as > well to replace things along the lines of: > nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); > nlh->nlmsg_flags = flags; > Since theres a sufficient number of them. Right, proposal: --- 6204e59b7aa59cf79632003c621e521db1297b1b/include/linux/netlink.h (mode:100644) +++ uncommitted/include/linux/netlink.h (mode:100644) @@ -156,7 +156,7 @@ }; static __inline__ struct nlmsghdr * -__nlmsg_put(struct sk_buff *skb, u32 pid, u32 seq, int type, int len) +__nlmsg_put(struct sk_buff *skb, u32 pid, u32 seq, int type, int len, int flags) { struct nlmsghdr *nlh; int size = NLMSG_LENGTH(len); @@ -164,20 +164,23 @@ nlh = (struct nlmsghdr*)skb_put(skb, NLMSG_ALIGN(size)); nlh->nlmsg_type = type; nlh->nlmsg_len = size; - nlh->nlmsg_flags = 0; + nlh->nlmsg_flags = flags; nlh->nlmsg_pid = pid; nlh->nlmsg_seq = seq; return nlh; } -#define NLMSG_PUT(skb, pid, seq, type, len) \ +#define NLMSG_NEW(skb, pid, seq, type, len, flags) \ ({ if (skb_tailroom(skb) < (int)NLMSG_SPACE(len)) \ goto nlmsg_failure; \ - __nlmsg_put(skb, pid, seq, type, len); }) + __nlmsg_put(skb, pid, seq, type, len, flags); }) + +#define NLMSG_PUT(skb, pid, seq, type, len) \ + NLMSG_NEW(skb, pid, seq, type, len, 0) -#define NLMSG_PUT_ANSWER(skb, cb, type, len) \ - NLMSG_PUT(skb, NETLINK_CB((cb)->skb).pid, \ - (cb)->nlh->nlmsg_seq, type, len) +#define NLMSG_NEW_ANSWER(skb, cb, type, len, flags) \ + NLMSG_NEW(skb, NETLINK_CB((cb)->skb).pid, \ + (cb)->nlh->nlmsg_seq, type, len, flags) #define NLMSG_END(skb, nlh) \ ({ (nlh)->nlmsg_len = (skb)->tail - (unsigned char *) (nlh); \ I'd be especially happy with this because __nlmsg_put keeps control over the flags ;-> From hadi@cyberus.ca Fri May 27 06:51:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 06:52:00 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RDpvXq001026 for ; Fri, 27 May 2005 06:51:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DbfEt-0005a4-LG for netdev@oss.sgi.com; Fri, 27 May 2005 09:51:03 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbfEp-0004tB-5u; Fri, 27 May 2005 09:50:59 -0400 Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050527121503.GN15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> <1117192464.6688.3.camel@localhost.localdomain> <20050527121503.GN15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 09:50:53 -0400 Message-Id: <1117201853.6383.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2179 Lines: 54 On Fri, 2005-27-05 at 14:15 +0200, Thomas Graf wrote: > * jamal <1117192464.6688.3.camel@localhost.localdomain> 2005-05-27 07:14 > > It would have been better, IMO, to just work on a generic idev/devinet > > retrieval and setting instead of one component (as in ARP in this > > case). > > I thought about adding a devinet component to allow retrieving/setting > device specific parameters (along with other settings) but dropped the > idea because I did not want to implement the data structures twice. > > I think this is cleaner, it allows one request to be sent to see > the complete arp/ndisc configuration rather than sending one to > retrieve the global configuration/statistics and another one > to retrieve device specific parameters. > > Nevertheless, I'm open for changes so once I've written the devinet > component to change rp_filter, forwarding, arp_filter, etc. we can > still move the device specific NDTA_PARMS to the devinet component > if we still think it would be better. For now, the neightbl component > is clean, small, well defined and probably never needs to be touched > again. > > Is that acceptable for you? > I think depends on where we are going. My view is that the current abstraction model is fine for this specific bit. i.e from an abstraction point of view these parameters are per device per protocol (v4/v6/etc). In other words, if i was to draw a model diagram it would show: --> netdevice ----> v4 addresses ----> v4 netdevice configuration ----> v6 addresses ----> v6 netdevice configuration i.e the best way to do it imo, especially since you are doing this from scratch, is to maintain that model. Your patch breaks away from this. The only thing that is not devconfig queriable or settable at the moment is the stats. That i can certainly see as being part of the standard neighbor details for example. Infact this would apply elsewhere as well, for example in the FIB where some stats are being displayed via /proc at the moment. We actually did discuss this a while back and i had an incomplete patch for doing it the way i suggest above which i unfortunately cant seem to locate at the moment. cheers, jamal From hadi@cyberus.ca Fri May 27 06:59:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 06:59:51 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RDxkXq001937 for ; Fri, 27 May 2005 06:59:46 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DbfMW-0003Kn-JX for netdev@oss.sgi.com; Fri, 27 May 2005 09:58:56 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbfMU-0006jO-Hu; Fri, 27 May 2005 09:58:54 -0400 Subject: Re: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050527125010.GO15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 09:58:51 -0400 Message-Id: <1117202331.6383.39.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 567 Lines: 19 On Fri, 2005-27-05 at 14:50 +0200, Thomas Graf wrote: > > -#define NLMSG_PUT(skb, pid, seq, type, len) \ > +#define NLMSG_NEW(skb, pid, seq, type, len, flags) \ How about introducing NLMSG_NEW and leave NLMSG_PUT where it is? This way we could do incremental updates. If there are not too many of those NLMSG_PUT around, then it shouldnt be an issue. The first change would be definetely on top of the current patch i sent which is well deserved. Lets have Dave swallow my patch then either you or i could make those changes. Sounds reasonable? cheers, jamal From adobriyan@gmail.com Fri May 27 07:04:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:05:02 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RE4vXq002618 for ; Fri, 27 May 2005 07:04:57 -0700 Received: by wproxy.gmail.com with SMTP id 68so1806490wra for ; Fri, 27 May 2005 07:04:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=WYYibsWfuAIa9VsqJMZxNfod1EQE0arU38tNt9H+GhQN6X/ZjetWtoGBoO/1x1M1OO+7jFI1KhurgBvTTTaPP2ykSfXbrB6VLxO+hDa+/jnStZeVU4vdr5PwmyQm0c4veofSF3t6k5TSfgpzbV0mFCIzbyB/JiEXRh98E+SBKCk= Received: by 10.54.8.33 with SMTP id 33mr2547786wrh; Fri, 27 May 2005 07:04:08 -0700 (PDT) Received: from mipter.zuzino.mipt.ru ([217.10.38.130]) by mx.gmail.com with ESMTP id 15sm1294854wrl.2005.05.27.07.04.05; Fri, 27 May 2005 07:04:08 -0700 (PDT) From: Alexey Dobriyan To: netdev@oss.sgi.com Subject: [PATCH] baycom_epp.c: Fix compilation with gcc-4.1.0-20050522 Date: Fri, 27 May 2005 18:08:31 +0400 User-Agent: KMail/1.7.2 Cc: Thomas Sailer MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505271808.32032.adobriyan@gmail.com> X-archive-position: 1755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: netdev Content-Length: 2975 Lines: 60 drivers/net/hamradio/baycom_epp.c:432: error: jump into statement expression ... Signed-off-by: Alexey Dobriyan --- linux-vanilla/drivers/net/hamradio/baycom_epp.c 2005-05-27 12:58:48.000000000 +0400 +++ linux-gcc4/drivers/net/hamradio/baycom_epp.c 2005-05-27 17:54:14.000000000 +0400 @@ -380,22 +380,18 @@ static inline void do_kiss_params(struct */ #define ENCODEITERA(j) \ -({ \ if (!(notbitstream & (0x1f0 << j))) \ goto stuff##j; \ - encodeend##j: ; \ -}) + encodeend##j: ; #define ENCODEITERB(j) \ -({ \ stuff##j: \ bitstream &= ~(0x100 << j); \ bitbuf = (bitbuf & (((2 << j) << numbit) - 1)) | \ ((bitbuf & ~(((2 << j) << numbit) - 1)) << 1); \ numbit++; \ notbitstream = ~bitstream; \ - goto encodeend##j; \ -}) + goto encodeend##j; static void encode_hdlc(struct baycom_state *bc) @@ -611,16 +607,13 @@ static void do_rxpacket(struct net_devic } #define DECODEITERA(j) \ -({ \ if (!(notbitstream & (0x0fc << j))) /* flag or abort */ \ goto flgabrt##j; \ if ((bitstream & (0x1f8 << j)) == (0xf8 << j)) /* stuffed bit */ \ goto stuff##j; \ - enditer##j: ; \ -}) + enditer##j: ; #define DECODEITERB(j) \ -({ \ flgabrt##j: \ if (!(notbitstream & (0x1fc << j))) { /* abort received */ \ state = 0; \ @@ -638,8 +631,7 @@ static void do_rxpacket(struct net_devic stuff##j: \ numbits--; \ bitbuf = (bitbuf & ((~0xff) << j)) | ((bitbuf & ~((~0xff) << j)) << 1); \ - goto enditer##j; \ -}) + goto enditer##j; static int receive(struct net_device *dev, int cnt) { From tgraf@suug.ch Fri May 27 07:13:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:13:51 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4REDlXq003699 for ; Fri, 27 May 2005 07:13:48 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id E40981C0EB; Fri, 27 May 2005 16:13:20 +0200 (CEST) Date: Fri, 27 May 2005 16:13:20 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting Message-ID: <20050527141320.GQ15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117202331.6383.39.camel@localhost.localdomain> X-archive-position: 1757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 855 Lines: 23 * jamal <1117202331.6383.39.camel@localhost.localdomain> 2005-05-27 09:58 > On Fri, 2005-27-05 at 14:50 +0200, Thomas Graf wrote: > > > > > > -#define NLMSG_PUT(skb, pid, seq, type, len) \ > > +#define NLMSG_NEW(skb, pid, seq, type, len, flags) \ > > How about introducing NLMSG_NEW and leave NLMSG_PUT where it is? > This way we could do incremental updates. If there are not too many of > those NLMSG_PUT around, then it shouldnt be an issue. That is what the patch does but the diff looks a bit irritating. 1) Introduce NLMSG_NEW to take flags 2) Make NLMSG_PUT call NLMSG_NEW with flags==0 3) Change __nlmsg_put to take flags argument > The first change would be definetely on top of the current patch i sent > which is well deserved. > Lets have Dave swallow my patch then either you or i could make those > changes. Sounds reasonable? Sure. From tgraf@suug.ch Fri May 27 07:50:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:50:34 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4REoUXq005360 for ; Fri, 27 May 2005 07:50:31 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 507F41C0EB; Fri, 27 May 2005 16:50:02 +0200 (CEST) Date: Fri, 27 May 2005 16:50:02 +0200 From: Thomas Graf To: "David S. Miller" Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: [PATCHSET] dsmark fixes & cleanups Message-ID: <20050527145002.GR15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 1758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 697 Lines: 20 Dave, The following patchset fixes various smallish bugs in dsmark and does a general cleanup. The lower the patch number, the less intrusive and more serious the bug is. Patches tested using tc-testsuite (see below) and some manual testing. --- dsmark: dsmark root qdisc creation succeeded dsmark: dsmark class 1 creation succeeded dsmark: dsmark class 2 creation succeeded dsmark: dsmark dump qdisc succeeded with output: qdisc dsmark 10: indices 0x0040 default_index 0x0001 set_tc_index dsmark: dsmark dump class succeeded with output: class dsmark 10:12 parent 10: mask 0xff value 0x02 class dsmark 10:13 parent 10: mask 0xfc value 0x04 dsmark: generic qdisc tree deletion succeeded --- From tgraf@suug.ch Fri May 27 07:51:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:51:31 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4REpPXq005528 for ; Fri, 27 May 2005 07:51:26 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id BB96A1C0EB; Fri, 27 May 2005 16:50:58 +0200 (CEST) Date: Fri, 27 May 2005 16:50:58 +0200 From: Thomas Graf To: "David S. Miller" Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: [PATCH 1/7] [PKT_SCHED] Fix dsmark to count ignored indices while walking Message-ID: <20050527145058.GS15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527145002.GR15391@postel.suug.ch> X-archive-position: 1759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1144 Lines: 37 Unused indices which are ignored while walking must still be counted to avoid dumping the same index twice. Signed-off-by: Thomas Graf --- commit 99ed2eb92cc035b223e2d383446f7f183600ba27 tree 127116412eeedf62fcda0acc882500cd981cbab1 parent e66646bb6686bb1be24e25b3743028f762544de2 author Thomas Graf Fri, 27 May 2005 14:29:52 +0200 committer Thomas Graf Fri, 27 May 2005 14:29:52 +0200 net/sched/sch_dsmark.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) Index: net/sched/sch_dsmark.c =================================================================== --- 735126283c38e22995f5da71b2e90a9d71ac4b1e/net/sched/sch_dsmark.c (mode:100644) +++ 127116412eeedf62fcda0acc882500cd981cbab1/net/sched/sch_dsmark.c (mode:100644) @@ -163,14 +163,15 @@ return; for (i = 0; i < p->indices; i++) { if (p->mask[i] == 0xff && !p->value[i]) - continue; + goto ignore; if (walker->count >= walker->skip) { if (walker->fn(sch, i+1, walker) < 0) { walker->stop = 1; break; } } - walker->count++; +ignore: + walker->count++; } } From tgraf@suug.ch Fri May 27 07:52:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:52:08 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4REq3Xq005818 for ; Fri, 27 May 2005 07:52:04 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B946A1C0EB; Fri, 27 May 2005 16:51:36 +0200 (CEST) Date: Fri, 27 May 2005 16:51:36 +0200 From: Thomas Graf To: "David S. Miller" Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: [PATCH 2/7] [PKT_SCHED] make dsmark try using pfifo instead of noop while grafting Message-ID: <20050527145136.GT15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527145002.GR15391@postel.suug.ch> X-archive-position: 1760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1011 Lines: 33 Signed-off-by: Thomas Graf --- commit 0297af53b691b2c14b09f65be7b9e32a43a34319 tree 686339fe0d5a70e263d261324365e65f53cc9880 parent 99ed2eb92cc035b223e2d383446f7f183600ba27 author Thomas Graf Fri, 27 May 2005 14:30:37 +0200 committer Thomas Graf Fri, 27 May 2005 14:30:37 +0200 net/sched/sch_dsmark.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) Index: net/sched/sch_dsmark.c =================================================================== --- 127116412eeedf62fcda0acc882500cd981cbab1/net/sched/sch_dsmark.c (mode:100644) +++ 686339fe0d5a70e263d261324365e65f53cc9880/net/sched/sch_dsmark.c (mode:100644) @@ -73,8 +73,13 @@ DPRINTK("dsmark_graft(sch %p,[qdisc %p],new %p,old %p)\n",sch,p,new, old); - if (!new) - new = &noop_qdisc; + + if (new == NULL) { + new = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (new == NULL) + new = &noop_qdisc; + } + sch_tree_lock(sch); *old = xchg(&p->q,new); if (*old) From tgraf@suug.ch Fri May 27 07:52:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:52:53 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4REqnXq006349 for ; Fri, 27 May 2005 07:52:49 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 3D6391C0EB; Fri, 27 May 2005 16:52:22 +0200 (CEST) Date: Fri, 27 May 2005 16:52:22 +0200 From: Thomas Graf To: "David S. Miller" Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: [PATCH 3/7] [PKT_SCHED] Disable dsmark debugging messages by default Message-ID: <20050527145222.GU15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527145002.GR15391@postel.suug.ch> X-archive-position: 1761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 874 Lines: 26 Signed-off-by: Thomas Graf --- commit 0ecf7991c4f8532a5afc903e175e2bec80585fea tree 07e28bf36ae4052536820a75bbefc6ac1c7a9098 parent 0297af53b691b2c14b09f65be7b9e32a43a34319 author Thomas Graf Fri, 27 May 2005 14:35:44 +0200 committer Thomas Graf Fri, 27 May 2005 14:35:44 +0200 net/sched/sch_dsmark.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: net/sched/sch_dsmark.c =================================================================== --- 686339fe0d5a70e263d261324365e65f53cc9880/net/sched/sch_dsmark.c (mode:100644) +++ 07e28bf36ae4052536820a75bbefc6ac1c7a9098/net/sched/sch_dsmark.c (mode:100644) @@ -18,7 +18,7 @@ #include -#if 1 /* control */ +#if 0 /* control */ #define DPRINTK(format,args...) printk(KERN_DEBUG format,##args) #else #define DPRINTK(format,args...) From tgraf@suug.ch Fri May 27 07:53:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:53:27 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RErKXq006681 for ; Fri, 27 May 2005 07:53:22 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 1D0CA1C0EB; Fri, 27 May 2005 16:52:53 +0200 (CEST) Date: Fri, 27 May 2005 16:52:52 +0200 From: Thomas Graf To: "David S. Miller" Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: [PATCH 4/7] [RTNETLINK] Add RTA_(PUT|GET) shortcuts for u8, u16, and flag Message-ID: <20050527145252.GV15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527145002.GR15391@postel.suug.ch> X-archive-position: 1762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2227 Lines: 68 Signed-off-by: Thomas Graf --- commit c49bbdd22621352b9b96097ffdb9e5c14b4ed95e tree 6204e59b7aa59cf79632003c621e521db1297b1b parent 0ecf7991c4f8532a5afc903e175e2bec80585fea author Thomas Graf Fri, 27 May 2005 14:36:11 +0200 committer Thomas Graf Fri, 27 May 2005 14:36:11 +0200 include/linux/rtnetlink.h | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+) Index: include/linux/rtnetlink.h =================================================================== --- 07e28bf36ae4052536820a75bbefc6ac1c7a9098/include/linux/rtnetlink.h (mode:100644) +++ 6204e59b7aa59cf79632003c621e521db1297b1b/include/linux/rtnetlink.h (mode:100644) @@ -897,6 +897,14 @@ goto rtattr_failure; \ memcpy(skb_put(skb, RTA_ALIGN(attrlen)), data, attrlen); }) +#define RTA_PUT_U8(skb, attrtype, value) \ +({ u8 _tmp = (value); \ + RTA_PUT(skb, attrtype, sizeof(u8), &_tmp); }) + +#define RTA_PUT_U16(skb, attrtype, value) \ +({ u16 _tmp = (value); \ + RTA_PUT(skb, attrtype, sizeof(u16), &_tmp); }) + #define RTA_PUT_U32(skb, attrtype, value) \ ({ u32 _tmp = (value); \ RTA_PUT(skb, attrtype, sizeof(u32), &_tmp); }) @@ -914,6 +922,9 @@ #define RTA_PUT_STRING(skb, attrtype, value) \ RTA_PUT(skb, attrtype, strlen(value) + 1, value) +#define RTA_PUT_FLAG(skb, attrtype) \ + RTA_PUT(skb, attrtype, 0, NULL); + #define RTA_NEST(skb, type) \ ({ struct rtattr *__start = (struct rtattr *) (skb)->tail; \ RTA_PUT(skb, type, 0, NULL); \ @@ -928,6 +939,16 @@ skb_trim(skb, (unsigned char *) (start) - (skb)->data); \ -1; }) +#define RTA_GET_U8(rta) \ +({ if (!rta || RTA_PAYLOAD(rta) < sizeof(u8)) \ + goto rtattr_failure; \ + *(u8 *) RTA_DATA(rta); }) + +#define RTA_GET_U16(rta) \ +({ if (!rta || RTA_PAYLOAD(rta) < sizeof(u16)) \ + goto rtattr_failure; \ + *(u16 *) RTA_DATA(rta); }) + #define RTA_GET_U32(rta) \ ({ if (!rta || RTA_PAYLOAD(rta) < sizeof(u32)) \ goto rtattr_failure; \ @@ -940,6 +961,8 @@ memcpy(&_tmp, RTA_DATA(rta), sizeof(_tmp)); \ _tmp; }) +#define RTA_GET_FLAG(rta) (!!(rta)) + #define RTA_GET_SECS(rta) ((unsigned long) RTA_GET_U64(rta) * HZ) #define RTA_GET_MSECS(rta) (msecs_to_jiffies((unsigned long) RTA_GET_U64(rta))) From tgraf@suug.ch Fri May 27 07:54:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:54:05 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RErxXq007111 for ; Fri, 27 May 2005 07:53:59 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id AB4871C0EB; Fri, 27 May 2005 16:53:32 +0200 (CEST) Date: Fri, 27 May 2005 16:53:32 +0200 From: Thomas Graf To: "David S. Miller" Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: [PATCH 5/7] [PKT_SCHED] Fix dsmark to apply changes consistent Message-ID: <20050527145332.GW15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527145002.GR15391@postel.suug.ch> X-archive-position: 1763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 5188 Lines: 185 Fixes dsmark to do all configuration sanity checks first and only apply the changes if all of them can be applied without any errors. Also fixes the weak sanity checks for DSMARK_VALUE and DSMASK_MASK. Signed-off-by: Thomas Graf --- commit 76061832cc84456bd970769c0dfcdfefc20d22fa tree ffa2efa3cf35b0a3c8c983060731be7b4d3330db parent c49bbdd22621352b9b96097ffdb9e5c14b4ed95e author Thomas Graf Fri, 27 May 2005 15:15:26 +0200 committer Thomas Graf Fri, 27 May 2005 15:15:26 +0200 net/sched/sch_dsmark.c | 129 ++++++++++++++++++++++++++++++------------------- 1 files changed, 81 insertions(+), 48 deletions(-) Index: net/sched/sch_dsmark.c =================================================================== --- 6204e59b7aa59cf79632003c621e521db1297b1b/net/sched/sch_dsmark.c (mode:100644) +++ ffa2efa3cf35b0a3c8c983060731be7b4d3330db/net/sched/sch_dsmark.c (mode:100644) @@ -62,6 +62,21 @@ int set_tc_index; }; +static inline int dsmark_valid_indices(u16 indices) +{ + while (indices != 1) { + if (indices & 1) + return 0; + indices >>= 1; + } + + return 1; +} + +static inline int dsmark_valid_index(struct dsmark_qdisc_data *p, u16 index) +{ + return (index <= p->indices && index > 0); +} /* ------------------------- Class/flow operations ------------------------- */ @@ -120,31 +135,39 @@ static int dsmark_change(struct Qdisc *sch, u32 classid, u32 parent, - struct rtattr **tca, unsigned long *arg) + struct rtattr **tca, unsigned long *arg) { struct dsmark_qdisc_data *p = PRIV(sch); struct rtattr *opt = tca[TCA_OPTIONS-1]; struct rtattr *tb[TCA_DSMARK_MAX]; + int err = -EINVAL; + u8 mask = 0; DPRINTK("dsmark_change(sch %p,[qdisc %p],classid %x,parent %x)," - "arg 0x%lx\n",sch,p,classid,parent,*arg); - if (*arg > p->indices) - return -ENOENT; - if (!opt || rtattr_parse_nested(tb, TCA_DSMARK_MAX, opt)) - return -EINVAL; - if (tb[TCA_DSMARK_MASK-1]) { - if (!RTA_PAYLOAD(tb[TCA_DSMARK_MASK-1])) - return -EINVAL; - p->mask[*arg-1] = *(__u8 *) RTA_DATA(tb[TCA_DSMARK_MASK-1]); - } - if (tb[TCA_DSMARK_VALUE-1]) { - if (!RTA_PAYLOAD(tb[TCA_DSMARK_VALUE-1])) - return -EINVAL; - p->value[*arg-1] = *(__u8 *) RTA_DATA(tb[TCA_DSMARK_VALUE-1]); + "arg 0x%lx\n", sch, p, classid, parent, *arg); + + if (!dsmark_valid_index(p, *arg)) { + err = -ENOENT; + goto rtattr_failure; } - return 0; -} + if (!opt || rtattr_parse_nested(tb, TCA_DSMARK_MAX, opt)) + goto rtattr_failure; + + if (tb[TCA_DSMARK_MASK-1]) + mask = RTA_GET_U8(tb[TCA_DSMARK_MASK-1]); + + if (tb[TCA_DSMARK_VALUE-1]) + p->value[*arg-1] = RTA_GET_U8(tb[TCA_DSMARK_VALUE-1]); + + if (tb[TCA_DSMARK_MASK-1]) + p->mask[*arg-1] = mask; + + err = 0; + +rtattr_failure: + return err; +} static int dsmark_delete(struct Qdisc *sch,unsigned long arg) { @@ -328,43 +351,53 @@ } -static int dsmark_init(struct Qdisc *sch,struct rtattr *opt) +static int dsmark_init(struct Qdisc *sch, struct rtattr *opt) { struct dsmark_qdisc_data *p = PRIV(sch); struct rtattr *tb[TCA_DSMARK_MAX]; - __u16 tmp; + int err = -EINVAL; + u32 default_index = NO_DEFAULT_INDEX; + u16 indices; + u8 *mask; - DPRINTK("dsmark_init(sch %p,[qdisc %p],opt %p)\n",sch,p,opt); - if (!opt || - rtattr_parse(tb,TCA_DSMARK_MAX,RTA_DATA(opt),RTA_PAYLOAD(opt)) < 0 || - !tb[TCA_DSMARK_INDICES-1] || - RTA_PAYLOAD(tb[TCA_DSMARK_INDICES-1]) < sizeof(__u16)) - return -EINVAL; - p->indices = *(__u16 *) RTA_DATA(tb[TCA_DSMARK_INDICES-1]); - if (!p->indices) - return -EINVAL; - for (tmp = p->indices; tmp != 1; tmp >>= 1) { - if (tmp & 1) - return -EINVAL; - } - p->default_index = NO_DEFAULT_INDEX; - if (tb[TCA_DSMARK_DEFAULT_INDEX-1]) { - if (RTA_PAYLOAD(tb[TCA_DSMARK_DEFAULT_INDEX-1]) < sizeof(__u16)) - return -EINVAL; - p->default_index = - *(__u16 *) RTA_DATA(tb[TCA_DSMARK_DEFAULT_INDEX-1]); + DPRINTK("dsmark_init(sch %p,[qdisc %p],opt %p)\n", sch, p, opt); + + if (!opt || rtattr_parse_nested(tb, TCA_DSMARK_MAX, opt) < 0) + goto errout; + + indices = RTA_GET_U16(tb[TCA_DSMARK_INDICES-1]); + if (!indices || !dsmark_valid_indices(indices)) + goto errout; + + if (tb[TCA_DSMARK_DEFAULT_INDEX-1]) + default_index = RTA_GET_U16(tb[TCA_DSMARK_DEFAULT_INDEX-1]); + + mask = kmalloc(indices * 2, GFP_KERNEL); + if (mask == NULL) { + err = -ENOMEM; + goto errout; } - p->set_tc_index = !!tb[TCA_DSMARK_SET_TC_INDEX-1]; - p->mask = kmalloc(p->indices*2,GFP_KERNEL); - if (!p->mask) - return -ENOMEM; - p->value = p->mask+p->indices; - memset(p->mask,0xff,p->indices); - memset(p->value,0,p->indices); - if (!(p->q = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops))) + + p->mask = mask; + memset(p->mask, 0xff, indices); + + p->value = p->mask + indices; + memset(p->value, 0, indices); + + p->indices = indices; + p->default_index = default_index; + p->set_tc_index = RTA_GET_FLAG(tb[TCA_DSMARK_SET_TC_INDEX-1]); + + p->q = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (p->q == NULL) p->q = &noop_qdisc; - DPRINTK("dsmark_init: qdisc %p\n",&p->q); - return 0; + + DPRINTK("dsmark_init: qdisc %p\n", p->q); + + err = 0; +errout: +rtattr_failure: + return err; } From tgraf@suug.ch Fri May 27 07:54:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:54:48 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4REsgXq007535 for ; Fri, 27 May 2005 07:54:42 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 84EEC1C0ED; Fri, 27 May 2005 16:54:15 +0200 (CEST) Date: Fri, 27 May 2005 16:54:15 +0200 From: Thomas Graf To: "David S. Miller" Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: [PATCH 6/7] [PKT_SCHED] Make dsmark use the new dumping macros Message-ID: <20050527145415.GX15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527145002.GR15391@postel.suug.ch> X-archive-position: 1764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2920 Lines: 92 Signed-off-by: Thomas Graf --- commit 36b5fe1b0094ab6d6ba2589076bec1975d5769ed tree ff95a30a27c52aef9561f2ed04e9950d0afcae6a parent 76061832cc84456bd970769c0dfcdfefc20d22fa author Thomas Graf Fri, 27 May 2005 15:22:44 +0200 committer Thomas Graf Fri, 27 May 2005 15:22:44 +0200 net/sched/sch_dsmark.c | 52 ++++++++++++++++++++++--------------------------- 1 files changed, 24 insertions(+), 28 deletions(-) Index: net/sched/sch_dsmark.c =================================================================== --- ffa2efa3cf35b0a3c8c983060731be7b4d3330db/net/sched/sch_dsmark.c (mode:100644) +++ ff95a30a27c52aef9561f2ed04e9950d0afcae6a/net/sched/sch_dsmark.c (mode:100644) @@ -428,50 +428,46 @@ static int dsmark_dump_class(struct Qdisc *sch, unsigned long cl, - struct sk_buff *skb, struct tcmsg *tcm) + struct sk_buff *skb, struct tcmsg *tcm) { struct dsmark_qdisc_data *p = PRIV(sch); - unsigned char *b = skb->tail; - struct rtattr *rta; + struct rtattr *opts = NULL; - DPRINTK("dsmark_dump_class(sch %p,[qdisc %p],class %ld\n",sch,p,cl); - if (!cl || cl > p->indices) + DPRINTK("dsmark_dump_class(sch %p,[qdisc %p],class %ld\n", sch, p, cl); + + if (!dsmark_valid_index(p, cl)) return -EINVAL; - tcm->tcm_handle = TC_H_MAKE(TC_H_MAJ(sch->handle),cl-1); - rta = (struct rtattr *) b; - RTA_PUT(skb,TCA_OPTIONS,0,NULL); - RTA_PUT(skb,TCA_DSMARK_MASK,1,&p->mask[cl-1]); - RTA_PUT(skb,TCA_DSMARK_VALUE,1,&p->value[cl-1]); - rta->rta_len = skb->tail-b; - return skb->len; + + tcm->tcm_handle = TC_H_MAKE(TC_H_MAJ(sch->handle), cl-1); + + opts = RTA_NEST(skb, TCA_OPTIONS); + RTA_PUT_U8(skb,TCA_DSMARK_MASK, p->mask[cl-1]); + RTA_PUT_U8(skb,TCA_DSMARK_VALUE, p->value[cl-1]); + + return RTA_NEST_END(skb, opts); rtattr_failure: - skb_trim(skb,b-skb->data); - return -1; + return RTA_NEST_CANCEL(skb, opts); } static int dsmark_dump(struct Qdisc *sch, struct sk_buff *skb) { struct dsmark_qdisc_data *p = PRIV(sch); - unsigned char *b = skb->tail; - struct rtattr *rta; + struct rtattr *opts = NULL; + + opts = RTA_NEST(skb, TCA_OPTIONS); + RTA_PUT_U16(skb, TCA_DSMARK_INDICES, p->indices); - rta = (struct rtattr *) b; - RTA_PUT(skb,TCA_OPTIONS,0,NULL); - RTA_PUT(skb,TCA_DSMARK_INDICES,sizeof(__u16),&p->indices); - if (p->default_index != NO_DEFAULT_INDEX) { - __u16 tmp = p->default_index; + if (p->default_index != NO_DEFAULT_INDEX) + RTA_PUT_U16(skb, TCA_DSMARK_DEFAULT_INDEX, p->default_index); - RTA_PUT(skb,TCA_DSMARK_DEFAULT_INDEX, sizeof(__u16), &tmp); - } if (p->set_tc_index) - RTA_PUT(skb, TCA_DSMARK_SET_TC_INDEX, 0, NULL); - rta->rta_len = skb->tail-b; - return skb->len; + RTA_PUT_FLAG(skb, TCA_DSMARK_SET_TC_INDEX); + + return RTA_NEST_END(skb, opts); rtattr_failure: - skb_trim(skb,b-skb->data); - return -1; + return RTA_NEST_CANCEL(skb, opts); } static struct Qdisc_class_ops dsmark_class_ops = { From tgraf@suug.ch Fri May 27 07:56:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:56:45 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4REudXq009012 for ; Fri, 27 May 2005 07:56:39 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id D7BAE1C0EB; Fri, 27 May 2005 16:56:11 +0200 (CEST) Date: Fri, 27 May 2005 16:56:11 +0200 From: Thomas Graf To: "David S. Miller" Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: [PATCH 7/7] [PKT_SCHED] Logic simplifications and codingstyle/whitespace cleanups Message-ID: <20050527145611.GY15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527145002.GR15391@postel.suug.ch> X-archive-position: 1765 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 9218 Lines: 387 Signed-off-by: Thomas Graf --- commit fde09d4989b6c7b5183ffb3ec2076ff53dd6fa78 tree b032d0d440d93aac252e656bd41df32ff5461e3a parent 36b5fe1b0094ab6d6ba2589076bec1975d5769ed author Thomas Graf Fri, 27 May 2005 16:25:41 +0200 committer Thomas Graf Fri, 27 May 2005 16:25:41 +0200 net/sched/sch_dsmark.c | 174 ++++++++++++++++++++++++------------------------- 1 files changed, 88 insertions(+), 86 deletions(-) Index: net/sched/sch_dsmark.c =================================================================== --- ff95a30a27c52aef9561f2ed04e9950d0afcae6a/net/sched/sch_dsmark.c (mode:100644) +++ b032d0d440d93aac252e656bd41df32ff5461e3a/net/sched/sch_dsmark.c (mode:100644) @@ -31,7 +31,7 @@ #endif -#define PRIV(sch) qdisc_priv(sch) +#define PRIV(sch) ((struct dsmark_qdisc_data *) qdisc_priv(sch)) /* @@ -55,10 +55,10 @@ struct dsmark_qdisc_data { struct Qdisc *q; struct tcf_proto *filter_list; - __u8 *mask; /* "owns" the array */ - __u8 *value; - __u16 indices; - __u32 default_index; /* index range is 0...0xffff */ + u8 *mask; /* "owns" the array */ + u8 *value; + u16 indices; + u32 default_index; /* index range is 0...0xffff */ int set_tc_index; }; @@ -80,14 +80,13 @@ /* ------------------------- Class/flow operations ------------------------- */ - -static int dsmark_graft(struct Qdisc *sch,unsigned long arg, - struct Qdisc *new,struct Qdisc **old) +static int dsmark_graft(struct Qdisc *sch, unsigned long arg, + struct Qdisc *new, struct Qdisc **old) { struct dsmark_qdisc_data *p = PRIV(sch); - DPRINTK("dsmark_graft(sch %p,[qdisc %p],new %p,old %p)\n",sch,p,new, - old); + DPRINTK("dsmark_graft(sch %p,[qdisc %p],new %p,old %p)\n", + sch, p, new, old); if (new == NULL) { new = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); @@ -96,44 +95,37 @@ } sch_tree_lock(sch); - *old = xchg(&p->q,new); - if (*old) - qdisc_reset(*old); + *old = xchg(&p->q, new); + qdisc_reset(*old); sch->q.qlen = 0; - sch_tree_unlock(sch); /* @@@ move up ? */ + sch_tree_unlock(sch); + return 0; } - static struct Qdisc *dsmark_leaf(struct Qdisc *sch, unsigned long arg) { - struct dsmark_qdisc_data *p = PRIV(sch); - - return p->q; + return PRIV(sch)->q; } - -static unsigned long dsmark_get(struct Qdisc *sch,u32 classid) +static unsigned long dsmark_get(struct Qdisc *sch, u32 classid) { - struct dsmark_qdisc_data *p __attribute__((unused)) = PRIV(sch); + DPRINTK("dsmark_get(sch %p,[qdisc %p],classid %x)\n", + sch, PRIV(sch), classid); - DPRINTK("dsmark_get(sch %p,[qdisc %p],classid %x)\n",sch,p,classid); - return TC_H_MIN(classid)+1; + return TC_H_MIN(classid) + 1; } - static unsigned long dsmark_bind_filter(struct Qdisc *sch, - unsigned long parent, u32 classid) + unsigned long parent, u32 classid) { - return dsmark_get(sch,classid); + return dsmark_get(sch, classid); } - static void dsmark_put(struct Qdisc *sch, unsigned long cl) { } - static int dsmark_change(struct Qdisc *sch, u32 classid, u32 parent, struct rtattr **tca, unsigned long *arg) { @@ -169,26 +161,29 @@ return err; } -static int dsmark_delete(struct Qdisc *sch,unsigned long arg) +static int dsmark_delete(struct Qdisc *sch, unsigned long arg) { struct dsmark_qdisc_data *p = PRIV(sch); - if (!arg || arg > p->indices) + if (!dsmark_valid_index(p, arg)) return -EINVAL; + p->mask[arg-1] = 0xff; p->value[arg-1] = 0; + return 0; } - static void dsmark_walk(struct Qdisc *sch,struct qdisc_walker *walker) { struct dsmark_qdisc_data *p = PRIV(sch); int i; - DPRINTK("dsmark_walk(sch %p,[qdisc %p],walker %p)\n",sch,p,walker); + DPRINTK("dsmark_walk(sch %p,[qdisc %p],walker %p)\n", sch, p, walker); + if (walker->stop) return; + for (i = 0; i < p->indices; i++) { if (p->mask[i] == 0xff && !p->value[i]) goto ignore; @@ -203,26 +198,20 @@ } } - static struct tcf_proto **dsmark_find_tcf(struct Qdisc *sch,unsigned long cl) { - struct dsmark_qdisc_data *p = PRIV(sch); - - return &p->filter_list; + return &PRIV(sch)->filter_list; } - /* --------------------------- Qdisc operations ---------------------------- */ - static int dsmark_enqueue(struct sk_buff *skb,struct Qdisc *sch) { struct dsmark_qdisc_data *p = PRIV(sch); - struct tcf_result res; - int result; - int ret = NET_XMIT_POLICED; + int err; + + D2PRINTK("dsmark_enqueue(skb %p,sch %p,[qdisc %p])\n", skb, sch, p); - D2PRINTK("dsmark_enqueue(skb %p,sch %p,[qdisc %p])\n",skb,sch,p); if (p->set_tc_index) { /* FIXME: Safe with non-linear skbs? --RR */ switch (skb->protocol) { @@ -239,17 +228,21 @@ break; }; } - result = TC_POLICE_OK; /* be nice to gcc */ - if (TC_H_MAJ(skb->priority) == sch->handle) { + + if (TC_H_MAJ(skb->priority) == sch->handle) skb->tc_index = TC_H_MIN(skb->priority); - } else { - result = tc_classify(skb,p->filter_list,&res); - D2PRINTK("result %d class 0x%04x\n",result,res.classid); + else { + struct tcf_result res; + int result = tc_classify(skb, p->filter_list, &res); + + D2PRINTK("result %d class 0x%04x\n", result, res.classid); + switch (result) { #ifdef CONFIG_NET_CLS_POLICE case TC_POLICE_SHOT: kfree_skb(skb); - break; + sch->qstats.drops++; + return NET_XMIT_POLICED; #if 0 case TC_POLICE_RECLASSIFY: /* FIXME: what to do here ??? */ @@ -266,43 +259,45 @@ break; }; } - if ( -#ifdef CONFIG_NET_CLS_POLICE - result == TC_POLICE_SHOT || -#endif - ((ret = p->q->enqueue(skb,p->q)) != 0)) { + err = p->q->enqueue(skb,p->q); + if (err != NET_XMIT_SUCCESS) { sch->qstats.drops++; - return ret; + return err; } + sch->bstats.bytes += skb->len; sch->bstats.packets++; sch->q.qlen++; - return ret; -} + return NET_XMIT_SUCCESS; +} static struct sk_buff *dsmark_dequeue(struct Qdisc *sch) { struct dsmark_qdisc_data *p = PRIV(sch); struct sk_buff *skb; - int index; + u32 index; + + D2PRINTK("dsmark_dequeue(sch %p,[qdisc %p])\n", sch, p); - D2PRINTK("dsmark_dequeue(sch %p,[qdisc %p])\n",sch,p); skb = p->q->ops->dequeue(p->q); - if (!skb) + if (skb == NULL) return NULL; + sch->q.qlen--; - index = skb->tc_index & (p->indices-1); - D2PRINTK("index %d->%d\n",skb->tc_index,index); + + index = skb->tc_index & (p->indices - 1); + D2PRINTK("index %d->%d\n", skb->tc_index, index); + switch (skb->protocol) { case __constant_htons(ETH_P_IP): - ipv4_change_dsfield(skb->nh.iph, - p->mask[index],p->value[index]); + ipv4_change_dsfield(skb->nh.iph, p->mask[index], + p->value[index]); break; case __constant_htons(ETH_P_IPV6): - ipv6_change_dsfield(skb->nh.ipv6h, - p->mask[index],p->value[index]); + ipv6_change_dsfield(skb->nh.ipv6h, p->mask[index], + p->value[index]); break; default: /* @@ -316,41 +311,46 @@ htons(skb->protocol)); break; }; + return skb; } - static int dsmark_requeue(struct sk_buff *skb,struct Qdisc *sch) { - int ret; struct dsmark_qdisc_data *p = PRIV(sch); + int err; - D2PRINTK("dsmark_requeue(skb %p,sch %p,[qdisc %p])\n",skb,sch,p); - if ((ret = p->q->ops->requeue(skb, p->q)) == 0) { - sch->q.qlen++; - sch->qstats.requeues++; - return 0; + D2PRINTK("dsmark_requeue(skb %p,sch %p,[qdisc %p])\n", skb, sch, p); + + err = p->q->ops->requeue(skb, p->q); + if (err != NET_XMIT_SUCCESS) { + sch->qstats.drops++; + return err; } - sch->qstats.drops++; - return ret; -} + sch->q.qlen++; + sch->qstats.requeues++; + + return NET_XMIT_SUCCESS; +} static unsigned int dsmark_drop(struct Qdisc *sch) { struct dsmark_qdisc_data *p = PRIV(sch); unsigned int len; - DPRINTK("dsmark_reset(sch %p,[qdisc %p])\n",sch,p); - if (!p->q->ops->drop) - return 0; - if (!(len = p->q->ops->drop(p->q))) + DPRINTK("dsmark_reset(sch %p,[qdisc %p])\n", sch, p); + + if (p->q->ops->drop == NULL) return 0; - sch->q.qlen--; + + len = p->q->ops->drop(p->q); + if (len) + sch->q.qlen--; + return len; } - static int dsmark_init(struct Qdisc *sch, struct rtattr *opt) { struct dsmark_qdisc_data *p = PRIV(sch); @@ -400,33 +400,32 @@ return err; } - static void dsmark_reset(struct Qdisc *sch) { struct dsmark_qdisc_data *p = PRIV(sch); - DPRINTK("dsmark_reset(sch %p,[qdisc %p])\n",sch,p); + DPRINTK("dsmark_reset(sch %p,[qdisc %p])\n", sch, p); qdisc_reset(p->q); sch->q.qlen = 0; } - static void dsmark_destroy(struct Qdisc *sch) { struct dsmark_qdisc_data *p = PRIV(sch); struct tcf_proto *tp; - DPRINTK("dsmark_destroy(sch %p,[qdisc %p])\n",sch,p); + DPRINTK("dsmark_destroy(sch %p,[qdisc %p])\n", sch, p); + while (p->filter_list) { tp = p->filter_list; p->filter_list = tp->next; tcf_destroy(tp); } + qdisc_destroy(p->q); kfree(p->mask); } - static int dsmark_dump_class(struct Qdisc *sch, unsigned long cl, struct sk_buff *skb, struct tcmsg *tcm) { @@ -505,10 +504,13 @@ { return register_qdisc(&dsmark_qdisc_ops); } + static void __exit dsmark_module_exit(void) { unregister_qdisc(&dsmark_qdisc_ops); } + module_init(dsmark_module_init) module_exit(dsmark_module_exit) + MODULE_LICENSE("GPL"); From hadi@cyberus.ca Fri May 27 07:57:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 07:58:00 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4REvtXq009564 for ; Fri, 27 May 2005 07:57:56 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DbgGn-00065P-Tx for netdev@oss.sgi.com; Fri, 27 May 2005 08:57:05 -0600 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbgGn-0000WK-Ko; Fri, 27 May 2005 10:57:05 -0400 Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050527141023.GP15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> <1117192464.6688.3.camel@localhost.localdomain> <20050527121503.GN15391@postel.suug.ch> <1117201853.6383.29.camel@localhost.localdomain> <20050527141023.GP15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 10:57:02 -0400 Message-Id: <1117205822.6383.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1766 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3519 Lines: 80 On Fri, 2005-27-05 at 16:10 +0200, Thomas Graf wrote: > * jamal <1117201853.6383.29.camel@localhost.localdomain> 2005-05-27 09:50 > > In other words, if i was to draw a model diagram it would show: > > --> netdevice > > ----> v4 addresses > > ----> v4 netdevice configuration > > ----> v6 addresses > > ----> v6 netdevice configuration > > > > i.e the best way to do it imo, especially since you are doing this from > > scratch, is to maintain that model. Your patch breaks away from this. > > I think this model is only valid for neighbour table parameter set > and not for neighbour tables themselves. > Yes, that's true. In other words, neighbor tables details are out of scope of that model and are more appropriate to the v4/6 neighbor "box". Anything else that is netdevice related or connected as in the above model (as opposed to say the ARP "box" related detail) is better to leave or add it to be part of devconfig if it doesnt exist. To be precise there are things in your patch that are fine to leave there; but the most it seems to me belong to the devconfig netlink path (which doesnt exist today). > > The only thing that is not devconfig queriable or settable at the moment > > is the stats. That i can certainly see as being part of the standard > > neighbor details for example. Infact this would apply elsewhere as well, > > for example in the FIB where some stats are being displayed via /proc at > > the moment. > > This is not correct, struct ndt_config (read-only configuration, sort > of like statistics), gc thresholds, gc interval, and the default parameter > set are also not devconfig queriable. From a user point of view the > most commonly changed values will be the gc thresholds, gc interval > and parameters in the default set and if you forget about the device > specific parameters for a second it would be pretty obvious to not put > them into devconfig. So my point is that I don't want to put the most > obvious and common use into something where it doesn't really fit. The thresholds etc are there - just not netlink accessible. Example, the default values for V4 are settable or queriable via: /proc/sys/net/ipv4/neigh/default/gc_thresh3 /proc/sys/net/ipv4/neigh/default/gc_thresh2 /proc/sys/net/ipv4/neigh/default/gc_thresh1 /proc/sys/net/ipv4/neigh/default/gc_interval > I do agree that the device specific parameters fit into a devconfig > or whathever we'll call it but not the whole neighbour table > configuration bits. > Agreed that some things are specific to the "ARP" or "NDISC" block but not all that you have belongs to those boxes. > > We actually did discuss this a while back and i had an incomplete patch > > for doing it the way i suggest above which i unfortunately cant seem to > > locate at the moment. > > Can't remember to have seen such as mail or patch, do you remember > the thread you posted this? I posted the patch 3 times and I just > read through the archives again and can't find any such commments. I never posted the patch unfortunately but mentioned it in the discussions. What counts is we are having this discussion now;-> I apologize i didnt comment on the patch earlier - sometimes when i am away from the list for sometime i skip threads which may require me to spend time looking at them to make any useful comments. This maybe the reason i didnt respond. To catchup i normally read emails addressed to me first then go over the list in a LIFO mode and stop once i get engaged in a discussion. cheers, jamal From hadi@cyberus.ca Fri May 27 08:02:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 08:02:24 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RF2LXq010368 for ; Fri, 27 May 2005 08:02:22 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DbgL9-0008DU-7v for netdev@oss.sgi.com; Fri, 27 May 2005 11:01:35 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbgL8-0001Jq-NR; Fri, 27 May 2005 11:01:34 -0400 Subject: Re: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050527141320.GQ15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 11:01:31 -0400 Message-Id: <1117206091.6383.73.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1767 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 803 Lines: 27 On Fri, 2005-27-05 at 16:13 +0200, Thomas Graf wrote: > That is what the patch does but the diff looks a bit irritating. > 1) Introduce NLMSG_NEW to take flags > 2) Make NLMSG_PUT call NLMSG_NEW with flags==0 > 3) Change __nlmsg_put to take flags argument > Yikes - sorry i glossed over the patch. > > The first change would be definetely on top of the current patch i sent > > which is well deserved. > > Lets have Dave swallow my patch then either you or i could make those > > changes. Sounds reasonable? > > Sure. Dave please apply the patch i posted into your tree and then we can follow with this other stuff. Actually Thomas, you can probably apply my patch on your side and then the other changes to use _NEW() on top of it. If you dont have time i could do it tommorow. cheers, jamal From tgraf@suug.ch Fri May 27 08:16:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 08:16:41 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RFGaXq011274 for ; Fri, 27 May 2005 08:16:36 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 0AAD01C0EB; Fri, 27 May 2005 17:16:08 +0200 (CEST) Date: Fri, 27 May 2005 17:16:08 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050527151608.GZ15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> <1117192464.6688.3.camel@localhost.localdomain> <20050527121503.GN15391@postel.suug.ch> <1117201853.6383.29.camel@localhost.localdomain> <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117205822.6383.68.camel@localhost.localdomain> X-archive-position: 1768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2445 Lines: 60 * jamal <1117205822.6383.68.camel@localhost.localdomain> 2005-05-27 10:57 > The thresholds etc are there - just not netlink accessible. Example, the > default values for V4 are settable or queriable via: > > /proc/sys/net/ipv4/neigh/default/gc_thresh3 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 > /proc/sys/net/ipv4/neigh/default/gc_interval Sorry but this is just one big hack: a) they do not belong there, the first implication a user does when he sees default/, dev1/, dev2/, devN is that default/ covers the same set of parameters as devX/. Therefore he expects all parameters in default/ to be also in devX/. b) struct neigh_parms parms; /* HACK. gc_* shoul follow parms without a gap! */ int gc_interval; int gc_thresh1; int gc_thresh2; int gc_thresh3; ... if (dev) { dev_name_source = dev->name; t->neigh_dev[0].ctl_name = dev->ifindex; t->neigh_vars[12].procname = NULL; <- gc_interval t->neigh_vars[13].procname = NULL; <- gc_thresh1 t->neigh_vars[14].procname = NULL; <- gc_thresh2 t->neigh_vars[15].procname = NULL; <- gc_thresh3 } else { dev_name_source = t->neigh_dev[0].procname; t->neigh_vars[12].data = (int *)(p + 1); t->neigh_vars[13].data = (int *)(p + 1) + 1; t->neigh_vars[14].data = (int *)(p + 1) + 2; t->neigh_vars[15].data = (int *)(p + 1) + 3; } I will not push along these hacks into my code ;-> Some more notes on the devconfig idea: I'm not sure if you are still implying devconfig as devinet but if so: although we only have neighbour tables on devinets so far there might be neighbour table on other interfaces for whatever reason. A protocol might allocate a neighbour parameter set on any netdevice which makes me think that the netlink neighbour code should be open for this as well. It depends on how we do the devconfig thing, so what I suggest it so leave this as-is for the moment and make a decision once we know more about how the devconfig thing will look like. Reasonable? > I apologize i didnt comment on the patch earlier - sometimes when i am > away from the list for sometime i skip threads which may require me to > spend time looking at them to make any useful comments. This maybe the > reason i didnt respond. To catchup i normally read emails addressed to > me first then go over the list in a LIFO mode and stop once i get > engaged in a discussion. I should have CCed you, my fault. From tgraf@suug.ch Fri May 27 08:19:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 08:19:43 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RFJeXq015366 for ; Fri, 27 May 2005 08:19:40 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 249331C0EB; Fri, 27 May 2005 17:19:13 +0200 (CEST) Date: Fri, 27 May 2005 17:19:13 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting Message-ID: <20050527151913.GA15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117206091.6383.73.camel@localhost.localdomain> X-archive-position: 1769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 668 Lines: 15 * jamal <1117206091.6383.73.camel@localhost.localdomain> 2005-05-27 11:01 > Dave please apply the patch i posted into your tree and then we can > follow with this other stuff. > Actually Thomas, you can probably apply my patch on your side and then > the other changes to use _NEW() on top of it. If you dont have time i > could do it tommorow. Sure, I can come up with a patchset today which will include: o the new NLMSG_NEW macro o your patch adopted to use the new NLMSG_NEW macro o small patch to rename NLMSG_PUT_ANSWER usages into NLMSG_NEW_ANSWER o a small fallout from the new neighbour table code which gcc didn't warn me about when it should. OK? From shemminger@osdl.org Fri May 27 08:51:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 08:51:50 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RFpkXq016602 for ; Fri, 27 May 2005 08:51:46 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4RFotjA015844 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 08:50:55 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4RFotSG026695; Fri, 27 May 2005 08:50:55 -0700 Date: Fri, 27 May 2005 08:50:55 -0700 From: Stephen Hemminger To: Mitch Williams Cc: netdev@oss.sgi.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: Re: RFC: NAPI packet weighting patch Message-ID: <20050527085055.79da3d75@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4663 Lines: 123 On Thu, 26 May 2005 14:36:22 -0700 Mitch Williams wrote: > The following patch (which applies to 2.6.12rc4) adds a new sysctl > parameter called 'netdev_packet_weight'. This parameter controls how many > backlog work units each RX packet is worth. > > With the parameter set to 0 (the default), NAPI polling works exactly as > it does today: each packet is worth one backlog work unit, and the > maximum number of received packets that will be processed in any given > softirq is controlled by the 'netdev_max_backlog' parameter. > > By setting the netdev_packet_weight to a nonzero value, we make each > packet worth more than one backlog work unit. Since it's a shift value, a > setting of 1 makes each packet worth 2 work units, a setting of 2 makes > each packet worth 4 units, etc. Under normal circumstances you would > never use a value higher than 3, though 4 might work for Gigabit and 10 > Gigabit networks. > > By increasing the packet weight, we accomplish two things: first, we > cause the individual NAPI RX loops in each driver to process fewer > packets. This means that they will free up RX resources to the hardware > more often, which reduces the possibility of dropped packets. Second, it > shortens the total time spent in the NAPI softirq, which can free the CPU > to handle other tasks more often, thus reducing overall latency. Rather than weighting each packet differently, why not just reduce the upper bound on number of packets. There are several patches is in my 2.6.12-rc5-tcp3 that make this easier: ---- http://developer.osdl.org/shemminger/patches/2.6.12-rc5-tcp3/patches/bigger-backlog.patch Separate out the two uses of netdev_max_backlog. One controls the upper bound on packets processed per softirq, the new name for this is netdev_max_weight; the other controls the limit on packets queued via netif_rx Signed-off-by: Stephen Hemminger Index: linux-2.6.12-rc4-tcp2/net/core/sysctl_net_core.c =================================================================== --- linux-2.6.12-rc4-tcp2.orig/net/core/sysctl_net_core.c +++ linux-2.6.12-rc4-tcp2/net/core/sysctl_net_core.c @@ -13,6 +13,7 @@ #ifdef CONFIG_SYSCTL extern int netdev_max_backlog; +extern int netdev_max_weight; extern int weight_p; extern int net_msg_cost; extern int net_msg_burst; @@ -137,6 +138,14 @@ ctl_table core_table[] = { .mode = 0644, .proc_handler = &proc_dointvec }, + { + .ctl_name = NET_CORE_MAX_WEIGHT, + .procname = "netdev_max_weight", + .data = &netdev_max_weight, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec + }, { .ctl_name = 0 } }; Index: linux-2.6.12-rc4-tcp2/net/core/dev.c =================================================================== --- linux-2.6.12-rc4-tcp2.orig/net/core/dev.c +++ linux-2.6.12-rc4-tcp2/net/core/dev.c @@ -1334,7 +1334,8 @@ out: Receiver routines =======================================================================*/ -int netdev_max_backlog = 300; +int netdev_max_backlog = 10000; +int netdev_max_weight = 500; int weight_p = 64; /* old backlog weight */ DEFINE_PER_CPU(struct netif_rx_stats, netdev_rx_stat) = { 0, }; @@ -1682,8 +1683,7 @@ static void net_rx_action(struct softirq { struct softnet_data *queue = &__get_cpu_var(softnet_data); unsigned long start_time = jiffies; - int budget = netdev_max_backlog; - + int budget = netdev_max_weight; local_irq_disable(); Index: linux-2.6.12-rc4-tcp2/include/linux/sysctl.h =================================================================== --- linux-2.6.12-rc4-tcp2.orig/include/linux/sysctl.h +++ linux-2.6.12-rc4-tcp2/include/linux/sysctl.h @@ -242,6 +242,7 @@ enum NET_CORE_MOD_CONG=16, NET_CORE_DEV_WEIGHT=17, NET_CORE_SOMAXCONN=18, + NET_CORE_MAX_WEIGHT=19, }; /* /proc/sys/net/ethernet */ ---- http://developer.osdl.org/shemminger/patches/2.6.12-rc5-tcp3/patches/fix-weightp.patch Changing the dev_weight sysctl parameter has no effect because the weight of the backlog devices is set during initialization and never changed. Fix this by propogating changes. Signed-off-by: Stephen Hemminger Index: linux-2.6.12-rc4-tcp2/net/core/dev.c =================================================================== --- linux-2.6.12-rc4-tcp2.orig/net/core/dev.c +++ linux-2.6.12-rc4-tcp2/net/core/dev.c @@ -1636,6 +1636,7 @@ static int process_backlog(struct net_de struct softnet_data *queue = &__get_cpu_var(softnet_data); unsigned long start_time = jiffies; + backlog_dev->weight = weight_p; for (;;) { struct sk_buff *skb; struct net_device *dev; From shemminger@osdl.org Fri May 27 08:53:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 08:53:21 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RFrHXq016823 for ; Fri, 27 May 2005 08:53:17 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4RFqPjA015959 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 08:52:25 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4RFqPEr026815; Fri, 27 May 2005 08:52:25 -0700 Date: Fri, 27 May 2005 08:52:25 -0700 From: Stephen Hemminger To: Michael Renzmann Cc: netdev@oss.sgi.com Subject: Re: Network driver test suite (part 2) Message-ID: <20050527085225.5160c96f@dxpl.pdx.osdl.net> In-Reply-To: <4296BACF.7030202@otaku42.de> References: <4296BACF.7030202@otaku42.de> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 778 Lines: 17 On Fri, 27 May 2005 08:14:39 +0200 Michael Renzmann wrote: > Hi all. > > I vaguely remembered there was a discussion about a test suite which > allows to check whether a network driver works as intended. After > digging my local message archives I found the thread with the above > title, but it seems the thread ceased without any result (apart from a > wishlist for such a test suite). > > Hence my question: is there such a test suite available now? If not, did > anyone at least start working on such a project? What do you others > usually use to test-drive a network driver? I know of know such suite, an engineer at OSDL had started pulling pieces and ideas together, but unfortunately he was laid off. Let me know what you find out. From shemminger@osdl.org Fri May 27 08:54:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 08:54:17 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RFsEXq017061 for ; Fri, 27 May 2005 08:54:15 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4RFrMjA016007 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 08:53:22 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4RFrM0B026854; Fri, 27 May 2005 08:53:22 -0700 Date: Fri, 27 May 2005 08:53:22 -0700 From: Stephen Hemminger To: Alexey Dobriyan Cc: netdev@oss.sgi.com, Thomas Sailer Subject: Re: [PATCH] baycom_epp.c: Fix compilation with gcc-4.1.0-20050522 Message-ID: <20050527085322.35e312cf@dxpl.pdx.osdl.net> In-Reply-To: <200505271808.32032.adobriyan@gmail.com> References: <200505271808.32032.adobriyan@gmail.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 817 Lines: 22 On Fri, 27 May 2005 18:08:31 +0400 Alexey Dobriyan wrote: > drivers/net/hamradio/baycom_epp.c:432: error: jump into statement expression > ... > > Signed-off-by: Alexey Dobriyan > > --- linux-vanilla/drivers/net/hamradio/baycom_epp.c 2005-05-27 12:58:48.000000000 +0400 > +++ linux-gcc4/drivers/net/hamradio/baycom_epp.c 2005-05-27 17:54:14.000000000 +0400 > @@ -380,22 +380,18 @@ static inline void do_kiss_params(struct > */ > > #define ENCODEITERA(j) \ > -({ \ > if (!(notbitstream & (0x1f0 << j))) \ > goto stuff##j; \ > - encodeend##j: ; \ > -}) > + encodeend##j: ; Ick... Please just kill this kind of macro crap From hadi@cyberus.ca Fri May 27 08:58:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 08:58:40 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RFwbXq018828 for ; Fri, 27 May 2005 08:58:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DbhDb-0007Eu-3s for netdev@oss.sgi.com; Fri, 27 May 2005 11:57:51 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbhDa-0003eG-05; Fri, 27 May 2005 11:57:50 -0400 Subject: Re: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050527151913.GA15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 11:57:46 -0400 Message-Id: <1117209466.6383.106.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 512 Lines: 19 On Fri, 2005-27-05 at 17:19 +0200, Thomas Graf wrote: > Sure, I can come up with a patchset today which will include: > o the new NLMSG_NEW macro > o your patch adopted to use the new NLMSG_NEW macro > o small patch to rename NLMSG_PUT_ANSWER usages into NLMSG_NEW_ANSWER > o a small fallout from the new neighbour table code which gcc didn't > warn me about when it should. > > OK? Sounds reasonable. cheers, jamal PS:- Have to disappear for a few hours so they maybe latency in further responses. From shemminger@osdl.org Fri May 27 08:58:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 08:58:12 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RFw8Xq018614 for ; Fri, 27 May 2005 08:58:08 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4RFvEjA016422 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 08:57:15 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4RFvDfF027024; Fri, 27 May 2005 08:57:14 -0700 Date: Fri, 27 May 2005 08:57:13 -0700 From: Stephen Hemminger To: ravinandan.arakali@neterion.com Cc: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com, raghavendra.koushik@neterion.com, ravinandan.arakali@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature Message-ID: <20050527085713.373d702a@dxpl.pdx.osdl.net> In-Reply-To: <20050526232006.60E6365005@linux.site> References: <20050526232006.60E6365005@linux.site> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1123 Lines: 29 On Thu, 26 May 2005 16:20:06 -0700 (PDT) ravinandan.arakali@neterion.com wrote: > Hi, > Attached below is a kernel patch to provide UDP LSO(Large Send Offload) > feature. > This is the UDP counterpart of TSO. Basically, an oversized packet > (less than or equal to 65535) is handed to the NIC. The adapter then > produces IP fragments in conformance with RFC791(IPv4) or RFC2460(IPv6). > > Very much like TCP TSO, UDP LSO provides significant reduction in CPU > utilization, especially with 1500 MTU frames. For 10GbE traffic, > these extra CPU cycles translate into significant throughput increase > on most server platforms. > > Reasonable amount of testing has been done on the patch using Neterion's > 10G Xframe-II adapter to ensure code stability. > > Please review the patch. > > Also, below is a "how-to" on changes required in network drivers to use > the UDP LSO interface. The only downside is that it might encourage continued use of NFS over UDP. Perhaps we need a big fat warning in NFS that says: *** Your using NFS over UDP, your data integrity is no longer guaranteed; *** you have been warned. From hadi@cyberus.ca Fri May 27 08:57:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 08:57:47 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RFvgXq018569 for ; Fri, 27 May 2005 08:57:42 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DbhCj-0008If-7T for netdev@oss.sgi.com; Fri, 27 May 2005 11:56:57 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbhCg-0003Vn-Kf; Fri, 27 May 2005 11:56:54 -0400 Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050527151608.GZ15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> <1117192464.6688.3.camel@localhost.localdomain> <20050527121503.GN15391@postel.suug.ch> <1117201853.6383.29.camel@localhost.localdomain> <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> <20050527151608.GZ15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 11:56:51 -0400 Message-Id: <1117209411.6383.104.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3411 Lines: 98 On Fri, 2005-27-05 at 17:16 +0200, Thomas Graf wrote: > * jamal <1117205822.6383.68.camel@localhost.localdomain> 2005-05-27 10:57 > > The thresholds etc are there - just not netlink accessible. Example, the > > default values for V4 are settable or queriable via: > > > > /proc/sys/net/ipv4/neigh/default/gc_thresh3 > > /proc/sys/net/ipv4/neigh/default/gc_thresh2 > > /proc/sys/net/ipv4/neigh/default/gc_thresh1 > > /proc/sys/net/ipv4/neigh/default/gc_interval > > Sorry but this is just one big hack: It maybe in the user space representation, but not in the kernel abstraction which is what i was refering to. In other words look at struct in_device; > a) they do not belong there, the first implication a user does when > he sees default/, dev1/, dev2/, devN is that default/ covers > the same set of parameters as devX/. Therefore he expects all > parameters in default/ to be also in devX/. > The deafult can be overriden by devX. So they dont need to sync. But this is a separate topic > b) struct neigh_parms parms; > /* HACK. gc_* shoul follow parms without a gap! */ > int gc_interval; > int gc_thresh1; > int gc_thresh2; > int gc_thresh3; > > ... > > if (dev) { > dev_name_source = dev->name; > t->neigh_dev[0].ctl_name = dev->ifindex; > t->neigh_vars[12].procname = NULL; <- gc_interval > t->neigh_vars[13].procname = NULL; <- gc_thresh1 > t->neigh_vars[14].procname = NULL; <- gc_thresh2 > t->neigh_vars[15].procname = NULL; <- gc_thresh3 > } else { > dev_name_source = t->neigh_dev[0].procname; > t->neigh_vars[12].data = (int *)(p + 1); > t->neigh_vars[13].data = (int *)(p + 1) + 1; > t->neigh_vars[14].data = (int *)(p + 1) + 2; > t->neigh_vars[15].data = (int *)(p + 1) + 3; > } > > I will not push along these hacks into my code ;-> > I am afraid you are looking at this from the wrong angle (user space), Thomas ;-> The abstraction in the kernel is proper. To redraw that model again with the exact structure names: netdevice -> L2 config stuff config stuff more config stuff .. .. netdevice protocol config: -> v4 specific (struct in_device) ----> IPV4 addresses (ifa_list), ARP params(arp_parms),etc -> v6 specific (struct inet6_dev) ----> IPV6 addresses(addr_list), ndisc params (nd_parms), etc There are a few more items but i am leaving them out for brevity. I hope it makes more sense now. > Some more notes on the devconfig idea: I'm not sure if you are still > implying devconfig as devinet but if so: although we only have neighbour > tables on devinets so far there might be neighbour table on other > interfaces for whatever reason. in_devxxx types; sorry, I created the confusion by mentioning devconf in the sweep. > A protocol might allocate a neighbour > parameter set on any netdevice which makes me think that the netlink > neighbour code should be open for this as well. It depends on how we > do the devconfig thing, so what I suggest it so leave this as-is for > the moment and make a decision once we know more about how the devconfig > thing will look like. Reasonable? Take a look at what i said above and see if it makes sense. Note, I am not objecting to the patch like i said - I think some of those items are must put in that patch. Whatever simplifies life for you. I am not exactly a purist but at times i like getting it right from the beggining. cheers, jamal From shemminger@osdl.org Fri May 27 09:00:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 09:00:19 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RG0GXq019905 for ; Fri, 27 May 2005 09:00:16 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4RFxOjA016511 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 08:59:24 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4RFxOkx027111; Fri, 27 May 2005 08:59:24 -0700 Date: Fri, 27 May 2005 08:59:24 -0700 From: Stephen Hemminger To: "Atul Sabharwal" Cc: "David S. Miller" , netdev@oss.sgi.com, bridge@osdl.org Subject: Re: [Bridge] Re: [PATCH] (6/6) bridge: receive path optimization Message-ID: <20050527085924.720ba7ef@dxpl.pdx.osdl.net> In-Reply-To: <009201c56280$e9b7cd00$0202a8c0@ATULSPC> References: <20050526110425.27590eb8@dxpl.pdx.osdl.net> <20050526.144638.71091166.davem@davemloft.net> <20050526154857.3cb34d11@dxpl.pdx.osdl.net> <20050526.155401.18310361.davem@davemloft.net> <009201c56280$e9b7cd00$0202a8c0@ATULSPC> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 752 Lines: 21 On Thu, 26 May 2005 22:57:05 -0700 "Atul Sabharwal" wrote: > I have a question about using the 802.1d driver with a switch. I have a > managed switch > which connects to the Xscale MAC using a Reverse MII interface. > > It seems that the 802.1d bridge puts the interface into promiscuous mode and > needs multiple > ethernet devices to work with. Can it work with a single ethernet device > which is connected > to a BCM5338 ( broadcomm 8 port switch chip ). Why? what would you gain? > I understand that I would have to change the STP configuration component to > write to the > broadcomm chip. You would be better off writing a different driver, the amount of shared logic would be less than the per hardware logic. From ravinandan.arakali@neterion.com Fri May 27 09:33:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 09:33:28 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RGXOXq021682 for ; Fri, 27 May 2005 09:33:24 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j4RGW2OC012088; Fri, 27 May 2005 12:32:02 -0400 (EDT) Received: from rarakali ([10.16.16.57]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id j4RGVxVG004295; Fri, 27 May 2005 12:31:59 -0400 (EDT) From: "Ravinandan Arakali" To: "'David S. Miller'" Cc: , , , , , Subject: RE: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature Date: Fri, 27 May 2005 09:32:00 -0700 Message-ID: <000a01c562d9$9b661130$3910100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050526.164217.45745005.davem@davemloft.net> Importance: Normal X-Scanned-By: MIMEDefang 2.34 X-archive-position: 1777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev Content-Length: 1267 Lines: 41 Hi David, Thanks for the quick feedback. At that time when we considered using skb_shinfo(skb)->fraglist, it contained fragments of MTU size. So, for a 60k udp datagram and 1500 MTU we will have 60k/1500 = 45 fragments which is more than MAX_SKB_FRAGS(18). However we will relook at fraglist for the possibility of increasing frag size to >MTU. Thanks, Ravi -----Original Message----- From: David S. Miller [mailto:davem@davemloft.net] Sent: Thursday, May 26, 2005 4:42 PM To: ravinandan.arakali@neterion.com Cc: jgarzik@pobox.com; netdev@oss.sgi.com; raghavendra.koushik@neterion.com; leonid.grossman@neterion.com; ananda.raju@neterion.com; rapuru.sriram@neterion.com Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature sock_append_data() seems like a lot of wasted work. We already pass around the fragmented SKB as a list chained by skb_shinfo(skb)->fraglist, just pass this thing to the device and in this way you'll avoid all of that work sock_append_data() does entirely. Or is there a reason you did not implement it this way? This is one of the uses the skb_shinfo(skb)->fraglist was intended for. IN FACT, this fragmentation offload you are implementing here is what the feature bit NETIF_F_FRAGLIST was meant to indicate. From tgraf@suug.ch Fri May 27 09:35:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 09:35:47 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RGZiXq022074 for ; Fri, 27 May 2005 09:35:44 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id A77401C0EB; Fri, 27 May 2005 18:35:16 +0200 (CEST) Date: Fri, 27 May 2005 18:35:16 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050527163516.GB15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> <1117192464.6688.3.camel@localhost.localdomain> <20050527121503.GN15391@postel.suug.ch> <1117201853.6383.29.camel@localhost.localdomain> <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117209411.6383.104.camel@localhost.localdomain> X-archive-position: 1778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2683 Lines: 63 * jamal <1117209411.6383.104.camel@localhost.localdomain> 2005-05-27 11:56 > On Fri, 2005-27-05 at 17:16 +0200, Thomas Graf wrote: > > Sorry but this is just one big hack: > > It maybe in the user space representation, but not in the kernel > abstraction which is what i was refering to. > In other words look at struct in_device; Yes, it references the arp device specific parameters and so does inet6_dev for the ndisc cache. But this repsents only the current state, we might have neighbour table parameter sets which are not bound to inetdevs in the future. However, I regard this as minor and I can agree on moving the device specific parameters into a inetdev based architecture but I do NOT agree on moving gc_ into this architecture as well, it doesn't belong there. Nitpicking for a bit, although inet6_dev and in_device hold reference to the their arp respectively ndisc parameter set, the sysctl interface does not use this reference but stores the ifindex of the netdevice, _which_ is correct I think because parameter sets are _not_ limited to inetdevs in terms of architecture but only in terms of current use. > The deafult can be overriden by devX. So they dont need to sync. > But this is a separate topic I was not talking about in-sync but rather that gc_* only appears in default/ but not in devX/. What I expect is that every default parameter can be overwritten in devX which is not true for gc_*. Which is the reason why I implemented them outside of the NDTPA_PARMS nested TLV. > I am afraid you are looking at this from the wrong angle (user space), > Thomas ;-> > The abstraction in the kernel is proper. > > To redraw that model again with the exact structure names: > > netdevice -> > L2 config stuff > config stuff > more config stuff > .. > .. > netdevice protocol config: > -> v4 specific (struct in_device) > ----> IPV4 addresses (ifa_list), ARP params(arp_parms),etc > -> v6 specific (struct inet6_dev) > ----> IPV6 addresses(addr_list), ndisc params (nd_parms), etc > > There are a few more items but i am leaving them out for brevity. > I hope it makes more sense now. I understand your architecture and if we follow this thought we'd have a "default" netdevice which repesents all default settings. I do agree with this architecture but the problematic question remains: Do we want parameters in "default" which are not available in devX? I think this question is what it gets down to in the end. If we say, yes we do want this, then we can implement all generic settings, such as tcp_, using this scheme as well. I don't disagree with this completely but I find it not very intuitive from a user perspective. From mchan@broadcom.com Fri May 27 09:57:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 09:57:21 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RGvHXq023661 for ; Fri, 27 May 2005 09:57:17 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 27 May 2005 09:56:06 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 27 May 2005 09:56:04 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAT30726; Fri, 27 May 2005 09:56:00 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id JAA12532; Fri, 27 May 2005 09:55:59 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 May 2005 16:55:59 +0000 Received: from rh4 by nt-irva-0741; 27 May 2005 08:58:23 -0700 Subject: Re: A new driver for Broadcom bcm5706 From: "Michael Chan" To: "Christoph Hellwig" cc: davem@davemloft.net, jgarzik@redhat.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com In-Reply-To: <20050527074115.GA28208@infradead.org> References: <1116609329.31523.16.camel@rh4> <20050527074115.GA28208@infradead.org> Date: Fri, 27 May 2005 08:58:23 -0700 Message-ID: <1117209503.4584.11.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E898EAF1VO2638161-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 769 Lines: 19 On Fri, 2005-05-27 at 08:41 +0100, Christoph Hellwig wrote: > On Fri, May 20, 2005 at 10:15:29AM -0700, Michael Chan wrote: > > A new driver bnx2 for Broadcom bcm5706 is available. Since the patch is > > over 500K, I've put it on the ftp server: > > > > ftp://Net_sys_anon@ftp1.broadcom.com/bnx2-2.patch > > > > The patch also includes new 1000BASE-X advertisement bit definitions in > > mii.h > > These defintions overlap older 10MB/s defintions. I don't think the number > space is scare enough to need this hack. If we absolutely want to keep it > you should at least add some big comments explaining it. > > Yes they do. But these overlapping bit definitions are defined by the 802.3 standard for 1000Base-X. These are not Broadcom proprietary definitions. From tgraf@suug.ch Fri May 27 10:00:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 10:00:08 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RH04Xq024217 for ; Fri, 27 May 2005 10:00:04 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id CDD671C0EB; Fri, 27 May 2005 18:59:35 +0200 (CEST) Date: Fri, 27 May 2005 18:59:35 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting Message-ID: <20050527165935.GC15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117209466.6383.106.camel@localhost.localdomain> X-archive-position: 1780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 928 Lines: 23 * jamal <1117209466.6383.106.camel@localhost.localdomain> 2005-05-27 11:57 > On Fri, 2005-27-05 at 17:19 +0200, Thomas Graf wrote: > > > Sure, I can come up with a patchset today which will include: > > o the new NLMSG_NEW macro > > o your patch adopted to use the new NLMSG_NEW macro > > o small patch to rename NLMSG_PUT_ANSWER usages into NLMSG_NEW_ANSWER > > o a small fallout from the new neighbour table code which gcc didn't > > warn me about when it should. > > > > OK? > > Sounds reasonable. I took your patch, converted it to use NLMSG_NEW and finished converting all the modules that you started. Yet unconverted are: netfilter, net/sched/ tcp_diag, xfrm, kernel/audit. I also fixed some uses of NL_CREDS() to fetch the pid for message generation which is wrong. Various dumping procedures did not set the multi flag at all, I fixed all of them. Do not apply these patches yet, they're way too intrusive From tgraf@suug.ch Fri May 27 10:01:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 10:01:14 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RH19Xq024720 for ; Fri, 27 May 2005 10:01:09 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 0D8781C0EB; Fri, 27 May 2005 19:00:42 +0200 (CEST) Date: Fri, 27 May 2005 19:00:41 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH 1/2] [NETLINK] Introduce NLMSG_NEW macro to better handle netlink flags Message-ID: <20050527170041.GD15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527165935.GC15391@postel.suug.ch> X-archive-position: 1781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4489 Lines: 125 Introduces a new macro NLMSG_NEW which extends NLMSG_PUT but takes a flags argument. NLMSG_PUT stays there for compatibility but now calls NLMSG_NEW with flags == 0. NLMSG_PUT_ANSWER is renamed to NLMSG_NEW_ANSWER which now also takes a flags argument. Also converts the users of NLMSG_PUT_ANSWER to use NLMSG_NEW_ANSWER and fixes the two direct users of __nlmsg_put to either provide the flags or use NLMSG_NEW(_ANSWER). Signed-off-by: Thomas Graf --- commit 1eb85f52f4e0d23996f6aa49009ce02fc0579658 tree debb58e5f900a6551f751b457226250cfccc3c75 parent fde09d4989b6c7b5183ffb3ec2076ff53dd6fa78 author Thomas Graf Fri, 27 May 2005 17:43:09 +0200 committer Thomas Graf Fri, 27 May 2005 17:43:09 +0200 include/linux/netlink.h | 17 ++++++++++------- net/core/neighbour.c | 8 ++++---- net/netlink/af_netlink.c | 8 +++++--- 3 files changed, 19 insertions(+), 14 deletions(-) Index: include/linux/netlink.h =================================================================== --- b032d0d440d93aac252e656bd41df32ff5461e3a/include/linux/netlink.h (mode:100644) +++ debb58e5f900a6551f751b457226250cfccc3c75/include/linux/netlink.h (mode:100644) @@ -156,7 +156,7 @@ }; static __inline__ struct nlmsghdr * -__nlmsg_put(struct sk_buff *skb, u32 pid, u32 seq, int type, int len) +__nlmsg_put(struct sk_buff *skb, u32 pid, u32 seq, int type, int len, int flags) { struct nlmsghdr *nlh; int size = NLMSG_LENGTH(len); @@ -164,20 +164,23 @@ nlh = (struct nlmsghdr*)skb_put(skb, NLMSG_ALIGN(size)); nlh->nlmsg_type = type; nlh->nlmsg_len = size; - nlh->nlmsg_flags = 0; + nlh->nlmsg_flags = flags; nlh->nlmsg_pid = pid; nlh->nlmsg_seq = seq; return nlh; } -#define NLMSG_PUT(skb, pid, seq, type, len) \ +#define NLMSG_NEW(skb, pid, seq, type, len, flags) \ ({ if (skb_tailroom(skb) < (int)NLMSG_SPACE(len)) \ goto nlmsg_failure; \ - __nlmsg_put(skb, pid, seq, type, len); }) + __nlmsg_put(skb, pid, seq, type, len, flags); }) + +#define NLMSG_PUT(skb, pid, seq, type, len) \ + NLMSG_NEW(skb, pid, seq, type, len, 0) -#define NLMSG_PUT_ANSWER(skb, cb, type, len) \ - NLMSG_PUT(skb, NETLINK_CB((cb)->skb).pid, \ - (cb)->nlh->nlmsg_seq, type, len) +#define NLMSG_NEW_ANSWER(skb, cb, type, len, flags) \ + NLMSG_NEW(skb, NETLINK_CB((cb)->skb).pid, \ + (cb)->nlh->nlmsg_seq, type, len, flags) #define NLMSG_END(skb, nlh) \ ({ (nlh)->nlmsg_len = (skb)->tail - (unsigned char *) (nlh); \ Index: net/core/neighbour.c =================================================================== --- b032d0d440d93aac252e656bd41df32ff5461e3a/net/core/neighbour.c (mode:100644) +++ debb58e5f900a6551f751b457226250cfccc3c75/net/core/neighbour.c (mode:100644) @@ -1588,8 +1588,8 @@ struct nlmsghdr *nlh; struct ndtmsg *ndtmsg; - nlh = NLMSG_PUT_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg)); - nlh->nlmsg_flags |= NLM_F_MULTI; + nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg), + NLM_F_MULTI); ndtmsg = NLMSG_DATA(nlh); @@ -1673,8 +1673,8 @@ struct ndtmsg *ndtmsg; struct nlmsghdr *nlh; - nlh = NLMSG_PUT_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg)); - nlh->nlmsg_flags |= NLM_F_MULTI; + nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg), + NLM_F_MULTI); ndtmsg = NLMSG_DATA(nlh); Index: net/netlink/af_netlink.c =================================================================== --- b032d0d440d93aac252e656bd41df32ff5461e3a/net/netlink/af_netlink.c (mode:100644) +++ debb58e5f900a6551f751b457226250cfccc3c75/net/netlink/af_netlink.c (mode:100644) @@ -1095,8 +1095,7 @@ return 0; } - nlh = __nlmsg_put(skb, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, NLMSG_DONE, sizeof(int)); - nlh->nlmsg_flags |= NLM_F_MULTI; + nlh = NLMSG_NEW_ANSWER(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI); memcpy(NLMSG_DATA(nlh), &len, sizeof(len)); skb_queue_tail(&sk->sk_receive_queue, skb); sk->sk_data_ready(sk, skb->len); @@ -1107,6 +1106,9 @@ netlink_destroy_callback(cb); return 0; + +nlmsg_failure: + return -ENOBUFS; } int netlink_dump_start(struct sock *ssk, struct sk_buff *skb, @@ -1178,7 +1180,7 @@ } rep = __nlmsg_put(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq, - NLMSG_ERROR, sizeof(struct nlmsgerr)); + NLMSG_ERROR, sizeof(struct nlmsgerr), 0); errmsg = NLMSG_DATA(rep); errmsg->error = err; memcpy(&errmsg->msg, nlh, err ? nlh->nlmsg_len : sizeof(struct nlmsghdr)); From tgraf@suug.ch Fri May 27 10:02:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 10:02:07 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RH22Xq025181 for ; Fri, 27 May 2005 10:02:02 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 3FE5C1C0EB; Fri, 27 May 2005 19:01:35 +0200 (CEST) Date: Fri, 27 May 2005 19:01:35 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH 2/2] [NETLINK] Correctly set NLM_F_MULTI without checking the pid Message-ID: <20050527170135.GE15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527165935.GC15391@postel.suug.ch> X-archive-position: 1782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 22836 Lines: 676 This patch rectifies some rtnetlink message builders that derive the flags from the pid. It is now explicit like the other cases which get it right. Also fixes half a dozen dumpers which did not set NLM_F_MULTI at all. Signed-off-by: Jamal Hadi Salim Signed-off-by: Thomas Graf --- commit b20a9fb4f28c4397096cf3c745c42cf045c36a7a tree 5144b4dc6ffa4fb1821eb758838f63c5e210bc34 parent 1eb85f52f4e0d23996f6aa49009ce02fc0579658 author Thomas Graf Fri, 27 May 2005 18:58:48 +0200 committer Thomas Graf Fri, 27 May 2005 18:58:48 +0200 net/core/neighbour.c | 14 ++++++------- net/core/rtnetlink.c | 13 +++++++----- net/decnet/dn_dev.c | 9 ++++---- net/decnet/dn_route.c | 11 +++++----- net/decnet/dn_rules.c | 7 +++--- net/decnet/dn_table.c | 8 +++---- net/ipv4/devinet.c | 9 +++----- net/ipv4/fib_hash.c | 3 +- net/ipv4/fib_lookup.h | 3 +- net/ipv4/fib_rules.c | 7 +++--- net/ipv4/fib_semantics.c | 6 ++--- net/ipv4/route.c | 11 ++++------ net/ipv6/addrconf.c | 49 ++++++++++++++++++++++------------------------- net/ipv6/route.c | 11 +++++----- 14 files changed, 83 insertions(+), 78 deletions(-) Index: net/core/neighbour.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/core/neighbour.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/core/neighbour.c (mode:100644) @@ -1857,18 +1857,17 @@ } static int neigh_fill_info(struct sk_buff *skb, struct neighbour *n, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned int flags) { unsigned long now = jiffies; unsigned char *b = skb->tail; struct nda_cacheinfo ci; int locked = 0; u32 probes; - struct nlmsghdr *nlh = NLMSG_PUT(skb, pid, seq, event, - sizeof(struct ndmsg)); + struct nlmsghdr *nlh = NLMSG_NEW(skb, pid, seq, event, + sizeof(struct ndmsg), flags); struct ndmsg *ndm = NLMSG_DATA(nlh); - nlh->nlmsg_flags = pid ? NLM_F_MULTI : 0; ndm->ndm_family = n->ops->family; ndm->ndm_flags = n->flags; ndm->ndm_type = n->type; @@ -1918,7 +1917,8 @@ continue; if (neigh_fill_info(skb, n, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, - RTM_NEWNEIGH) <= 0) { + RTM_NEWNEIGH, + NLM_F_MULTI) <= 0) { read_unlock_bh(&tbl->lock); rc = -1; goto out; @@ -2327,7 +2327,7 @@ if (!skb) return; - if (neigh_fill_info(skb, n, 0, 0, RTM_GETNEIGH) < 0) { + if (neigh_fill_info(skb, n, 0, 0, RTM_GETNEIGH, 0) < 0) { kfree_skb(skb); return; } @@ -2346,7 +2346,7 @@ if (!skb) return; - if (neigh_fill_info(skb, n, 0, 0, RTM_NEWNEIGH) < 0) { + if (neigh_fill_info(skb, n, 0, 0, RTM_NEWNEIGH, 0) < 0) { kfree_skb(skb); return; } Index: net/core/rtnetlink.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/core/rtnetlink.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/core/rtnetlink.c (mode:100644) @@ -178,14 +178,14 @@ static int rtnetlink_fill_ifinfo(struct sk_buff *skb, struct net_device *dev, - int type, u32 pid, u32 seq, u32 change) + int type, u32 pid, u32 seq, u32 change, + unsigned int flags) { struct ifinfomsg *r; struct nlmsghdr *nlh; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, type, sizeof(*r)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh = NLMSG_NEW(skb, pid, seq, type, sizeof(*r), flags); r = NLMSG_DATA(nlh); r->ifi_family = AF_UNSPEC; r->ifi_type = dev->type; @@ -275,7 +275,10 @@ for (dev=dev_base, idx=0; dev; dev = dev->next, idx++) { if (idx < s_idx) continue; - if (rtnetlink_fill_ifinfo(skb, dev, RTM_NEWLINK, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, 0) <= 0) + if (rtnetlink_fill_ifinfo(skb, dev, RTM_NEWLINK, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, 0, + NLM_F_MULTI) <= 0) break; } read_unlock(&dev_base_lock); @@ -449,7 +452,7 @@ if (!skb) return; - if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change) < 0) { + if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change, 0) < 0) { kfree_skb(skb); return; } Index: net/decnet/dn_dev.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/decnet/dn_dev.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/decnet/dn_dev.c (mode:100644) @@ -716,13 +716,13 @@ } static int dn_dev_fill_ifaddr(struct sk_buff *skb, struct dn_ifaddr *ifa, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned int flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags); ifm = NLMSG_DATA(nlh); ifm->ifa_family = AF_DECnet; @@ -755,7 +755,7 @@ netlink_set_err(rtnl, 0, RTMGRP_DECnet_IFADDR, ENOBUFS); return; } - if (dn_dev_fill_ifaddr(skb, ifa, 0, 0, event) < 0) { + if (dn_dev_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_DECnet_IFADDR, EINVAL); return; @@ -790,7 +790,8 @@ if (dn_dev_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, - RTM_NEWADDR) <= 0) + RTM_NEWADDR, + NLM_F_MULTI) <= 0) goto done; } } Index: net/decnet/dn_route.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/decnet/dn_route.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/decnet/dn_route.c (mode:100644) @@ -1465,7 +1465,8 @@ return dn_route_input_slow(skb); } -static int dn_rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, int event, int nowait) +static int dn_rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, + int event, int nowait, unsigned int flags) { struct dn_route *rt = (struct dn_route *)skb->dst; struct rtmsg *r; @@ -1473,9 +1474,8 @@ unsigned char *b = skb->tail; struct rta_cacheinfo ci; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r)); + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags); r = NLMSG_DATA(nlh); - nlh->nlmsg_flags = (nowait && pid) ? NLM_F_MULTI : 0; r->rtm_family = AF_DECnet; r->rtm_dst_len = 16; r->rtm_src_len = 0; @@ -1596,7 +1596,7 @@ NETLINK_CB(skb).dst_pid = NETLINK_CB(in_skb).pid; - err = dn_rt_fill_info(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq, RTM_NEWROUTE, 0); + err = dn_rt_fill_info(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq, RTM_NEWROUTE, 0, 0); if (err == 0) goto out_free; @@ -1644,7 +1644,8 @@ continue; skb->dst = dst_clone(&rt->u.dst); if (dn_rt_fill_info(skb, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWROUTE, 1) <= 0) { + cb->nlh->nlmsg_seq, RTM_NEWROUTE, + 1, NLM_F_MULTI) <= 0) { dst_release(xchg(&skb->dst, NULL)); rcu_read_unlock_bh(); goto done; Index: net/decnet/dn_rules.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/decnet/dn_rules.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/decnet/dn_rules.c (mode:100644) @@ -342,14 +342,15 @@ .notifier_call = dn_fib_rules_event, }; -static int dn_fib_fill_rule(struct sk_buff *skb, struct dn_fib_rule *r, struct netlink_callback *cb) +static int dn_fib_fill_rule(struct sk_buff *skb, struct dn_fib_rule *r, + struct netlink_callback *cb, unsigned int flags) { struct rtmsg *rtm; struct nlmsghdr *nlh; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, NETLINK_CREDS(cb->skb)->pid, cb->nlh->nlmsg_seq, RTM_NEWRULE, sizeof(*rtm)); + nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWRULE, sizeof(*rtm), flags); rtm = NLMSG_DATA(nlh); rtm->rtm_family = AF_DECnet; rtm->rtm_dst_len = r->r_dst_len; @@ -394,7 +395,7 @@ for(r = dn_fib_rules, idx = 0; r; r = r->r_next, idx++) { if (idx < s_idx) continue; - if (dn_fib_fill_rule(skb, r, cb) < 0) + if (dn_fib_fill_rule(skb, r, cb, NLM_F_MULTI) < 0) break; } read_unlock(&dn_fib_rules_lock); Index: net/decnet/dn_table.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/decnet/dn_table.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/decnet/dn_table.c (mode:100644) @@ -270,13 +270,13 @@ static int dn_fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event, u8 tb_id, u8 type, u8 scope, void *dst, int dst_len, - struct dn_fib_info *fi) + struct dn_fib_info *fi, unsigned int flags) { struct rtmsg *rtm; struct nlmsghdr *nlh; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*rtm)); + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*rtm), flags); rtm = NLMSG_DATA(nlh); rtm->rtm_family = AF_DECnet; rtm->rtm_dst_len = dst_len; @@ -345,7 +345,7 @@ if (dn_fib_dump_info(skb, pid, nlh->nlmsg_seq, event, tb_id, f->fn_type, f->fn_scope, &f->fn_key, z, - DN_FIB_INFO(f)) < 0) { + DN_FIB_INFO(f), 0) < 0) { kfree_skb(skb); return; } @@ -377,7 +377,7 @@ tb->n, (f->fn_state & DN_S_ZOMBIE) ? 0 : f->fn_type, f->fn_scope, &f->fn_key, dz->dz_order, - f->fn_info) < 0) { + f->fn_info, NLM_F_MULTI) < 0) { cb->args[3] = i; return -1; } Index: net/ipv4/devinet.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/devinet.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/devinet.c (mode:100644) @@ -1015,14 +1015,13 @@ }; static int inet_fill_ifaddr(struct sk_buff *skb, struct in_ifaddr *ifa, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned int flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags); ifm = NLMSG_DATA(nlh); ifm->ifa_family = AF_INET; ifm->ifa_prefixlen = ifa->ifa_prefixlen; @@ -1075,7 +1074,7 @@ continue; if (inet_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, - RTM_NEWADDR) <= 0) { + RTM_NEWADDR, NLM_F_MULTI) <= 0) { rcu_read_unlock(); goto done; } @@ -1098,7 +1097,7 @@ if (!skb) netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, ENOBUFS); - else if (inet_fill_ifaddr(skb, ifa, 0, 0, event) < 0) { + else if (inet_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, EINVAL); } else { Index: net/ipv4/fib_hash.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/fib_hash.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/fib_hash.c (mode:100644) @@ -703,7 +703,8 @@ &f->fn_key, fz->fz_order, fa->fa_tos, - fa->fa_info) < 0) { + fa->fa_info, + NLM_F_MULTI) < 0) { cb->args[3] = i; return -1; } Index: net/ipv4/fib_lookup.h =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/fib_lookup.h (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/fib_lookup.h (mode:100644) @@ -30,7 +30,8 @@ struct kern_rta *rta, struct fib_info *fi); extern int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event, u8 tb_id, u8 type, u8 scope, void *dst, - int dst_len, u8 tos, struct fib_info *fi); + int dst_len, u8 tos, struct fib_info *fi, + unsigned int); extern void rtmsg_fib(int event, u32 key, struct fib_alias *fa, int z, int tb_id, struct nlmsghdr *n, struct netlink_skb_parms *req); Index: net/ipv4/fib_rules.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/fib_rules.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/fib_rules.c (mode:100644) @@ -367,13 +367,14 @@ static __inline__ int inet_fill_rule(struct sk_buff *skb, struct fib_rule *r, - struct netlink_callback *cb) + struct netlink_callback *cb, + unsigned int flags) { struct rtmsg *rtm; struct nlmsghdr *nlh; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, NETLINK_CREDS(cb->skb)->pid, cb->nlh->nlmsg_seq, RTM_NEWRULE, sizeof(*rtm)); + nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWRULE, sizeof(*rtm), flags); rtm = NLMSG_DATA(nlh); rtm->rtm_family = AF_INET; rtm->rtm_dst_len = r->r_dst_len; @@ -422,7 +423,7 @@ for (r=fib_rules, idx=0; r; r = r->r_next, idx++) { if (idx < s_idx) continue; - if (inet_fill_rule(skb, r, cb) < 0) + if (inet_fill_rule(skb, r, cb, NLM_F_MULTI) < 0) break; } read_unlock(&fib_rules_lock); Index: net/ipv4/fib_semantics.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/fib_semantics.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/fib_semantics.c (mode:100644) @@ -286,7 +286,7 @@ if (fib_dump_info(skb, pid, n->nlmsg_seq, event, tb_id, fa->fa_type, fa->fa_scope, &key, z, fa->fa_tos, - fa->fa_info) < 0) { + fa->fa_info, 0) < 0) { kfree_skb(skb); return; } @@ -932,13 +932,13 @@ int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event, u8 tb_id, u8 type, u8 scope, void *dst, int dst_len, u8 tos, - struct fib_info *fi) + struct fib_info *fi, unsigned int flags) { struct rtmsg *rtm; struct nlmsghdr *nlh; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*rtm)); + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*rtm), flags); rtm = NLMSG_DATA(nlh); rtm->rtm_family = AF_INET; rtm->rtm_dst_len = dst_len; Index: net/ipv4/route.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/route.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/route.c (mode:100644) @@ -2581,7 +2581,7 @@ } static int rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, int event, - int nowait) + int nowait, unsigned int flags) { struct rtable *rt = (struct rtable*)skb->dst; struct rtmsg *r; @@ -2591,9 +2591,8 @@ #ifdef CONFIG_IP_MROUTE struct rtattr *eptr; #endif - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r)); + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags); r = NLMSG_DATA(nlh); - nlh->nlmsg_flags = (nowait && pid) ? NLM_F_MULTI : 0; r->rtm_family = AF_INET; r->rtm_dst_len = 32; r->rtm_src_len = 0; @@ -2744,7 +2743,7 @@ NETLINK_CB(skb).dst_pid = NETLINK_CB(in_skb).pid; err = rt_fill_info(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq, - RTM_NEWROUTE, 0); + RTM_NEWROUTE, 0, 0); if (!err) goto out_free; if (err < 0) { @@ -2781,8 +2780,8 @@ continue; skb->dst = dst_clone(&rt->u.dst); if (rt_fill_info(skb, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, - RTM_NEWROUTE, 1) <= 0) { + cb->nlh->nlmsg_seq, RTM_NEWROUTE, + 1, NLM_F_MULTI) <= 0) { dst_release(xchg(&skb->dst, NULL)); rcu_read_unlock_bh(); goto done; Index: net/ipv6/addrconf.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv6/addrconf.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv6/addrconf.c (mode:100644) @@ -2621,15 +2621,14 @@ } static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned int flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; struct ifa_cacheinfo ci; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags); ifm = NLMSG_DATA(nlh); ifm->ifa_family = AF_INET6; ifm->ifa_prefixlen = ifa->prefix_len; @@ -2671,15 +2670,14 @@ } static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; struct ifa_cacheinfo ci; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags); ifm = NLMSG_DATA(nlh); ifm->ifa_family = AF_INET6; ifm->ifa_prefixlen = 128; @@ -2708,15 +2706,14 @@ } static int inet6_fill_ifacaddr(struct sk_buff *skb, struct ifacaddr6 *ifaca, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned int flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; struct ifa_cacheinfo ci; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags); ifm = NLMSG_DATA(nlh); ifm->ifa_family = AF_INET6; ifm->ifa_prefixlen = 128; @@ -2785,7 +2782,8 @@ continue; if ((err = inet6_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) + cb->nlh->nlmsg_seq, RTM_NEWADDR, + NLM_F_MULTI)) <= 0) goto done; } /* temp addr */ @@ -2796,7 +2794,8 @@ continue; if ((err = inet6_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) + cb->nlh->nlmsg_seq, RTM_NEWADDR, + NLM_F_MULTI)) <= 0) goto done; } #endif @@ -2809,7 +2808,8 @@ continue; if ((err = inet6_fill_ifmcaddr(skb, ifmca, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_GETMULTICAST)) <= 0) + cb->nlh->nlmsg_seq, RTM_GETMULTICAST, + NLM_F_MULTI)) <= 0) goto done; } break; @@ -2821,7 +2821,8 @@ continue; if ((err = inet6_fill_ifacaddr(skb, ifaca, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_GETANYCAST)) <= 0) + cb->nlh->nlmsg_seq, RTM_GETANYCAST, + NLM_F_MULTI)) <= 0) goto done; } break; @@ -2871,7 +2872,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, ENOBUFS); return; } - if (inet6_fill_ifaddr(skb, ifa, 0, 0, event) < 0) { + if (inet6_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, EINVAL); return; @@ -2906,7 +2907,7 @@ } static int inet6_fill_ifinfo(struct sk_buff *skb, struct inet6_dev *idev, - u32 pid, u32 seq, int event) + u32 pid, u32 seq, int event, unsigned int flags) { struct net_device *dev = idev->dev; __s32 *array = NULL; @@ -2917,8 +2918,7 @@ __u32 mtu = dev->mtu; struct ifla_cacheinfo ci; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r)); - if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags); r = NLMSG_DATA(nlh); r->ifi_family = AF_INET6; r->ifi_type = dev->type; @@ -2985,7 +2985,7 @@ if ((idev = in6_dev_get(dev)) == NULL) continue; err = inet6_fill_ifinfo(skb, idev, NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWLINK); + cb->nlh->nlmsg_seq, RTM_NEWLINK, NLM_F_MULTI); in6_dev_put(idev); if (err <= 0) break; @@ -3007,7 +3007,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, ENOBUFS); return; } - if (inet6_fill_ifinfo(skb, idev, 0, 0, event) < 0) { + if (inet6_fill_ifinfo(skb, idev, 0, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, EINVAL); return; @@ -3017,18 +3017,15 @@ } static int inet6_fill_prefix(struct sk_buff *skb, struct inet6_dev *idev, - struct prefix_info *pinfo, u32 pid, u32 seq, int event) + struct prefix_info *pinfo, u32 pid, u32 seq, + int event, unsigned int flags) { struct prefixmsg *pmsg; struct nlmsghdr *nlh; unsigned char *b = skb->tail; struct prefix_cacheinfo ci; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*pmsg)); - - if (pid) - nlh->nlmsg_flags |= NLM_F_MULTI; - + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*pmsg), flags); pmsg = NLMSG_DATA(nlh); pmsg->prefix_family = AF_INET6; pmsg->prefix_ifindex = idev->dev->ifindex; @@ -3067,7 +3064,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, ENOBUFS); return; } - if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event) < 0) { + if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, EINVAL); return; Index: net/ipv6/route.c =================================================================== --- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv6/route.c (mode:100644) +++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv6/route.c (mode:100644) @@ -1570,7 +1570,8 @@ struct in6_addr *src, int iif, int type, u32 pid, u32 seq, - struct nlmsghdr *in_nlh, int prefix) + struct nlmsghdr *in_nlh, int prefix, + unsigned int flags) { struct rtmsg *rtm; struct nlmsghdr *nlh; @@ -1588,7 +1589,7 @@ pid = in_nlh->nlmsg_pid; } - nlh = NLMSG_PUT(skb, pid, seq, type, sizeof(*rtm)); + nlh = NLMSG_NEW(skb, pid, seq, type, sizeof(*rtm), flags); rtm = NLMSG_DATA(nlh); rtm->rtm_family = AF_INET6; rtm->rtm_dst_len = rt->rt6i_dst.plen; @@ -1674,7 +1675,7 @@ return rt6_fill_node(arg->skb, rt, NULL, NULL, 0, RTM_NEWROUTE, NETLINK_CB(arg->cb->skb).pid, arg->cb->nlh->nlmsg_seq, - NULL, prefix); + NULL, prefix, NLM_F_MULTI); } static int fib6_dump_node(struct fib6_walker_t *w) @@ -1822,7 +1823,7 @@ &fl.fl6_dst, &fl.fl6_src, iif, RTM_NEWROUTE, NETLINK_CB(in_skb).pid, - nlh->nlmsg_seq, nlh, 0); + nlh->nlmsg_seq, nlh, 0, 0); if (err < 0) { err = -EMSGSIZE; goto out_free; @@ -1848,7 +1849,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_ROUTE, ENOBUFS); return; } - if (rt6_fill_node(skb, rt, NULL, NULL, 0, event, 0, 0, nlh, 0) < 0) { + if (rt6_fill_node(skb, rt, NULL, NULL, 0, event, 0, 0, nlh, 0, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_ROUTE, EINVAL); return; From SRS0+2be871c1938b6cbd8bec+642+infradead.org+hch@pentafluge.srs.infradead.org Fri May 27 10:16:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 10:16:36 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RHGSXq026248 for ; Fri, 27 May 2005 10:16:33 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DbiQn-0001UY-0T; Fri, 27 May 2005 18:15:33 +0100 Date: Fri, 27 May 2005 18:15:32 +0100 From: Christoph Hellwig To: Michael Chan Cc: Christoph Hellwig , davem@davemloft.net, jgarzik@redhat.com, netdev@oss.sgi.com, ffan@broadcom.com, lusinsky@broadcom.com Subject: Re: A new driver for Broadcom bcm5706 Message-ID: <20050527171532.GA5715@infradead.org> References: <1116609329.31523.16.camel@rh4> <20050527074115.GA28208@infradead.org> <1117209503.4584.11.camel@rh4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117209503.4584.11.camel@rh4> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 1783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 532 Lines: 13 On Fri, May 27, 2005 at 08:58:23AM -0700, Michael Chan wrote: > > These defintions overlap older 10MB/s defintions. I don't think the number > > space is scare enough to need this hack. If we absolutely want to keep it > > you should at least add some big comments explaining it. > > > > > Yes they do. But these overlapping bit definitions are defined by the > 802.3 standard for 1000Base-X. These are not Broadcom proprietary > definitions. Ok, makes a lot of sense. Now just mention that in a nice comment in ethtool.h :) From SRS0+2be871c1938b6cbd8bec+642+infradead.org+hch@pentafluge.srs.infradead.org Fri May 27 11:54:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 11:54:30 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RIsRXq030757 for ; Fri, 27 May 2005 11:54:28 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1Dbjxf-0001wX-37; Fri, 27 May 2005 19:53:35 +0100 Date: Fri, 27 May 2005 19:53:35 +0100 From: Christoph Hellwig To: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, mchan@broadcom.com Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids Message-ID: <20050527185334.GA7417@infradead.org> Mail-Followup-To: Christoph Hellwig , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, mchan@broadcom.com References: <04132005193844.8410@laptop> <04132005193844.8474@laptop> <20050421165956.55bdcb14.davem@davemloft.net> <20050527184750.GB11592@tuxdriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527184750.GB11592@tuxdriver.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 1785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 705 Lines: 20 On Fri, May 27, 2005 at 02:47:52PM -0400, John W. Linville wrote: > Update pci.ids for BCM5752 > > Signed-off-by: John W. Linville > --- > > drivers/pci/pci.ids | 1 + > 1 files changed, 1 insertion(+) > > --- tg3-pci/drivers/pci/pci.ids.orig 2005-05-27 14:41:25.243607911 -0400 > +++ tg3-pci/drivers/pci/pci.ids 2005-05-27 14:43:45.553326412 -0400 > @@ -7173,6 +7173,7 @@ > 080f Sentry5 DDR/SDR RAM Controller > 0811 Sentry5 External Interface Core > 0816 BCM3302 Sentry5 MIPS32 CPU > + 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express I don't think you should mention "PCI Express" here. That can trivially befound it looking at the configuration header. From linville@bilbo.tuxdriver.com Fri May 27 11:48:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 11:48:50 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RImkXq030156 for ; Fri, 27 May 2005 11:48:47 -0700 Received: from bilbo.tuxdriver.com (azure.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j4RHkQa26603; Fri, 27 May 2005 13:46:26 -0400 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j4RIlsJD021753; Fri, 27 May 2005 14:47:54 -0400 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j4RIlq3R021752; Fri, 27 May 2005 14:47:52 -0400 Date: Fri, 27 May 2005 14:47:52 -0400 From: "John W. Linville" To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, mchan@broadcom.com Subject: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids Message-ID: <20050527184750.GB11592@tuxdriver.com> Mail-Followup-To: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, mchan@broadcom.com References: <04132005193844.8410@laptop> <04132005193844.8474@laptop> <20050421165956.55bdcb14.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050421165956.55bdcb14.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 1784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 650 Lines: 21 Update pci.ids for BCM5752 Signed-off-by: John W. Linville --- drivers/pci/pci.ids | 1 + 1 files changed, 1 insertion(+) --- tg3-pci/drivers/pci/pci.ids.orig 2005-05-27 14:41:25.243607911 -0400 +++ tg3-pci/drivers/pci/pci.ids 2005-05-27 14:43:45.553326412 -0400 @@ -7173,6 +7173,7 @@ 080f Sentry5 DDR/SDR RAM Controller 0811 Sentry5 External Interface Core 0816 BCM3302 Sentry5 MIPS32 CPU + 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express 1644 NetXtreme BCM5700 Gigabit Ethernet 1014 0277 Broadcom Vigil B5700 1000Base-T 1028 00d1 Broadcom BCM5700 -- John W. Linville linville@tuxdriver.com From linville@bilbo.tuxdriver.com Fri May 27 12:01:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 12:01:09 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RJ16Xq031804 for ; Fri, 27 May 2005 12:01:06 -0700 Received: from bilbo.tuxdriver.com (azure.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j4RHwXa26771; Fri, 27 May 2005 13:58:33 -0400 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j4RJ01rf021817; Fri, 27 May 2005 15:00:01 -0400 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j4RJ00wF021816; Fri, 27 May 2005 15:00:00 -0400 Date: Fri, 27 May 2005 15:00:00 -0400 From: "John W. Linville" To: Christoph Hellwig , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, mchan@broadcom.com Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids Message-ID: <20050527190000.GC11592@tuxdriver.com> Mail-Followup-To: Christoph Hellwig , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, mchan@broadcom.com References: <04132005193844.8410@laptop> <04132005193844.8474@laptop> <20050421165956.55bdcb14.davem@davemloft.net> <20050527184750.GB11592@tuxdriver.com> <20050527185334.GA7417@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527185334.GA7417@infradead.org> User-Agent: Mutt/1.4.1i X-archive-position: 1786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 1135 Lines: 28 On Fri, May 27, 2005 at 07:53:35PM +0100, Christoph Hellwig wrote: > On Fri, May 27, 2005 at 02:47:52PM -0400, John W. Linville wrote: > > + 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express > > I don't think you should mention "PCI Express" here. That can trivially > befound it looking at the configuration header. I'm just following what is at pciids.sourceforge.net. Plus, it is already like that for nine other IDs: 1659 NetXtreme BCM5721 Gigabit Ethernet PCI Express 1677 NetXtreme BCM5751 Gigabit Ethernet PCI Express 167d NetXtreme BCM5751M Gigabit Ethernet PCI Express 167e NetXtreme BCM5751F Fast Ethernet PCI Express 169d NetLink BCM5789 Gigabit Ethernet PCI Express 16dd NetLink BCM5781 Gigabit Ethernet PCI Express 16f7 NetXtreme BCM5753 Gigabit Ethernet PCI Express 16fd NetXtreme BCM5753M Gigabit Ethernet PCI Express 16fe NetXtreme BCM5753F Fast Ethernet PCI Express The Broadcom guys can speak-up, but I figure they know if "PCI Express" is appropriate for their device... :-) John -- John W. Linville linville@tuxdriver.com From SRS0+2be871c1938b6cbd8bec+642+infradead.org+hch@pentafluge.srs.infradead.org Fri May 27 12:02:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 12:02:57 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RJ2sXq032357 for ; Fri, 27 May 2005 12:02:54 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1Dbk5r-00020E-JM; Fri, 27 May 2005 20:02:03 +0100 Date: Fri, 27 May 2005 20:02:03 +0100 From: Christoph Hellwig To: Christoph Hellwig , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, mchan@broadcom.com Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids Message-ID: <20050527190203.GA7692@infradead.org> Mail-Followup-To: Christoph Hellwig , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, mchan@broadcom.com References: <04132005193844.8410@laptop> <04132005193844.8474@laptop> <20050421165956.55bdcb14.davem@davemloft.net> <20050527184750.GB11592@tuxdriver.com> <20050527185334.GA7417@infradead.org> <20050527190000.GC11592@tuxdriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527190000.GC11592@tuxdriver.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 1787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 1272 Lines: 26 On Fri, May 27, 2005 at 03:00:00PM -0400, John W. Linville wrote: > On Fri, May 27, 2005 at 07:53:35PM +0100, Christoph Hellwig wrote: > > On Fri, May 27, 2005 at 02:47:52PM -0400, John W. Linville wrote: > > > > + 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express > > > > I don't think you should mention "PCI Express" here. That can trivially > > befound it looking at the configuration header. > > I'm just following what is at pciids.sourceforge.net. Plus, it is > already like that for nine other IDs: > > 1659 NetXtreme BCM5721 Gigabit Ethernet PCI Express > 1677 NetXtreme BCM5751 Gigabit Ethernet PCI Express > 167d NetXtreme BCM5751M Gigabit Ethernet PCI Express > 167e NetXtreme BCM5751F Fast Ethernet PCI Express > 169d NetLink BCM5789 Gigabit Ethernet PCI Express > 16dd NetLink BCM5781 Gigabit Ethernet PCI Express > 16f7 NetXtreme BCM5753 Gigabit Ethernet PCI Express > 16fd NetXtreme BCM5753M Gigabit Ethernet PCI Express > 16fe NetXtreme BCM5753F Fast Ethernet PCI Express > > The Broadcom guys can speak-up, but I figure they know if "PCI Express" > is appropriate for their device... :-) ok, it should be an all or nothing. I still think it's more than silly.. From davem@davemloft.net Fri May 27 12:03:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 12:03:28 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RJ3LXq032556 for ; Fri, 27 May 2005 12:03:21 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Dbk64-0007lw-0E; Fri, 27 May 2005 12:02:16 -0700 Date: Fri, 27 May 2005 12:02:15 -0700 (PDT) Message-Id: <20050527.120215.26278001.davem@davemloft.net> To: ravinandan.arakali@neterion.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, raghavendra.koushik@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature From: "David S. Miller" In-Reply-To: <000a01c562d9$9b661130$3910100a@pc.s2io.com> References: <20050526.164217.45745005.davem@davemloft.net> <000a01c562d9$9b661130$3910100a@pc.s2io.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 918 Lines: 23 From: "Ravinandan Arakali" Date: Fri, 27 May 2005 09:32:00 -0700 > Thanks for the quick feedback. > At that time when we considered using skb_shinfo(skb)->fraglist, > it contained fragments of MTU size. So, for a 60k udp datagram > and 1500 MTU we will have 60k/1500 = 45 fragments which is > more than MAX_SKB_FRAGS(18). > > However we will relook at fraglist for the possibility of increasing > frag size to >MTU. MAX_SKB_FRAGS controls the limit of skb_shinfo(skb)->frags[] entries, not how many SKBs may be chained via skb_shinfo(skb)->fraglist, there is no limit on the latter. Note that there is much coalescing that can be performed on the SKB list data areas, particularly if UDP sendfile() is being used. But such coalescing is messy to be performing inside of the drivers. It may end up being the case that your approach ends up being a better one for these reasons. From davem@davemloft.net Fri May 27 12:04:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 12:04:56 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RJ4qXq000951 for ; Fri, 27 May 2005 12:04:52 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Dbk6x-0007mK-QI; Fri, 27 May 2005 12:03:11 -0700 Date: Fri, 27 May 2005 12:03:11 -0700 (PDT) Message-Id: <20050527.120311.17863590.davem@davemloft.net> To: shemminger@osdl.org Cc: ravinandan.arakali@neterion.com, jgarzik@pobox.com, netdev@oss.sgi.com, raghavendra.koushik@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature From: "David S. Miller" In-Reply-To: <20050527085713.373d702a@dxpl.pdx.osdl.net> References: <20050526232006.60E6365005@linux.site> <20050527085713.373d702a@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 447 Lines: 12 From: Stephen Hemminger Date: Fri, 27 May 2005 08:57:13 -0700 > The only downside is that it might encourage continued use of NFS over UDP. > Perhaps we need a big fat warning in NFS that says: > > *** Your using NFS over UDP, your data integrity is no longer guaranteed; > *** you have been warned. I agree, I think the NFS client should print out something like this when it mounts a volume over UDP for the first time. From mchan@broadcom.com Fri May 27 12:10:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 12:10:44 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RJAfXq001608 for ; Fri, 27 May 2005 12:10:41 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 27 May 2005 12:09:42 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 27 May 2005 12:09:40 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAT68433; Fri, 27 May 2005 12:09:40 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA28433; Fri, 27 May 2005 12:09:40 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 May 2005 19:09:39 +0000 Received: from rh4 by nt-irva-0741; 27 May 2005 11:12:04 -0700 Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids From: "Michael Chan" To: "John W. Linville" cc: "Christoph Hellwig" , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, lusinsky@broadcom.com In-Reply-To: <20050527190000.GC11592@tuxdriver.com> References: <04132005193844.8410@laptop> <04132005193844.8474@laptop> <20050421165956.55bdcb14.davem@davemloft.net> <20050527184750.GB11592@tuxdriver.com> <20050527185334.GA7417@infradead.org> <20050527190000.GC11592@tuxdriver.com> Date: Fri, 27 May 2005 11:12:04 -0700 Message-ID: <1117217524.4310.1.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E89AFFC1VO2673885-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1241 Lines: 27 On Fri, 2005-05-27 at 15:00 -0400, John W. Linville wrote: > On Fri, May 27, 2005 at 07:53:35PM +0100, Christoph Hellwig wrote: > > On Fri, May 27, 2005 at 02:47:52PM -0400, John W. Linville wrote: > > > > + 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express > > > > I don't think you should mention "PCI Express" here. That can trivially > > befound it looking at the configuration header. > > I'm just following what is at pciids.sourceforge.net. Plus, it is > already like that for nine other IDs: > > 1659 NetXtreme BCM5721 Gigabit Ethernet PCI Express > 1677 NetXtreme BCM5751 Gigabit Ethernet PCI Express > 167d NetXtreme BCM5751M Gigabit Ethernet PCI Express > 167e NetXtreme BCM5751F Fast Ethernet PCI Express > 169d NetLink BCM5789 Gigabit Ethernet PCI Express > 16dd NetLink BCM5781 Gigabit Ethernet PCI Express > 16f7 NetXtreme BCM5753 Gigabit Ethernet PCI Express > 16fd NetXtreme BCM5753M Gigabit Ethernet PCI Express > 16fe NetXtreme BCM5753F Fast Ethernet PCI Express > > The Broadcom guys can speak-up, but I figure they know if "PCI Express" > is appropriate for their device... :-) > Yes, "PCI Express" is appropriate. Thanks John. From davem@davemloft.net Fri May 27 12:31:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 12:31:45 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RJVfXq006322 for ; Fri, 27 May 2005 12:31:41 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbkXW-0007xc-0p; Fri, 27 May 2005 12:30:38 -0700 Date: Fri, 27 May 2005 12:30:37 -0700 (PDT) Message-Id: <20050527.123037.68041200.davem@davemloft.net> To: linville@tuxdriver.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, mchan@broadcom.com Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids From: "David S. Miller" In-Reply-To: <20050527184750.GB11592@tuxdriver.com> References: <04132005193844.8474@laptop> <20050421165956.55bdcb14.davem@davemloft.net> <20050527184750.GB11592@tuxdriver.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 307 Lines: 11 From: "John W. Linville" Date: Fri, 27 May 2005 14:47:52 -0400 > Update pci.ids for BCM5752 > > Signed-off-by: John W. Linville I'll apply this, thanks John. pci.ids needs several updates for tg3 in fact, and it also now needs entries for bnx2 as well. From linville@bilbo.tuxdriver.com Fri May 27 13:27:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 13:27:13 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RKR8Xq009057 for ; Fri, 27 May 2005 13:27:09 -0700 Received: from bilbo.tuxdriver.com (azure.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j4RJOna28063; Fri, 27 May 2005 15:24:49 -0400 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j4RKQIgW022793; Fri, 27 May 2005 16:26:18 -0400 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j4RKQIPG022792; Fri, 27 May 2005 16:26:18 -0400 Date: Fri, 27 May 2005 16:26:18 -0400 From: "John W. Linville" To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com, cramerj@intel.com Subject: [patch linux-2.6.12-rc5 1/1] e1000: revert watchdog task Message-ID: <20050527202617.GA22786@tuxdriver.com> Mail-Followup-To: netdev@oss.sgi.com, jgarzik@pobox.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com, cramerj@intel.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 1793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 2703 Lines: 71 Undo the previous addition of the e1000_watchdog_task workqueue. Signed-off-by: John W. Linville --- After some discussion w/ the e1000 maintainers, we came to the conclusion that the e1000_watchdog_task was at best unnecessary and at worst caused more problems than it might solve. This patch reverst the patch which created that workqueue (posted 3/14/2005). drivers/net/e1000/e1000.h | 1 - drivers/net/e1000/e1000_main.c | 15 ++------------- 2 files changed, 2 insertions(+), 14 deletions(-) --- linux-2.6.12-rc5/drivers/net/e1000/e1000.h.orig 2005-05-27 16:15:47.478498035 -0400 +++ linux-2.6.12-rc5/drivers/net/e1000/e1000.h 2005-05-27 16:15:55.004463809 -0400 @@ -220,7 +220,6 @@ struct e1000_adapter { spinlock_t stats_lock; atomic_t irq_sem; struct work_struct tx_timeout_task; - struct work_struct watchdog_task; uint8_t fc_autoneg; struct timer_list blink_timer; --- linux-2.6.12-rc5/drivers/net/e1000/e1000_main.c.orig 2005-05-27 16:15:47.480497760 -0400 +++ linux-2.6.12-rc5/drivers/net/e1000/e1000_main.c 2005-05-27 16:15:55.006463534 -0400 @@ -123,7 +123,6 @@ static void e1000_clean_rx_ring(struct e static void e1000_set_multi(struct net_device *netdev); static void e1000_update_phy_info(unsigned long data); static void e1000_watchdog(unsigned long data); -static void e1000_watchdog_task(struct e1000_adapter *adapter); static void e1000_82547_tx_fifo_stall(unsigned long data); static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev); static struct net_device_stats * e1000_get_stats(struct net_device *netdev); @@ -641,9 +640,6 @@ e1000_probe(struct pci_dev *pdev, adapter->watchdog_timer.function = &e1000_watchdog; adapter->watchdog_timer.data = (unsigned long) adapter; - INIT_WORK(&adapter->watchdog_task, - (void (*)(void *))e1000_watchdog_task, adapter); - init_timer(&adapter->phy_info_timer); adapter->phy_info_timer.function = &e1000_update_phy_info; adapter->phy_info_timer.data = (unsigned long) adapter; @@ -1752,20 +1748,13 @@ e1000_82547_tx_fifo_stall(unsigned long /** * e1000_watchdog - Timer Call-back - * @data: pointer to adapter cast into an unsigned long + * @data: pointer to netdev cast into an unsigned long **/ + static void e1000_watchdog(unsigned long data) { struct e1000_adapter *adapter = (struct e1000_adapter *) data; - - /* Do the rest outside of interrupt context */ - schedule_work(&adapter->watchdog_task); -} - -static void -e1000_watchdog_task(struct e1000_adapter *adapter) -{ struct net_device *netdev = adapter->netdev; struct e1000_desc_ring *txdr = &adapter->tx_ring; uint32_t link; -- John W. Linville linville@tuxdriver.com From mchan@broadcom.com Fri May 27 13:25:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 13:25:58 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RKPtXq008924 for ; Fri, 27 May 2005 13:25:55 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 27 May 2005 13:22:08 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 27 May 2005 13:22:06 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BAT84914; Fri, 27 May 2005 13:21:55 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA14219; Fri, 27 May 2005 13:21:55 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 May 2005 20:21:54 +0000 Received: from rh4 by nt-irva-0741; 27 May 2005 12:24:19 -0700 Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids From: "Michael Chan" To: "David S. Miller" cc: linville@tuxdriver.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com In-Reply-To: <20050527.123037.68041200.davem@davemloft.net> References: <04132005193844.8474@laptop> <20050421165956.55bdcb14.davem@davemloft.net> <20050527184750.GB11592@tuxdriver.com> <20050527.123037.68041200.davem@davemloft.net> Date: Fri, 27 May 2005 12:24:19 -0700 Message-ID: <1117221859.4310.6.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E895EFA2U42798052-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 392 Lines: 14 On Fri, 2005-05-27 at 12:30 -0700, David S. Miller wrote: > I'll apply this, thanks John. > > pci.ids needs several updates for tg3 in fact, and it > also now needs entries for bnx2 as well. > The bnx2 IDs are already in, probably from sourceforge. And the tg3 IDs look reasonably complete to me. So in the future, do we need to patch this file or just let sourceforge take care of it? From mitch.a.williams@intel.com Fri May 27 13:28:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 13:28:52 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RKSlXq009431 for ; Fri, 27 May 2005 13:28:47 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4RKR5g5032298; Fri, 27 May 2005 20:27:05 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j4RKR5lj002167; Fri, 27 May 2005 20:27:05 GMT Received: from mawilli1-desk2.amr.corp.intel.com (mawilli1-desk2.amr.corp.intel.com [134.134.3.124]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j4RKR4SL010757; Fri, 27 May 2005 13:27:04 -0700 Date: Fri, 27 May 2005 13:27:04 -0700 From: Mitch Williams X-X-Sender: mawilli1@mawilli1-desk2.amr.corp.intel.com To: netdev@oss.sgi.com, Stephen Hemminger , hadi@cyberus.ca, Robert.Olsson@data.slu.se cc: "Ronciak, John" , "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: Re: RFC: NAPI packet weighting patch In-Reply-To: <20050527085055.79da3d75@dxpl.pdx.osdl.net> Message-ID: References: <20050527085055.79da3d75@dxpl.pdx.osdl.net> ReplyTo: "Mitch Williams" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch.a.williams@intel.com Precedence: bulk X-list: netdev Content-Length: 1433 Lines: 36 Stephen, Robert, and Jamal all replied to my original message, and all said approximately the same thing: "Why don't you just reduce the weight in the driver? It does the same thing." To which I reply, respectfully, I know that. And no it doesn't, not exactly. My primary reason for adding this setting is to allow for runtime tweaking -- just like max_backlog has right now. Driver weight is a compile-time setting, and has to be changed for every driver that you run. This setting allows you to scale the weight of all your drivers, at runtime, in one place. It's complimentary to Stephen's max_weight idea -- his patch affects how long you spend in any individual softirq; my patch affects how long you spend in any driver's individual NAPI poll routine, as well as how long the softirq lasts. Perhaps we can merge the two patches to come up with some Ultimate Tweakable Network Goodness. I'd be happy to do that (on Tuesday; I'm heading home early today) if anybody's interested. -Mitch NB: I've got a white paper that I wrote up for internal consumption. I plan to post it to our Sourceforge archive, but I need to do a bunch of scrubbing first, lest our lawyers go into convulsions. Meanwhile, I can give away the ending: for my performance tests, on a pure Gigabit network, I saw consistently better performance by a) using my patch, b) reducing max_backlog, and c) using a nonzero value for packet_weight. From davem@davemloft.net Fri May 27 13:41:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 13:41:44 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RKffXq010980 for ; Fri, 27 May 2005 13:41:41 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbldB-000823-4x; Fri, 27 May 2005 13:40:33 -0700 Date: Fri, 27 May 2005 13:40:32 -0700 (PDT) Message-Id: <20050527.134032.78491984.davem@davemloft.net> To: mchan@broadcom.com Cc: linville@tuxdriver.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids From: "David S. Miller" In-Reply-To: <1117221859.4310.6.camel@rh4> References: <20050527184750.GB11592@tuxdriver.com> <20050527.123037.68041200.davem@davemloft.net> <1117221859.4310.6.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 431 Lines: 12 From: "Michael Chan" Date: Fri, 27 May 2005 12:24:19 -0700 > So in the future, do we need to patch this file or just let sourceforge > take care of it? I think the proper procedure is to send it to sourceforge. But there is some latency in the changes making it back into the kernel. Either way, if it is submitted to the kernel or sourceforge (or even both), it ends up getting merged together in the end. From davem@davemloft.net Fri May 27 13:42:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 13:42:11 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RKg8Xq011095 for ; Fri, 27 May 2005 13:42:08 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Dbldf-00082S-Mq; Fri, 27 May 2005 13:41:03 -0700 Date: Fri, 27 May 2005 13:41:03 -0700 (PDT) Message-Id: <20050527.134103.10293460.davem@davemloft.net> To: jgarzik@pobox.com Cc: mchan@broadcom.com, linville@tuxdriver.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids From: "David S. Miller" In-Reply-To: <429785B5.6020705@pobox.com> References: <20050527.123037.68041200.davem@davemloft.net> <1117221859.4310.6.camel@rh4> <429785B5.6020705@pobox.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 312 Lines: 8 From: Jeff Garzik Date: Fri, 27 May 2005 16:40:21 -0400 > pci.ids is only used in one location -- deprecated /proc/pci -- and will > be removed in the next year or so, I imagine. Further, pci.ids is > periodically sync'd en masse from sourceforge into the kernel by janitors. Good point. From jgarzik@pobox.com Fri May 27 13:41:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 13:41:21 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RKfIXq010928 for ; Fri, 27 May 2005 13:41:18 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1Dbld1-0003fb-B5; Fri, 27 May 2005 20:40:24 +0000 Message-ID: <429785B5.6020705@pobox.com> Date: Fri, 27 May 2005 16:40:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: "David S. Miller" , linville@tuxdriver.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids References: <04132005193844.8474@laptop> <20050421165956.55bdcb14.davem@davemloft.net> <20050527184750.GB11592@tuxdriver.com> <20050527.123037.68041200.davem@davemloft.net> <1117221859.4310.6.camel@rh4> In-Reply-To: <1117221859.4310.6.camel@rh4> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 926 Lines: 31 Michael Chan wrote: > On Fri, 2005-05-27 at 12:30 -0700, David S. Miller wrote: > > >>I'll apply this, thanks John. >> >>pci.ids needs several updates for tg3 in fact, and it >>also now needs entries for bnx2 as well. >> > > > The bnx2 IDs are already in, probably from sourceforge. And the tg3 IDs > look reasonably complete to me. > > So in the future, do we need to patch this file or just let sourceforge > take care of it? Honestly, pci.ids is such a non-critical file, unless DaveM disagrees I would strongly encourage people to -only- send pci.ids updates to sourceforge. pci.ids is only used in one location -- deprecated /proc/pci -- and will be removed in the next year or so, I imagine. Further, pci.ids is periodically sync'd en masse from sourceforge into the kernel by janitors. Users should be using 'lspci' not /proc/pci, and lspci takes it data from sourceforge database not the kernel. Jeff From davem@davemloft.net Fri May 27 13:42:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 13:43:03 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RKgvXq011718 for ; Fri, 27 May 2005 13:42:57 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DbleF-00082n-RV; Fri, 27 May 2005 13:41:39 -0700 Date: Fri, 27 May 2005 13:41:39 -0700 (PDT) Message-Id: <20050527.134139.32345929.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: hadi@cyberus.ca, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [0/10] [IPSEC] IPsec event notification From: "David S. Miller" In-Reply-To: <20050527110730.GA4424@gondor.apana.org.au> References: <20050527110730.GA4424@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 272 Lines: 10 From: Herbert Xu Date: Fri, 27 May 2005 21:07:30 +1000 > Would it be possible for you to pull the tree at > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/herbert/ipsec-2.6.git/ > > into your net-2.6.13 tree? Pulled, thanks Herbert. From shemminger@osdl.org Fri May 27 14:03:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 14:03:06 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RL32Xq013734 for ; Fri, 27 May 2005 14:03:02 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4RL1WjA006775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 14:01:33 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4RL1Wgw009146; Fri, 27 May 2005 14:01:32 -0700 Date: Fri, 27 May 2005 14:01:32 -0700 From: Stephen Hemminger To: Mitch Williams Cc: netdev@oss.sgi.com, hadi@cyberus.ca, Robert.Olsson@data.slu.se, "Ronciak, John" , "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: Re: RFC: NAPI packet weighting patch Message-ID: <20050527140132.1435132d@dxpl.pdx.osdl.net> In-Reply-To: References: <20050527085055.79da3d75@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 984 Lines: 24 On Fri, 27 May 2005 13:27:04 -0700 Mitch Williams wrote: > > Stephen, Robert, and Jamal all replied to my original message, and all > said approximately the same thing: "Why don't you just reduce the weight > in the driver? It does the same thing." > > To which I reply, respectfully, I know that. And no it doesn't, not > exactly. > > My primary reason for adding this setting is to allow for runtime tweaking > -- just like max_backlog has right now. Driver weight is a compile-time > setting, and has to be changed for every driver that you run. > > This setting allows you to scale the weight of all your drivers, at > runtime, in one place. It's complimentary to Stephen's max_weight idea -- > his patch affects how long you spend in any individual softirq; my patch > affects how long you spend in any driver's individual NAPI poll routine, > as well as how long the softirq lasts. > Why not just allow adjusting dev->weight via sysfs? From christoph@lameter.com Fri May 27 14:16:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 14:17:02 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RLGsXq014662 for ; Fri, 27 May 2005 14:16:54 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DbmBP-0006gY-6h; Fri, 27 May 2005 14:15:56 -0700 Date: Fri, 27 May 2005 14:15:55 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Eric Dumazet cc: Andi Kleen , netdev@oss.sgi.com, akpm@osdl.org, shai@scalex86.org Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 In-Reply-To: <428AF378.5020109@cosmosbay.com> Message-ID: References: <428AF378.5020109@cosmosbay.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 366 Lines: 10 On Wed, 18 May 2005, Eric Dumazet wrote: > Related question, is pci_alloc_consistent() already NUMA aware ? Nope. It also ultimately acquires memory via vmalloc. pci_alloc_consistent will also need some rework to allocate memory consistent (well the name is coherent right?) with the node that the device is on. Second case of a need for a node aware vmalloc? From christoph@lameter.com Fri May 27 14:53:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 14:53:58 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RLrsXq016359 for ; Fri, 27 May 2005 14:53:54 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DbmlD-0006kD-CL; Fri, 27 May 2005 14:52:57 -0700 Date: Fri, 27 May 2005 14:52:55 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Andrew Morton cc: Ganesh Venkatesan , davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shai@scalex86.org Subject: [PATCH] e1000: NUMA aware allocation of descriptors V2 In-Reply-To: <20050518134250.3ee2703f.akpm@osdl.org> Message-ID: References: <20050517190343.2e57fdd7.akpm@osdl.org> <20050517.195703.104034854.davem@davemloft.net> <20050517215845.2f87be2f.akpm@osdl.org> <5fc59ff305051808558f1ce59@mail.gmail.com> <20050518134250.3ee2703f.akpm@osdl.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 6193 Lines: 176 NUMA awareness for the e1000 driver. Allocate tx and rx descriptors on the node of the device. It is safe to replace vmalloc by kmalloc node since only the descriptors are allocated in a NUMA aware way. These will not be so large that the use of vmalloc becomes necesssary. The patch includes a modification to slab.h to revert from inline functions for kmalloc_node/kmem_cache_alloc_node to a macro so that an undefined variable may be specified. Is that ok? If so then I probably need to spin a separate patch just for slab.h. V1-V2: - Patch against 2.6.12-rc5-mm1 - Do not defined netdev->node for non NUMA case - Change kmem_cache_alloc_node and kmalloc_node to fall back to macro definitions for the non numa case so that an undefined variable can be specified. References to earlier discussions: http://marc.theaimsgroup.com/?t=111638151000001&r=1&w=2 Note that i386 pci_alloc_coherent also needs to be made NUMA aware. Signed-off-by: Christoph Lameter Signed-off-by: Justin M. Forbes Signed-off-by: Shai Fultheim Index: linux-2.6.12-rc5/drivers/net/e1000/e1000_main.c =================================================================== --- linux-2.6.12-rc5.orig/drivers/net/e1000/e1000_main.c 2005-05-27 21:22:39.000000000 +0000 +++ linux-2.6.12-rc5/drivers/net/e1000/e1000_main.c 2005-05-27 21:25:28.000000000 +0000 @@ -567,7 +567,9 @@ netdev->mem_start = mmio_start; netdev->mem_end = mmio_start + mmio_len; netdev->base_addr = adapter->hw.io_base; - +#ifdef CONFIG_NUMA + netdev->node = pcibus_to_node(pdev->bus); +#endif adapter->bd_number = cards_found; /* setup the private structure */ @@ -971,7 +973,9 @@ int size; size = sizeof(struct e1000_buffer) * txdr->count; - txdr->buffer_info = vmalloc(size); + + txdr->buffer_info = kmalloc_node(size, GFP_KERNEL, adapter->netdev->node ); + if(!txdr->buffer_info) { DPRINTK(PROBE, ERR, "Unable to allocate memory for the transmit descriptor ring\n"); @@ -987,7 +991,7 @@ txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { setup_tx_desc_die: - vfree(txdr->buffer_info); + kfree(txdr->buffer_info); DPRINTK(PROBE, ERR, "Unable to allocate memory for the transmit descriptor ring\n"); return -ENOMEM; @@ -1015,7 +1019,7 @@ DPRINTK(PROBE, ERR, "Unable to allocate aligned memory " "for the transmit descriptor ring\n"); - vfree(txdr->buffer_info); + kfree(txdr->buffer_info); return -ENOMEM; } else { /* Free old allocation, new allocation was successful */ @@ -1123,7 +1127,8 @@ int size, desc_len; size = sizeof(struct e1000_buffer) * rxdr->count; - rxdr->buffer_info = vmalloc(size); + rxdr->buffer_info = kmalloc_node(size, GFP_KERNEL, adapter->netdev->node); + if(!rxdr->buffer_info) { DPRINTK(PROBE, ERR, "Unable to allocate memory for the receive descriptor ring\n"); @@ -1134,7 +1139,7 @@ size = sizeof(struct e1000_ps_page) * rxdr->count; rxdr->ps_page = kmalloc(size, GFP_KERNEL); if(!rxdr->ps_page) { - vfree(rxdr->buffer_info); + kfree(rxdr->buffer_info); DPRINTK(PROBE, ERR, "Unable to allocate memory for the receive descriptor ring\n"); return -ENOMEM; @@ -1144,7 +1149,7 @@ size = sizeof(struct e1000_ps_page_dma) * rxdr->count; rxdr->ps_page_dma = kmalloc(size, GFP_KERNEL); if(!rxdr->ps_page_dma) { - vfree(rxdr->buffer_info); + kfree(rxdr->buffer_info); kfree(rxdr->ps_page); DPRINTK(PROBE, ERR, "Unable to allocate memory for the receive descriptor ring\n"); @@ -1166,7 +1171,7 @@ if(!rxdr->desc) { setup_rx_desc_die: - vfree(rxdr->buffer_info); + kfree(rxdr->buffer_info); kfree(rxdr->ps_page); kfree(rxdr->ps_page_dma); DPRINTK(PROBE, ERR, @@ -1196,7 +1201,7 @@ DPRINTK(PROBE, ERR, "Unable to allocate aligned memory " "for the receive descriptor ring\n"); - vfree(rxdr->buffer_info); + kfree(rxdr->buffer_info); kfree(rxdr->ps_page); kfree(rxdr->ps_page_dma); return -ENOMEM; @@ -1393,7 +1398,7 @@ e1000_clean_tx_ring(adapter); - vfree(adapter->tx_ring.buffer_info); + kfree(adapter->tx_ring.buffer_info); adapter->tx_ring.buffer_info = NULL; pci_free_consistent(pdev, adapter->tx_ring.size, @@ -1473,7 +1478,7 @@ e1000_clean_rx_ring(adapter); - vfree(rx_ring->buffer_info); + kfree(rx_ring->buffer_info); rx_ring->buffer_info = NULL; kfree(rx_ring->ps_page); rx_ring->ps_page = NULL; Index: linux-2.6.12-rc5/include/linux/netdevice.h =================================================================== --- linux-2.6.12-rc5.orig/include/linux/netdevice.h 2005-05-27 21:22:39.000000000 +0000 +++ linux-2.6.12-rc5/include/linux/netdevice.h 2005-05-27 21:22:43.000000000 +0000 @@ -279,7 +279,9 @@ unsigned long mem_start; /* shared mem start */ unsigned long base_addr; /* device I/O address */ unsigned int irq; /* device IRQ number */ - +#ifdef CONFIG_NUMA + unsigned int node; /* device node number */ +#endif /* * Some hardware also needs these fields, but they are not * part of the usual set specified in Space.c. Index: linux-2.6.12-rc5/include/linux/slab.h =================================================================== --- linux-2.6.12-rc5.orig/include/linux/slab.h 2005-05-25 03:31:20.000000000 +0000 +++ linux-2.6.12-rc5/include/linux/slab.h 2005-05-27 21:30:42.000000000 +0000 @@ -106,14 +106,12 @@ extern void *kmem_cache_alloc_node(kmem_cache_t *, int flags, int node); extern void *kmalloc_node(size_t size, int flags, int node); #else -static inline void *kmem_cache_alloc_node(kmem_cache_t *cachep, int flags, int node) -{ - return kmem_cache_alloc(cachep, flags); -} -static inline void *kmalloc_node(size_t size, int flags, int node) -{ - return kmalloc(size, flags); -} +/* + * The definitions are macros here to allow the use of an undefined variable + * for the node. The variable may only be defined if CONFIG_NUMA is set. + */ +#define kmem_cache_alloc_node(__cachep, __flags, __node) kmem_cache_alloc(__cachep, __flags) +#define kmalloc_node(__size, __flags, __node) kmalloc(__size, __flags) #endif extern int FASTCALL(kmem_cache_reap(int)); From rich@phekda.gotadsl.co.uk Fri May 27 15:37:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 15:37:37 -0700 (PDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RMbVXq018436 for ; Fri, 27 May 2005 15:37:31 -0700 Received: from katrina.int.phekda.gotadsl.co.uk (unknown [84.12.78.142]) by smtp.nildram.co.uk (Postfix) with ESMTP id 23EC924D99B; Fri, 27 May 2005 23:36:37 +0100 (BST) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id EEAA0381DF; Fri, 27 May 2005 23:36:39 +0100 (BST) Message-ID: <4297A0F7.5070209@phekda.gotadsl.co.uk> Date: Fri, 27 May 2005 23:36:39 +0100 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: Linux netdev Subject: [PATCH] r8169: support restricting speed+duplex in autonegotiation Content-Type: multipart/mixed; boundary="------------060003000203050201030506" X-archive-position: 1802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 14309 Lines: 485 This is a multi-part message in MIME format. --------------060003000203050201030506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. Attached is a patch for drivers/net/r8169.c against Linux 2.6.11 that allows adjustment of the speed and duplex advertised via autonegotiation. Example usage: ethtool -s eth0 autoneg on speed 10 duplex half Also attached is a test script which tries various combinations of autoneg, speed and duplex. There is also a log of the test run attache.d While the test ran I had an ssh session running "while true; do sleep 1; date; done". The ssh session did not drop. Note that I don't have GigE, so that part of the test was bogus. I also tried various speed tests, to check that the speed and duplex were actually changed. They were. Bye, Rich r8169: Allow adjustment of speed and duplex advertised via autonegotiation Signed-off-by: Richard Dawe --------------060003000203050201030506 Content-Type: text/plain; name="r8169-ethtool-autoneg.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r8169-ethtool-autoneg.diff" --- r8169.c.orig 2005-05-27 21:12:21.000000000 +0100 +++ r8169.c 2005-05-27 22:14:59.000000000 +0100 @@ -407,7 +407,9 @@ struct rtl8169_private { #ifdef CONFIG_R8169_VLAN struct vlan_group *vlgrp; #endif - int (*set_speed)(struct net_device *, u8 autoneg, u16 speed, u8 duplex); + int (*set_speed)(struct net_device *, + u8 autoneg, u16 speed, u8 duplex, + u32 advertising); void (*get_settings)(struct net_device *, struct ethtool_cmd *); void (*phy_reset_enable)(void __iomem *); unsigned int (*phy_reset_pending)(void __iomem *); @@ -549,7 +551,9 @@ static void rtl8169_check_link_status(st spin_unlock_irqrestore(&tp->lock, flags); } -static void rtl8169_link_option(int idx, u8 *autoneg, u16 *speed, u8 *duplex) +static void rtl8169_link_option(int idx, + u8 *autoneg, u16 *speed, u8 *duplex, + u32 *advertising) { struct { u16 speed; @@ -579,6 +583,23 @@ static void rtl8169_link_option(int idx, *autoneg = p->autoneg; *speed = p->speed; *duplex = p->duplex; + + if (p->media == _10_Half) + *advertising = ADVERTISED_10baseT_Half; + if (p->media == _10_Full) + *advertising = ADVERTISED_10baseT_Full; + if (p->media == _100_Half) + *advertising = ADVERTISED_100baseT_Half; + if (p->media == _100_Full) + *advertising = ADVERTISED_100baseT_Full; + if (p->media == _1000_Full) + *advertising = ADVERTISED_1000baseT_Full; + if (p->media == 0xff) + *advertising = ADVERTISED_10baseT_Half | + ADVERTISED_10baseT_Full | + ADVERTISED_100baseT_Half | + ADVERTISED_100baseT_Full | + ADVERTISED_1000baseT_Full; } static void rtl8169_get_drvinfo(struct net_device *dev, @@ -597,7 +618,8 @@ static int rtl8169_get_regs_len(struct n } static int rtl8169_set_speed_tbi(struct net_device *dev, - u8 autoneg, u16 speed, u8 duplex) + u8 autoneg, u16 speed, u8 duplex, + u32 advertising) { struct rtl8169_private *tp = netdev_priv(dev); void __iomem *ioaddr = tp->mmio_addr; @@ -608,7 +630,8 @@ static int rtl8169_set_speed_tbi(struct if ((autoneg == AUTONEG_DISABLE) && (speed == SPEED_1000) && (duplex == DUPLEX_FULL)) { RTL_W32(TBICSR, reg & ~(TBINwEnable | TBINwRestart)); - } else if (autoneg == AUTONEG_ENABLE) + } else if ((autoneg == AUTONEG_ENABLE) && + (advertising & ADVERTISED_1000baseT_Full)) RTL_W32(TBICSR, reg | TBINwEnable | TBINwRestart); else { printk(KERN_WARNING PFX @@ -621,11 +644,13 @@ static int rtl8169_set_speed_tbi(struct } static int rtl8169_set_speed_xmii(struct net_device *dev, - u8 autoneg, u16 speed, u8 duplex) + u8 autoneg, u16 speed, u8 duplex, + u32 advertising) { struct rtl8169_private *tp = netdev_priv(dev); void __iomem *ioaddr = tp->mmio_addr; int auto_nego, giga_ctrl; + int ret = 0; auto_nego = mdio_read(ioaddr, PHY_AUTO_NEGO_REG); auto_nego &= ~(PHY_Cap_10_Half | PHY_Cap_10_Full | @@ -634,9 +659,16 @@ static int rtl8169_set_speed_xmii(struct giga_ctrl &= ~(PHY_Cap_1000_Full | PHY_Cap_Null); if (autoneg == AUTONEG_ENABLE) { - auto_nego |= (PHY_Cap_10_Half | PHY_Cap_10_Full | - PHY_Cap_100_Half | PHY_Cap_100_Full); - giga_ctrl |= PHY_Cap_1000_Full; + if (advertising & ADVERTISED_10baseT_Half) + auto_nego |= PHY_Cap_10_Half; + if (advertising & ADVERTISED_10baseT_Full) + auto_nego |= PHY_Cap_10_Full; + if (advertising & ADVERTISED_100baseT_Half) + auto_nego |= PHY_Cap_100_Half; + if (advertising & ADVERTISED_100baseT_Full) + auto_nego |= PHY_Cap_100_Full; + if (advertising & ADVERTISED_1000baseT_Full) + giga_ctrl |= PHY_Cap_1000_Full; } else { if (speed == SPEED_10) auto_nego |= PHY_Cap_10_Half | PHY_Cap_10_Full; @@ -649,23 +681,28 @@ static int rtl8169_set_speed_xmii(struct auto_nego &= ~(PHY_Cap_10_Full | PHY_Cap_100_Full); } - tp->phy_auto_nego_reg = auto_nego; - tp->phy_1000_ctrl_reg = giga_ctrl; + if (ret == 0) + { + tp->phy_auto_nego_reg = auto_nego; + tp->phy_1000_ctrl_reg = giga_ctrl; + + mdio_write(ioaddr, PHY_AUTO_NEGO_REG, auto_nego); + mdio_write(ioaddr, PHY_1000_CTRL_REG, giga_ctrl); + mdio_write(ioaddr, PHY_CTRL_REG, PHY_Enable_Auto_Nego | + PHY_Restart_Auto_Nego); + } - mdio_write(ioaddr, PHY_AUTO_NEGO_REG, auto_nego); - mdio_write(ioaddr, PHY_1000_CTRL_REG, giga_ctrl); - mdio_write(ioaddr, PHY_CTRL_REG, PHY_Enable_Auto_Nego | - PHY_Restart_Auto_Nego); - return 0; + return ret; } static int rtl8169_set_speed(struct net_device *dev, - u8 autoneg, u16 speed, u8 duplex) + u8 autoneg, u16 speed, u8 duplex, + u32 advertising) { struct rtl8169_private *tp = netdev_priv(dev); int ret; - ret = tp->set_speed(dev, autoneg, speed, duplex); + ret = tp->set_speed(dev, autoneg, speed, duplex, advertising); if (netif_running(dev) && (tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full)) mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); @@ -680,7 +717,9 @@ static int rtl8169_set_settings(struct n int ret; spin_lock_irqsave(&tp->lock, flags); - ret = rtl8169_set_speed(dev, cmd->autoneg, cmd->speed, cmd->duplex); + ret = rtl8169_set_speed(dev, + cmd->autoneg, cmd->speed, cmd->duplex, + cmd->advertising); spin_unlock_irqrestore(&tp->lock, flags); return ret; @@ -1311,6 +1350,7 @@ rtl8169_init_one(struct pci_dev *pdev, c static int printed_version = 0; u8 autoneg, duplex; u16 speed; + u32 advertising; int i, rc; assert(pdev != NULL); @@ -1423,9 +1463,9 @@ rtl8169_init_one(struct pci_dev *pdev, c mdio_write(ioaddr, 0x0b, 0x0000); //w 0x0b 15 0 0 } - rtl8169_link_option(board_idx, &autoneg, &speed, &duplex); + rtl8169_link_option(board_idx, &autoneg, &speed, &duplex, &advertising); - rtl8169_set_speed(dev, autoneg, speed, duplex); + rtl8169_set_speed(dev, autoneg, speed, duplex, advertising); if (RTL_R8(PHYstatus) & TBI_Enable) printk(KERN_INFO PFX "%s: TBI auto-negotiating\n", dev->name); --------------060003000203050201030506 Content-Type: application/x-sh; name="test.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test.sh" for i in on off; do ethtool -s eth0 autoneg $i speed 10 duplex half sleep 10 ethtool eth0 sleep 10 ethtool -s eth0 autoneg $i speed 10 duplex full sleep 10 ethtool eth0 sleep 10 ethtool -s eth0 autoneg $i speed 100 duplex half sleep 10 ethtool eth0 sleep 10 ethtool -s eth0 autoneg $i speed 100 duplex full sleep 10 ethtool eth0 sleep 10 ethtool -s eth0 autoneg $i speed 1000 duplex full sleep 10 ethtool eth0 sleep 10 ethtool -s eth0 autoneg on sleep 10 ethtool eth0 sleep 10 done --------------060003000203050201030506 Content-Type: text/plain; name="test.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test.log" + for i in on off + ethtool -s eth0 autoneg on speed 10 duplex half + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Half Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 + ethtool -s eth0 autoneg on speed 10 duplex full + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 + ethtool -s eth0 autoneg on speed 100 duplex half + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 100baseT/Half Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Half Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 + ethtool -s eth0 autoneg on speed 100 duplex full + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 + ethtool -s eth0 autoneg on speed 1000 duplex full + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Half Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: no + sleep 10 + ethtool -s eth0 autoneg on + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 + for i in on off + ethtool -s eth0 autoneg off speed 10 duplex half + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Half Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 + ethtool -s eth0 autoneg off speed 10 duplex full + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 + ethtool -s eth0 autoneg off speed 100 duplex half + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 100baseT/Half Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Half Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 + ethtool -s eth0 autoneg off speed 100 duplex full + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 + ethtool -s eth0 autoneg off speed 1000 duplex full + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Half Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: no + sleep 10 + ethtool -s eth0 autoneg on + sleep 10 + ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes + sleep 10 --------------060003000203050201030506-- From davej@redhat.com Fri May 27 15:47:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 15:47:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RMlVXq019232 for ; Fri, 27 May 2005 15:47:31 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4RMka8g031903; Fri, 27 May 2005 18:46:36 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4RMkaO00335; Fri, 27 May 2005 18:46:36 -0400 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j4RMkaET016279; Fri, 27 May 2005 18:46:36 -0400 Received: (from davej@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) id j4RMkalU016277; Fri, 27 May 2005 18:46:36 -0400 X-Authentication-Warning: devserv.devel.redhat.com: davej set sender to davej@redhat.com using -f Date: Fri, 27 May 2005 18:46:36 -0400 From: Dave Jones To: "David S. Miller" Cc: mchan@broadcom.com, linville@tuxdriver.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids Message-ID: <20050527224636.GA1677@redhat.com> Mail-Followup-To: Dave Jones , "David S. Miller" , mchan@broadcom.com, linville@tuxdriver.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com References: <20050527184750.GB11592@tuxdriver.com> <20050527.123037.68041200.davem@davemloft.net> <1117221859.4310.6.camel@rh4> <20050527.134032.78491984.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527.134032.78491984.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 1803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@redhat.com Precedence: bulk X-list: netdev Content-Length: 790 Lines: 20 On Fri, May 27, 2005 at 01:40:32PM -0700, David S. Miller wrote: > From: "Michael Chan" > Date: Fri, 27 May 2005 12:24:19 -0700 > > > So in the future, do we need to patch this file or just let sourceforge > > take care of it? > > I think the proper procedure is to send it to sourceforge. > But there is some latency in the changes making it back > into the kernel. The latest diff vs mainline is always available at http://www.codemonkey.org.uk/projects/pci/ (Comedy aside, I dont even remember which box is running the cronjob that generates those files any more, good that its still ticking :-) Greg did a sync up a while ago, but didn't seem too enthusiastic about doing it regularly, due to the fact that /proc/pci is aparently going away. Dave From tgraf@suug.ch Fri May 27 15:48:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 15:48:23 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RMlwXq019279 for ; Fri, 27 May 2005 15:48:18 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 587B11C0EB; Sat, 28 May 2005 00:47:25 +0200 (CEST) Date: Sat, 28 May 2005 00:47:25 +0200 From: Thomas Graf To: netdev@oss.sgi.com Cc: Jamal Hadi Salim Subject: [RFC] textsearch infrastructure et al v2 Message-ID: <20050527224725.GG15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 1804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1681 Lines: 45 Dave, I'm going through another RFC round to hopefully get some comments on the notes below. I'm not yet satistifed with the core infrastructure wrt to non-linear data, especially for complex cases such as non linear skbs. The current way can be easly described as: search_occurrance() search-algorithm() while get-next-segment() process-segment() So basically we save the state of the segment fetching instead of saving the state of the search algorithm which would be way too complex for things like regular expression string matching. In the case of non linear skbs this would lead to: 1) start of search algorithm 2) first call to get_text(), return skb->data 3) processing of the text segment, return if match found 4) second call to get_text(), map and return first fragment 5) processing ... 6) third call to get_text(), unmap first fragment, map and return second fragment 7) processing ... n) etc. Assuming that the most common case is to have no fragments at all or if we only process a very limited number of fragments (due to restricted search area) this should be quite fast. However, the complexity of get_text() for the skb case including the map/unmap of the fragment interrupts the search flow quite a bit which hurts performance. In order to address this issue I'm having second thoughts about whether to allow the textsearch user to provide an array of text segments including their size, i.e. the skb fragments could be maped in prior and the algorithm could scan through it like nothing. ;-> However, this has one essential drawback, we might map fragments which we'll never use so this can be slower in the end. Any other ideas around? From tgraf@suug.ch Fri May 27 15:48:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 15:48:51 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RMmjXq019657 for ; Fri, 27 May 2005 15:48:45 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 32E0F1C0EB; Sat, 28 May 2005 00:48:18 +0200 (CEST) Date: Sat, 28 May 2005 00:48:18 +0200 From: Thomas Graf To: netdev@oss.sgi.com Cc: Jamal Hadi Salim Subject: [PATCH 2/5] [LIB] Knuth-Morris-Pratt string-matching algorithm Message-ID: <20050527224818.GI15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527224725.GG15391@postel.suug.ch> X-archive-position: 1806 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 5775 Lines: 201 Signed-off-by: Thomas Graf --- commit 5b70ca8eab4c7d7ef884582d9713cdbffa0f4cd4 tree 4d90ca82120da7b308b9a6bf11a1069473ca5d30 parent bf7ae763f13d767bd039703b3ab4f5954561df39 author Thomas Graf Fri, 27 May 2005 23:44:02 +0200 committer Thomas Graf Fri, 27 May 2005 23:44:02 +0200 lib/Kconfig | 13 +++++ lib/Makefile | 2 lib/ts_kmp.c | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 160 insertions(+) Index: lib/Kconfig =================================================================== --- ab065819ea6e966aa3db4f1c5935c421dd689d2e/lib/Kconfig (mode:100644) +++ 4d90ca82120da7b308b9a6bf11a1069473ca5d30/lib/Kconfig (mode:100644) @@ -57,5 +57,18 @@ config REED_SOLOMON_DEC16 boolean +menu "Textsearch facility" + +config TEXTSEARCH_KMP + tristate "Knuth-Morris-Pratt" + help + Say Y here if you want to be able to search text using the + Knuth-Morris-Pratt textsearch algorithm. + + To compile this code as a module, choose M here: the + module will be called ts_kmp. + +endmenu + endmenu Index: lib/Makefile =================================================================== --- ab065819ea6e966aa3db4f1c5935c421dd689d2e/lib/Makefile (mode:100644) +++ 4d90ca82120da7b308b9a6bf11a1069473ca5d30/lib/Makefile (mode:100644) @@ -33,6 +33,8 @@ obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/ +obj-$(CONFIG_TEXTSEARCH_KMP) += ts_kmp.o + hostprogs-y := gen_crc32table clean-files := crc32table.h Index: lib/ts_kmp.c =================================================================== --- /dev/null (tree:ab065819ea6e966aa3db4f1c5935c421dd689d2e) +++ 4d90ca82120da7b308b9a6bf11a1069473ca5d30/lib/ts_kmp.c (mode:100644) @@ -0,0 +1,145 @@ +/* + * lib/ts_kmp.c Knuth-Morris-Pratt text search implementation + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + * + * Implements a linear-time string-matching algorithm due to Knuth, + * Morris, and Pratt [0]. Their algorithm avoids the explicit + * computation of the transition function DELTA altogether. Its + * matching time is O(n), for n being length(text), using just an + * auxiliary function PI[1..m], for m being length(pattern), + * precomputed from the pattern in time O(m). The array PI allows + * the transition function DELTA to be computed efficiently + * "on the fly" as needed. Roughly speaking, for any state + * "q" = 0,1,...,m and any character "a" in SIGMA, the value + * PI["q"] contains the information that is independent of "a" and + * is needed to compute DELTA("q", "a") [1]. Since the array PI + * has only m entries, whereas DELTA has O(m|SIGMA|) entries, we + * save a factor of |SIGMA| in the preprocessing time by computing + * PI rather than DELTA. + * + * [0] Cormen, Leiserson, Rivest, Stein + * Introdcution to Algorithms, 2nd Edition, MIT Press + * [1] See finite automation theory + */ + +#include +#include +#include +#include +#include + +struct ts_kmp +{ + int pattern_len; + unsigned char * pattern; + unsigned int prefix_tbl[0]; +}; + +static int kmp_find(struct ts_config *conf, struct ts_state *state) +{ + struct ts_kmp *kmp = ts_config_priv(conf); + int i, q = 0, consumed = state->offset; + unsigned char *text; + size_t text_len; + + for (;;) { + text_len = conf->get_text(consumed, &text, conf, state); + + if (text_len == 0) + break; + + for (i = 0; i < text_len; i++) { + while (q > 0 && kmp->pattern[q] != text[i]) + q = kmp->prefix_tbl[q - 1]; + if (kmp->pattern[q] == text[i]) + q++; + if (q == kmp->pattern_len) { + state->offset = consumed + i + 1; + return state->offset - kmp->pattern_len; + } + } + + consumed += text_len; + } + + return -1; + +} + +static inline void compute_prefix_tbl(const unsigned char *pattern, size_t len, + unsigned int *prefix_tbl) +{ + unsigned int k, q; + + for (k = 0, q = 1; q < len; q++) { + while (k > 0 && pattern[k] != pattern[q]) + k = prefix_tbl[k-1]; + if (pattern[k] == pattern[q]) + k++; + prefix_tbl[q] = k; + } +} + +static struct ts_config *kmp_init(const unsigned char *pattern, size_t len, + int gfp_mask) +{ + struct ts_config *conf; + struct ts_kmp *kmp; + size_t prefix_tbl_len = len * sizeof(unsigned int); + size_t priv_size = sizeof(*kmp) + len + prefix_tbl_len; + + conf = alloc_ts_config(priv_size, gfp_mask); + if (IS_ERR(conf)) + return conf; + + kmp = ts_config_priv(conf); + kmp->pattern_len = len; + compute_prefix_tbl(pattern, len, kmp->prefix_tbl); + kmp->pattern = (unsigned char *) kmp->prefix_tbl + prefix_tbl_len; + memcpy(kmp->pattern, pattern, len); + + return conf; +} + +static unsigned char *kmp_get_pattern(struct ts_config *conf) +{ + struct ts_kmp *kmp = ts_config_priv(conf); + return kmp->pattern; +} + +static unsigned int kmp_get_pattern_len(struct ts_config *conf) +{ + struct ts_kmp *kmp = ts_config_priv(conf); + return kmp->pattern_len; +} + +static struct ts_ops kmp_ops = { + .name = "kmp", + .find = kmp_find, + .init = kmp_init, + .get_pattern = kmp_get_pattern, + .get_pattern_len = kmp_get_pattern_len, + .owner = THIS_MODULE, + .list = LIST_HEAD_INIT(kmp_ops.list) +}; + +static int __init init_kmp(void) +{ + return textsearch_register(&kmp_ops); +} + +static void __exit exit_kmp(void) +{ + textsearch_unregister(&kmp_ops); +} + +MODULE_LICENSE("GPL"); + +module_init(init_kmp); +module_exit(exit_kmp); From tgraf@suug.ch Fri May 27 15:48:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 15:48:33 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RMmQXq019480 for ; Fri, 27 May 2005 15:48:27 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 3E70E1C0ED; Sat, 28 May 2005 00:47:59 +0200 (CEST) Date: Sat, 28 May 2005 00:47:59 +0200 From: Thomas Graf To: netdev@oss.sgi.com Cc: Jamal Hadi Salim Subject: [PATCH 1/5] [LIB] textsearch infrastructure Message-ID: <20050527224759.GH15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527224725.GG15391@postel.suug.ch> X-archive-position: 1805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 14704 Lines: 490 Before a textsearch can be performed, a configuration must be created by calling textsearch_prepare() specyfing the searching algorithm and the pattern to match. The returned configuration may then be used for an arbitary amount of times and even in parallel as long as you provide a separate struct ts_state variable for every instance. The actual search is performed by either calling textsearch_find_- continuous() for linear text or by providing an own get_text() implementation and calling textsearch_find(). Both functions will returns the position of the first matching occurrence of the patern. Subsequent matches may be retrived via textsearch_next() irrespective of the linearity of the text. Once you're done using a configuration you must give back the allocted resources by calling textsearch_destroy(). Signed-off-by: Thomas Graf --- commit bf7ae763f13d767bd039703b3ab4f5954561df39 tree ab065819ea6e966aa3db4f1c5935c421dd689d2e parent fde09d4989b6c7b5183ffb3ec2076ff53dd6fa78 author Thomas Graf Fri, 27 May 2005 20:18:48 +0200 committer Thomas Graf Fri, 27 May 2005 20:18:48 +0200 include/linux/textsearch.h | 196 ++++++++++++++++++++++++++++++++++++ lib/Makefile | 2 lib/textsearch.c | 241 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 438 insertions(+), 1 deletion(-) Index: include/linux/textsearch.h =================================================================== --- /dev/null (tree:b032d0d440d93aac252e656bd41df32ff5461e3a) +++ ab065819ea6e966aa3db4f1c5935c421dd689d2e/include/linux/textsearch.h (mode:100644) @@ -0,0 +1,196 @@ +#ifndef __LINUX_TEXTSEARCH_H +#define __LINUX_TEXTSEARCH_H + +#ifdef __KERNEL__ + +#include +#include +#include +#include +#include + +struct ts_config; + +/** + * struct ts_state - textsearch state + * @offset: offset for next match + * @args: for persistant variables of get_text() + */ +struct ts_state +{ + int offset; + long args[6]; +}; + +/** + * struct ts_ops - textsearch operations + * @name: name of search algorithm + * @init: called upon initialization to prepare a search + * @find: does the actual matching on a prepared configuration + * @destroy: called upon destroyage of a configuration + * @owner: reference to algorithm module if existent + * @list: operations list we are on + */ +struct ts_ops +{ + const char *name; + struct ts_config * (*init)(const unsigned char *, size_t, int); + int (*find)(struct ts_config *, + struct ts_state *); + void (*destroy)(struct ts_config *); + unsigned char * (*get_pattern)(struct ts_config *); + unsigned int (*get_pattern_len)(struct ts_config *); + struct module *owner; + struct list_head list; +}; + +/** + * struct ts_config - textsearch configuration + * @ops: textsearch operations + * @get_text: callback to fetch text to search in + * @len: length of pattern + */ +struct ts_config +{ + struct ts_ops *ops; + + /** + * get_text - return next chunk of text + * @offset: Number of bytes consumed by the matcher + * @dst: destination buffer + * @conf: search configuration + * @state: search state + * + * Gets called repeatedly until 0 is returned.Must assign a pointer + * to the start of the next chunk of text to *dst and return the + * length of the chunk or 0 if at the end. offset==0 indicates + * a new search. May store/read persistant values in state->args[]. + */ + int (*get_text)(int offset, unsigned char **dst, + struct ts_config *conf, + struct ts_state *state); + + /** + * finish - called when the matching has been completed successful + * or not. + * @conf: search configuration + * @state: search state + */ + void (*finish)(struct ts_config *conf, + struct ts_state *state); +}; + +/** + * textsearch_next - continue search for a pattern in a text + * @conf: search configuration + * @state: search state + * + * Continues a search looking for more occurrences of the pattern. + * You must call textsearch_find() to search the first occurrence + * in order to reset the state. + * + * Returns the position of next occurance of the pattern or a + * negative number if no match was found. + */ +static inline int textsearch_next(struct ts_config *conf, + struct ts_state *state) +{ + int ret = conf->ops->find(conf, state); + + if (conf->finish) + conf->finish(conf, state); + + return ret; +} + +/** + * textsearch_find - search for a pattern in a text + * @conf: search configuration + * @state: search state + * + * Peforms the actual search on the prepared configuration. + * + * Returns the position of first occurrence of the pattern or a + * negative number if no match was found. + */ +static inline int textsearch_find(struct ts_config *conf, + struct ts_state *state) +{ + state->offset = 0; + return textsearch_next(conf, state); +} + +/** + * textsearch_destroy - destroy a textsearch configuration + * @conf: search configuration + * + * Releases all references of the configuration and frees + * up the memory. + */ +static inline void textsearch_destroy(struct ts_config *conf) +{ + if (conf->ops) { + if (conf->ops->destroy) + conf->ops->destroy(conf); + module_put(conf->ops->owner); + } + + kfree(conf); +} + +/** + * textsearch_get_pattern - return pattern of a textsearch configuration + * @conf: textsearch configuration + */ +static inline unsigned char *textsearch_get_pattern(struct ts_config *conf) +{ + return conf->ops->get_pattern(conf); +} + +/** + * textsearch_get_pattern_len - return pattern length of a textsearch configuration + * @conf: textsearch configuration + */ +static inline unsigned int textsearch_get_pattern_len(struct ts_config *conf) +{ + return conf->ops->get_pattern_len(conf); +} + +/** + * alloc_ts_config - allocate a textsearch configuration + * @payload: size of additional module specific data required + * @gfp_mask: allocation mask + * + * Returns a empty textsearch configuration or a ERR_PTR(). + */ +static inline struct ts_config *alloc_ts_config(size_t payload, int gfp_mask) +{ + struct ts_config *conf; + + conf = kmalloc(sizeof(*conf) + payload, gfp_mask); + if (conf == NULL) + return ERR_PTR(-ENOMEM); + + memset(conf, 0, sizeof(*conf) + payload); + return conf; +} + +/** + * ts_config_priv - returns private part of a textsearch configuration + * @conf: textsearch configuration + */ +static inline void *ts_config_priv(struct ts_config *conf) +{ + return ((unsigned char *) conf + sizeof(struct ts_config)); +} + +extern int textsearch_register(struct ts_ops *); +extern int textsearch_unregister(struct ts_ops *); +extern struct ts_config *textsearch_prepare(const char *, const unsigned char *, + size_t, int, int); +extern int textsearch_find_continuous(struct ts_config *, struct ts_state *, + const unsigned char *, size_t); + +#endif /* __KERNEL__ */ + +#endif Index: lib/Makefile =================================================================== --- b032d0d440d93aac252e656bd41df32ff5461e3a/lib/Makefile (mode:100644) +++ ab065819ea6e966aa3db4f1c5935c421dd689d2e/lib/Makefile (mode:100644) @@ -6,7 +6,7 @@ bust_spinlocks.o rbtree.o radix-tree.o dump_stack.o \ kobject.o kref.o idr.o div64.o int_sqrt.o \ bitmap.o extable.o kobject_uevent.o prio_tree.o sha1.o \ - halfmd4.o + halfmd4.o textsearch.o obj-y += sort.o parser.o Index: lib/textsearch.c =================================================================== --- /dev/null (tree:b032d0d440d93aac252e656bd41df32ff5461e3a) +++ ab065819ea6e966aa3db4f1c5935c421dd689d2e/lib/textsearch.c (mode:100644) @@ -0,0 +1,241 @@ +/* + * lib/textsearch.c Generic text search interface + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + * + * ========================================================================== + * + * The textsearch infrastructure provides text searching facitilies for both + * linear and non-linear data. + * + * Before a textsearch can be performed, a configuration must be created + * by calling textsearch_prepare() specyfing the searching algorithm and + * the pattern to match. The returned configuration may then be used for + * an arbitary amount of times and even in parallel as long as you + * provide a separate struct ts_state variable for every instance. + * + * The actual search is performed by either calling textsearch_find_- + * continuous() for linear text or by providing an own get_text() + * implementation and calling textsearch_find(). Both functions will + * returns the position of the first matching occurrence of the patern. + * Subsequent matches may be retrived via textsearch_next() irrespective + * of the linearity of the text. + * + * Once you're done using a configuration you must give back the + * allocted resources by calling textsearch_destroy(). + * + * Example: + * int pos; + * struct ts_config *conf; + * struct ts_state state; + * conar char *pattern = "chicken"; + * const char *example = "We dance the funky chicken"; + * + * conf = textsearch_prepare("kmp", pattern, strlen(pattern), GFP_KERNEL, 1); + * if (IS_ERR(conf)) { + * err = PTR_ERR(conf); + * goto errout; + * } + * + * pos = textsearch_find_continuous(conf, &state, example, strlen(example)); + * if (pos >= 0) + * panic("Oh my god, dancing chickens at %d\n", pos); + * + * textsearch_destroy(conf); + * + * ========================================================================== + */ + +#include +#include +#include +#include +#include +#include + +static LIST_HEAD(ts_ops); +static DEFINE_RWLOCK(ts_mod_lock); + +static inline struct ts_ops *lookup_ts_algo(const char *name) +{ + struct ts_ops *o; + + read_lock(&ts_mod_lock); + list_for_each_entry(o, &ts_ops, list) { + if (!strcmp(name, o->name)) { + if (!try_module_get(o->owner)) + o = NULL; + read_unlock(&ts_mod_lock); + return o; + } + } + read_unlock(&ts_mod_lock); + + return NULL; +} + +/** + * textsearch_register - register a textsearch module + * @ops: operations lookup table + * + * This function must be called by textsearch modules to announce + * their presence. The given @ops must have %name set to a unique + * identifier and the callbacks find() and init() must be implemented. + * + * Returns -EEXISTS if another module has already registered with + * same name. + */ +int textsearch_register(struct ts_ops *ops) +{ + int err = -EEXIST; + struct ts_ops *o; + + if (ops->name == NULL || ops->find == NULL || ops->init == NULL || + ops->get_pattern == NULL || ops->get_pattern_len == NULL) + return -EINVAL; + + write_lock(&ts_mod_lock); + list_for_each_entry(o, &ts_ops, list) + if (!strcmp(ops->name, o->name)) + goto errout; + + list_add_tail(&ops->list, &ts_ops); + err = 0; +errout: + write_unlock(&ts_mod_lock); + return err; +} + +/** + * textsearch_unregister - unregister a textsearch module + * @ops: operations lookup table + * + * This function must be called by textsearch modules to announce + * their disappearance for examples when the module gets unloaded. + * The @ops parameter must be the same as the one during the + * registration. + * + * Returns -ENOENT if no matching textsearch registration was found. + */ +int textsearch_unregister(struct ts_ops *ops) +{ + int err = 0; + struct ts_ops *o; + + write_lock(&ts_mod_lock); + list_for_each_entry(o, &ts_ops, list) { + if (o == ops) { + list_del(&o->list); + goto out; + } + } + + err = -ENOENT; +out: + write_unlock(&ts_mod_lock); + return err; +} + +static inline int get_linear_text(int offset, unsigned char **text, + struct ts_config *conf, + struct ts_state *state) +{ + unsigned char *string = (unsigned char *) state->args[0]; + size_t len = state->args[1]; + + if (offset < len) { + *text = string + offset; + return len - offset; + } else + return 0; +} + +/** + * textsearch_find_continuous - search a pattern in continuous/linear text + * @conf: search configuration + * @state: search state + * @text: text to search in + * @len: length of text + * + * A simplified version of textsearch_find() for continuous/linear text. + * Call textsearch_next() to retrieve subsequent matches. + * + * Returns the position of first occurrence of the pattern or a + * negative number if no match was found. + */ +int textsearch_find_continuous(struct ts_config *conf, struct ts_state *state, + const unsigned char *text, size_t len) +{ + conf->get_text = get_linear_text; + state->args[0] = (long) text; + state->args[1] = len; + + return textsearch_find(conf, state); +} + +/** + * textsearch_prepare - Prepare a text search + * @algo: name of search algorithm + * @pattern: pattern data + * @len: length of pattern + * @gfp_mask: allocation mask + * @autoload: bool indicating whether to autoload modules + * + * Looks up the search algorithm module and creates a new textsearch + * configuration for the specified pattern. Upon completion all + * necessary refcnts are held and the configuration must be put back + * using textsearch_put() after usage. + * + * Note: The format of the pattern may not be compatible between + * the various search algorithms. + * + * Returns a new textsearch configuration according to the specified + * parameters or a ERR_PTR(). + */ +struct ts_config *textsearch_prepare(const char *algo, + const unsigned char *pattern, size_t len, + int gfp_mask, int autoload) +{ + int err = -ENOENT; + struct ts_config *conf; + struct ts_ops *ops; + + ops = lookup_ts_algo(algo); +#ifdef CONFIG_KMOD + /* Why not always autoload you may ask. Some users may be + * in a situation where requesting a module may deadlock, + * especially when the module is located on a NFS mount. */ + if (ops == NULL && autoload) { + request_module("ts_%s", algo); + ops = lookup_ts_algo(algo); + } +#endif + + if (ops == NULL) + goto errout; + + conf = ops->init(pattern, len, gfp_mask); + if (IS_ERR(conf)) { + err = PTR_ERR(conf); + goto errout; + } + + conf->ops = ops; + return conf; + +errout: + if (ops) + module_put(ops->owner); + + return ERR_PTR(err); +} + +EXPORT_SYMBOL(textsearch_register); +EXPORT_SYMBOL(textsearch_unregister); +EXPORT_SYMBOL(textsearch_prepare); +EXPORT_SYMBOL(textsearch_find_continuous); From tgraf@suug.ch Fri May 27 15:49:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 15:49:14 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RMn5Xq019854 for ; Fri, 27 May 2005 15:49:05 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id CEB111C0ED; Sat, 28 May 2005 00:48:37 +0200 (CEST) Date: Sat, 28 May 2005 00:48:37 +0200 From: Thomas Graf To: netdev@oss.sgi.com Cc: Jamal Hadi Salim Subject: [PATCH 3/5] [LIB] Naive regular expression string-matching algorithm Message-ID: <20050527224837.GJ15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527224725.GG15391@postel.suug.ch> X-archive-position: 1807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 12554 Lines: 377 Signed-off-by: Thomas Graf --- commit 81553cdea2a7ff762cb44aeced743d3a77efd2d7 tree 266c4ad512e5ae71bd7cd88c94bfb18fb2f761d6 parent 5b70ca8eab4c7d7ef884582d9713cdbffa0f4cd4 author Thomas Graf Fri, 27 May 2005 23:44:24 +0200 committer Thomas Graf Fri, 27 May 2005 23:44:24 +0200 include/linux/textsearch_regexp.h | 47 ++++++ lib/Kconfig | 9 + lib/Makefile | 1 lib/ts_regexp.c | 272 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 329 insertions(+) Index: include/linux/textsearch_regexp.h =================================================================== --- /dev/null (tree:4d90ca82120da7b308b9a6bf11a1069473ca5d30) +++ 266c4ad512e5ae71bd7cd88c94bfb18fb2f761d6/include/linux/textsearch_regexp.h (mode:100644) @@ -0,0 +1,47 @@ +#ifndef __LINUX_TEXTSEARCH_REGEXP_H +#define __LINUX_TEXTSEARCH_REGEXP_H + +#include + +enum { + TS_RE_SPECIFIC, /* specific character */ + TS_RE_WILDCARD, /* any character */ + TS_RE_DIGIT, /* isdigit() */ + TS_RE_XDIGIT, /* isxdigit() */ + TS_RE_PRINT, /* isprint() */ + TS_RE_ALPHA, /* isalpha() */ + TS_RE_ALNUM, /* isalnum() */ + TS_RE_ASCII, /* isascii() */ + TS_RE_CNTRL, /* iscntrl() */ + TS_RE_GRAPH, /* isgraph() */ + TS_RE_LOWER, /* islower() */ + TS_RE_UPPER, /* isupper() */ + TS_RE_PUNCT, /* ispunct() */ + TS_RE_SPACE, /* isspace() */ + __TS_RE_TYPE_MAX, +}; +#define TS_RE_TYPE_MAX (__TS_RE_TYPE_MAX - 1) + +enum { + TS_RE_SINGLE, /* 1 occurrence */ + TS_RE_PERHAPS, /* 1 or 0 occurrence */ + TS_RE_ANY, /* 0..n occurrences */ + TS_RE_MULTI, /* 1..n occurrences */ + __TS_RE_RECUR_MAX, +}; +#define TS_RE_RECUR_MAX (__TS_RE_RECUR_MAX - 1) + +/** + * struct ts_regexp_token - regular expression token + * @type: type of token + * @recur: number of recurrences + * @value: character value for TS_RE_SPECIFIC + */ +struct ts_regexp_token +{ + __u16 type; + __u8 recur; + __u8 value; +}; + +#endif Index: lib/Kconfig =================================================================== --- 4d90ca82120da7b308b9a6bf11a1069473ca5d30/lib/Kconfig (mode:100644) +++ 266c4ad512e5ae71bd7cd88c94bfb18fb2f761d6/lib/Kconfig (mode:100644) @@ -68,6 +68,15 @@ To compile this code as a module, choose M here: the module will be called ts_kmp. +config TEXTSEARCH_REGEXP + tristate "Regular Expression" + help + Say Y here if you want to be able to search text using a + naive and limited regular expression textsearch algorithm. + + To compile this code as a module, choose M here: the + module will be called ts_regexp. + endmenu endmenu Index: lib/Makefile =================================================================== --- 4d90ca82120da7b308b9a6bf11a1069473ca5d30/lib/Makefile (mode:100644) +++ 266c4ad512e5ae71bd7cd88c94bfb18fb2f761d6/lib/Makefile (mode:100644) @@ -34,6 +34,7 @@ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/ obj-$(CONFIG_TEXTSEARCH_KMP) += ts_kmp.o +obj-$(CONFIG_TEXTSEARCH_REGEXP) += ts_regexp.o hostprogs-y := gen_crc32table clean-files := crc32table.h Index: lib/ts_regexp.c =================================================================== --- /dev/null (tree:4d90ca82120da7b308b9a6bf11a1069473ca5d30) +++ 266c4ad512e5ae71bd7cd88c94bfb18fb2f761d6/lib/ts_regexp.c (mode:100644) @@ -0,0 +1,272 @@ +/* + * lib/ts_regexp.c Naive and very limited regular expression + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include +#include +#include + +struct ts_regexp +{ + int ntokens; + struct ts_regexp_token tokens[0]; +}; + +/* other values derived from ctype.h */ +#define _A 0x100 /* ascii */ +#define _W 0x200 /* wildcard */ + +/* Map to _ctype flags and some magic numbers */ +static u16 token_map[TS_RE_TYPE_MAX+1] = { + [TS_RE_SPECIFIC] = 0, + [TS_RE_WILDCARD] = _W, + [TS_RE_CNTRL] = _C, + [TS_RE_LOWER] = _L, + [TS_RE_UPPER] = _U, + [TS_RE_PUNCT] = _P, + [TS_RE_SPACE] = _S, + [TS_RE_DIGIT] = _D, + [TS_RE_XDIGIT] = _D | _X, + [TS_RE_ALPHA] = _U | _L, + [TS_RE_ALNUM] = _U | _L | _D, + [TS_RE_PRINT] = _P | _U | _L | _D | _SP, + [TS_RE_GRAPH] = _P | _U | _L | _D, + [TS_RE_ASCII] = _A, +}; + +static u16 token_lookup_tbl[256] = { +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 0- 3 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 4- 7 */ +_W|_A|_C, _W|_A|_C|_S, _W|_A|_C|_S, _W|_A|_C|_S, /* 8- 11 */ +_W|_A|_C|_S, _W|_A|_C|_S, _W|_A|_C, _W|_A|_C, /* 12- 15 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 16- 19 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 20- 23 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 24- 27 */ +_W|_A|_C, _W|_A|_C, _W|_A|_C, _W|_A|_C, /* 28- 31 */ +_W|_A|_S|_SP, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 32- 35 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 36- 39 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 40- 43 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 44- 47 */ +_W|_A|_D, _W|_A|_D, _W|_A|_D, _W|_A|_D, /* 48- 51 */ +_W|_A|_D, _W|_A|_D, _W|_A|_D, _W|_A|_D, /* 52- 55 */ +_W|_A|_D, _W|_A|_D, _W|_A|_P, _W|_A|_P, /* 56- 59 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 60- 63 */ +_W|_A|_P, _W|_A|_U|_X, _W|_A|_U|_X, _W|_A|_U|_X, /* 64- 67 */ +_W|_A|_U|_X, _W|_A|_U|_X, _W|_A|_U|_X, _W|_A|_U, /* 68- 71 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_U, /* 72- 75 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_U, /* 76- 79 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_U, /* 80- 83 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_U, /* 84- 87 */ +_W|_A|_U, _W|_A|_U, _W|_A|_U, _W|_A|_P, /* 88- 91 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_P, /* 92- 95 */ +_W|_A|_P, _W|_A|_L|_X, _W|_A|_L|_X, _W|_A|_L|_X, /* 96- 99 */ +_W|_A|_L|_X, _W|_A|_L|_X, _W|_A|_L|_X, _W|_A|_L, /* 100-103 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_L, /* 104-107 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_L, /* 108-111 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_L, /* 112-115 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_L, /* 116-119 */ +_W|_A|_L, _W|_A|_L, _W|_A|_L, _W|_A|_P, /* 120-123 */ +_W|_A|_P, _W|_A|_P, _W|_A|_P, _W|_A|_C, /* 124-127 */ +_W, _W, _W, _W, /* 128-131 */ +_W, _W, _W, _W, /* 132-135 */ +_W, _W, _W, _W, /* 136-139 */ +_W, _W, _W, _W, /* 140-143 */ +_W, _W, _W, _W, /* 144-147 */ +_W, _W, _W, _W, /* 148-151 */ +_W, _W, _W, _W, /* 152-155 */ +_W, _W, _W, _W, /* 156-159 */ +_W|_S|_SP, _W|_P, _W|_P, _W|_P, /* 160-163 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 164-167 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 168-171 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 172-175 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 176-179 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 180-183 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 184-187 */ +_W|_P, _W|_P, _W|_P, _W|_P, /* 188-191 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 192-195 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 196-199 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 200-203 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 204-207 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 208-211 */ +_W|_U, _W|_U, _W|_U, _W|_P, /* 212-215 */ +_W|_U, _W|_U, _W|_U, _W|_U, /* 216-219 */ +_W|_U, _W|_U, _W|_U, _W|_L, /* 220-223 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 224-227 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 228-231 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 232-235 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 236-239 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 240-243 */ +_W|_L, _W|_L, _W|_L, _W|_P, /* 244-247 */ +_W|_L, _W|_L, _W|_L, _W|_L, /* 248-251 */ +_W|_L, _W|_L, _W|_L, _W|_L}; /* 252-255 */ + +static inline int match_token(struct ts_regexp_token *t, u8 d) +{ + if (t->type) + return (token_lookup_tbl[d] & t->type) != 0; + else + return t->value == d; +} + +static int regexp_find(struct ts_config *conf, struct ts_state *state) +{ + struct ts_regexp *regexp = ts_config_priv(conf); + int i, q, consumed = state->offset; + int match_start = state->offset; + struct ts_regexp_token *t = NULL, *next; + size_t text_len = 0; + unsigned char *text; + +#define GET_TEXT() \ + ({ i = 0; conf->get_text(consumed, &text, conf, state); }) + +#define end_of_text() (i >= text_len && !GET_TEXT()) +#define more_text() (i < text_len || GET_TEXT()) + +#define NEXT_CHAR() do { i++; consumed++; } while (0) + + for (i = 0, q = 0; q < regexp->ntokens; q++) { + t = ®exp->tokens[q]; + + if (likely(q < (regexp->ntokens - 1))) + next = ®exp->tokens[q+1]; + else + next = NULL; + + switch (t->recur) { + case TS_RE_SINGLE: + if (unlikely(end_of_text())) + goto no_match; + + if (!match_token(t, text[i])) + goto no_match; + break; + + case TS_RE_PERHAPS: + if (likely(more_text())) + if (match_token(t, text[i])) + break; + continue; + + case TS_RE_MULTI: + if (unlikely(end_of_text())) + goto no_match; + + if (!match_token(t, text[i])) + goto no_match; + + NEXT_CHAR(); + /* fall through */ + + case TS_RE_ANY: + if (next == NULL) + goto found_match; + + if (likely(more_text())) { + while (!match_token(next, text[i])) { + if (!match_token(t, text[i])) + goto no_match; + NEXT_CHAR(); + if (unlikely(end_of_text())) + goto no_match; + } + } + continue; + } + + NEXT_CHAR(); + } + + if (q >= (regexp->ntokens - 1)) + goto found_match; + +no_match: + return -1; + +found_match: + state->offset = consumed + i + 1; + return match_start; +} + +static struct ts_config *regexp_init(const unsigned char *pattern, size_t len, + int gfp_mask) +{ + int i, err = -EINVAL; + struct ts_config *conf; + struct ts_regexp *regexp; + struct ts_regexp_token *tokens = (struct ts_regexp_token *) pattern; + + if (len % sizeof(struct ts_regexp_token)) + goto errout; + + for (i = 0; i < len / sizeof(struct ts_regexp_token); i++) { + struct ts_regexp_token *t = &tokens[i]; + + if (t->type > TS_RE_TYPE_MAX || + t->type > TS_RE_RECUR_MAX) + goto errout; + + t->type = token_map[t->type]; + } + + conf = alloc_ts_config(len, gfp_mask); + if (IS_ERR(conf)) + return conf; + + regexp = ts_config_priv(conf); + regexp->ntokens = len / sizeof(struct ts_regexp_token); + memcpy(regexp->tokens, pattern, len); + + return conf; + +errout: + return ERR_PTR(err); +} + +static unsigned char *regexp_get_pattern(struct ts_config *conf) +{ + struct ts_regexp *regexp = ts_config_priv(conf); + return (unsigned char *) regexp->tokens; +} + +static unsigned int regexp_get_pattern_len(struct ts_config *conf) +{ + struct ts_regexp *regexp = ts_config_priv(conf); + return regexp->ntokens * sizeof(struct ts_regexp_token); +} + +static struct ts_ops regexp_ops = { + .name = "regexp", + .find = regexp_find, + .init = regexp_init, + .get_pattern = regexp_get_pattern, + .get_pattern_len = regexp_get_pattern_len, + .owner = THIS_MODULE, + .list = LIST_HEAD_INIT(regexp_ops.list) +}; + +static int __init init_regexp(void) +{ + return textsearch_register(®exp_ops); +} + +static void __exit exit_regexp(void) +{ + textsearch_unregister(®exp_ops); +} + +MODULE_LICENSE("GPL"); + +module_init(init_regexp); +module_exit(exit_regexp); From tgraf@suug.ch Fri May 27 15:49:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 15:49:32 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RMnPXq020173 for ; Fri, 27 May 2005 15:49:26 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 68B681C0EB; Sat, 28 May 2005 00:48:58 +0200 (CEST) Date: Sat, 28 May 2005 00:48:58 +0200 From: Thomas Graf To: netdev@oss.sgi.com Cc: Jamal Hadi Salim Subject: [PATCH 4/5] [NET] Add skb_find_text() to search for a text pattern in skbs Message-ID: <20050527224858.GK15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527224725.GG15391@postel.suug.ch> X-archive-position: 1808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4075 Lines: 137 Adds the function skb_find_text() to search for text patterns in both, linear and non-linear skbs. Signed-off-by: Thomas Graf --- commit 4fdcfba0bf99efed709bc8ebaeda0d5ed7e9cc67 tree 13ce1cd98014267f2a353b96e813c1e70bbe9c3b parent 81553cdea2a7ff762cb44aeced743d3a77efd2d7 author Thomas Graf Fri, 27 May 2005 23:44:50 +0200 committer Thomas Graf Fri, 27 May 2005 23:44:50 +0200 include/linux/skbuff.h | 4 ++ net/core/skbuff.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 87 insertions(+) Index: include/linux/skbuff.h =================================================================== --- 266c4ad512e5ae71bd7cd88c94bfb18fb2f761d6/include/linux/skbuff.h (mode:100644) +++ 13ce1cd98014267f2a353b96e813c1e70bbe9c3b/include/linux/skbuff.h (mode:100644) @@ -28,6 +28,7 @@ #include #include #include +#include #define HAVE_ALLOC_SKB /* For the drivers to know */ #define HAVE_ALIGNABLE_SKB /* Ditto 8) */ @@ -1187,6 +1188,9 @@ extern void skb_split(struct sk_buff *skb, struct sk_buff *skb1, const u32 len); +extern int skb_find_text(struct sk_buff *skb, int from, int to, + struct ts_config *config, struct ts_state *state); + static inline void *skb_header_pointer(const struct sk_buff *skb, int offset, int len, void *buffer) { Index: net/core/skbuff.c =================================================================== --- 266c4ad512e5ae71bd7cd88c94bfb18fb2f761d6/net/core/skbuff.c (mode:100644) +++ 13ce1cd98014267f2a353b96e813c1e70bbe9c3b/net/core/skbuff.c (mode:100644) @@ -1506,6 +1506,88 @@ skb_split_no_header(skb, skb1, len, pos); } +static int get_skb_text(int offset, unsigned char **text, + struct ts_config *conf, struct ts_state *state) +{ + /* args[0]: lower limit + * args[1]: upper limit + * args[2]: skb + * args[3]: fragment index + * args[4]: current fragment data buffer + * args[5]: octets consumed up to previous fragment */ + int from = state->args[0], to = state->args[1]; + struct sk_buff *skb = (struct sk_buff *) state->args[2]; + int limit = min_t(int, skb_headlen(skb), to); + int real_offset = offset + from; + skb_frag_t *f; + + if (!skb_is_nonlinear(skb)) { + if (real_offset < limit) { +linear: + *text = skb->data + real_offset; + return limit - real_offset; + } + + return 0; + } + + if (real_offset < limit) + goto linear; + +next_fragment: + f = &skb_shinfo(skb)->frags[state->args[3]]; + limit = min_t(int, f->size + state->args[5], to); + + if (!state->args[4]) + state->args[4] = (long) kmap_skb_frag(f); + + if (real_offset < limit) { + *text = (unsigned char *) state->args[4] + f->page_offset + + (real_offset - (int) state->args[5]); + return limit - real_offset; + } + + kunmap_skb_frag((void *) state->args[4]); + state->args[3]++; + state->args[4] = (long) NULL; + state->args[5] += f->size; + + if (state->args[3] >= skb_shinfo(skb)->nr_frags) + return 0; + + goto next_fragment; +} + +static void get_skb_text_finish(struct ts_config *conf, struct ts_state *state) +{ + if (state->args[4]) + kunmap_skb_frag((void *) state->args[4]); +} + +/** + * skb_find_text - Find a text pattern in skb data + * @skb: the buffer to look in + * @from: search offset + * @to: search limit + * @config: textsearch configuration + * @state: empty textsearch state variable + */ +int skb_find_text(struct sk_buff *skb, int from, int to, + struct ts_config *config, struct ts_state *state) +{ + config->get_text = get_skb_text; + config->finish = get_skb_text_finish; + state->args[0] = from; + state->args[1] = to; + state->args[2] = (long) skb; + state->args[3] = 0; + state->args[4] = 0; + state->args[5] = skb_headlen(skb); + + return textsearch_find(config, state); +} + + void __init skb_init(void) { skbuff_head_cache = kmem_cache_create("skbuff_head_cache", @@ -1544,3 +1626,4 @@ EXPORT_SYMBOL(skb_unlink); EXPORT_SYMBOL(skb_append); EXPORT_SYMBOL(skb_split); +EXPORT_SYMBOL(skb_find_text); From tgraf@suug.ch Fri May 27 15:49:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 15:49:54 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RMnkXq020342 for ; Fri, 27 May 2005 15:49:46 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id CA3751C0ED; Sat, 28 May 2005 00:49:18 +0200 (CEST) Date: Sat, 28 May 2005 00:49:18 +0200 From: Thomas Graf To: netdev@oss.sgi.com Cc: Jamal Hadi Salim Subject: [PATCH 5/5] [PKT_SCHED] textsearch ematch Message-ID: <20050527224918.GL15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527224725.GG15391@postel.suug.ch> X-archive-position: 1809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 6688 Lines: 231 Signed-off-by: Thomas Graf --- commit 5d28d54b48451e7833295be68b7e4b6fcc2b5375 tree cc252d153b4b21f347aab71bbfe04c0bf2a3a8a2 parent 4fdcfba0bf99efed709bc8ebaeda0d5ed7e9cc67 author Thomas Graf Fri, 27 May 2005 23:45:15 +0200 committer Thomas Graf Fri, 27 May 2005 23:45:15 +0200 include/linux/pkt_cls.h | 1 include/linux/tc_ematch/tc_em_text.h | 19 ++++ net/sched/Kconfig | 11 ++ net/sched/Makefile | 1 net/sched/em_text.c | 142 +++++++++++++++++++++++++++++++++++ 5 files changed, 174 insertions(+) Index: include/linux/pkt_cls.h =================================================================== --- 13ce1cd98014267f2a353b96e813c1e70bbe9c3b/include/linux/pkt_cls.h (mode:100644) +++ cc252d153b4b21f347aab71bbfe04c0bf2a3a8a2/include/linux/pkt_cls.h (mode:100644) @@ -408,6 +408,7 @@ TCF_EM_NBYTE, TCF_EM_U32, TCF_EM_META, + TCF_EM_TEXT, __TCF_EM_MAX }; Index: include/linux/tc_ematch/tc_em_text.h =================================================================== --- /dev/null (tree:13ce1cd98014267f2a353b96e813c1e70bbe9c3b) +++ cc252d153b4b21f347aab71bbfe04c0bf2a3a8a2/include/linux/tc_ematch/tc_em_text.h (mode:100644) @@ -0,0 +1,19 @@ +#ifndef __LINUX_TC_EM_TEXT_H +#define __LINUX_TC_EM_TEXT_H + +#include + +#define TC_EM_TEXT_ALGOSIZ 16 + +struct tcf_em_text +{ + char algo[TC_EM_TEXT_ALGOSIZ]; + __u16 from_offset; + __u16 to_offset; + __u16 pattern_len; + __u8 from_layer:4; + __u8 to_layer:4; + __u8 pad; +}; + +#endif Index: net/sched/Kconfig =================================================================== --- 13ce1cd98014267f2a353b96e813c1e70bbe9c3b/net/sched/Kconfig (mode:100644) +++ cc252d153b4b21f347aab71bbfe04c0bf2a3a8a2/net/sched/Kconfig (mode:100644) @@ -449,6 +449,17 @@ To compile this code as a module, choose M here: the module will be called em_meta. +config NET_EMATCH_TEXT + tristate "Textsearch" + depends on NET_EMATCH + ---help--- + Say Y here if you want to be ablt to classify packets based on + textsearch comparisons. Please select the appropriate textsearch + algorithms in the Library section. + + To compile this code as a module, choose M here: the + module will be called em_text. + config NET_CLS_ACT bool "Packet ACTION" depends on EXPERIMENTAL && NET_CLS && NET_QOS Index: net/sched/Makefile =================================================================== --- 13ce1cd98014267f2a353b96e813c1e70bbe9c3b/net/sched/Makefile (mode:100644) +++ cc252d153b4b21f347aab71bbfe04c0bf2a3a8a2/net/sched/Makefile (mode:100644) @@ -40,3 +40,4 @@ obj-$(CONFIG_NET_EMATCH_NBYTE) += em_nbyte.o obj-$(CONFIG_NET_EMATCH_U32) += em_u32.o obj-$(CONFIG_NET_EMATCH_META) += em_meta.o +obj-$(CONFIG_NET_EMATCH_TEXT) += em_text.o Index: net/sched/em_text.c =================================================================== --- /dev/null (tree:13ce1cd98014267f2a353b96e813c1e70bbe9c3b) +++ cc252d153b4b21f347aab71bbfe04c0bf2a3a8a2/net/sched/em_text.c (mode:100644) @@ -0,0 +1,142 @@ +/* + * net/sched/em_text.c Textsearch ematch + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Thomas Graf + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +struct text_match +{ + u16 from_offset; + u16 to_offset; + u8 from_layer; + u8 to_layer; + struct ts_config *config; +}; + +static int em_text_match(struct sk_buff *skb, struct tcf_ematch *m, + struct tcf_pkt_info *info) +{ + struct text_match *tm = (struct text_match *) m->data; + int from, to; + struct ts_state state; + + from = tcf_get_base_ptr(skb, tm->from_layer) - skb->data; + from += tm->from_offset; + to = tcf_get_base_ptr(skb, tm->to_layer) - skb->data; + to += tm->to_offset; + + if (skb_find_text(skb, from, to, tm->config, &state) < 0) + return 0; + + return 1; +} + +static int em_text_change(struct tcf_proto *tp, void *data, int len, + struct tcf_ematch *m) +{ + struct text_match *tm; + struct tcf_em_text *conf = data; + struct ts_config *ts_conf; + + if (len < sizeof(*conf) || + len < (sizeof(*conf) + conf->pattern_len)) + return -EINVAL; + + if (conf->from_layer > conf->to_layer) + return -EINVAL; + + if (conf->from_layer == conf->to_layer && + conf->from_offset > conf->to_offset) + return -EINVAL; + + ts_conf = textsearch_prepare(conf->algo, (char *) conf + sizeof(*conf), + conf->pattern_len, GFP_KERNEL, 1); + if (IS_ERR(ts_conf)) + return PTR_ERR(ts_conf); + + tm = kmalloc(sizeof(*tm), GFP_KERNEL); + if (tm == NULL) { + textsearch_destroy(ts_conf); + return -ENOBUFS; + } + + tm->from_offset = conf->from_offset; + tm->to_offset = conf->to_offset; + tm->from_layer = conf->from_layer; + tm->to_layer = conf->to_layer; + tm->config = ts_conf; + + m->datalen = sizeof(*tm); + m->data = (unsigned long) tm; + + return 0; +} + +static void em_text_destroy(struct tcf_proto *tp, struct tcf_ematch *m) +{ + struct text_match *tm = (struct text_match *) m->data; + textsearch_destroy(tm->config); +} + +static int em_text_dump(struct sk_buff *skb, struct tcf_ematch *m) +{ + struct text_match *tm = (struct text_match *) m->data; + struct tcf_em_text conf; + + strncpy(conf.algo, tm->config->ops->name, sizeof(conf.algo) - 1); + conf.from_offset = tm->from_offset; + conf.to_offset = tm->to_offset; + conf.from_layer = tm->from_layer; + conf.to_layer = tm->to_layer; + conf.pattern_len = textsearch_get_pattern_len(tm->config); + conf.pad = 0; + + RTA_PUT_NOHDR(skb, sizeof(conf), &conf); + RTA_PUT_NOHDR(skb, conf.pattern_len, + textsearch_get_pattern(tm->config)); + return 0; + +rtattr_failure: + return -1; +} + +static struct tcf_ematch_ops em_text_ops = { + .kind = TCF_EM_TEXT, + .change = em_text_change, + .match = em_text_match, + .destroy = em_text_destroy, + .dump = em_text_dump, + .owner = THIS_MODULE, + .link = LIST_HEAD_INIT(em_text_ops.link) +}; + +static int __init init_em_text(void) +{ + return tcf_em_register(&em_text_ops); +} + +static void __exit exit_em_text(void) +{ + tcf_em_unregister(&em_text_ops); +} + +MODULE_LICENSE("GPL"); + +module_init(init_em_text); +module_exit(exit_em_text); From akpm@osdl.org Fri May 27 16:25:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 16:25:44 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RNPcXq027352 for ; Fri, 27 May 2005 16:25:39 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4RNOdjA016699 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 16:24:42 -0700 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4RNOcOO015952; Fri, 27 May 2005 16:24:39 -0700 Date: Fri, 27 May 2005 16:25:28 -0700 From: Andrew Morton To: Christoph Lameter Cc: ganesh.venkatesan@gmail.com, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shai@scalex86.org Subject: Re: [PATCH] e1000: NUMA aware allocation of descriptors V2 Message-Id: <20050527162528.2ba5113e.akpm@osdl.org> In-Reply-To: References: <20050517190343.2e57fdd7.akpm@osdl.org> <20050517.195703.104034854.davem@davemloft.net> <20050517215845.2f87be2f.akpm@osdl.org> <5fc59ff305051808558f1ce59@mail.gmail.com> <20050518134250.3ee2703f.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1810 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 536 Lines: 13 Christoph Lameter wrote: > > NUMA awareness for the e1000 driver. Allocate tx and rx descriptors > on the node of the device. > > It is safe to replace vmalloc by kmalloc node since only the descriptors > are allocated in a NUMA aware way. These will not be so large that the > use of vmalloc becomes necesssary. Really? That's probably OK with the default number of tx descriptors, but that number can be made arbitrarily large with a module parameter. Could you please work this with the e1000 developers? From herbert@gondor.apana.org.au Fri May 27 16:40:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 16:40:23 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4RNeGXq028216 for ; Fri, 27 May 2005 16:40:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DboOj-0005if-00; Sat, 28 May 2005 09:37:49 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DboOb-0002Pl-00; Sat, 28 May 2005 09:37:41 +1000 Date: Sat, 28 May 2005 09:37:41 +1000 To: "David S. Miller" , jamal , Patrick McHardy , netdev@oss.sgi.com Subject: [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification Message-ID: <20050527233741.GA9157@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 5731 Lines: 181 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This is the patch that I reverted due to Jamal's objection to it. I still think it's the right way to go which is why I'm submitting it. As it is, all the xfrm event notifications sent by the kernel except the ones for SA/policy deletion are symmetric in the sense that if they were sent straight back to the kernel in that same form they would be accepted and perform the same action that triggered the initial events. As far as I know this is true for non-xfrm netlink notifications as well, including deletion events. What is different between xfrm and and other netlink notifications is that requests such as route/address deletion use the same format as route/address addition, while the SA/policy deletion format is certainly not the same as SA/policy addition. Based on these observations, I think we should change the IPsec deletion notifications to use the same format as the IPsec deletion requests that triggered them in the first place. Of course, we can do this in a way without losing information such as the SA/policy that was actually deleted. The objection to this change is that it creates an inconsistency between xfrm deletion and non-xfrm deletion event formats. However, my view is that this is an inconsistency that is already present between xfrm deleteion and non-xfrm deletion request formats. By doing this we in fact improve the consistency in the sense that all netlink event notifications, xfrm or non-xfrm are now of the same format as their corresponding requests. One thing to note is that whatever we decide here we'll probably be stuck with it for a long time since this is part of the xfrm netlink ABI. Here is the original changelog: This patch changes the format of the XFRM_MSG_DELSA and XFRM_MSG_DELPOLICY notification so that the main message sent is of the same format as that received by the kernel if the original message was via netlink. This also means that we won't lose the byid information carried in km_event. Since this user interface is introduced by Jamal's patch we can still afford to change it. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="p1.patch" diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h --- a/include/linux/xfrm.h +++ b/include/linux/xfrm.h @@ -174,6 +174,8 @@ enum xfrm_attr_type_t { XFRMA_ALG_COMP, /* struct xfrm_algo */ XFRMA_ENCAP, /* struct xfrm_algo + struct xfrm_encap_tmpl */ XFRMA_TMPL, /* 1 or more struct xfrm_user_tmpl */ + XFRMA_SA, + XFRMA_POLICY, __XFRMA_MAX #define XFRMA_MAX (__XFRMA_MAX - 1) diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -1159,7 +1159,7 @@ nlmsg_failure: static int inline xfrm_sa_len(struct xfrm_state *x) { - int l = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); + int l = 0; if (x->aalg) l += RTA_SPACE(sizeof(*x->aalg) + (x->aalg->alg_key_len+7)/8); if (x->ealg) @@ -1175,20 +1175,39 @@ static int inline xfrm_sa_len(struct xfr static int xfrm_notify_sa(struct xfrm_state *x, struct km_event *c) { struct xfrm_usersa_info *p; + struct xfrm_usersa_id *id; struct nlmsghdr *nlh; struct sk_buff *skb; unsigned char *b; int len = xfrm_sa_len(x); + int headlen; + + headlen = sizeof(*p); + if (c->event == XFRM_MSG_DELSA) { + len += RTA_SPACE(headlen); + headlen = sizeof(*id); + } + len += NLMSG_SPACE(headlen); skb = alloc_skb(len, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; b = skb->tail; - nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, sizeof(*p)); + nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, headlen); nlh->nlmsg_flags = 0; p = NLMSG_DATA(nlh); + if (c->event == XFRM_MSG_DELSA) { + id = NLMSG_DATA(nlh); + memcpy(&id->daddr, &x->id.daddr, sizeof(id->daddr)); + id->spi = x->id.spi; + id->family = x->props.family; + id->proto = x->id.proto; + + p = RTA_DATA(__RTA_PUT(skb, XFRMA_SA, sizeof(*p))); + } + copy_to_user_state(x, p); if (x->aalg) @@ -1389,20 +1408,39 @@ static int xfrm_exp_policy_notify(struct static int xfrm_notify_policy(struct xfrm_policy *xp, int dir, struct km_event *c) { struct xfrm_userpolicy_info *p; + struct xfrm_userpolicy_id *id; struct nlmsghdr *nlh; struct sk_buff *skb; unsigned char *b; int len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); - len += NLMSG_SPACE(sizeof(struct xfrm_userpolicy_info)); + int headlen; + + headlen = sizeof(*p); + if (c->event == XFRM_MSG_DELPOLICY) { + len += RTA_SPACE(headlen); + headlen = sizeof(*id); + } + len += NLMSG_SPACE(headlen); skb = alloc_skb(len, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; b = skb->tail; - nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, sizeof(*p)); + nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, headlen); p = NLMSG_DATA(nlh); + if (c->event == XFRM_MSG_DELPOLICY) { + id = NLMSG_DATA(nlh); + memset(id, 0, sizeof(*id)); + id->dir = dir; + if (c->data.byid) + id->index = xp->index; + else + memcpy(&id->sel, &xp->selector, sizeof(id->sel)); + + p = RTA_DATA(__RTA_PUT(skb, XFRMA_POLICY, sizeof(*p))); + } nlh->nlmsg_flags = 0; @@ -1415,6 +1453,7 @@ static int xfrm_notify_policy(struct xfr return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); nlmsg_failure: +rtattr_failure: kfree_skb(skb); return -1; } --W/nzBZO5zC0uMSeA-- From greearb@candelatech.com Fri May 27 17:00:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 17:00:50 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S00lXq029686 for ; Fri, 27 May 2005 17:00:47 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j4S0WY5I002331; Fri, 27 May 2005 17:32:34 -0700 Message-ID: <4297B479.1080404@candelatech.com> Date: Fri, 27 May 2005 16:59:53 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Dawe CC: Francois Romieu , Linux netdev Subject: Re: [PATCH] r8169: support restricting speed+duplex in autonegotiation References: <4297A0F7.5070209@phekda.gotadsl.co.uk> In-Reply-To: <4297A0F7.5070209@phekda.gotadsl.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 2910 Lines: 86 Richard Dawe wrote: > Hello. > > Attached is a patch for drivers/net/r8169.c against Linux 2.6.11 that > allows adjustment of the speed and duplex advertised via > autonegotiation. Example usage: > > ethtool -s eth0 autoneg on speed 10 duplex half > > Also attached is a test script which tries various combinations of > autoneg, speed and duplex. There is also a log of the test run attache.d > While the test ran I had an ssh session running "while true; do sleep 1; > date; done". The ssh session did not drop. Note that I don't have GigE, > so that part of the test was bogus. > > I also tried various speed tests, to check that the speed and duplex > were actually changed. They were. > > Bye, Rich > > r8169: Allow adjustment of speed and duplex advertised via autonegotiation > > Signed-off-by: Richard Dawe > > > ------------------------------------------------------------------------ > > --- r8169.c.orig 2005-05-27 21:12:21.000000000 +0100 > +++ r8169.c 2005-05-27 22:14:59.000000000 +0100 > @@ -407,7 +407,9 @@ struct rtl8169_private { > #ifdef CONFIG_R8169_VLAN > struct vlan_group *vlgrp; > #endif > - int (*set_speed)(struct net_device *, u8 autoneg, u16 speed, u8 duplex); > + int (*set_speed)(struct net_device *, > + u8 autoneg, u16 speed, u8 duplex, > + u32 advertising); > void (*get_settings)(struct net_device *, struct ethtool_cmd *); > void (*phy_reset_enable)(void __iomem *); > unsigned int (*phy_reset_pending)(void __iomem *); > @@ -549,7 +551,9 @@ static void rtl8169_check_link_status(st > spin_unlock_irqrestore(&tp->lock, flags); > } > > -static void rtl8169_link_option(int idx, u8 *autoneg, u16 *speed, u8 *duplex) > +static void rtl8169_link_option(int idx, > + u8 *autoneg, u16 *speed, u8 *duplex, > + u32 *advertising) > { > struct { > u16 speed; > @@ -579,6 +583,23 @@ static void rtl8169_link_option(int idx, > *autoneg = p->autoneg; > *speed = p->speed; > *duplex = p->duplex; > + > + if (p->media == _10_Half) > + *advertising = ADVERTISED_10baseT_Half; > + if (p->media == _10_Full) > + *advertising = ADVERTISED_10baseT_Full; > + if (p->media == _100_Half) > + *advertising = ADVERTISED_100baseT_Half; > + if (p->media == _100_Full) > + *advertising = ADVERTISED_100baseT_Full; > + if (p->media == _1000_Full) > + *advertising = ADVERTISED_1000baseT_Full; > + if (p->media == 0xff) > + *advertising = ADVERTISED_10baseT_Half | > + ADVERTISED_10baseT_Full | > + ADVERTISED_100baseT_Half | > + ADVERTISED_100baseT_Full | > + ADVERTISED_1000baseT_Full; > } So, is there no way to advert just 100Mbps-half and -full ? Seems like you should be able to set each flag by itself and create a bit-mask of the particular flags that you want... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From herbert@gondor.apana.org.au Fri May 27 17:11:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 17:11:25 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S0BHXq030368 for ; Fri, 27 May 2005 17:11:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Dbou1-0005te-00; Sat, 28 May 2005 10:10:10 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Dbotx-0002kT-00; Sat, 28 May 2005 10:10:05 +1000 Date: Sat, 28 May 2005 10:10:05 +1000 To: "David S. Miller" Cc: hadi@cyberus.ca, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [0/10] [IPSEC] IPsec event notification Message-ID: <20050528001005.GA10547@gondor.apana.org.au> References: <20050527110730.GA4424@gondor.apana.org.au> <20050527.134139.32345929.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527.134139.32345929.davem@davemloft.net> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 426 Lines: 13 On Fri, May 27, 2005 at 01:41:39PM -0700, David S. Miller wrote: > > Pulled, thanks Herbert. Thanks Dave. Any objections to asking Andrew to start pulling your net-2.6.13 tree or is he doing that already? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Fri May 27 17:31:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 17:31:43 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S0VaXq031320 for ; Fri, 27 May 2005 17:31:40 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DbpE5-0004nN-EL for netdev@oss.sgi.com; Fri, 27 May 2005 20:30:53 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbpDz-000865-RC; Fri, 27 May 2005 20:30:48 -0400 Subject: Re: [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Patrick McHardy , netdev@oss.sgi.com In-Reply-To: <20050527233741.GA9157@gondor.apana.org.au> References: <20050527233741.GA9157@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 20:30:42 -0400 Message-Id: <1117240242.6251.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 754 Lines: 19 On Sat, 2005-28-05 at 09:37 +1000, Herbert Xu wrote: > Hi Dave: > > This is the patch that I reverted due to Jamal's objection to it. > I still think it's the right way to go which is why I'm submitting > it. As it is, all the xfrm event notifications sent by the kernel > except the ones for SA/policy deletion are symmetric in the sense > that if they were sent straight back to the kernel in that same > form they would be accepted and perform the same action that > triggered the initial events. As far as I know this is true for > non-xfrm netlink notifications as well, including deletion events. > I have no objection to this patch going forth. I think i have sufficiently expressed my dislike - but we gotta make progress;-> cheers, jamal From hadi@cyberus.ca Fri May 27 17:57:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 17:57:21 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S0vIXq000435 for ; Fri, 27 May 2005 17:57:19 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1Dbpcw-0002q7-1q for netdev@oss.sgi.com; Fri, 27 May 2005 20:56:34 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dbpct-0002nn-Kr; Fri, 27 May 2005 20:56:31 -0400 Subject: Re: RFC: NAPI packet weighting patch From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: Mitch Williams , netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Ronciak, John" , "Venkatesan, Ganesh" , "Brandeburg, Jesse" In-Reply-To: <20050527140132.1435132d@dxpl.pdx.osdl.net> References: <20050527085055.79da3d75@dxpl.pdx.osdl.net> <20050527140132.1435132d@dxpl.pdx.osdl.net> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 20:56:26 -0400 Message-Id: <1117241786.6251.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 290 Lines: 13 On Fri, 2005-27-05 at 14:01 -0700, Stephen Hemminger wrote: > > Why not just allow adjusting dev->weight via sysfs? I think that should be good enough - and i thought your patch already did this. Adding a shift to the weight in a _weighted_ RR algorithm does sound odd. cheers, jamal From hadi@cyberus.ca Fri May 27 18:07:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 18:08:03 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S17wXq001263 for ; Fri, 27 May 2005 18:07:58 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DbpnH-0004xW-El for netdev@oss.sgi.com; Fri, 27 May 2005 21:07:15 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dbpn2-00042h-VS; Fri, 27 May 2005 21:07:01 -0400 Subject: Re: [PATCH 2/2] [NETLINK] Correctly set NLM_F_MULTI without checking the pid From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050527170135.GE15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> <20050527170135.GE15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 21:06:55 -0400 Message-Id: <1117242415.6251.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1816 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 591 Lines: 19 Ok, looks good. Dave please apply this one instead of the one i posted this morning - it incorporates the name change as well. Incase its not clear - 1/2 in this patch set is also fine. cheers, jamal On Fri, 2005-27-05 at 19:01 +0200, Thomas Graf wrote: > This patch rectifies some rtnetlink message builders that derive the > flags from the pid. It is now explicit like the other cases > which get it right. Also fixes half a dozen dumpers which did not > set NLM_F_MULTI at all. > > Signed-off-by: Jamal Hadi Salim > Signed-off-by: Thomas Graf > From hadi@cyberus.ca Fri May 27 18:13:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 18:13:23 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S1DLXq001861 for ; Fri, 27 May 2005 18:13:21 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DbpsR-0002Mh-NB for netdev@oss.sgi.com; Fri, 27 May 2005 21:12:35 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbpsQ-0005tC-80; Fri, 27 May 2005 21:12:34 -0400 Subject: Re: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050527165935.GC15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 21:12:29 -0400 Message-Id: <1117242749.6251.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 744 Lines: 25 On Fri, 2005-27-05 at 18:59 +0200, Thomas Graf wrote: > I took your patch, converted it to use NLMSG_NEW and finished > converting all the modules that you started. Thats the patchset 1/2 and 2/2, correct? > Yet unconverted > are: netfilter, net/sched/ tcp_diag, xfrm, kernel/audit. > I didnt find any issues with these as far as PID extrapolation. > I also fixed some uses of NL_CREDS() to fetch the pid for > message generation which is wrong. Various dumping procedures > did not set the multi flag at all, I fixed all of them. > > Do not apply these patches yet, they're way too intrusive Do you mean the two patches? Those looked fine to me; i.e its mostly the patch i posted this morning with the new Macros, no? cheers, jamal From tgraf@suug.ch Fri May 27 18:28:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 18:28:43 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S1SeXq002759 for ; Fri, 27 May 2005 18:28:40 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id DFFAD1C0EB; Sat, 28 May 2005 03:28:10 +0200 (CEST) Date: Sat, 28 May 2005 03:28:10 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting Message-ID: <20050528012810.GN15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> <1117242749.6251.15.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117242749.6251.15.camel@localhost.localdomain> X-archive-position: 1818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1187 Lines: 30 * jamal <1117242749.6251.15.camel@localhost.localdomain> 2005-05-27 21:12 > > Yet unconverted > > are: netfilter, net/sched/ tcp_diag, xfrm, kernel/audit. > > > > I didnt find any issues with these as far as PID extrapolation. I should have written, yet unchecked. > > I also fixed some uses of NL_CREDS() to fetch the pid for > > message generation which is wrong. Various dumping procedures > > did not set the multi flag at all, I fixed all of them. > > > > Do not apply these patches yet, they're way too intrusive > > Do you mean the two patches? Those looked fine to me; Yes, those two patches. My part comes directly out of my fingers and is only compile tested. I didn't even run them yet. > i.e its mostly the patch i posted this morning with the new Macros, no? I went through all users of NLMSG_PUT in the modules you touched and checked if they properly set NLM_F_MULTI and used the new macro when appropriate. Anyways, I want to be careful with this, there might be userspace apps which rely on pid being filled in from siocb->scm->creds or userspace apps which don't expect the NLM_F_MULTI flag even when they should so we should check with all parties involved. From hadi@cyberus.ca Fri May 27 18:43:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 18:43:51 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S1hjXq003677 for ; Fri, 27 May 2005 18:43:45 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DbqLr-00018Q-A3 for netdev@oss.sgi.com; Fri, 27 May 2005 21:42:59 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbqLk-0001rQ-7v; Fri, 27 May 2005 21:42:52 -0400 Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050527163516.GB15391@postel.suug.ch> References: <20050526185306.GW15391@postel.suug.ch> <20050526185526.GZ15391@postel.suug.ch> <1117192464.6688.3.camel@localhost.localdomain> <20050527121503.GN15391@postel.suug.ch> <1117201853.6383.29.camel@localhost.localdomain> <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> <20050527163516.GB15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 21:42:46 -0400 Message-Id: <1117244567.6251.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2808 Lines: 71 On Fri, 2005-27-05 at 18:35 +0200, Thomas Graf wrote: > I do NOT agree on moving gc_ into this architecture as well, > it doesn't belong there. Well, you do realize they are part of the in_dev ? ;-> > Nitpicking for a bit, although inet6_dev and in_device hold > reference to the their arp respectively ndisc parameter set, > the sysctl interface does not use this reference but stores > the ifindex of the netdevice, _which_ is correct I think > because parameter sets are _not_ limited to inetdevs in terms > of architecture but only in terms of current use. > I see a little main service header with ifindex always no different than IFA or IFLINK etc followed by appropriate TLVs which are nested. Unfortunately i still cant find the patch - i started with a different approach; my immediate interest was to get events when someone made in_device changes. BTW, this is going to be one of the main challenges since there are many paths to configure these things. > > The deafult can be overriden by devX. So they dont need to sync. > > But this is a separate topic > > I was not talking about in-sync but rather that gc_* only > appears in default/ but not in devX/. What I expect is that > every default parameter can be overwritten in devX which > is not true for gc_*. Which is the reason why I implemented > them outside of the NDTPA_PARMS nested TLV. > Well, if you look at the structure there is no reason they should really be separate; infact theres a comment: ----------- struct neigh_parms parms; /* HACK. gc_* shoul follow parms without a gap! */ int gc_interval; int gc_thresh1; int gc_thresh2; ---------- To me the abstraction is pretty clear. I would agree that the way parameters configurable from user space and some of the methods may not be the best in terms of neighbor tables organization. > I understand your architecture and if we follow this thought > we'd have a "default" netdevice which repesents all default > settings. >From looking at the code, the default stuff seems to be "hardcoded". Example in the definition arp_tbl. > I do agree with this architecture but the problematic > question remains: Do we want parameters in "default" which are > not available in devX? I think this question is what it gets > down to in the end. If we say, yes we do want this, then we > can implement all generic settings, such as tcp_, using this > scheme as well. I don't disagree with this completely but I > find it not very intuitive from a user perspective. The model like i said is clean. There are some issues i have qualms with - such as IP address arrangements and tight integration with netdevices - but those can addressed at a later time. cheers, jamal From hadi@cyberus.ca Fri May 27 18:49:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 18:49:07 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S1n4Xq004318 for ; Fri, 27 May 2005 18:49:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DbqR1-0003nv-Lf for netdev@oss.sgi.com; Fri, 27 May 2005 21:48:19 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DbqR0-0002en-3n; Fri, 27 May 2005 21:48:18 -0400 Subject: Re: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050528012810.GN15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> <1117242749.6251.15.camel@localhost.localdomain> <20050528012810.GN15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Fri, 27 May 2005 21:48:13 -0400 Message-Id: <1117244893.6251.41.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1782 Lines: 51 On Sat, 2005-28-05 at 03:28 +0200, Thomas Graf wrote: > * jamal <1117242749.6251.15.camel@localhost.localdomain> 2005-05-27 21:12 > > > Yet unconverted > > > are: netfilter, net/sched/ tcp_diag, xfrm, kernel/audit. > > > > > > > I didnt find any issues with these as far as PID extrapolation. > > I should have written, yet unchecked. > I did check netfilter, net/sched/ tcp_diag, xfrm and they do things right. > > > Do not apply these patches yet, they're way too intrusive > > > > Do you mean the two patches? Those looked fine to me; > > Yes, those two patches. My part comes directly out of my fingers > and is only compile tested. I didn't even run them yet. > Hrm - you should probably have said that in the patch text ;-> I did test the one i sent - basic things and by code inspection saw little risk as well. Perhaps we should push mine then you can add on top of it. > > i.e its mostly the patch i posted this morning with the new Macros, no? > > I went through all users of NLMSG_PUT in the modules you touched and > checked if they properly set NLM_F_MULTI and used the new macro when > appropriate. > > Anyways, I want to be careful with this, there might be userspace > apps which rely on pid being filled in from siocb->scm->creds or > userspace apps which don't expect the NLM_F_MULTI flag even when > they should so we should check with all parties involved. > I dont see any issues with my original patch or for that matter yours except for now that you are saying you havent compiled it even ;->. All dumps MUST set NLM_F_MULTI - thats the main change really. All non-dump paths may set NLM_F_MULTI, and from that angle, if theres any bugs in the old code they are maintained ;-> So how about we push my original patch instead? cheers, jamal From jgarzik@pobox.com Fri May 27 19:14:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 19:14:11 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S2E6Xq005313 for ; Fri, 27 May 2005 19:14:06 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1Dbqp6-0003nx-29; Sat, 28 May 2005 02:13:14 +0000 Message-ID: <4297D3B4.1070809@pobox.com> Date: Fri, 27 May 2005 22:13:08 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: James Ketrenos , Andrew Morton , Linux Kernel Subject: netdev-2.6.git updated, ipw wireless drivers merged Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 352 Lines: 13 The ipw 2100/2200 wireless drivers were merged into the netdev-2.6.git repository, under the 'we18-ieee80211' branch. There is also the we18-ieee80211-wifi branch, which lumps HostAP on top of that. (if you need info on git, read http://lkml.org/lkml/2005/5/26/11) Also, Andrew: I fixed that compilation error you mentioned a week or so ago. From jgarzik@pobox.com Fri May 27 19:24:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 19:25:01 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S2OvXq006000 for ; Fri, 27 May 2005 19:24:57 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1Dbqze-0003oN-D2; Sat, 28 May 2005 02:24:06 +0000 Message-ID: <4297D643.5020407@pobox.com> Date: Fri, 27 May 2005 22:24:03 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Broadbent CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1141 Lines: 35 Mark Broadbent wrote: > The interrupt handling code in the tulip network driver appears to use a non > IRQ safe spinlock in an interrupt context. The following patch should correct > this. > > Signed-off-by: Mark Broadbent > > Index: linux-2.6.11/drivers/net/tulip/interrupt.c > =================================================================== > --- linux-2.6.11.orig/drivers/net/tulip/interrupt.c 2005-03-07 18:11:23.000000000 +0000 > +++ linux-2.6.11/drivers/net/tulip/interrupt.c 2005-04-28 16:16:23.000000000 +0100 > @@ -567,8 +567,9 @@ > > if (csr5 & (TxNoBuf | TxDied | TxIntr | TimerInt)) { > unsigned int dirty_tx; > + unsigned long flags; > > - spin_lock(&tp->lock); > + spin_lock_irqsave(&tp->lock, flags); > > for (dirty_tx = tp->dirty_tx; tp->cur_tx - dirty_tx > 0; > dirty_tx++) { > @@ -640,7 +641,7 @@ > dev->name, csr5, ioread32(ioaddr + CSR6), tp->csr6); > tulip_restart_rxtx(tp); > } > - spin_unlock(&tp->lock); > + spin_unlock_irqrestore(&tp->lock, flags); It's already inside the interrupt handler, so this patch is not needed. Jeff From jgarzik@pobox.com Fri May 27 19:44:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 19:45:01 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S2iwXq006917 for ; Fri, 27 May 2005 19:44:58 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DbrJ1-0003oi-4k; Sat, 28 May 2005 02:44:07 +0000 Message-ID: <4297DAEA.70700@pobox.com> Date: Fri, 27 May 2005 22:43:54 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Benc CC: NetDev , LKML , pavel@suse.cz Subject: Re: [1/5] ieee80211: cleanup References: <20050524150711.01632672@griffin.suse.cz> <20050524151018.3304fbeb@griffin.suse.cz> In-Reply-To: <20050524151018.3304fbeb@griffin.suse.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From pablo@eurodev.net Fri May 27 20:11:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 20:11:52 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S3BkXq008636 for ; Fri, 27 May 2005 20:11:47 -0700 Received: from [85.136.100.184] by smtp06.retemail.es (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050528031052.LWFL1136.smtp06.retemail.es@[85.136.100.184]>; Sat, 28 May 2005 05:10:52 +0200 Message-ID: <4297E172.5020907@eurodev.net> Date: Sat, 28 May 2005 05:11:46 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: netdev@oss.sgi.com, Jamal Hadi Salim Subject: Re: [PATCH 4/5] [NET] Add skb_find_text() to search for a text pattern in skbs References: <20050527224725.GG15391@postel.suug.ch> <20050527224858.GK15391@postel.suug.ch> In-Reply-To: <20050527224858.GK15391@postel.suug.ch> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1694 Lines: 60 Thomas Graf wrote: > +static int get_skb_text(int offset, unsigned char **text, > + struct ts_config *conf, struct ts_state *state) > +{ > + /* args[0]: lower limit > + * args[1]: upper limit > + * args[2]: skb > + * args[3]: fragment index > + * args[4]: current fragment data buffer > + * args[5]: octets consumed up to previous fragment */ > + int from = state->args[0], to = state->args[1]; > + struct sk_buff *skb = (struct sk_buff *) state->args[2]; > + int limit = min_t(int, skb_headlen(skb), to); > + int real_offset = offset + from; > + skb_frag_t *f; > + > + if (!skb_is_nonlinear(skb)) { > + if (real_offset < limit) { > +linear: > + *text = skb->data + real_offset; > + return limit - real_offset; > + } > + > + return 0; > + } > + > + if (real_offset < limit) > + goto linear; > + > +next_fragment: > + f = &skb_shinfo(skb)->frags[state->args[3]]; > + limit = min_t(int, f->size + state->args[5], to); > + > + if (!state->args[4]) > + state->args[4] = (long) kmap_skb_frag(f); > + > + if (real_offset < limit) { > + *text = (unsigned char *) state->args[4] + f->page_offset + > + (real_offset - (int) state->args[5]); > + return limit - real_offset; > + } > + > + kunmap_skb_frag((void *) state->args[4]); > + state->args[3]++; > + state->args[4] = (long) NULL; > + state->args[5] += f->size; > + > + if (state->args[3] >= skb_shinfo(skb)->nr_frags) > + return 0; > + > + goto next_fragment; > +} Still miss something here. You aren't looking for matches in skbs inserted in skb_shinfo(skb)->frag_list. Have a look at rusty's skb_iter functions. Since he cooked those for this purpose (string matching), why don't we use them instead of yours ? -- Pablo From jgarzik@pobox.com Fri May 27 20:16:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 20:16:19 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S3GEXq009305 for ; Fri, 27 May 2005 20:16:14 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DbrnG-0003pF-J7; Sat, 28 May 2005 03:15:23 +0000 Message-ID: <4297E246.1070606@pobox.com> Date: Fri, 27 May 2005 23:15:18 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Benc , "David S. Miller" CC: NetDev , LKML , pavel@suse.cz Subject: Re: [3/5] netdev: HH_DATA_OFF bugfix References: <20050524150711.01632672@griffin.suse.cz> <20050524151204.554f73cb@griffin.suse.cz> In-Reply-To: <20050524151204.554f73cb@griffin.suse.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 929 Lines: 28 Jiri Benc wrote: > When the hardware header size is a multiple of HH_DATA_MOD, HH_DATA_OFF() > incorrectly returns HH_DATA_MOD (instead of 0). > > Signed-off-by: Jiri Benc > > --- linux/include/linux/netdevice.h > +++ work/include/linux/netdevice.h > @@ -204,7 +209,7 @@ > /* cached hardware header; allow for machine alignment needs. */ > #define HH_DATA_MOD 16 > #define HH_DATA_OFF(__len) \ > - (HH_DATA_MOD - ((__len) & (HH_DATA_MOD - 1))) > + (HH_DATA_MOD - (((__len - 1) & (HH_DATA_MOD - 1)) + 1)) > #define HH_DATA_ALIGN(__len) \ > (((__len)+(HH_DATA_MOD-1))&~(HH_DATA_MOD - 1)) > unsigned long hh_data[HH_DATA_ALIGN(LL_MAX_HEADER) / sizeof(long)]; You'll want to run this one by DaveM. He would be the appropriate one to merge this, since it affects all ethernet devices (net/ethernet/eth.c uses HH_DATA_OFF macro). I'm going over the rest of the ieee80211/ipw patches... Jeff From jgarzik@pobox.com Fri May 27 20:19:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 20:19:25 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S3JMXq013407 for ; Fri, 27 May 2005 20:19:22 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DbrqL-0003pN-1t; Sat, 28 May 2005 03:18:33 +0000 Message-ID: <4297E307.30707@pobox.com> Date: Fri, 27 May 2005 23:18:31 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Benc CC: NetDev , LKML , pavel@suse.cz Subject: Re: [0/5] Improvements to the ieee80211 layer References: <20050524150711.01632672@griffin.suse.cz> In-Reply-To: <20050524150711.01632672@griffin.suse.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1590 Lines: 42 Jiri Benc wrote: > The ieee80211 layer, now present in -mm, lacks many important features > (actually it's just a part of the ipw2100/ipw2200 driver; these cards do > a lot of the processing in the hardware/firmware and thus the layer > currently can not be used for simpler devices). Agreed. > This is the first series of patches that try to convert it to a generic > IEEE 802.11 layer, usable for most of today's wireless cards. Great! > The long term plan is: > - to implement a complete 802.11 stack in the kernel, making it easy to > write drivers for simple (cheap) devices > - to implement all of Ad-Hoc, AP and monitor modes in the layer, so it > will be easy to support them in the drivers > - to integrate Wireless Extensions to unify the kernel-userspace > interface of all the drivers > > This means that drivers for "stupid" (simple, cheap) cards should be > very short and easy to write, whereas drivers for "clever" cards will be > longer (but still shorter than they are now). > > We have a couple of cards for testing, and we gradually modify the > drivers for ipw2100 and ipw2200 with the development of the layer. When > the layer is mature enough for the "stupid" cards, we will rewrite the > driver for Atheros-based cards to use this layer. We plan to send all > the patches for these drivers to the netdev list. Of course, we are in > close contact with Pavel Machek, who is pushing the ipw2100 driver > upstream. I'm interesting in writing a RealTek driver using ieee80211. As the ieee80211 layer matures, I'll start publishing that code. Jeff From jgarzik@pobox.com Fri May 27 20:38:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 20:38:46 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S3cfXq014785 for ; Fri, 27 May 2005 20:38:41 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1Dbs8y-0003pb-Ul; Sat, 28 May 2005 03:37:51 +0000 Message-ID: <4297E78A.4030906@pobox.com> Date: Fri, 27 May 2005 23:37:46 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Benc CC: NetDev , LKML , pavel@suse.cz Subject: Re: [2/5] ieee80211: ieee80211_device alignment fix and cleanup References: <20050524150711.01632672@griffin.suse.cz> <20050524151117.5e059d1d@griffin.suse.cz> In-Reply-To: <20050524151117.5e059d1d@griffin.suse.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1662 Lines: 52 Comments on the remaining patches in this series: 1) I am not convinced that the subclassing of net_device should be done in this manner. Read drivers/net/wan/hdlc_generic.c and .../pc300_drv.c for examples of how hdlc_device is handled. Comments and thoughts welcome. 2) Please put all the new, protocol-layer functions ieee80211_type_trans(), ieee80211_change_mtu(), ieee80211_header(), etc. in their own file. 3) Temporary or not, the following construct is simply not necessary. Modify the definition rather than repeating this two-call piece of code in multiple areas: ieee80211_priv(netdev_priv(dev)); 4) A low-level wireless hardware driver should look like other net drivers, and use the existing driver API. The low level driver should implement its own dev->hard_start_xmit(). ieee = netdev_priv(dev); - dev->hard_start_xmit = ieee80211_xmit; - ieee->dev = dev; + ieee->priv = ieee80211_priv(ieee); + + dev->hard_start_xmit = ieee80211_xmit; Certainly, the driver will make many calls to generic ieee80211_xxx functions to get things done. I understand this was not your change; you simply moved the dev->hard_start_xmit() assignment down. I just wanted to take this opportunity to make a point. 5) The wireless code in -mm all sourced directly from my netdev-2.6.git tree. I strongly encourage everyone who wants to work on wireless to download git (read http://lkml.org/lkml/2005/5/26/11) and check out branches 'we18' (wireless ex 18), 'we18-ieee80211' (we18 + ieee80211), and 'we18-ieee80211-wifi' (we18 + ieee80211 + hostAP) of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git From jgarzik@pobox.com Fri May 27 20:45:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 27 May 2005 20:46:00 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4S3jtXq015509 for ; Fri, 27 May 2005 20:45:55 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux)) id 1DbsFz-0003pl-GJ; Sat, 28 May 2005 03:45:06 +0000 Message-ID: <4297E93D.2060003@pobox.com> Date: Fri, 27 May 2005 23:45:01 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel Subject: netdev-2.6, wireless queues updated Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1828 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 988 Lines: 26 The net driver change queue has been updated, most notably with some new wireless drivers and wireless stack updates. Intel contributed drivers for their Centrino hardware, "ipw2100" and "ipw2200". SuSE has begun contributing work that advances the ieee80211 stack work, taking it much closer to the goal of having ieee802.11 support fully integrated into the network stack as "real" protocol layer. Git repository containing a great many branches: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git The branch of note for wireless developers is currently 'we18-ieee80211'. Git instructions, for those needing an introduction: http://lkml.org/lkml/2005/5/26/11 And finally a patch containing _only_ the changes on the we18-ieee80211 branch, http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.12-rc5-git2-ieee80211-1.patch.bz2 Notably, this patch does not include HostAP, which is stored in a child branch 'we18-ieee80211-wifi'. From tgraf@suug.ch Sat May 28 04:33:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 04:33:20 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SBXGXq006658 for ; Sat, 28 May 2005 04:33:16 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id BD25D1C0EB; Sat, 28 May 2005 13:32:45 +0200 (CEST) Date: Sat, 28 May 2005 13:32:45 +0200 From: Thomas Graf To: Pablo Neira Cc: netdev@oss.sgi.com, Jamal Hadi Salim Subject: Re: [PATCH 4/5] [NET] Add skb_find_text() to search for a text pattern in skbs Message-ID: <20050528113245.GO15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> <20050527224858.GK15391@postel.suug.ch> <4297E172.5020907@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4297E172.5020907@eurodev.net> X-archive-position: 1829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 474 Lines: 9 * Pablo Neira <4297E172.5020907@eurodev.net> 2005-05-28 05:11 > Still miss something here. You aren't looking for matches in skbs > inserted in skb_shinfo(skb)->frag_list. Have a look at rusty's skb_iter > functions. Since he cooked those for this purpose (string matching), why > don't we use them instead of yours ? Absolutely, I'm planning to use rusty's skb_iter instead. I postponed this to when the core infrastructure is stable but thanks a lot for this comment. From hadi@cyberus.ca Sat May 28 05:00:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 05:00:42 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SC0aXq008325 for ; Sat, 28 May 2005 05:00:39 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Dbzyl-0004J3-0n for netdev@oss.sgi.com; Sat, 28 May 2005 07:59:47 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dbzyi-0000He-Hk; Sat, 28 May 2005 07:59:44 -0400 Subject: Re: [RFC] textsearch infrastructure et al v2 From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050527224725.GG15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Sat, 28 May 2005 07:59:41 -0400 Message-Id: <1117281581.6251.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2230 Lines: 58 On Sat, 2005-28-05 at 00:47 +0200, Thomas Graf wrote: > Dave, I'm going through another RFC round to hopefully get > some comments on the notes below. > > I'm not yet satistifed with the core infrastructure wrt to > non-linear data, especially for complex cases such as non > linear skbs. The current way can be easly described as: > > search_occurrance() > search-algorithm() > while get-next-segment() > process-segment() > I dont have opinions on this since you and Pablo seem to agree on it. What I remember is that libssearch (or whatever that thing Harald was looking at) did it differently (callback invoked and it return a code which said to continue or not). Also the design should (I think you do already, just double checking) - should be wary of optimizing for a specific algorithmn; i see you have KMP but not Boyer-Moore for example and i am not sure what the repurcassions of above approach are etc etc. > So basically we save the state of the segment fetching > instead of saving the state of the search algorithm which > would be way too complex for things like regular expression > string matching. > Can you explain this a little more. Didnt quiet understand. If you are going across skbs, dont you need to save state? > In the case of non linear skbs this would lead to: > I think the best approach would be to first linearize then search. On the egress side this would mean annoying things like no TSO or what was posted yesterday USO etc. Same thing with ingress, but i suspect other than the netiron NIC we probably wont be seeing much of non-linear skbs on the ingress. On ingress as well you are also better off to assemble fragments first on that side before doing text searches. Perhaps implementing an action like the one used by openbsd to "normalize" packets before a string match. i.e classifier (pkt header) --> normalize --> classifier(string match)-> ? Infact one could argue that if you are to scan a virus you may need to assemble more than one skb on ingress (essentially a message). The only other comment i have is on the patch you called naive regexp; I think you should probably call it something else instead of regexp since you invented it. cheers, jamal From tgraf@suug.ch Sat May 28 05:08:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 05:08:04 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SC7xXq008960 for ; Sat, 28 May 2005 05:08:00 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 3BB561C0EB; Sat, 28 May 2005 14:07:31 +0200 (CEST) Date: Sat, 28 May 2005 14:07:31 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050528120731.GP15391@postel.suug.ch> References: <20050526185526.GZ15391@postel.suug.ch> <1117192464.6688.3.camel@localhost.localdomain> <20050527121503.GN15391@postel.suug.ch> <1117201853.6383.29.camel@localhost.localdomain> <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> <20050527163516.GB15391@postel.suug.ch> <1117244567.6251.34.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117244567.6251.34.camel@localhost.localdomain> X-archive-position: 1831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3480 Lines: 80 * jamal <1117244567.6251.34.camel@localhost.localdomain> 2005-05-27 21:42 > On Fri, 2005-27-05 at 18:35 +0200, Thomas Graf wrote: > > > I do NOT agree on moving gc_ into this architecture as well, > > it doesn't belong there. > > Well, you do realize they are part of the in_dev ? ;-> Huh? They cannot be device specific, there is only one gc per neighbour table. So even _iff_ there was a device specific setting it wouldn't make much sense ;-> > I see a little main service header with ifindex always no different than > IFA or IFLINK etc followed by appropriate TLVs which are nested. I guess we could simply move NDTPA_PARMS into the devconfig family. > > Unfortunately i still cant find the patch - i started with a different > approach; my immediate interest was to get events when someone made > in_device changes. BTW, this is going to be one of the main challenges > since there are many paths to configure these things. Right. > Well, if you look at the structure there is no reason they should really > be separate; infact theres a comment: > ----------- > struct neigh_parms parms; > /* HACK. gc_* shoul follow parms without a gap! */ > int gc_interval; > int gc_thresh1; > int gc_thresh2; > ---------- You do realize the reason for that comment? ;-> The author of the neighbour procfs code was simply too lazy to put these into a separate place so he introduced a nasty hack. > > I understand your architecture and if we follow this thought > > we'd have a "default" netdevice which repesents all default > > settings. > > >From looking at the code, the default stuff seems to be "hardcoded". > Example in the definition arp_tbl. These are just the default values for the default parameter set. > The model like i said is clean. There are some issues i have qualms with > - such as IP address arrangements and tight integration with netdevices > - but those can addressed at a later time. What about this, we move the device specific part into the new devconfig layer but leave the main configuration, statistics, and gc parameters in RTM_NEIGHTBL? i.e. arp_cache entries 2 reachable-time 23s 993msec retransmit-time 1s key-len 4 entry-size 152 last-flush 55m 44s 572msec gc threshold 128/512/1024 interval 30s chain-position 3 hash-rand 0x69650257/0x00000003 last-rand 1m 44s 571msec ? refcnt 1 pending-queue-limit 3 proxy-delayed-queue-limit 64 ? num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3 ? min-age 1s base-reachable-time 30s stale-check-interval 1m ? initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec lookups 195 hits 190 failed 0 allocations 3 destroys 1 hash-grows 1 forced-gc-runs 0 periodic-gc-runs 910 rcv-unicast-probes 0 rcv-multicast-probes 0 Xarp_cache reachable-time 35s 967msec retransmit-time 1s X refcnt 3 pending-queue-limit 3 proxy-delayed-queue-limit 64 X num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3 X min-age 1s base-reachable-time 30s stale-check-interval 1m X initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec Everything marked with X is clearly device specific so it will move. Everything marked with '?' is the default parameter set, we can either leave it or move it as well and put it under into a 'default' ifindex. I don't care about the latter, either is fine with me. From tgraf@suug.ch Sat May 28 05:18:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 05:19:01 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SCIuXq009654 for ; Sat, 28 May 2005 05:18:57 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 818D81C0EB; Sat, 28 May 2005 14:18:27 +0200 (CEST) Date: Sat, 28 May 2005 14:18:27 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting Message-ID: <20050528121827.GQ15391@postel.suug.ch> References: <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> <1117242749.6251.15.camel@localhost.localdomain> <20050528012810.GN15391@postel.suug.ch> <1117244893.6251.41.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117244893.6251.41.camel@localhost.localdomain> X-archive-position: 1832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 569 Lines: 17 * jamal <1117244893.6251.41.camel@localhost.localdomain> 2005-05-27 21:48 > I did check netfilter, net/sched/ tcp_diag, xfrm and they do things > right. OK. > Hrm - you should probably have said that in the patch text ;-> I wanted to have some time for testing today without the need to resubmit the patches. ;-> > I did test the one i sent - basic things and by code inspection saw > little risk as well. Perhaps we should push mine then you can add on top > of it. I just tested both patches for about 30 minutes. Everything OK. Feel free to apply the patches. From tgraf@suug.ch Sat May 28 05:36:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 05:36:18 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SCaBXq010507 for ; Sat, 28 May 2005 05:36:12 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 35C9D1C0EB; Sat, 28 May 2005 14:35:42 +0200 (CEST) Date: Sat, 28 May 2005 14:35:42 +0200 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] textsearch infrastructure et al v2 Message-ID: <20050528123542.GR15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> <1117281581.6251.68.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117281581.6251.68.camel@localhost.localdomain> X-archive-position: 1833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3078 Lines: 69 * jamal <1117281581.6251.68.camel@localhost.localdomain> 2005-05-28 07:59 > I dont have opinions on this since you and Pablo seem to agree on it. > What I remember is that libssearch (or whatever that thing Harald was > looking at) did it differently (callback invoked and it return a code > which said to continue or not). Same for my infrastructure with the difference that libqsearch uses a single input buffer so no chance for non-linear data. > Also the design should (I think you do already, just double checking) - > should be wary of optimizing for a specific algorithmn; i see you have > KMP but not Boyer-Moore for example and i am not sure what the > repurcassions of above approach are etc etc. This is a weakness of the current implementation, it could be addresses via the other method that I proposed. The current patch doesn't allow for random access over fragment borders which means that Boyer-Moore would require a temporary buffer with a size of the pattern length in order to do random access over multiple fragments. However, I haven't seen any infrastructure yet that can handle non-linear data with bm wihout a complete prefetch in the beginning though. You could still implement a bm by either using a naive search at the borders or simply define the limitation that you can only look at the first fragment so you'd have to linearize. > > So basically we save the state of the segment fetching > > instead of saving the state of the search algorithm which > > would be way too complex for things like regular expression > > string matching. > > > > Can you explain this a little more. Didnt quiet understand. > If you are going across skbs, dont you need to save state? Most people look at it from the angle of iterate over text segments and apply a text search algorithm. I inverted this and said, start the text search algorithm and iterate over all text segments inside the algorithm. This makes many things a lot easier because we only have to save the state of the iterator. This brings up another limitation though, we cannot stop a search in progress and continue later on. > I think the best approach would be to first linearize then search. This is what I'm trying to avoid. ;-> > On ingress as well you are also better off to assemble fragments first > on that side before doing text searches. We can still do this optionally, just because we support it doesn't mean we have to use it. > Perhaps implementing an action like the one used by openbsd to > "normalize" packets before a string match. > i.e > classifier (pkt header) --> normalize --> classifier(string match)-> ? > Infact one could argue that if you are to scan a virus you may need > to assemble more than one skb on ingress (essentially a message). http://oss.sgi.com/archives/netdev/2005-05/msg00298.html See the section after <> > The only other comment i have is on the patch you called naive regexp; > I think you should probably call it something else instead of regexp > since you invented it. I was never good at names, any suggestions? From pablo@eurodev.net Sat May 28 05:56:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 05:56:39 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SCuYXq011628 for ; Sat, 28 May 2005 05:56:35 -0700 Received: from [85.136.96.216] by smtp06.retemail.es (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050528125543.RDNY1136.smtp06.retemail.es@[85.136.96.216]>; Sat, 28 May 2005 14:55:43 +0200 Message-ID: <42986A85.9060001@eurodev.net> Date: Sat, 28 May 2005 14:56:37 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: jamal , netdev@oss.sgi.com Subject: Re: [RFC] textsearch infrastructure et al v2 References: <20050527224725.GG15391@postel.suug.ch> <1117281581.6251.68.camel@localhost.localdomain> <20050528123542.GR15391@postel.suug.ch> In-Reply-To: <20050528123542.GR15391@postel.suug.ch> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 3124 Lines: 75 Thomas Graf wrote: > * jamal <1117281581.6251.68.camel@localhost.localdomain> 2005-05-28 07:59 > >>I dont have opinions on this since you and Pablo seem to agree on it. to be frank, i'm still willing to propose some changes to Thomas, I'll do soon since he's pulled my ear with this second rfc request ;). >>What I remember is that libssearch (or whatever that thing Harald was >>looking at) did it differently (callback invoked and it return a code >>which said to continue or not). > > > Same for my infrastructure with the difference that libqsearch uses > a single input buffer so no chance for non-linear data. hm, i don't understand quite well, i bet that libqsearch was already fragment-aware. Anyway the main difference is that libqsearch wasn't designed to be used in user space so, for example, it needed a complete rework to reduce dynamic memory allocations. >>Also the design should (I think you do already, just double checking) - >>should be wary of optimizing for a specific algorithmn; i see you have >>KMP but not Boyer-Moore for example and i am not sure what the >>repurcassions of above approach are etc etc. > > > This is a weakness of the current implementation, it could be > addresses via the other method that I proposed. The current patch > doesn't allow for random access over fragment borders which means > that Boyer-Moore would require a temporary buffer with a size of > the pattern length in order to do random access over multiple > fragments. However, I haven't seen any infrastructure yet that can > handle non-linear data with bm wihout a complete prefetch in the > beginning though. You could still implement a bm by either using a > naive search at the borders or simply define the limitation that you > can only look at the first fragment so you'd have to linearize. For small pattern and long packets, such pattern searching on the fragment borders doesn't really hurt the performance. Anyway the matter of having several algorithms will let users choose that one that suits better their needs. boyer-moore (BM) and other variants are definitely a must to have. I'm still reading some papers about string matching and practical applications (p2p traffic recognition based on string matching, ids, etc etc) and the most interesting practical results come always from the use of BM friends. >>I think the best approach would be to first linearize then search. > > > This is what I'm trying to avoid. ;-> sure, agree with Thomas. Netfilter used to follow this approach in early 2.6 kernels and Patrick McHardy demostrated with some oprofile stuff that skb_copy_bits decreased performance. I'm not familiar with those problems jamal has mentioned though, could they really affect the string matching infrastructure in some way? I truly prefer avoiding linearizing skb's. >>The only other comment i have is on the patch you called naive regexp; >>I think you should probably call it something else instead of regexp >>since you invented it. > > > I was never good at names, any suggestions? nor me, i'd propose flamenco-dancing-regexp ;->. -- Pablo From pablo@eurodev.net Sat May 28 05:58:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 05:58:43 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SCwdXq012095 for ; Sat, 28 May 2005 05:58:40 -0700 Received: from [85.136.96.216] by smtp06.retemail.es (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050528125749.REHR1136.smtp06.retemail.es@[85.136.96.216]>; Sat, 28 May 2005 14:57:49 +0200 Message-ID: <42986AFD.6060107@eurodev.net> Date: Sat, 28 May 2005 14:58:37 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Pablo Neira CC: Thomas Graf , jamal , netdev@oss.sgi.com Subject: Re: [RFC] textsearch infrastructure et al v2 References: <20050527224725.GG15391@postel.suug.ch> <1117281581.6251.68.camel@localhost.localdomain> <20050528123542.GR15391@postel.suug.ch> <42986A85.9060001@eurodev.net> In-Reply-To: <42986A85.9060001@eurodev.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 512 Lines: 15 Pablo Neira wrote: >> Same for my infrastructure with the difference that libqsearch uses >> a single input buffer so no chance for non-linear data. > > > hm, i don't understand quite well, i bet that libqsearch was already > fragment-aware. Anyway the main difference is that libqsearch wasn't > designed to be used in user space so, for example, it needed a complete > rework to reduce dynamic memory allocations. sorry, i meant '/s/wasn't/was/g'. libqsearch was designed to be used my snort. -- Pablo From pablo@eurodev.net Sat May 28 05:58:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 05:58:51 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SCwlXq012180 for ; Sat, 28 May 2005 05:58:47 -0700 Received: from [85.136.96.216] by smtp06.retemail.es (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050528125756.REJN1136.smtp06.retemail.es@[85.136.96.216]>; Sat, 28 May 2005 14:57:56 +0200 Message-ID: <42986B0B.8020608@eurodev.net> Date: Sat, 28 May 2005 14:58:51 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Pablo Neira CC: Thomas Graf , jamal , netdev@oss.sgi.com Subject: Re: [RFC] textsearch infrastructure et al v2 References: <20050527224725.GG15391@postel.suug.ch> <1117281581.6251.68.camel@localhost.localdomain> <20050528123542.GR15391@postel.suug.ch> <42986A85.9060001@eurodev.net> In-Reply-To: <42986A85.9060001@eurodev.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 512 Lines: 15 Pablo Neira wrote: >> Same for my infrastructure with the difference that libqsearch uses >> a single input buffer so no chance for non-linear data. > > > hm, i don't understand quite well, i bet that libqsearch was already > fragment-aware. Anyway the main difference is that libqsearch wasn't > designed to be used in user space so, for example, it needed a complete > rework to reduce dynamic memory allocations. sorry, i meant '/s/wasn't/was/g'. libqsearch was designed to be used by snort. -- Pablo From rich@phekda.gotadsl.co.uk Sat May 28 06:29:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 06:29:34 -0700 (PDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SDTTXq013964 for ; Sat, 28 May 2005 06:29:29 -0700 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-115-146.dyn.gotadsl.co.uk [82.133.115.146]) by smtp.nildram.co.uk (Postfix) with ESMTP id 6A588252109; Sat, 28 May 2005 14:28:34 +0100 (BST) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 4E921381DF; Sat, 28 May 2005 14:28:37 +0100 (BST) Message-ID: <429871F9.6040305@phekda.gotadsl.co.uk> Date: Sat, 28 May 2005 14:28:25 +0100 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Ben Greear Cc: Francois Romieu , Linux netdev Subject: Re: [PATCH] r8169: support restricting speed+duplex in autonegotiation References: <4297A0F7.5070209@phekda.gotadsl.co.uk> <4297B479.1080404@candelatech.com> In-Reply-To: <4297B479.1080404@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 2638 Lines: 75 Hello. Ben Greear wrote: > Richard Dawe wrote: > >> Hello. >> >> Attached is a patch for drivers/net/r8169.c against Linux 2.6.11 that >> allows adjustment of the speed and duplex advertised via >> autonegotiation. Example usage: >> >> ethtool -s eth0 autoneg on speed 10 duplex half [snip] >> r8169: Allow adjustment of speed and duplex advertised via >> autonegotiation >> >> Signed-off-by: Richard Dawe >> >> >> ------------------------------------------------------------------------ >> >> --- r8169.c.orig 2005-05-27 21:12:21.000000000 +0100 >> +++ r8169.c 2005-05-27 22:14:59.000000000 +0100 [snip] >> @@ -579,6 +583,23 @@ static void rtl8169_link_option(int idx, >> *autoneg = p->autoneg; >> *speed = p->speed; >> *duplex = p->duplex; >> + >> + if (p->media == _10_Half) >> + *advertising = ADVERTISED_10baseT_Half; >> + if (p->media == _10_Full) >> + *advertising = ADVERTISED_10baseT_Full; >> + if (p->media == _100_Half) >> + *advertising = ADVERTISED_100baseT_Half; >> + if (p->media == _100_Full) >> + *advertising = ADVERTISED_100baseT_Full; >> + if (p->media == _1000_Full) >> + *advertising = ADVERTISED_1000baseT_Full; >> + if (p->media == 0xff) >> + *advertising = ADVERTISED_10baseT_Half | >> + ADVERTISED_10baseT_Full | >> + ADVERTISED_100baseT_Half | >> + ADVERTISED_100baseT_Full | >> + ADVERTISED_1000baseT_Full; >> } > > > So, is there no way to advert just 100Mbps-half and -full ? > > Seems like you should be able to set each flag by itself and > create a bit-mask of the particular flags that you want... This particular code is to support the "media" option for the r8169 module. The "media" option is marked as deprecated in favour of ethtool. It looks like you could control what is advertised by using the ethool ioctls, since you can pass a bitmask to that. I can't see a way to do that with the ethtool command, since you can only specify one pair of "speed" and "duplex" arguments. One thing I forgot to mention in my mail is that there is no way of disabling autonegotiation with the r8169 driver. I started working on this, but I don't know how to force the PHY to a particular speed+duplex combination with autonegotation switched off. I'm guessing that autonegotiation enabled with one advertised speed+duplex != fixed speed+duplex. Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From cavok@tiscali.it Sat May 28 06:33:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 06:34:02 -0700 (PDT) Received: from mail.netline.it ([217.19.149.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4SDXsXq014635 for ; Sat, 28 May 2005 06:33:56 -0700 Received: (qmail 91493 invoked by uid 106); 28 May 2005 13:32:00 -0000 Received: from cavok@tiscali.it by mail.netline.it by uid 0 with qmail-scanner-1.22 (clamdscan: 0.73. Clear:RC:0(82.50.155.115):. Processed in 0.02317 secs); 28 May 2005 13:32:00 -0000 Received: from unknown (HELO raptus.dandreoli.com) (cavok@dandreoli.com@82.50.155.115) by mail.netline.it with SMTP; 28 May 2005 13:31:59 -0000 Received: by raptus.dandreoli.com (Postfix, from userid 1000) id 492591FDE9; Sat, 28 May 2005 15:33:01 +0200 (CEST) Date: Sat, 28 May 2005 15:33:01 +0200 From: Domenico Andreoli To: Jeff Garzik Cc: Netdev , Linux Kernel Subject: Re: netdev-2.6, wireless queues updated Message-ID: <20050528133301.GA30966@raptus.dandreoli.com> Mail-Followup-To: Jeff Garzik , Netdev , Linux Kernel References: <4297E93D.2060003@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4297E93D.2060003@pobox.com> User-Agent: Mutt/1.5.9i X-archive-position: 1838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cavok@libero.it Precedence: bulk X-list: netdev Content-Length: 952 Lines: 25 On Fri, May 27, 2005 at 11:45:01PM -0400, Jeff Garzik wrote: > > And finally a patch containing _only_ the changes on the we18-ieee80211 > branch, > http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.12-rc5-git2-ieee80211-1.patch.bz2 jeff, i am using a separate ipw2200 1.0.4 module with the proper hotplug firmware. after i read this message i wanted to try your patch but during the build i realized that you may have merged a different version (indeed it looks like 1.0.0). i don't really know what would be happened after reboot, using driver 1.0.0 and firmware for 1.0.4. i'd put a big notice in the help of ipw2* modules about matching driver and firmware versions. mixing them is probably a bad gift to your hardware. yes, people should read those readmes. cheers domenico -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 From tgraf@suug.ch Sat May 28 06:58:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 06:58:50 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SDwgXq015790 for ; Sat, 28 May 2005 06:58:45 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B95921C0EB; Sat, 28 May 2005 15:58:13 +0200 (CEST) Date: Sat, 28 May 2005 15:58:13 +0200 From: Thomas Graf To: Pablo Neira Cc: jamal , netdev@oss.sgi.com Subject: Re: [RFC] textsearch infrastructure et al v2 Message-ID: <20050528135813.GS15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> <1117281581.6251.68.camel@localhost.localdomain> <20050528123542.GR15391@postel.suug.ch> <42986A85.9060001@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42986A85.9060001@eurodev.net> X-archive-position: 1839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3039 Lines: 71 * Pablo Neira <42986A85.9060001@eurodev.net> 2005-05-28 14:56 > hm, i don't understand quite well, i bet that libqsearch was already > fragment-aware. I'll rephrase, libqsearch, according to my understanding, is not able to do optimized scanning over borders, i.e. it uses the same naive approach as your proposal. This isn't necessarly a weakness, it heavly depends on the length of the pattern and the amount of fragments. One of the major differences between libqsearch and the textsearch I propose is that libqsearch implements "jokers", a subset of what ts_regexp.c does. This heavly complicates their reference implementation of bm. Again, this isn't necessarly a weakness, since the framework doesn't require the algorithm to actually implement these. I cannot really tell which of the proposals we have right now is the best/fastest/cleanest/fanciest/whatever. For that reason I decided to transfer as much responsibility as possibly away from the core into the actual algorithms, respectively made it configureable via callback functions. It is still possible to write a ts_(kmp|bm)_state.c which saves the state of the scanning progress but other than in libqsearch this is not a requirement. > For small pattern and long packets, such pattern searching on the > fragment borders doesn't really hurt the performance. Exactly. > boyer-moore (BM) and other variants are definitely a must to have. I'm > still reading some papers about string matching and practical > applications (p2p traffic recognition based on string matching, ids, etc > etc) and the most interesting practical results come always from the use > of BM friends. Absolultely, I implemented KMP because it doesn't require random access to the text and thus serves well as a reference implementation. I'll be glad to see your BM ported. > I'm not familiar with those problems jamal has mentioned though, could > they really affect the string matching infrastructure in some way? I > truly prefer avoiding linearizing skb's. I think we have to differ between non-linear skbs which we should have without linearization and the scanning through real fragments. In order to make some progress we have to answer these questions: * Do we want to be able to search on non-linear data in general? I say: yes * Do we want to be able to search on non-linear data which is not completely available and/or present at the time the search starts? In other words, do we want a search to be interruptable to continue later on. e.g. search over multiple skbs without queueing them up. I say: no * Do we want to provide random access to the text to be searched? If so, optionally or as a requirement? This merely has impact on a) BM could be efficiently implemented w/o naive scanning around the borders and b) requires the text segments to be completely maped/prepare at the risk they'll never be used. [0] I say: probably no [0] This impact can be limited by having the user specify strict searching area limits. From romieu@fr.zoreil.com Sat May 28 07:45:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 07:45:07 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SEj3Xq017210 for ; Sat, 28 May 2005 07:45:04 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4SEgCOK017664; Sat, 28 May 2005 16:42:12 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4SEg7AN017663; Sat, 28 May 2005 16:42:07 +0200 Date: Sat, 28 May 2005 16:42:07 +0200 From: Francois Romieu To: Richard Dawe Cc: Ben Greear , Linux netdev Subject: Re: [PATCH] r8169: support restricting speed+duplex in autonegotiation Message-ID: <20050528144207.GA17021@electric-eye.fr.zoreil.com> References: <4297A0F7.5070209@phekda.gotadsl.co.uk> <4297B479.1080404@candelatech.com> <429871F9.6040305@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429871F9.6040305@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 568 Lines: 15 Richard Dawe : [...] > This particular code is to support the "media" option for the r8169 > module. The "media" option is marked as deprecated in favour of ethtool. The current code is supposed to provide via ethtool the same function that the media option did in Realtek's version of the driver (i.e. mostly a current 'ethtool -s ethX autoneg off speed foo duplex bar'). Afaik, neither in Realtek's code nor in the current in-kernel driver does the (obsolescent) "media" code do what one would expect from a "media" option. -- Ueimor From hadi@cyberus.ca Sat May 28 09:01:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 09:01:39 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SG1ZXq024132 for ; Sat, 28 May 2005 09:01:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Dc3jv-0000tB-Pg for netdev@oss.sgi.com; Sat, 28 May 2005 10:00:43 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dc3jw-0007yo-Rs; Sat, 28 May 2005 12:00:45 -0400 Subject: Re: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050528121827.GQ15391@postel.suug.ch> References: <20050527125010.GO15391@postel.suug.ch> <1117202331.6383.39.camel@localhost.localdomain> <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> <1117242749.6251.15.camel@localhost.localdomain> <20050528012810.GN15391@postel.suug.ch> <1117244893.6251.41.camel@localhost.localdomain> <20050528121827.GQ15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Sat, 28 May 2005 12:00:41 -0400 Message-Id: <1117296041.19563.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 482 Lines: 19 On Sat, 2005-28-05 at 14:18 +0200, Thomas Graf wrote: > I wanted to have some time for testing today without the need > to resubmit the patches. ;-> > fair enough ;-> > I just tested both patches for about 30 minutes. Everything OK. Feel > free to apply the patches. We have another problem. What tree is this against? Both patches have failures patching against latest davem and linus git trees. I am kind of distracted right now but I could fix this later. cheers, jamal From tgraf@suug.ch Sat May 28 09:17:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 09:17:11 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SGH6Xq025108 for ; Sat, 28 May 2005 09:17:07 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id D75291C0EB; Sat, 28 May 2005 18:16:37 +0200 (CEST) Date: Sat, 28 May 2005 18:16:37 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting Message-ID: <20050528161637.GT15391@postel.suug.ch> References: <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> <1117242749.6251.15.camel@localhost.localdomain> <20050528012810.GN15391@postel.suug.ch> <1117244893.6251.41.camel@localhost.localdomain> <20050528121827.GQ15391@postel.suug.ch> <1117296041.19563.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117296041.19563.6.camel@localhost.localdomain> X-archive-position: 1842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 917 Lines: 21 * jamal <1117296041.19563.6.camel@localhost.localdomain> 2005-05-28 12:00 > > I just tested both patches for about 30 minutes. Everything OK. Feel > > free to apply the patches. > > We have another problem. What tree is this against? Both patches have > failures patching against latest davem and linus git trees. It's against my davem-pending tree which should reflect the current state of davem's tree so they _should_ apply on his side. In this specific case you're probably missing the neighbour table patches. Basically I produce diffs this way: separate tree per patchset -> merge into testing tree -> testing period -. merge into $person-pending -> extraction of patches and submission. I was trying to get some more quality control into my workflow, so I started testing patches for 3-4 weeks to avoid fallouts but apparently this is failing miserably at the moment due to some broken scripts of mine. From tgraf@suug.ch Sat May 28 09:26:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 09:26:57 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SGQqXq025894 for ; Sat, 28 May 2005 09:26:53 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 3F1401C0EB; Sat, 28 May 2005 18:26:24 +0200 (CEST) Date: Sat, 28 May 2005 18:26:24 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] [DECNET] Remove unnecessary initilization of unused variable entries Message-ID: <20050528162624.GU15391@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 1843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 954 Lines: 27 This patch was supposed to be part of the neighbour tables related patchset but apparently got lost. Signed-off-by: Thomas Graf --- commit eb870ca30d39dd41d9e70103aeef4d9c6e896697 tree 9a945f37582c6f1a503366fa0831916d99cba013 parent 31006b6a5e72afbc76f95fe778e6370dd820dda0 author Thomas Graf Sat, 28 May 2005 18:21:48 +0200 committer Thomas Graf Sat, 28 May 2005 18:21:48 +0200 net/decnet/dn_neigh.c | 1 - 1 files changed, 1 deletion(-) Index: net/decnet/dn_neigh.c =================================================================== --- 4df388ef25005542b65fc297e0d1fc45acbd1d5a/net/decnet/dn_neigh.c (mode:100644) +++ 9a945f37582c6f1a503366fa0831916d99cba013/net/decnet/dn_neigh.c (mode:100644) @@ -101,7 +101,6 @@ .id = "dn_neigh_cache", .parms ={ .tbl = &dn_neigh_table, - .entries = 0, .base_reachable_time = 30 * HZ, .retrans_time = 1 * HZ, .gc_staletime = 60 * HZ, From rich@phekda.gotadsl.co.uk Sat May 28 13:40:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 13:40:31 -0700 (PDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SKeNXq004902 for ; Sat, 28 May 2005 13:40:24 -0700 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-102-176.dyn.gotadsl.co.uk [82.133.102.176]) by smtp.nildram.co.uk (Postfix) with ESMTP id 18D4324F4EF; Sat, 28 May 2005 21:39:29 +0100 (BST) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id BC1A7381DF; Sat, 28 May 2005 21:39:31 +0100 (BST) Message-ID: <4298D6F9.7030608@phekda.gotadsl.co.uk> Date: Sat, 28 May 2005 21:39:21 +0100 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: Ben Greear , Linux netdev Subject: Re: [PATCH] r8169: support restricting speed+duplex in autonegotiation References: <4297A0F7.5070209@phekda.gotadsl.co.uk> <4297B479.1080404@candelatech.com> <429871F9.6040305@phekda.gotadsl.co.uk> <20050528144207.GA17021@electric-eye.fr.zoreil.com> In-Reply-To: <20050528144207.GA17021@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 951 Lines: 31 Hello. Francois Romieu wrote: > Richard Dawe : > [...] > >>This particular code is to support the "media" option for the r8169 >>module. The "media" option is marked as deprecated in favour of ethtool. > > > The current code is supposed to provide via ethtool the same function that > the media option did in Realtek's version of the driver (i.e. mostly a > current 'ethtool -s ethX autoneg off speed foo duplex bar'). AFAICS the current r8169 driver always autonegotiates in xMII mode. > Afaik, neither in Realtek's code nor in the current in-kernel driver does > the (obsolescent) "media" code do what one would expect from a "media" > option. My patch doesn't change the behaviour of the "media" option. Is the "media" part of the patch confusing? Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From baruch@ev-en.org Sat May 28 14:20:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 14:20:10 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SLK0Xq006247 for ; Sat, 28 May 2005 14:20:00 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 5DEEC11A7B2; Sun, 29 May 2005 00:19:07 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id A703011A751; Sun, 29 May 2005 00:19:03 +0300 (IDT) Message-ID: <4298E045.9050009@ev-en.org> Date: Sat, 28 May 2005 22:19:01 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, Stephen Hemminger Cc: Doug Leith Subject: Comparison of several congestion control algorithms X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 1845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 368 Lines: 11 Hello, I wanted to point you to a comparison of congestion control algorithm done at the Hamilton Institute. These experiments compare Scalable-TCP, High-Speed TCP, FAST-TCP, BIC-TCP, H-TCP and Standard TCP. They compared fairness, compatibility with TCP and link utilisation. You can find the results and a report at http://hamilton.ie/net/eval/ Regards, Baruch From buytenh@wantstofly.org Sat May 28 16:13:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 16:13:10 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SND4Xq010580 for ; Sat, 28 May 2005 16:13:05 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 4D868945C3; Sun, 29 May 2005 01:12:10 +0200 (MEST) Date: Sun, 29 May 2005 01:12:10 +0200 From: Lennert Buytenhek To: akepner@sgi.com Cc: netdev@oss.sgi.com, jbarnes@engr.sgi.com, gnb@sgi.com Subject: Re: [PATCH] use mmiowb in tg3_poll Message-ID: <20050528231209.GA8456@xi.wantstofly.org> References: <200410211628.06906.jbarnes@engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 1846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 805 Lines: 22 On Fri, Oct 22, 2004 at 01:51:01PM -0700, akepner@sgi.com wrote: > Returning from tg3_poll() without flushing the PIO write which > reenables interrupts can result in lower cpu utilization and higher > throughput. I'm quite curious what kind of MMIO read latency you see on your Altix boxen. This app is quite useful for determining those figures on x86{,_64} machines: http://svn.gnumonks.org/trunk/mmio_test/mmio_test.c I'm not sure if it'll run on Itanium out of the box (it currently assumes PAGE_SIZE <= 4096, you'd probably need to tweak rdtscl(), and if there's a weird phys:pci address correspondence you might have to teach it about that as well), but it would be nice if you could give an approximate indication of exactly how expensive an MMIO read is on your platform. cheers, Lennert From domen@nd47.coderock.org Sat May 28 16:17:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 16:18:03 -0700 (PDT) Received: from trashy.coderock.org (coderock.org [193.77.147.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SNHqXq011083 for ; Sat, 28 May 2005 16:17:53 -0700 Received: by trashy.coderock.org (Postfix, from userid 780) id 66B861E4D7; Sun, 29 May 2005 01:17:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 5376F1E3F8; Sun, 29 May 2005 01:16:59 +0200 (CEST) Received: from nd47.coderock.org (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id CA11F1E3A4; Sun, 29 May 2005 01:16:54 +0200 (CEST) Received: (from domen@localhost) by nd47.coderock.org (8.13.3/8.13.3/Submit) id j4SNGs6J013534; Sun, 29 May 2005 01:16:54 +0200 Message-Id: <20050528231654.365592000@nd47.coderock.org> Date: Sun, 29 May 2005 01:16:55 +0200 From: domen@coderock.org To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, Tobias Klauser , domen@coderock.org Subject: [patch 1/1] Use pci_set_dma_mask() instead of direct assignment of DMA mask Content-Disposition: inline; filename=dma_mask-drivers_net_amd8111e X-archive-position: 1847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1329 Lines: 47 From: Tobias Klauser The amd8111e driver directly assigns the DMA mask to the dma_mask member of the struct pci_dev instead of using pci_set_dma_mask(). This makes the call to pci_dma_supported() redundant as pci_set_dma_mask() does this check. I do not own this device so I only compile-tested this patch. Signed-off-by: Tobias Klauser Signed-off-by: Domen Puncer --- amd8111e.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) Index: quilt/drivers/net/amd8111e.c =================================================================== --- quilt.orig/drivers/net/amd8111e.c +++ quilt/drivers/net/amd8111e.c @@ -87,6 +87,7 @@ Revision History: #include #include #include +#include #include #include @@ -2002,12 +2003,11 @@ static int __devinit amd8111e_probe_one( } /* Initialize DMA */ - if(!pci_dma_supported(pdev, 0xffffffff)){ + if (pci_set_dma_mask(pdev, DMA_32BIT_MASK) < 0) { printk(KERN_ERR "amd8111e: DMA not supported," "exiting.\n"); - goto err_free_reg; - } else - pdev->dma_mask = 0xffffffff; + goto err_free_reg; + } reg_addr = pci_resource_start(pdev, 0); reg_len = pci_resource_len(pdev, 0); -- From domen@nd47.coderock.org Sat May 28 16:19:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 16:19:55 -0700 (PDT) Received: from trashy.coderock.org (coderock.org [193.77.147.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4SNJcXq015213 for ; Sat, 28 May 2005 16:19:39 -0700 Received: by trashy.coderock.org (Postfix, from userid 780) id 71F0E1E4C4; Sun, 29 May 2005 01:18:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 389ED1E3A4; Sun, 29 May 2005 01:18:41 +0200 (CEST) Received: from nd47.coderock.org (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 2B0291E3BE; Sun, 29 May 2005 01:16:48 +0200 (CEST) Received: (from domen@localhost) by nd47.coderock.org (8.13.3/8.13.3/Submit) id j4SNGlCR013437; Sun, 29 May 2005 01:16:47 +0200 Message-Id: <20050528231647.466278000@nd47.coderock.org> Date: Sun, 29 May 2005 01:16:47 +0200 From: domen@coderock.org To: perex@suse.cz Cc: jgarzik@pobox.com, netdev@oss.sgi.com, Christophe Lucas , domen@coderock.org Subject: [patch 1/1] printk : drivers/net/hp100.c Content-Disposition: inline; filename=printk-drivers_net_hp100 X-archive-position: 1848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 44168 Lines: 1055 From: Christophe Lucas printk() calls should include appropriate KERN_* constant. Signed-off-by: Christophe Lucas Signed-off-by: Domen Puncer --- hp100.c | 266 ++++++++++++++++++++++++++++++++-------------------------------- 1 files changed, 133 insertions(+), 133 deletions(-) Index: quilt/drivers/net/hp100.c =================================================================== --- quilt.orig/drivers/net/hp100.c +++ quilt/drivers/net/hp100.c @@ -406,7 +406,7 @@ struct net_device * __init hp100_probe(i #ifdef HP100_DEBUG_B hp100_outw(0x4200, TRACE); - printk("hp100: %s: probe\n", dev->name); + printk(KERN_DEBUG "hp100: %s: probe\n", dev->name); #endif if (unit >= 0) { @@ -447,7 +447,7 @@ static int __devinit hp100_probe1(struct #ifdef HP100_DEBUG_B hp100_outw(0x4201, TRACE); - printk("hp100: %s: probe1\n", dev->name); + printk(KERN_DEBUG "hp100: %s: probe1\n", dev->name); #endif /* memory region for programmed i/o */ @@ -460,13 +460,13 @@ static int __devinit hp100_probe1(struct chip = hp100_inw(PAGING) & HP100_CHIPID_MASK; #ifdef HP100_DEBUG if (chip == HP100_CHIPID_SHASTA) - printk("hp100: %s: Shasta Chip detected. (This is a pre 802.12 chip)\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Shasta Chip detected. (This is a pre 802.12 chip)\n", dev->name); else if (chip == HP100_CHIPID_RAINIER) - printk("hp100: %s: Rainier Chip detected. (This is a pre 802.12 chip)\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Rainier Chip detected. (This is a pre 802.12 chip)\n", dev->name); else if (chip == HP100_CHIPID_LASSEN) - printk("hp100: %s: Lassen Chip detected.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Lassen Chip detected.\n", dev->name); else - printk("hp100: %s: Warning: Unknown CASCADE chip (id=0x%.4x).\n", dev->name, chip); + printk(KERN_DEBUG "hp100: %s: Warning: Unknown CASCADE chip (id=0x%.4x).\n", dev->name, chip); #endif dev->base_addr = ioaddr; @@ -523,7 +523,7 @@ static int __devinit hp100_probe1(struct if (local_mode < 1 || local_mode > 4) local_mode = 1; /* default */ #ifdef HP100_DEBUG - printk("hp100: %s: original LSW = 0x%x\n", dev->name, + printk(KERN_DEBUG "hp100: %s: original LSW = 0x%x\n", dev->name, hp100_inw(OPTION_LSW)); #endif @@ -531,17 +531,17 @@ static int __devinit hp100_probe1(struct hp100_outw(HP100_MEM_EN | HP100_RESET_LB, OPTION_LSW); hp100_outw(HP100_IO_EN | HP100_SET_LB, OPTION_LSW); hp100_outw(HP100_BM_WRITE | HP100_BM_READ | HP100_RESET_HB, OPTION_LSW); - printk("hp100: IO mapped mode forced.\n"); + printk(KERN_INFO "hp100: IO mapped mode forced.\n"); } else if (local_mode == 2) { hp100_outw(HP100_MEM_EN | HP100_SET_LB, OPTION_LSW); hp100_outw(HP100_IO_EN | HP100_SET_LB, OPTION_LSW); hp100_outw(HP100_BM_WRITE | HP100_BM_READ | HP100_RESET_HB, OPTION_LSW); - printk("hp100: Shared memory mode requested.\n"); + printk(KERN_INFO "hp100: Shared memory mode requested.\n"); } else if (local_mode == 4) { if (chip == HP100_CHIPID_LASSEN) { hp100_outw(HP100_BM_WRITE | HP100_BM_READ | HP100_SET_HB, OPTION_LSW); hp100_outw(HP100_IO_EN | HP100_MEM_EN | HP100_RESET_LB, OPTION_LSW); - printk("hp100: Busmaster mode requested.\n"); + printk(KERN_INFO "hp100: Busmaster mode requested.\n"); } local_mode = 1; } @@ -552,7 +552,7 @@ static int __devinit hp100_probe1(struct if ((lsw & HP100_IO_EN) && (~lsw & HP100_MEM_EN) && (~lsw & (HP100_BM_WRITE | HP100_BM_READ))) { #ifdef HP100_DEBUG - printk("hp100: %s: IO_EN bit is set on card.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: IO_EN bit is set on card.\n", dev->name); #endif local_mode = 3; } else if (chip == HP100_CHIPID_LASSEN && @@ -567,13 +567,13 @@ static int __devinit hp100_probe1(struct /* Gracefully fallback to shared memory */ goto busmasterfail; } - printk("hp100: Busmaster mode enabled.\n"); + printk(KERN_INFO "hp100: Busmaster mode enabled.\n"); hp100_outw(HP100_MEM_EN | HP100_IO_EN | HP100_RESET_LB, OPTION_LSW); } else { busmasterfail: #ifdef HP100_DEBUG - printk("hp100: %s: Card not configured for BM or BM not supported with this card.\n", dev->name); - printk("hp100: %s: Trying shared memory mode.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Card not configured for BM or BM not supported with this card.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Trying shared memory mode.\n", dev->name); #endif /* In this case, try shared memory mode */ local_mode = 2; @@ -582,7 +582,7 @@ static int __devinit hp100_probe1(struct } } #ifdef HP100_DEBUG - printk("hp100: %s: new LSW = 0x%x\n", dev->name, hp100_inw(OPTION_LSW)); + printk(KERN_DEBUG "hp100: %s: new LSW = 0x%x\n", dev->name, hp100_inw(OPTION_LSW)); #endif /* Check for shared memory on the card, eventually remap it */ @@ -599,7 +599,7 @@ static int __devinit hp100_probe1(struct mem_ptr_phys &= ~0x1fff; /* 8k alignment */ if (bus == HP100_BUS_ISA && (mem_ptr_phys & ~0xfffff) != 0) { - printk("hp100: Can only use programmed i/o mode.\n"); + printk(KERN_INFO "hp100: Can only use programmed i/o mode.\n"); mem_ptr_phys = 0; mem_mapped = 0; local_mode = 3; /* Use programmed i/o */ @@ -612,18 +612,18 @@ static int __devinit hp100_probe1(struct for (virt_memory_size = memory_size; virt_memory_size > 16383; virt_memory_size >>= 1) { if ((mem_ptr_virt = ioremap((u_long) mem_ptr_phys, virt_memory_size)) == NULL) { #ifdef HP100_DEBUG - printk("hp100: %s: ioremap for 0x%x bytes high PCI memory at 0x%lx failed\n", dev->name, virt_memory_size, mem_ptr_phys); + printk(KERN_DEBUG "hp100: %s: ioremap for 0x%x bytes high PCI memory at 0x%lx failed\n", dev->name, virt_memory_size, mem_ptr_phys); #endif } else { #ifdef HP100_DEBUG - printk("hp100: %s: remapped 0x%x bytes high PCI memory at 0x%lx to %p.\n", dev->name, virt_memory_size, mem_ptr_phys, mem_ptr_virt); + printk(KERN_DEBUG "hp100: %s: remapped 0x%x bytes high PCI memory at 0x%lx to %p.\n", dev->name, virt_memory_size, mem_ptr_phys, mem_ptr_virt); #endif break; } } if (mem_ptr_virt == NULL) { /* all ioremap tries failed */ - printk("hp100: Failed to ioremap the PCI card memory. Will have to use i/o mapped mode.\n"); + printk(KERN_WARNING "hp100: Failed to ioremap the PCI card memory. Will have to use i/o mapped mode.\n"); local_mode = 3; virt_memory_size = 0; } @@ -634,7 +634,7 @@ static int __devinit hp100_probe1(struct mem_mapped = 0; mem_ptr_phys = 0; mem_ptr_virt = NULL; - printk("hp100: Using (slow) programmed i/o mode.\n"); + printk(KERN_INFO "hp100: Using (slow) programmed i/o mode.\n"); } /* Initialise the "private" data structure for this card. */ @@ -716,7 +716,7 @@ static int __devinit hp100_probe1(struct lp->whatever_offset = ((u_long) page_baddr) - ((u_long) lp->page_vaddr_algn); #ifdef HP100_DEBUG_BM - printk("hp100: %s: Reserved DMA memory from 0x%x to 0x%x\n", dev->name, (u_int) lp->page_vaddr_algn, (u_int) lp->page_vaddr_algn + MAX_RINGSIZE); + printk(KERN_DEBUG "hp100: %s: Reserved DMA memory from 0x%x to 0x%x\n", dev->name, (u_int) lp->page_vaddr_algn, (u_int) lp->page_vaddr_algn + MAX_RINGSIZE); #endif lp->rxrcommit = lp->txrcommit = 0; lp->rxrhead = lp->rxrtail = &(lp->rxring[0]); @@ -734,7 +734,7 @@ static int __devinit hp100_probe1(struct lp->lan_type = hp100_sense_lan(dev); /* Print out a message what about what we think we have probed. */ - printk("hp100: at 0x%x, IRQ %d, ", ioaddr, dev->irq); + printk(KERN_INFO "hp100: at 0x%x, IRQ %d, ", ioaddr, dev->irq); switch (bus) { case HP100_BUS_EISA: printk("EISA"); @@ -749,7 +749,7 @@ static int __devinit hp100_probe1(struct printk(" bus, %dk SRAM (rx/tx %d%%).\n", lp->memory_size >> 10, lp->rx_ratio); if (lp->mode == 2) { /* memory mapped */ - printk("hp100: Memory area at 0x%lx-0x%lx", mem_ptr_phys, + printk(KERN_INFO "hp100: Memory area at 0x%lx-0x%lx", mem_ptr_phys, (mem_ptr_phys + (mem_ptr_phys > 0x100000 ? (u_long) lp->memory_size : 16 * 1024)) - 1); if (mem_ptr_virt) printk(" (virtual base %p)", mem_ptr_virt); @@ -760,7 +760,7 @@ static int __devinit hp100_probe1(struct dev->mem_end = mem_ptr_phys + lp->memory_size; } - printk("hp100: "); + printk(KERN_INFO "hp100: "); if (lp->lan_type != HP100_LAN_ERR) printk("Adapter is attached to "); switch (lp->lan_type) { @@ -792,7 +792,7 @@ static void hp100_hwinit(struct net_devi #ifdef HP100_DEBUG_B hp100_outw(0x4202, TRACE); - printk("hp100: %s: hwinit\n", dev->name); + printk(KERN_DEBUG "hp100: %s: hwinit\n", dev->name); #endif /* Initialise the card. -------------------------------------------- */ @@ -887,12 +887,12 @@ static void hp100_mmuinit(struct net_dev #ifdef HP100_DEBUG_B hp100_outw(0x4203, TRACE); - printk("hp100: %s: mmuinit\n", dev->name); + printk(KERN_DEBUG "hp100: %s: mmuinit\n", dev->name); #endif #ifdef HP100_DEBUG if (0 != (hp100_inw(OPTION_LSW) & HP100_HW_RST)) { - printk("hp100: %s: Not in reset when entering mmuinit. Fix me.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Not in reset when entering mmuinit. Fix me.\n", dev->name); return; } #endif @@ -985,7 +985,7 @@ static void hp100_mmuinit(struct net_dev recv_stop = (xmit_stop * (lp->rx_ratio) / 100) & ~(0x03ff); hp100_outw((pdl_stop >> 4) - 1, PDL_MEM_STOP); #ifdef HP100_DEBUG_BM - printk("hp100: %s: PDL_STOP = 0x%x\n", dev->name, pdl_stop); + printk(KERN_DEBUG "hp100: %s: PDL_STOP = 0x%x\n", dev->name, pdl_stop); #endif } else { /* ETR chip (Lassen) in busmaster mode */ @@ -996,16 +996,16 @@ static void hp100_mmuinit(struct net_dev hp100_outw(xmit_stop >> 4, TX_MEM_STOP); hp100_outw(recv_stop >> 4, RX_MEM_STOP); #ifdef HP100_DEBUG_BM - printk("hp100: %s: TX_STOP = 0x%x\n", dev->name, xmit_stop >> 4); - printk("hp100: %s: RX_STOP = 0x%x\n", dev->name, recv_stop >> 4); + printk(KERN_DEBUG "hp100: %s: TX_STOP = 0x%x\n", dev->name, xmit_stop >> 4); + printk(KERN_DEBUG "hp100: %s: RX_STOP = 0x%x\n", dev->name, recv_stop >> 4); #endif } else { /* Slave modes (memory mapped and programmed io) */ hp100_outw((((lp->memory_size * lp->rx_ratio) / 100) >> 4), RX_MEM_STOP); hp100_outw(((lp->memory_size - 1) >> 4), TX_MEM_STOP); #ifdef HP100_DEBUG - printk("hp100: %s: TX_MEM_STOP: 0x%x\n", dev->name, hp100_inw(TX_MEM_STOP)); - printk("hp100: %s: RX_MEM_STOP: 0x%x\n", dev->name, hp100_inw(RX_MEM_STOP)); + printk(KERN_DEBUG "hp100: %s: TX_MEM_STOP: 0x%x\n", dev->name, hp100_inw(TX_MEM_STOP)); + printk(KERN_DEBUG "hp100: %s: RX_MEM_STOP: 0x%x\n", dev->name, hp100_inw(RX_MEM_STOP)); #endif } @@ -1067,7 +1067,7 @@ static int hp100_open(struct net_device #ifdef HP100_DEBUG_B hp100_outw(0x4204, TRACE); - printk("hp100: %s: open\n", dev->name); + printk(KERN_DEBUG "hp100: %s: open\n", dev->name); #endif /* New: if bus is PCI or EISA, interrupts might be shared interrupts */ @@ -1075,7 +1075,7 @@ static int hp100_open(struct net_device lp->bus == HP100_BUS_PCI || lp->bus == HP100_BUS_EISA ? SA_SHIRQ : SA_INTERRUPT, "hp100", dev)) { - printk("hp100: %s: unable to get IRQ %d\n", dev->name, dev->irq); + printk(KERN_WARNING "hp100: %s: unable to get IRQ %d\n", dev->name, dev->irq); return -EAGAIN; } @@ -1104,7 +1104,7 @@ static int hp100_close(struct net_device #ifdef HP100_DEBUG_B hp100_outw(0x4205, TRACE); - printk("hp100: %s: close\n", dev->name); + printk(KERN_DEBUG "hp100: %s: close\n", dev->name); #endif hp100_page(PERFORMANCE); @@ -1120,7 +1120,7 @@ static int hp100_close(struct net_device free_irq(dev->irq, dev); #ifdef HP100_DEBUG - printk("hp100: %s: close LSW = 0x%x\n", dev->name, + printk(KERN_DEBUG "hp100: %s: close LSW = 0x%x\n", dev->name, hp100_inw(OPTION_LSW)); #endif @@ -1144,11 +1144,11 @@ static void hp100_init_pdls(struct net_d #ifdef HP100_DEBUG_B hp100_outw(0x4206, TRACE); - printk("hp100: %s: init pdls\n", dev->name); + printk(KERN_DEBUG "hp100: %s: init pdls\n", dev->name); #endif if (0 == lp->page_vaddr_algn) - printk("hp100: %s: Warning: lp->page_vaddr_algn not initialised!\n", dev->name); + printk(KERN_WARNING "hp100: %s: Warning: lp->page_vaddr_algn not initialised!\n", dev->name); else { /* pageptr shall point into the DMA accessible memory region */ /* we use this pointer to status the upper limit of allocated */ @@ -1188,7 +1188,7 @@ static int hp100_init_rxpdl(struct net_d /* pdlptr is starting address for this pdl */ if (0 != (((unsigned long) pdlptr) & 0xf)) - printk("hp100: %s: Init rxpdl: Unaligned pdlptr 0x%lx.\n", + printk(KERN_INFO "hp100: %s: Init rxpdl: Unaligned pdlptr 0x%lx.\n", dev->name, (unsigned long) pdlptr); ringptr->pdl = pdlptr + 1; @@ -1215,7 +1215,7 @@ static int hp100_init_txpdl(struct net_d register u32 * pdlptr) { if (0 != (((unsigned long) pdlptr) & 0xf)) - printk("hp100: %s: Init txpdl: Unaligned pdlptr 0x%lx.\n", dev->name, (unsigned long) pdlptr); + printk(KERN_INFO "hp100: %s: Init txpdl: Unaligned pdlptr 0x%lx.\n", dev->name, (unsigned long) pdlptr); ringptr->pdl = pdlptr; /* +1; */ ringptr->pdl_paddr = virt_to_whatever(dev, pdlptr); /* +1 */ @@ -1243,7 +1243,7 @@ static int hp100_build_rx_pdl(hp100_ring #ifdef HP100_DEBUG_B hp100_outw(0x4207, TRACE); - printk("hp100: %s: build rx pdl\n", dev->name); + printk(KERN_DEBUG "hp100: %s: build rx pdl\n", dev->name); #endif /* Allocate skb buffer of maximum size */ @@ -1271,7 +1271,7 @@ static int hp100_build_rx_pdl(hp100_ring * directly before the PDL. */ #ifdef HP100_DEBUG_BM - printk("hp100: %s: build_rx_pdl: PDH@0x%x, skb->data (len %d) at 0x%x\n", + printk(KERN_DEBUG "hp100: %s: build_rx_pdl: PDH@0x%x, skb->data (len %d) at 0x%x\n", dev->name, (u_int) ringptr->pdl, ((MAX_ETHER_SIZE + 2 + 3) / 4) * 4, (unsigned int) ringptr->skb->data); @@ -1286,7 +1286,7 @@ static int hp100_build_rx_pdl(hp100_ring #ifdef HP100_DEBUG_BM for (p = (ringptr->pdl); p < (ringptr->pdl + 5); p++) - printk("hp100: %s: Adr 0x%.8x = 0x%.8x\n", dev->name, (u_int) p, (u_int) * p); + printk(KERN_DEBUG "hp100: %s: Adr 0x%.8x = 0x%.8x\n", dev->name, (u_int) p, (u_int) * p); #endif return (1); } @@ -1296,7 +1296,7 @@ static int hp100_build_rx_pdl(hp100_ring * making the PDL only 1 fragment (i.e. the 4 byte packet status) */ #ifdef HP100_DEBUG_BM - printk("hp100: %s: build_rx_pdl: PDH@0x%x, No space for skb.\n", dev->name, (u_int) ringptr->pdl); + printk(KERN_DEBUG "hp100: %s: build_rx_pdl: PDH@0x%x, No space for skb.\n", dev->name, (u_int) ringptr->pdl); #endif ringptr->pdl[0] = 0x00010000; /* PDH: Count=1 Fragment */ @@ -1323,7 +1323,7 @@ static void hp100_rxfill(struct net_devi #ifdef HP100_DEBUG_B hp100_outw(0x4208, TRACE); - printk("hp100: %s: rxfill\n", dev->name); + printk(KERN_DEBUG "hp100: %s: rxfill\n", dev->name); #endif hp100_page(PERFORMANCE); @@ -1340,7 +1340,7 @@ static void hp100_rxfill(struct net_devi /* Hand this PDL over to the card */ /* Note: This needs performance page selected! */ #ifdef HP100_DEBUG_BM - printk("hp100: %s: rxfill: Hand to card: pdl #%d @0x%x phys:0x%x, buffer: 0x%x\n", + printk(KERN_DEBUG "hp100: %s: rxfill: Hand to card: pdl #%d @0x%x phys:0x%x, buffer: 0x%x\n", dev->name, lp->rxrcommit, (u_int) ringptr->pdl, (u_int) ringptr->pdl_paddr, (u_int) ringptr->pdl[3]); #endif @@ -1364,7 +1364,7 @@ static void hp100_BM_shutdown(struct net #ifdef HP100_DEBUG_B hp100_outw(0x4209, TRACE); - printk("hp100: %s: bm shutdown\n", dev->name); + printk(KERN_DEBUG "hp100: %s: bm shutdown\n", dev->name); #endif hp100_page(PERFORMANCE); @@ -1413,7 +1413,7 @@ static void hp100_BM_shutdown(struct net } if (time >= 10000) - printk("hp100: %s: BM shutdown error.\n", dev->name); + printk(KERN_INFO "hp100: %s: BM shutdown error.\n", dev->name); /* To ensure all bus master outloading activity has ceased, * wait until the Tx PDA count goes to zero or no more Tx space @@ -1445,7 +1445,7 @@ static int hp100_check_lan(struct net_de if (lp->lan_type < 0) { /* no LAN type detected yet? */ hp100_stop_interface(dev); if ((lp->lan_type = hp100_sense_lan(dev)) < 0) { - printk("hp100: %s: no connection found - check wire\n", dev->name); + printk(KERN_INFO "hp100: %s: no connection found - check wire\n", dev->name); hp100_start_interface(dev); /* 10Mb/s RX packets maybe handled */ return -EIO; } @@ -1471,7 +1471,7 @@ static int hp100_start_xmit_bm(struct sk #ifdef HP100_DEBUG_B hp100_outw(0x4210, TRACE); - printk("hp100: %s: start_xmit_bm\n", dev->name); + printk(KERN_DEBUG "hp100: %s: start_xmit_bm\n", dev->name); #endif if (skb == NULL) { @@ -1491,7 +1491,7 @@ static int hp100_start_xmit_bm(struct sk if (lp->txrtail->next == lp->txrhead) { /* No memory. */ #ifdef HP100_DEBUG - printk("hp100: %s: start_xmit_bm: No TX PDL available.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: start_xmit_bm: No TX PDL available.\n", dev->name); #endif /* not waited long enough since last tx? */ if (jiffies - dev->trans_start < HZ) @@ -1502,7 +1502,7 @@ static int hp100_start_xmit_bm(struct sk if (lp->lan_type == HP100_LAN_100 && lp->hub_status < 0) { /* we have a 100Mb/s adapter but it isn't connected to hub */ - printk("hp100: %s: login to 100Mb/s hub retry\n", dev->name); + printk(KERN_INFO "hp100: %s: login to 100Mb/s hub retry\n", dev->name); hp100_stop_interface(dev); lp->hub_status = hp100_login_to_vg_hub(dev, 0); hp100_start_interface(dev); @@ -1513,17 +1513,17 @@ static int hp100_start_xmit_bm(struct sk hp100_ints_on(); spin_unlock_irqrestore(&lp->lock, flags); if (i == HP100_LAN_ERR) - printk("hp100: %s: link down detected\n", dev->name); + printk(KERN_INFO "hp100: %s: link down detected\n", dev->name); else if (lp->lan_type != i) { /* cable change! */ /* it's very hard - all network settings must be changed!!! */ - printk("hp100: %s: cable change 10Mb/s <-> 100Mb/s detected\n", dev->name); + printk(KERN_INFO "hp100: %s: cable change 10Mb/s <-> 100Mb/s detected\n", dev->name); lp->lan_type = i; hp100_stop_interface(dev); if (lp->lan_type == HP100_LAN_100) lp->hub_status = hp100_login_to_vg_hub(dev, 0); hp100_start_interface(dev); } else { - printk("hp100: %s: interface reset\n", dev->name); + printk(KERN_INFO "hp100: %s: interface reset\n", dev->name); hp100_stop_interface(dev); if (lp->lan_type == HP100_LAN_100) lp->hub_status = hp100_login_to_vg_hub(dev, 0); @@ -1590,7 +1590,7 @@ static void hp100_clean_txring(struct ne #ifdef HP100_DEBUG_B hp100_outw(0x4211, TRACE); - printk("hp100: %s: clean txring\n", dev->name); + printk(KERN_DEBUG "hp100: %s: clean txring\n", dev->name); #endif /* How many PDLs have been transmitted? */ @@ -1598,12 +1598,12 @@ static void hp100_clean_txring(struct ne #ifdef HP100_DEBUG if (donecount > MAX_TX_PDL) - printk("hp100: %s: Warning: More PDLs transmitted than commited to card???\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Warning: More PDLs transmitted than commited to card???\n", dev->name); #endif for (; 0 != donecount; donecount--) { #ifdef HP100_DEBUG_BM - printk("hp100: %s: Free skb: data @0x%.8x txrcommit=0x%x TXPDL=0x%x, done=0x%x\n", + printk(KERN_DEBUG "hp100: %s: Free skb: data @0x%.8x txrcommit=0x%x TXPDL=0x%x, done=0x%x\n", dev->name, (u_int) lp->txrhead->skb->data, lp->txrcommit, hp100_inb(TX_PDL), donecount); #endif @@ -1627,7 +1627,7 @@ static int hp100_start_xmit(struct sk_bu #ifdef HP100_DEBUG_B hp100_outw(0x4212, TRACE); - printk("hp100: %s: start_xmit\n", dev->name); + printk(KERN_DEBUG "hp100: %s: start_xmit\n", dev->name); #endif if (skb == NULL) { @@ -1644,19 +1644,19 @@ static int hp100_start_xmit(struct sk_bu i = hp100_inl(TX_MEM_FREE) & 0x7fffffff; if (!(((i / 2) - 539) > (skb->len + 16) && (hp100_inb(TX_PKT_CNT) < 255))) { #ifdef HP100_DEBUG - printk("hp100: %s: start_xmit: tx free mem = 0x%x\n", dev->name, i); + printk(KERN_DEBUG "hp100: %s: start_xmit: tx free mem = 0x%x\n", dev->name, i); #endif /* not waited long enough since last failed tx try? */ if (jiffies - dev->trans_start < HZ) { #ifdef HP100_DEBUG - printk("hp100: %s: trans_start timing problem\n", + printk(KERN_DEBUG "hp100: %s: trans_start timing problem\n", dev->name); #endif return -EAGAIN; } if (lp->lan_type == HP100_LAN_100 && lp->hub_status < 0) { /* we have a 100Mb/s adapter but it isn't connected to hub */ - printk("hp100: %s: login to 100Mb/s hub retry\n", dev->name); + printk(KERN_DEBUG "hp100: %s: login to 100Mb/s hub retry\n", dev->name); hp100_stop_interface(dev); lp->hub_status = hp100_login_to_vg_hub(dev, 0); hp100_start_interface(dev); @@ -1667,17 +1667,17 @@ static int hp100_start_xmit(struct sk_bu hp100_ints_on(); spin_unlock_irqrestore(&lp->lock, flags); if (i == HP100_LAN_ERR) - printk("hp100: %s: link down detected\n", dev->name); + printk(KERN_DEBUG "hp100: %s: link down detected\n", dev->name); else if (lp->lan_type != i) { /* cable change! */ /* it's very hard - all network setting must be changed!!! */ - printk("hp100: %s: cable change 10Mb/s <-> 100Mb/s detected\n", dev->name); + printk(KERN_INFO "hp100: %s: cable change 10Mb/s <-> 100Mb/s detected\n", dev->name); lp->lan_type = i; hp100_stop_interface(dev); if (lp->lan_type == HP100_LAN_100) lp->hub_status = hp100_login_to_vg_hub(dev, 0); hp100_start_interface(dev); } else { - printk("hp100: %s: interface reset\n", dev->name); + printk(KERN_INFO "hp100: %s: interface reset\n", dev->name); hp100_stop_interface(dev); if (lp->lan_type == HP100_LAN_100) lp->hub_status = hp100_login_to_vg_hub(dev, 0); @@ -1691,7 +1691,7 @@ static int hp100_start_xmit(struct sk_bu for (i = 0; i < 6000 && (hp100_inb(OPTION_MSW) & HP100_TX_CMD); i++) { #ifdef HP100_DEBUG_TX - printk("hp100: %s: start_xmit: busy\n", dev->name); + printk(KERN_DEBUG "hp100: %s: start_xmit: busy\n", dev->name); #endif } @@ -1702,7 +1702,7 @@ static int hp100_start_xmit(struct sk_bu * when the current packet being transmitted on the wire is completed. */ hp100_outw(HP100_TX_COMPLETE, IRQ_STATUS); #ifdef HP100_DEBUG_TX - printk("hp100: %s: start_xmit: irq_status=0x%.4x, irqmask=0x%.4x, len=%d\n", + printk(KERN_DEBUG "hp100: %s: start_xmit: irq_status=0x%.4x, irqmask=0x%.4x, len=%d\n", dev->name, val, hp100_inw(IRQ_MASK), (int) skb->len); #endif @@ -1743,7 +1743,7 @@ static int hp100_start_xmit(struct sk_bu dev_kfree_skb_any(skb); #ifdef HP100_DEBUG_TX - printk("hp100: %s: start_xmit: end\n", dev->name); + printk(KERN_DEBUG "hp100: %s: start_xmit: end\n", dev->name); #endif return 0; @@ -1769,7 +1769,7 @@ static void hp100_rx(struct net_device * #ifdef DEBUG_B hp100_outw(0x4213, TRACE); - printk("hp100: %s: rx\n", dev->name); + printk(KERN_DEBUG "hp100: %s: rx\n", dev->name); #endif /* First get indication of received lan packet */ @@ -1778,7 +1778,7 @@ static void hp100_rx(struct net_device * packets = hp100_inb(RX_PKT_CNT); #ifdef HP100_DEBUG_RX if (packets > 1) - printk("hp100: %s: rx: waiting packets = %d\n", dev->name, packets); + printk(KERN_DEBUG "hp100: %s: rx: waiting packets = %d\n", dev->name, packets); #endif while (packets-- > 0) { @@ -1786,7 +1786,7 @@ static void hp100_rx(struct net_device * /* really advanced to the next packet. */ for (pkt_len = 0; pkt_len < 6000 && (hp100_inb(OPTION_MSW) & HP100_ADV_NXT_PKT); pkt_len++) { #ifdef HP100_DEBUG_RX - printk ("hp100: %s: rx: busy, remaining packets = %d\n", dev->name, packets); + printk (KERN_DEBUG "hp100: %s: rx: busy, remaining packets = %d\n", dev->name, packets); #endif } @@ -1803,7 +1803,7 @@ static void hp100_rx(struct net_device * pkt_len = ((header & HP100_PKT_LEN_MASK) + 3) & ~3; #ifdef HP100_DEBUG_RX - printk("hp100: %s: rx: new packet - length=%d, errors=0x%x, dest=0x%x\n", + printk(KERN_DEBUG "hp100: %s: rx: new packet - length=%d, errors=0x%x, dest=0x%x\n", dev->name, header & HP100_PKT_LEN_MASK, (header >> 16) & 0xfff8, (header >> 16) & 7); #endif @@ -1812,7 +1812,7 @@ static void hp100_rx(struct net_device * skb = dev_alloc_skb(pkt_len+2); if (skb == NULL) { /* Not enough memory->drop packet */ #ifdef HP100_DEBUG - printk("hp100: %s: rx: couldn't allocate a sk_buff of size %d\n", + printk(KERN_DEBUG "hp100: %s: rx: couldn't allocate a sk_buff of size %d\n", dev->name, pkt_len); #endif lp->stats.rx_dropped++; @@ -1840,7 +1840,7 @@ static void hp100_rx(struct net_device * skb->protocol = eth_type_trans(skb, dev); #ifdef HP100_DEBUG_RX - printk("hp100: %s: rx: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x\n", + printk(KERN_DEBUG "hp100: %s: rx: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x\n", dev->name, ptr[0], ptr[1], ptr[2], ptr[3], ptr[4], ptr[5], ptr[6], ptr[7], ptr[8], ptr[9], ptr[10], ptr[11]); @@ -1862,7 +1862,7 @@ static void hp100_rx(struct net_device * } } /* end of while(there are packets) loop */ #ifdef HP100_DEBUG_RX - printk("hp100_rx: %s: end\n", dev->name); + printk(KERN_DEBUG "hp100_rx: %s: end\n", dev->name); #endif } @@ -1879,18 +1879,18 @@ static void hp100_rx_bm(struct net_devic #ifdef HP100_DEBUG_B hp100_outw(0x4214, TRACE); - printk("hp100: %s: rx_bm\n", dev->name); + printk(KERN_DEBUG "hp100: %s: rx_bm\n", dev->name); #endif #ifdef HP100_DEBUG if (0 == lp->rxrcommit) { - printk("hp100: %s: rx_bm called although no PDLs were committed to adapter?\n", dev->name); + printk(KERN_DEBUG "hp100: %s: rx_bm called although no PDLs were committed to adapter?\n", dev->name); return; } else /* RX_PKT_CNT states how many PDLs are currently formatted and available to * the cards BM engine */ if ((hp100_inw(RX_PKT_CNT) & 0x00ff) >= lp->rxrcommit) { - printk("hp100: %s: More packets received than commited? RX_PKT_CNT=0x%x, commit=0x%x\n", + printk(KERN_DEBUG "hp100: %s: More packets received than commited? RX_PKT_CNT=0x%x, commit=0x%x\n", dev->name, hp100_inw(RX_PKT_CNT) & 0x00ff, lp->rxrcommit); return; @@ -1915,10 +1915,10 @@ static void hp100_rx_bm(struct net_devic pci_unmap_single(lp->pci_dev, (dma_addr_t) ptr->pdl[3], MAX_ETHER_SIZE, PCI_DMA_FROMDEVICE); #ifdef HP100_DEBUG_BM - printk("hp100: %s: rx_bm: header@0x%x=0x%x length=%d, errors=0x%x, dest=0x%x\n", + printk(KERN_DEBUG "hp100: %s: rx_bm: header@0x%x=0x%x length=%d, errors=0x%x, dest=0x%x\n", dev->name, (u_int) (ptr->pdl - 1), (u_int) header, pkt_len, (header >> 16) & 0xfff8, (header >> 16) & 7); - printk("hp100: %s: RX_PDL_COUNT:0x%x TX_PDL_COUNT:0x%x, RX_PKT_CNT=0x%x PDH=0x%x, Data@0x%x len=0x%x\n", + printk(KERN_DEBUG "hp100: %s: RX_PDL_COUNT:0x%x TX_PDL_COUNT:0x%x, RX_PKT_CNT=0x%x PDH=0x%x, Data@0x%x len=0x%x\n", dev->name, hp100_inb(RX_PDL), hp100_inb(TX_PDL), hp100_inb(RX_PKT_CNT), (u_int) * (ptr->pdl), (u_int) * (ptr->pdl + 3), (u_int) * (ptr->pdl + 4)); @@ -1927,7 +1927,7 @@ static void hp100_rx_bm(struct net_devic if ((pkt_len >= MIN_ETHER_SIZE) && (pkt_len <= MAX_ETHER_SIZE)) { if (ptr->skb == NULL) { - printk("hp100: %s: rx_bm: skb null\n", dev->name); + printk(KERN_DEBUG "hp100: %s: rx_bm: skb null\n", dev->name); /* can happen if we only allocated room for the pdh due to memory shortage. */ lp->stats.rx_dropped++; } else { @@ -1950,7 +1950,7 @@ static void hp100_rx_bm(struct net_devic } } else { #ifdef HP100_DEBUG - printk("hp100: %s: rx_bm: Received bad packet (length=%d)\n", dev->name, pkt_len); + printk(KERN_DEBUG "hp100: %s: rx_bm: Received bad packet (length=%d)\n", dev->name, pkt_len); #endif if (ptr->skb != NULL) dev_kfree_skb_any(ptr->skb); @@ -1963,7 +1963,7 @@ static void hp100_rx_bm(struct net_devic if (0 == hp100_build_rx_pdl(lp->rxrtail, dev)) { /* No space for skb, header can still be received. */ #ifdef HP100_DEBUG - printk("hp100: %s: rx_bm: No space for new PDL.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: rx_bm: No space for new PDL.\n", dev->name); #endif return; } else { /* successfully allocated new PDL - put it in ringlist at tail. */ @@ -2003,7 +2003,7 @@ static void hp100_update_stats(struct ne #ifdef HP100_DEBUG_B hp100_outw(0x4216, TRACE); - printk("hp100: %s: update-stats\n", dev->name); + printk(KERN_DEBUG "hp100: %s: update-stats\n", dev->name); #endif /* Note: Statistics counters clear when read. */ @@ -2030,7 +2030,7 @@ static void hp100_misc_interrupt(struct #ifdef HP100_DEBUG_B int ioaddr = dev->base_addr; hp100_outw(0x4216, TRACE); - printk("hp100: %s: misc_interrupt\n", dev->name); + printk(KERN_DEBUG "hp100: %s: misc_interrupt\n", dev->name); #endif /* Note: Statistics counters clear when read. */ @@ -2044,7 +2044,7 @@ static void hp100_clear_stats(struct hp1 #ifdef HP100_DEBUG_B hp100_outw(0x4217, TRACE); - printk("hp100: %s: clear_stats\n", dev->name); + printk(KERN_DEBUG "hp100: %s: clear_stats\n", dev->name); #endif spin_lock_irqsave(&lp->lock, flags); @@ -2073,7 +2073,7 @@ static void hp100_set_multicast_list(str #ifdef HP100_DEBUG_B hp100_outw(0x4218, TRACE); - printk("hp100: %s: set_mc_list\n", dev->name); + printk(KERN_DEBUG "hp100: %s: set_mc_list\n", dev->name); #endif spin_lock_irqsave(&lp->lock, flags); @@ -2099,13 +2099,13 @@ static void hp100_set_multicast_list(str memset(&lp->hash_bytes, 0x00, 8); #ifdef HP100_DEBUG - printk("hp100: %s: computing hash filter - mc_count = %i\n", dev->name, dev->mc_count); + printk(KERN_DEBUG "hp100: %s: computing hash filter - mc_count = %i\n", dev->name, dev->mc_count); #endif for (i = 0, dmi = dev->mc_list; i < dev->mc_count; i++, dmi = dmi->next) { addrs = dmi->dmi_addr; if ((*addrs & 0x01) == 0x01) { /* multicast address? */ #ifdef HP100_DEBUG - printk("hp100: %s: multicast = %02x:%02x:%02x:%02x:%02x:%02x, ", + printk(KERN_DEBUG "hp100: %s: multicast = %02x:%02x:%02x:%02x:%02x:%02x, ", dev->name, addrs[0], addrs[1], addrs[2], addrs[3], addrs[4], addrs[5]); #endif @@ -2114,7 +2114,7 @@ static void hp100_set_multicast_list(str printk(":%02x:", idx); } #ifdef HP100_DEBUG - printk("idx = %i\n", idx); + printk(KERN_DEBUG "idx = %i\n", idx); #endif lp->hash_bytes[idx >> 3] |= (1 << (idx & 7)); } @@ -2141,7 +2141,7 @@ static void hp100_set_multicast_list(str for (i = 0; i < 8; i++) hp100_outb(lp->hash_bytes[i], HASH_BYTE0 + i); #ifdef HP100_DEBUG - printk("hp100: %s: mac1 = 0x%x, mac2 = 0x%x, multicast hash = %02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x\n", + printk(KERN_DEBUG "hp100: %s: mac1 = 0x%x, mac2 = 0x%x, multicast hash = %02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x\n", dev->name, lp->mac1_mode, lp->mac2_mode, lp->hash_bytes[0], lp->hash_bytes[1], lp->hash_bytes[2], lp->hash_bytes[3], @@ -2151,7 +2151,7 @@ static void hp100_set_multicast_list(str if (lp->lan_type == HP100_LAN_100) { #ifdef HP100_DEBUG - printk("hp100: %s: 100VG MAC settings have changed - relogin.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: 100VG MAC settings have changed - relogin.\n", dev->name); #endif lp->hub_status = hp100_login_to_vg_hub(dev, 1); /* force a relogin to the hub */ } @@ -2166,7 +2166,7 @@ static void hp100_set_multicast_list(str for (i = 0; i < 8; i++) hp100_outb(lp->hash_bytes[i], HASH_BYTE0 + i); #ifdef HP100_DEBUG - printk("hp100: %s: multicast hash = %02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x\n", + printk(KERN_DEBUG "hp100: %s: multicast hash = %02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x\n", dev->name, lp->hash_bytes[0], lp->hash_bytes[1], lp->hash_bytes[2], lp->hash_bytes[3], lp->hash_bytes[4], @@ -2176,7 +2176,7 @@ static void hp100_set_multicast_list(str if (lp->lan_type == HP100_LAN_100) { #ifdef HP100_DEBUG - printk("hp100: %s: 100VG MAC settings have changed - relogin.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: 100VG MAC settings have changed - relogin.\n", dev->name); #endif lp->hub_status = hp100_login_to_vg_hub(dev, 1); /* force a relogin to the hub */ } @@ -2219,7 +2219,7 @@ static irqreturn_t hp100_interrupt(int i /* hp100_page( PERFORMANCE ); */ val = hp100_inw(IRQ_STATUS); #ifdef HP100_DEBUG_IRQ - printk("hp100: %s: mode=%x,IRQ_STAT=0x%.4x,RXPKTCNT=0x%.2x RXPDL=0x%.2x TXPKTCNT=0x%.2x TXPDL=0x%.2x\n", + printk(KERN_DEBUG "hp100: %s: mode=%x,IRQ_STAT=0x%.4x,RXPKTCNT=0x%.2x RXPDL=0x%.2x TXPKTCNT=0x%.2x TXPDL=0x%.2x\n", dev->name, lp->mode, (u_int) val, hp100_inb(RX_PKT_CNT), hp100_inb(RX_PDL), hp100_inb(TX_PKT_CNT), hp100_inb(TX_PDL)); #endif @@ -2241,7 +2241,7 @@ static irqreturn_t hp100_interrupt(int i if (lp->mode == 1) hp100_rx_bm(dev); else { - printk("hp100: %s: rx_pdl_fill_compl interrupt although not busmaster?\n", dev->name); + printk(KERN_INFO "hp100: %s: rx_pdl_fill_compl interrupt although not busmaster?\n", dev->name); } } @@ -2278,7 +2278,7 @@ static irqreturn_t hp100_interrupt(int i */ if (val & (HP100_TX_ERROR | HP100_RX_ERROR)) { #ifdef HP100_DEBUG_IRQ - printk("hp100: %s: TX/RX Error IRQ\n", dev->name); + printk(KERN_DEBUG "hp100: %s: TX/RX Error IRQ\n", dev->name); #endif hp100_update_stats(dev); if (lp->mode == 1) { @@ -2307,7 +2307,7 @@ static irqreturn_t hp100_interrupt(int i if (val & HP100_MISC_ERROR) { /* New for J2585B */ #ifdef HP100_DEBUG_IRQ printk - ("hp100: %s: Misc. Error Interrupt - Check cabling.\n", + (KERN_DEBUG "hp100: %s: Misc. Error Interrupt - Check cabling.\n", dev->name); #endif if (lp->mode == 1) { @@ -2334,7 +2334,7 @@ static void hp100_start_interface(struct #ifdef HP100_DEBUG_B hp100_outw(0x4220, TRACE); - printk("hp100: %s: hp100_start_interface\n", dev->name); + printk(KERN_DEBUG "hp100: %s: hp100_start_interface\n", dev->name); #endif spin_lock_irqsave(&lp->lock, flags); @@ -2394,7 +2394,7 @@ static void hp100_stop_interface(struct u_int val; #ifdef HP100_DEBUG_B - printk("hp100: %s: hp100_stop_interface\n", dev->name); + printk(KERN_DEBUG "hp100: %s: hp100_stop_interface\n", dev->name); hp100_outw(0x4221, TRACE); #endif @@ -2418,7 +2418,7 @@ static void hp100_stop_interface(struct hp100_page(PERFORMANCE); return; } - printk("hp100: %s: hp100_stop_interface - timeout\n", dev->name); + printk(KERN_INFO "hp100: %s: hp100_stop_interface - timeout\n", dev->name); hp100_page(PERFORMANCE); } } @@ -2438,7 +2438,7 @@ static void hp100_load_eeprom(struct net for (i = 0; i < 10000; i++) if (!(hp100_inb(OPTION_MSW) & HP100_EE_LOAD)) return; - printk("hp100: %s: hp100_load_eeprom - timeout\n", dev->name); + printk(KERN_INFO "hp100: %s: hp100_load_eeprom - timeout\n", dev->name); } /* Sense connection status. @@ -2461,7 +2461,7 @@ static int hp100_sense_lan(struct net_de val_VG = hp100_inb(VG_LAN_CFG_1); hp100_page(PERFORMANCE); #ifdef HP100_DEBUG - printk("hp100: %s: sense_lan: val_VG = 0x%04x, val_10 = 0x%04x\n", + printk(KERN_DEBUG "hp100: %s: sense_lan: val_VG = 0x%04x, val_10 = 0x%04x\n", dev->name, val_VG, val_10); #endif @@ -2503,7 +2503,7 @@ static int hp100_down_vg_link(struct net #ifdef HP100_DEBUG_B hp100_outw(0x4224, TRACE); - printk("hp100: %s: down_vg_link\n", dev->name); + printk(KERN_DEBUG "hp100: %s: down_vg_link\n", dev->name); #endif hp100_page(MAC_CTRL); @@ -2538,7 +2538,7 @@ static int hp100_down_vg_link(struct net #ifdef HP100_DEBUG if (time_after_eq(jiffies, time)) - printk("hp100: %s: down_vg_link: Link does not go down?\n", dev->name); + printk(KERN_DEBUG "hp100: %s: down_vg_link: Link does not go down?\n", dev->name); #endif /* To prevent condition where Rev 1 VG MAC and old hubs do not complete */ @@ -2593,7 +2593,7 @@ static int hp100_down_vg_link(struct net if (time_before_eq(time, jiffies)) { #ifdef HP100_DEBUG - printk("hp100: %s: down_vg_link: timeout\n", dev->name); + printk(KERN_DEBUG "hp100: %s: down_vg_link: timeout\n", dev->name); #endif return -EIO; } @@ -2619,7 +2619,7 @@ static int hp100_login_to_vg_hub(struct #ifdef HP100_DEBUG_B hp100_outw(0x4225, TRACE); - printk("hp100: %s: login_to_vg_hub\n", dev->name); + printk(KERN_DEBUG "hp100: %s: login_to_vg_hub\n", dev->name); #endif /* Initiate a login sequence iff VG MAC is enabled and either Load Address @@ -2630,7 +2630,7 @@ static int hp100_login_to_vg_hub(struct startst = hp100_inb(VG_LAN_CFG_1); if ((force_relogin == 1) || (hp100_inb(MAC_CFG_4) & HP100_MAC_SEL_ST)) { #ifdef HP100_DEBUG_TRAINING - printk("hp100: %s: Start training\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Start training\n", dev->name); #endif /* Ensure VG Reset bit is 1 (i.e., do not reset) */ @@ -2645,7 +2645,7 @@ static int hp100_login_to_vg_hub(struct hp100_andb(~(HP100_LINK_CMD /* |HP100_LOAD_ADDR */ ), VG_LAN_CFG_1); #ifdef HP100_DEBUG_TRAINING - printk("hp100: %s: Bring down the link\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Bring down the link\n", dev->name); #endif /* Wait for link to drop */ @@ -2699,12 +2699,12 @@ static int hp100_login_to_vg_hub(struct if (time_after_eq(jiffies, time)) { #ifdef HP100_DEBUG_TRAINING - printk("hp100: %s: Link cable status not ok? Training aborted.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Link cable status not ok? Training aborted.\n", dev->name); #endif } else { #ifdef HP100_DEBUG_TRAINING printk - ("hp100: %s: HUB tones detected. Trying to train.\n", + (KERN_DEBUG "hp100: %s: HUB tones detected. Trying to train.\n", dev->name); #endif @@ -2713,7 +2713,7 @@ static int hp100_login_to_vg_hub(struct val = hp100_inb(VG_LAN_CFG_1); if ((val & (HP100_LINK_UP_ST))) { #ifdef HP100_DEBUG_TRAINING - printk("hp100: %s: Passed training.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Passed training.\n", dev->name); #endif break; } @@ -2727,30 +2727,30 @@ static int hp100_login_to_vg_hub(struct /* If LINK_UP_ST is set, then we are logged into the hub. */ if (time_before_eq(jiffies, time) && (val & HP100_LINK_UP_ST)) { #ifdef HP100_DEBUG_TRAINING - printk("hp100: %s: Successfully logged into the HUB.\n", dev->name); + printk(KERN_DEBUG "hp100: %s: Successfully logged into the HUB.\n", dev->name); if (lp->chip == HP100_CHIPID_LASSEN) { val = hp100_inw(TRAIN_ALLOW); - printk("hp100: %s: Card supports 100VG MAC Version \"%s\" ", + printk(KERN_DEBUG "hp100: %s: Card supports 100VG MAC Version \"%s\" ", dev->name, (hp100_inw(TRAIN_REQUEST) & HP100_CARD_MACVER) ? "802.12" : "Pre"); printk("Driver will use MAC Version \"%s\"\n", (val & HP100_HUB_MACVER) ? "802.12" : "Pre"); - printk("hp100: %s: Frame format is %s.\n", dev->name, (val & HP100_MALLOW_FRAMEFMT) ? "802.5" : "802.3"); + printk(KERN_DEBUG "hp100: %s: Frame format is %s.\n", dev->name, (val & HP100_MALLOW_FRAMEFMT) ? "802.5" : "802.3"); } #endif } else { /* If LINK_UP_ST is not set, login was not successful */ - printk("hp100: %s: Problem logging into the HUB.\n", dev->name); + printk(KERN_INFO "hp100: %s: Problem logging into the HUB.\n", dev->name); if (lp->chip == HP100_CHIPID_LASSEN) { /* Check allowed Register to find out why there is a problem. */ val = hp100_inw(TRAIN_ALLOW); /* won't work on non-ETR card */ #ifdef HP100_DEBUG_TRAINING - printk("hp100: %s: MAC Configuration requested: 0x%04x, HUB allowed: 0x%04x\n", dev->name, hp100_inw(TRAIN_REQUEST), val); + printk(KERN_DEBUG "hp100: %s: MAC Configuration requested: 0x%04x, HUB allowed: 0x%04x\n", dev->name, hp100_inw(TRAIN_REQUEST), val); #endif if (val & HP100_MALLOW_ACCDENIED) - printk("hp100: %s: HUB access denied.\n", dev->name); + printk(KERN_INFO "hp100: %s: HUB access denied.\n", dev->name); if (val & HP100_MALLOW_CONFIGURE) - printk("hp100: %s: MAC Configuration is incompatible with the Network.\n", dev->name); + printk(KERN_INFO "hp100: %s: MAC Configuration is incompatible with the Network.\n", dev->name); if (val & HP100_MALLOW_DUPADDR) - printk("hp100: %s: Duplicate MAC Address on the Network.\n", dev->name); + printk(KERN_INFO "hp100: %s: Duplicate MAC Address on the Network.\n", dev->name); } } @@ -2771,7 +2771,7 @@ static int hp100_login_to_vg_hub(struct if (val & HP100_LINK_UP_ST) return (0); /* login was ok */ else { - printk("hp100: %s: Training failed.\n", dev->name); + printk(KERN_INFO "hp100: %s: Training failed.\n", dev->name); hp100_down_vg_link(dev); return -EIO; } @@ -2787,7 +2787,7 @@ static void hp100_cascade_reset(struct n #ifdef HP100_DEBUG_B hp100_outw(0x4226, TRACE); - printk("hp100: %s: cascade_reset\n", dev->name); + printk(KERN_DEBUG "hp100: %s: cascade_reset\n", dev->name); #endif if (enable) { @@ -2819,21 +2819,21 @@ void hp100_RegisterDump(struct net_devic int Register; /* Dump common registers */ - printk("hp100: %s: Cascade Register Dump\n", dev->name); - printk("hardware id #1: 0x%.2x\n", hp100_inb(HW_ID)); - printk("hardware id #2/paging: 0x%.2x\n", hp100_inb(PAGING)); - printk("option #1: 0x%.4x\n", hp100_inw(OPTION_LSW)); - printk("option #2: 0x%.4x\n", hp100_inw(OPTION_MSW)); + printk(KERN_INFO "hp100: %s: Cascade Register Dump\n", dev->name); + printk(KERN_INFO "hardware id #1: 0x%.2x\n", hp100_inb(HW_ID)); + printk(KERN_INFO "hardware id #2/paging: 0x%.2x\n", hp100_inb(PAGING)); + printk(KERN_INFO "option #1: 0x%.4x\n", hp100_inw(OPTION_LSW)); + printk(KERN_INFO "option #2: 0x%.4x\n", hp100_inw(OPTION_MSW)); /* Dump paged registers */ for (Page = 0; Page < 8; Page++) { /* Dump registers */ - printk("page: 0x%.2x\n", Page); + printk(KERN_INFO "page: 0x%.2x\n", Page); outw(Page, ioaddr + 0x02); for (Register = 0x8; Register < 0x22; Register += 2) { /* Display Register contents except data port */ if (((Register != 0x10) && (Register != 0x12)) || (Page > 0)) { - printk("0x%.2x = 0x%.4x\n", Register, inw(ioaddr + Register)); + printk(KERN_INFO "0x%.2x = 0x%.4x\n", Register, inw(ioaddr + Register)); } } } @@ -2881,7 +2881,7 @@ static int __init hp100_eisa_probe (stru goto out2; #ifdef HP100_DEBUG - printk("hp100: %s: EISA adapter found at 0x%x\n", dev->name, + printk(KERN_DEBUG "hp100: %s: EISA adapter found at 0x%x\n", dev->name, dev->base_addr); #endif gendev->driver_data = dev; @@ -2934,7 +2934,7 @@ static int __devinit hp100_pci_probe (st pci_read_config_word(pdev, PCI_COMMAND, &pci_command); if (!(pci_command & PCI_COMMAND_IO)) { #ifdef HP100_DEBUG - printk("hp100: %s: PCI I/O Bit has not been set. Setting...\n", dev->name); + printk(KERN_DEBUG "hp100: %s: PCI I/O Bit has not been set. Setting...\n", dev->name); #endif pci_command |= PCI_COMMAND_IO; pci_write_config_word(pdev, PCI_COMMAND, pci_command); @@ -2942,7 +2942,7 @@ static int __devinit hp100_pci_probe (st if (!(pci_command & PCI_COMMAND_MASTER)) { #ifdef HP100_DEBUG - printk("hp100: %s: PCI Master Bit has not been set. Setting...\n", dev->name); + printk(KERN_DEBUG "hp100: %s: PCI Master Bit has not been set. Setting...\n", dev->name); #endif pci_command |= PCI_COMMAND_MASTER; pci_write_config_word(pdev, PCI_COMMAND, pci_command); @@ -2957,7 +2957,7 @@ static int __devinit hp100_pci_probe (st goto out2; #ifdef HP100_DEBUG - printk("hp100: %s: PCI adapter found at 0x%x\n", dev->name, ioaddr); + printk(KERN_DEBUG "hp100: %s: PCI adapter found at 0x%x\n", dev->name, ioaddr); #endif pci_set_drvdata(pdev, dev); return 0; -- From alessandro.suardi@gmail.com Sat May 28 18:12:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 18:12:10 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4T1C5Xq019138 for ; Sat, 28 May 2005 18:12:05 -0700 Received: by rproxy.gmail.com with SMTP id r35so524413rna for ; Sat, 28 May 2005 18:11:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pacs/gGM/6WumbMJcDV86HmqcwN8fu/SvRw63ALqvAXQh9Q/OtkBYVCedZD9tfAYQKvgH07JkrOJSiYNYur44hvYVvl/BQaRJKLn5QfUz1eoxAHmk5iT7YIOlPwpY3fE8Y0ZztvnfjW73l1SE/+95FKwD978riN5dfiQvDXD+3Y= Received: by 10.38.5.73 with SMTP id 73mr4880985rne; Sat, 28 May 2005 18:11:14 -0700 (PDT) Received: by 10.38.13.11 with HTTP; Sat, 28 May 2005 18:11:14 -0700 (PDT) Message-ID: <5a4c581d0505281811a6b067d@mail.gmail.com> Date: Sun, 29 May 2005 03:11:14 +0200 From: Alessandro Suardi Reply-To: Alessandro Suardi To: Andrew Morton Subject: Re: non-fatal oops with EIP at skb_release_data, available for debugging Cc: netdev@oss.sgi.com In-Reply-To: <20050525220003.5f6ab060.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <5a4c581d05030412482a596ee5@mail.gmail.com> <5a4c581d05040615306f12ebde@mail.gmail.com> <20050525220003.5f6ab060.akpm@osdl.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4T1C5Xq019138 X-archive-position: 1849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alessandro.suardi@gmail.com Precedence: bulk X-list: netdev Content-Length: 6094 Lines: 129 On 5/26/05, Andrew Morton wrote: > Alessandro Suardi wrote: > > > > Quoting my post of over a month ago, hit another > > non-fatal oops this time with 2.6.12-rc1-bk2... > > Has this bug been sighted in more recent kernels? 2.6.12-rc2 is the last kernel I've been running on that box and the oops never happened once. I'm waiting for -final or -rc6 and then load it on that K7-800, but so far 2.6.12-rc2 has been rock solid. I think it was reaching the 30 days uptime but my building had a power outage last week... > > [17330.816664] Adding 232932k swap on /dev/hdb4. Priority:-2 extents:1 > > [42120.713332] UDP: bad checksum. From 84.188.199.xxx:57483 to > > 192.168.1.7:10600 ulen 27 > > [56984.872784] UDP: bad checksum. From 216.155.90.xxx:11417 to > > 192.168.1.7:10600 ulen 28 > > [383152.586711] scsi: unknown opcode 0x01 > > [630539.047761] UDP: short packet: From 4.46.101.xxx:5431 58/27 to > > 192.168.1.7:1 0600 > > [681405.777002] ------------[ cut here ]------------ > > [681405.777337] kernel BUG at include/linux/mm.h:343! > > [681405.777642] invalid operand: 0000 [#1] > > [681405.777885] PREEMPT > > [681405.778041] Modules linked in: parport_pc parport 8139too floppy > > [681405.778488] CPU: 0 > > [681405.778491] EIP: 0060:[] Not tainted VLI > > [681405.778494] EFLAGS: 00210256 (2.6.12-rc1-bk2) > > [681405.779293] EIP is at skb_release_data+0xa3/0xb0 > > [681405.779593] eax: 00000000 ebx: 00000002 ecx: ceb1af80 edx: c10eeb40 > > [681405.780027] esi: c30785c0 edi: c30785c0 ebp: ccd95d28 esp: ccd95d20 > > [681405.780458] ds: 007b es: 007b ss: 0068 > > [681405.780723] Process metacity (pid: 2190, threadinfo=ccd94000 task=cb501a40) > > [681405.781164] Stack: c30785c0 00000020 ccd95d34 c02dcd3b cec7a6c0 > > ccd95d54 c02 dcdb7 ccd95f3c > > [681405.781807] 00001620 c30785c0 506c6f85 c30785c0 506c6f85 > > ccd95da8 c03 0100a 00000000 > > [681405.782448] c02dc46f caf7d420 ccd95d80 00000001 caf7d46c > > ccd94000 000 00001 00000000 > > [681405.783088] Call Trace: > > [681405.783258] [] show_stack+0x7a/0x90 > > [681405.783574] [] show_registers+0x14d/0x1c0 > > [681405.783915] [] die+0xe4/0x170 > > [681405.784192] [] do_invalid_op+0xa3/0xb0 > > [681405.784517] [] error_code+0x2b/0x30 > > [681405.785009] [] kfree_skbmem+0xb/0x20 > > [681405.785494] [] __kfree_skb+0x67/0xf0 > > [681405.785978] [] tcp_recvmsg+0x5fa/0x720 > > [681405.786477] [] sock_common_recvmsg+0x46/0x60 > > [681405.787004] [] sock_recvmsg+0xbd/0xf0 > > [681405.787493] [] sock_readv_writev+0x83/0x90 > > [681405.788009] [] sock_readv+0x3b/0x50 > > [681405.788487] [] do_readv_writev+0x205/0x230 > > [681405.789004] [] vfs_readv+0x3d/0x50 > > [681405.789476] [] sys_readv+0x3d/0xa0 > > [681405.789947] [] sysenter_past_esp+0x54/0x75 > > [681405.790461] Code: 8b 86 98 00 00 00 5e c9 e9 7b e9 e5 ff 89 d0 e8 > > 44 f7 e5 f f eb d6 89 f0 e8 fb fe ff ff 5b 8b 86 98 00 00 00 5e c9 e9 > > 5d e9 e5 ff <0f> 0b 5 7 01 32 ed 35 c0 eb ac 8d 76 00 55 89 e5 53 89 > > c3 e8 45 > > [681405.857278] <7>UDP: short packet: From 213.23.1.xxx:11236 2814/33 > > to 192.168. 1.7:10600 > > > > > > On Mar 4, 2005 10:48 PM, Alessandro Suardi wrote: > > > This is my K7-800, 256MB RAM machine running as > > > ed2k/bittorrent 24/7 box... metacity died, but the > > > windows are still alive (and working) so if someone > > > wants to get more info about it, just ping me... > > > > > > [root@donkey ~]# cat /proc/version > > > Linux version 2.6.11-rc3-bk8 (asuardi@donkey) (gcc version 3.4.2 > > > 20041017 (Red Hat 3.4.2-6.fc3)) #1 Sat Feb 12 00:01:28 CET 2005 > > > [root@donkey ~]# lsmod > > > Module Size Used by > > > loop 15368 - > > > nls_iso8859_1 3840 - > > > parport_pc 29444 - > > > parport 24704 - > > > 8139too 24896 - > > > floppy 57392 - > > > > > > From the dmesg ring: > > > > > > kernel BUG at include/linux/mm.h:343! > > > invalid operand: 0000 [#1] > > > PREEMPT > > > Modules linked in: loop nls_iso8859_1 parport_pc parport 8139too floppy > > > CPU: 0 > > > EIP: 0060:[] Not tainted VLI > > > EFLAGS: 00210256 (2.6.11-rc3-bk8) > > > EIP is at skb_release_data+0x92/0xa0 > > > eax: 00000000 ebx: 00000000 ecx: cca36f80 edx: c11a97c0 > > > esi: c4205f20 edi: c4205f20 ebp: cd149dcc esp: cd149dc4 > > > ds: 007b es: 007b ss: 0068 > > > Process metacity (pid: 2109, threadinfo=cd148000 task=ce8935d0) > > > Stack: c4205f20 00000000 cd149dd8 c02da6bb c6e9a0c0 cd149df8 c02da737 c5134250 > > > 00000000 c4205f20 c5134250 c4205f20 c5134250 cd149e4c c02feba6 00000000 > > > 00000040 cc68c454 00000000 00000001 cc68c444 cd148000 00000001 00000000 > > > Call Trace: > > > [] show_stack+0x7a/0x90 > > > [] show_registers+0x14d/0x1c0 > > > [] die+0xe4/0x180 > > > [] do_invalid_op+0xa3/0xb0 > > > [] error_code+0x2b/0x30 > > > [] kfree_skbmem+0xb/0x20 > > > [] __kfree_skb+0x67/0xf0 > > > [] tcp_recvmsg+0x5f6/0x710 > > > [] sock_common_recvmsg+0x46/0x60 > > > [] sock_aio_read+0xee/0x100 > > > [] do_sync_read+0x97/0xf0 > > > [] vfs_read+0x91/0x120 > > > [] sys_read+0x3d/0x70 > > > [] sysenter_past_esp+0x52/0x75 > > > Code: c9 e9 03 e5 e5 ff 8d 76 00 5b 5e c9 c3 89 d0 e8 c5 f2 e5 ff eb > > > cf 89 f0 e8 0c ff ff ff 5b 8b 86 98 00 00 00 5e c9 e9 de e4 e5 ff <0f> > > > 0b 57 01 ab c5 35 c0 eb a5 8d 74 26 00 55 89 e5 53 89 c3 e8 --alessandro "To love is to find your own soul Through the soul of the beloved one. When the beloved one withdraws itself from your soul Then you have lost your soul." (Edgar Lee Masters, Spoon River Anthology - "Mary McNeely") From davem@davemloft.net Sat May 28 20:26:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 20:26:16 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4T3QBXq026144 for ; Sat, 28 May 2005 20:26:12 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DcEP6-0001tZ-Dd; Sat, 28 May 2005 20:23:56 -0700 Date: Sat, 28 May 2005 20:23:56 -0700 (PDT) Message-Id: <20050528.202356.94889774.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: hadi@cyberus.ca, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [0/10] [IPSEC] IPsec event notification From: "David S. Miller" In-Reply-To: <20050528001005.GA10547@gondor.apana.org.au> References: <20050527110730.GA4424@gondor.apana.org.au> <20050527.134139.32345929.davem@davemloft.net> <20050528001005.GA10547@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 257 Lines: 8 From: Herbert Xu Date: Sat, 28 May 2005 10:10:05 +1000 > Any objections to asking Andrew to start pulling your > net-2.6.13 tree or is he doing that already? I told him last week to do so, so he should be already doing this. From jmorris@redhat.com Sat May 28 23:08:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 May 2005 23:09:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4T68wXq029799 for ; Sat, 28 May 2005 23:08:59 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4T684Rq009207; Sun, 29 May 2005 02:08:04 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4T683O16373; Sun, 29 May 2005 02:08:03 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j4T67gDj031702; Sun, 29 May 2005 02:07:52 -0400 Date: Sun, 29 May 2005 02:07:42 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: jaegert cc: netdev@oss.sgi.com, , , , Subject: Re: [PATCH 1/2] Resend: LSM-IPSec Networking Hooks In-Reply-To: <1116361510.5560.121.camel@dyn9002018177.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 1787 Lines: 64 A few issues: 1) The following patch is needed to ensure that the error value is propagated back, that the err is initialized and that you don't try and xfrm_pol_put() an uninitialized xp. diff -purN -X dontdiff linux-2.6.12-rc4.w/net/key/af_key.c linux-2.6.12-rc4.x/net/key/af_key.c --- linux-2.6.12-rc4.w/net/key/af_key.c 2005-05-29 01:30:08.000000000 -0400 +++ linux-2.6.12-rc4.x/net/key/af_key.c 2005-05-29 01:54:17.751327592 -0400 @@ -2098,8 +2098,9 @@ static int pfkey_spddelete(struct sock * sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; memcpy(&tmp.selector, &sel, sizeof(struct xfrm_selector)); if (sec_ctx != NULL) { - if (security_xfrm_policy_alloc(&tmp, sec_ctx)) - goto out; + err = security_xfrm_policy_alloc(&tmp, sec_ctx); + if (err) + return err; } xp = xfrm_policy_bysel(pol->sadb_x_policy_dir-1, &tmp.selector, 1); 2) Compiler warnings: You pass a struct xfrm_user_sec_ctx to security_xfrm_policy_alloc() instead of the struct sadb_x_sec_ctx defined for that function: net/xfrm/xfrm_user.c:223 net/xfrm/xfrm_user.c:651 net/xfrm/xfrm_user.c:939 This may seem to work on some systems because the structs are the same, but one is packed and it's bad form in any case. Not sure what the best way is to fix this. xfrm is native, so any penalty should likely go to pfkey. Also, net/xfrm/xfrm_user.c:1241: warning: unused variable `ctx' 3) security/selinux/nethooks.c The name of this file is potentially misleading, it does not contain all of the SELinux networking hooks, just the xfrm related code. I'd suggest calling it security/selinux/xfrm.c. It also has no author/copyright info, or a GPL notice (look at the other files there). (More to come). - James -- James Morris From mroos@linux.ee Sun May 29 03:48:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 29 May 2005 03:48:40 -0700 (PDT) Received: from math.ut.ee (math.ut.ee [193.40.36.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4TAmVXq009546 for ; Sun, 29 May 2005 03:48:32 -0700 Received: from math.ut.ee (localhost [IPv6:::1]) by math.ut.ee (8.12.8+Sun/8.12.8/math-1.2) with ESMTP id j4TAlcYN012155 for ; Sun, 29 May 2005 13:47:38 +0300 (EEST) Received: from localhost (mroos@localhost) by math.ut.ee (8.12.8+Sun/8.12.2/Submit) with ESMTP id j4TAlYpv012136 for ; Sun, 29 May 2005 13:47:38 +0300 (EEST) X-Authentication-Warning: math.ut.ee: mroos owned process doing -bs Date: Sun, 29 May 2005 13:47:34 +0300 (EEST) From: Meelis Roos To: netdev@oss.sgi.com Subject: Q: ieee80211_txb Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 1853 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev Content-Length: 334 Lines: 9 I tried to understand the new 802.11 stack API and met some things I couldn't understand by just looking at the code. My main question is currently struct ieee80211_txb. How is it meant to be used? How driver-specific is it - should it fit all drivers or does it assume some specific DMA set-up? -- Meelis Roos (mroos@linux.ee) From herbert@gondor.apana.org.au Sun May 29 04:29:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 29 May 2005 04:29:24 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4TBTIXq014798 for ; Sun, 29 May 2005 04:29:19 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DcLxD-0005VU-00; Sun, 29 May 2005 21:27:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DcLx5-0000Ul-00; Sun, 29 May 2005 21:27:31 +1000 Date: Sun, 29 May 2005 21:27:31 +1000 To: "David S. Miller" Cc: hadi@cyberus.ca, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [0/10] [IPSEC] IPsec event notification Message-ID: <20050529112731.GA1891@gondor.apana.org.au> References: <20050527110730.GA4424@gondor.apana.org.au> <20050527.134139.32345929.davem@davemloft.net> <20050528001005.GA10547@gondor.apana.org.au> <20050528.202356.94889774.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050528.202356.94889774.davem@davemloft.net> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 612 Lines: 16 On Sat, May 28, 2005 at 08:23:56PM -0700, David S. Miller wrote: > From: Herbert Xu > Date: Sat, 28 May 2005 10:10:05 +1000 > > > Any objections to asking Andrew to start pulling your > > net-2.6.13 tree or is he doing that already? > > I told him last week to do so, so he should be already > doing this. Thanks a lot Dave. I've asked Andrew to stop pulling my tree. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From romieu@fr.zoreil.com Sun May 29 15:57:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 29 May 2005 15:57:15 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4TMv9Xq018395 for ; Sun, 29 May 2005 15:57:11 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4TMsdL2029357; Mon, 30 May 2005 00:54:39 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4TMsXs5029356; Mon, 30 May 2005 00:54:33 +0200 Date: Mon, 30 May 2005 00:54:33 +0200 From: Francois Romieu To: Richard Dawe Cc: Ben Greear , Linux netdev Subject: Re: [PATCH] r8169: support restricting speed+duplex in autonegotiation Message-ID: <20050529225433.GA24990@electric-eye.fr.zoreil.com> References: <4297A0F7.5070209@phekda.gotadsl.co.uk> <4297B479.1080404@candelatech.com> <429871F9.6040305@phekda.gotadsl.co.uk> <20050528144207.GA17021@electric-eye.fr.zoreil.com> <4298D6F9.7030608@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4298D6F9.7030608@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 642 Lines: 20 Richard Dawe : [...] > Is the "media" part of the patch confusing? No (it could have stored its data in link_settings[] though). I do not understand what the "ret" variable in rtl8169_set_speed_xmii() is supposed to do but it is not a big issue. Style aside, Ben has imho a point. The patch adds a special case: - is there a real need ? - is it a 8169-specific thing or not ? The code is added in an area where the driver is currently not pretty. The driver should probably replace its own defines with the ones in then really disable autonegotiation when it is asked to (hint, hint). -- Ueimor From akpm@osdl.org Sun May 29 18:23:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 29 May 2005 18:23:44 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4U1NdXq028035 for ; Sun, 29 May 2005 18:23:39 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4U1MijA010269 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 29 May 2005 18:22:45 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4U1MihN008120; Sun, 29 May 2005 18:22:44 -0700 Date: Sun, 29 May 2005 18:21:52 -0700 From: Andrew Morton To: Alessandro Suardi Cc: netdev@oss.sgi.com Subject: Re: non-fatal oops with EIP at skb_release_data, available for debugging Message-Id: <20050529182152.60be1979.akpm@osdl.org> In-Reply-To: <5a4c581d0505281811a6b067d@mail.gmail.com> References: <5a4c581d05030412482a596ee5@mail.gmail.com> <5a4c581d05040615306f12ebde@mail.gmail.com> <20050525220003.5f6ab060.akpm@osdl.org> <5a4c581d0505281811a6b067d@mail.gmail.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1856 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 787 Lines: 19 Alessandro Suardi wrote: > > On 5/26/05, Andrew Morton wrote: > > Alessandro Suardi wrote: > > > > > > Quoting my post of over a month ago, hit another > > > non-fatal oops this time with 2.6.12-rc1-bk2... > > > > Has this bug been sighted in more recent kernels? > > 2.6.12-rc2 is the last kernel I've been running on that box > and the oops never happened once. I'm waiting for -final > or -rc6 and then load it on that K7-800, but so far 2.6.12-rc2 > has been rock solid. I think it was reaching the 30 days > uptime but my building had a power outage last week... There should be a -rc6. Please be sure to test that - we don't want to let 2.6.12 out with a bug like this in it, thanks. From yi.zhu@intel.com Sun May 29 19:38:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 29 May 2005 19:38:26 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4U2cNXq032053 for ; Sun, 29 May 2005 19:38:23 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4U2bSP8012704; Mon, 30 May 2005 02:37:28 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4U2bSfk019406; Mon, 30 May 2005 02:37:28 GMT Received: from debian.sh.intel.com ([172.16.219.38]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005052919372722424 ; Sun, 29 May 2005 19:37:27 -0700 Subject: Re: Q: ieee80211_txb From: Zhu Yi To: Meelis Roos Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Intel Corp. Date: Mon, 30 May 2005 10:34:18 +0800 Message-Id: <1117420458.24850.36.camel@debian.sh.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1857 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yi.zhu@intel.com Precedence: bulk X-list: netdev Content-Length: 749 Lines: 18 On Sun, 2005-05-29 at 13:47 +0300, Meelis Roos wrote: > I tried to understand the new 802.11 stack API and met some things I > couldn't understand by just looking at the code. > > My main question is currently struct ieee80211_txb. How is it meant to > be used? How driver-specific is it - should it fit all drivers or does > it assume some specific DMA set-up? The ieee80211_txb should not be driver specific. ->fragments is struct sk_buff, indicates the packet skb or the fragmentation skb list for software based fragmentation. And others members are self explained. Currently it fits the ipw* drivers (you see a reserved word is used), we should change it to be more generic and provide enough info for every wireless driver. Thanks, -yi From jmorris@redhat.com Mon May 30 00:07:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 00:07:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4U775Xq032694 for ; Mon, 30 May 2005 00:07:06 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4U7637V030254; Mon, 30 May 2005 03:06:03 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4U762O20082; Mon, 30 May 2005 03:06:02 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j4U75fDj017672; Mon, 30 May 2005 03:05:52 -0400 Date: Mon, 30 May 2005 03:05:41 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: jaegert cc: netdev@oss.sgi.com, , , , Subject: Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks In-Reply-To: <1116361671.5560.125.camel@dyn9002018177.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1858 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 3434 Lines: 138 On Tue, 17 May 2005, jaegert wrote: > +#define nethooks_debug(fmt, args...) {if (DEBUG) printk(KERN_NOTICE fmt,## args);} Why isn't this debugging using KERN_DEBUG? > +static inline struct inode_security_struct *get_sock_isec(struct sock *sk) > +{ > + if (!sk->sk_socket) { > + nethooks_debug("%s: no socket on this sock (!?)\n", > + __FUNCTION__); > + return (struct inode_security_struct *) NULL; > + } No need to cast NULL here. > +int selinux_xfrm_policy_lookup(struct sock *sk, struct xfrm_selector *sel, struct flowi *fl, u8 dir) > +{ > + int rc = 0; > + struct inode_security_struct *isec = NULL; > + u32 sock_sid, sel_sid = SECINITSID_UNLABELED; > + > + nethooks_debug("%s: authorize\n", __FUNCTION__); > + > + if (!sk) { > + /* no sock to send -- e.g., icmp reply */ > + /* authorize as kernel packet */ > + if (fl && fl->proto == IPPROTO_ICMP) { > + nethooks_debug("%s: ICMP case\n", > + __FUNCTION__); > + sock_sid = SECINITSID_KERNEL; > + goto authorize; > + } > + /* > + * hooks.c accepts packets with no socket unconditionally > + */ > + nethooks_debug("%s: no sock on this skbuff: non-ICMP\n", > + __FUNCTION__); > + goto out; > + } I'm not sure that ICMP is the only protocol which might be caught here; are there any other cases where there's no sk that also get caught here? The debugging in any case is not all that useful, I'd suggest adding a protocol number. > + read_lock_bh(&sk->sk_callback_lock); You only need this lock for (dir == FLOW_DIR_IN). > +static inline int selinux_xfrm_selector_alloc(struct xfrm_selector *sel, struct sadb_x_sec_ctx *sec_ctx) > +{ > + int rc = 0; > + > + if (!sec_ctx) > + return -EINVAL; Shouldn't this be a BUG_ON() ? > + memcpy(sel->security->ctx_str, > + sec_ctx+1, > + sel->security->ctx_len); Don't you need to validate that ctx_len is within bounds of the data copied from userspace? > + rc = security_context_to_sid(sel->security->ctx_str, > + sel->security->ctx_len, > + &sel->security->ctx_sid); > + sel->security->ctx_str[sel->security->ctx_len] = 0; Why null terminate here? security_context_to_sid() was looking for it already, assuming we haven't crashed yet. > +int selinux_xfrm_policy_alloc(struct xfrm_policy *xp, struct sadb_x_sec_ctx *sec_ctx) > +{ > + int rc = 0; > + > + if (!xp) > + return -EINVAL; Another case for BUG_ON(). > + nethooks_debug(KERN_NOTICE "%s: start alloc\n", __FUNCTION__); > + > + rc = selinux_xfrm_selector_alloc(&xp->selector, sec_ctx); > + > + return rc; > +} How about getting rid of rc and just return the value of the last function. > +void selinux_xfrm_policy_free(struct xfrm_policy *xp) > +{ > + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); > + > + if (xfrm_ctx) > + kfree(xfrm_ctx); > +} Just call kfree() unconditionally. > +int selinux_xfrm_state_alloc(struct xfrm_state *x, struct sadb_x_sec_ctx *sec_ctx) > +{ > + int rc = 0; > + > + if (!x) > + return -EINVAL; BUG_ON() > + rc = selinux_xfrm_selector_alloc(&x->sel, sec_ctx); > + > + return rc; No need for rc again. > +void selinux_xfrm_state_free(struct xfrm_state *x) > +{ > + struct xfrm_sec_ctx *xfrm_ctx = xfrm_state_security(x); > + > + if (xfrm_ctx) > + kfree(xfrm_ctx); > +} kfree() again. (Still reviewing...) - James -- James Morris From ak@muc.de Mon May 30 02:42:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 02:42:14 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4U9g8Xq011934 for ; Mon, 30 May 2005 02:42:12 -0700 Received: (qmail 56522 invoked by uid 3709); 30 May 2005 09:41:07 -0000 Date: 30 May 2005 11:41:07 +0200 Date: Mon, 30 May 2005 11:41:07 +0200 From: Andi Kleen To: Christoph Lameter Cc: Eric Dumazet , netdev@oss.sgi.com, akpm@osdl.org, shai@scalex86.org Subject: Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000 Message-ID: <20050530094107.GJ86087@muc.de> References: <428AF378.5020109@cosmosbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 1859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 775 Lines: 21 On Fri, May 27, 2005 at 02:15:55PM -0700, Christoph Lameter wrote: > On Wed, 18 May 2005, Eric Dumazet wrote: > > > Related question, is pci_alloc_consistent() already NUMA aware ? > > Nope. It also ultimately acquires memory via vmalloc. x86-64 vmalloc has been NUMA aware forever. I believe the HP BigTux patchkit for IA64 added it there too, although it might not have hit mainline. > > pci_alloc_consistent will also need some rework to allocate memory > consistent (well the name is coherent right?) with the node that the > device is on. Second case of a need for a node aware vmalloc? You can already have it today by temporarily changing the process mempolicy. However for pci_alloc_consistent just using alloc_pages_node directly seems to work fine. -Andi From akepner@sgi.com Mon May 30 09:35:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 09:35:46 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4UGZeXq009501 for ; Mon, 30 May 2005 09:35:40 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j4UILDxN001286 for ; Mon, 30 May 2005 11:21:13 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j4UGXlbT78316528 for ; Mon, 30 May 2005 09:33:47 -0700 (PDT) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-193.corp.sgi.com [134.15.0.193]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j4UGWkdP31493081; Mon, 30 May 2005 09:32:46 -0700 (PDT) Date: Mon, 30 May 2005 09:30:13 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Lennert Buytenhek cc: netdev@oss.sgi.com, jesse.barnes@intel.com, gnb@sgi.com Subject: Re: [PATCH] use mmiowb in tg3_poll In-Reply-To: <20050528231209.GA8456@xi.wantstofly.org> Message-ID: References: <200410211628.06906.jbarnes@engr.sgi.com> <20050528231209.GA8456@xi.wantstofly.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1860 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 970 Lines: 31 On Sun, 29 May 2005, Lennert Buytenhek wrote: > ..... > I'm quite curious what kind of MMIO read latency you see on your > Altix boxen. This app is quite useful for determining those figures > on x86{,_64} machines: > > http://svn.gnumonks.org/trunk/mmio_test/mmio_test.c > .... [cc list change: jbarnes@engr.sgi.com -> jesse.barnes@intel.com] Haven't tried this program yet (though it looks interesting.) In the past I've instrumented the driver with get_cycles() to acquire the PIO read and mmiowb() latencies. I quickly looked through the records that I have and, unfortunately, wasn't able to locate raw data. But I found some scrawlings in my notes which say the most recent measurements for an Altix are: i) PIO read latency ~ 2.4 usec ii) mmiowb() latency ~ 1.1 usec (This data was taken when the PIOs/mmiowb()s were coming from a CPU which was "nearest" to the NIC.) If you have data for x86{,_64}, I'd be interested in that, too. -- Arthur From laforge@netfilter.org Mon May 30 11:08:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 11:08:10 -0700 (PDT) Received: from ganesha.gnumonks.org ([213.95.27.120]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4UI7xXq014506 for ; Mon, 30 May 2005 11:08:05 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Dcof9-00081b-W1; Mon, 30 May 2005 20:06:56 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1Dcof8-0006TM-OP; Mon, 30 May 2005 20:06:54 +0200 Date: Mon, 30 May 2005 20:06:54 +0200 From: Harald Welte To: David Miller Cc: Netfilter Development Mailinglist , netdev@oss.sgi.com Subject: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path Message-ID: <20050530180654.GX22760@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , David Miller , Netfilter Development Mailinglist , netdev@oss.sgi.com References: <20050526142420.GD13114@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vqZEy/DEMZDTzjXG" Content-Disposition: inline In-Reply-To: <20050526142420.GD13114@sunbeam.de.gnumonks.org> User-Agent: mutt-ng 1.5.8-r168i (Debian) X-archive-position: 1861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 3638 Lines: 103 --vqZEy/DEMZDTzjXG Content-Type: multipart/mixed; boundary="oxour8c+zPVguRmP" Content-Disposition: inline --oxour8c+zPVguRmP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 26, 2005 at 04:24:21PM +0200, Harald Welte wrote: =20 > When we have ip_queue being used from LOCAL_IN, then we end up with a > situation where the verdicts coming back from userspace traverse the TCP > input path from syscall context. While this seems to work most of the > time, there's an ungly deadlock: >=20 > syscall context is interrupted by the timer interrupt. When the timer > interrupt leaves, the timer softirq get's scheduled and calls > tcp_delack_timer() and alike. They themselves do bh_lock_sock(sk), > which is already held from somewhere else[1] -> boom. I've now tested the suggested solution by Patrick McHardy and Herbert Xu to simply use local_bh_{en,dis}able(). Please apply the following patch to mainline. btw: How do we get this into 2.6.11.x ? Signed-off-by: Harald Welte --=20 - Harald Welte http://netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --oxour8c+zPVguRmP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="queue-local-reinject-smp-deadlock-fix-localbhdisable.patch" Content-Transfer-Encoding: quoted-printable Index: linux-2.6.10/net/ipv4/netfilter/ip_queue.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.10.orig/net/ipv4/netfilter/ip_queue.c 2005-05-27 09:44:32.000= 000000 +0200 +++ linux-2.6.10/net/ipv4/netfilter/ip_queue.c 2005-05-27 09:47:13.00000000= 0 +0200 @@ -3,6 +3,7 @@ * communicating with userspace via netlink. * * (C) 2000-2002 James Morris + * (C) 2003-2005 Netfilter Core Team * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -14,6 +15,7 @@ * Zander). * 2000-08-01: Added Nick Williams' MAC support. * 2002-06-25: Code cleanup. + * 2005-05-26: local_bh_{disable,enable} around nf_reinject (Harald Welte) * */ #include @@ -66,7 +68,15 @@ static void ipq_issue_verdict(struct ipq_queue_entry *entry, int verdict) { + /* TCP input path (and probably other bits) assume to be called + * from softirq context, not from syscall, like ipq_issue_verdict is + * called. TCP input path deadlocks with locks taken from timer + * softirq, e.g. We therefore emulate this by local_bh_disable() */ + + local_bh_disable(); nf_reinject(entry->skb, entry->info, verdict); + local_bh_enable(); + kfree(entry); } =20 --oxour8c+zPVguRmP-- --vqZEy/DEMZDTzjXG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCm1Y+XaXGVTD0i/8RAufMAJ0c/XMkxoX9ELYwyvJ+K/SE9Gz68gCgj1v0 RB57oSGm8xQAhPsi4UgJT94= =OQYS -----END PGP SIGNATURE----- --vqZEy/DEMZDTzjXG-- From herbert@gondor.apana.org.au Mon May 30 14:50:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 14:50:57 -0700 (PDT) Received: from goliath.apana.org.au (goliath.apana.org.au [202.12.88.44]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4ULomXq029631 for ; Mon, 30 May 2005 14:50:49 -0700 Received: from arnor.apana.org.au ([203.14.152.115] ident=mail) by goliath.apana.org.au with esmtp (Exim 4.50) id 1Dcs8l-0002Y0-Fz; Tue, 31 May 2005 07:49:44 +1000 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Dcs8c-0007oG-00; Tue, 31 May 2005 07:49:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Dcs8Y-0006bl-00; Tue, 31 May 2005 07:49:30 +1000 From: Herbert Xu To: Steven.Hand@cl.cam.ac.uk (Steven Hand) Subject: Re: Bug in 2.6.11.11 - udp_poll(), fragments + CONFIG_HIGHMEM Cc: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, davem@davemloft.net, Steven.Hand@cl.cam.ac.uk, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.net User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 31 May 2005 07:49:30 +1000 X-SA-Exim-Connect-IP: 203.14.152.115 X-SA-Exim-Mail-From: herbert@gondor.apana.org.au X-SA-Exim-Scanned: No (on goliath.apana.org.au); SAEximRunCond expanded to false X-archive-position: 1871 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2402 Lines: 78 Steven Hand wrote: > > Reconstructed forward trace: > > net/ipv4/udp.c:1334 spin_lock_irq() > net/ipv4/udp.c:1336 udp_checksum_complete() > net/core/skbuff.c:1069 skb_shinfo(skb)->nr_frags > 1 > net/core/skbuff.c:1086 kunmap_skb_frag() > net/core/skbuff.h:1087 local_bh_enable() > kernel/softirq.c:0140 WARN_ON(irqs_disabled()); Thanks for catching this. The receive queue lock is never taken in IRQs (and should never be) so we can simply substitute bh for irq. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -738,7 +738,7 @@ int udp_ioctl(struct sock *sk, int cmd, unsigned long amount; amount = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); if (skb != NULL) { /* @@ -748,7 +748,7 @@ int udp_ioctl(struct sock *sk, int cmd, */ amount = skb->len - sizeof(struct udphdr); } - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); return put_user(amount, (int __user *)arg); } @@ -848,12 +848,12 @@ csum_copy_err: /* Clear queue. */ if (flags&MSG_PEEK) { int clear = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); if (skb == skb_peek(&sk->sk_receive_queue)) { __skb_unlink(skb, &sk->sk_receive_queue); clear = 1; } - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); if (clear) kfree_skb(skb); } @@ -1334,7 +1334,7 @@ unsigned int udp_poll(struct file *file, struct sk_buff_head *rcvq = &sk->sk_receive_queue; struct sk_buff *skb; - spin_lock_irq(&rcvq->lock); + spin_lock_bh(&rcvq->lock); while ((skb = skb_peek(rcvq)) != NULL) { if (udp_checksum_complete(skb)) { UDP_INC_STATS_BH(UDP_MIB_INERRORS); @@ -1345,7 +1345,7 @@ unsigned int udp_poll(struct file *file, break; } } - spin_unlock_irq(&rcvq->lock); + spin_unlock_bh(&rcvq->lock); /* nothing to see, move along */ if (skb == NULL) From davem@davemloft.net Mon May 30 15:27:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 15:27:53 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4UMRkXq031413 for ; Mon, 30 May 2005 15:27:47 -0700 Received: from localhost ([127.0.0.1]) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DcsiZ-0003Qp-IP; Mon, 30 May 2005 15:26:43 -0700 Date: Mon, 30 May 2005 15:26:13 -0700 (PDT) Message-Id: <20050530.152613.78709308.davem@davemloft.net> To: laforge@netfilter.org Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path From: "David S. Miller" In-Reply-To: <20050530180654.GX22760@sunbeam.de.gnumonks.org> References: <20050526142420.GD13114@sunbeam.de.gnumonks.org> <20050530180654.GX22760@sunbeam.de.gnumonks.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 415 Lines: 16 From: Harald Welte Date: Mon, 30 May 2005 20:06:54 +0200 > I've now tested the suggested solution by Patrick McHardy and Herbert Xu to > simply use local_bh_{en,dis}able(). > > Please apply the following patch to mainline. Will do. > btw: How do we get this into 2.6.11.x ? You submit your patch to stable@kernel.org. But I will take care of this for you Harald, don't worry about it. From davem@davemloft.net Mon May 30 15:52:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 15:52:29 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4UMq5Xq032706 for ; Mon, 30 May 2005 15:52:25 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Dct5h-00062F-6E; Mon, 30 May 2005 15:50:37 -0700 Date: Mon, 30 May 2005 15:50:37 -0700 (PDT) Message-Id: <20050530.155037.128618730.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: Steven.Hand@cl.cam.ac.uk, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Bug in 2.6.11.11 - udp_poll(), fragments + CONFIG_HIGHMEM From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1873 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 314 Lines: 10 From: Herbert Xu Date: Tue, 31 May 2005 07:49:30 +1000 > Thanks for catching this. The receive queue lock is never taken > in IRQs (and should never be) so we can simply substitute bh for > irq. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From jmorris@redhat.com Mon May 30 17:03:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 17:03:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4V03GXq007039 for ; Mon, 30 May 2005 17:03:17 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4V02ISt026315; Mon, 30 May 2005 20:02:19 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4V02HO25061; Mon, 30 May 2005 20:02:17 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j4V025Dj012023; Mon, 30 May 2005 20:02:05 -0400 Date: Mon, 30 May 2005 20:02:05 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: jaegert cc: netdev@oss.sgi.com, , , , Subject: Re: [PATCH 1/2] Resend: LSM-IPSec Networking Hooks In-Reply-To: <1116361510.5560.121.camel@dyn9002018177.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1874 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 3863 Lines: 146 On Tue, 17 May 2005, jaegert wrote: > The pfkey interface is tested using the ipsec-tools. ipsec-tools have > been modified (a separate ipsec-tools patch is available for version > 0.5) that supports assignment of xfrm_policy entries and security > associations with security contexts via setkey and the negotiation > using the security contexts via racoon. > > The xfrm_user interface is tested via ad hoc programs that set > security contexts. These programs are also available from me, and > contain programs for setting, getting, and deleting policy for testing > this interface. Testing of sa functions was done by tracing kernel > behavior. Can you please publish or send me (so I can publish) the ipsec-tools patch and these xfrm_user utilities? > [SADB_X_EXT_NAT_T_OA] = (u8) sizeof(struct sadb_address), > + [SADB_X_EXT_SEC_CTX] = (u8) sizeof(struct sadb_x_sec_ctx), > }; Indenting. > if (km_query(x, tmpl, pol) == 0) { > + if (!xfrm_sec_ctx_match(xfrm_policy_security(pol), xfrm_state_security(x))) { > + x->km.state = XFRM_STATE_DEAD; > + xfrm_state_put(x); > + x = NULL; > + error = 1; > + goto out; > + } Why set error to 1 here? This should be an -E value. > + if (security_xfrm_policy_clone(old, newp)) { > + kfree(newp); > + return (struct xfrm_policy *)NULL; /* ENOMEM */ > + } Don't cast NULL. > +static inline int xfrm_user_sec_ctx_size(struct xfrm_policy *xp) > +{ > + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp); > + int len; > + > + if (xfrm_ctx) { > + len = sizeof(struct xfrm_user_sec_ctx); > + len += xfrm_ctx->ctx_len; > + return len; > + } > + return 0; > +} This can be simplified with a single return path, initialize len to zero. > +static int attach_sec_ctx(struct xfrm_state *x, struct rtattr *u_arg) > +{ > + struct xfrm_user_sec_ctx *uxsc = RTA_DATA(u_arg); > + > + if (uxsc) { > + security_xfrm_state_free(x); > + return security_xfrm_state_alloc(x, uxsc); > + } > + > + return 0; > +} The security_xfrm_state_free() seems unecesary and buggy if needed. This is called in state allocation context, i.e. just afer xfrm_state_alloc() and there should be no already allocate security state. > +static int copy_sec_ctx(struct xfrm_policy *pol, struct xfrm_user_sec_ctx *uctx) > +{ > + int err = 0; > + > + security_xfrm_policy_free(pol); > + err = security_xfrm_policy_alloc(pol, uctx); > + return err; > +} Again, why free just before allocation? This code is only being called in policy allocation context and freeing like this would be buggy in any case. > +static int copy_from_user_sec_ctx(struct xfrm_policy *pol, struct rtattr **xfrma) > +{ > + struct rtattr *rt = xfrma[XFRMA_SEC_CTX-1]; > + struct xfrm_user_sec_ctx *uctx = RTA_DATA(rt); > + > + if (uctx) { > + copy_sec_ctx(pol, uctx); > + } > + > + return 0; > +} If it always returns zero, make it a void function. > + /* spi must be zero'd unless real tmpl */ > + for (tmpl = ut; tmpl->id.spi != 0; tmpl = tmpl + 1) Indenting. > + else { > + uctx = (struct xfrm_user_sec_ctx *) NULL; > nr = ((len - sizeof(*p)) / sizeof(*ut)); > if (nr > XFRM_MAX_DEPTH) > return NULL; > + } Indenting. > + if (uctx) > + copy_sec_ctx(xp, uctx); Why not just make copy_sec_ctx() check for uctx itself, so the calling code can be cleaner? > len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); > len += NLMSG_SPACE(sizeof(struct xfrm_user_polexpire)); > + len += xfrm_user_sec_ctx_size(xp); > skb = alloc_skb(len, GFP_ATOMIC); This looks wrong, the length is not aligned properly. NLMSG_SPACE needs to enclose the xfrm_user_sec_ctx_size() as well. (There's another one of these further down). - James -- James Morris From pablo@eurodev.net Mon May 30 17:28:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 17:28:47 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4V0SVXq008669 for ; Mon, 30 May 2005 17:28:41 -0700 Received: from [85.136.103.189] by smtp06.retemail.es (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050531002732.IWDS1136.smtp06.retemail.es@[85.136.103.189]>; Tue, 31 May 2005 02:27:32 +0200 Message-ID: <429BAFAD.3080804@eurodev.net> Date: Tue, 31 May 2005 02:28:29 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: shemminger@osdl.org CC: jamal , netdev Subject: [TC PATCH] some fixes for ipt action X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------060808090602060001060301" X-archive-position: 1875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 3542 Lines: 164 This is a multi-part message in MIME format. --------------060808090602060001060301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Stephen, I've sent this patch to jamal some weeks ago. He's acked it, you can confirm that from him. This patch: - fixes a leak on error paths (a similar path was commited to iptables two days ago[1]). - simplify option handling. - fixes final_check checking, it was broken. [1] https://lists.netfilter.org/pipermail/netfilter-devel/2005-May/019844.html Pablo --------------060808090602060001060301 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== tc/m_ipt.c 1.5 vs edited ===== --- 1.5/tc/m_ipt.c 2005-03-24 12:53:31 +01:00 +++ edited/tc/m_ipt.c 2005-03-31 02:05:42 +02:00 @@ -69,6 +69,7 @@ }; static struct iptables_target *t_list = NULL; +static struct option *opts = original_opts; static unsigned int global_option_offset = 0; #define OPTION_OFFSET 256 @@ -169,18 +170,13 @@ return result; } -static struct option * -copy_options(struct option *oldopts) +static void free_opts(struct option *opts) { - struct option *merge; - unsigned int num_old; - for (num_old = 0; oldopts[num_old].name; num_old++) ; - merge = malloc(sizeof (struct option) * (num_old + 1)); - if (NULL == merge) - return NULL; - memcpy(merge, oldopts, num_old * sizeof (struct option)); - memset(merge + num_old, 0, sizeof (struct option)); - return merge; + if (opts != original_opts) { + free(opts); + opts = original_opts; + global_option_offset = 0; + } } static struct option * @@ -385,7 +381,6 @@ int c; int rargc = *argc_p; char **argv = *argv_p; - struct option *opts; int argc = 0, iargc = 0; char k[16]; int res = -1; @@ -409,11 +404,6 @@ return -1; } - opts = copy_options(original_opts); - - if (NULL == opts) - return -1; - while (1) { c = getopt_long(argc, argv, "j:", opts, NULL); if (c == -1) @@ -440,23 +430,14 @@ default: memset(&fw, 0, sizeof (fw)); if (m) { - unsigned int fake_flags = 0; m->parse(c - m->option_offset, argv, 0, - &fake_flags, NULL, &m->t); + &m->tflags, NULL, &m->t); } else { fprintf(stderr," failed to find target %s\n\n", optarg); return -1; } ok++; - - /*m->final_check(m->t); -- Is this necessary? - ** useful when theres depencies - ** eg ipt_TCPMSS.c has have the TCP match loaded - ** before this can be used; - ** also seems the ECN target needs it - */ - break; } @@ -466,6 +447,7 @@ if (matches(argv[optind], "index") == 0) { if (get_u32(&index, argv[optind + 1], 10)) { fprintf(stderr, "Illegal \"index\"\n"); + free_opts(opts); return -1; } iok++; @@ -479,6 +461,10 @@ return -1; } + /* check that we passed the correct parameters to the target */ + if (m) + m->final_check(m->tflags); + { struct tcmsg *t = NLMSG_DATA(n); if (t->tcm_parent != TC_H_ROOT @@ -519,6 +505,7 @@ *argv_p = argv; optind = 1; + free_opts(opts); return 0; @@ -529,16 +516,10 @@ { struct rtattr *tb[TCA_IPT_MAX + 1]; struct ipt_entry_target *t = NULL; - struct option *opts; if (arg == NULL) return -1; - opts = copy_options(original_opts); - - if (NULL == opts) - return -1; - parse_rtattr_nested(tb, TCA_IPT_MAX, arg); if (tb[TCA_IPT_TABLE] == NULL) { @@ -601,6 +582,7 @@ fprintf(f, " \n"); } + free_opts(opts); return 0; } --------------060808090602060001060301-- From bunk@stusta.de Mon May 30 17:34:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 17:34:37 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4V0YXXq009608 for ; Mon, 30 May 2005 17:34:33 -0700 Received: (qmail 19700 invoked from network); 31 May 2005 00:33:39 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 31 May 2005 00:33:39 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 26C52BB4E4; Tue, 31 May 2005 02:33:39 +0200 (CEST) Date: Tue, 31 May 2005 02:33:39 +0200 From: Adrian Bunk To: Andrew Morton , netdev@oss.sgi.com, jgarzik@pobox.com Cc: linux-kernel@vger.kernel.org Subject: [-mm patch] fix IEEE80211_CRYPT_* selects Message-ID: <20050531003339.GG3627@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 1876 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 2999 Lines: 91 Some of the options didn't obey the most important rule of select If you select something, you have to ensure that the dependencies of what you do select are fulfilled. resulting in the following compile error: <-- snip --> ... LD .tmp_vmlinux1 crypto/built-in.o(.init.text+0x31b): In function `aes_init': : undefined reference to `crypto_register_alg' crypto/built-in.o(.init.text+0x326): In function `michael_mic_init': : undefined reference to `crypto_register_alg' crypto/built-in.o(.exit.text+0x6): In function `aes_fini': : undefined reference to `crypto_unregister_alg' crypto/built-in.o(.exit.text+0x16): In function `michael_mic_exit': : undefined reference to `crypto_unregister_alg' net/built-in.o(.text+0x5ba52): In function `ieee80211_ccmp_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5ba94): In function `ieee80211_ccmp_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5bab7): In function `ieee80211_ccmp_deinit': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c5c2): In function `ieee80211_tkip_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5c5d5): In function `ieee80211_tkip_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5c623): In function `ieee80211_tkip_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c62a): In function `ieee80211_tkip_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c65e): In function `ieee80211_tkip_deinit': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c665): In function `ieee80211_tkip_deinit': : undefined reference to `crypto_free_tfm' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> This patch adds the missing selects of CRYPTO (similar to how IEEE80211_CRYPT_WEP already does it). Yes, you could argue whether CRYPTO should be select'ed by the CRYPTO_* options, but with the current CRYPTO* dependencies this patch is required. --- This patch was already sent on: - 7 May 2005 - 26 Feb 2005 net/ieee80211/Kconfig | 2 ++ 1 files changed, 2 insertions(+) --- linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig.old 2005-02-26 12:12:44.000000000 +0100 +++ linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig 2005-02-26 12:13:47.000000000 +0100 @@ -42,10 +42,11 @@ "ieee80211_crypt_wep". config IEEE80211_CRYPT_CCMP tristate "IEEE 802.11i CCMP support" depends on IEEE80211 + select CRYPTO select CRYPTO_AES ---help--- Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled networks. @@ -54,10 +55,11 @@ "ieee80211_crypt_ccmp". config IEEE80211_CRYPT_TKIP tristate "IEEE 802.11i TKIP encryption" depends on IEEE80211 + select CRYPTO select CRYPTO_MICHAEL_MIC ---help--- Include software based cipher suites in support of IEEE 802.11i (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with TKIP enabled networks. From james@grickle.org Mon May 30 17:34:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 17:34:57 -0700 (PDT) Received: from cerberus.grickle.org (Alameda.net.has.not.owned.this.ip.for.more.then.four.years [209.0.49.117] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4V0YmXq009656 for ; Mon, 30 May 2005 17:34:52 -0700 Received: from cerberus.grickle.org (localhost [127.0.0.1]) by cerberus.grickle.org (8.13.3/8.13.3) with ESMTP id j4V0XmLs017944; Mon, 30 May 2005 19:33:48 -0500 Received: from localhost (localhost [[UNIX: localhost]]) by cerberus.grickle.org (8.13.3/8.13.3/Submit) id j4V0RQGZ015129; Mon, 30 May 2005 19:27:26 -0500 X-Authentication-Warning: cerberus.grickle.org: james set sender to james@grickle.org using -f From: James Harr To: Francois Romieu Subject: Re: r8169 802.1q/MTU bug Date: Mon, 30 May 2005 19:27:26 -0500 User-Agent: KMail/1.8 References: <20050530071148.GB1514@electric-eye.fr.zoreil.com> In-Reply-To: <20050530071148.GB1514@electric-eye.fr.zoreil.com> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505301927.26110.james@grickle.org> X-archive-position: 1877 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: james@grickle.org Precedence: bulk X-list: netdev Content-Length: 1746 Lines: 57 Hi, The driver you sent gives me an error when I try to compile and load it with 2.6.11.11: # make [...] CC [M] drivers/net/r8169.o drivers/net/r8169.c: In function `rtl8169_down': drivers/net/r8169.c:2589: warning: implicit declaration of function synchronize_sched [...] # insmod drivers/net/r8169.ko insmod: error inserting 'drivers/net/r8169.ko': -1 Unknown symbol in module It does a similar thing when I try to install it: # make modules_install [...] if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.11.11; fi WARNING: /lib/modules/2.6.11.11/kernel/drivers/net/r8169.ko needs unknown symbol synchronize_sched As I noted in a previous email, it doesn't give me this problem when I have jumbo frames enabled on my switch. Since I found out my switch supported jumbo frames, I started to toy around with larger MTUs. When a VLAN's MTU was set to 7200, my system locked up. I didn't have this problem at 7196. Also, the crash problem wasn't there on a regular interface with no VLANs and the MTU at 7200. Thanks, James Harr On Monday 30 May 2005 2:11 am, you wrote: > James Harr : > [...] > > > I've been using a gigabit RealTek 8169 card for a while, I just recently > > started using 802.1q with them. I stumbled upon the problem described at > > the top of here: > > > > http://www.candelatech.com/~greear/vlan/howto.html > > Can you try the attached version of the r8169 driver with the latest > kernel ? > > If the issue is still there, it is almost surely the one you link to. > I'll give it a look when I'm back at home, it should not be long to fix. > > Please Cc: netdev@oss.sgi.com (it is archived and googlable). -- James Harr http://www.grickle.org/ From bunk@stusta.de Mon May 30 17:59:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 17:59:59 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4V0xrXq012319 for ; Mon, 30 May 2005 17:59:53 -0700 Received: (qmail 20067 invoked from network); 31 May 2005 00:58:57 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 31 May 2005 00:58:57 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 40558AF51B; Tue, 31 May 2005 02:58:57 +0200 (CEST) Date: Tue, 31 May 2005 02:58:57 +0200 From: Adrian Bunk To: Andrew Morton Cc: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: [2.6 patch] drivers/net/wan/: possible cleanups Message-ID: <20050531005857.GJ3627@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 1878 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 29904 Lines: 950 This patch contains possible cleanups including the following: - make needlessly global code static - #if 0 the following unused global function: - sdladrv.c: sdla_intde - remove the following unused global variable: - lmc_media.c: lmc_t1_cables - remove the following unneeded EXPORT_SYMBOL's: - cycx_drv.c: cycx_inten - sdladrv.c: sdla_inten - sdladrv.c: sdla_intde - sdladrv.c: sdla_intack - sdladrv.c: sdla_intr - syncppp.c: sppp_input - syncppp.c: sppp_change_mtu Signed-off-by: Adrian Bunk --- This patch was already sent on: - 18 Apr 2005 drivers/net/wan/cycx_drv.c | 7 +- drivers/net/wan/cycx_main.c | 2 drivers/net/wan/dscc4.c | 14 ++--- drivers/net/wan/farsync.c | 24 ++++---- drivers/net/wan/hdlc_fr.c | 2 drivers/net/wan/lmc/lmc_debug.c | 10 +-- drivers/net/wan/lmc/lmc_media.c | 8 -- drivers/net/wan/pc300.h | 16 ----- drivers/net/wan/pc300_drv.c | 87 ++++++++++++++++---------------- drivers/net/wan/pc300_tty.c | 18 +++--- drivers/net/wan/sdla.c | 20 +++---- drivers/net/wan/sdladrv.c | 16 ++--- drivers/net/wan/syncppp.c | 10 +-- include/linux/cycx_drv.h | 1 include/linux/sdladrv.h | 4 - include/net/syncppp.h | 1 16 files changed, 101 insertions(+), 139 deletions(-) --- linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h.old 2005-02-16 19:14:39.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h 2005-02-16 19:14:46.000000000 +0100 @@ -60,6 +60,5 @@ extern int cycx_poke(struct cycx_hw *hw, u32 addr, void *buf, u32 len); extern int cycx_exec(void __iomem *addr); -extern void cycx_inten(struct cycx_hw *hw); extern void cycx_intr(struct cycx_hw *hw); #endif /* _CYCX_DRV_H */ --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c.old 2005-02-16 19:14:55.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c 2005-02-16 19:15:35.000000000 +0100 @@ -110,7 +110,7 @@ * < 0 error. * Context: process */ -int __init cycx_drv_init(void) +static int __init cycx_drv_init(void) { printk(KERN_INFO "%s v%u.%u %s\n", fullname, MOD_VERSION, MOD_RELEASE, copyright); @@ -120,7 +120,7 @@ /* Module 'remove' entry point. * o release all remaining system resources */ -void cycx_drv_cleanup(void) +static void cycx_drv_cleanup(void) { } @@ -185,8 +185,7 @@ } /* Enable interrupt generation. */ -EXPORT_SYMBOL(cycx_inten); -void cycx_inten(struct cycx_hw *hw) +static void cycx_inten(struct cycx_hw *hw) { writeb(0, hw->dpmbase); } --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c.old 2005-02-16 19:46:47.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c 2005-02-16 19:47:00.000000000 +0100 @@ -103,7 +103,7 @@ * < 0 error. * Context: process */ -int __init cycx_init(void) +static int __init cycx_init(void) { int cnt, err = -ENOMEM; --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c.old 2005-02-16 23:57:37.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c 2005-02-17 00:00:26.000000000 +0100 @@ -74,11 +74,11 @@ /* * Modules parameters and associated varaibles */ -int fst_txq_low = FST_LOW_WATER_MARK; -int fst_txq_high = FST_HIGH_WATER_MARK; -int fst_max_reads = 7; -int fst_excluded_cards = 0; -int fst_excluded_list[FST_MAX_CARDS]; +static int fst_txq_low = FST_LOW_WATER_MARK; +static int fst_txq_high = FST_HIGH_WATER_MARK; +static int fst_max_reads = 7; +static int fst_excluded_cards = 0; +static int fst_excluded_list[FST_MAX_CARDS]; module_param(fst_txq_low, int, 0); module_param(fst_txq_high, int, 0); @@ -572,13 +572,13 @@ static void fst_process_tx_work_q(unsigned long work_q); static void fst_process_int_work_q(unsigned long work_q); -DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0); -DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0); +static DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0); +static DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0); -struct fst_card_info *fst_card_array[FST_MAX_CARDS]; -spinlock_t fst_work_q_lock; -u64 fst_work_txq; -u64 fst_work_intq; +static struct fst_card_info *fst_card_array[FST_MAX_CARDS]; +static spinlock_t fst_work_q_lock; +static u64 fst_work_txq; +static u64 fst_work_intq; static void fst_q_work_item(u64 * queue, int card_index) @@ -1498,7 +1498,7 @@ * The interrupt service routine * Dev_id is our fst_card_info pointer */ -irqreturn_t +static irqreturn_t fst_intr(int irq, void *dev_id, struct pt_regs *regs) { struct fst_card_info *card; --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/hdlc_fr.c.old 2005-02-17 00:00:38.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/hdlc_fr.c 2005-02-17 00:00:46.000000000 +0100 @@ -347,7 +347,7 @@ -int pvc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +static int pvc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { pvc_device *pvc = dev_to_pvc(dev); fr_proto_pvc_info info; --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/lmc/lmc_media.c.old 2005-02-17 00:02:29.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/lmc/lmc_media.c 2005-02-17 00:02:47.000000000 +0100 @@ -48,14 +48,6 @@ */ /* - * For lack of a better place, put the SSI cable stuff here. - */ -char *lmc_t1_cables[] = { - "V.10/RS423", "EIA530A", "reserved", "X.21", "V.35", - "EIA449/EIA530/V.36", "V.28/EIA232", "none", NULL -}; - -/* * protocol independent method. */ static void lmc_set_protocol (lmc_softc_t * const, lmc_ctl_t *); --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300.h.old 2005-02-17 00:03:07.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300.h 2005-02-17 00:55:23.000000000 +0100 @@ -472,24 +472,8 @@ #ifdef __KERNEL__ /* Function Prototypes */ -int dma_buf_write(pc300_t *, int, ucchar *, int); -int dma_buf_read(pc300_t *, int, struct sk_buff *); void tx_dma_start(pc300_t *, int); -void rx_dma_start(pc300_t *, int); -void tx_dma_stop(pc300_t *, int); -void rx_dma_stop(pc300_t *, int); -int cpc_queue_xmit(struct sk_buff *, struct net_device *); -void cpc_net_rx(struct net_device *); -void cpc_sca_status(pc300_t *, int); -int cpc_change_mtu(struct net_device *, int); -int cpc_ioctl(struct net_device *, struct ifreq *, int); -int ch_config(pc300dev_t *); -int rx_config(pc300dev_t *); -int tx_config(pc300dev_t *); -void cpc_opench(pc300dev_t *); -void cpc_closech(pc300dev_t *); int cpc_open(struct net_device *dev); -int cpc_close(struct net_device *dev); int cpc_set_media(hdlc_device *, int); #endif /* __KERNEL__ */ --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300_drv.c.old 2005-02-17 00:03:20.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300_drv.c 2005-02-17 00:14:10.000000000 +0100 @@ -291,6 +291,7 @@ static void plx_init(pc300_t *); static void cpc_trace(struct net_device *, struct sk_buff *, char); static int cpc_attach(struct net_device *, unsigned short, unsigned short); +static int cpc_close(struct net_device *dev); #ifdef CONFIG_PC300_MLPPP void cpc_tty_init(pc300dev_t * dev); @@ -437,7 +438,7 @@ printk("\n"); } -int dma_get_rx_frame_size(pc300_t * card, int ch) +static int dma_get_rx_frame_size(pc300_t * card, int ch) { volatile pcsca_bd_t __iomem *ptdescr; ucshort first_bd = card->chan[ch].rx_first_bd; @@ -462,7 +463,7 @@ * dma_buf_write: writes a frame to the Tx DMA buffers * NOTE: this function writes one frame at a time. */ -int dma_buf_write(pc300_t * card, int ch, ucchar * ptdata, int len) +static int dma_buf_write(pc300_t * card, int ch, ucchar * ptdata, int len) { int i, nchar; volatile pcsca_bd_t __iomem *ptdescr; @@ -503,7 +504,7 @@ * dma_buf_read: reads a frame from the Rx DMA buffers * NOTE: this function reads one frame at a time. */ -int dma_buf_read(pc300_t * card, int ch, struct sk_buff *skb) +static int dma_buf_read(pc300_t * card, int ch, struct sk_buff *skb) { int nchar; pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; @@ -560,7 +561,7 @@ return (rcvd); } -void tx_dma_stop(pc300_t * card, int ch) +static void tx_dma_stop(pc300_t * card, int ch) { void __iomem *scabase = card->hw.scabase; ucchar drr_ena_bit = 1 << (5 + 2 * ch); @@ -571,7 +572,7 @@ cpc_writeb(scabase + DRR, drr_rst_bit & ~drr_ena_bit); } -void rx_dma_stop(pc300_t * card, int ch) +static void rx_dma_stop(pc300_t * card, int ch) { void __iomem *scabase = card->hw.scabase; ucchar drr_ena_bit = 1 << (4 + 2 * ch); @@ -582,7 +583,7 @@ cpc_writeb(scabase + DRR, drr_rst_bit & ~drr_ena_bit); } -void rx_dma_start(pc300_t * card, int ch) +static void rx_dma_start(pc300_t * card, int ch) { void __iomem *scabase = card->hw.scabase; pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; @@ -607,7 +608,7 @@ /*************************/ /*** FALC Routines ***/ /*************************/ -void falc_issue_cmd(pc300_t * card, int ch, ucchar cmd) +static void falc_issue_cmd(pc300_t * card, int ch, ucchar cmd) { void __iomem *falcbase = card->hw.falcbase; unsigned long i = 0; @@ -622,7 +623,7 @@ cpc_writeb(falcbase + F_REG(CMDR, ch), cmd); } -void falc_intr_enable(pc300_t * card, int ch) +static void falc_intr_enable(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -672,7 +673,7 @@ } } -void falc_open_timeslot(pc300_t * card, int ch, int timeslot) +static void falc_open_timeslot(pc300_t * card, int ch, int timeslot) { void __iomem *falcbase = card->hw.falcbase; ucchar tshf = card->chan[ch].falc.offset; @@ -688,7 +689,7 @@ (0x80 >> (timeslot & 0x07))); } -void falc_close_timeslot(pc300_t * card, int ch, int timeslot) +static void falc_close_timeslot(pc300_t * card, int ch, int timeslot) { void __iomem *falcbase = card->hw.falcbase; ucchar tshf = card->chan[ch].falc.offset; @@ -704,7 +705,7 @@ ~(0x80 >> (timeslot & 0x07))); } -void falc_close_all_timeslots(pc300_t * card, int ch) +static void falc_close_all_timeslots(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -726,7 +727,7 @@ } } -void falc_open_all_timeslots(pc300_t * card, int ch) +static void falc_open_all_timeslots(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -758,7 +759,7 @@ } } -void falc_init_timeslot(pc300_t * card, int ch) +static void falc_init_timeslot(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -776,7 +777,7 @@ } } -void falc_enable_comm(pc300_t * card, int ch) +static void falc_enable_comm(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -792,7 +793,7 @@ ~((CPLD_REG1_FALC_DCD | CPLD_REG1_FALC_CTS) << (2 * ch))); } -void falc_disable_comm(pc300_t * card, int ch) +static void falc_disable_comm(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -806,7 +807,7 @@ ((CPLD_REG1_FALC_DCD | CPLD_REG1_FALC_CTS) << (2 * ch))); } -void falc_init_t1(pc300_t * card, int ch) +static void falc_init_t1(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -975,7 +976,7 @@ falc_close_all_timeslots(card, ch); } -void falc_init_e1(pc300_t * card, int ch) +static void falc_init_e1(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1155,7 +1156,7 @@ falc_close_all_timeslots(card, ch); } -void falc_init_hdlc(pc300_t * card, int ch) +static void falc_init_hdlc(pc300_t * card, int ch) { void __iomem *falcbase = card->hw.falcbase; pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; @@ -1181,7 +1182,7 @@ falc_intr_enable(card, ch); } -void te_config(pc300_t * card, int ch) +static void te_config(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1241,7 +1242,7 @@ CPC_UNLOCK(card, flags); } -void falc_check_status(pc300_t * card, int ch, unsigned char frs0) +static void falc_check_status(pc300_t * card, int ch, unsigned char frs0) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1397,7 +1398,7 @@ } } -void falc_update_stats(pc300_t * card, int ch) +static void falc_update_stats(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1450,7 +1451,7 @@ * the synchronizer and then sent to the system interface. *---------------------------------------------------------------------------- */ -void falc_remote_loop(pc300_t * card, int ch, int loop_on) +static void falc_remote_loop(pc300_t * card, int ch, int loop_on) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1495,7 +1496,7 @@ * coding must be identical. *---------------------------------------------------------------------------- */ -void falc_local_loop(pc300_t * card, int ch, int loop_on) +static void falc_local_loop(pc300_t * card, int ch, int loop_on) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -1522,7 +1523,7 @@ * looped. They are originated by the FALC-LH transmitter. *---------------------------------------------------------------------------- */ -void falc_payload_loop(pc300_t * card, int ch, int loop_on) +static void falc_payload_loop(pc300_t * card, int ch, int loop_on) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1576,7 +1577,7 @@ * Description: Turns XLU bit off in the proper register *---------------------------------------------------------------------------- */ -void turn_off_xlu(pc300_t * card, int ch) +static void turn_off_xlu(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1597,7 +1598,7 @@ * Description: Turns XLD bit off in the proper register *---------------------------------------------------------------------------- */ -void turn_off_xld(pc300_t * card, int ch) +static void turn_off_xld(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1619,7 +1620,7 @@ * to generate a LOOP activation code over a T1/E1 line. *---------------------------------------------------------------------------- */ -void falc_generate_loop_up_code(pc300_t * card, int ch) +static void falc_generate_loop_up_code(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1652,7 +1653,7 @@ * to generate a LOOP deactivation code over a T1/E1 line. *---------------------------------------------------------------------------- */ -void falc_generate_loop_down_code(pc300_t * card, int ch) +static void falc_generate_loop_down_code(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1682,7 +1683,7 @@ * it on the reception side. *---------------------------------------------------------------------------- */ -void falc_pattern_test(pc300_t * card, int ch, unsigned int activate) +static void falc_pattern_test(pc300_t * card, int ch, unsigned int activate) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1729,7 +1730,7 @@ * Description: This routine returns the bit error counter value *---------------------------------------------------------------------------- */ -ucshort falc_pattern_test_error(pc300_t * card, int ch) +static ucshort falc_pattern_test_error(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -1769,7 +1770,7 @@ netif_rx(skb); } -void cpc_tx_timeout(struct net_device *dev) +static void cpc_tx_timeout(struct net_device *dev) { pc300dev_t *d = (pc300dev_t *) dev->priv; pc300ch_t *chan = (pc300ch_t *) d->chan; @@ -1797,7 +1798,7 @@ netif_wake_queue(dev); } -int cpc_queue_xmit(struct sk_buff *skb, struct net_device *dev) +static int cpc_queue_xmit(struct sk_buff *skb, struct net_device *dev) { pc300dev_t *d = (pc300dev_t *) dev->priv; pc300ch_t *chan = (pc300ch_t *) d->chan; @@ -1880,7 +1881,7 @@ return 0; } -void cpc_net_rx(struct net_device *dev) +static void cpc_net_rx(struct net_device *dev) { pc300dev_t *d = (pc300dev_t *) dev->priv; pc300ch_t *chan = (pc300ch_t *) d->chan; @@ -2403,7 +2404,7 @@ return IRQ_HANDLED; } -void cpc_sca_status(pc300_t * card, int ch) +static void cpc_sca_status(pc300_t * card, int ch) { ucchar ilar; void __iomem *scabase = card->hw.scabase; @@ -2495,7 +2496,7 @@ } } -void cpc_falc_status(pc300_t * card, int ch) +static void cpc_falc_status(pc300_t * card, int ch) { pc300ch_t *chan = &card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -2523,7 +2524,7 @@ CPC_UNLOCK(card, flags); } -int cpc_change_mtu(struct net_device *dev, int new_mtu) +static int cpc_change_mtu(struct net_device *dev, int new_mtu) { if ((new_mtu < 128) || (new_mtu > PC300_DEF_MTU)) return -EINVAL; @@ -2531,7 +2532,7 @@ return 0; } -int cpc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +static int cpc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { hdlc_device *hdlc = dev_to_hdlc(dev); pc300dev_t *d = (pc300dev_t *) dev->priv; @@ -2856,7 +2857,7 @@ } } -int ch_config(pc300dev_t * d) +static int ch_config(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -3004,7 +3005,7 @@ return 0; } -int rx_config(pc300dev_t * d) +static int rx_config(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300_t *card = (pc300_t *) chan->card; @@ -3035,7 +3036,7 @@ return 0; } -int tx_config(pc300dev_t * d) +static int tx_config(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300_t *card = (pc300_t *) chan->card; @@ -3098,7 +3099,7 @@ return 0; } -void cpc_opench(pc300dev_t * d) +static void cpc_opench(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300_t *card = (pc300_t *) chan->card; @@ -3116,7 +3117,7 @@ cpc_readb(scabase + M_REG(CTL, ch)) & ~(CTL_RTS | CTL_DTR)); } -void cpc_closech(pc300dev_t * d) +static void cpc_closech(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300_t *card = (pc300_t *) chan->card; @@ -3173,7 +3174,7 @@ return 0; } -int cpc_close(struct net_device *dev) +static int cpc_close(struct net_device *dev) { hdlc_device *hdlc = dev_to_hdlc(dev); pc300dev_t *d = (pc300dev_t *) dev->priv; --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdla.c.old 2005-02-17 00:15:50.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdla.c 2005-02-17 00:17:56.000000000 +0100 @@ -182,7 +182,7 @@ return(byte); } -void sdla_stop(struct net_device *dev) +static void sdla_stop(struct net_device *dev) { struct frad_local *flp; @@ -209,7 +209,7 @@ } } -void sdla_start(struct net_device *dev) +static void sdla_start(struct net_device *dev) { struct frad_local *flp; @@ -247,7 +247,7 @@ * ***************************************************/ -int sdla_z80_poll(struct net_device *dev, int z80_addr, int jiffs, char resp1, char resp2) +static int sdla_z80_poll(struct net_device *dev, int z80_addr, int jiffs, char resp1, char resp2) { unsigned long start, done, now; char resp, *temp; @@ -505,7 +505,7 @@ static int sdla_reconfig(struct net_device *dev); -int sdla_activate(struct net_device *slave, struct net_device *master) +static int sdla_activate(struct net_device *slave, struct net_device *master) { struct frad_local *flp; int i; @@ -527,7 +527,7 @@ return(0); } -int sdla_deactivate(struct net_device *slave, struct net_device *master) +static int sdla_deactivate(struct net_device *slave, struct net_device *master) { struct frad_local *flp; int i; @@ -549,7 +549,7 @@ return(0); } -int sdla_assoc(struct net_device *slave, struct net_device *master) +static int sdla_assoc(struct net_device *slave, struct net_device *master) { struct frad_local *flp; int i; @@ -585,7 +585,7 @@ return(0); } -int sdla_deassoc(struct net_device *slave, struct net_device *master) +static int sdla_deassoc(struct net_device *slave, struct net_device *master) { struct frad_local *flp; int i; @@ -613,7 +613,7 @@ return(0); } -int sdla_dlci_conf(struct net_device *slave, struct net_device *master, int get) +static int sdla_dlci_conf(struct net_device *slave, struct net_device *master, int get) { struct frad_local *flp; struct dlci_local *dlp; @@ -1324,7 +1324,7 @@ return(0); } -int sdla_change_mtu(struct net_device *dev, int new_mtu) +static int sdla_change_mtu(struct net_device *dev, int new_mtu) { struct frad_local *flp; @@ -1337,7 +1337,7 @@ return(-EOPNOTSUPP); } -int sdla_set_config(struct net_device *dev, struct ifmap *map) +static int sdla_set_config(struct net_device *dev, struct ifmap *map) { struct frad_local *flp; int i; --- linux-2.6.11-rc3-mm2-full/include/linux/sdladrv.h.old 2005-02-17 00:18:15.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/include/linux/sdladrv.h 2005-02-17 00:19:47.000000000 +0100 @@ -52,12 +52,8 @@ extern int sdla_setup (sdlahw_t* hw, void* sfm, unsigned len); extern int sdla_down (sdlahw_t* hw); -extern int sdla_inten (sdlahw_t* hw); -extern int sdla_intde (sdlahw_t* hw); -extern int sdla_intack (sdlahw_t* hw); extern void S514_intack (sdlahw_t* hw, u32 int_status); extern void read_S514_int_stat (sdlahw_t* hw, u32* int_status); -extern int sdla_intr (sdlahw_t* hw); extern int sdla_mapmem (sdlahw_t* hw, unsigned long addr); extern int sdla_peek (sdlahw_t* hw, unsigned long addr, void* buf, unsigned len); --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdladrv.c.old 2005-02-17 00:18:30.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdladrv.c 2005-02-17 00:20:04.000000000 +0100 @@ -642,9 +642,7 @@ * Enable interrupt generation. */ -EXPORT_SYMBOL(sdla_inten); - -int sdla_inten (sdlahw_t* hw) +static int sdla_inten (sdlahw_t* hw) { unsigned port = hw->port; int tmp, i; @@ -698,8 +696,7 @@ * Disable interrupt generation. */ -EXPORT_SYMBOL(sdla_intde); - +#if 0 int sdla_intde (sdlahw_t* hw) { unsigned port = hw->port; @@ -748,14 +745,13 @@ } return 0; } +#endif /* 0 */ /*============================================================================ * Acknowledge SDLA hardware interrupt. */ -EXPORT_SYMBOL(sdla_intack); - -int sdla_intack (sdlahw_t* hw) +static int sdla_intack (sdlahw_t* hw) { unsigned port = hw->port; int tmp; @@ -827,8 +823,7 @@ * Generate an interrupt to adapter's CPU. */ -EXPORT_SYMBOL(sdla_intr); - +#if 0 int sdla_intr (sdlahw_t* hw) { unsigned port = hw->port; @@ -863,6 +858,7 @@ } return 0; } +#endif /* 0 */ /*============================================================================ * Execute Adapter Command. --- linux-2.6.11-rc3-mm2-full/include/net/syncppp.h.old 2005-02-17 00:20:19.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/include/net/syncppp.h 2005-02-17 00:20:25.000000000 +0100 @@ -86,7 +86,6 @@ void sppp_attach (struct ppp_device *pd); void sppp_detach (struct net_device *dev); -void sppp_input (struct net_device *dev, struct sk_buff *m); int sppp_do_ioctl (struct net_device *dev, struct ifreq *ifr, int cmd); struct sk_buff *sppp_dequeue (struct net_device *dev); int sppp_isempty (struct net_device *dev); --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/syncppp.c.old 2005-02-17 00:20:36.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/syncppp.c 2005-02-17 00:21:37.000000000 +0100 @@ -221,7 +221,7 @@ * here. */ -void sppp_input (struct net_device *dev, struct sk_buff *skb) +static void sppp_input (struct net_device *dev, struct sk_buff *skb) { struct ppp_header *h; struct sppp *sp = (struct sppp *)sppp_of(dev); @@ -355,8 +355,6 @@ return; } -EXPORT_SYMBOL(sppp_input); - /* * Handle transmit packets. */ @@ -990,7 +988,7 @@ * the mtu is out of range. */ -int sppp_change_mtu(struct net_device *dev, int new_mtu) +static int sppp_change_mtu(struct net_device *dev, int new_mtu) { if(new_mtu<128||new_mtu>PPP_MTU||(dev->flags&IFF_UP)) return -EINVAL; @@ -998,8 +996,6 @@ return 0; } -EXPORT_SYMBOL(sppp_change_mtu); - /** * sppp_do_ioctl - Ioctl handler for ppp/hdlc * @dev: Device subject to ioctl @@ -1455,7 +1451,7 @@ return 0; } -struct packet_type sppp_packet_type = { +static struct packet_type sppp_packet_type = { .type = __constant_htons(ETH_P_WAN_PPP), .func = sppp_rcv, }; --- linux-2.6.12-rc2-mm3-full/drivers/net/wan/lmc/lmc_debug.c.old 2005-04-18 22:42:50.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/wan/lmc/lmc_debug.c 2005-04-18 22:44:32.000000000 +0200 @@ -8,10 +8,10 @@ /* * Prints out len, max to 80 octets using printk, 20 per line */ -void lmcConsoleLog(char *type, unsigned char *ucData, int iLen) -{ #ifdef DEBUG #ifdef LMC_PACKET_LOG +void lmcConsoleLog(char *type, unsigned char *ucData, int iLen) +{ int iNewLine = 1; char str[80], *pstr; @@ -43,26 +43,24 @@ } sprintf(pstr, "\n"); printk(str); +} #endif #endif -} #ifdef DEBUG u_int32_t lmcEventLogIndex = 0; u_int32_t lmcEventLogBuf[LMC_EVENTLOGSIZE * LMC_EVENTLOGARGS]; -#endif void lmcEventLog (u_int32_t EventNum, u_int32_t arg2, u_int32_t arg3) { -#ifdef DEBUG lmcEventLogBuf[lmcEventLogIndex++] = EventNum; lmcEventLogBuf[lmcEventLogIndex++] = arg2; lmcEventLogBuf[lmcEventLogIndex++] = arg3; lmcEventLogBuf[lmcEventLogIndex++] = jiffies; lmcEventLogIndex &= (LMC_EVENTLOGSIZE * LMC_EVENTLOGARGS) - 1; -#endif } +#endif /* DEBUG */ void lmc_trace(struct net_device *dev, char *msg){ #ifdef LMC_TRACE --- linux-2.6.12-rc2-mm3-full/drivers/net/wan/pc300_tty.c.old 2005-04-18 22:45:21.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/wan/pc300_tty.c 2005-04-18 22:46:51.000000000 +0200 @@ -112,10 +112,10 @@ static struct tty_driver serial_drv; /* local variables */ -st_cpc_tty_area cpc_tty_area[CPC_TTY_NPORTS]; +static st_cpc_tty_area cpc_tty_area[CPC_TTY_NPORTS]; -int cpc_tty_cnt=0; /* number of intrfaces configured with MLPPP */ -int cpc_tty_unreg_flag = 0; +static int cpc_tty_cnt = 0; /* number of intrfaces configured with MLPPP */ +static int cpc_tty_unreg_flag = 0; /* TTY functions prototype */ static int cpc_tty_open(struct tty_struct *tty, struct file *flip); @@ -132,9 +132,9 @@ static void cpc_tty_signal_off(pc300dev_t *pc300dev, unsigned char); static void cpc_tty_signal_on(pc300dev_t *pc300dev, unsigned char); -int pc300_tiocmset(struct tty_struct *, struct file *, - unsigned int, unsigned int); -int pc300_tiocmget(struct tty_struct *, struct file *); +static int pc300_tiocmset(struct tty_struct *, struct file *, + unsigned int, unsigned int); +static int pc300_tiocmget(struct tty_struct *, struct file *); /* functions called by PC300 driver */ void cpc_tty_init(pc300dev_t *dev); @@ -540,8 +540,8 @@ return(0); } -int pc300_tiocmset(struct tty_struct *tty, struct file *file, - unsigned int set, unsigned int clear) +static int pc300_tiocmset(struct tty_struct *tty, struct file *file, + unsigned int set, unsigned int clear) { st_cpc_tty_area *cpc_tty; @@ -567,7 +567,7 @@ return 0; } -int pc300_tiocmget(struct tty_struct *tty, struct file *file) +static int pc300_tiocmget(struct tty_struct *tty, struct file *file) { unsigned int result; unsigned char status; --- linux-2.6.12-rc2-mm3-full/drivers/net/wan/dscc4.c.old 2005-04-18 23:16:49.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/wan/dscc4.c 2005-04-18 23:18:21.000000000 +0200 @@ -446,8 +446,8 @@ return readl(dpriv->base_addr + CH0FTDA + dpriv->dev_id*4) == dpriv->ltda; } -int state_check(u32 state, struct dscc4_dev_priv *dpriv, struct net_device *dev, - const char *msg) +static int state_check(u32 state, struct dscc4_dev_priv *dpriv, + struct net_device *dev, const char *msg) { int ret = 0; @@ -466,8 +466,9 @@ return ret; } -void dscc4_tx_print(struct net_device *dev, struct dscc4_dev_priv *dpriv, - char *msg) +static void dscc4_tx_print(struct net_device *dev, + struct dscc4_dev_priv *dpriv, + char *msg) { printk(KERN_DEBUG "%s: tx_current=%02d tx_dirty=%02d (%s)\n", dev->name, dpriv->tx_current, dpriv->tx_dirty, msg); @@ -507,7 +508,8 @@ } } -inline int try_get_rx_skb(struct dscc4_dev_priv *dpriv, struct net_device *dev) +static inline int try_get_rx_skb(struct dscc4_dev_priv *dpriv, + struct net_device *dev) { unsigned int dirty = dpriv->rx_dirty%RX_RING_SIZE; struct RxFD *rx_fd = dpriv->rx_fd + dirty; @@ -1894,7 +1896,7 @@ * It failed and locked solid. Thus the introduction of a dummy skb. * Problem is acknowledged in errata sheet DS5. Joy :o/ */ -struct sk_buff *dscc4_init_dummy_skb(struct dscc4_dev_priv *dpriv) +static struct sk_buff *dscc4_init_dummy_skb(struct dscc4_dev_priv *dpriv) { struct sk_buff *skb; From jm@jm.kir.nu Mon May 30 18:26:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 18:26:45 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4V1QZXq014516 for ; Mon, 30 May 2005 18:26:36 -0700 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DcvSE-0003J1-Ky; Mon, 30 May 2005 18:22:02 -0700 Date: Mon, 30 May 2005 18:22:01 -0700 From: Jouni Malinen To: Adrian Bunk Cc: hostap@shmoo.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [-mm patch] net/ieee80211/: remove pci.h #include's Message-ID: <20050531012200.GC7950@jm.kir.nu> Mail-Followup-To: Adrian Bunk , hostap@shmoo.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050530205634.GQ10441@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050530205634.GQ10441@stusta.de> User-Agent: Mutt/1.5.8i X-archive-position: 1879 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 652 Lines: 16 On Mon, May 30, 2005 at 10:56:34PM +0200, Adrian Bunk wrote: > I was wondering why editing pci.h triggered the rebuild of three files > under net/, and as far as I can see, there's no reason for these three > files to #include pci.h . > net/ieee80211/ieee80211_module.c | 1 - > net/ieee80211/ieee80211_rx.c | 1 - > net/ieee80211/ieee80211_tx.c | 1 - I don't know where these came from since Host AP driver does not include linux/pci.h into the files doing generic IEEE 802.11 processing. Anyway, I have nothing against removing these include lines. -- Jouni Malinen PGP id EFC895FA From jmorris@redhat.com Mon May 30 21:17:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 30 May 2005 21:17:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4V4GxXq027813 for ; Mon, 30 May 2005 21:17:00 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4V4FwFK010699; Tue, 31 May 2005 00:15:58 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4V4FwO23204; Tue, 31 May 2005 00:15:58 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j4V4FlDj026450; Tue, 31 May 2005 00:15:52 -0400 Date: Tue, 31 May 2005 00:15:47 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: jaegert cc: netdev@oss.sgi.com, , , , Subject: Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks In-Reply-To: <1116361671.5560.125.camel@dyn9002018177.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1880 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 1391 Lines: 47 On Tue, 17 May 2005, jaegert wrote: Ok, my last review in this iteration. > @@ -984,6 +1029,13 @@ static struct xfrm_state * pfkey_msg2xfr > x->lft.soft_add_expires_seconds = lifetime->sadb_lifetime_addtime; > x->lft.soft_use_expires_seconds = lifetime->sadb_lifetime_usetime; > } > + > + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; > + if (sec_ctx != NULL) { > + if (security_xfrm_state_alloc(x, sec_ctx)) > + goto out; You should propagate the return value of security_xfrm_state_alloc() here by assigning it to err. > -selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o > +selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o nethooks.o What about making nethooks.o (or whatever it'll be called) conditionally compiled via CONFIG_SECURITY_NETWORK_XFRM ? (see netif.o) > + * ISSUES: > + * 1. Caching packets, so they are not dropped during negotiation This needs to be done for IPsec in general, not sure what the status is. > + * 2. Emulating a reasonable SO_PEERSEC across machines This may not be too difficult if we limit this to connected TCP sockets. > + * 3. Testing sk_policy setting with context What does this mean? Overall, this looks like a really good approach to the problem. - James -- James Morris From hadi@cyberus.ca Tue May 31 02:40:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 02:41:01 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4V9eoXq018275 for ; Tue, 31 May 2005 02:40:50 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Dd3E2-0002zx-8c for netdev@oss.sgi.com; Tue, 31 May 2005 03:39:54 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dd3E1-0007Rv-K4; Tue, 31 May 2005 05:39:53 -0400 Subject: Re: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050528161637.GT15391@postel.suug.ch> References: <20050527141320.GQ15391@postel.suug.ch> <1117206091.6383.73.camel@localhost.localdomain> <20050527151913.GA15391@postel.suug.ch> <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> <1117242749.6251.15.camel@localhost.localdomain> <20050528012810.GN15391@postel.suug.ch> <1117244893.6251.41.camel@localhost.localdomain> <20050528121827.GQ15391@postel.suug.ch> <1117296041.19563.6.camel@localhost.localdomain> <20050528161637.GT15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Tue, 31 May 2005 05:39:51 -0400 Message-Id: <1117532391.6134.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1881 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1616 Lines: 41 On Sat, 2005-28-05 at 18:16 +0200, Thomas Graf wrote: > * jamal <1117296041.19563.6.camel@localhost.localdomain> 2005-05-28 12:00 > > > I just tested both patches for about 30 minutes. Everything OK. Feel > > > free to apply the patches. > > > > We have another problem. What tree is this against? Both patches have > > failures patching against latest davem and linus git trees. > > It's against my davem-pending tree which should reflect the current > state of davem's tree so they _should_ apply on his side. In this > specific case you're probably missing the neighbour table patches. Now you really have to send some swiss chocolate over ;-> It still doesnt apply to Davems latest tree. > Basically I produce diffs this way: > > separate tree per patchset -> merge into testing tree -> > testing period -. merge into $person-pending -> extraction > of patches and submission. > Almost very close to what i do - which could be improved or you keep a few hundred trees. Jeff Garzik (some email to netdev with a HOWTO ) was talking about some new scheme where instead of trees you use branches of the same tree. I didnt quiet follow his trick. > I was trying to get some more quality control into my workflow, > so I started testing patches for 3-4 weeks to avoid fallouts > but apparently this is failing miserably at the moment due to > some broken scripts of mine. I think the problem in this case was you had already commited to that tree your changes that you sent to Dave. And the tree you were using as a base for generating the patch was only something you and Dave know about. cheers, jamal From hadi@cyberus.ca Tue May 31 03:05:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 03:05:18 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VA59Xq021446 for ; Tue, 31 May 2005 03:05:11 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Dd3bV-0003hr-9A for netdev@oss.sgi.com; Tue, 31 May 2005 04:04:09 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dd3bV-0001sN-6p; Tue, 31 May 2005 06:04:09 -0400 Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050528120731.GP15391@postel.suug.ch> References: <20050526185526.GZ15391@postel.suug.ch> <1117192464.6688.3.camel@localhost.localdomain> <20050527121503.GN15391@postel.suug.ch> <1117201853.6383.29.camel@localhost.localdomain> <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> <20050527163516.GB15391@postel.suug.ch> <1117244567.6251.34.camel@localhost.localdomain> <20050528120731.GP15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Tue, 31 May 2005 06:04:07 -0400 Message-Id: <1117533847.6134.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1883 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3797 Lines: 89 Doesnt seem like i responded to this. On Sat, 2005-28-05 at 14:07 +0200, Thomas Graf wrote: > * jamal <1117244567.6251.34.camel@localhost.localdomain> 2005-05-27 21:42 > > On Fri, 2005-27-05 at 18:35 +0200, Thomas Graf wrote: > > > > > I do NOT agree on moving gc_ into this architecture as well, > > > it doesn't belong there. > > > > Well, you do realize they are part of the in_dev ? ;-> > > Huh? They cannot be device specific, there is only one gc > per neighbour table. So even _iff_ there was a device specific > setting it wouldn't make much sense ;-> > I keep forgeting some of these tables are system wide. But i think it doesnt matter as long as we comply to the abstration thats in the kernel; in other words, config access is still via the in_devxx. i.e if you supply any ifindex (since all devices _at the moment_ point to the same ARP/ndisc table), it can be accessed and configured. > > I see a little main service header with ifindex always no different than > > IFA or IFLINK etc followed by appropriate TLVs which are nested. > > I guess we could simply move NDTPA_PARMS into the devconfig family. Probably a good start. This would still be missing the gc thresholds etc, no? > > Well, if you look at the structure there is no reason they should really > > be separate; infact theres a comment: > > ----------- > > struct neigh_parms parms; > > /* HACK. gc_* shoul follow parms without a gap! */ > > int gc_interval; > > int gc_thresh1; > > int gc_thresh2; > > ---------- > > You do realize the reason for that comment? ;-> The author of > the neighbour procfs code was simply too lazy to put these > into a separate place so he introduced a nasty hack. > I think you are correct. > What about this, we move the device specific part into the new devconfig > layer but leave the main configuration, statistics, and gc parameters > in RTM_NEIGHTBL? i.e. > > arp_cache entries 2 reachable-time 23s 993msec retransmit-time 1s > key-len 4 entry-size 152 last-flush 55m 44s 572msec > gc threshold 128/512/1024 interval 30s chain-position 3 > hash-rand 0x69650257/0x00000003 last-rand 1m 44s 571msec > ? refcnt 1 pending-queue-limit 3 proxy-delayed-queue-limit 64 > ? num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3 > ? min-age 1s base-reachable-time 30s stale-check-interval 1m > ? initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec > lookups 195 hits 190 failed 0 allocations 3 destroys 1 > hash-grows 1 forced-gc-runs 0 periodic-gc-runs 910 > rcv-unicast-probes 0 rcv-multicast-probes 0 > > Xarp_cache reachable-time 35s 967msec retransmit-time 1s > X refcnt 3 pending-queue-limit 3 proxy-delayed-queue-limit 64 > X num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3 > X min-age 1s base-reachable-time 30s stale-check-interval 1m > X initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec > > > Everything marked with X is clearly device specific so it will move. > Everything marked with '?' is the default parameter set, we can either > leave it or move it as well and put it under into a 'default' ifindex. > I don't care about the latter, either is fine with me. > All "stuffs" (your bases is mine) accessible via in_devxx abstraction should be devconfig configurable. I do concur that some of it may not make sense - but that should be the exception rules... Ok, lets say these tables are one such exception, but note: In the future there could be multiple ARP tables for example (very likely given all the virtualization approaches happening). In other words different devices may point to different tables... cheers, jamal From tgraf@suug.ch Tue May 31 04:43:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 04:43:33 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VBhTXq031279 for ; Tue, 31 May 2005 04:43:30 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id C94821C0EB; Tue, 31 May 2005 13:42:51 +0200 (CEST) Date: Tue, 31 May 2005 13:42:51 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050531114251.GC15391@postel.suug.ch> References: <20050527121503.GN15391@postel.suug.ch> <1117201853.6383.29.camel@localhost.localdomain> <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> <20050527163516.GB15391@postel.suug.ch> <1117244567.6251.34.camel@localhost.localdomain> <20050528120731.GP15391@postel.suug.ch> <1117533847.6134.32.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117533847.6134.32.camel@localhost.localdomain> X-archive-position: 1884 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4029 Lines: 70 * jamal <1117533847.6134.32.camel@localhost.localdomain> 2005-05-31 06:04 > Probably a good start. This would still be missing the gc thresholds > etc, no? Yes, this only includes the parts that I marked with 'X' and '?' below. > > What about this, we move the device specific part into the new devconfig > > layer but leave the main configuration, statistics, and gc parameters > > in RTM_NEIGHTBL? i.e. > > > > arp_cache entries 2 reachable-time 23s 993msec retransmit-time 1s > > key-len 4 entry-size 152 last-flush 55m 44s 572msec > > gc threshold 128/512/1024 interval 30s chain-position 3 > > hash-rand 0x69650257/0x00000003 last-rand 1m 44s 571msec > > ? refcnt 1 pending-queue-limit 3 proxy-delayed-queue-limit 64 > > ? num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3 > > ? min-age 1s base-reachable-time 30s stale-check-interval 1m > > ? initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec > > lookups 195 hits 190 failed 0 allocations 3 destroys 1 > > hash-grows 1 forced-gc-runs 0 periodic-gc-runs 910 > > rcv-unicast-probes 0 rcv-multicast-probes 0 > > > > Xarp_cache reachable-time 35s 967msec retransmit-time 1s > > X refcnt 3 pending-queue-limit 3 proxy-delayed-queue-limit 64 > > X num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3 > > X min-age 1s base-reachable-time 30s stale-check-interval 1m > > X initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec > > > > > > Everything marked with X is clearly device specific so it will move. > > Everything marked with '?' is the default parameter set, we can either > > leave it or move it as well and put it under into a 'default' ifindex. > > I don't care about the latter, either is fine with me. > > > > All "stuffs" (your bases is mine) accessible via in_devxx abstraction > should be devconfig configurable. I do concur that some of it may not > make sense - but that should be the exception rules... > Ok, lets say these tables are one such exception, but note: > In the future there could be multiple ARP tables for example (very > likely given all the virtualization approaches happening). In other > words different devices may point to different tables... Let's assume for a moment that there are no device specific parameters, just the default parameter set, e.g everything in the "arp_cache" block. According do your idea, everything would be part of a faked in_dev entry with ifindex==0 (or alike). We'd have the exact same issues as with RTM_NEIGHTBL, the requirement of unique table ids stays the same. There is one big difference though, what if we ever have neighbour tables which do not care about inet devices at all? Maybe some kind of new virtual devices for in-kernel communication? ;-> Sounds scary and not realistic, but my point is basically that neighbour tables itself have a global scope, the assignment to the device and device specific parameters is on the level of the neighbours itself. The connection to in_dev/... is one level higher with a scope of the relevant neighbour table. A neighbour table implementation is not required to support device specific parameters, the code neighbour code will always assign the default parameter set and leaves it up to the constructor of the implementation level to reassign a device specific parameter set. Which means that what the procfs and now also neightbl code does it kind of a hack anyway since the core neighbour code is not aware of device specific stuff anyway, all it does is provide an easy method to manage them in a efficient matter. I would like to stay consistent to this architecture if possible to be able to follow every new additions. I hope my point is now clear, I wasn't so sure until now ;-> However, I think you have a good point, parameter sets have a strong relation to inet devices at the moment. If you still think that we should move _everything_ into a devconfig layer then I'll do it but I still support my initial prospoal. From hadi@cyberus.ca Tue May 31 05:55:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 05:55:21 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VCtIXq004608 for ; Tue, 31 May 2005 05:55:18 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Dd6GJ-0003n2-0v for netdev@oss.sgi.com; Tue, 31 May 2005 08:54:27 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dd6Fk-0007Ez-1i; Tue, 31 May 2005 08:53:52 -0400 Subject: Re: [PATCH] use mmiowb in tg3_poll From: jamal Reply-To: hadi@cyberus.ca To: Arthur Kepner Cc: Lennert Buytenhek , netdev@oss.sgi.com, jesse.barnes@intel.com, gnb@sgi.com In-Reply-To: References: <200410211628.06906.jbarnes@engr.sgi.com> <20050528231209.GA8456@xi.wantstofly.org> Content-Type: text/plain Organization: unknown Date: Tue, 31 May 2005 08:53:42 -0400 Message-Id: <1117544022.6134.54.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1886 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 582 Lines: 21 On Mon, 2005-30-05 at 09:30 -0700, Arthur Kepner wrote: > I quickly looked through the records that I have and, unfortunately, > wasn't able to locate raw data. But I found some scrawlings in my > notes which say the most recent measurements for an Altix are: > > i) PIO read latency ~ 2.4 usec > ii) mmiowb() latency ~ 1.1 usec > In terms of CPU cycles, how many do the above compute to be? The absolute time numbers you have are also useful for quantification purposes. Did i read correctly that your reads are about 2x more expensive than the writes? cheers, jamal From hadi@cyberus.ca Tue May 31 05:49:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 05:49:36 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VCnVXq004022 for ; Tue, 31 May 2005 05:49:34 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Dd6Ai-0000BT-Ft for netdev@oss.sgi.com; Tue, 31 May 2005 08:48:40 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Dd6Ab-0006Ss-Gp; Tue, 31 May 2005 08:48:33 -0400 Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050531114251.GC15391@postel.suug.ch> References: <20050527121503.GN15391@postel.suug.ch> <1117201853.6383.29.camel@localhost.localdomain> <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> <20050527163516.GB15391@postel.suug.ch> <1117244567.6251.34.camel@localhost.localdomain> <20050528120731.GP15391@postel.suug.ch> <1117533847.6134.32.camel@localhost.localdomain> <20050531114251.GC15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Tue, 31 May 2005 08:48:30 -0400 Message-Id: <1117543711.6134.48.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1885 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3514 Lines: 67 On Tue, 2005-31-05 at 13:42 +0200, Thomas Graf wrote: > > All "stuffs" (your bases is mine) accessible via in_devxx abstraction > > should be devconfig configurable. I do concur that some of it may not > > make sense - but that should be the exception rules... > > Ok, lets say these tables are one such exception, but note: > > In the future there could be multiple ARP tables for example (very > > likely given all the virtualization approaches happening). In other > > words different devices may point to different tables... > > Let's assume for a moment that there are no device specific parameters, > just the default parameter set, e.g everything in the "arp_cache" block. > According do your idea, everything would be part of a faked in_dev entry > with ifindex==0 (or alike). We'd have the exact same issues as with > RTM_NEIGHTBL, the requirement of unique table ids stays the same. There > is one big difference though, what if we ever have neighbour tables which > do not care about inet devices at all? Maybe some kind of new virtual > devices for in-kernel communication? ;-> Sounds scary and not realistic, An extra virtual device just to store the defaults will be overkill. OTOH, a global allocated structure for defaults is ok. I think thats the way it is done today. > but my point is basically that neighbour tables itself have a global scope, > the assignment to the device and device specific parameters is on the > level of the neighbours itself. The connection to in_dev/... is one > level higher with a scope of the relevant neighbour table. A neighbour > table implementation is not required to support device specific > parameters, the code neighbour code will always assign the default > parameter set and leaves it up to the constructor of the implementation > level to reassign a device specific parameter set. Which means that what > the procfs and now also neightbl code does it kind of a hack anyway > since the core neighbour code is not aware of device specific stuff > anyway, all it does is provide an easy method to manage them in a > efficient matter. The neighbor code ought not be aware of devices; but whoever is configuring must be. By configuring i mean "stiching together" the different blocks (as in some netlink based program in user space). the idevxxx is a "stiching" construct - and therefore it may be aware of many other things that a standalone block doesnt. One could argue that the ifindex in a netdevice is also under the same class. The ARP, NDISC, netdevice, filters etc are the blocks being sown together. Most of the times these blocks are built together in a topology that a packet flows through. > I would like to stay consistent to this architecture > if possible to be able to follow every new additions. > > I hope my point is now clear, I wasn't so sure until now ;-> However, > I think you have a good point, parameter sets have a strong relation > to inet devices at the moment. If you still think that we should move > _everything_ into a devconfig layer then I'll do it but I still support > my initial prospoal. > I agree that we should leave the neighbor table-specific knobs out of devconfig. It will help, though, for devconfig to have a single reference to the "instance" of the table(perhaps a name or a even a 32 bit pointer address) that a device uses (thefore maintaining the abstraction); but since there is only one table for v4 and v6 anyways i suppose it is implicitly assumed to be that one table. cheers, jamal From tgraf@suug.ch Tue May 31 06:18:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 06:18:25 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VDIKXq006238 for ; Tue, 31 May 2005 06:18:21 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id D90031C0EB; Tue, 31 May 2005 15:17:47 +0200 (CEST) Date: Tue, 31 May 2005 15:17:47 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050531131747.GF15391@postel.suug.ch> References: <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> <20050527163516.GB15391@postel.suug.ch> <1117244567.6251.34.camel@localhost.localdomain> <20050528120731.GP15391@postel.suug.ch> <1117533847.6134.32.camel@localhost.localdomain> <20050531114251.GC15391@postel.suug.ch> <1117543711.6134.48.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117543711.6134.48.camel@localhost.localdomain> X-archive-position: 1887 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2333 Lines: 47 * jamal <1117543711.6134.48.camel@localhost.localdomain> 2005-05-31 08:48 > The neighbor code ought not be aware of devices; but whoever is > configuring must be. By configuring i mean "stiching together" the > different blocks (as in some netlink based program in user space). the > idevxxx is a "stiching" construct - and therefore it may be aware of > many other things that a standalone block doesnt. One could argue that > the ifindex in a netdevice is also under the same class. The ARP, NDISC, > netdevice, filters etc are the blocks being sown together. > Most of the times these blocks are built together in a topology that a > packet flows through. OK, so your idevxxx is a kind of container for various configurable blocks that logically belong to a inetdevice and a device specific parameter set for a neighbour table would one of these blocks? I think this is appropriate for NDTA_PARMS, e.g. there might be multiple of such neighbour table parameter blocks per inetdevice identified by the name of the neighbour table. You certainly have a good point there, I see two minor drawbacks though: a) where do we put these parameter blocks if it doesn't belong to a inetdevice? and b) it makes collecting the complete configuration of a neighbour table complicated. Nevertheless, I think I can agree on this. > I agree that we should leave the neighbor table-specific knobs out of > devconfig. OK, so we leave RTM_NEIGHTBL_* as-is but move the device specific parameter sets into devconfig? i.e. RTM_NEIGHTBL_* will cover: * the core neighbour table configuration (key-len, entry-size, last-flush, gc thresholds, gc interval, hash settings, etc.) * the default parameter set * neighbour table statistics > It will help, though, for devconfig to have a single reference to the > "instance" of the table(perhaps a name or a even a 32 bit pointer > address) that a device uses (thefore maintaining the abstraction); but > since there is only one table for v4 and v6 anyways i suppose it is > implicitly assumed to be that one table. This kind of breaks the architecture, i'd rather have it the other way around, i.e. we hold a netdevice reference in each parameter set and when lookup a parameter set for a specific idevxxx we iterate through all neighbour tables and their paremter sets and compare ifindex. From jbenc@suse.cz Tue May 31 06:31:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 06:31:49 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VDVjXq007624 for ; Tue, 31 May 2005 06:31:46 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id BD48162830C; Tue, 31 May 2005 15:30:50 +0200 (CEST) Date: Tue, 31 May 2005 15:30:50 +0200 From: Jiri Benc To: Jeff Garzik Cc: NetDev , jbohac@suse.cz Subject: Re: [2/5] ieee80211: ieee80211_device alignment fix and cleanup Message-ID: <20050531153050.139b1408@griffin.suse.cz> In-Reply-To: <4297E78A.4030906@pobox.com> References: <20050524150711.01632672@griffin.suse.cz> <20050524151117.5e059d1d@griffin.suse.cz> <4297E78A.4030906@pobox.com> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1888 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 2939 Lines: 69 On Fri, 27 May 2005 23:37:46 -0400, Jeff Garzik wrote: > 1) I am not convinced that the subclassing of net_device should be done > in this manner. Read drivers/net/wan/hdlc_generic.c and .../pc300_drv.c > for examples of how hdlc_device is handled. We see two differences to the hdlc concept: 1. the driver private data is allocated together with the net_device and ieee80211_device data; 2. ieee80211_device is passed to functions instead of net_device. Allocating all the structures together just extends the concept of net_device allocation. The advantage is that all the structures are located close to each other in the memory which (hopefully) improves cache performance. Passing ieee80211_device seems to be more appropriate in this case, since drivers will be accessing ieee80211 data far more frequently than net_device data. For example, part of the plan is to integrate Wireless Extensions into the ieee80211 layer -- for all the ioctl handlers, it will be much more interesting to have the ieee80211_device passed to them. Furthermore, driver writers will not be tempted to think that net_device->priv points to _their_ private data (which the name suggests, but is not true). Or did you mean something different? > 2) Please put all the new, protocol-layer functions > ieee80211_type_trans(), ieee80211_change_mtu(), ieee80211_header(), etc. > in their own file. Will be posted in the next patch series. > 3) Temporary or not, the following construct is simply not necessary. > Modify the definition rather than repeating this two-call piece of code > in multiple areas: > ieee80211_priv(netdev_priv(dev)); As soon as we're done integrating WE into ieee80211, most of this will disappear. But sure, we can add a ieee80211_priv_from_netdev (or so) macro for now. > 4) A low-level wireless hardware driver should look like other net > drivers, and use the existing driver API. The low level driver should > implement its own dev->hard_start_xmit(). > Certainly, the driver will make many calls to generic ieee80211_xxx > functions to get things done. Actually, hard_start_xmit has to do a lot of work regarding software fragmentation, encryption, sequence numbering, etc. Sure, every driver could call some ieee80211_prepare_to_xmit function in its own hard_start_xmit, but we see no point in doing this as it would have to be done by almost every driver. Drivers for very clever cards may probably be an exception, but the risk is, that if they implement part of the logic themselves, they will be more difficult to maintain as new features are implemented in the ieee80211 layer. Furthermore, it is against one of our premises ("the simpler card, the simpler driver"). We think that this concept of an "ieee80211 sublayer" has more advantages than the concept of an "ieee80211 library". Do you have any reasons why it should be the other way round? Jiri Benc & Jirka Bohac -- Jiri Benc SUSE Labs From hadi@znyx.com Tue May 31 08:00:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 08:00:27 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VF0LXq013629 for ; Tue, 31 May 2005 08:00:21 -0700 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005053108030047:4190 ; Tue, 31 May 2005 08:03:00 -0700 Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Thomas Graf Cc: netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <20050531131747.GF15391@postel.suug.ch> References: <20050527141023.GP15391@postel.suug.ch> <1117205822.6383.68.camel@localhost.localdomain> <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> <20050527163516.GB15391@postel.suug.ch> <1117244567.6251.34.camel@localhost.localdomain> <20050528120731.GP15391@postel.suug.ch> <1117533847.6134.32.camel@localhost.localdomain> <20050531114251.GC15391@postel.suug.ch> <1117543711.6134.48.camel@localhost.localdomain> <20050531131747.GF15391@postel.suug.ch> Organization: ZNYX Networks Date: Tue, 31 May 2005 10:59:21 -0400 Message-Id: <1117551561.6279.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/31/2005 08:03:00 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/31/2005 08:03:04 AM, Serialize complete at 05/31/2005 08:03:04 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 1889 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 3089 Lines: 86 On Tue, 2005-31-05 at 15:17 +0200, Thomas Graf wrote: > > OK, so your idevxxx is a kind of container for various configurable > blocks that logically belong to a inetdevice and a device specific > parameter set for a neighbour table would one of these blocks? > Essentialy just in_device and inet6_dev > I think this is appropriate for NDTA_PARMS, e.g. there might be > multiple of such neighbour table parameter blocks per inetdevice > identified by the name of the neighbour table. You certainly have > a good point there, I see two minor drawbacks though: a) where > do we put these parameter blocks if it doesn't belong to a > inetdevice? and b) it makes collecting the complete configuration > of a neighbour table complicated. Nevertheless, I think I can > agree on this. > To recap: netdevice -> L2 config stuff config stuff more config stuff even more config stuff .. .. netdevice protocol config: -> v4 specific (struct in_device) ----> IPV4 addresses (ifa_list), ARP params(arp_parms),etc -> v6 specific (struct inet6_dev) ----> IPV6 addresses(addr_list), ndisc params (nd_parms), etc I think we are agreeing _not_ to configure ifa_list, arp_parms etc via devconfig. Leave these to their already existing config paths. In the case of devconfig: What i am suggesting is to put some identifier that can be used to access lets say one or more arp_parms. This way when i dump the devconfig i should be able to see "connected to arp table 1". I should then be able to say dump arp table 1. If it is too complex an idea we can drop it. The defaults should stay as you say (and as they exist today) in the arp block. > > I agree that we should leave the neighbor table-specific knobs out of > > devconfig. > > OK, so we leave RTM_NEIGHTBL_* as-is but move the device specific > parameter sets into devconfig? i.e. RTM_NEIGHTBL_* will cover: > > * the core neighbour table configuration (key-len, entry-size, > last-flush, gc thresholds, gc interval, hash settings, etc.) > * the default parameter set > * neighbour table statistics > Sounds reasonable. And per device arp/ndisc is of course one of many configurable parameters via devconfig. > > > It will help, though, for devconfig to have a single reference to the > > "instance" of the table(perhaps a name or a even a 32 bit pointer > > address) that a device uses (thefore maintaining the abstraction); but > > since there is only one table for v4 and v6 anyways i suppose it is > > implicitly assumed to be that one table. > > This kind of breaks the architecture, i'd rather have it the other > way around, i.e. we hold a netdevice reference in each parameter set > and when lookup a parameter set for a specific idevxxx we iterate > through all neighbour tables and their paremter sets and compare > ifindex. The directionality as i see it is: netdevice --> arp/ndisc table(s) [And the binding/stiching of those tables is via inxx_devyy]. I dont have issues with arp pointing to netdevice as well, but I thought ARP/ndisc already have ifindex reference? cheers, jamal From grundler@cup.hp.com Tue May 31 08:36:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 08:37:02 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VFamXq019158 for ; Tue, 31 May 2005 08:36:55 -0700 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id 18C9E16B9; Tue, 31 May 2005 08:35:54 -0700 (PDT) Received: from localhost.localdomain (debian.cup.hp.com [15.244.57.47]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id IAA12138; Tue, 31 May 2005 08:30:07 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 1000) id 748BA8FC56; Tue, 31 May 2005 08:38:19 -0700 (PDT) Date: Tue, 31 May 2005 08:38:19 -0700 From: Grant Grundler To: Michael Chan Cc: "David S. Miller" , Peter Chubb , netdev@oss.sgi.com Subject: Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way) Message-ID: <20050531153819.GA20793@esmail.cup.hp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-archive-position: 1890 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: iod00d@hp.com Precedence: bulk X-list: netdev Content-Length: 3381 Lines: 80 On Wed, Dec 22, 2004 at 04:02:44PM -0800, Michael Chan wrote: > David, While the 2nd patch or something similar should be applied, I > think the underlying cause of tg3_readphy() returning error should be > further investigated. > > Peter, if you provide more information, such as registers MAC_MI_MODE > (0x454) and MAC_MI_COM (0x44c) after the failure, I can look into it. Michael, Peter bounced this email to me after we talked about issues he was having with the rx8620 (HP 16-way ia64, sx1000 chipset) "IOX Core LAN". It sounded like the same problem I tracked down with rx8620 IOX Core LAN in March. Here is the summary : | In May, 2004, tg3 v3.4 changed how MAC_LED_CTRL (0x40c) was getting | programmed and how to determine what to program into LED_CTRL. The new | code trusted NIC_SRAM_DATA_CFG (0x00000b58) to indicate what to write | to LED_CTRL and MII EXT_CTRL registers. On "IOX Core Lan", SRAM was | saying MODE_MAC (0x0) and that doesn't work. HP is working with broadcom to figure out how to update the firmware. Ben Malavazi is talking with Pratapa Reddy Vaka 'Johnny Ho' I'm not sure they are aware of the root cause. But they can probably provide you with the process to update the onboard firmware image should this come up again. b57diag is one way. HP also has an FCUPDATE tool that's a bit less dangerous/more user friendly. FCUPDATE needs a newer EFI driver to operate correctly so it's non-trivial to get started as well. I'm hoping one of the two can be scripted to auto update. I'm told rx5670 Core LAN firmware was the original image used by the rx8620 IOX Core LAN team and may also exhibit the same problem. I've not heard any trouble reports so far on rx5670 but please forward them to me if you do. Please do NOT apply the appended patch - it's just a temp workaround until the owners of the "IOX Core LAN" and Broadcom can get their act together. The patch appended below is for RHEL3u4 (tg3 v3.10RH) but should apply (with fuzz) to any tg3 v3.4 or later. The patch adds a "quirk" (bug workaround) to overide the SRAM value and use LED_CTRL_MODE_PHY_1 (0x00000800) instead. This results in LNK3_LED_MODE (0x2) getting written to MII_TG3_EXT_CTRL (0x10) for bcm5700/5701 chips. I do NOT understand why programming the MII_TG3_EXT_CTRL register differently will change how auto-negotiation works. hth, grant --- orig/drivers/net/tg3.c 2005-03-19 21:39:25.000000000 -0600 +++ ggg/drivers/net/tg3.c 2005-03-20 13:17:50.000000000 -0600 @@ -7090,9 +7089,20 @@ static int __devinit tg3_phy_probe(struc }; if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) && - tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL) - tp->led_ctrl = LED_CTRL_MODE_PHY_2; + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701)) { + /* Quirks: firmware is wrong */ + switch (tp->pdev->subsystem_vendor) { + case PCI_VENDOR_ID_DELL: + tp->led_ctrl = LED_CTRL_MODE_PHY_2; + break; + + case PCI_VENDOR_ID_HP: + /* HP IOX Core Lan 1000Base-T [A7109AX] */ + if (tp->pdev->subsystem_device == 0x12c1) + tp->led_ctrl = LED_CTRL_MODE_PHY_1; + break; + } + } if (((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703) || (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) || From tgraf@suug.ch Tue May 31 09:13:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 09:13:51 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VGDlXq021866 for ; Tue, 31 May 2005 09:13:48 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 22A731C0EB; Tue, 31 May 2005 18:13:15 +0200 (CEST) Date: Tue, 31 May 2005 18:13:15 +0200 From: Thomas Graf To: Jamal Hadi Salim Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Message-ID: <20050531161315.GH15391@postel.suug.ch> References: <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> <20050527163516.GB15391@postel.suug.ch> <1117244567.6251.34.camel@localhost.localdomain> <20050528120731.GP15391@postel.suug.ch> <1117533847.6134.32.camel@localhost.localdomain> <20050531114251.GC15391@postel.suug.ch> <1117543711.6134.48.camel@localhost.localdomain> <20050531131747.GF15391@postel.suug.ch> <1117551561.6279.2.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117551561.6279.2.camel@localhost.localdomain> X-archive-position: 1891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2642 Lines: 70 * Jamal Hadi Salim <1117551561.6279.2.camel@localhost.localdomain> 2005-05-31 10:59 > netdevice -> > L2 config stuff > config stuff > more config stuff > even more config stuff > .. > .. > netdevice protocol config: > -> v4 specific (struct in_device) > ----> IPV4 addresses (ifa_list), ARP params(arp_parms),etc > -> v6 specific (struct inet6_dev) > ----> IPV6 addresses(addr_list), ndisc params (nd_parms), etc Absolutely. > I think we are agreeing _not_ to configure ifa_list, arp_parms etc > via devconfig. Leave these to their already existing config paths. arp_parms is just a reference to the corresponding device specific parameter set of the "arp_cache" neighbour table. Maybe I've been misunderstanding you throughout all your posts or maybe I've a wrong understanding of the neighbour code in general. As far as I understand it: 1) The actual neighbour implementation registers a new neighbour table by calling neigh_table_init() with the proposed default configuration for this table. This also includes the default parameter set used to derive device specific parameter sets later on, e.g. arp_tbl. 2) Upon the creation of a inet_device/... a new parameter set is allocated that derives the initial parameter values from the default parameter set. This parameter set is stored in in_dev->arp_parms and linked in a list of parameter sets in the neighbour table (neightbl->parms). 3) When a new neighbour is created the core neighbour code will assign the default parameter set of the table to the neighbour and increments its refcnt. It then calls the constructor of arp,ndisc,... which replaces the parameter set just assigned with the one in in_dev->arp_parms which is the parameter set. So what I propose is to have the neighbour table parameters, e.g. everything in arp_tbl be distributed over RTM_NEIGHTBL and put the device specific parameters into devconfig, e.g. in_dev->arp_parms. > In the case of devconfig: > What i am suggesting is to put some identifier that can be used > to access lets say one or more arp_parms. This way when i dump > the devconfig i should be able to see "connected to arp table 1". > I should then be able to say dump arp table 1. OK, this is possible with either way. I don't worry about this. > The directionality as i see it is: > > netdevice --> arp/ndisc table(s) > [And the binding/stiching of those tables is via inxx_devyy]. Absolutely, more specific: netdevice -> inet_device -> parameter set -> neighbour table or: neighbour table -> list of parameter sets -> netdevice both ways are possible right now. From satkinson@motorola.com Tue May 31 09:39:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 09:39:22 -0700 (PDT) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VGdFXq023547 for ; Tue, 31 May 2005 09:39:16 -0700 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j4VGkMP7021949 for ; Tue, 31 May 2005 09:46:22 -0700 (MST) Received: from il06exm11.corp.mot.com (il06exm11.corp.mot.com [10.0.111.11]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j4VGgQfs022416 for ; Tue, 31 May 2005 11:42:26 -0500 (CDT) Received: by il06exm11 with Internet Mail Service (5.5.2657.72) id ; Tue, 31 May 2005 11:38:18 -0500 Message-ID: <5D454811D0A1D711A12A00065BF36FAD1A0E93A4@il06exm11> From: Atkinson Stephen-G19998 To: netdev@oss.sgi.com Subject: Patch for "ETH_P_ALL_NO_NIT" Date: Tue, 31 May 2005 11:38:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-archive-position: 1892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: satkinson@motorola.com Precedence: bulk X-list: netdev Content-Length: 2442 Lines: 68 I would like to be able to receive all packets (regardless of type) on a given net_device. One way to do this would be to use ETH_P_ALL however, ETH_P_ALL has two meanings, 1) receive all packets and 2) behave as a "NIT" (Network Interface Tap?). The NIT functionality causes packets transmitted on the net_device in question to be "received" by an ETH_P_ALL socket, unless the packet was sent by that socket. So, I'd like to propose a new ethernet type (ETH_P_ALL_NO_NIT) which would behave like ETH_P_ALL without the side effects of NIT. I've included a patch for ETH_P_ALL_NO_NIT below. Comments? Signed-off-by: Steve Atkinson --- linux-2.6.9_orig/include/linux/if_ether.h 2004-10-18 17:54:37.000000000 -0400 +++ linux-2.6.9/include/linux/if_ether.h 2005-05-31 10:32:50.000000000 -0400 @@ -91,6 +91,7 @@ #define ETH_P_IRDA 0x0017 /* Linux-IrDA */ #define ETH_P_ECONET 0x0018 /* Acorn Econet */ #define ETH_P_HDLC 0x0019 /* HDLC frames */ +#define ETH_P_ALL_NO_NIT 0x0020 /* Every packet but DON'T ENABLE netdev_nit */ /* * This is an Ethernet frame header. --- linux-2.6.9_orig/net/core/dev.c 2004-10-18 17:54:08.000000000 -0400 +++ linux-2.6.9/net/core/dev.c 2005-05-31 10:56:50.000000000 -0400 @@ -276,7 +276,10 @@ if (pt->type == htons(ETH_P_ALL)) { netdev_nit++; list_add_rcu(&pt->list, &ptype_all); - } else { + } else if(pt->type == htons(ETH_P_ALL_NO_NIT)) { + list_add_rcu(&pt->list, &ptype_all); + } + else { hash = ntohs(pt->type) & 15; list_add_rcu(&pt->list, &ptype_base[hash]); } @@ -310,9 +313,11 @@ if (pt->type == htons(ETH_P_ALL)) { netdev_nit--; head = &ptype_all; - } else + } else if (pt->type == htons(ETH_P_ALL_NO_NIT)) { + head = &ptype_all; + } else { head = &ptype_base[ntohs(pt->type) & 15]; - + } list_for_each_entry(pt1, head, list) { if (pt == pt1) { list_del_rcu(&pt->list); @@ -1072,9 +1077,10 @@ /* Never send packets back to the socket * they originated from - MvS (miquels@drinkel.ow.org) */ - if ((ptype->dev == dev || !ptype->dev) && - (ptype->af_packet_priv == NULL || - (struct sock *)ptype->af_packet_priv != skb->sk)) { + if ( (ptype->type != ETH_P_ALL_NO_NIT) && + (ptype->dev == dev || !ptype->dev) && + (ptype->af_packet_priv == NULL || + (struct sock *)ptype->af_packet_priv != skb->sk)) { struct sk_buff *skb2= skb_clone(skb, GFP_ATOMIC); if (!skb2) break; From jesse.barnes@intel.com Tue May 31 09:47:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 09:47:27 -0700 (PDT) Received: from scsfmr001.sc.intel.com (fmr21.intel.com [143.183.121.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VGlOXq024450 for ; Tue, 31 May 2005 09:47:24 -0700 Received: from scsfmr101.sc.intel.com (scsfmr101.sc.intel.com [10.3.253.10]) by scsfmr001.sc.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4VGjqgO023587; Tue, 31 May 2005 16:45:52 GMT Received: from [143.183.136.154] ([143.183.136.154]) by scsfmr101.sc.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j4VGdu56010913; Tue, 31 May 2005 16:39:56 GMT From: Jesse Barnes To: hadi@cyberus.ca Subject: Re: [PATCH] use mmiowb in tg3_poll Date: Tue, 31 May 2005 09:45:36 -0700 User-Agent: KMail/1.8 Cc: Arthur Kepner , Lennert Buytenhek , netdev@oss.sgi.com, gnb@sgi.com References: <200410211628.06906.jbarnes@engr.sgi.com> <1117544022.6134.54.camel@localhost.localdomain> In-Reply-To: <1117544022.6134.54.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505310945.36903.jesse.barnes@intel.com> X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse.barnes@intel.com Precedence: bulk X-list: netdev Content-Length: 565 Lines: 13 On Tuesday, May 31, 2005 5:53 am, jamal wrote: > Did i read correctly that your reads are about 2x more expensive than > the writes? The test above just measures the difference between using a full PIO read to ensure write ordering vs. the lighter weight mmiowb call. As for your question though, non-relaxed reads are very expensive on the Altix platform due to its highly distributed NUMA I/O architecture. The _relaxed variants can be quite fast however, and can be used anytime a PIO read doesn't imply anything about previous DMA transactions. Jesse From mitch.a.williams@intel.com Tue May 31 10:37:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 10:37:11 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VHb8Xq027347 for ; Tue, 31 May 2005 10:37:08 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4VHZR08029306; Tue, 31 May 2005 17:35:27 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j4VHZRQq016274; Tue, 31 May 2005 17:35:27 GMT Received: from mawilli1-desk2.amr.corp.intel.com (mawilli1-desk2.amr.corp.intel.com [134.134.3.124]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j4VHZQSL028641; Tue, 31 May 2005 10:35:26 -0700 Date: Tue, 31 May 2005 10:35:26 -0700 From: Mitch Williams X-X-Sender: mawilli1@mawilli1-desk2.amr.corp.intel.com To: jamal cc: Stephen Hemminger , "Williams, Mitch A" , netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Ronciak, John" , "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: Re: RFC: NAPI packet weighting patch In-Reply-To: <1117241786.6251.7.camel@localhost.localdomain> Message-ID: References: <20050527085055.79da3d75@dxpl.pdx.osdl.net> <20050527140132.1435132d@dxpl.pdx.osdl.net> <1117241786.6251.7.camel@localhost.localdomain> ReplyTo: "Mitch Williams" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1894 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch.a.williams@intel.com Precedence: bulk X-list: netdev Content-Length: 633 Lines: 26 On Fri, 27 May 2005, jamal wrote: > > On Fri, 2005-27-05 at 14:01 -0700, Stephen Hemminger wrote: > > > > > Why not just allow adjusting dev->weight via sysfs? > > I think that should be good enough - and i thought your patch already > did this. > Adding a shift to the weight in a _weighted_ RR algorithm does sound > odd. > Stephen's patch only affects the weight for the backlog device. Exporting dev-> weight to sysfs will allow the weight to be set for any network device. Which makes perfect sense. I'll work on getting this done and verifying performance this week. Expect a patch in a few days. Thanks, guys. -Mitch From shemminger@osdl.org Tue May 31 10:41:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 10:41:44 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VHffXq027966 for ; Tue, 31 May 2005 10:41:41 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4VHeBjA018932 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 31 May 2005 10:40:12 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4VHeB29030265; Tue, 31 May 2005 10:40:11 -0700 Date: Tue, 31 May 2005 10:40:11 -0700 From: Stephen Hemminger To: Mitch Williams Cc: jamal , "Williams, Mitch A" , netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Ronciak, John" , "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: Re: RFC: NAPI packet weighting patch Message-ID: <20050531104011.654ad281@dxpl.pdx.osdl.net> In-Reply-To: References: <20050527085055.79da3d75@dxpl.pdx.osdl.net> <20050527140132.1435132d@dxpl.pdx.osdl.net> <1117241786.6251.7.camel@localhost.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1895 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1140 Lines: 37 Like this (untested) patch: Index: napi-sysfs/net/core/net-sysfs.c =================================================================== --- napi-sysfs.orig/net/core/net-sysfs.c +++ napi-sysfs/net/core/net-sysfs.c @@ -184,6 +184,22 @@ static ssize_t store_tx_queue_len(struct static CLASS_DEVICE_ATTR(tx_queue_len, S_IRUGO | S_IWUSR, show_tx_queue_len, store_tx_queue_len); +NETDEVICE_SHOW(weight, fmt_ulong); + +static int change_weight(struct net_device *net, unsigned long new_weight) +{ + net->weight = new_weight; + return 0; +} + +static ssize_t store_weight(struct class_device *dev, const char *buf, size_t len) +{ + return netdev_store(dev, buf, len, change_weight); +} + +static CLASS_DEVICE_ATTR(weight, S_IRUGO | S_IWUSR, show_weight, + store_weight); + static struct class_device_attribute *net_class_attributes[] = { &class_device_attr_ifindex, @@ -193,6 +209,7 @@ static struct class_device_attribute *ne &class_device_attr_features, &class_device_attr_mtu, &class_device_attr_flags, + &class_device_attr_weight, &class_device_attr_type, &class_device_attr_address, &class_device_attr_broadcast, From mitch.a.williams@intel.com Tue May 31 10:45:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 10:45:14 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VHjAXq028640 for ; Tue, 31 May 2005 10:45:11 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4VHhWNU000955; Tue, 31 May 2005 17:43:32 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j4VHhWQq021487; Tue, 31 May 2005 17:43:32 GMT Received: from mawilli1-desk2.amr.corp.intel.com (mawilli1-desk2.amr.corp.intel.com [134.134.3.124]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j4VHhWSL029229; Tue, 31 May 2005 10:43:32 -0700 Date: Tue, 31 May 2005 10:43:32 -0700 From: Mitch Williams X-X-Sender: mawilli1@mawilli1-desk2.amr.corp.intel.com To: Stephen Hemminger cc: "Williams, Mitch A" , jamal , netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Ronciak, John" , "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: Re: RFC: NAPI packet weighting patch In-Reply-To: <20050531104011.654ad281@dxpl.pdx.osdl.net> Message-ID: References: <20050527085055.79da3d75@dxpl.pdx.osdl.net><20050527140132.1435132d@dxpl.pdx.osdl.net><1117241786.6251.7.camel@localhost.localdomain> <20050531104011.654ad281@dxpl.pdx.osdl.net> ReplyTo: "Mitch Williams" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-archive-position: 1896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch.a.williams@intel.com Precedence: bulk X-list: netdev Content-Length: 201 Lines: 12 On Tue, 31 May 2005, Stephen Hemminger wrote: > > Like this (untested) patch: > Gosh, you're making my life too easy. Thanks! I'll apply this, give it a spin, and let you know what I see. -Mitch From shemminger@osdl.org Tue May 31 11:00:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 11:00:42 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VI0cXq029874 for ; Tue, 31 May 2005 11:00:39 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4VHxdjA020418 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 31 May 2005 10:59:40 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4VHxdVr031266; Tue, 31 May 2005 10:59:39 -0700 Date: Tue, 31 May 2005 10:59:39 -0700 From: Stephen Hemminger To: Andy Fleming Cc: Netdev , Embedded PPC Linux list , Kumar Gala Subject: Re: RFC: PHY Abstraction Layer II Message-ID: <20050531105939.7486e071@dxpl.pdx.osdl.net> In-Reply-To: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 12673 Lines: 476 Here are some patches: * allow phy's to be modules * use driver owner for ref count * make local functions static where ever possible * get rid of bus read may sleep implication in comment. since you are holding phy spin lock it better not!! Untested since I don't have sungem, but am thinking about this for skge driver. Index: skge-phy/drivers/net/phy/davicom.c =================================================================== --- skge-phy.orig/drivers/net/phy/davicom.c +++ skge-phy/drivers/net/phy/davicom.c @@ -60,13 +60,17 @@ #define MII_DM9161_10BTCSR 0x12 #define MII_DM9161_10BTCSR_INIT 0x7800 +MODULE_DESCRIPTION("Davicom PHY driver"); +MODULE_AUTHOR("Andy Fleming"); +MODULE_LICENSE("GPL"); + struct dm9161_private { struct timer_list timer; int resetdone; }; #define DM9161_DELAY 1 -int dm9161_config_intr(struct phy_device *phydev) +static int dm9161_config_intr(struct phy_device *phydev) { int temp; @@ -226,6 +230,7 @@ static struct phy_driver dm9161_driver = .config_aneg = dm9161_config_aneg, .read_status = genphy_read_status, .remove = dm9161_remove, + .driver = { .owner = THIS_MODULE,}, }; static struct phy_driver dm9131_driver = { @@ -238,38 +243,33 @@ static struct phy_driver dm9131_driver = .read_status = genphy_read_status, .ack_interrupt = dm9161_ack_interrupt, .config_intr = dm9161_config_intr, + .driver = { .owner = THIS_MODULE,}, }; -int __init dm9161_init(void) +static int __init davicom_init(void) { - int retval; + int ret; - retval = phy_driver_register(&dm9161_driver); + ret = phy_driver_register(&dm9161_driver); + if (ret) + goto err1; - return retval; -} + ret = phy_driver_register(&dm9131_driver); + if (ret) + goto err2; + return 0; -static void __exit dm9161_exit(void) -{ + err2: phy_driver_unregister(&dm9161_driver); + err1: + return ret; } -module_init(dm9161_init); -module_exit(dm9161_exit); - -int __init dm9131_init(void) -{ - int retval; - - retval = phy_driver_register(&dm9131_driver); - - return retval; -} - -static void __exit dm9131_exit(void) +static void __exit davicom_exit(void) { + phy_driver_unregister(&dm9161_driver); phy_driver_unregister(&dm9131_driver); } -module_init(dm9131_init); -module_exit(dm9131_exit); +module_init(davicom_init); +module_exit(davicom_exit); Index: skge-phy/drivers/net/phy/marvell.c =================================================================== --- skge-phy.orig/drivers/net/phy/marvell.c +++ skge-phy/drivers/net/phy/marvell.c @@ -45,6 +45,10 @@ #define MII_M1011_IMASK_INIT 0x6400 #define MII_M1011_IMASK_CLEAR 0x0000 +MODULE_DESCRIPTION("Marvell PHY driver"); +MODULE_AUTHOR("Andy Fleming"); +MODULE_LICENSE("GPL"); + static int marvell_ack_interrupt(struct phy_device *phydev) { int err; @@ -119,15 +123,12 @@ static struct phy_driver m88e1101_driver .read_status = &genphy_read_status, .ack_interrupt = &marvell_ack_interrupt, .config_intr = &marvell_config_intr, + .driver = { .owner = THIS_MODULE,}, }; -int __init marvell_init(void) +static int __init marvell_init(void) { - int retval; - - retval = phy_driver_register(&m88e1101_driver); - - return retval; + return phy_driver_register(&m88e1101_driver); } static void __exit marvell_exit(void) Index: skge-phy/drivers/net/phy/lxt.c =================================================================== --- skge-phy.orig/drivers/net/phy/lxt.c +++ skge-phy/drivers/net/phy/lxt.c @@ -58,6 +58,10 @@ #define MII_LXT971_ISR 19 /* Interrupt Status Register */ +MODULE_DESCRIPTION("Intel LXT PHY driver"); +MODULE_AUTHOR("Andy Fleming"); +MODULE_LICENSE("GPL"); + static int lxt970_ack_interrupt(struct phy_device *phydev) { int err; @@ -130,6 +134,7 @@ static struct phy_driver lxt970_driver = .read_status = genphy_read_status, .ack_interrupt = lxt970_ack_interrupt, .config_intr = lxt970_config_intr, + .driver = { .owner = THIS_MODULE,}, }; static struct phy_driver lxt971_driver = { @@ -142,38 +147,33 @@ static struct phy_driver lxt971_driver = .read_status = genphy_read_status, .ack_interrupt = lxt971_ack_interrupt, .config_intr = lxt971_config_intr, + .driver = { .owner = THIS_MODULE,}, }; -int __init lxt970_init(void) +static int __init lxt_init(void) { - int retval; + int ret; - retval = phy_driver_register(&lxt970_driver); + ret = phy_driver_register(&lxt970_driver); + if (ret) + goto err1; - return retval; -} + ret = phy_driver_register(&lxt971_driver); + if (ret) + goto err2; + return 0; -static void __exit lxt970_exit(void) -{ + err2: phy_driver_unregister(&lxt970_driver); + err1: + return ret; } -module_init(lxt970_init); -module_exit(lxt970_exit); - -int __init lxt971_init(void) -{ - int retval; - - retval = phy_driver_register(&lxt971_driver); - - return retval; -} - -static void __exit lxt971_exit(void) +static void __exit lxt_exit(void) { + phy_driver_unregister(&lxt970_driver); phy_driver_unregister(&lxt971_driver); } -module_init(lxt971_init); -module_exit(lxt971_exit); +module_init(lxt_init); +module_exit(lxt_exit); Index: skge-phy/drivers/net/phy/qsemi.c =================================================================== --- skge-phy.orig/drivers/net/phy/qsemi.c +++ skge-phy/drivers/net/phy/qsemi.c @@ -59,9 +59,12 @@ #define QS6612_PCR_MLT3_DIS 0x0002 #define QS6612_PCR_SCRM_DESCRM 0x0001 +MODULE_DESCRIPTION("Quality Semiconductor PHY driver"); +MODULE_AUTHOR("Andy Fleming"); +MODULE_LICENSE("GPL"); /* Returns 0, unless there's a write error */ -int qs6612_probe(struct phy_device *phydev) +static int qs6612_probe(struct phy_device *phydev) { /* The PHY powers up isolated on the RPX, * so send a command to allow operation. @@ -77,7 +80,7 @@ int qs6612_probe(struct phy_device *phyd return phy_write(phydev, MII_QS6612_PCR, 0x0dc0); } -int qs6612_ack_interrupt(struct phy_device *phydev) +static int qs6612_ack_interrupt(struct phy_device *phydev) { int err; @@ -99,7 +102,7 @@ int qs6612_ack_interrupt(struct phy_devi return 0; } -int qs6612_config_intr(struct phy_device *phydev) +static int qs6612_config_intr(struct phy_device *phydev) { int err; if (phydev->interrupts == PHY_INTERRUPT_ENABLED) @@ -123,15 +126,12 @@ static struct phy_driver qs6612_driver = .read_status = genphy_read_status, .ack_interrupt = qs6612_ack_interrupt, .config_intr = qs6612_config_intr, + .driver = { .owner = THIS_MODULE,}, }; -int __init qs6612_init(void) +static int __init qs6612_init(void) { - int retval; - - retval = phy_driver_register(&qs6612_driver); - - return retval; + return phy_driver_register(&qs6612_driver); } static void __exit qs6612_exit(void) Index: skge-phy/drivers/net/phy/phy_device.c =================================================================== --- skge-phy.orig/drivers/net/phy/phy_device.c +++ skge-phy/drivers/net/phy/phy_device.c @@ -370,7 +370,7 @@ int genphy_config_advert(struct phy_devi return adv; } - +EXPORT_SYMBOL(genphy_config_advert); /* genphy_setup_forced * @@ -443,7 +443,7 @@ int genphy_config_aneg(struct phy_device return err; } - +EXPORT_SYMBOL(genphy_config_aneg); /* genphy_update_link * @@ -567,7 +567,7 @@ int genphy_read_status(struct phy_device return 0; } - +EXPORT_SYMBOL(genphy_read_status); static int genphy_probe(struct phy_device *phydev) { @@ -624,7 +624,7 @@ static int genphy_probe(struct phy_devic * set the state to READY (the driver's probe function should * set it to STARTING if needed). */ -int phy_probe(struct device *dev) +static int phy_probe(struct device *dev) { struct phy_device *phydev; struct phy_driver *phydrv; @@ -662,7 +662,7 @@ int phy_probe(struct device *dev) return err; } -int phy_remove(struct device *dev) +static int phy_remove(struct device *dev) { struct phy_device *phydev; @@ -701,13 +701,15 @@ int phy_driver_register(struct phy_drive return retval; } +EXPORT_SYMBOL(phy_driver_register); void phy_driver_unregister(struct phy_driver *drv) { driver_unregister(&drv->driver); } +EXPORT_SYMBOL(phy_driver_unregister); -struct phy_driver genphy_driver = { +static struct phy_driver genphy_driver = { .phy_id = 0xffffffff, .phy_id_mask = 0xffffffff, .name = "Generic PHY", @@ -715,15 +717,13 @@ struct phy_driver genphy_driver = { .features = 0, .config_aneg = genphy_config_aneg, .read_status = genphy_read_status, + .driver = {.owner = THIS_MODULE, }, }; static int __init genphy_init(void) { - int retval; - - retval = phy_driver_register(&genphy_driver); + return phy_driver_register(&genphy_driver); - return retval; } static void __exit genphy_exit(void) Index: skge-phy/drivers/net/phy/mdio_bus.c =================================================================== --- skge-phy.orig/drivers/net/phy/mdio_bus.c +++ skge-phy/drivers/net/phy/mdio_bus.c @@ -124,7 +124,7 @@ EXPORT_SYMBOL(unregister_mdiobus); * description: Given a PHY device, and a PHY driver, return 1 if * the driver supports the device. Otherwise, return 0 */ -int mdio_bus_match(struct device *dev, struct device_driver *drv) +static int mdio_bus_match(struct device *dev, struct device_driver *drv) { struct phy_device *phydev = to_phy_device(dev); struct phy_driver *phydrv = to_phy_driver(drv); @@ -170,7 +170,7 @@ struct bus_type mdio_bus_type = { .resume = mdio_bus_resume, }; -int __init mdio_bus_init(void) +static int __init mdio_bus_init(void) { return bus_register(&mdio_bus_type); } Index: skge-phy/drivers/net/phy/cicada.c =================================================================== --- skge-phy.orig/drivers/net/phy/cicada.c +++ skge-phy/drivers/net/phy/cicada.c @@ -65,6 +65,9 @@ #define MII_CIS8201_AUXCONSTAT_GBIT 0x0010 #define MII_CIS8201_AUXCONSTAT_100 0x0008 +MODULE_DESCRIPTION("Cicadia PHY driver"); +MODULE_AUTHOR("Andy Fleming"); +MODULE_LICENSE("GPL"); static int cis820x_probe(struct phy_device *phydev) { @@ -104,9 +107,9 @@ static int cis820x_config_intr(struct ph /* Cicada 820x */ static struct phy_driver cis8204_driver = { - 0x000fc440, - "Cicada Cis8204", - 0x000fffc0, + .phy_id = 0x000fc440, + .name = "Cicada Cis8204", + .phy_id_mask = 0x000fffc0, .features = PHY_GBIT_FEATURES, .flags = PHY_HAS_INTERRUPT, .probe = &cis820x_probe, @@ -114,15 +117,12 @@ static struct phy_driver cis8204_driver .read_status = &genphy_read_status, .ack_interrupt = &cis820x_ack_interrupt, .config_intr = &cis820x_config_intr, + .driver = { .owner = THIS_MODULE,}, }; -int __init cis8204_init(void) +static int __init cis8204_init(void) { - int retval; - - retval = phy_driver_register(&cis8204_driver); - - return retval; + return phy_driver_register(&cis8204_driver); } static void __exit cis8204_exit(void) Index: skge-phy/drivers/net/phy/phy.c =================================================================== --- skge-phy.orig/drivers/net/phy/phy.c +++ skge-phy/drivers/net/phy/phy.c @@ -42,10 +42,7 @@ int phy_read(struct phy_device *phydev, u16 regnum); int phy_write(struct phy_device *phydev, u16 regnum, u16 val); -/* Convenience functions for reading a given PHY register. - * This MUST NOT be called from interrupt context, - * because the bus read function may sleep - * or generally lock up. */ +/* Convenience functions for reading a given PHY register. */ int phy_read(struct phy_device *phydev, u16 regnum) { int retval; @@ -57,6 +54,7 @@ int phy_read(struct phy_device *phydev, return retval; } +EXPORT_SYMBOL(phy_read); int phy_write(struct phy_device *phydev, u16 regnum, u16 val) { @@ -69,6 +67,7 @@ int phy_write(struct phy_device *phydev, return err; } +EXPORT_SYMBOL(phy_write); int phy_clear_interrupt(struct phy_device *phydev) @@ -236,7 +235,7 @@ static inline int phy_find_valid(int idx * duplexes. Drop down by one in this order: 1000/FULL, * 1000/HALF, 100/FULL, 100/HALF, 10/FULL, 10/HALF */ -void phy_sanitize_settings(struct phy_device *phydev) +static void phy_sanitize_settings(struct phy_device *phydev) { u32 features = phydev->supported; int idx; @@ -260,7 +259,7 @@ void phy_sanitize_settings(struct phy_de * 1000/FULL, 1000/HALF, 100/FULL, 100/HALF, * 10/FULL, 10/HALF. The function bottoms out at 10/HALF. */ -void phy_force_reduction(struct phy_device *phydev) +static void phy_force_reduction(struct phy_device *phydev) { int idx; @@ -323,7 +322,7 @@ static irqreturn_t phy_interrupt(int irq * Otherwise, we enable the interrupts in the PHY. * Returns 0 on success. */ -int phy_start_interrupts(struct phy_device *phydev) +static int phy_start_interrupts(struct phy_device *phydev) { int err = 0; From mchan@broadcom.com Tue May 31 11:21:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 11:21:47 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VILhXq031274 for ; Tue, 31 May 2005 11:21:43 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 31 May 2005 11:20:16 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 31 May 2005 11:20:14 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BBI09502; Tue, 31 May 2005 11:20:12 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA07111; Tue, 31 May 2005 11:20:12 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 May 2005 18:20:12 +0000 Received: from rh4 by nt-irva-0741; 31 May 2005 10:22:37 -0700 Subject: Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way) From: "Michael Chan" To: "Grant Grundler" cc: "David S. Miller" , "Peter Chubb" , netdev@oss.sgi.com In-Reply-To: <20050531153819.GA20793@esmail.cup.hp.com> References: <20050531153819.GA20793@esmail.cup.hp.com> Date: Tue, 31 May 2005 10:22:37 -0700 Message-ID: <1117560157.4310.16.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E82756A2U44250710-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1898 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 745 Lines: 17 On Tue, 2005-05-31 at 08:38 -0700, Grant Grundler wrote: > Michael, > Peter bounced this email to me after we talked about issues he was > having with the rx8620 (HP 16-way ia64, sx1000 chipset) "IOX Core LAN". > It sounded like the same problem I tracked down with rx8620 IOX Core LAN > in March. Here is the summary : > > | In May, 2004, tg3 v3.4 changed how MAC_LED_CTRL (0x40c) was getting > | programmed and how to determine what to program into LED_CTRL. The new > | code trusted NIC_SRAM_DATA_CFG (0x00000b58) to indicate what to write > | to LED_CTRL and MII EXT_CTRL registers. On "IOX Core Lan", SRAM was > | saying MODE_MAC (0x0) and that doesn't work. > Thanks Grant, I'll chase this down and find a solution to this problem. From mchan@broadcom.com Tue May 31 11:41:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 11:41:47 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VIfiXq032314 for ; Tue, 31 May 2005 11:41:45 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 31 May 2005 11:40:22 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 31 May 2005 11:40:20 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BBI14846; Tue, 31 May 2005 11:40:20 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA13672; Tue, 31 May 2005 11:40:20 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 May 2005 18:40:20 +0000 Received: from rh4 by nt-irva-0741; 31 May 2005 10:42:45 -0700 Subject: Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way) From: "Michael Chan" To: "Grant Grundler" cc: "David S. Miller" , "Peter Chubb" , netdev@oss.sgi.com In-Reply-To: <20050531183653.GF20793@esmail.cup.hp.com> References: <20050531153819.GA20793@esmail.cup.hp.com> <1117560157.4310.16.camel@rh4> <20050531183653.GF20793@esmail.cup.hp.com> Date: Tue, 31 May 2005 10:42:45 -0700 Message-ID: <1117561365.4310.22.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E82701C1VO4071098-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 391 Lines: 11 On Tue, 2005-05-31 at 11:36 -0700, Grant Grundler wrote: > On Tue, May 31, 2005 at 10:22:37AM -0700, Michael Chan wrote: > > Thanks Grant, I'll chase this down and find a solution to this problem. > > You mean you'll help find a way to reflash the onboard eeprom? > No, I mean I will create a patch that will work for older devices that do not have the valid LED bits in eeprom. Thanks. From grundler@cup.hp.com Tue May 31 11:52:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 11:53:03 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VIqxXq000645 for ; Tue, 31 May 2005 11:52:59 -0700 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel13.hp.com (Postfix) with ESMTP id AABD61C048EB; Tue, 31 May 2005 11:34:27 -0700 (PDT) Received: from localhost.localdomain (debian.cup.hp.com [15.244.57.47]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id LAA23877; Tue, 31 May 2005 11:28:41 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 1000) id 7F0558FC56; Tue, 31 May 2005 11:36:53 -0700 (PDT) Date: Tue, 31 May 2005 11:36:53 -0700 From: Grant Grundler To: Michael Chan Cc: "David S. Miller" , Peter Chubb , netdev@oss.sgi.com Subject: Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way) Message-ID: <20050531183653.GF20793@esmail.cup.hp.com> References: <20050531153819.GA20793@esmail.cup.hp.com> <1117560157.4310.16.camel@rh4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117560157.4310.16.camel@rh4> User-Agent: Mutt/1.5.9i X-archive-position: 1900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: iod00d@hp.com Precedence: bulk X-list: netdev Content-Length: 855 Lines: 20 On Tue, May 31, 2005 at 10:22:37AM -0700, Michael Chan wrote: > > Michael, > > Peter bounced this email to me after we talked about issues he was > > having with the rx8620 (HP 16-way ia64, sx1000 chipset) "IOX Core LAN". > > It sounded like the same problem I tracked down with rx8620 IOX Core LAN > > in March. Here is the summary : > > > > | In May, 2004, tg3 v3.4 changed how MAC_LED_CTRL (0x40c) was getting > > | programmed and how to determine what to program into LED_CTRL. The new > > | code trusted NIC_SRAM_DATA_CFG (0x00000b58) to indicate what to write > > | to LED_CTRL and MII EXT_CTRL registers. On "IOX Core Lan", SRAM was > > | saying MODE_MAC (0x0) and that doesn't work. > > > > Thanks Grant, I'll chase this down and find a solution to this problem. You mean you'll help find a way to reflash the onboard eeprom? thanks, grant From grundler@cup.hp.com Tue May 31 12:02:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 12:02:19 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VJ2EXq001839 for ; Tue, 31 May 2005 12:02:16 -0700 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel10.hp.com (Postfix) with ESMTP id 11799199B; Tue, 31 May 2005 12:01:20 -0700 (PDT) Received: from localhost.localdomain (debian.cup.hp.com [15.244.57.47]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id LAA25796; Tue, 31 May 2005 11:55:34 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 1000) id F2C258FC56; Tue, 31 May 2005 12:03:45 -0700 (PDT) Date: Tue, 31 May 2005 12:03:45 -0700 From: Grant Grundler To: Michael Chan Cc: Grant Grundler , "David S. Miller" , Peter Chubb , netdev@oss.sgi.com Subject: Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way) Message-ID: <20050531190345.GH20793@esmail.cup.hp.com> References: <20050531153819.GA20793@esmail.cup.hp.com> <1117560157.4310.16.camel@rh4> <20050531183653.GF20793@esmail.cup.hp.com> <1117561365.4310.22.camel@rh4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117561365.4310.22.camel@rh4> User-Agent: Mutt/1.5.9i X-archive-position: 1901 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: iod00d@hp.com Precedence: bulk X-list: netdev Content-Length: 443 Lines: 13 On Tue, May 31, 2005 at 10:42:45AM -0700, Michael Chan wrote: > No, I mean I will create a patch that will work for older devices that > do not have the valid LED bits in eeprom. Ah ok. How can you know if the LED bits are valid (or not)? I consider this a bug in the eeprom and have set things in motion (in HP) to correct it since the card is not an obsolete product. Otherwise, the patch I submitted should be sufficient. thanks, grant From mchan@broadcom.com Tue May 31 12:21:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 12:21:45 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VJLeXq006540 for ; Tue, 31 May 2005 12:21:41 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 31 May 2005 12:20:30 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 31 May 2005 12:20:29 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BBJ08293; Tue, 31 May 2005 12:20:28 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA24929; Tue, 31 May 2005 12:20:28 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 May 2005 19:20:27 +0000 Received: from rh4 by nt-irva-0741; 31 May 2005 11:22:53 -0700 Subject: Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way) From: "Michael Chan" To: "Grant Grundler" cc: "David S. Miller" , "Peter Chubb" , netdev@oss.sgi.com In-Reply-To: <20050531190345.GH20793@esmail.cup.hp.com> References: <20050531153819.GA20793@esmail.cup.hp.com> <1117560157.4310.16.camel@rh4> <20050531183653.GF20793@esmail.cup.hp.com> <1117561365.4310.22.camel@rh4> <20050531190345.GH20793@esmail.cup.hp.com> Date: Tue, 31 May 2005 11:22:52 -0700 Message-ID: <1117563772.4310.30.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E8267742U44269185-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 807 Lines: 22 On Tue, 2005-05-31 at 12:03 -0700, Grant Grundler wrote: > On Tue, May 31, 2005 at 10:42:45AM -0700, Michael Chan wrote: > > No, I mean I will create a patch that will work for older devices that > > do not have the valid LED bits in eeprom. > > Ah ok. How can you know if the LED bits are valid (or not)? > There are version numbers and signatures that we may be able to use. I am working with the firmware engineer to see if we can find a way. > I consider this a bug in the eeprom and have set things in motion > (in HP) to correct it since the card is not an obsolete product. > > Otherwise, the patch I submitted should be sufficient. > I am hoping to have a patch that will work for all older devices instead of just checking for subvendor IDs, if possible. If not, we'll go with your patch. From davem@davemloft.net Tue May 31 14:44:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 14:44:54 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VLinXq011918 for ; Tue, 31 May 2005 14:44:49 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdEWQ-0002Oc-Ku; Tue, 31 May 2005 14:43:38 -0700 Date: Tue, 31 May 2005 14:43:38 -0700 (PDT) Message-Id: <20050531.144338.112623594.davem@davemloft.net> To: hadi@cyberus.ca Cc: tgraf@suug.ch, netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting From: "David S. Miller" In-Reply-To: <1117197157.6688.24.camel@localhost.localdomain> References: <1117197157.6688.24.camel@localhost.localdomain> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 350 Lines: 10 From: jamal Date: Fri, 27 May 2005 08:32:37 -0400 > This patch rectifies some rtnetlink message builders that derive the > flags from the pid. It is now explicit like the other cases > which get it right. > > Signed-off-by: Jamal Hadi Salim Please use explicit "unsigned int flags" instead of "unsigned flags". From davem@davemloft.net Tue May 31 14:42:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 14:42:23 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VLgIXq011678 for ; Tue, 31 May 2005 14:42:19 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdEU7-0002O9-3H; Tue, 31 May 2005 14:41:15 -0700 Date: Tue, 31 May 2005 14:41:14 -0700 (PDT) Message-Id: <20050531.144114.78710204.davem@davemloft.net> To: hch@lst.de Cc: netdev@oss.sgi.com Subject: Re: [PATCH] shaper.c: fix locking From: "David S. Miller" In-Reply-To: <20050527115450.GA19469@lst.de> References: <20050527115450.GA19469@lst.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 542 Lines: 13 From: Christoph Hellwig Subject: [PATCH] shaper.c: fix locking Date: Fri, 27 May 2005 13:54:50 +0200 > o use a semaphore instead of an opencoded and racy lock > o move locking out of shaper_kick and into the callers - most just > released the lock before calling shaper_kick > o remove in_interrupt() tests. from ->close we can always block, from > ->hard_start_xmit and timer context never Do you really want to use a semaphore for a lock taken %99 of the time in software IRQ context, which obviously cannot sleep? From davem@davemloft.net Tue May 31 14:57:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 14:57:37 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VLvVXq013624 for ; Tue, 31 May 2005 14:57:32 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdEip-0002QC-CB; Tue, 31 May 2005 14:56:27 -0700 Date: Tue, 31 May 2005 14:56:27 -0700 (PDT) Message-Id: <20050531.145627.85412348.davem@davemloft.net> To: tgraf@suug.ch Cc: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [RFC] textsearch infrastructure et al v2 From: "David S. Miller" In-Reply-To: <20050527224725.GG15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 355 Lines: 12 From: Thomas Graf Date: Sat, 28 May 2005 00:47:25 +0200 > Any other ideas around? You could just fetch "windows" of data. You can define this window to be 32 bytes, or whatever. Then you use skb_copy_data() into this 32 byte window scratch pad the text searcher uses, and you're done. It starts looking like an MPEG stream parser :-) From davem@davemloft.net Tue May 31 15:06:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:06:48 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VM6hXq014732 for ; Tue, 31 May 2005 15:06:44 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdEri-0002R1-G9; Tue, 31 May 2005 15:05:38 -0700 Date: Tue, 31 May 2005 15:05:38 -0700 (PDT) Message-Id: <20050531.150538.39158461.davem@davemloft.net> To: pablo@eurodev.net Cc: tgraf@suug.ch, hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [RFC] textsearch infrastructure et al v2 From: "David S. Miller" In-Reply-To: <42986A85.9060001@eurodev.net> References: <1117281581.6251.68.camel@localhost.localdomain> <20050528123542.GR15391@postel.suug.ch> <42986A85.9060001@eurodev.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 655 Lines: 16 From: Pablo Neira Date: Sat, 28 May 2005 14:56:37 +0200 > Netfilter used to follow this approach in early 2.6 kernels and Patrick > McHardy demostrated with some oprofile stuff that skb_copy_bits > decreased performance. This case got converted into what skb_copy_bits() was probably meant to be, skb_header_pointer(). The idea is, if it's linear in the SKB already (headers almost certainly are) just pass back the pointer to it, else copy into the user provided temporary buffer and return a pointer to that. The text search stuff could easily do the same thing, using a 32-byte or so sliding window to run the text search on. From jdmason@us.ibm.com Tue May 31 15:08:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:08:56 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VM8qXq015192 for ; Tue, 31 May 2005 15:08:52 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4VM7v0c733782 for ; Tue, 31 May 2005 18:07:57 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4VM7vmm149220 for ; Tue, 31 May 2005 16:07:57 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4VM7uVS021694 for ; Tue, 31 May 2005 16:07:56 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4VM7uNs021680; Tue, 31 May 2005 16:07:56 -0600 From: Jon Mason Organization: IBM To: Mitch Williams Subject: Re: RFC: NAPI packet weighting patch Date: Tue, 31 May 2005 17:07:54 -0500 User-Agent: KMail/1.7.2 Cc: jamal , Stephen Hemminger , netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Ronciak, John" , "Venkatesan, Ganesh" , "Brandeburg, Jesse" References: <1117241786.6251.7.camel@localhost.localdomain> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505311707.54487.jdmason@us.ibm.com> X-archive-position: 1907 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1198 Lines: 32 On Tuesday 31 May 2005 12:35 pm, Mitch Williams wrote: > On Fri, 27 May 2005, jamal wrote: > > On Fri, 2005-27-05 at 14:01 -0700, Stephen Hemminger wrote: > > > Why not just allow adjusting dev->weight via sysfs? > > > > I think that should be good enough - and i thought your patch already > > did this. > > Adding a shift to the weight in a _weighted_ RR algorithm does sound > > odd. > > Stephen's patch only affects the weight for the backlog device. Exporting > dev-> weight to sysfs will allow the weight to be set for any network > device. Which makes perfect sense. > > I'll work on getting this done and verifying performance this week. > Expect a patch in a few days. > > Thanks, guys. > > -Mitch It seems to me that the drivers should adjust dev->weight dependent on the media speed/duplexity of the current link. A 10Mbps link will be constantly re-enabling interrupts, as the incoming traffic is too slow. Why not have it be 1/4 the weight of the gigabit NAPI weight, and set it when the link speed is detected (or forced)? Of course some performace analysis would have to be done to determine the optimal numbers for each speed/duplexity setting per driver. Thanks, Jon From davem@davemloft.net Tue May 31 15:15:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:15:57 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMFtXq015907 for ; Tue, 31 May 2005 15:15:55 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdF0V-0002Rz-7G; Tue, 31 May 2005 15:14:43 -0700 Date: Tue, 31 May 2005 15:14:43 -0700 (PDT) Message-Id: <20050531.151443.74564699.davem@davemloft.net> To: jdmason@us.ibm.com Cc: mitch.a.williams@intel.com, hadi@cyberus.ca, shemminger@osdl.org, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: Re: RFC: NAPI packet weighting patch From: "David S. Miller" In-Reply-To: <200505311707.54487.jdmason@us.ibm.com> References: <1117241786.6251.7.camel@localhost.localdomain> <200505311707.54487.jdmason@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 839 Lines: 21 From: Jon Mason Date: Tue, 31 May 2005 17:07:54 -0500 > Of course some performace analysis would have to be done to determine the > optimal numbers for each speed/duplexity setting per driver. per cpu speed, per memory bus speed, per I/O bus speed, and add in other complications such as NUMA My point is that whatever experimental number you come up with will be good for that driver on your systems, not necessarily for others. Even within a system, whatever number you select will be the wrong thing to use if one starts a continuous I/O stream to the SATA controller in the next PCI slot, for example. We keep getting bitten by this, as the Altix perf data continually shows, and we need to absolutely stop thinking this way. The way to go is to make selections based upon observed events and mesaurements. From davem@davemloft.net Tue May 31 15:21:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:21:55 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMLrXq016553 for ; Tue, 31 May 2005 15:21:53 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdF6Q-0002UB-2S; Tue, 31 May 2005 15:20:50 -0700 Date: Tue, 31 May 2005 15:20:49 -0700 (PDT) Message-Id: <20050531.152049.48531507.davem@davemloft.net> To: tgraf@suug.ch Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: Re: [PATCH 2/7] [PKT_SCHED] make dsmark try using pfifo instead of noop while grafting From: "David S. Miller" In-Reply-To: <20050527145136.GT15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> <20050527145136.GT15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1910 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 25 Lines: 2 Applied, thanks Thomas. From davem@davemloft.net Tue May 31 15:21:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:22:00 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMLvXq016607 for ; Tue, 31 May 2005 15:21:57 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdF6U-0002UI-Dd; Tue, 31 May 2005 15:20:54 -0700 Date: Tue, 31 May 2005 15:20:54 -0700 (PDT) Message-Id: <20050531.152054.08322353.davem@davemloft.net> To: tgraf@suug.ch Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/7] [PKT_SCHED] Disable dsmark debugging messages by default From: "David S. Miller" In-Reply-To: <20050527145222.GU15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> <20050527145222.GU15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1911 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 25 Lines: 2 Applied, thanks Thomas. From davem@davemloft.net Tue May 31 15:21:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:21:53 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMLoXq016544 for ; Tue, 31 May 2005 15:21:50 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdF6L-0002Tx-Fr; Tue, 31 May 2005 15:20:45 -0700 Date: Tue, 31 May 2005 15:20:45 -0700 (PDT) Message-Id: <20050531.152045.18310045.davem@davemloft.net> To: tgraf@suug.ch Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: Re: [PATCH 1/7] [PKT_SCHED] Fix dsmark to count ignored indices while walking From: "David S. Miller" In-Reply-To: <20050527145058.GS15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> <20050527145058.GS15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1909 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 25 Lines: 2 Applied, thanks Thomas. From tgraf@suug.ch Tue May 31 15:27:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:27:24 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMRJXq018300 for ; Tue, 31 May 2005 15:27:20 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id C647F1C0EB; Wed, 1 Jun 2005 00:26:46 +0200 (CEST) Date: Wed, 1 Jun 2005 00:26:46 +0200 From: Thomas Graf To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting Message-ID: <20050531222646.GK15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050531.144338.112623594.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531.144338.112623594.davem@davemloft.net> X-archive-position: 1912 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 519 Lines: 13 * David S. Miller <20050531.144338.112623594.davem@davemloft.net> 2005-05-31 14:43 > From: jamal > Date: Fri, 27 May 2005 08:32:37 -0400 > > > This patch rectifies some rtnetlink message builders that derive the > > flags from the pid. It is now explicit like the other cases > > which get it right. > > > > Signed-off-by: Jamal Hadi Salim > > Please use explicit "unsigned int flags" instead of "unsigned flags". I converted this already in the two patches later in the thread. From davem@davemloft.net Tue May 31 15:31:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:31:14 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMVCXq019250 for ; Tue, 31 May 2005 15:31:12 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdFFQ-0002hF-Ly; Tue, 31 May 2005 15:30:08 -0700 Date: Tue, 31 May 2005 15:30:08 -0700 (PDT) Message-Id: <20050531.153008.112289363.davem@davemloft.net> To: tgraf@suug.ch Cc: werner@almesberger.net, netdev@oss.sgi.com Subject: Re: [PATCH 7/7] [PKT_SCHED] Logic simplifications and codingstyle/whitespace cleanups From: "David S. Miller" In-Reply-To: <20050527145611.GY15391@postel.suug.ch> References: <20050527145002.GR15391@postel.suug.ch> <20050527145611.GY15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1913 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 392 Lines: 12 Ok, I did something tricky to make this all work out and put the changes in the correct tree cleanly. I put patches 1-3 into my main net-2.6 tree, they will go to Linus shortly. Patches 4-7 I put into my net-2.6.13 tree after merging in the net-2.6 tree (and thus patches 1-3). I pushed it out to kernel.org, and it should show up on all the mirrors and the GIT website shortly. Thanks. From davem@davemloft.net Tue May 31 15:32:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:32:39 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMWWXq019783 for ; Tue, 31 May 2005 15:32:32 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdFGf-0002hY-Sk; Tue, 31 May 2005 15:31:25 -0700 Date: Tue, 31 May 2005 15:31:25 -0700 (PDT) Message-Id: <20050531.153125.95894437.davem@davemloft.net> To: tgraf@suug.ch Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: PATCH: rtnetlink explicit flags setting From: "David S. Miller" In-Reply-To: <20050531222646.GK15391@postel.suug.ch> References: <1117197157.6688.24.camel@localhost.localdomain> <20050531.144338.112623594.davem@davemloft.net> <20050531222646.GK15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1914 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 254 Lines: 8 From: Thomas Graf Date: Wed, 1 Jun 2005 00:26:46 +0200 > > Please use explicit "unsigned int flags" instead of "unsigned flags". > > I converted this already in the two patches later in the thread. I see, thanks for pointing this out. From romieu@fr.zoreil.com Tue May 31 15:35:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:35:56 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMZoXq020685 for ; Tue, 31 May 2005 15:35:51 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4VMV7a3001551; Wed, 1 Jun 2005 00:31:07 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4VMV2rj001550; Wed, 1 Jun 2005 00:31:02 +0200 Date: Wed, 1 Jun 2005 00:31:02 +0200 From: Francois Romieu To: James Harr Cc: netdev@oss.sgi.com Subject: Re: r8169 802.1q/MTU bug Message-ID: <20050531223102.GA29707@electric-eye.fr.zoreil.com> References: <20050530071148.GB1514@electric-eye.fr.zoreil.com> <200505301927.26110.james@grickle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505301927.26110.james@grickle.org> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1915 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 522 Lines: 25 James Harr : [...] > The driver you sent gives me an error when I try to compile and load it with > 2.6.11.11: The driver that I sent you builds with 2.6.12-rc4. Please try 2.6.12-rc4 + the aforementioned driver. If it still crashes (?), tell if your .config matches: CONFIG_R8169=m CONFIG_R8169_NAPI=y # CONFIG_R8169_VLAN is not set or: CONFIG_R8169=m CONFIG_R8169_NAPI=y CONFIG_R8169_VLAN=y An history of the commands issued to set the config before the crash would be welcome too. -- Ueimor From davem@davemloft.net Tue May 31 15:38:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:38:41 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMccXq021292 for ; Tue, 31 May 2005 15:38:39 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdFMa-0002jn-Gc; Tue, 31 May 2005 15:37:32 -0700 Date: Tue, 31 May 2005 15:37:32 -0700 (PDT) Message-Id: <20050531.153732.102575315.davem@davemloft.net> To: tgraf@suug.ch Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH 2/2] [NETLINK] Correctly set NLM_F_MULTI without checking the pid From: "David S. Miller" In-Reply-To: <20050527170135.GE15391@postel.suug.ch> References: <1117209466.6383.106.camel@localhost.localdomain> <20050527165935.GC15391@postel.suug.ch> <20050527170135.GE15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 86 Lines: 3 Both patches applied to my net-2.6.13 tree, it should show up on kernel.org shortly. From davem@davemloft.net Tue May 31 15:39:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:39:13 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMdAXq021399 for ; Tue, 31 May 2005 15:39:10 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdFN9-0002kH-7B; Tue, 31 May 2005 15:38:07 -0700 Date: Tue, 31 May 2005 15:38:07 -0700 (PDT) Message-Id: <20050531.153807.44097803.davem@davemloft.net> To: tgraf@suug.ch Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [DECNET] Remove unnecessary initilization of unused variable entries From: "David S. Miller" In-Reply-To: <20050528162624.GU15391@postel.suug.ch> References: <20050528162624.GU15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 249 Lines: 9 From: Thomas Graf Date: Sat, 28 May 2005 18:26:24 +0200 > This patch was supposed to be part of the neighbour tables related > patchset but apparently got lost. > > Signed-off-by: Thomas Graf Applied to net-2.6.13 From davem@davemloft.net Tue May 31 15:39:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:39:11 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMd8Xq021373 for ; Tue, 31 May 2005 15:39:08 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdFMy-0002k3-Jy; Tue, 31 May 2005 15:37:56 -0700 Date: Tue, 31 May 2005 15:37:56 -0700 (PDT) Message-Id: <20050531.153756.88476408.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: hadi@cyberus.ca, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification From: "David S. Miller" In-Reply-To: <20050527233741.GA9157@gondor.apana.org.au> References: <20050527233741.GA9157@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1917 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 118 Lines: 5 Applied to net-2.6.13, so you have some time to make some changes to the API before they get cast in stone. Thanks. From kernel@linuxace.com Tue May 31 15:41:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:41:13 -0700 (PDT) Received: from linuxace.com (adsl-67-120-171-161.dsl.lsan03.pacbell.net [67.120.171.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4VMf9Xq022873 for ; Tue, 31 May 2005 15:41:09 -0700 Received: (qmail 17099 invoked by uid 0); 31 May 2005 22:40:12 -0000 Date: Tue, 31 May 2005 15:40:12 -0700 From: Phil Oester To: netdev@oss.sgi.com Cc: herbert@gondor.apana.org.au, akpm@osdl.org Subject: 2.6.12-rcx networking oops Message-ID: <20050531224012.GA16789@linuxace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 1919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@linuxace.com Precedence: bulk X-list: netdev Content-Length: 6140 Lines: 149 At Andrew's suggestion, I tested the latest 2.6.12-rc5-gitx, and am still hitting an oops on a gateway box under load. From comparing the various oops, it seems like a dev is disappearing while one CPU is in the middle of processing traffic. At least that's what my naive analysis leads me to believe. The latest oops is the first shown below (2.6.12-rc5-git5), and seems to be here: 0xc0270d3f is in fib_validate_source (net/ipv4/fib_frontend.c:195). 195 if (FIB_RES_DEV(res) == dev) The second oops below was against 2.6.12-rc4, hitting here: 0xc026a59a is in inet_select_addr (inetdevice.h:159). 159 return (struct in_device*)dev->ip_ptr; The third oops below is also against 2.6.12-rc4, hitting here: 0xc026dbba is in ip_check_mc (net/ipv4/igmp.c:2101). 2101 for (im=in_dev->mc_list; im; im=im->next) { Since I'm trying to update a 2.6.10 box, Herbert Xu asked me to test each 2.6.11-rc to see where the problem begins, but it appears around 2.6.11-rc2 some LLTX changes were made which caused lockups (they were later reverted before 2.6.11-final). So, I can't really tell when this started. Any further suggestions? Phil Unable to handle kernel NULL pointer dereference at virtual address 00000060 printing eip: c0270d3f *pde = 00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010206 (2.6.12-rc5-git5) EIP is at fib_validate_source+0xcf/0x1f0 eax: f7c2c000 ebx: c0337dec ecx: f7c258a0 edx: 00000000 esi: c0335c2c edi: 00000000 ebp: c0337db0 esp: c0337d40 ds: 3f1f es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0337000 task=c02b9bc0) Stack: 00000000 3b6014aa 00000000 00010000 f7b7a460 00000000 00000002 3b6014aa 4f7514aa 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c0337e00 Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x14d/0x1b0 [] die+0xed/0x170 [] do_page_fault+0x30a/0x65a [] error_code+0x4f/0x54 [] ip_route_input_slow+0x445/0x840 [] ip_route_input+0x9a/0x160 [] ip_rcv+0x3b0/0x4d0 [] netif_receive_skb+0x13a/0x1a0 [] e1000_clean_rx_irq+0x180/0x4d0 [] e1000_clean+0x40/0xe0 [] net_rx_action+0x90/0x130 [] __do_softirq+0xd4/0xf0 [] do_softirq+0x52/0x70 ======================= [] irq_exit+0x3a/0x40 [] do_IRQ+0x50/0x70 [] common_interrupt+0x1a/0x20 [] cpu_idle+0x7b/0x80 [] rest_init+0x1e/0x20 [] start_kernel+0x14c/0x170 [] 0xc010020e Code: ff 83 c4 64 5b 5e 5f 5d c3 89 d0 e8 4c 09 00 00 eb ea 8b 46 04 8b 40 24 85 c0 0f 84 00 01 00 00 8b 5d 10 89 03 8b 56 04 8b 45 0c <39> 42 60 0f 84 dd 00 00 00 85 d2 74 0f f0 ff 4a 14 0f 94 c0 84 Unable to handle kernel NULL pointer dereference at virtual address 000000ec printing eip: c026a59a *pde = 00000000 Oops: 0000 [#1] SMP CPU: 1 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.12-rc4) EIP is at inet_select_addr+0xa/0xf0 eax: 00000000 ebx: c1bb4720 ecx: 00000000 edx: 00000000 esi: 00000000 edi: 00000000 ebp: c0333d60 esp: c0333d54 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0333000 task=c191b520) Stack: c1bb4720 c0333d74 00000000 c0333dd8 c026eb0b 00000000 3e6014aa 00000000 0001001d f78d169f 00000000 00000001 3e6014aa 25e65e42 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x14d/0x1b0 [] die+0xed/0x170 [] do_page_fault+0x30a/0x65a [] error_code+0x4f/0x54 [] fib_validate_source+0x1cb/0x1f0 [] ip_route_input_slow+0x445/0x840 [] ip_rcv+0x3b0/0x4d0 [] netif_receive_skb+0x13a/0x1a0 [] e1000_clean_rx_irq+0x156/0x480 [] e1000_clean+0x3f/0xe0 [] net_rx_action+0x90/0x130 [] __do_softirq+0xd4/0xf0 [] do_softirq+0x52/0x70 ======================= [] do_IRQ+0x50/0x70 [] common_interrupt+0x1a/0x20 [] cpu_idle+0x72/0x80 [<00000000>] stext+0x3feffd6c/0xc [] 0xc191ffb4 Code: 30 5b 5e 5f 5d c3 c7 45 c4 f2 <7> ff ff ff eb ec 89 f6 8b 75 d0 eb ae 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 57 31 ff 56 89 ce 53 <8b> 80 ec 00 00 00 85 c0 74 38 8b 48 0c 85 c9 74 2d f6 41 25 01 Unable to handle kernel NULL pointer dereference at virtual address 00000060 printing eip: c026b44a *pde = 00000000 Oops: 0000 [#1] SMP CPU: 1 EIP: 0060:[] Not tainted VLI EFLAGS: 00010206 (2.6.12-rc4) EIP is at ip_check_mc+0x2a/0xb0 eax: 026014aa ebx: c1bb4720 ecx: f7a51e60 edx: 00000000 esi: c033bbe6 edi: 0000b9e6 ebp: f7c29000 esp: c0331d88 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0331000 task=c191b520) Stack: 00000000 3e6014aa 00000000 0001001d f7044f60 00000000 00000001 3e6014aa 7525bece 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c0331e44 Call Trace: [] ip_route_input_slow+0x3da/0x760 [] ip_rcv+0x3b9/0x4d0 [] ip_rcv_finish+0x0/0x240 [] __wake_up+0x38/0x50 [] netif_receive_skb+0x13a/0x1a0 [] e1000_clean_rx_irq+0x16e/0x4c0 [] e1000_clean_tx_irq+0x1af/0x3b0 [] e1000_clean+0x3c/0xe0 [] net_rx_action+0x7f/0x110 [] __do_softirq+0xd4/0xf0 [] do_softirq+0x4f/0x60 ======================= [] do_IRQ+0x4d/0x70 [] common_interrupt+0x1a/0x20 [] default_idle+0x0/0x30 [] default_idle+0x23/0x30 [] cpu_idle+0x70/0x80 Code: 90 55 31 ed 57 56 89 d6 53 83 ec 08 89 c3 89 4c 24 04 8d 40 10 89 04 24 0f b7 7c 24 1c e8 3f be 01 00 8b 43 14 85 c0 74 14 90 8d 26 00 00 00 00 39 70 04 74 19 8b 40 1c 85 c0 75 f4 8b 04 24 From tgraf@suug.ch Tue May 31 15:45:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:45:18 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMjDXq023458 for ; Tue, 31 May 2005 15:45:14 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id E07F91C0EB; Wed, 1 Jun 2005 00:44:39 +0200 (CEST) Date: Wed, 1 Jun 2005 00:44:39 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [RFC] textsearch infrastructure et al v2 Message-ID: <20050531224439.GL15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> <20050531.145627.85412348.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531.145627.85412348.davem@davemloft.net> X-archive-position: 1920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 927 Lines: 25 * David S. Miller <20050531.145627.85412348.davem@davemloft.net> 2005-05-31 14:56 > From: Thomas Graf > Date: Sat, 28 May 2005 00:47:25 +0200 > > > Any other ideas around? > > You could just fetch "windows" of data. > > You can define this window to be 32 bytes, or whatever. Heh, I had something like this in mind. Well, basically the current behaviour is not different except that the window is variable and uses the page data directly rather than copying. Back on the static window subject, it would definitely be helpful for right-to-left scan algorithms such as boyer-moore. However, I think that the overhead due to the massive map/unmap and copying is bigger than the costs of naive searches around the fragment borders. Pablo joined me on the subject, he's currently working on converting the fragmentation iteration to use Rusty's skb_iter code. we'll present new work with some numbers shortly. From edgar@edgar.se.axis.com Tue May 31 15:48:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:48:26 -0700 (PDT) Received: from miranda.se.axis.com (miranda.se.axis.com [193.13.178.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMmJXq024177 for ; Tue, 31 May 2005 15:48:19 -0700 Received: from edgar.se.axis.com (edgar.se.axis.com [10.92.151.1]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id j4VMlHNc005124 for ; Wed, 1 Jun 2005 00:47:17 +0200 Received: (qmail 4563 invoked by uid 400); 1 Jun 2005 00:47:17 +0200 Date: Wed, 1 Jun 2005 00:47:17 +0200 From: Edgar E Iglesias To: netdev@oss.sgi.com Subject: ipv4 ipsec Message-ID: <20050531224717.GE4068@edgar.se.axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i X-archive-position: 1921 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: edgar.iglesias@axis.com Precedence: bulk X-list: netdev Content-Length: 1119 Lines: 38 Hi, Im not sure this is the correct list for ipsec issues, but shouldn't the size check at the bottom of net/ipv4/esp4.c be the other way around (2.6.11)? static int __init esp4_init(void) { struct xfrm_decap_state decap; if (sizeof(struct esp_decap_data) < sizeof(decap.decap_data)) { extern void decap_data_too_small(void); decap_data_too_small(); } decap.decap_data should hold an opaque type for the implementation specific decap state, so I guess it should be the bigger of the two. Best regards -- Programmer Edgar E Iglesias 46.46.272.1946 % diff -bu /usr/src/linux-2.6.11-gentoo-r8/net/ipv4/esp4.c esp4.c --- /usr/src/linux-2.6.11-gentoo-r8/net/ipv4/esp4.c 2005-05-11 10:05:03.000000000 +0200 +++ esp4.c 2005-06-01 00:38:55.000000000 +0200 @@ -480,7 +480,7 @@ { struct xfrm_decap_state decap; - if (sizeof(struct esp_decap_data) < + if (sizeof(struct esp_decap_data) > sizeof(decap.decap_data)) { extern void decap_data_too_small(void); From davem@davemloft.net Tue May 31 15:49:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:49:56 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMnrXq024725 for ; Tue, 31 May 2005 15:49:53 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdFXU-0005EW-7P for netdev@oss.sgi.com; Tue, 31 May 2005 15:48:48 -0700 Date: Tue, 31 May 2005 15:48:47 -0700 (PDT) Message-Id: <20050531.154847.63995530.davem@davemloft.net> To: netdev@oss.sgi.com Subject: Locking model for NAPI drivers From: "David S. Miller" X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 26484 Lines: 946 I was doing some brainstorming to try and fix a nagging problem in the tg3 driver which suggested that doing the SMP locking differently might be the best and cleanest solution. The tg3 problem is that it can do an skb_copy() in HW IRQ disabled context which is illegal. But then I noticed that the spinlocks really don't need IRQ disabling. Only the tinyest sliver of code, the interrupt handler, actually runs in HW interrupt context. The bulk of the driver runs in SW interrupt context. So the idea is, if we can make all of the spinlocks BH locks we'll solve a whole bunch of problems: 1) skb_copy() will run in BH context, fixing that bug 2) the driver will actually produce useful profiling data via oprofile and friends since timer interrupts will run even while holding the locks 3) moving long delays (particually when doing link settings) into work queues becomes much easier, at least in theory Once we make this transformation, we need some way to synchronize with the IRQ handler when shutting down the device or making major configuration changes to the chip. The idea I came up with is a two-bit atomic bitmask. When base level code wants to quiesce interrupt processing, it takes the necessary driver spinlocks, sets the "SYNC" bit in the bitmask, forces and IRQ to be asserted by the tg3 card, then waits for the COMPLETE bit to get set by the interrupt handler. The total cost of this scheme under normal operation is a single shared memory location read at hw IRQ time. If e1000, ixgb, s2io, the infiniband drivers, and friends can force the chip to signal an interrupt they can do this kind of locking enhancement as well. Here is the full implementation I'm testing currently with Michael Chan for tg3. Note how tg3_tx() can now directly call dev_kfree_skb() directly (instead of dev_kfree_skb_irq()) and most of tg3_poll() can now run totally lockless. [TG3]: Eliminate all hw IRQ handler spinlocks. Move all driver spinlocks to be taken at sw IRQ context only. This fixes the skb_copy() we were doing with hw IRQs disabled (which is illegal and triggers a BUG() with HIGHMEM enabled). It also simplifies the locking all over the driver tremendously. We accomplish this feat by creating a special sequence to synchronize with the hw IRQ handler using a 2-bit atomic state. Signed-off-by: David S. Miller --- 1/drivers/net/tg3.c.~1~ 2005-05-30 15:29:23.000000000 -0700 +++ 2/drivers/net/tg3.c 2005-05-31 14:20:08.000000000 -0700 @@ -332,12 +332,10 @@ static struct { static void tg3_write_indirect_reg32(struct tg3 *tp, u32 off, u32 val) { if ((tp->tg3_flags & TG3_FLAG_PCIX_TARGET_HWBUG) != 0) { - unsigned long flags; - - spin_lock_irqsave(&tp->indirect_lock, flags); + spin_lock_bh(&tp->indirect_lock); pci_write_config_dword(tp->pdev, TG3PCI_REG_BASE_ADDR, off); pci_write_config_dword(tp->pdev, TG3PCI_REG_DATA, val); - spin_unlock_irqrestore(&tp->indirect_lock, flags); + spin_unlock_bh(&tp->indirect_lock); } else { writel(val, tp->regs + off); if ((tp->tg3_flags & TG3_FLAG_5701_REG_WRITE_BUG) != 0) @@ -348,12 +346,10 @@ static void tg3_write_indirect_reg32(str static void _tw32_flush(struct tg3 *tp, u32 off, u32 val) { if ((tp->tg3_flags & TG3_FLAG_PCIX_TARGET_HWBUG) != 0) { - unsigned long flags; - - spin_lock_irqsave(&tp->indirect_lock, flags); + spin_lock_bh(&tp->indirect_lock); pci_write_config_dword(tp->pdev, TG3PCI_REG_BASE_ADDR, off); pci_write_config_dword(tp->pdev, TG3PCI_REG_DATA, val); - spin_unlock_irqrestore(&tp->indirect_lock, flags); + spin_unlock_bh(&tp->indirect_lock); } else { void __iomem *dest = tp->regs + off; writel(val, dest); @@ -393,28 +389,24 @@ static inline void _tw32_tx_mbox(struct static void tg3_write_mem(struct tg3 *tp, u32 off, u32 val) { - unsigned long flags; - - spin_lock_irqsave(&tp->indirect_lock, flags); + spin_lock_bh(&tp->indirect_lock); pci_write_config_dword(tp->pdev, TG3PCI_MEM_WIN_BASE_ADDR, off); pci_write_config_dword(tp->pdev, TG3PCI_MEM_WIN_DATA, val); /* Always leave this as zero. */ pci_write_config_dword(tp->pdev, TG3PCI_MEM_WIN_BASE_ADDR, 0); - spin_unlock_irqrestore(&tp->indirect_lock, flags); + spin_unlock_bh(&tp->indirect_lock); } static void tg3_read_mem(struct tg3 *tp, u32 off, u32 *val) { - unsigned long flags; - - spin_lock_irqsave(&tp->indirect_lock, flags); + spin_lock_bh(&tp->indirect_lock); pci_write_config_dword(tp->pdev, TG3PCI_MEM_WIN_BASE_ADDR, off); pci_read_config_dword(tp->pdev, TG3PCI_MEM_WIN_DATA, val); /* Always leave this as zero. */ pci_write_config_dword(tp->pdev, TG3PCI_MEM_WIN_BASE_ADDR, 0); - spin_unlock_irqrestore(&tp->indirect_lock, flags); + spin_unlock_bh(&tp->indirect_lock); } static void tg3_disable_ints(struct tg3 *tp) @@ -438,7 +430,7 @@ static void tg3_enable_ints(struct tg3 * tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, (tp->last_tag << 24)); tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW); - + tp->irq_state = 0; tg3_cond_int(tp); } @@ -475,6 +467,8 @@ static void tg3_restart_ints(struct tg3 tp->last_tag << 24); mmiowb(); + BUG_ON(tp->irq_state); + /* When doing tagged status, this work check is unnecessary. * The last_tag we write above tells the chip which piece of * work we've completed. @@ -2573,7 +2567,7 @@ static void tg3_tx(struct tg3 *tp) sw_idx = NEXT_TX(sw_idx); } - dev_kfree_skb_irq(skb); + dev_kfree_skb(skb); } tp->tx_cons = sw_idx; @@ -2879,11 +2873,8 @@ static int tg3_poll(struct net_device *n { struct tg3 *tp = netdev_priv(netdev); struct tg3_hw_status *sblk = tp->hw_status; - unsigned long flags; int done; - spin_lock_irqsave(&tp->lock, flags); - /* handle link change and other phy events */ if (!(tp->tg3_flags & (TG3_FLAG_USE_LINKCHG_REG | @@ -2891,7 +2882,9 @@ static int tg3_poll(struct net_device *n if (sblk->status & SD_STATUS_LINK_CHG) { sblk->status = SD_STATUS_UPDATED | (sblk->status & ~SD_STATUS_LINK_CHG); + spin_lock(&tp->lock); tg3_setup_phy(tp, 0); + spin_unlock(&tp->lock); } } @@ -2902,8 +2895,6 @@ static int tg3_poll(struct net_device *n spin_unlock(&tp->tx_lock); } - spin_unlock_irqrestore(&tp->lock, flags); - /* run RX thread, within the bounds set by NAPI. * All RX "locking" is done by ensuring outside * code synchronizes with dev->poll() @@ -2928,15 +2919,56 @@ static int tg3_poll(struct net_device *n /* if no more work, tell net stack and NIC we're done */ done = !tg3_has_work(tp); if (done) { - spin_lock_irqsave(&tp->lock, flags); + spin_lock(&tp->lock); __netif_rx_complete(netdev); tg3_restart_ints(tp); - spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock(&tp->lock); } return (done ? 0 : 1); } +static void tg3_irq_quiesce(struct tg3 *tp) +{ + BUG_ON(test_bit(TG3_IRQSTATE_SYNC, &tp->irq_state)); + + set_bit(TG3_IRQSTATE_SYNC, &tp->irq_state); + smp_mb(); + tw32(GRC_LOCAL_CTRL, + tp->grc_local_ctrl | GRC_LCLCTRL_SETINT); + + while (!test_bit(TG3_IRQSTATE_COMPLETE, &tp->irq_state)) + cpu_relax(); +} + +static inline int tg3_irq_sync(struct tg3 *tp) +{ + if (test_bit(TG3_IRQSTATE_SYNC, &tp->irq_state)) { + set_bit(TG3_IRQSTATE_COMPLETE, &tp->irq_state); + return 1; + } + return 0; +} + +/* Fully shutdown all tg3 driver activity elsewhere in the system. + * If irq_sync is non-zero, then the IRQ handler must be synchronized + * with as well. Most of the time, this is not necessary except when + * shutting down the device. + */ +static inline void tg3_full_lock(struct tg3 *tp, int irq_sync) +{ + if (irq_sync) + tg3_irq_quiesce(tp); + spin_lock_bh(&tp->lock); + spin_lock(&tp->tx_lock); +} + +static inline void tg3_full_unlock(struct tg3 *tp) +{ + spin_unlock(&tp->tx_lock); + spin_unlock_bh(&tp->lock); +} + /* MSI ISR - No need to check for interrupt sharing and no need to * flush status block and interrupt mailbox. PCI ordering rules * guarantee that MSI will arrive after the status block. @@ -2946,9 +2978,6 @@ static irqreturn_t tg3_msi(int irq, void struct net_device *dev = dev_id; struct tg3 *tp = netdev_priv(dev); struct tg3_hw_status *sblk = tp->hw_status; - unsigned long flags; - - spin_lock_irqsave(&tp->lock, flags); /* * Writing any value to intr-mbox-0 clears PCI INTA# and @@ -2959,6 +2988,8 @@ static irqreturn_t tg3_msi(int irq, void */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); tp->last_tag = sblk->status_tag; + if (tg3_irq_sync(tp)) + goto out; sblk->status &= ~SD_STATUS_UPDATED; if (likely(tg3_has_work(tp))) netif_rx_schedule(dev); /* schedule NAPI poll */ @@ -2967,9 +2998,7 @@ static irqreturn_t tg3_msi(int irq, void tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, tp->last_tag << 24); } - - spin_unlock_irqrestore(&tp->lock, flags); - +out: return IRQ_RETVAL(1); } @@ -2978,11 +3007,8 @@ static irqreturn_t tg3_interrupt(int irq struct net_device *dev = dev_id; struct tg3 *tp = netdev_priv(dev); struct tg3_hw_status *sblk = tp->hw_status; - unsigned long flags; unsigned int handled = 1; - spin_lock_irqsave(&tp->lock, flags); - /* In INTx mode, it is possible for the interrupt to arrive at * the CPU before the status block posted prior to the interrupt. * Reading the PCI State register will confirm whether the @@ -2999,6 +3025,8 @@ static irqreturn_t tg3_interrupt(int irq */ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); + if (tg3_irq_sync(tp)) + goto out; sblk->status &= ~SD_STATUS_UPDATED; if (likely(tg3_has_work(tp))) netif_rx_schedule(dev); /* schedule NAPI poll */ @@ -3013,9 +3041,7 @@ static irqreturn_t tg3_interrupt(int irq } else { /* shared interrupt */ handled = 0; } - - spin_unlock_irqrestore(&tp->lock, flags); - +out: return IRQ_RETVAL(handled); } @@ -3024,11 +3050,8 @@ static irqreturn_t tg3_interrupt_tagged( struct net_device *dev = dev_id; struct tg3 *tp = netdev_priv(dev); struct tg3_hw_status *sblk = tp->hw_status; - unsigned long flags; unsigned int handled = 1; - spin_lock_irqsave(&tp->lock, flags); - /* In INTx mode, it is possible for the interrupt to arrive at * the CPU before the status block posted prior to the interrupt. * Reading the PCI State register will confirm whether the @@ -3046,6 +3069,8 @@ static irqreturn_t tg3_interrupt_tagged( tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); tp->last_tag = sblk->status_tag; + if (tg3_irq_sync(tp)) + goto out; sblk->status &= ~SD_STATUS_UPDATED; if (likely(tg3_has_work(tp))) netif_rx_schedule(dev); /* schedule NAPI poll */ @@ -3060,9 +3085,7 @@ static irqreturn_t tg3_interrupt_tagged( } else { /* shared interrupt */ handled = 0; } - - spin_unlock_irqrestore(&tp->lock, flags); - +out: return IRQ_RETVAL(handled); } @@ -3101,8 +3124,7 @@ static void tg3_reset_task(void *_data) tg3_netif_stop(tp); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 1); restart_timer = tp->tg3_flags2 & TG3_FLG2_RESTART_TIMER; tp->tg3_flags2 &= ~TG3_FLG2_RESTART_TIMER; @@ -3112,8 +3134,7 @@ static void tg3_reset_task(void *_data) tg3_netif_start(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); if (restart_timer) mod_timer(&tp->timer, jiffies + 1); @@ -3219,39 +3240,21 @@ static int tg3_start_xmit(struct sk_buff unsigned int i; u32 len, entry, base_flags, mss; int would_hit_hwbug; - unsigned long flags; len = skb_headlen(skb); /* No BH disabling for tx_lock here. We are running in BH disabled * context and TX reclaim runs via tp->poll inside of a software - * interrupt. Rejoice! - * - * Actually, things are not so simple. If we are to take a hw - * IRQ here, we can deadlock, consider: - * - * CPU1 CPU2 - * tg3_start_xmit - * take tp->tx_lock - * tg3_timer - * take tp->lock - * tg3_interrupt - * spin on tp->lock - * spin on tp->tx_lock - * - * So we really do need to disable interrupts when taking - * tx_lock here. + * interrupt. Furthermore, IRQ processing runs lockless so we have + * no IRQ context deadlocks to worry about either. Rejoice! */ - local_irq_save(flags); - if (!spin_trylock(&tp->tx_lock)) { - local_irq_restore(flags); + if (!spin_trylock(&tp->tx_lock)) return NETDEV_TX_LOCKED; - } /* This is a hard error, log it. */ if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->nr_frags + 1))) { netif_stop_queue(dev); - spin_unlock_irqrestore(&tp->tx_lock, flags); + spin_unlock(&tp->tx_lock); printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", dev->name); return NETDEV_TX_BUSY; @@ -3416,7 +3419,7 @@ static int tg3_start_xmit(struct sk_buff out_unlock: mmiowb(); - spin_unlock_irqrestore(&tp->tx_lock, flags); + spin_unlock(&tp->tx_lock); dev->trans_start = jiffies; @@ -3450,8 +3453,8 @@ static int tg3_change_mtu(struct net_dev } tg3_netif_stop(tp); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + + tg3_full_lock(tp, 1); tg3_halt(tp, RESET_KIND_SHUTDOWN, 1); @@ -3461,8 +3464,7 @@ static int tg3_change_mtu(struct net_dev tg3_netif_start(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); return 0; } @@ -5083,9 +5085,9 @@ static int tg3_set_mac_addr(struct net_d memcpy(dev->dev_addr, addr->sa_data, dev->addr_len); - spin_lock_irq(&tp->lock); + spin_lock_bh(&tp->lock); __tg3_set_mac_addr(tp); - spin_unlock_irq(&tp->lock); + spin_unlock_bh(&tp->lock); return 0; } @@ -5797,10 +5799,8 @@ static void tg3_periodic_fetch_stats(str static void tg3_timer(unsigned long __opaque) { struct tg3 *tp = (struct tg3 *) __opaque; - unsigned long flags; - spin_lock_irqsave(&tp->lock, flags); - spin_lock(&tp->tx_lock); + spin_lock(&tp->lock); if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) { /* All of this garbage is because when using non-tagged @@ -5817,8 +5817,7 @@ static void tg3_timer(unsigned long __op if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) { tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER; - spin_unlock(&tp->tx_lock); - spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock(&tp->lock); schedule_work(&tp->reset_task); return; } @@ -5886,8 +5885,7 @@ static void tg3_timer(unsigned long __op tp->asf_counter = tp->asf_multiplier; } - spin_unlock(&tp->tx_lock); - spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock(&tp->lock); tp->timer.expires = jiffies + tp->timer_offset; add_timer(&tp->timer); @@ -6002,14 +6000,12 @@ static int tg3_test_msi(struct tg3 *tp) /* Need to reset the chip because the MSI cycle may have terminated * with Master Abort. */ - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 1); tg3_halt(tp, RESET_KIND_SHUTDOWN, 1); err = tg3_init_hw(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); if (err) free_irq(tp->pdev->irq, dev); @@ -6022,14 +6018,12 @@ static int tg3_open(struct net_device *d struct tg3 *tp = netdev_priv(dev); int err; - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); tg3_disable_ints(tp); tp->tg3_flags &= ~TG3_FLAG_INIT_COMPLETE; - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); /* The placement of this call is tied * to the setup and use of Host TX descriptors. @@ -6076,8 +6070,7 @@ static int tg3_open(struct net_device *d return err; } - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); err = tg3_init_hw(tp); if (err) { @@ -6101,8 +6094,7 @@ static int tg3_open(struct net_device *d tp->timer.function = tg3_timer; } - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); if (err) { free_irq(tp->pdev->irq, dev); @@ -6118,8 +6110,7 @@ static int tg3_open(struct net_device *d err = tg3_test_msi(tp); if (err) { - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) { pci_disable_msi(tp->pdev); @@ -6129,22 +6120,19 @@ static int tg3_open(struct net_device *d tg3_free_rings(tp); tg3_free_consistent(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); return err; } } - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); add_timer(&tp->timer); tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE; tg3_enable_ints(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); netif_start_queue(dev); @@ -6390,8 +6378,7 @@ static int tg3_close(struct net_device * del_timer_sync(&tp->timer); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 1); #if 0 tg3_dump_state(tp); #endif @@ -6405,8 +6392,7 @@ static int tg3_close(struct net_device * TG3_FLAG_GOT_SERDES_FLOWCTL); netif_carrier_off(tp->dev); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); free_irq(tp->pdev->irq, dev); if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) { @@ -6443,16 +6429,15 @@ static unsigned long calc_crc_errors(str if (!(tp->tg3_flags2 & TG3_FLG2_PHY_SERDES) && (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701)) { - unsigned long flags; u32 val; - spin_lock_irqsave(&tp->lock, flags); + spin_lock_bh(&tp->lock); if (!tg3_readphy(tp, 0x1e, &val)) { tg3_writephy(tp, 0x1e, val | 0x8000); tg3_readphy(tp, 0x14, &val); } else val = 0; - spin_unlock_irqrestore(&tp->lock, flags); + spin_unlock_bh(&tp->lock); tp->phy_crc_errors += val; @@ -6714,11 +6699,9 @@ static void tg3_set_rx_mode(struct net_d { struct tg3 *tp = netdev_priv(dev); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); __tg3_set_rx_mode(dev); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); } #define TG3_REGDUMP_LEN (32 * 1024) @@ -6740,8 +6723,7 @@ static void tg3_get_regs(struct net_devi memset(p, 0, TG3_REGDUMP_LEN); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); #define __GET_REG32(reg) (*(p)++ = tr32(reg)) #define GET_REG32_LOOP(base,len) \ @@ -6791,8 +6773,7 @@ do { p = (u32 *)(orig_p + (reg)); \ #undef GET_REG32_LOOP #undef GET_REG32_1 - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); } static int tg3_get_eeprom_len(struct net_device *dev) @@ -6968,8 +6949,7 @@ static int tg3_set_settings(struct net_d return -EINVAL; } - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); tp->link_config.autoneg = cmd->autoneg; if (cmd->autoneg == AUTONEG_ENABLE) { @@ -6985,8 +6965,7 @@ static int tg3_set_settings(struct net_d if (netif_running(dev)) tg3_setup_phy(tp, 1); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); return 0; } @@ -7022,12 +7001,12 @@ static int tg3_set_wol(struct net_device !(tp->tg3_flags & TG3_FLAG_SERDES_WOL_CAP)) return -EINVAL; - spin_lock_irq(&tp->lock); + spin_lock_bh(&tp->lock); if (wol->wolopts & WAKE_MAGIC) tp->tg3_flags |= TG3_FLAG_WOL_ENABLE; else tp->tg3_flags &= ~TG3_FLAG_WOL_ENABLE; - spin_unlock_irq(&tp->lock); + spin_unlock_bh(&tp->lock); return 0; } @@ -7067,7 +7046,7 @@ static int tg3_nway_reset(struct net_dev if (!netif_running(dev)) return -EAGAIN; - spin_lock_irq(&tp->lock); + spin_lock_bh(&tp->lock); r = -EINVAL; tg3_readphy(tp, MII_BMCR, &bmcr); if (!tg3_readphy(tp, MII_BMCR, &bmcr) && @@ -7075,7 +7054,7 @@ static int tg3_nway_reset(struct net_dev tg3_writephy(tp, MII_BMCR, bmcr | BMCR_ANRESTART); r = 0; } - spin_unlock_irq(&tp->lock); + spin_unlock_bh(&tp->lock); return r; } @@ -7106,8 +7085,7 @@ static int tg3_set_ringparam(struct net_ if (netif_running(dev)) tg3_netif_stop(tp); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); tp->rx_pending = ering->rx_pending; @@ -7123,8 +7101,7 @@ static int tg3_set_ringparam(struct net_ tg3_netif_start(tp); } - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); return 0; } @@ -7145,8 +7122,8 @@ static int tg3_set_pauseparam(struct net if (netif_running(dev)) tg3_netif_stop(tp); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 1); + if (epause->autoneg) tp->tg3_flags |= TG3_FLAG_PAUSE_AUTONEG; else @@ -7165,8 +7142,8 @@ static int tg3_set_pauseparam(struct net tg3_init_hw(tp); tg3_netif_start(tp); } - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + + tg3_full_unlock(tp); return 0; } @@ -7187,12 +7164,12 @@ static int tg3_set_rx_csum(struct net_de return 0; } - spin_lock_irq(&tp->lock); + spin_lock_bh(&tp->lock); if (data) tp->tg3_flags |= TG3_FLAG_RX_CHECKSUMS; else tp->tg3_flags &= ~TG3_FLAG_RX_CHECKSUMS; - spin_unlock_irq(&tp->lock); + spin_unlock_bh(&tp->lock); return 0; } @@ -7714,8 +7691,7 @@ static void tg3_self_test(struct net_dev if (netif_running(dev)) tg3_netif_stop(tp); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 1); tg3_halt(tp, RESET_KIND_SUSPEND, 1); tg3_nvram_lock(tp); @@ -7737,14 +7713,14 @@ static void tg3_self_test(struct net_dev data[4] = 1; } - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); + if (tg3_test_interrupt(tp) != 0) { etest->flags |= ETH_TEST_FL_FAILED; data[5] = 1; } - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + + tg3_full_lock(tp, 0); tg3_halt(tp, RESET_KIND_SHUTDOWN, 1); if (netif_running(dev)) { @@ -7752,8 +7728,8 @@ static void tg3_self_test(struct net_dev tg3_init_hw(tp); tg3_netif_start(tp); } - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + + tg3_full_unlock(tp); } } @@ -7774,9 +7750,9 @@ static int tg3_ioctl(struct net_device * if (tp->tg3_flags2 & TG3_FLG2_PHY_SERDES) break; /* We have no PHY */ - spin_lock_irq(&tp->lock); + spin_lock_bh(&tp->lock); err = tg3_readphy(tp, data->reg_num & 0x1f, &mii_regval); - spin_unlock_irq(&tp->lock); + spin_unlock_bh(&tp->lock); data->val_out = mii_regval; @@ -7790,9 +7766,9 @@ static int tg3_ioctl(struct net_device * if (!capable(CAP_NET_ADMIN)) return -EPERM; - spin_lock_irq(&tp->lock); + spin_lock_bh(&tp->lock); err = tg3_writephy(tp, data->reg_num & 0x1f, data->val_in); - spin_unlock_irq(&tp->lock); + spin_unlock_bh(&tp->lock); return err; @@ -7808,28 +7784,24 @@ static void tg3_vlan_rx_register(struct { struct tg3 *tp = netdev_priv(dev); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); tp->vlgrp = grp; /* Update RX_MODE_KEEP_VLAN_TAG bit in RX_MODE register. */ __tg3_set_rx_mode(dev); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); } static void tg3_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid) { struct tg3 *tp = netdev_priv(dev); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); if (tp->vlgrp) tp->vlgrp->vlan_devices[vid] = NULL; - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); } #endif @@ -10136,24 +10108,19 @@ static int tg3_suspend(struct pci_dev *p del_timer_sync(&tp->timer); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 1); tg3_disable_ints(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); netif_device_detach(dev); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); tg3_halt(tp, RESET_KIND_SHUTDOWN, 1); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); err = tg3_set_power_state(tp, pci_choose_state(pdev, state)); if (err) { - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); tg3_init_hw(tp); @@ -10163,8 +10130,7 @@ static int tg3_suspend(struct pci_dev *p netif_device_attach(dev); tg3_netif_start(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); } return err; @@ -10187,8 +10153,7 @@ static int tg3_resume(struct pci_dev *pd netif_device_attach(dev); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + tg3_full_lock(tp, 0); tg3_init_hw(tp); @@ -10199,8 +10164,7 @@ static int tg3_resume(struct pci_dev *pd tg3_netif_start(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + tg3_full_unlock(tp); return 0; } --- 1/drivers/net/tg3.h.~1~ 2005-05-30 15:29:23.000000000 -0700 +++ 2/drivers/net/tg3.h 2005-05-30 18:55:43.000000000 -0700 @@ -2006,17 +2006,33 @@ struct tg3_ethtool_stats { struct tg3 { /* begin "general, frequently-used members" cacheline section */ + /* If the IRQ handler (which runs lockless) needs to be + * quiesced, the following bitmask state is used. The + * SYNC bit is set by non-IRQ context code to initiate + * the quiescence. The setter of this bit also forces + * an interrupt to run via the GRC misc host control + * register. + * + * The IRQ handler notes this, disables interrupts, and + * sets the COMPLETE bit. At this point the SYNC bit + * setter can be assured that interrupts will no longer + * get run. + * + * In this way all SMP driver locks are never acquired + * in hw IRQ context, only sw IRQ context or lower. + */ + unsigned long irq_state; +#define TG3_IRQSTATE_SYNC 0 +#define TG3_IRQSTATE_COMPLETE 1 + /* SMP locking strategy: * * lock: Held during all operations except TX packet * processing. * - * tx_lock: Held during tg3_start_xmit{,_4gbug} and tg3_tx + * tx_lock: Held during tg3_start_xmit and tg3_tx * - * If you want to shut up all asynchronous processing you must - * acquire both locks, 'lock' taken before 'tx_lock'. IRQs must - * be disabled to take 'lock' but only softirq disabling is - * necessary for acquisition of 'tx_lock'. + * Both of these locks are to be held with BH safety. */ spinlock_t lock; spinlock_t indirect_lock; From davem@davemloft.net Tue May 31 15:51:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:51:47 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMphXq025415 for ; Tue, 31 May 2005 15:51:43 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdFZG-0005tt-3F; Tue, 31 May 2005 15:50:38 -0700 Date: Tue, 31 May 2005 15:50:37 -0700 (PDT) Message-Id: <20050531.155037.31448155.davem@davemloft.net> To: tgraf@suug.ch Cc: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [RFC] textsearch infrastructure et al v2 From: "David S. Miller" In-Reply-To: <20050531224439.GL15391@postel.suug.ch> References: <20050527224725.GG15391@postel.suug.ch> <20050531.145627.85412348.davem@davemloft.net> <20050531224439.GL15391@postel.suug.ch> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1923 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 271 Lines: 9 From: Thomas Graf Date: Wed, 1 Jun 2005 00:44:39 +0200 > Pablo joined me on the subject, he's currently working > on converting the fragmentation iteration to use Rusty's > skb_iter code. we'll present new work with some numbers > shortly. Sounds good. From davem@davemloft.net Tue May 31 15:57:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 15:57:49 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VMvkXq026361 for ; Tue, 31 May 2005 15:57:46 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdFf8-00064Q-Re; Tue, 31 May 2005 15:56:42 -0700 Date: Tue, 31 May 2005 15:56:42 -0700 (PDT) Message-Id: <20050531.155642.38710400.davem@davemloft.net> To: edgar.iglesias@axis.com Cc: netdev@oss.sgi.com Subject: Re: ipv4 ipsec From: "David S. Miller" In-Reply-To: <20050531224717.GE4068@edgar.se.axis.com> References: <20050531224717.GE4068@edgar.se.axis.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1924 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 790 Lines: 19 From: Edgar E Iglesias Date: Wed, 1 Jun 2005 00:47:17 +0200 > Im not sure this is the correct list for ipsec issues, but shouldn't > the size check at the bottom of net/ipv4/esp4.c be the other way > around (2.6.11)? You are right, good catch. Luckily the size of esp_decap_data is exactly 20 bytes, so the incorrect test happens to be harmless. > --- /usr/src/linux-2.6.11-gentoo-r8/net/ipv4/esp4.c 2005-05-11 10:05:03.000000000 +0200 > +++ esp4.c 2005-06-01 00:38:55.000000000 +0200 Please porperly -p1 root your patch so I can apply it, and also please provide a "Signed-off-by: " line for yourself as well. It may seem pointless for a one-line patch, but I want to get you and others into the habit of submitting patches properly in the future. From akpm@osdl.org Tue May 31 16:14:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 16:14:24 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VNEKXq027233 for ; Tue, 31 May 2005 16:14:21 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4VNDEjA014127 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 31 May 2005 16:13:17 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4VNDDHC019012; Tue, 31 May 2005 16:13:13 -0700 Date: Tue, 31 May 2005 16:12:20 -0700 From: Andrew Morton To: Phil Oester Cc: netdev@oss.sgi.com, herbert@gondor.apana.org.au Subject: Re: 2.6.12-rcx networking oops Message-Id: <20050531161220.4af50a69.akpm@osdl.org> In-Reply-To: <20050531224012.GA16789@linuxace.com> References: <20050531224012.GA16789@linuxace.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1925 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 627 Lines: 15 Phil Oester wrote: > > At Andrew's suggestion, I tested the latest 2.6.12-rc5-gitx, and am still > hitting an oops on a gateway box under load. From comparing the various > oops, it seems like a dev is disappearing while one CPU is in the middle > of processing traffic. At least that's what my naive analysis leads > me to believe. Are you _sure_ the hardware is good? Are you running anything which would cause netdevs to be destroyed? Bringing virtual devices up and down? TUN/TAP driver? Bonding driver? Anything like that? Have you tried CONFIG_DEBUG_SLAB and/or CONFIG_DEBUG_PAGEALLOC? From jdmason@us.ibm.com Tue May 31 16:21:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 16:21:43 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VNLcXq031367 for ; Tue, 31 May 2005 16:21:38 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4VNKh8E145216 for ; Tue, 31 May 2005 19:20:43 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4VNKhRI223050 for ; Tue, 31 May 2005 17:20:43 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4VNKgtK012958 for ; Tue, 31 May 2005 17:20:43 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4VNKgUj012955; Tue, 31 May 2005 17:20:42 -0600 From: Jon Mason Organization: IBM To: James Harr Subject: Re: r8169 802.1q/MTU bug Date: Tue, 31 May 2005 18:20:41 -0500 User-Agent: KMail/1.7.2 Cc: Francois Romieu , netdev@oss.sgi.com References: <20050530071148.GB1514@electric-eye.fr.zoreil.com> <200505301927.26110.james@grickle.org> In-Reply-To: <200505301927.26110.james@grickle.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505311820.41469.jdmason@us.ibm.com> X-archive-position: 1926 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1423 Lines: 40 On Monday 30 May 2005 07:27 pm, James Harr wrote: > Hi, > The driver you sent gives me an error when I try to compile and load it > with 2.6.11.11: > > # make > [...] > CC [M] drivers/net/r8169.o > drivers/net/r8169.c: In function `rtl8169_down': > drivers/net/r8169.c:2589: warning: implicit declaration of function > synchronize_sched > [...] > > # insmod drivers/net/r8169.ko > insmod: error inserting 'drivers/net/r8169.ko': -1 Unknown symbol in module > > > It does a similar thing when I try to install it: > > # make modules_install > [...] > if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.11.11; fi > WARNING: /lib/modules/2.6.11.11/kernel/drivers/net/r8169.ko needs unknown > symbol synchronize_sched > > As I noted in a previous email, it doesn't give me this problem when I have > jumbo frames enabled on my switch. > > Since I found out my switch supported jumbo frames, I started to toy around > with larger MTUs. When a VLAN's MTU was set to 7200, my system locked up. I > didn't have this problem at 7196. Also, the crash problem wasn't there on a > regular interface with no VLANs and the MTU at 7200. I wonder if this is related to the adapter breaking large frames into multiple descriptors. On normal (non-VLAN) frames, this happens at MTU 8169. I wonder if enabling VLAN and jumbo frames (a combination I never tried) brings down the threshold to MTU 7200. Thanks, Jon From kernel@linuxace.com Tue May 31 16:24:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 16:24:24 -0700 (PDT) Received: from linuxace.com (adsl-67-120-171-161.dsl.lsan03.pacbell.net [67.120.171.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4VNOLXq031910 for ; Tue, 31 May 2005 16:24:21 -0700 Received: (qmail 17333 invoked by uid 0); 31 May 2005 23:23:26 -0000 Date: Tue, 31 May 2005 16:23:26 -0700 From: Phil Oester To: Andrew Morton Cc: netdev@oss.sgi.com, herbert@gondor.apana.org.au Subject: Re: 2.6.12-rcx networking oops Message-ID: <20050531232326.GA17289@linuxace.com> References: <20050531224012.GA16789@linuxace.com> <20050531161220.4af50a69.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531161220.4af50a69.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-archive-position: 1927 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@linuxace.com Precedence: bulk X-list: netdev Content-Length: 822 Lines: 21 On Tue, May 31, 2005 at 04:12:20PM -0700, Andrew Morton wrote: > Are you _sure_ the hardware is good? Well, it lasts on 2.6.10 indefinitely (since 1/1/5 minus the recent upgrade attempts). And the hardware itself has been in service for a few years without failure. It will last on 2.6.11 or 12-rc over the weekend fine, but as soon as traffic picks up during the workday it keels over. > Are you running anything which would cause netdevs to be destroyed? > Bringing virtual devices up and down? TUN/TAP driver? Bonding driver? > Anything like that? The box runs keepalived (for VRRP), and quagga (for OSPF). Neither should be destroying netdevs during normal operation AFAIK. > Have you tried CONFIG_DEBUG_SLAB and/or CONFIG_DEBUG_PAGEALLOC? No - do you think it would reveal anything given the above? Phil From edgar@edgar.se.axis.com Tue May 31 16:24:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 16:24:40 -0700 (PDT) Received: from miranda.se.axis.com (miranda.se.axis.com [193.13.178.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VNOZXq031962 for ; Tue, 31 May 2005 16:24:36 -0700 Received: from edgar.se.axis.com (edgar.se.axis.com [10.92.151.1]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id j4VNNeNc013270 for ; Wed, 1 Jun 2005 01:23:40 +0200 Received: (qmail 4643 invoked by uid 400); 1 Jun 2005 01:23:40 +0200 Date: Wed, 1 Jun 2005 01:23:40 +0200 From: Edgar E Iglesias To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: ipv4 ipsec Message-ID: <20050531232340.GA4589@edgar.se.axis.com> References: <20050531224717.GE4068@edgar.se.axis.com> <20050531.155642.38710400.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531.155642.38710400.davem@davemloft.net> User-Agent: Mutt/1.5.8i X-archive-position: 1928 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: edgar.iglesias@axis.com Precedence: bulk X-list: netdev Content-Length: 1701 Lines: 49 On Tue, May 31, 2005 at 03:56:42PM -0700, David S. Miller wrote: > From: Edgar E Iglesias > Date: Wed, 1 Jun 2005 00:47:17 +0200 > > > Im not sure this is the correct list for ipsec issues, but shouldn't > > the size check at the bottom of net/ipv4/esp4.c be the other way > > around (2.6.11)? > > You are right, good catch. Luckily the size of esp_decap_data > is exactly 20 bytes, so the incorrect test happens to be harmless. mostly harmless.. But for gcc ports that create packed structs per default, it is 19 bytes. > > > --- /usr/src/linux-2.6.11-gentoo-r8/net/ipv4/esp4.c 2005-05-11 10:05:03.000000000 +0200 > > +++ esp4.c 2005-06-01 00:38:55.000000000 +0200 > > Please porperly -p1 root your patch so I can apply it, and also > please provide a "Signed-off-by: " line for yourself as well. > > It may seem pointless for a one-line patch, but I want to get you > and others into the habit of submitting patches properly in the > future. oh sorry, I hope I get it right this time :) Best regards -- Programmer Edgar E Iglesias 46.46.272.1946 Signed-off-by: Edgar E Iglesias --------- % diff -Naur linux-2.6.11-gentoo-r6/net/ipv4/esp4.c linux-2.6.11-gentoo-r9/net/ipv4/esp4.c --- linux-2.6.11-gentoo-r6/net/ipv4/esp4.c 2005-04-14 21:39:32.000000000 +0200 +++ linux-2.6.11-gentoo-r9/net/ipv4/esp4.c 2005-06-01 00:38:55.000000000 +0200 @@ -480,7 +480,7 @@ { struct xfrm_decap_state decap; - if (sizeof(struct esp_decap_data) < + if (sizeof(struct esp_decap_data) > sizeof(decap.decap_data)) { extern void decap_data_too_small(void); From jdmason@us.ibm.com Tue May 31 16:29:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 16:29:58 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VNTgXq000610 for ; Tue, 31 May 2005 16:29:48 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4VNSlmD587852 for ; Tue, 31 May 2005 19:28:47 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4VNSkmm156522 for ; Tue, 31 May 2005 17:28:46 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4VNSjbq023813 for ; Tue, 31 May 2005 17:28:46 -0600 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.53.90.32]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4VNSjBk023809; Tue, 31 May 2005 17:28:45 -0600 From: Jon Mason Organization: IBM To: "David S. Miller" Subject: Re: RFC: NAPI packet weighting patch Date: Tue, 31 May 2005 18:28:43 -0500 User-Agent: KMail/1.7.2 Cc: mitch.a.williams@intel.com, hadi@cyberus.ca, shemminger@osdl.org, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com References: <1117241786.6251.7.camel@localhost.localdomain> <200505311707.54487.jdmason@us.ibm.com> <20050531.151443.74564699.davem@davemloft.net> In-Reply-To: <20050531.151443.74564699.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505311828.44304.jdmason@us.ibm.com> X-archive-position: 1929 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1138 Lines: 26 On Tuesday 31 May 2005 05:14 pm, David S. Miller wrote: > From: Jon Mason > Date: Tue, 31 May 2005 17:07:54 -0500 > > > Of course some performace analysis would have to be done to determine the > > optimal numbers for each speed/duplexity setting per driver. > > per cpu speed, per memory bus speed, per I/O bus speed, and add in other > complications such as NUMA > > My point is that whatever experimental number you come up with will be > good for that driver on your systems, not necessarily for others. > > Even within a system, whatever number you select will be the wrong > thing to use if one starts a continuous I/O stream to the SATA > controller in the next PCI slot, for example. > > We keep getting bitten by this, as the Altix perf data continually shows, > and we need to absolutely stop thinking this way. > > The way to go is to make selections based upon observed events and > mesaurements. I'm not arguing against a /proc entry to tune dev->weight for those sysadmins advanced enough to do that. I am arguing that we can make the driver smarter (at little/no cost) for "out of the box" users. From akpm@osdl.org Tue May 31 16:30:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 16:30:36 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VNUVXq000724 for ; Tue, 31 May 2005 16:30:32 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4VNTVjA015448 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 31 May 2005 16:29:32 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j4VNTUjw019855; Tue, 31 May 2005 16:29:30 -0700 Date: Tue, 31 May 2005 16:28:37 -0700 From: Andrew Morton To: Phil Oester Cc: netdev@oss.sgi.com, herbert@gondor.apana.org.au Subject: Re: 2.6.12-rcx networking oops Message-Id: <20050531162837.4a110b29.akpm@osdl.org> In-Reply-To: <20050531232326.GA17289@linuxace.com> References: <20050531224012.GA16789@linuxace.com> <20050531161220.4af50a69.akpm@osdl.org> <20050531232326.GA17289@linuxace.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1930 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1165 Lines: 29 Phil Oester wrote: > > On Tue, May 31, 2005 at 04:12:20PM -0700, Andrew Morton wrote: > > Are you _sure_ the hardware is good? > > Well, it lasts on 2.6.10 indefinitely (since 1/1/5 minus the recent > upgrade attempts). And the hardware itself has been in service for > a few years without failure. It will last on 2.6.11 or 12-rc over > the weekend fine, but as soon as traffic picks up during the workday > it keels over. hm, OK. So I assume the machine has recently been running 2.6.10. So it's unlikely to be a hardware problem. > > Are you running anything which would cause netdevs to be destroyed? > > Bringing virtual devices up and down? TUN/TAP driver? Bonding driver? > > Anything like that? > > The box runs keepalived (for VRRP), and quagga (for OSPF). Neither should > be destroying netdevs during normal operation AFAIK. OK. It would need more than a very-ex-net person to work out how those things affect the networking stack ;) > > Have you tried CONFIG_DEBUG_SLAB and/or CONFIG_DEBUG_PAGEALLOC? > > No - do you think it would reveal anything given the above? It might catch the failure at an earlier stage. From kernel@linuxace.com Tue May 31 16:35:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 16:35:33 -0700 (PDT) Received: from linuxace.com (adsl-67-120-171-161.dsl.lsan03.pacbell.net [67.120.171.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j4VNZTXq001769 for ; Tue, 31 May 2005 16:35:30 -0700 Received: (qmail 17425 invoked by uid 0); 31 May 2005 23:34:35 -0000 Date: Tue, 31 May 2005 16:34:35 -0700 From: Phil Oester To: Andrew Morton Cc: netdev@oss.sgi.com, herbert@gondor.apana.org.au Subject: Re: 2.6.12-rcx networking oops Message-ID: <20050531233435.GA17397@linuxace.com> References: <20050531224012.GA16789@linuxace.com> <20050531161220.4af50a69.akpm@osdl.org> <20050531232326.GA17289@linuxace.com> <20050531162837.4a110b29.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531162837.4a110b29.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-archive-position: 1931 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@linuxace.com Precedence: bulk X-list: netdev Content-Length: 554 Lines: 17 On Tue, May 31, 2005 at 04:28:37PM -0700, Andrew Morton wrote: > hm, OK. So I assume the machine has recently been running 2.6.10. So it's > unlikely to be a hardware problem. It's running 2.6.10 as we speak -- I typically reboot it at night into 2.6.12-rc and between 8-10am the next day it panics itself back into 2.6.10. > > > Have you tried CONFIG_DEBUG_SLAB and/or CONFIG_DEBUG_PAGEALLOC? > > > > No - do you think it would reveal anything given the above? > > It might catch the failure at an earlier stage. I'll try it out tomorrow. Phil From davem@davemloft.net Tue May 31 16:48:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 16:48:49 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VNmjXq002650 for ; Tue, 31 May 2005 16:48:46 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdGST-00069A-Vh; Tue, 31 May 2005 16:47:42 -0700 Date: Tue, 31 May 2005 16:47:41 -0700 (PDT) Message-Id: <20050531.164741.116354448.davem@davemloft.net> To: edgar.iglesias@axis.com Cc: netdev@oss.sgi.com Subject: Re: ipv4 ipsec From: "David S. Miller" In-Reply-To: <20050531232340.GA4589@edgar.se.axis.com> References: <20050531224717.GE4068@edgar.se.axis.com> <20050531.155642.38710400.davem@davemloft.net> <20050531232340.GA4589@edgar.se.axis.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1933 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 273 Lines: 9 From: Edgar E Iglesias Date: Wed, 1 Jun 2005 01:23:40 +0200 > oh sorry, I hope I get it right this time :) Your email client has mangled the tab characters into spaces in the patch, so the patch still will not apply correctly. Please fix this. From romieu@fr.zoreil.com Tue May 31 16:47:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 16:47:59 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4VNloXq002559 for ; Tue, 31 May 2005 16:47:51 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j4VNj3x5002808; Wed, 1 Jun 2005 01:45:04 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j4VNiwMM002807; Wed, 1 Jun 2005 01:44:58 +0200 Date: Wed, 1 Jun 2005 01:44:58 +0200 From: Francois Romieu To: Jon Mason Cc: James Harr , netdev@oss.sgi.com Subject: Re: r8169 802.1q/MTU bug Message-ID: <20050531234458.GA2023@electric-eye.fr.zoreil.com> References: <20050530071148.GB1514@electric-eye.fr.zoreil.com> <200505301927.26110.james@grickle.org> <200505311820.41469.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505311820.41469.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 1932 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 647 Lines: 15 Jon Mason : [...] > I wonder if this is related to the adapter breaking large frames into > multiple descriptors. On normal (non-VLAN) frames, this happens at MTU > 8169. I wonder if enabling VLAN and jumbo frames (a combination I never > tried) brings down the threshold to MTU 7200. Testing suggests that there is at least a size filtering issue (fixed in netdev-2.6.git but not in 2.6.11.xx nor in 2.6.12-rc). It is unrelated to hardware vlan support and happens a few bytes above the MTU on the vlan device (which is set to the same value as the adapter). Of course different issues could hide in the dark. -- Ueimor From edgar@edgar.se.axis.com Tue May 31 17:03:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 17:03:59 -0700 (PDT) Received: from miranda.se.axis.com (miranda.se.axis.com [193.13.178.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5103sXq004773 for ; Tue, 31 May 2005 17:03:55 -0700 Received: from edgar.se.axis.com (edgar.se.axis.com [10.92.151.1]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id j5102xNc020780 for ; Wed, 1 Jun 2005 02:02:59 +0200 Received: (qmail 4767 invoked by uid 400); 1 Jun 2005 02:02:59 +0200 Date: Wed, 1 Jun 2005 02:02:59 +0200 From: Edgar E Iglesias To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: ipv4 ipsec Message-ID: <20050601000259.GA4742@edgar.se.axis.com> References: <20050531224717.GE4068@edgar.se.axis.com> <20050531.155642.38710400.davem@davemloft.net> <20050531232340.GA4589@edgar.se.axis.com> <20050531.164741.116354448.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531.164741.116354448.davem@davemloft.net> User-Agent: Mutt/1.5.8i X-archive-position: 1934 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: edgar.iglesias@axis.com Precedence: bulk X-list: netdev Content-Length: 903 Lines: 33 On Tue, May 31, 2005 at 04:47:41PM -0700, David S. Miller wrote: > From: Edgar E Iglesias > Date: Wed, 1 Jun 2005 01:23:40 +0200 > > > oh sorry, I hope I get it right this time :) > > Your email client has mangled the tab characters into spaces > in the patch, so the patch still will not apply correctly. > > Please fix this. One more try.. sorry Best regards -- Programmer Edgar E Iglesias 46.46.272.1946 Signed-off-by: Edgar E Iglesias ----- --- linux-2.6.11-gentoo-r6/net/ipv4/esp4.c 2005-04-14 21:39:32.000000000 +0200 +++ linux-2.6.11-gentoo-r9/net/ipv4/esp4.c 2005-06-01 00:38:55.000000000 +0200 @@ -480,7 +480,7 @@ { struct xfrm_decap_state decap; - if (sizeof(struct esp_decap_data) < + if (sizeof(struct esp_decap_data) > sizeof(decap.decap_data)) { extern void decap_data_too_small(void); From davem@davemloft.net Tue May 31 17:09:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 17:09:13 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5109AXq005428 for ; Tue, 31 May 2005 17:09:11 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdGmD-0006Eg-Fy; Tue, 31 May 2005 17:08:05 -0700 Date: Tue, 31 May 2005 17:08:05 -0700 (PDT) Message-Id: <20050531.170805.133287243.davem@davemloft.net> To: edgar.iglesias@axis.com Cc: netdev@oss.sgi.com Subject: Re: ipv4 ipsec From: "David S. Miller" In-Reply-To: <20050601000259.GA4742@edgar.se.axis.com> References: <20050531232340.GA4589@edgar.se.axis.com> <20050531.164741.116354448.davem@davemloft.net> <20050601000259.GA4742@edgar.se.axis.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1935 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 276 Lines: 7 From: Edgar E Iglesias Date: Wed, 1 Jun 2005 02:02:59 +0200 > --- linux-2.6.11-gentoo-r6/net/ipv4/esp4.c 2005-04-14 21:39:32.000000000 +0200 > +++ linux-2.6.11-gentoo-r9/net/ipv4/esp4.c 2005-06-01 00:38:55.000000000 +0200 Patch applied, thank you. From stlman@poczta.fm Tue May 31 18:12:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 18:12:19 -0700 (PDT) Received: from smtp.poczta.interia.pl (smtp2.poczta.interia.pl [213.25.80.232]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j511CCXq010251 for ; Tue, 31 May 2005 18:12:13 -0700 Received: by smtp.poczta.interia.pl (INTERIA.PL, from userid 502) id F0AEA376A86; Wed, 1 Jun 2005 03:11:14 +0200 (CEST) Received: from poczta.interia.pl (mi03.poczta.interia.pl [10.217.12.3]) by smtp.poczta.interia.pl (INTERIA.PL) with ESMTP id 947AE376A7E for ; Wed, 1 Jun 2005 03:11:14 +0200 (CEST) Received: by poczta.interia.pl (INTERIA.PL, from userid 502) id 4B7773C33F; Wed, 1 Jun 2005 03:11:14 +0200 (CEST) Received: from [10.0.0.3] (coh147.neoplus.adsl.tpnet.pl [83.31.187.147]) by www.poczta.fm (INTERIA.PL) with ESMTP id E16023C339 for ; Wed, 1 Jun 2005 03:11:13 +0200 (CEST) Message-ID: <429D0B2E.3010309@poczta.fm> Date: Wed, 01 Jun 2005 03:11:10 +0200 From: Lukasz Stelmach User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Driver for MCS7780 USB-IrDA bridge chip References: <42943CB5.50400@poczta.fm> In-Reply-To: <42943CB5.50400@poczta.fm> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD2F69C3CAEA5D906B4E0F3DA" X-EMID: 5d057138 X-archive-position: 1936 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: stlman@poczta.fm Precedence: bulk X-list: netdev Content-Length: 2020 Lines: 65 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD2F69C3CAEA5D906B4E0F3DA Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Greetings Everyone. Greg told me that you (the list) might be interested in this so I should send the announcement to you. The new, shiny 0.2alpha.3 release is ready to test it, smash it and blow it off ;-) The major improvement is support for other SIR speeds: 2400 through 115200 bps. Well I think they will work but frankly speaking I haven't tested them because my Handspring always negotiates the highest rate. I am sure there is quite a lot of bugs left so *please* test it as much as you can. I am realy convinced that performance may be a really big problem so I will appreciate any comments on the design. Source tarball is available at: http://www.ee.pw.edu.pl/~stelmacl/mcs7780-0.2alpha.3.tar.bz2 http://www.ee.pw.edu.pl/~stelmacl/mcs7780-0.2alpha.3.tar.bz2.asc (sig) or http://stlman.fm.interia.pl/mcs7780-0.2alpha.3.tar.bz2 http://stlman.fm.interia.pl/mcs7780-0.2alpha.3.tar.bz2.asc (sig) To answer your question: I will make a patch but let me first be sure it is usable and at least beta-stable. You can help ;-) This is the announcement of the 0.1alpha.1 version: http://lkml.org/lkml/2005/5/25/47 Always yours. --=20 By=B3o mi bardzo mi=B3o. Trzecia pospolita kl=EAska, [= =2E..] >=A3ukasz< Ju=BF nie katolicka lecz z=B3odziejska. = (c)PP --------------enigD2F69C3CAEA5D906B4E0F3DA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCnQsuNdzY8sm9K9wRAlRBAJ0Vpuw04ROL/5KjfYpBwDpJYrEn0wCfQUyZ DMqTjLmN1wgpJsPSujRmZDE= =7yn/ -----END PGP SIGNATURE----- --------------enigD2F69C3CAEA5D906B4E0F3DA-- From hch@lst.de Tue May 31 22:22:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 22:23:03 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j515MsXq005410 for ; Tue, 31 May 2005 22:22:55 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j515Lo6t011954 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Jun 2005 07:21:50 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j515LocY011952; Wed, 1 Jun 2005 07:21:50 +0200 Date: Wed, 1 Jun 2005 07:21:50 +0200 From: Christoph Hellwig To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] shaper.c: fix locking Message-ID: <20050601052149.GA11935@lst.de> References: <20050527115450.GA19469@lst.de> <20050531.144114.78710204.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531.144114.78710204.davem@davemloft.net> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1937 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 703 Lines: 16 On Tue, May 31, 2005 at 02:41:14PM -0700, David S. Miller wrote: > From: Christoph Hellwig > Subject: [PATCH] shaper.c: fix locking > Date: Fri, 27 May 2005 13:54:50 +0200 > > > o use a semaphore instead of an opencoded and racy lock > > o move locking out of shaper_kick and into the callers - most just > > released the lock before calling shaper_kick > > o remove in_interrupt() tests. from ->close we can always block, from > > ->hard_start_xmit and timer context never > > Do you really want to use a semaphore for a lock taken > %99 of the time in software IRQ context, which obviously > cannot sleep? I want to change as little as possible from the previous variant ;-) From herbert@gondor.apana.org.au Tue May 31 22:50:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 22:51:04 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j515ouXq008592 for ; Tue, 31 May 2005 22:50:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DdM74-0003Zz-00; Wed, 01 Jun 2005 15:49:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DdM71-0000gn-00; Wed, 01 Jun 2005 15:49:55 +1000 Date: Wed, 1 Jun 2005 15:49:55 +1000 To: Phil Oester Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: 2.6.12-rcx networking oops Message-ID: <20050601054955.GA2625@gondor.apana.org.au> References: <20050531224012.GA16789@linuxace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531224012.GA16789@linuxace.com> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1938 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 684 Lines: 16 On Tue, May 31, 2005 at 03:40:12PM -0700, Phil Oester wrote: > > EIP is at fib_validate_source+0xcf/0x1f0 > eax: f7c2c000 ebx: c0337dec ecx: f7c258a0 edx: 00000000 > esi: c0335c2c edi: 00000000 ebp: c0337db0 esp: c0337d40 > ds: 3f1f es: 007b ss: 0068 > Process swapper (pid: 0, threadinfo=c0337000 task=c02b9bc0) This looks like stack overflow. %esi is meant to be "res" which is a local variable. As you can see, it's pointing below %esp and threadinfo. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ak@muc.de Tue May 31 23:29:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 31 May 2005 23:29:21 -0700 (PDT) Received: from one.firstfloor.org ([213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j516TCXq011416 for ; Tue, 31 May 2005 23:29:13 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id DB291D033E; Wed, 1 Jun 2005 08:28:04 +0200 (CEST) To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: Locking model for NAPI drivers References: <20050531.154847.63995530.davem@davemloft.net> From: Andi Kleen Date: Wed, 01 Jun 2005 08:28:04 +0200 In-Reply-To: <20050531.154847.63995530.davem@davemloft.net> (David S. Miller's message of "Tue, 31 May 2005 15:48:47 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 754 Lines: 23 "David S. Miller" writes: Stupid question, but... > I was doing some brainstorming to try and fix a nagging problem in > the tg3 driver which suggested that doing the SMP locking differently > might be the best and cleanest solution. > > The tg3 problem is that it can do an skb_copy() in HW IRQ disabled > context which is illegal. That is because of the kmap_atomic it does right? At least in the i386 highmem implementation I don't see any code that would be less safe in hard interrupt context compared to BHs. And FRV and mips look like they allow it too. > This fixes the skb_copy() we were doing with hw > IRQs disabled (which is illegal and triggers a > BUG() with HIGHMEM enabled). Which BUG did it trigger? -Andi