Re: current status of ixg(4)
On 2015/04/14 17:22, Masanobu SAITOH wrote: On 2015/04/10 4:26, 6b...@6bone.informatik.uni-leipzig.de wrote: On Wed, 8 Apr 2015, SAITOH Masanobu wrote: Use new one: http://www.netbsd.org/~msaitoh/ixg-20150407-1.dif After a first test, it looks as if the interrupt throttling now works (better). Thanks. I committed the diff. I also committed a change that ifconfig -z didn't work. Regards Uwe New one: http://www.netbsd.org/~msaitoh/ixg-20150414-0.dif - Sync ixg(4) up to FreeBSD r250108: - Cleanup some unused counters and some unused code. - Improve performance. - Fix flow control - don't override user value on re-init - Fix to make 1G optics work correctly - Change to interrupt enabling - some bits were incorrect for certain hardware. - Certain stats fixes, remove a duplicate increment of ierror, thanks to Scott Long for pointing these out. - Fix the setting of RX which related to multicast. - Some netmap related fixes. - Committed. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On 2015/04/10 4:26, 6b...@6bone.informatik.uni-leipzig.de wrote: On Wed, 8 Apr 2015, SAITOH Masanobu wrote: Use new one: http://www.netbsd.org/~msaitoh/ixg-20150407-1.dif After a first test, it looks as if the interrupt throttling now works (better). Thanks. I committed the diff. I also committed a change that ifconfig -z didn't work. Regards Uwe New one: http://www.netbsd.org/~msaitoh/ixg-20150414-0.dif - Sync ixg(4) up to FreeBSD r250108: - Cleanup some unused counters and some unused code. - Improve performance. - Fix flow control - don't override user value on re-init - Fix to make 1G optics work correctly - Change to interrupt enabling - some bits were incorrect for certain hardware. - Certain stats fixes, remove a duplicate increment of ierror, thanks to Scott Long for pointing these out. - Fix the setting of RX which related to multicast. - Some netmap related fixes. - -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On Tue, 7 Apr 2015, Justin Cormack wrote: Try the sysctls, there is a maximum interrupt rate, hw.ixgbe.max_interrupt_rate Justin Sure that the value exists at netbsd? # sysctl -a | grep ixg0 net.interfaces.ixg0.sndq.len = 0 net.interfaces.ixg0.sndq.maxlen = 2046 net.interfaces.ixg0.sndq.drops = 0 hw.ixg0.num_rx_desc = 2048 hw.ixg0.num_queues = 1 hw.ixg0.fc = 3 hw.ixg0.enable_aim = 1 hw.ixg0.advertise_speed = 0 hw.ixg0.ts = 0 hw.ixg0.rx_processing_limit = 256 hw.ixg0.queue0.interrupt_rate = 2000 hw.ixg0.queue0.irqs = 8053816 hw.ixg0.queue0.txd_head = 1872 hw.ixg0.queue0.txd_tail = 1872 hw.ixg0.queue0.rxd_head = 159 hw.ixg0.queue0.rxd_tail = 158 Regards Uwe
Re: current status of ixg(4)
On Wed, 8 Apr 2015, SAITOH Masanobu wrote: Use new one: http://www.netbsd.org/~msaitoh/ixg-20150407-1.dif After a first test, it looks as if the interrupt throttling now works (better). Regards Uwe
Re: current status of ixg(4)
On 2015/03/27 16:03, Masanobu SAITOH wrote: New patch: http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif New patch: http://www.netbsd.org/~msaitoh/ixg-20150407-0.dif -- Sync ixg(4) up to FreeBSD r243716: - A lot of bugfixes. Some of them are realted to multi queue and those have not affected in NetBSD because we have not used it yet. - Show 1000Base-SX correctly. - Fix if_baudrate from 1G to 10G. - Improve performance. -- -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On 31 March 2015 at 14:38, 6b...@6bone.informatik.uni-leipzig.de wrote: On Fri, 27 Mar 2015, Masanobu SAITOH wrote: This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif I have tested the patch and found no problems. My server (HP G5) can handle with the new driver package rates up to 200,000 packets per second. Then CPU0 is running at 100% with interrupts. If I have not charged me, it comes with 200,000 packets per second and an MTU of 1500 bytes to a maximum of 2.4GB. Is it possible to optimize some parameters for the interrupt throttling? Try the sysctls, there is a maximum interrupt rate, hw.ixgbe.max_interrupt_rate Justin
Re: current status of ixg(4)
On 2015/04/07 21:02, SAITOH Masanobu wrote: On 2015/03/27 16:03, Masanobu SAITOH wrote: New patch: http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif New patch: Sorry, I overrided with broken ixgbe.c before making the diff. Use new one: http://www.netbsd.org/~msaitoh/ixg-20150407-1.dif -- Sync ixg(4) up to FreeBSD r243716: - A lot of bugfixes. Some of them are realted to multi queue and those have not affected in NetBSD because we have not used it yet. - Show 1000Base-SX correctly. - Fix if_baudrate from 1G to 10G. - Improve performance. -- -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On 2015/04/02 18:13, Masanobu SAITOH wrote: On 2015/04/02 0:01, Thor Lancelot Simon wrote: On Tue, Mar 31, 2015 at 03:38:45PM +0200, 6b...@6bone.informatik.uni-leipzig.de wrote: On Fri, 27 Mar 2015, Masanobu SAITOH wrote: This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif I have tested the patch and found no problems. Thanks. I'll commit that diff. My server (HP G5) can handle with the new driver package rates up to 200,000 packets per second. Then CPU0 is running at 100% with interrupts. If I have not charged me, it comes with 200,000 packets per second and an MTU of 1500 bytes to a maximum of 2.4GB. Is it possible to optimize some parameters for the interrupt throttling? I think for your workload you may actually want interrupt distribution over multiple CPUs. But we have some support for that in -current now, right? The next thing you're likely to run into is contention for the kernel lock in ip_input. But if I recall correctlly how this driver's built, I don't think you should be seeing that time charged to the interrupt handler, so I *think* you are not there yet. Thor It's correct what tls@ said. For ixg(4), it has multiqueue support, but it's not enabled because NetBSD-current has not MSI/MSI-X support yet. The remaining is to merge knakahara@'s MSI/MSI-X support and use the API. The change would be merged in a few weeks. For layer 2, NET_MPSAFE enables the MP capability. For layer 3, it's now working in progress. For the detail about NET_MPSAFE and MSI/MSI-X, see Ryota Ozaki and Kengo Nakahara's paper and presentations in AsiaBSDCon 2015: http://www.netbsd.org/gallery/presentations/ There are some graphs from page 60 to 63 in their slides. Other than NET_MPSAFE and MSI/MSI-X, ixg(4) still have a room to improve the performance. I have not merged all of FreeBSD's change yet. I checked all changes and I knew there were some changes that I have not merged yet. Thanks. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On 2015/04/02 0:01, Thor Lancelot Simon wrote: On Tue, Mar 31, 2015 at 03:38:45PM +0200, 6b...@6bone.informatik.uni-leipzig.de wrote: On Fri, 27 Mar 2015, Masanobu SAITOH wrote: This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif I have tested the patch and found no problems. Thanks. I'll commit that diff. My server (HP G5) can handle with the new driver package rates up to 200,000 packets per second. Then CPU0 is running at 100% with interrupts. If I have not charged me, it comes with 200,000 packets per second and an MTU of 1500 bytes to a maximum of 2.4GB. Is it possible to optimize some parameters for the interrupt throttling? I think for your workload you may actually want interrupt distribution over multiple CPUs. But we have some support for that in -current now, right? The next thing you're likely to run into is contention for the kernel lock in ip_input. But if I recall correctlly how this driver's built, I don't think you should be seeing that time charged to the interrupt handler, so I *think* you are not there yet. Thor It's correct what tls@ said. For ixg(4), it has multiqueue support, but it's not enabled because NetBSD-current has not MSI/MSI-X support yet. The remaining is to merge knakahara@'s MSI/MSI-X support and use the API. The change would be merged in a few weeks. For layer 2, NET_MPSAFE enables the MP capability. For layer 3, it's now working in progress. For the detail about NET_MPSAFE and MSI/MSI-X, see Ryota Ozaki and Kengo Nakahara's paper and presentations in AsiaBSDCon 2015: http://www.netbsd.org/gallery/presentations/ Other than NET_MPSAFE and MSI/MSI-X, ixg(4) still have a room to improve the performance. I have not merged all of FreeBSD's change yet. I checked all changes and I knew there were some changes that I have not merged yet. Thanks. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On Tue, Mar 31, 2015 at 03:38:45PM +0200, 6b...@6bone.informatik.uni-leipzig.de wrote: On Fri, 27 Mar 2015, Masanobu SAITOH wrote: This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif I have tested the patch and found no problems. My server (HP G5) can handle with the new driver package rates up to 200,000 packets per second. Then CPU0 is running at 100% with interrupts. If I have not charged me, it comes with 200,000 packets per second and an MTU of 1500 bytes to a maximum of 2.4GB. Is it possible to optimize some parameters for the interrupt throttling? I think for your workload you may actually want interrupt distribution over multiple CPUs. But we have some support for that in -current now, right? The next thing you're likely to run into is contention for the kernel lock in ip_input. But if I recall correctlly how this driver's built, I don't think you should be seeing that time charged to the interrupt handler, so I *think* you are not there yet. Thor
Re: current status of ixg(4)
On Fri, 27 Mar 2015, Masanobu SAITOH wrote: This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif I have tested the patch and found no problems. My server (HP G5) can handle with the new driver package rates up to 200,000 packets per second. Then CPU0 is running at 100% with interrupts. If I have not charged me, it comes with 200,000 packets per second and an MTU of 1500 bytes to a maximum of 2.4GB. Is it possible to optimize some parameters for the interrupt throttling? Regards Uwe
Re: current status of ixg(4)
New patch: http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif This change synchronizes our ixg(4) driver up to FreeBSD r38149: - Add TSO6 support. - The max size in dma tag is changed from 65535 to 262140 (IXGBE_TSO_SIZE). The value is the same as other *BSDs. The change might cause a address space shortage (ixgbe_dmamap_create() might fail) on some machines. - Fix a lot of bugs. - Improve performance. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On 2015/03/27 16:03, Masanobu SAITOH wrote: New patch: http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif This change synchronizes our ixg(4) driver up to FreeBSD r38149: s/38149/238149/ - Add TSO6 support. - The max size in dma tag is changed from 65535 to 262140 (IXGBE_TSO_SIZE). The value is the same as other *BSDs. The change might cause a address space shortage (ixgbe_dmamap_create() might fail) on some machines. - Fix a lot of bugs. - Improve performance. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On Wed, 25 Mar 2015, SAITOH Masanobu wrote: Did you really applied this patch? Upps... I tried to apply the patch against the -current sources where I have applied http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif before # patch vlan.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: ixgbe.c |=== |RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ixgbe.c,v |retrieving revision 1.14.2.2 |diff -u -p -r1.14.2.2 ixgbe.c |--- ixgbe.c24 Feb 2015 10:41:09 -1.14.2.2 |+++ ixgbe.c23 Mar 2015 07:32:50 - -- Patching file ixgbe.c using Plan A... Hunk #1 failed at 1064. 1 out of 1 hunks failed--saving rejects to ixgbe.c.rej Hmm... Ignoring the trailing garbage. done So you are right. The patch was not applied. If I add the code manuelly it works perfekt! Thank you. Regards Uwe
Re: current status of ixg(4)
On 2015/03/25 21:18, 6b...@6bone.informatik.uni-leipzig.de wrote: (snip) So you are right. The patch was not applied. If I add the code manuelly it works perfekt! Thank you. You're welcome. I'll send pullup requests to netbsd-7 and netbsd-6. Regards Uwe -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
Hi. On 2015/03/24 7:05, 6b...@6bone.informatik.uni-leipzig.de wrote: On Mon, 23 Mar 2015, Masanobu SAITOH wrote: Is this problem filed PR? If not, could you file a PR? Could you test with this patch? The path dosn't solve the problem. Did you really applied this patch? Index: ixgbe.c === RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ixgbe.c,v retrieving revision 1.14.2.2 diff -u -p -r1.14.2.2 ixgbe.c --- ixgbe.c24 Feb 2015 10:41:09 -1.14.2.2 +++ ixgbe.c23 Mar 2015 07:32:50 - @@ -1064,6 +1064,9 @@ ixgbe_ifflags_cb(struct ethercom *ec) else if ((change (IFF_PROMISC | IFF_ALLMULTI)) != 0) ixgbe_set_promisc(adapter); +/* Set up VLAN support and filter */ +ixgbe_setup_vlan_hw_support(adapter); + IXGBE_CORE_UNLOCK(adapter); return rc; Here the requested information: HW: 023:00:0: Intel 82599 (SFP+) 10 GbE Controller (ethernet network, revision 0x01) 023:00:1: Intel 82599 (SFP+) 10 GbE Controller (ethernet network, revision 0x01) Driver: ixg0 at pci14 dev 0 function 0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 ixg0: interrupting at ioapic0 pin 19 ixg0: PCI Express Bus: Speed 2.5Gb/s Width x8 ixg1 at pci14 dev 0 function 1: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 ixg1: interrupting at ioapic0 pin 16 ifmedia_match: multiple match for 0x20/0xfff, selected instance 0 ixg1: PCI Express Bus: Speed 2.5Gb/s Width x8 One of my card is: 011:00:0: Intel 82599 (SFI/SFP+) 10 GbE Controller (ethernet network, revision 0x01) It's the same as yours. ifconfig: ixg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 capabilities=bff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx capabilities=bff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx capabilities=bff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,LRO enabled=0 ec_capabilities=7VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU ec_enabled=7VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU address: a0:36:9f:26:95:04 media: Ethernet autoselect (10GbaseSR full-duplex) status: active input: 64405 packets, 5192777 bytes, 700 multicasts, 2459 unknown protocol output: 7 packets, 1138 bytes, 3 multicasts inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 inet6 fe80::a236:9fff:fe26:9504%ixg0 prefixlen 64 scopeid 0x1 vlan8: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 capabilities=3ff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx capabilities=3ff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx capabilities=3ff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx enabled=0 vlan: 8 parent: ixg0 address: a0:36:9f:26:95:04 input: 0 packets, 0 bytes output: 3 packets, 250 bytes, 3 multicasts inet6 fe80::a236:9fff:fe26:9504%vlan8 prefixlen 64 scopeid 0x4 You can see, the input counter is 0. tcpdump -i vlan8 shows no packets. But tcpdump -evi ixg0 shows tagged packets for vlan 8: e.g.: 23:26:13.880538 a2:de:48:00:00:0e ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 8, p 0, ethertype ARP, Request who-has 139.18.13.212 tell 139.18.13.254, length 46 On my machine: ixg1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 capabilities=fff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx capabilities=fff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx capabilities=fff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6,LRO enabled=0 ec_capabilities=7VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU ec_enabled=7VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU address: 00:1b:21:9b:4e:d6 media: Ethernet autoselect (1000baseT full-duplex) status: active input: 3 packets, 284 bytes output: 14 packets, 1244 bytes, 5 multicasts inet6 fe80::21b:21ff:fe9b:4ed6%ixg1 prefixlen 64 scopeid 0x4 vlan8: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 capabilities=7ff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx capabilities=7ff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx capabilities=7ff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6 enabled=0 vlan: 8 parent: ixg1 address: 00:1b:21:9b:4e:d6 input: 3 packets, 260 bytes output: 9 packets, 702 bytes, 5 multicasts inet 10.0.0.2 netmask 0xff00 broadcast 10.255.255.255 inet6 fe80::21b:21ff:fe9b:4ed6%vlan8 prefixlen 64 scopeid 0x6 and ping 10.0.0.2 from other machine makes vlan8's input counter increments. Could you test again? Thank you for your efforts Regards Uwe -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
Hi, Uwe. but I found a problem with vlan interfaces. You can create a vlan interface with: ifconfig vlan8 create ifconfig vlan8 vlan 8 vlanif ixg0 up The interface is generated. But there are no packages. ifconfig -v shows no inbound packets. tcpdump on ixg0 but indicates tagged packets for VLAN8. The problem also existed with the previous ixg driver. With wm interfaces, the problem does not seem to exist. Is this problem filed PR? If not, could you file a PR? Could you test with this patch? Index: ixgbe.c === RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ixgbe.c,v retrieving revision 1.14.2.2 diff -u -p -r1.14.2.2 ixgbe.c --- ixgbe.c 24 Feb 2015 10:41:09 - 1.14.2.2 +++ ixgbe.c 23 Mar 2015 07:32:50 - @@ -1064,6 +1064,9 @@ ixgbe_ifflags_cb(struct ethercom *ec) else if ((change (IFF_PROMISC | IFF_ALLMULTI)) != 0) ixgbe_set_promisc(adapter); + /* Set up VLAN support and filter */ + ixgbe_setup_vlan_hw_support(adapter); + IXGBE_CORE_UNLOCK(adapter); return rc; -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On Mon, 23 Mar 2015, Masanobu SAITOH wrote: Is this problem filed PR? If not, could you file a PR? Could you test with this patch? The path dosn't solve the problem. Here the requested information: HW: 023:00:0: Intel 82599 (SFP+) 10 GbE Controller (ethernet network, revision 0x01) 023:00:1: Intel 82599 (SFP+) 10 GbE Controller (ethernet network, revision 0x01) Driver: ixg0 at pci14 dev 0 function 0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 ixg0: interrupting at ioapic0 pin 19 ixg0: PCI Express Bus: Speed 2.5Gb/s Width x8 ixg1 at pci14 dev 0 function 1: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 ixg1: interrupting at ioapic0 pin 16 ifmedia_match: multiple match for 0x20/0xfff, selected instance 0 ixg1: PCI Express Bus: Speed 2.5Gb/s Width x8 ifconfig: ixg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 capabilities=bff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx capabilities=bff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx capabilities=bff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,LRO enabled=0 ec_capabilities=7VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU ec_enabled=7VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU address: a0:36:9f:26:95:04 media: Ethernet autoselect (10GbaseSR full-duplex) status: active input: 64405 packets, 5192777 bytes, 700 multicasts, 2459 unknown protocol output: 7 packets, 1138 bytes, 3 multicasts inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 inet6 fe80::a236:9fff:fe26:9504%ixg0 prefixlen 64 scopeid 0x1 vlan8: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 capabilities=3ff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx capabilities=3ff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx capabilities=3ff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx enabled=0 vlan: 8 parent: ixg0 address: a0:36:9f:26:95:04 input: 0 packets, 0 bytes output: 3 packets, 250 bytes, 3 multicasts inet6 fe80::a236:9fff:fe26:9504%vlan8 prefixlen 64 scopeid 0x4 You can see, the input counter is 0. tcpdump -i vlan8 shows no packets. But tcpdump -evi ixg0 shows tagged packets for vlan 8: e.g.: 23:26:13.880538 a2:de:48:00:00:0e ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 8, p 0, ethertype ARP, Request who-has 139.18.13.212 tell 139.18.13.254, length 46 Thank you for your efforts Regards Uwe
Re: current status of ixg(4)
On 2015/03/22 2:20, 6b...@6bone.informatik.uni-leipzig.de wrote: On Sat, 21 Mar 2015, SAITOH Masanobu wrote: New patch: http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif Could you try with this patch again? Now the patch works, BTW, what card(or chip) does your machine have? X540, 82599 or 82598? but I found a problem with vlan interfaces. You can create a vlan interface with: ifconfig vlan8 create ifconfig vlan8 vlan 8 vlanif ixg0 up The interface is generated. But there are no packages. ifconfig -v shows no inbound packets. tcpdump on ixg0 but indicates tagged packets for VLAN8. The problem also existed with the previous ixg driver. With wm interfaces, the problem does not seem to exist. Is this problem filed PR? If not, could you file a PR? Thanks. Regards Uwe -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: current status of ixg(4)
On Fri, 20 Mar 2015, Masanobu SAITOH wrote: Date: Fri, 20 Mar 2015 17:38:03 +0900 From: Masanobu SAITOH msai...@execsw.org To: current-users@NetBSD.org Cc: msai...@execsw.org Subject: current status of ixg(4) Hello. Yesterday, I commited some changes to ixg(4) on -current. http://mail-index.netbsd.org/source-changes/2015/03/19/msg064110.html I'll wait for a few days to wait feedback of this change. And then I'll send pullup request to pullup-7@. I have applied the patch on -current. The build fails with: ixgbe_api.o: In function `ixgbe_init_shared_code': ixgbe_api.c:(.text+0x16d): undefined reference to `ixgbe_init_ops_X540' Regards Uwe
Re: current status of ixg(4)
On Sat, 21 Mar 2015, SAITOH Masanobu wrote: New patch: http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif Could you try with this patch again? Now the patch works, but I found a problem with vlan interfaces. You can create a vlan interface with: ifconfig vlan8 create ifconfig vlan8 vlan 8 vlanif ixg0 up The interface is generated. But there are no packages. ifconfig -v shows no inbound packets. tcpdump on ixg0 but indicates tagged packets for VLAN8. The problem also existed with the previous ixg driver. With wm interfaces, the problem does not seem to exist. Regards Uwe
Re: current status of ixg(4)
Hi. On 2015/03/21 18:55, 6b...@6bone.informatik.uni-leipzig.de wrote: On Fri, 20 Mar 2015, Masanobu SAITOH wrote: Date: Fri, 20 Mar 2015 17:38:03 +0900 From: Masanobu SAITOH msai...@execsw.org To: current-users@NetBSD.org Cc: msai...@execsw.org Subject: current status of ixg(4) Hello. Yesterday, I commited some changes to ixg(4) on -current. http://mail-index.netbsd.org/source-changes/2015/03/19/msg064110.html I'll wait for a few days to wait feedback of this change. And then I'll send pullup request to pullup-7@. I have applied the patch on -current. The build fails with: ixgbe_api.o: In function `ixgbe_init_shared_code': ixgbe_api.c:(.text+0x16d): undefined reference to `ixgbe_init_ops_X540' Regards Uwe Sorry, I forgot to add a diff of files.pci. New patch: http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif Could you try with this patch again? -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
current status of ixg(4)
Hello. Yesterday, I commited some changes to ixg(4) on -current. http://mail-index.netbsd.org/source-changes/2015/03/19/msg064110.html I'll wait for a few days to wait feedback of this change. And then I'll send pullup request to pullup-7@. And, I made a patch to support Intel X540: http://www.netbsd.org/~msaitoh/ixg-20150320-0.dif This change syncronizes our ixg(4) driver up to FreeBSD r230775. It's still very old though... It's not tested well and it'll take a few or more days to sync with the latest FreeBSD driver. Any feedback are welcome! -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
