From owner-freebsd-net@freebsd.org Sun Jan 24 00:11:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C3C3A8FCE6 for ; Sun, 24 Jan 2016 00:11:05 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A581C1C00 for ; Sun, 24 Jan 2016 00:11:04 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lb0-x22d.google.com with SMTP id bc4so58002020lbc.2 for ; Sat, 23 Jan 2016 16:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=jLmmoXb2IOFBQrET2mmoY8WJes5i7xps4vtIyT9pE+o=; b=0wNYM5YAnjO8pgPBfVRFffleOfpEq8MdvtWHw5G6bdQBgDpxUUWibvW+SJkL5HXNrx hzO3hhBvo809IZB5fgWILH+C3TcCwDxbjybEf01YRXFs3rxk+pmir3o0mPZR5Eg1Aqbb 4ylTxKBHD29uJ6MgOwcFrnFTRXO40I8Em0CxGSnht0/mKZByAtGbMzVHA31F8V9GV3oA e9qwGYUJtRn34PAQguuIyLf88NHz/XLQAtDprRpiS3iqXcpnF4EL9z+zuVxOzEBTaIVD jlmSN5OilSbMSDsWEKscVG9D9NN5iY6n8SGLS9Qb3pnK8KoxyCpwf5jT5f7NH98JVsIc Mr7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=jLmmoXb2IOFBQrET2mmoY8WJes5i7xps4vtIyT9pE+o=; b=Iy0NSCaxDeXZWTHTavqoc160GgkNbip6PzgVuqeJOxcs0RF7o2ZH9GoeSpFtSxQyMz 5YRNUhme97OVw+2Q8N6FYuKxQLNNpJGOd2XbqQ4eSgwiSuRs/bMMCbysa7+S7V2aQlPB ri8iukUAwQmZ32yAzjV9FHXTu29BZFNPFJ86efK9OzJmNzOpiyLyTqDQQuqBQIub8rOC jhTVHGA7LCB2jQkmI7q+QpUJkbbeqAgT6t+2isf7as/nrUW6hS7v1mvipBdv3OaJ22H9 eScUmTGXNjlBqNjOrePY3Wphn9qReiEAI7R2FGuOrrzFhLEKPABhLJrNdEAA0JVED8x2 Tn+Q== X-Gm-Message-State: AG10YOStoIKKYrU1vVQSbwITVntdxrDlB/2NdrER93W0MBZ2n6rqWlgdxSLUv5DJv6SGjXHlvy4jGEj24tqiRw== MIME-Version: 1.0 X-Received: by 10.112.13.99 with SMTP id g3mr3655273lbc.86.1453594262329; Sat, 23 Jan 2016 16:11:02 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Sat, 23 Jan 2016 16:11:02 -0800 (PST) In-Reply-To: <20160123211816.GE4574@ox> References: <20160123053428.2091EA0121@smtp.hushmail.com> <20160123154052.GA4574@ox> <20160123171300.0F448A0121@smtp.hushmail.com> <20160123174840.32B1DA0121@smtp.hushmail.com> <20160123183836.GB4574@ox> <20160123211816.GE4574@ox> Date: Sat, 23 Jan 2016 16:11:02 -0800 X-Google-Sender-Auth: 6syN4Knu_ev6hngJqRlrLzMYJ-4 Message-ID: Subject: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: Luigi Rizzo To: Luigi Rizzo , Marcus Cenzatti , "freebsd-net@freebsd.org" , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 00:11:05 -0000 On Sat, Jan 23, 2016 at 1:18 PM, Navdeep Parhar wrote: > On Sat, Jan 23, 2016 at 11:12:28AM -0800, Luigi Rizzo wrote: >> On Sat, Jan 23, 2016 at 10:38 AM, Navdeep Parhar wrote: >> > On Sat, Jan 23, 2016 at 03:48:39PM -0200, Marcus Cenzatti wrote: >> > ... >> >> >> >> woops, my bad, yes probably we had some drop, with -S and -D now I get 1.2Mpps. >> > >> > Run "netstat -hdw1 -i cxl" on the receiver during your test. >> >> Navdeep, does this give any info on the ncxl port rather >> than the cxl port connected to the host stack ? > > You're right, it should have been "netstat -hdw 1 -I ncxl". In these > kinds of experiments it might even be best to run two netstats in > parallel on cxl and ncxl. > >> >> ... >> > Do you know if the transmitter will pad up so as not to put runts on the >> > wire? If not then you might want to bump up the size of the frame >> > explicitly (there's some pkt-gen knob for this). >> > >> >> ix/ixl do automatic padding, and in any case pkt-gen >> by default generates valid packet sizes (and so it does >> with the variable-size tests I suggested). >> >> Is there any parameter that controls interrupt moderation ? >> >> In any case we need to know the numbers when sending to the >> ncxl MAC address as opposed to broadcast. >> >> I suspects one of these problems: >> >> - the interrupt moderation interval is too long thus limiting >> the rate to one ring/interval. Unlikely though, even >> with 1k slots, the measured 1.2 Mpps corresponds to almost >> 1ms which is too long >> >> - the receiver cannot cope with the input load and somehow >> takes a long time to recover from congestion. If this is >> the case, running the sender at a lower rate might reach >> a peak throughput > 1.2 Mpps when the receiver can still >> keep up, and then drop to the low rate under congestion. >> >> - and of course bus errors, when the device is connected on >> a PCIe slot with only 1-2 data lanes. >> This actually happens a lot, physical connector sizes >> do not reflect the number of active PCIe lanes. > > There are no drops or PAUSE or any sign of backpressure. The netstat > counters show 900K incoming and 0 drops/errors, which means 900K packets > on the wire for the port and all were delivered to the driver > successfully. I am not 100% convinced by the above explanation, both because of the way the experiment was conducted (broadcast destination, duplication in the hw to two queues, stats only from cxl0 and not ncxl0), and because sending to the unicast DMAC already showed a higher throughput. So I suspect the 900k counter does not actually reflect packets on the wire. Where and how the drops are counted I have no idea (presumably some internal counter in the NIC, but for broadcast traffic replicated to multiple queues I don't know which counter tracks the drop - one per queue, a global one, etc. > The mismatch in the transmitter's counter and the incoming counter can > only be explained by > a) Frames whose DMAC address didn't match the local interface's MAC. the DMAC was the same for all frames. > This can be tested by switching cxl0 and ncxl0 to promisc mode to see if > that opens the flood gates. > b) Frames mangled badly enough to be discarded. But these should show > as an error or drop in at least one of these: > > sysctl dev.cxl..stats > sysctl -n dev.t5nex.0.misc.tp_err_stats one question -- do the sysctl for cxl. and t5nex.0 also report the ncxl* stats, or you have a separate entry for those ? cheers luigi From owner-freebsd-net@freebsd.org Sun Jan 24 02:40:43 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 061DCA84774 for ; Sun, 24 Jan 2016 02:40:43 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D184210D9 for ; Sun, 24 Jan 2016 02:40:42 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 866BF20110 for ; Sun, 24 Jan 2016 02:40:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=bnjE/uItxKnhZch0CeCauk0HWGS/J/tRiSCFamHnJ68=; b=uj/RLuyLOC+L9EdVv7rPHfVMhUuqBrNoR4r7Lb3xidlocAPXGE2cU6QMMErswmmSQUYCuzlI0H6kW5rc3T5QY2e0zzGp6ZFuGOUVy66jx5exTx3jULC7xAjXSl0lWx7JIDnQHgJ9C3EoxLShetfcOep6drkLcNWN7wU2aMFTqFZlTuCctIWz0qtKT4/WVVjFPy+bpjNug8qW8yzBxsswdIC0fF66SsOnN/4g0Ajzj5srVN2POq3aU2KpPoE4l0zICe9VFk3+PHvcqXTDT4SIT/4Djb1J3LFi0CAm/LfSjfilFj0pg22UNIOrg3QAkV/9kw4imsEmKeIpcmPimgtZ+Q== Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP; Sun, 24 Jan 2016 02:40:40 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 128A2A0128; Sun, 24 Jan 2016 02:40:40 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 24 Jan 2016 00:40:39 -0200 To: "Luigi Rizzo" , freebsd-net@freebsd.org, "Navdeep Parhar" Subject: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: "Marcus Cenzatti" In-Reply-To: References: <20160123053428.2091EA0121@smtp.hushmail.com> <20160123154052.GA4574@ox> <20160123171300.0F448A0121@smtp.hushmail.com> <20160123174840.32B1DA0121@smtp.hushmail.com> <20160123183836.GB4574@ox> <20160123211816.GE4574@ox> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20160124024040.128A2A0128@smtp.hushmail.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 02:40:43 -0000 On 1/23/2016 at 10:11 PM, "Luigi Rizzo" wrote: > >On Sat, Jan 23, 2016 at 1:18 PM, Navdeep Parhar > wrote: >> On Sat, Jan 23, 2016 at 11:12:28AM -0800, Luigi Rizzo wrote: >>> On Sat, Jan 23, 2016 at 10:38 AM, Navdeep Parhar > wrote: >>> > On Sat, Jan 23, 2016 at 03:48:39PM -0200, Marcus Cenzatti >wrote: >>> > ... >>> >> >>> >> woops, my bad, yes probably we had some drop, with -S and -D >now I get 1.2Mpps. >>> > >>> > Run "netstat -hdw1 -i cxl" on the receiver during your >test. >>> >>> Navdeep, does this give any info on the ncxl port rather >>> than the cxl port connected to the host stack ? >> >> You're right, it should have been "netstat -hdw 1 -I ncxl". >In these >> kinds of experiments it might even be best to run two netstats in >> parallel on cxl and ncxl. >> >>> >>> ... >>> > Do you know if the transmitter will pad up so as not to put >runts on the >>> > wire? If not then you might want to bump up the size of the >frame >>> > explicitly (there's some pkt-gen knob for this). >>> > >>> >>> ix/ixl do automatic padding, and in any case pkt-gen >>> by default generates valid packet sizes (and so it does >>> with the variable-size tests I suggested). >>> >>> Is there any parameter that controls interrupt moderation ? >>> >>> In any case we need to know the numbers when sending to the >>> ncxl MAC address as opposed to broadcast. >>> >>> I suspects one of these problems: >>> >>> - the interrupt moderation interval is too long thus limiting >>> the rate to one ring/interval. Unlikely though, even >>> with 1k slots, the measured 1.2 Mpps corresponds to almost >>> 1ms which is too long >>> >>> - the receiver cannot cope with the input load and somehow >>> takes a long time to recover from congestion. If this is >>> the case, running the sender at a lower rate might reach >>> a peak throughput > 1.2 Mpps when the receiver can still >>> keep up, and then drop to the low rate under congestion. >>> >>> - and of course bus errors, when the device is connected on >>> a PCIe slot with only 1-2 data lanes. >>> This actually happens a lot, physical connector sizes >>> do not reflect the number of active PCIe lanes. >> >> There are no drops or PAUSE or any sign of backpressure. The >netstat >> counters show 900K incoming and 0 drops/errors, which means 900K >packets >> on the wire for the port and all were delivered to the driver >> successfully. > >I am not 100% convinced by the above explanation, both because >of the way the experiment was conducted (broadcast >destination, duplication in the hw to two queues, >stats only from cxl0 and not ncxl0), and because sending >to the unicast DMAC already showed a higher throughput. > >So I suspect the 900k counter does not actually reflect >packets on the wire. Where and how the drops are counted >I have no idea (presumably some internal counter in the NIC, >but for broadcast traffic replicated to multiple queues >I don't know which counter tracks the drop - one per queue, >a global one, etc. > > >> The mismatch in the transmitter's counter and the incoming >counter can >> only be explained by >> a) Frames whose DMAC address didn't match the local interface's >MAC. > >the DMAC was the same for all frames. > >> This can be tested by switching cxl0 and ncxl0 to promisc mode >to see if >> that opens the flood gates. >> b) Frames mangled badly enough to be discarded. But these >should show >> as an error or drop in at least one of these: >> >> sysctl dev.cxl..stats >> sysctl -n dev.t5nex.0.misc.tp_err_stats > >one question -- do the sysctl for cxl. and t5nex.0 >also report the ncxl* stats, or you have a separate entry >for those ? > >cheers >luigi dear gentlemen, i started over in the end of the day, rebooted everything and removed all tweeks (had no sysctl tweeks on the previous output but had removed tx|rx csum and tso from both intel and chelsio). mr Adrian Chadd suggested to shut cxl0 down but if I ifconfig cxl0 down both cxl0 and ncxl0 will be down, anyway I removed IP address from cxl0 and let only ncxl0 addressed. I have new numbers: - MAC address based tests: 14Mpps TX => 11Mpps RX (much better, finally, but still lower than Intel-Intel, not a problem at all) - IP address based tests: 14Mpps TX => 300Kpps RX (kernel rate possibly, but on netmap mode, why? a problem for sure) on both experiments we actually had no error pointed on netstat or sysctls, and actual RX speed observed on netstat on the second test was 15Mpps. here is the full transcript for the two session tests with stats outputs. things i could not understand are: 1) on mac address tests the sender (tx) pkt-gen shows: Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:07:e9:44:d2:ba -> 00:07:43:33:8d:c1) where those ip addresses come from? same is observed on rx: 529.477028 extract_ip_range [291] range is 10.0.0.1:0 to 10.0.0.1:0 529.477042 extract_ip_range [291] range is 10.1.0.1:0 to 10.1.0.1:0 2) on ip address tests, the sender (tx/intel) pkt-gen shows: 172.16.0.2 -> 172.16.0.1 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) does this mean we are transmitting to broadcast? the receiver (chelsio/tx) shows this, that makes much more sense: 500.757057 main [1715] interface is ncxl0 500.757321 extract_ip_range [291] range is 172.16.0.2:0 to 172.16.0.2:0 500.757348 extract_ip_range [291] range is 172.16.0.1:0 to 172.16.0.1:0 501.007425 main [1910] mapped 334980KB at 0x801c00000 so I could not explain why I had 800Kpps rates on chelsio when I had that tweeks and after rebooting i have a much more decent 11Mpps rate but i could confirm, if I remove the tweeks I get 800K-1.2M pps again on MAC address tests. since cxl0 is not addressed and ncxl0 will only work in netmap mode i believe it will never arp reply, therefore the netmap application should arp reply when someone arp requests the actual mac address for a given ip address, will pkt-gen arp reply? because this could, maybe, explain the destination part for 00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff (but source mac address should be correct) just to remember, when I test intel-intel I get the same 14Mpps RX and TX rates on both IP address test as well as my previously wrong (using -s|-d instead of -S|-D pkt-gen options) mac address tests, but i don't remember if mac address were shown like that luigi, the sysctl you asked navdeep about, sysctl dev.ncxl.0.stats, does not exist, only sysctl dev.cxl.0.stats exists and I could not find other stats similar to dev.t5nex.0.misc.tp_err_stats so probably it's not different betweek cxl and ncxl ==== FULL TESTS TRANSCRIPT ==== intel# ifconfig -v ix0 ix0: flags=8843 metric 0 mtu 1500 options=8406b8 ether 00:07:e9:44:d2:ba inet 172.16.0.2 netmask 0xffffff00 broadcast 172.16.0.255 nd6 options=29 media: Ethernet 10Gbase-SR (10Gbase-SR ) status: active plugged: SFP/SFP+/SFP28 10G Base-SR (LC) vendor: FINISAR CORP. PN: FTLX8571D3BCL-FC SN: AM31TRU DATE: 2012-01-21 module temperature: 34.98 C Voltage: 3.28 Volts RX: 0.50 mW (-2.98 dBm) TX: 0.58 mW (-2.33 dBm) intel# ./pkt-gen -i ix0 -f tx -S 00:07:e9:44:d2:ba -D 00:07:43:33:8d:c1 268.505741 main [1715] interface is ix0 268.505795 extract_ip_range [291] range is 10.0.0.1:0 to 10.0.0.1:0 268.505806 extract_ip_range [291] range is 10.1.0.1:0 to 10.1.0.1:0 268.611395 main [1910] mapped 334980KB at 0x801c00000 Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:07:e9:44:d2:ba -> 00:07:43:33:8d:c1) 268.611467 main [1994] Sending 512 packets every 0.000000000 s 268.611473 main [1996] Wait 2 secs for phy reset 270.617971 main [1998] Ready... 270.618120 nm_open [456] overriding ifname ix0 ringid 0x0 flags 0x1 270.635480 sender_body [1073] start, fd 4 main_fd 3 270.670823 sender_body [1142] drop copy 271.637012 main_thread [1512] 14461469 pps (14484000 pkts in 1001558 usec) 272.647011 main_thread [1512] 14880527 pps (15029317 pkts in 1009999 usec) 273.648511 main_thread [1512] 14884638 pps (14906965 pkts in 1001500 usec) 274.649506 main_thread [1512] 14883795 pps (14898619 pkts in 1000996 usec) 275.650509 main_thread [1512] 14879377 pps (14894301 pkts in 1001003 usec) 276.651511 main_thread [1512] 14883276 pps (14898174 pkts in 1001001 usec) 277.652512 main_thread [1512] 14880941 pps (14895852 pkts in 1001002 usec) 278.653517 main_thread [1512] 14879125 pps (14894079 pkts in 1001005 usec) 279.654525 main_thread [1512] 14887529 pps (14902431 pkts in 1001001 usec) 280.656518 main_thread [1512] 14864554 pps (14894268 pkts in 1001999 usec) 281.657012 main_thread [1512] 14882656 pps (14890008 pkts in 1000494 usec) 282.658506 main_thread [1512] 14881346 pps (14903594 pkts in 1001495 usec) 283.664016 main_thread [1512] 14882829 pps (14964819 pkts in 1005509 usec) 284.690513 main_thread [1512] 14880361 pps (15274661 pkts in 1026498 usec) 285.691504 main_thread [1512] 14877683 pps (14892412 pkts in 1000990 usec) 286.692143 main_thread [1512] 14885234 pps (14894761 pkts in 1000640 usec) 287.693510 main_thread [1512] 14885267 pps (14905615 pkts in 1001367 usec) 288.694010 main_thread [1512] 14879692 pps (14887132 pkts in 1000500 usec) ^C289.189696 sigint_h [328] received control-C on thread 0x801806800 289.189750 sender_body [1171] flush tail 19 head 19 on thread 0x801806800 289.189790 sender_body [1179] pending tx tail 72 head 1105 on ring 0 289.189823 sender_body [1179] pending tx tail 154 head 1105 on ring 0 289.189848 sender_body [1179] pending tx tail 222 head 1105 on ring 0 289.189871 sender_body [1179] pending tx tail 274 head 1105 on ring 0 289.189901 sender_body [1179] pending tx tail 338 head 1105 on ring 0 289.700237 main_thread [1512] 7332017 pps (7377666 pkts in 1006226 usec) Sent 275688674 packets, 60 bytes each, in 18.55 seconds. Speed: 14.86 Mpps Bandwidth: 7.13 Gbps (raw 9.98 Gbps) intel# chelsio# ./pkt-gen -i ncxl0 -f rx -S 00:07:e9:44:d2:ba -D 00:07:43:33:8d:c1 529.476963 main [1715] interface is ncxl0 529.477028 extract_ip_range [291] range is 10.0.0.1:0 to 10.0.0.1:0 529.477042 extract_ip_range [291] range is 10.1.0.1:0 to 10.1.0.1:0 529.535750 main [1910] mapped 334980KB at 0x801c00000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 529.535829 main [1996] Wait 2 secs for phy reset 531.537267 main [1998] Ready... 531.537399 nm_open [456] overriding ifname ncxl0 ringid 0x0 flags 0x1 531.555050 receiver_body [1247] reading from netmap:ncxl0 fd 4 main_fd 3 532.555628 main_thread [1512] 11173691 pps (11180373 pkts in 1000598 usec) 533.556129 main_thread [1512] 11175384 pps (11180983 pkts in 1000501 usec) 534.567273 main_thread [1512] 11176345 pps (11300905 pkts in 1011145 usec) 535.568126 main_thread [1512] 11175813 pps (11185335 pkts in 1000852 usec) 536.569623 main_thread [1512] 11174668 pps (11191408 pkts in 1001498 usec) 537.580127 main_thread [1512] 11176569 pps (11293968 pkts in 1010504 usec) (..) 739.193065 main_thread [1512] 11173118 pps (11177744 pkts in 1000414 usec) 740.194062 main_thread [1512] 11175690 pps (11186832 pkts in 1000997 usec) 741.202063 main_thread [1512] 11176354 pps (11265776 pkts in 1008001 usec) 742.203564 main_thread [1512] 11176509 pps (11193296 pkts in 1001502 usec) 743.204559 main_thread [1512] 11175825 pps (11186945 pkts in 1000995 usec) ^C743.392524 sigint_h [328] received control-C on thread 0x801806800 744.212517 main_thread [1512] 2080802 pps (2097359 pkts in 1007957 usec) Received 2367310284 packets, in 211.84 seconds. Speed: 11.18 Mpps chelsio# netstat -hd -I ncxl0 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop ncxl0 1.5K 00:07:43:33:8d:c1 0 0 0 0 0 0 0 ncxl0 - 172.16.0.0 172.16.0.1 158M - - 0 - - - chelsio# netstat -hd -I cxl0 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop cxl0 1.5K 00:07:43:33:8d:c0 7.1G 0 669M 0 0 0 0 chelsio# netstat -hdwi 1 -l ncxl0 input (Total) output packets errs idrops bytes packets errs bytes colls drops 15M 0 3.7M 908M 4 0 660 0 0 15M 0 3.7M 908M 4 0 612 0 0 15M 0 3.7M 908M 4 0 612 0 0 15M 0 3.7M 908M 4 0 612 0 0 15M 0 3.7M 908M 4 0 612 0 0 15M 0 3.7M 908M 9 0 1.2K 0 0 15M 0 3.7M 908M 6 0 1.1K 0 0 15M 0 3.7M 908M 4 0 612 0 0 ^C chelsio# netstat -hdwi 1 -l cxl0 input (Total) output packets errs idrops bytes packets errs bytes colls drops 15M 0 3.7M 908M 4 0 660 0 0 15M 0 3.7M 908M 4 0 612 0 0 15M 0 3.7M 908M 6 0 763 0 0 15M 0 3.7M 908M 4 0 612 0 0 15M 0 3.7M 908M 4 0 612 0 0 15M 0 3.7M 908M 9 0 1.0K 0 0 ^C chelsio# netstat -hd -I ncxl0 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop ncxl0 1.5K 00:07:43:33:8d:c1 0 0 0 0 0 0 0 ncxl0 - 172.16.0.0 172.16.0.1 39M - - 0 - - - chelsio# chelsio# netstat -hd -I cxl0 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop cxl0 1.5K 00:07:43:33:8d:c0 6.0G 1 612k 0 0 0 0 chelsio# netstat -hdwi 1 -l ncxl0 input (Total) output packets errs idrops bytes packets errs bytes colls drops 15M 0 0 908M 8 0 1.1K 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 15 0 1.8K 0 0 15M 0 0 908M 10 0 1.2K 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 6 0 822 0 0 15M 0 0 908M 6 0 826 0 0 ^C chelsio# netstat -hdwi 1 -l cxl0 input (Total) output packets errs idrops bytes packets errs bytes colls drops 15M 0 0 908M 8 0 1.0K 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 5 0 756 0 0 15M 0 0 908M 10 0 1.2K 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 4 0 604 0 0 ^C chelsio# sysctl -n dev.t5nex.0.misc.tp_err_stats channel 0 channel 1 channel 2 channel 3 macInErrs: 0 0 0 0 hdrInErrs: 0 0 0 0 tcpInErrs: 0 0 0 0 tcp6InErrs: 0 0 0 0 tnlCongDrops: 42862617 0 0 0 tnlTxDrops: 0 0 0 0 ofldVlanDrops: 0 0 0 0 ofldChanDrops: 0 0 0 0 ofldNoNeigh: 0 ofldCongDefer: 0 chelsio# sysctl dev.cxl.0.stats dev.cxl.0.stats.rx_trunc3: 0 dev.cxl.0.stats.rx_trunc2: 0 dev.cxl.0.stats.rx_trunc1: 0 dev.cxl.0.stats.rx_trunc0: 0 dev.cxl.0.stats.rx_ovflow3: 0 dev.cxl.0.stats.rx_ovflow2: 0 dev.cxl.0.stats.rx_ovflow1: 0 dev.cxl.0.stats.rx_ovflow0: 853083783 dev.cxl.0.stats.rx_ppp7: 0 dev.cxl.0.stats.rx_ppp6: 0 dev.cxl.0.stats.rx_ppp5: 0 dev.cxl.0.stats.rx_ppp4: 0 dev.cxl.0.stats.rx_ppp3: 0 dev.cxl.0.stats.rx_ppp2: 0 dev.cxl.0.stats.rx_ppp1: 0 dev.cxl.0.stats.rx_ppp0: 0 dev.cxl.0.stats.rx_pause: 0 dev.cxl.0.stats.rx_frames_1519_max: 0 dev.cxl.0.stats.rx_frames_1024_1518: 0 dev.cxl.0.stats.rx_frames_512_1023: 0 dev.cxl.0.stats.rx_frames_256_511: 0 dev.cxl.0.stats.rx_frames_128_255: 0 dev.cxl.0.stats.rx_frames_65_127: 0 dev.cxl.0.stats.rx_frames_64: 9778077198 dev.cxl.0.stats.rx_runt: 0 dev.cxl.0.stats.rx_symbol_err: 0 dev.cxl.0.stats.rx_len_err: 0 dev.cxl.0.stats.rx_fcs_err: 0 dev.cxl.0.stats.rx_jabber: 0 dev.cxl.0.stats.rx_too_long: 0 dev.cxl.0.stats.rx_ucast_frames: 5365842946 dev.cxl.0.stats.rx_mcast_frames: 0 dev.cxl.0.stats.rx_bcast_frames: 4412237958 dev.cxl.0.stats.rx_frames: 9778082382 dev.cxl.0.stats.rx_octets: 625797304704 dev.cxl.0.stats.tx_ppp7: 0 dev.cxl.0.stats.tx_ppp6: 0 dev.cxl.0.stats.tx_ppp5: 0 dev.cxl.0.stats.tx_ppp4: 0 dev.cxl.0.stats.tx_ppp3: 0 dev.cxl.0.stats.tx_ppp2: 0 dev.cxl.0.stats.tx_ppp1: 0 dev.cxl.0.stats.tx_ppp0: 0 dev.cxl.0.stats.tx_pause: 0 dev.cxl.0.stats.tx_drop: 0 dev.cxl.0.stats.tx_frames_1519_max: 0 dev.cxl.0.stats.tx_frames_1024_1518: 0 dev.cxl.0.stats.tx_frames_512_1023: 0 dev.cxl.0.stats.tx_frames_256_511: 0 dev.cxl.0.stats.tx_frames_128_255: 0 dev.cxl.0.stats.tx_frames_65_127: 0 dev.cxl.0.stats.tx_frames_64: 0 dev.cxl.0.stats.tx_error_frames: 0 dev.cxl.0.stats.tx_ucast_frames: 0 dev.cxl.0.stats.tx_mcast_frames: 0 dev.cxl.0.stats.tx_bcast_frames: 0 dev.cxl.0.stats.tx_frames: 0 dev.cxl.0.stats.tx_octets: 0 dev.cxl.0.stats.tx_parse_error: 0 chelsio# sysctl dev.ncxl.0.stats ===> IP based tests: intel# ./pkt-gen -i ix0 -f tx -s 172.16.0.2 -d 172.16.0.1 150.673411 main [1715] interface is ix0 150.673545 extract_ip_range [291] range is 172.16.0.2:0 to 172.16.0.2:0 150.673560 extract_ip_range [291] range is 172.16.0.1:0 to 172.16.0.1:0 150.779091 main [1910] mapped 334980KB at 0x801c00000 Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. 172.16.0.2 -> 172.16.0.1 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) 150.779164 main [1994] Sending 512 packets every 0.000000000 s 150.779169 main [1996] Wait 2 secs for phy reset 152.846385 main [1998] Ready... 152.846515 nm_open [456] overriding ifname ix0 ringid 0x0 flags 0x1 152.863946 sender_body [1073] start, fd 4 main_fd 3 152.898386 sender_body [1142] drop copy 153.864749 main_thread [1512] 14477663 pps (14489636 pkts in 1000827 usec) 154.868750 main_thread [1512] 14879784 pps (14939318 pkts in 1004001 usec) 155.873246 main_thread [1512] 14883091 pps (14950005 pkts in 1004496 usec) 156.874753 main_thread [1512] 14883859 pps (14906289 pkts in 1001507 usec) (...) chelsio# ./pkt-gen -i ncxl0 -f rx -s 172.16.0.2 -d 172.16.0.1 500.757057 main [1715] interface is ncxl0 500.757321 extract_ip_range [291] range is 172.16.0.2:0 to 172.16.0.2:0 500.757348 extract_ip_range [291] range is 172.16.0.1:0 to 172.16.0.1:0 501.007425 main [1910] mapped 334980KB at 0x801c00000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 501.007511 main [1996] Wait 2 secs for phy reset 503.015342 main [1998] Ready... 503.015487 nm_open [456] overriding ifname ncxl0 ringid 0x0 flags 0x1 503.033543 receiver_body [1247] reading from netmap:ncxl0 fd 4 main_fd 3 504.034782 main_thread [1512] 303341 pps (303727 pkts in 1001273 usec) 505.035783 main_thread [1512] 301714 pps (302016 pkts in 1001000 usec) 506.036779 main_thread [1512] 302355 pps (302656 pkts in 1000996 usec) 507.037780 main_thread [1512] 301651 pps (301953 pkts in 1001002 usec) 508.038783 main_thread [1512] 301922 pps (302225 pkts in 1001002 usec) 509.039780 main_thread [1512] 301633 pps (301934 pkts in 1000997 usec) 510.040776 main_thread [1512] 304081 pps (304384 pkts in 1000996 usec) 511.043280 main_thread [1512] 305602 pps (306367 pkts in 1002504 usec) 512.044780 main_thread [1512] 305207 pps (305665 pkts in 1001500 usec) 513.045780 main_thread [1512] 305103 pps (305408 pkts in 1001001 usec) 514.056282 main_thread [1512] 304894 pps (308096 pkts in 1010502 usec) 515.057781 main_thread [1512] 305015 pps (305472 pkts in 1001499 usec) 516.058780 main_thread [1512] 305935 pps (306240 pkts in 1000998 usec) 517.066781 main_thread [1512] 305333 pps (307776 pkts in 1008001 usec) 518.073779 main_thread [1512] 304556 pps (306688 pkts in 1006999 usec) 519.081781 main_thread [1512] 304190 pps (306624 pkts in 1008002 usec) 520.087780 main_thread [1512] 304351 pps (306177 pkts in 1005998 usec) 521.088778 main_thread [1512] 305102 pps (305407 pkts in 1000999 usec) 522.089775 main_thread [1512] 305232 pps (305536 pkts in 1000997 usec) 523.090281 main_thread [1512] 305606 pps (305760 pkts in 1000505 usec) 524.091280 main_thread [1512] 305391 pps (305696 pkts in 1000999 usec) 525.093787 main_thread [1512] 305986 pps (306753 pkts in 1002507 usec) 526.101276 main_thread [1512] 305424 pps (307711 pkts in 1007489 usec) 527.102772 main_thread [1512] 305272 pps (305729 pkts in 1001496 usec) 528.106277 main_thread [1512] 305122 pps (306192 pkts in 1003506 usec) 529.107778 main_thread [1512] 305253 pps (305711 pkts in 1001501 usec) 523.090281 main_thread [1512] 305606 pps (305760 pkts in 1000505 usec) 524.091280 main_thread [1512] 305391 pps (305696 pkts in 1000999 usec) 525.093787 main_thread [1512] 305986 pps (306753 pkts in 1002507 usec) 526.101276 main_thread [1512] 305424 pps (307711 pkts in 1007489 usec) 527.102772 main_thread [1512] 305272 pps (305729 pkts in 1001496 usec) 528.106277 main_thread [1512] 305122 pps (306192 pkts in 1003506 usec) 529.107778 main_thread [1512] 305253 pps (305711 pkts in 1001501 usec) 530.110774 main_thread [1512] 304432 pps (305344 pkts in 1002995 usec) 531.111774 main_thread [1512] 304847 pps (305152 pkts in 1001000 usec) 532.115782 main_thread [1512] 305209 pps (306432 pkts in 1004008 usec) 533.122273 main_thread [1512] 305092 pps (307072 pkts in 1006491 usec) 534.129776 main_thread [1512] 304277 pps (306560 pkts in 1007504 usec) 535.130272 main_thread [1512] 305193 pps (305344 pkts in 1000496 usec) 536.135271 main_thread [1512] 304414 pps (305936 pkts in 1004999 usec) 537.136272 main_thread [1512] 305279 pps (305584 pkts in 1001000 usec) 538.137772 main_thread [1512] 305334 pps (305792 pkts in 1001500 usec) 539.138606 main_thread [1512] 304897 pps (305152 pkts in 1000835 usec) 540.140772 main_thread [1512] 305195 pps (305856 pkts in 1002165 usec) 541.148272 main_thread [1512] 304786 pps (307072 pkts in 1007501 usec) 542.149770 main_thread [1512] 304773 pps (305230 pkts in 1001498 usec) 543.153270 main_thread [1512] 305859 pps (306930 pkts in 1003500 usec) 544.154357 main_thread [1512] 305014 pps (305345 pkts in 1001086 usec) 545.156774 main_thread [1512] 304990 pps (305727 pkts in 1002418 usec) ^C546.157076 sigint_h [328] received control-C on thread 0x801806800 546.157273 main_thread [1512] 305512 pps (305664 pkts in 1000499 usec) Received 13138095 packets, in 43.12 seconds. Speed: 304.66 Kpps chelsio# netstat -hd -I ncxl0 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop ncxl0 1.5K 00:07:43:33:8d:c1 0 0 0 0 0 0 0 ncxl0 - 172.16.0.0 172.16.0.1 39M - - 0 - - - chelsio# chelsio# netstat -hd -I cxl0 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop cxl0 1.5K 00:07:43:33:8d:c0 6.0G 1 612k 0 0 0 0 chelsio# netstat -hdwi 1 -l ncxl0 input (Total) output packets errs idrops bytes packets errs bytes colls drops 15M 0 0 908M 8 0 1.1K 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 15 0 1.8K 0 0 15M 0 0 908M 10 0 1.2K 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 6 0 822 0 0 15M 0 0 908M 6 0 826 0 0 ^C chelsio# netstat -hdwi 1 -l cxl0 input (Total) output packets errs idrops bytes packets errs bytes colls drops 15M 0 0 908M 8 0 1.0K 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 5 0 756 0 0 15M 0 0 908M 10 0 1.2K 0 0 15M 0 0 908M 4 0 604 0 0 15M 0 0 908M 4 0 604 0 0 ^C chelsio# sysctl -n dev.t5nex.0.misc.tp_err_stats channel 0 channel 1 channel 2 channel 3 macInErrs: 0 0 0 0 hdrInErrs: 0 0 0 0 tcpInErrs: 0 0 0 0 tcp6InErrs: 0 0 0 0 tnlCongDrops: 612276 0 0 0 tnlTxDrops: 0 0 0 0 ofldVlanDrops: 0 0 0 0 ofldChanDrops: 0 0 0 0 ofldNoNeigh: 0 ofldCongDefer: 0 chelsio# sysctl dev.ncxl.0.stats sysctl: unknown oid 'dev.ncxl.0.stats' Exit 1 chelsio# sysctl dev.cxl.0.stats dev.cxl.0.stats.rx_trunc3: 0 dev.cxl.0.stats.rx_trunc2: 0 dev.cxl.0.stats.rx_trunc1: 0 dev.cxl.0.stats.rx_trunc0: 0 dev.cxl.0.stats.rx_ovflow3: 0 dev.cxl.0.stats.rx_ovflow2: 0 dev.cxl.0.stats.rx_ovflow1: 0 dev.cxl.0.stats.rx_ovflow0: 0 dev.cxl.0.stats.rx_ppp7: 0 dev.cxl.0.stats.rx_ppp6: 0 dev.cxl.0.stats.rx_ppp5: 0 dev.cxl.0.stats.rx_ppp4: 0 dev.cxl.0.stats.rx_ppp3: 0 dev.cxl.0.stats.rx_ppp2: 0 dev.cxl.0.stats.rx_ppp1: 0 dev.cxl.0.stats.rx_ppp0: 0 dev.cxl.0.stats.rx_pause: 0 dev.cxl.0.stats.rx_frames_1519_max: 0 dev.cxl.0.stats.rx_frames_1024_1518: 0 dev.cxl.0.stats.rx_frames_512_1023: 0 dev.cxl.0.stats.rx_frames_256_511: 0 dev.cxl.0.stats.rx_frames_128_255: 0 dev.cxl.0.stats.rx_frames_65_127: 0 dev.cxl.0.stats.rx_frames_64: 8216274634 dev.cxl.0.stats.rx_runt: 0 dev.cxl.0.stats.rx_symbol_err: 0 dev.cxl.0.stats.rx_len_err: 0 dev.cxl.0.stats.rx_fcs_err: 1 dev.cxl.0.stats.rx_jabber: 0 dev.cxl.0.stats.rx_too_long: 0 dev.cxl.0.stats.rx_ucast_frames: 0 dev.cxl.0.stats.rx_mcast_frames: 0 dev.cxl.0.stats.rx_bcast_frames: 8216279461 dev.cxl.0.stats.rx_frames: 8216280197 dev.cxl.0.stats.rx_octets: 525841964992 dev.cxl.0.stats.tx_ppp7: 0 dev.cxl.0.stats.tx_ppp6: 0 dev.cxl.0.stats.tx_ppp5: 0 dev.cxl.0.stats.tx_ppp4: 0 dev.cxl.0.stats.tx_ppp3: 0 dev.cxl.0.stats.tx_ppp2: 0 dev.cxl.0.stats.tx_ppp1: 0 dev.cxl.0.stats.tx_ppp0: 0 dev.cxl.0.stats.tx_pause: 0 dev.cxl.0.stats.tx_drop: 0 dev.cxl.0.stats.tx_frames_1519_max: 0 dev.cxl.0.stats.tx_frames_1024_1518: 0 dev.cxl.0.stats.tx_frames_512_1023: 0 dev.cxl.0.stats.tx_frames_256_511: 0 dev.cxl.0.stats.tx_frames_128_255: 0 dev.cxl.0.stats.tx_frames_65_127: 0 dev.cxl.0.stats.tx_frames_64: 0 dev.cxl.0.stats.tx_error_frames: 0 dev.cxl.0.stats.tx_ucast_frames: 0 dev.cxl.0.stats.tx_mcast_frames: 0 dev.cxl.0.stats.tx_bcast_frames: 0 dev.cxl.0.stats.tx_frames: 0 dev.cxl.0.stats.tx_octets: 0 dev.cxl.0.stats.tx_parse_error: 0 From owner-freebsd-net@freebsd.org Sun Jan 24 03:10:37 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EF2EA8E3FB for ; Sun, 24 Jan 2016 03:10:37 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B068153F for ; Sun, 24 Jan 2016 03:10:36 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id h129so67830709lfh.3 for ; Sat, 23 Jan 2016 19:10:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Et7TgLDEZLuYCiuK4gVaB+sNlse+aBviKQxPHBAL9H4=; b=HnpYZJtOzxhhRPbQ8nQu1v7S2To0jC6B6HTe2vEjw0Ga7YBGba5M6w1kyR60wl5xfy lCpfYN6JyEuopIcY14C8/MztJyujAlFGHofFF0boMHzD68aszZFlzIUy2l7Z9+qADqmg jF0SJOZCX49ogOaxFWoVr7/BVbj1X5zhtOMqf3RtTfWn1zvQ8SXDUV0cIcjsbYIqFUfh 8BPKGPO1+wCeGKASLEfKzTy3Ow+ykUMHSxnbUv1OhPgFwcQpfEr68Pdnxaan3aLbwb5b vKtkF+QtLue8/ksbrsFe6rkc9dwFjEG7YElR3eewyvODrtjtyRYjJL9Q1iqwYje/Zsn8 GC4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; bh=Et7TgLDEZLuYCiuK4gVaB+sNlse+aBviKQxPHBAL9H4=; b=ghvAnMYCWwt2W75Q44TKuFERHiGNgvXCtictnB5qeYJlmXZURHoXDPNk3B39cYaWb8 0k8UFwJ/7To1SNnuu1w4FfTuMRHXMK+FJhoKPbeHLI4DOLdZFTbyFIwo2uOf5LK6P+yR Lcf5Ybi6W0iErHiXv1RA8lfiYmffXOHiHh0JILvclxs6a+ZLZgq2bg8UBL6574q0OZMi SeH4XClNk373ppB+EzFGe2oEIpYvxtoS9woFubSAxlxIcwdEPFSkdiv4Ockncdl31JyI II2ThrIk9/pXkl/XT5/dhEHbDwFNGSeh+2fh7YEOWCUcGTq+6+Z2Wlt2k5WsDMbP7aJv Fwfg== X-Gm-Message-State: AG10YOS3Nkb6kuvCl7Ah80BjAMsjDUuARH/PLr7xrKuwwNBXW59wDlqV8syAEIHAK1JGWzbZkMlsBaeZWwXlqw== MIME-Version: 1.0 X-Received: by 10.25.29.193 with SMTP id d184mr3985857lfd.28.1453605033197; Sat, 23 Jan 2016 19:10:33 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Sat, 23 Jan 2016 19:10:33 -0800 (PST) Date: Sat, 23 Jan 2016 19:10:33 -0800 X-Google-Sender-Auth: BhS8xR4XnDgL7txKgifT07sn9ZA Message-ID: Subject: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: Luigi Rizzo To: Marcus Cenzatti Cc: "freebsd-net@freebsd.org" , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 03:10:37 -0000 Thanks for re-running the experiments. I am changing the subject so that in the archives it is clear that the chelsio card works fine. Overall the tests confirm that whenever you hit the host stack you are boun= d to the poor performance of the latter. The problem does not appear using in= tel as a receiver because on the intel card netmap mode disables the host stack= . More comments on the experiments: The only meaningful test is the one where you use the DMAC of the ncxl0 por= t: SENDER: ./pkt-gen -i ix0 -f tx -S 00:07:e9:44:d2:ba -D 00:07:43:33:8d:c= 1 in the other experiment you transmit broadcast frames and hit the network s= tack. ARP etc do not matter since tx and rx are directly connected. On the receiver you do not need to specify addresses: RECEIVER: ./pkt-gen -i ncxl0 -f rx The numbers in netstat are clearly rounded, so 15M is probably 14.88M (line rate), and 3.7M that you see correctly represents the difference between incoming and received packets. The fact that you see drops may be related to the NIC being unable to replenish the queue fast enough, which in turn may be a hardware or a software (netmap) issue. You may try experiment with shorter batches on the receive side (say, -b 64 or less) and see if you have better results. A short batch replenishes the rx queue more frequently, but it is not a conclusive experiment because there is an optimization in the netmap poll code which, as an unintended side effect, replenishes the queue less often than it should. For a conclusive experiment you should grab the netmap code from github.com/luigirizzo/netmap and use pkt-gen-b which uses busy wait and works around the poll "optimization" thanks again for investigating the issue. cheers luigi On Sat, Jan 23, 2016 at 6:40 PM, Marcus Cenzatti wrote: > > > > dear gentlemen, > > i started over in the end of the day, rebooted everything and removed all= tweeks (had no sysctl tweeks on the previous output but had removed tx|rx = csum and tso from both intel and chelsio). > > mr Adrian Chadd suggested to shut cxl0 down but if I ifconfig cxl0 down b= oth cxl0 and ncxl0 will be down, anyway I removed IP address from cxl0 and = let only ncxl0 addressed. > > I have new numbers: > > - MAC address based tests: 14Mpps TX =3D> 11Mpps RX (much better, finally= , but still lower than Intel-Intel, not a problem at all) > - IP address based tests: 14Mpps TX =3D> 300Kpps RX (kernel rate possibly= , but on netmap mode, why? a problem for sure) > > on both experiments we actually had no error pointed on netstat or sysctl= s, and actual RX speed observed on netstat on the second test was 15Mpps. > > here is the full transcript for the two session tests with stats outputs. > > things i could not understand are: > > 1) on mac address tests the sender (tx) pkt-gen shows: > > Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. > 10.0.0.1 -> 10.1.0.1 (00:07:e9:44:d2:ba -> 00:07:43:33:8d:c1) > > where those ip addresses come from? same is observed on rx: > > 529.477028 extract_ip_range [291] range is 10.0.0.1:0 to 10.0.0.1:0 > 529.477042 extract_ip_range [291] range is 10.1.0.1:0 to 10.1.0.1:0 > > 2) on ip address tests, the sender (tx/intel) pkt-gen shows: > > 172.16.0.2 -> 172.16.0.1 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) > > does this mean we are transmitting to broadcast? > > the receiver (chelsio/tx) shows this, that makes much more sense: > > 500.757057 main [1715] interface is ncxl0 > 500.757321 extract_ip_range [291] range is 172.16.0.2:0 to 172.16.0.2:0 > 500.757348 extract_ip_range [291] range is 172.16.0.1:0 to 172.16.0.1:0 > 501.007425 main [1910] mapped 334980KB at 0x801c00000 > > so I could not explain why I had 800Kpps rates on chelsio when I had that= tweeks and after rebooting i have a much more decent 11Mpps rate but i cou= ld confirm, if I remove the tweeks I get 800K-1.2M pps again on MAC address= tests. > > since cxl0 is not addressed and ncxl0 will only work in netmap mode i bel= ieve it will never arp reply, therefore the netmap application should arp r= eply when someone arp requests the actual mac address for a given ip addres= s, will pkt-gen arp reply? because this could, maybe, explain the destinati= on part for 00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff (but source mac address = should be correct) > > just to remember, when I test intel-intel I get the same 14Mpps RX and TX= rates on both IP address test as well as my previously wrong (using -s|-d = instead of -S|-D pkt-gen options) mac address tests, but i don't remember i= f mac address were shown like that > > luigi, the sysctl you asked navdeep about, sysctl dev.ncxl.0.stats, does = not exist, only sysctl dev.cxl.0.stats exists and I could not find other st= ats similar to dev.t5nex.0.misc.tp_err_stats so probably it's not different= betweek cxl and ncxl > > =3D=3D=3D=3D FULL TESTS TRANSCRIPT =3D=3D=3D=3D > > intel# ifconfig -v ix0 > ix0: flags=3D8843 metric 0 mtu 15= 00 > options=3D8406b8 > ether 00:07:e9:44:d2:ba > inet 172.16.0.2 netmask 0xffffff00 broadcast 172.16.0.255 > nd6 options=3D29 > media: Ethernet 10Gbase-SR (10Gbase-SR ) > status: active > plugged: SFP/SFP+/SFP28 10G Base-SR (LC) > vendor: FINISAR CORP. PN: FTLX8571D3BCL-FC SN: AM31TRU DATE: 2012= -01-21 > module temperature: 34.98 C Voltage: 3.28 Volts > RX: 0.50 mW (-2.98 dBm) TX: 0.58 mW (-2.33 dBm) > intel# ./pkt-gen -i ix0 -f tx -S 00:07:e9:44:d2:ba -D 00:07:43:33:8d:c1 > 268.505741 main [1715] interface is ix0 > 268.505795 extract_ip_range [291] range is 10.0.0.1:0 to 10.0.0.1:0 > 268.505806 extract_ip_range [291] range is 10.1.0.1:0 to 10.1.0.1:0 > 268.611395 main [1910] mapped 334980KB at 0x801c00000 > Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. > 10.0.0.1 -> 10.1.0.1 (00:07:e9:44:d2:ba -> 00:07:43:33:8d:c1) > 268.611467 main [1994] Sending 512 packets every 0.000000000 s > 268.611473 main [1996] Wait 2 secs for phy reset > 270.617971 main [1998] Ready... > 270.618120 nm_open [456] overriding ifname ix0 ringid 0x0 flags 0x1 > 270.635480 sender_body [1073] start, fd 4 main_fd 3 > 270.670823 sender_body [1142] drop copy > 271.637012 main_thread [1512] 14461469 pps (14484000 pkts in 1001558 usec= ) > 272.647011 main_thread [1512] 14880527 pps (15029317 pkts in 1009999 usec= ) > 273.648511 main_thread [1512] 14884638 pps (14906965 pkts in 1001500 usec= ) > 274.649506 main_thread [1512] 14883795 pps (14898619 pkts in 1000996 usec= ) > 275.650509 main_thread [1512] 14879377 pps (14894301 pkts in 1001003 usec= ) > 276.651511 main_thread [1512] 14883276 pps (14898174 pkts in 1001001 usec= ) > 277.652512 main_thread [1512] 14880941 pps (14895852 pkts in 1001002 usec= ) > 278.653517 main_thread [1512] 14879125 pps (14894079 pkts in 1001005 usec= ) > 279.654525 main_thread [1512] 14887529 pps (14902431 pkts in 1001001 usec= ) > 280.656518 main_thread [1512] 14864554 pps (14894268 pkts in 1001999 usec= ) > 281.657012 main_thread [1512] 14882656 pps (14890008 pkts in 1000494 usec= ) > 282.658506 main_thread [1512] 14881346 pps (14903594 pkts in 1001495 usec= ) > 283.664016 main_thread [1512] 14882829 pps (14964819 pkts in 1005509 usec= ) > 284.690513 main_thread [1512] 14880361 pps (15274661 pkts in 1026498 usec= ) > 285.691504 main_thread [1512] 14877683 pps (14892412 pkts in 1000990 usec= ) > 286.692143 main_thread [1512] 14885234 pps (14894761 pkts in 1000640 usec= ) > 287.693510 main_thread [1512] 14885267 pps (14905615 pkts in 1001367 usec= ) > 288.694010 main_thread [1512] 14879692 pps (14887132 pkts in 1000500 usec= ) > ^C289.189696 sigint_h [328] received control-C on thread 0x801806800 > 289.189750 sender_body [1171] flush tail 19 head 19 on thread 0x801806800 > 289.189790 sender_body [1179] pending tx tail 72 head 1105 on ring 0 > 289.189823 sender_body [1179] pending tx tail 154 head 1105 on ring 0 > 289.189848 sender_body [1179] pending tx tail 222 head 1105 on ring 0 > 289.189871 sender_body [1179] pending tx tail 274 head 1105 on ring 0 > 289.189901 sender_body [1179] pending tx tail 338 head 1105 on ring 0 > 289.700237 main_thread [1512] 7332017 pps (7377666 pkts in 1006226 usec) > Sent 275688674 packets, 60 bytes each, in 18.55 seconds. > Speed: 14.86 Mpps Bandwidth: 7.13 Gbps (raw 9.98 Gbps) > intel# > > > > chelsio# ./pkt-gen -i ncxl0 -f rx -S 00:07:e9:44:d2:ba -D 00:07:43:33:8d:= c1 > 529.476963 main [1715] interface is ncxl0 > 529.477028 extract_ip_range [291] range is 10.0.0.1:0 to 10.0.0.1:0 > 529.477042 extract_ip_range [291] range is 10.1.0.1:0 to 10.1.0.1:0 > 529.535750 main [1910] mapped 334980KB at 0x801c00000 > Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. > 529.535829 main [1996] Wait 2 secs for phy reset > 531.537267 main [1998] Ready... > 531.537399 nm_open [456] overriding ifname ncxl0 ringid 0x0 flags 0x1 > 531.555050 receiver_body [1247] reading from netmap:ncxl0 fd 4 main_fd 3 > 532.555628 main_thread [1512] 11173691 pps (11180373 pkts in 1000598 usec= ) > 533.556129 main_thread [1512] 11175384 pps (11180983 pkts in 1000501 usec= ) > 534.567273 main_thread [1512] 11176345 pps (11300905 pkts in 1011145 usec= ) > 535.568126 main_thread [1512] 11175813 pps (11185335 pkts in 1000852 usec= ) > 536.569623 main_thread [1512] 11174668 pps (11191408 pkts in 1001498 usec= ) > 537.580127 main_thread [1512] 11176569 pps (11293968 pkts in 1010504 usec= ) > (..) > > 739.193065 main_thread [1512] 11173118 pps (11177744 pkts in 1000414 usec= ) > 740.194062 main_thread [1512] 11175690 pps (11186832 pkts in 1000997 usec= ) > 741.202063 main_thread [1512] 11176354 pps (11265776 pkts in 1008001 usec= ) > 742.203564 main_thread [1512] 11176509 pps (11193296 pkts in 1001502 usec= ) > 743.204559 main_thread [1512] 11175825 pps (11186945 pkts in 1000995 usec= ) > ^C743.392524 sigint_h [328] received control-C on thread 0x801806800 > 744.212517 main_thread [1512] 2080802 pps (2097359 pkts in 1007957 usec) > Received 2367310284 packets, in 211.84 seconds. > Speed: 11.18 Mpps > > > chelsio# netstat -hd -I ncxl0 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts= Oerrs Coll Drop > ncxl0 1.5K 00:07:43:33:8d:c1 0 0 0 0= 0 0 0 > ncxl0 - 172.16.0.0 172.16.0.1 158M - - 0= - - - > chelsio# netstat -hd -I cxl0 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts= Oerrs Coll Drop > cxl0 1.5K 00:07:43:33:8d:c0 7.1G 0 669M 0= 0 0 0 > chelsio# netstat -hdwi 1 -l ncxl0 > input (Total) output > packets errs idrops bytes packets errs bytes colls drop= s > 15M 0 3.7M 908M 4 0 660 0 0 > 15M 0 3.7M 908M 4 0 612 0 0 > 15M 0 3.7M 908M 4 0 612 0 0 > 15M 0 3.7M 908M 4 0 612 0 0 > 15M 0 3.7M 908M 4 0 612 0 0 > 15M 0 3.7M 908M 9 0 1.2K 0 0 > 15M 0 3.7M 908M 6 0 1.1K 0 0 > 15M 0 3.7M 908M 4 0 612 0 0 > ^C > > chelsio# netstat -hdwi 1 -l cxl0 > input (Total) output > packets errs idrops bytes packets errs bytes colls drop= s > 15M 0 3.7M 908M 4 0 660 0 0 > 15M 0 3.7M 908M 4 0 612 0 0 > 15M 0 3.7M 908M 6 0 763 0 0 > 15M 0 3.7M 908M 4 0 612 0 0 > 15M 0 3.7M 908M 4 0 612 0 0 > 15M 0 3.7M 908M 9 0 1.0K 0 0 > ^C > > chelsio# netstat -hd -I ncxl0 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts= Oerrs Coll Drop > ncxl0 1.5K 00:07:43:33:8d:c1 0 0 0 0= 0 0 0 > > ncxl0 - 172.16.0.0 172.16.0.1 39M - - 0= - - - > chelsio# > chelsio# netstat -hd -I cxl0 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts= Oerrs Coll Drop > cxl0 1.5K 00:07:43:33:8d:c0 6.0G 1 612k 0= 0 0 0 > chelsio# netstat -hdwi 1 -l ncxl0 > input (Total) output > packets errs idrops bytes packets errs bytes colls drop= s > 15M 0 0 908M 8 0 1.1K 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 15 0 1.8K 0 0 > 15M 0 0 908M 10 0 1.2K 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 6 0 822 0 0 > 15M 0 0 908M 6 0 826 0 0 > ^C > chelsio# netstat -hdwi 1 -l cxl0 > input (Total) output > packets errs idrops bytes packets errs bytes colls drop= s > 15M 0 0 908M 8 0 1.0K 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 5 0 756 0 0 > 15M 0 0 908M 10 0 1.2K 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 4 0 604 0 0 > ^C > > > > chelsio# sysctl -n dev.t5nex.0.misc.tp_err_stats > channel 0 channel 1 channel 2 channel 3 > macInErrs: 0 0 0 0 > hdrInErrs: 0 0 0 0 > tcpInErrs: 0 0 0 0 > tcp6InErrs: 0 0 0 0 > tnlCongDrops: 42862617 0 0 0 > tnlTxDrops: 0 0 0 0 > ofldVlanDrops: 0 0 0 0 > ofldChanDrops: 0 0 0 0 > > ofldNoNeigh: 0 > ofldCongDefer: 0 > > chelsio# sysctl dev.cxl.0.stats > dev.cxl.0.stats.rx_trunc3: 0 > dev.cxl.0.stats.rx_trunc2: 0 > dev.cxl.0.stats.rx_trunc1: 0 > dev.cxl.0.stats.rx_trunc0: 0 > dev.cxl.0.stats.rx_ovflow3: 0 > dev.cxl.0.stats.rx_ovflow2: 0 > dev.cxl.0.stats.rx_ovflow1: 0 > dev.cxl.0.stats.rx_ovflow0: 853083783 > dev.cxl.0.stats.rx_ppp7: 0 > dev.cxl.0.stats.rx_ppp6: 0 > dev.cxl.0.stats.rx_ppp5: 0 > dev.cxl.0.stats.rx_ppp4: 0 > dev.cxl.0.stats.rx_ppp3: 0 > dev.cxl.0.stats.rx_ppp2: 0 > dev.cxl.0.stats.rx_ppp1: 0 > dev.cxl.0.stats.rx_ppp0: 0 > dev.cxl.0.stats.rx_pause: 0 > dev.cxl.0.stats.rx_frames_1519_max: 0 > dev.cxl.0.stats.rx_frames_1024_1518: 0 > dev.cxl.0.stats.rx_frames_512_1023: 0 > dev.cxl.0.stats.rx_frames_256_511: 0 > dev.cxl.0.stats.rx_frames_128_255: 0 > dev.cxl.0.stats.rx_frames_65_127: 0 > dev.cxl.0.stats.rx_frames_64: 9778077198 > dev.cxl.0.stats.rx_runt: 0 > dev.cxl.0.stats.rx_symbol_err: 0 > dev.cxl.0.stats.rx_len_err: 0 > dev.cxl.0.stats.rx_fcs_err: 0 > dev.cxl.0.stats.rx_jabber: 0 > dev.cxl.0.stats.rx_too_long: 0 > dev.cxl.0.stats.rx_ucast_frames: 5365842946 > dev.cxl.0.stats.rx_mcast_frames: 0 > dev.cxl.0.stats.rx_bcast_frames: 4412237958 > dev.cxl.0.stats.rx_frames: 9778082382 > dev.cxl.0.stats.rx_octets: 625797304704 > dev.cxl.0.stats.tx_ppp7: 0 > dev.cxl.0.stats.tx_ppp6: 0 > dev.cxl.0.stats.tx_ppp5: 0 > dev.cxl.0.stats.tx_ppp4: 0 > dev.cxl.0.stats.tx_ppp3: 0 > dev.cxl.0.stats.tx_ppp2: 0 > dev.cxl.0.stats.tx_ppp1: 0 > dev.cxl.0.stats.tx_ppp0: 0 > dev.cxl.0.stats.tx_pause: 0 > dev.cxl.0.stats.tx_drop: 0 > dev.cxl.0.stats.tx_frames_1519_max: 0 > dev.cxl.0.stats.tx_frames_1024_1518: 0 > dev.cxl.0.stats.tx_frames_512_1023: 0 > dev.cxl.0.stats.tx_frames_256_511: 0 > dev.cxl.0.stats.tx_frames_128_255: 0 > dev.cxl.0.stats.tx_frames_65_127: 0 > dev.cxl.0.stats.tx_frames_64: 0 > dev.cxl.0.stats.tx_error_frames: 0 > dev.cxl.0.stats.tx_ucast_frames: 0 > dev.cxl.0.stats.tx_mcast_frames: 0 > dev.cxl.0.stats.tx_bcast_frames: 0 > dev.cxl.0.stats.tx_frames: 0 > dev.cxl.0.stats.tx_octets: 0 > dev.cxl.0.stats.tx_parse_error: 0 > chelsio# sysctl dev.ncxl.0.stats > > =3D=3D=3D> IP based tests: > > intel# ./pkt-gen -i ix0 -f tx -s 172.16.0.2 -d 172.16.0.1 > 150.673411 main [1715] interface is ix0 > 150.673545 extract_ip_range [291] range is 172.16.0.2:0 to 172.16.0.2:0 > 150.673560 extract_ip_range [291] range is 172.16.0.1:0 to 172.16.0.1:0 > 150.779091 main [1910] mapped 334980KB at 0x801c00000 > Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. > 172.16.0.2 -> 172.16.0.1 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) > 150.779164 main [1994] Sending 512 packets every 0.000000000 s > 150.779169 main [1996] Wait 2 secs for phy reset > 152.846385 main [1998] Ready... > 152.846515 nm_open [456] overriding ifname ix0 ringid 0x0 flags 0x1 > 152.863946 sender_body [1073] start, fd 4 main_fd 3 > 152.898386 sender_body [1142] drop copy > 153.864749 main_thread [1512] 14477663 pps (14489636 pkts in 1000827 usec= ) > 154.868750 main_thread [1512] 14879784 pps (14939318 pkts in 1004001 usec= ) > 155.873246 main_thread [1512] 14883091 pps (14950005 pkts in 1004496 usec= ) > 156.874753 main_thread [1512] 14883859 pps (14906289 pkts in 1001507 usec= ) > (...) > > chelsio# ./pkt-gen -i ncxl0 -f rx -s 172.16.0.2 -d 172.16.0.1 > 500.757057 main [1715] interface is ncxl0 > 500.757321 extract_ip_range [291] range is 172.16.0.2:0 to 172.16.0.2:0 > 500.757348 extract_ip_range [291] range is 172.16.0.1:0 to 172.16.0.1:0 > 501.007425 main [1910] mapped 334980KB at 0x801c00000 > Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. > 501.007511 main [1996] Wait 2 secs for phy reset > 503.015342 main [1998] Ready... > 503.015487 nm_open [456] overriding ifname ncxl0 ringid 0x0 flags 0x1 > 503.033543 receiver_body [1247] reading from netmap:ncxl0 fd 4 main_fd 3 > 504.034782 main_thread [1512] 303341 pps (303727 pkts in 1001273 usec) > 505.035783 main_thread [1512] 301714 pps (302016 pkts in 1001000 usec) > 506.036779 main_thread [1512] 302355 pps (302656 pkts in 1000996 usec) > 507.037780 main_thread [1512] 301651 pps (301953 pkts in 1001002 usec) > 508.038783 main_thread [1512] 301922 pps (302225 pkts in 1001002 usec) > 509.039780 main_thread [1512] 301633 pps (301934 pkts in 1000997 usec) > 510.040776 main_thread [1512] 304081 pps (304384 pkts in 1000996 usec) > 511.043280 main_thread [1512] 305602 pps (306367 pkts in 1002504 usec) > 512.044780 main_thread [1512] 305207 pps (305665 pkts in 1001500 usec) > 513.045780 main_thread [1512] 305103 pps (305408 pkts in 1001001 usec) > 514.056282 main_thread [1512] 304894 pps (308096 pkts in 1010502 usec) > 515.057781 main_thread [1512] 305015 pps (305472 pkts in 1001499 usec) > 516.058780 main_thread [1512] 305935 pps (306240 pkts in 1000998 usec) > 517.066781 main_thread [1512] 305333 pps (307776 pkts in 1008001 usec) > 518.073779 main_thread [1512] 304556 pps (306688 pkts in 1006999 usec) > 519.081781 main_thread [1512] 304190 pps (306624 pkts in 1008002 usec) > 520.087780 main_thread [1512] 304351 pps (306177 pkts in 1005998 usec) > 521.088778 main_thread [1512] 305102 pps (305407 pkts in 1000999 usec) > 522.089775 main_thread [1512] 305232 pps (305536 pkts in 1000997 usec) > 523.090281 main_thread [1512] 305606 pps (305760 pkts in 1000505 usec) > 524.091280 main_thread [1512] 305391 pps (305696 pkts in 1000999 usec) > 525.093787 main_thread [1512] 305986 pps (306753 pkts in 1002507 usec) > 526.101276 main_thread [1512] 305424 pps (307711 pkts in 1007489 usec) > 527.102772 main_thread [1512] 305272 pps (305729 pkts in 1001496 usec) > 528.106277 main_thread [1512] 305122 pps (306192 pkts in 1003506 usec) > 529.107778 main_thread [1512] 305253 pps (305711 pkts in 1001501 usec) > 523.090281 main_thread [1512] 305606 pps (305760 pkts in 1000505 usec) > 524.091280 main_thread [1512] 305391 pps (305696 pkts in 1000999 usec) > 525.093787 main_thread [1512] 305986 pps (306753 pkts in 1002507 usec) > 526.101276 main_thread [1512] 305424 pps (307711 pkts in 1007489 usec) > 527.102772 main_thread [1512] 305272 pps (305729 pkts in 1001496 usec) > 528.106277 main_thread [1512] 305122 pps (306192 pkts in 1003506 usec) > 529.107778 main_thread [1512] 305253 pps (305711 pkts in 1001501 usec) > 530.110774 main_thread [1512] 304432 pps (305344 pkts in 1002995 usec) > 531.111774 main_thread [1512] 304847 pps (305152 pkts in 1001000 usec) > 532.115782 main_thread [1512] 305209 pps (306432 pkts in 1004008 usec) > 533.122273 main_thread [1512] 305092 pps (307072 pkts in 1006491 usec) > 534.129776 main_thread [1512] 304277 pps (306560 pkts in 1007504 usec) > 535.130272 main_thread [1512] 305193 pps (305344 pkts in 1000496 usec) > 536.135271 main_thread [1512] 304414 pps (305936 pkts in 1004999 usec) > 537.136272 main_thread [1512] 305279 pps (305584 pkts in 1001000 usec) > 538.137772 main_thread [1512] 305334 pps (305792 pkts in 1001500 usec) > 539.138606 main_thread [1512] 304897 pps (305152 pkts in 1000835 usec) > 540.140772 main_thread [1512] 305195 pps (305856 pkts in 1002165 usec) > 541.148272 main_thread [1512] 304786 pps (307072 pkts in 1007501 usec) > 542.149770 main_thread [1512] 304773 pps (305230 pkts in 1001498 usec) > 543.153270 main_thread [1512] 305859 pps (306930 pkts in 1003500 usec) > 544.154357 main_thread [1512] 305014 pps (305345 pkts in 1001086 usec) > 545.156774 main_thread [1512] 304990 pps (305727 pkts in 1002418 usec) > ^C546.157076 sigint_h [328] received control-C on thread 0x801806800 > 546.157273 main_thread [1512] 305512 pps (305664 pkts in 1000499 usec) > Received 13138095 packets, in 43.12 seconds. > Speed: 304.66 Kpps > > chelsio# netstat -hd -I ncxl0 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts= Oerrs Coll Drop > ncxl0 1.5K 00:07:43:33:8d:c1 0 0 0 0= 0 0 0 > > ncxl0 - 172.16.0.0 172.16.0.1 39M - - 0= - - - > chelsio# > chelsio# netstat -hd -I cxl0 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts= Oerrs Coll Drop > cxl0 1.5K 00:07:43:33:8d:c0 6.0G 1 612k 0= 0 0 0 > chelsio# netstat -hdwi 1 -l ncxl0 > input (Total) output > packets errs idrops bytes packets errs bytes colls drop= s > 15M 0 0 908M 8 0 1.1K 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 15 0 1.8K 0 0 > 15M 0 0 908M 10 0 1.2K 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 6 0 822 0 0 > 15M 0 0 908M 6 0 826 0 0 > ^C > chelsio# netstat -hdwi 1 -l cxl0 > input (Total) output > packets errs idrops bytes packets errs bytes colls drop= s > 15M 0 0 908M 8 0 1.0K 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 5 0 756 0 0 > 15M 0 0 908M 10 0 1.2K 0 0 > 15M 0 0 908M 4 0 604 0 0 > 15M 0 0 908M 4 0 604 0 0 > ^C > > chelsio# sysctl -n dev.t5nex.0.misc.tp_err_stats > channel 0 channel 1 channel 2 channel 3 > macInErrs: 0 0 0 0 > hdrInErrs: 0 0 0 0 > tcpInErrs: 0 0 0 0 > tcp6InErrs: 0 0 0 0 > tnlCongDrops: 612276 0 0 0 > tnlTxDrops: 0 0 0 0 > ofldVlanDrops: 0 0 0 0 > ofldChanDrops: 0 0 0 0 > > ofldNoNeigh: 0 > ofldCongDefer: 0 > > chelsio# sysctl dev.ncxl.0.stats > sysctl: unknown oid 'dev.ncxl.0.stats' > Exit 1 > chelsio# sysctl dev.cxl.0.stats > dev.cxl.0.stats.rx_trunc3: 0 > dev.cxl.0.stats.rx_trunc2: 0 > dev.cxl.0.stats.rx_trunc1: 0 > dev.cxl.0.stats.rx_trunc0: 0 > dev.cxl.0.stats.rx_ovflow3: 0 > dev.cxl.0.stats.rx_ovflow2: 0 > dev.cxl.0.stats.rx_ovflow1: 0 > dev.cxl.0.stats.rx_ovflow0: 0 > dev.cxl.0.stats.rx_ppp7: 0 > dev.cxl.0.stats.rx_ppp6: 0 > dev.cxl.0.stats.rx_ppp5: 0 > dev.cxl.0.stats.rx_ppp4: 0 > dev.cxl.0.stats.rx_ppp3: 0 > dev.cxl.0.stats.rx_ppp2: 0 > dev.cxl.0.stats.rx_ppp1: 0 > dev.cxl.0.stats.rx_ppp0: 0 > dev.cxl.0.stats.rx_pause: 0 > dev.cxl.0.stats.rx_frames_1519_max: 0 > dev.cxl.0.stats.rx_frames_1024_1518: 0 > dev.cxl.0.stats.rx_frames_512_1023: 0 > dev.cxl.0.stats.rx_frames_256_511: 0 > dev.cxl.0.stats.rx_frames_128_255: 0 > dev.cxl.0.stats.rx_frames_65_127: 0 > dev.cxl.0.stats.rx_frames_64: 8216274634 > dev.cxl.0.stats.rx_runt: 0 > dev.cxl.0.stats.rx_symbol_err: 0 > dev.cxl.0.stats.rx_len_err: 0 > dev.cxl.0.stats.rx_fcs_err: 1 > dev.cxl.0.stats.rx_jabber: 0 > dev.cxl.0.stats.rx_too_long: 0 > dev.cxl.0.stats.rx_ucast_frames: 0 > dev.cxl.0.stats.rx_mcast_frames: 0 > dev.cxl.0.stats.rx_bcast_frames: 8216279461 > dev.cxl.0.stats.rx_frames: 8216280197 > dev.cxl.0.stats.rx_octets: 525841964992 > dev.cxl.0.stats.tx_ppp7: 0 > dev.cxl.0.stats.tx_ppp6: 0 > dev.cxl.0.stats.tx_ppp5: 0 > dev.cxl.0.stats.tx_ppp4: 0 > dev.cxl.0.stats.tx_ppp3: 0 > dev.cxl.0.stats.tx_ppp2: 0 > dev.cxl.0.stats.tx_ppp1: 0 > dev.cxl.0.stats.tx_ppp0: 0 > dev.cxl.0.stats.tx_pause: 0 > dev.cxl.0.stats.tx_drop: 0 > dev.cxl.0.stats.tx_frames_1519_max: 0 > dev.cxl.0.stats.tx_frames_1024_1518: 0 > dev.cxl.0.stats.tx_frames_512_1023: 0 > dev.cxl.0.stats.tx_frames_256_511: 0 > dev.cxl.0.stats.tx_frames_128_255: 0 > dev.cxl.0.stats.tx_frames_65_127: 0 > dev.cxl.0.stats.tx_frames_64: 0 > dev.cxl.0.stats.tx_error_frames: 0 > dev.cxl.0.stats.tx_ucast_frames: 0 > dev.cxl.0.stats.tx_mcast_frames: 0 > dev.cxl.0.stats.tx_bcast_frames: 0 > dev.cxl.0.stats.tx_frames: 0 > dev.cxl.0.stats.tx_octets: 0 > dev.cxl.0.stats.tx_parse_error: 0 > > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Sun Jan 24 03:20:30 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BDDBA8E6BA for ; Sun, 24 Jan 2016 03:20:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3733B1887 for ; Sun, 24 Jan 2016 03:20:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x234.google.com with SMTP id q21so123315057iod.0 for ; Sat, 23 Jan 2016 19:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3qvKIVulx7Vz9fCk5MsGEhG0hRU/cM3WFO/9zgpfFYw=; b=w/9IaJgyKnAipNi5Hfc98mrzSUuHjs402Mm+dGGADS0gqg39mCyx+tNdywMCGQGQ16 X3E0NJTK64ELvIk8b0VvQ8sdro2yVh/SChg3cZmQeQT61vUl+dCVSFeK4MBXqUEgX95n QeD9Wb9NqhIUtTVmtHEiG8sD5kkQx+MNrJ3L6x1m+U8Vbtfs80S0mxv1guuclGRB4Z5J Hwuw2ffQ6IvBOr2K6pmmmVg5GsZaUrM4jhwryIojFB8JkAmksGO8SZpArlnFt7kL9i8I gMHj9bBbADrjyB9HjZQ35R/03TbLOQItCYUjjCtREnGxslX3o3nJoWDpnMlHl3aWKBUD HbHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3qvKIVulx7Vz9fCk5MsGEhG0hRU/cM3WFO/9zgpfFYw=; b=lUsdYU3YmapbdKQA3WUEB3iSw1tPLV43+fV2ZNG+bpNCgwxetINXkoWU1AGiVlUN5N fq13Qh/I3eDiQIJX/7X141tMGeOusRLHOmmePWelzrt5yuzQ05o1SbV6lp0w8EAzcfg6 3PN9n5Luh4WuNtlpQluy0Ypb4FI56rmvaKw4pww86sAAz7Re1oRF5lvY2lE44cJrrjYl zYixoovMvlGqnWsL2YpVM+MnjVTWYsNBMV8nIiH6UMmo8cGL6JEmFxhemSn4NfLhufcV QBLa9NzoYuZXJA6YGv3VkSrm2r1zb7RAJyD0nsBkUVkhuQ2LKlyXF0PZg+BkjUScAfYD SfGw== X-Gm-Message-State: AG10YORpnifz54VIgpqqc2do1xMDEQwqcUZ9Oc78K5kWLN1wBNRX1crtR/YgRhWJ/dVgJWoEuOwTgKBK/eFG8g== MIME-Version: 1.0 X-Received: by 10.107.162.146 with SMTP id l140mr10159265ioe.123.1453605629660; Sat, 23 Jan 2016 19:20:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.121.16 with HTTP; Sat, 23 Jan 2016 19:20:29 -0800 (PST) In-Reply-To: References: Date: Sat, 23 Jan 2016 19:20:29 -0800 X-Google-Sender-Auth: 182GQUDS5o9L1Z0-A9uantQfBgo Message-ID: Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: Adrian Chadd To: Luigi Rizzo Cc: Marcus Cenzatti , "freebsd-net@freebsd.org" , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 03:20:30 -0000 [snip] You should be able to run with cxl0 down but ncxl0 up. If that doesn't work then it's a bug. It worked when I last tried 40g bridging (about 5 months ago.) Try that manually - ifconfig cxl0 down; ifconfig ncxl0 up -a From owner-freebsd-net@freebsd.org Sun Jan 24 03:53:02 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62789A8D08A for ; Sun, 24 Jan 2016 03:53:02 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 409C4151F for ; Sun, 24 Jan 2016 03:53:02 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id C0E57A0420 for ; Sun, 24 Jan 2016 03:53:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=YVJm0lMOwUJkGAHWsubPDSbYZdOE3i3C3pjcJTMHB9c=; b=gTUcVA8iiKOsYXN6w623KbWyFDkEivWuSP9FD0TJEmuS7wZLv6DliPkRmFHOzRXsfTu07eDGz/ean6krs1gS3+B9BkRmxhAh7wfiQ4fpFlrnDMgHS7uD7fC15AFwXagCEttxqqX5riElRwQjAXJzcOL3hAHH5yS1mqSo7+ATdW3n7gaiy4uMYkSZ4cDVUQxH5E2ls9KeKt04ZhshlE55S56r0iQcud4Jp+1loEfv1xvyJyH5MQsg9qKARzWqY9oZDeTHZx4a5gX7cEB9H8Sd94Bc7vj/5LSHPpXP3CvrlfoI2QOppf+cN8P8V8rJLc4nR4RG0lhA71BCqVkzP6R5ww== Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp2.hushmail.com (Postfix) with ESMTP; Sun, 24 Jan 2016 03:53:00 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 3E533A0126; Sun, 24 Jan 2016 03:53:00 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 24 Jan 2016 01:52:59 -0200 To: "Adrian Chadd" , "Luigi Rizzo" Cc: freebsd-net@freebsd.org, "Navdeep Parhar" Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: "Marcus Cenzatti" In-Reply-To: References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20160124035300.3E533A0126@smtp.hushmail.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 03:53:02 -0000 On 1/24/2016 at 1:20 AM, "Adrian Chadd" wrote: > >[snip] > >You should be able to run with cxl0 down but ncxl0 up. If that >doesn't >work then it's a bug. It worked when I last tried 40g bridging >(about >5 months ago.) > >Try that manually - ifconfig cxl0 down; ifconfig ncxl0 up > > tried, ncxl really won't up while cxl is down, here you are: chelsio# ifconfig cxl0 down chelsio# ifconfig ncxl0 up chelsio# ifconfig cxl0 cxl0: flags=8802 metric 0 mtu 1500 options=ec00bb ether 00:07:43:33:8d:c0 nd6 options=29 media: Ethernet 10Gbase-SR status: no carrier chelsio# ifconfig ncxl0 ncxl0: flags=28943 metric 0 mtu 1500 ether 00:07:43:33:8d:c1 inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255 nd6 options=29 media: Ethernet 10Gbase-SR status: no carrier chelsio# ifconfig ncxl0 up (insisted) chelsio# ifconfig cxl0 cxl0: flags=8802 metric 0 mtu 1500 options=ec00bb ether 00:07:43:33:8d:c0 nd6 options=29 media: Ethernet 10Gbase-SR status: no carrier chelsio# ifconfig ncxl0 ncxl0: flags=28943 metric 0 mtu 1500 ether 00:07:43:33:8d:c1 inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255 nd6 options=29 media: Ethernet 10Gbase-SR status: no carrier chelsio# ifconfig cxl0 up chelsio# ifconfig cxl0 cxl0: flags=8843 metric 0 mtu 1500 options=ec00bb ether 00:07:43:33:8d:c0 nd6 options=29 media: Ethernet 10Gbase-SR status: active chelsio# ifconfig ncxl0 ncxl0: flags=28943 metric 0 mtu 1500 ether 00:07:43:33:8d:c1 inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255 nd6 options=29 media: Ethernet 10Gbase-SR status: active chelsio# From owner-freebsd-net@freebsd.org Sun Jan 24 04:10:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C628A8D59A for ; Sun, 24 Jan 2016 04:10:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D117C1B55 for ; Sun, 24 Jan 2016 04:10:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22f.google.com with SMTP id t15so15794801igr.0 for ; Sat, 23 Jan 2016 20:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4RxmzC6+ztMUSkF19Ts4plSWeK7N/vfLHWkjcI+T9VU=; b=MKVcdqATFPICDwqn83fQbmbykVHbzQKm1SVyiJ1MN9xgRpceFbF3tMXJ8zfuyInLlv ht8rePJtHF9xSchHjYCgNU1Mc//hZ2fChJq7xeG3bgCaXYLjfgzLkbYMqGZqegU+FHIj RFvwHns+67jTTUvgiMTodaVjsUag8s/zMpWMU53vfWqJd1WRUJ/Crfe2KQXD26s9ZMNg 6mJZDZx+nPvTOh4jspOeZHumbX79GKQpRp7okRO8ofsNBiea9R6aScYcpRfVeyBPxrBc k5VbRwTD9QwkyrlHYqIvt3Vl4ZhnYJBkzisb8t7gAZkO1oMPpTdRHkOE2ipSnw8kpGDC 6Y3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4RxmzC6+ztMUSkF19Ts4plSWeK7N/vfLHWkjcI+T9VU=; b=PGk9Gpyc30IBI/SnMgSlupyTO+OqbH1JZhQAkjNvKrjTVCYX7tuqLPXL7OcbOTUIFb eudKcMYJpHIxz59YwChkUTQtytQGE+GeuOf0Ny3e0prD+YwadwHtZmYqmDgg8SqN6SDd DaJ6Xn3CB/s/8WWIdrU9GUrJGi2GMXgEUuFqaR9TsmDaIXBFcHvS/lWTRAdIjRkaLTQp 7SA/bFwFiCJSK33HJljatyvFHRID29rEwZr/d/1No+wLmlXRWPbNLvDvD0VVoZPaSvYT Z3yvMBAoLZUxnvfwWZoZ79H/Iui1pLlc0Am/74AHN8JLZCxfRhbzL2q4i5VzCh9/OOut v5Xg== X-Gm-Message-State: AG10YORR3PLK5LKrx/uxl2I8u1zsOafuGz52Q8jGEY5CiRWCeEZ0AU51tMLhokkJToAgtaWm/Wd1UednnbbHlA== MIME-Version: 1.0 X-Received: by 10.50.122.100 with SMTP id lr4mr11539532igb.37.1453608604124; Sat, 23 Jan 2016 20:10:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.121.16 with HTTP; Sat, 23 Jan 2016 20:10:04 -0800 (PST) In-Reply-To: <20160124035300.3E533A0126@smtp.hushmail.com> References: <20160124035300.3E533A0126@smtp.hushmail.com> Date: Sat, 23 Jan 2016 20:10:04 -0800 X-Google-Sender-Auth: 6AQhUNrVwXEJU7bCTjQ455aizl8 Message-ID: Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: Adrian Chadd To: Marcus Cenzatti Cc: Luigi Rizzo , FreeBSD Net , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 04:10:05 -0000 [snip] Right, but then can you bring down cxl0 whilst leaving ncxl0 up? -a From owner-freebsd-net@freebsd.org Sun Jan 24 04:28:32 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DCD1A8DFF5 for ; Sun, 24 Jan 2016 04:28:32 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A626164A for ; Sun, 24 Jan 2016 04:28:31 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id A204CC02CD for ; Sun, 24 Jan 2016 04:28:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=tFZS4WAIqqNP/WpJ9nPg/07Gk7vnqVTCEBZbJ9Ki+5o=; b=gqJKyQsD0fTPsHYIEF+vy1JzTxtikdv9rpWSf/Csri82/fzgwafCZohOMXq8wSqV7NhiDsRs7TW9JYE9R1YdGwP0gH5DUZeDYBZCXf79e74PNhoxfjE5R5LmBH3n9FdE4kAmrMq5a7TouCCJPU0MCLS0jYLhim2gV4v+0+feBTB4IRH6y7BcT/a8RlZWg+p4vmBz1Ki/0f4/Y2Fl9D+KFUffwWr4ShGvjbgb+cqO/kTmee2DM/fDpoq1mTusqegPJ3qlIaoRelP70qUzP6wLBT2G++cSHXVnW3lUEKVnavWoZAu3duAhmcwgLMOa+jKtmyJMhLkOTTQIj72+hjeqMw== Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP; Sun, 24 Jan 2016 04:28:30 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 3D674A0128; Sun, 24 Jan 2016 04:28:30 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 24 Jan 2016 02:28:29 -0200 To: "Luigi Rizzo" Cc: freebsd-net@freebsd.org, "Navdeep Parhar" Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: "Marcus Cenzatti" In-Reply-To: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20160124042830.3D674A0128@smtp.hushmail.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 04:28:32 -0000 On 1/24/2016 at 1:10 AM, "Luigi Rizzo" wrote: > >Thanks for re-running the experiments. > >I am changing the subject so that in the archives it is clear >that the chelsio card works fine. > >Overall the tests confirm that whenever you hit the host stack you >are bound >to the poor performance of the latter. The problem does not appear >using intel >as a receiver because on the intel card netmap mode disables the >host stack. > >More comments on the experiments: > >The only meaningful test is the one where you use the DMAC of the >ncxl0 port: > > SENDER: ./pkt-gen -i ix0 -f tx -S 00:07:e9:44:d2:ba -D >00:07:43:33:8d:c1 > >in the other experiment you transmit broadcast frames and hit the >network stack. >ARP etc do not matter since tx and rx are directly connected. > >On the receiver you do not need to specify addresses: > > RECEIVER: ./pkt-gen -i ncxl0 -f rx > >The numbers in netstat are clearly rounded, so 15M is probably >14.88M >(line rate), and 3.7M that you see correctly represents the >difference >between incoming and received packets. > >The fact that you see drops may be related to the NIC being unable >to >replenish the queue fast enough, which in turn may be a hardware >or a >software (netmap) issue. >You may try experiment with shorter batches on the receive side >(say, -b 64 or less) and see if you have better results. > >A short batch replenishes the rx queue more frequently, but it is >not a conclusive experiment because there is an optimization in >the netmap poll code which, as an unintended side effect, >replenishes >the queue less often than it should. >For a conclusive experiment you should grab the netmap code from >github.com/luigirizzo/netmap and use pkt-gen-b which >uses busy wait and works around the poll "optimization" > >thanks again for investigating the issue. > >cheers >luigi > so as a summary, with IP test on intel card, netmap disables the host stack while on chelsio netmap does not disable the host stack and we ket things injected to host, so the only reliable test is mac based when using chelsio cards? yes I am already running github's netmap code, let's try with busy code: intel# netmap-master/examples/pkt-gen-b -i ix0 -f tx -S 00:07:e9:44:d2:ba -D 00:07:43:33:8d:c1 626.695437 main [1930] interface is ix0 626.695477 main [2050] running on 1 cpus (have 8) 626.695514 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 626.695524 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 626.800887 main [2148] mapped 334980KB at 0x801800000 Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:07:e9:44:d2:ba -> 00:07:43:33:8d:c1) 626.800959 main [2233] Sending 512 packets every 0.000000000 s 626.800965 main [2235] Wait 2 secs for phy reset 628.801494 main [2237] Ready... 628.801746 sender_body [1211] start, fd 3 main_fd 3 628.837383 sender_body [1293] drop copy 629.802349 main_thread [1720] 14.122 Mpps (14.131 Mpkts 6.783 Gbps in 1000633 usec) 415.72 avg_batch 0 min_space 630.803494 main_thread [1720] 14.503 Mpps (14.520 Mpkts 6.970 Gbps in 1001144 usec) 457.64 avg_batch 99999 min_space 631.804491 main_thread [1720] 14.474 Mpps (14.489 Mpkts 6.954 Gbps in 1000997 usec) 427.45 avg_batch 99999 min_space 632.807500 main_thread [1720] 14.430 Mpps (14.474 Mpkts 6.947 Gbps in 1003009 usec) 470.69 avg_batch 99999 min_space 633.808488 main_thread [1720] 14.455 Mpps (14.470 Mpkts 6.945 Gbps in 1000988 usec) 442.18 avg_batch 99999 min_space (...) 976.810270 sender_body [1334] pending tx tail 477 head 530 on ring 3 976.810300 sender_body [1334] pending tx tail 1241 head 1293 on ring 5 977.283393 main_thread [1720] 7.848 Mpps (8.249 Mpkts 3.959 Gbps in 1051008 usec) 473.06 avg_batch 99999 min_space Sent 5019797634 packets 301187858040 bytes 11178464 events 60 bytes each in 348.01 seconds. Speed: 14.424 Mpps Bandwidth: 6.924 Gbps (raw 9.693 Gbps). Average batch: 449.06 pkts chelsio# ./pkt-gen-b -i ncxl0 -f rx 785.659290 main [1930] interface is ncxl0 785.659337 main [2050] running on 1 cpus (have 4) 785.659477 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 785.659496 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 785.718707 main [2148] mapped 334980KB at 0x801800000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 785.718784 main [2235] Wait 2 secs for phy reset 787.729197 main [2237] Ready... 787.729449 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 788.730089 main_thread [1720] 11.159 Mpps (11.166 Mpkts 5.360 Gbps in 1000673 usec) 205.89 avg_batch 0 min_space 789.730588 main_thread [1720] 11.164 Mpps (11.169 Mpkts 5.361 Gbps in 1000500 usec) 183.54 avg_batch 0 min_space 790.734224 main_thread [1720] 11.172 Mpps (11.213 Mpkts 5.382 Gbps in 1003636 usec) 198.84 avg_batch 0 min_space ^C791.140853 sigint_h [404] received control-C on thread 0x801406800 791.742841 main_thread [1720] 4.504 Mpps (4.542 Mpkts 2.180 Gbps in 1008617 usec) 179.62 avg_batch 0 min_space Received 38091031 packets 2285461860 bytes 196774 events 60 bytes each in 3.41 seconds. Speed: 11.166 Mpps Bandwidth: 5.360 Gbps (raw 7.504 Gbps). Average batch: 193.58 pkts same results... same numbers on netstat too chelsio# ./pkt-gen-b -b 64 -i ncxl0 -f rx 522.430459 main [1930] interface is ncxl0 522.430507 main [2050] running on 1 cpus (have 4) 522.430644 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 522.430662 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 522.677743 main [2148] mapped 334980KB at 0x801800000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 522.677822 main [2235] Wait 2 secs for phy reset 524.698114 main [2237] Ready... 524.698373 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 525.699118 main_thread [1720] 10.958 Mpps (10.966 Mpkts 5.264 Gbps in 1000765 usec) 61.84 avg_batch 0 min_space 526.700108 main_thread [1720] 11.086 Mpps (11.097 Mpkts 5.327 Gbps in 1000991 usec) 61.06 avg_batch 0 min_space 527.705650 main_thread [1720] 11.166 Mpps (11.227 Mpkts 5.389 Gbps in 1005542 usec) 61.91 avg_batch 0 min_space 528.707113 main_thread [1720] 11.090 Mpps (11.107 Mpkts 5.331 Gbps in 1001463 usec) 61.34 avg_batch 0 min_space 529.707617 main_thread [1720] 10.847 Mpps (10.853 Mpkts 5.209 Gbps in 1000504 usec) 62.51 avg_batch 0 min_space ^C530.556309 sigint_h [404] received control-C on thread 0x801406800 530.709133 main_thread [1720] 9.166 Mpps (9.180 Mpkts 4.406 Gbps in 1001516 usec) 62.92 avg_batch 0 min_space Received 64430028 packets 3865801680 bytes 1041000 events 60 bytes each in 5.86 seconds. Speed: 10.999 Mpps Bandwidth: 5.279 Gbps (raw 7.391 Gbps). Average batch: 61.89 pkts chelsio# ./pkt-gen-b -b 48 -i ncxl0 -f rx 962.590603 main [1930] interface is ncxl0 962.590651 main [2050] running on 1 cpus (have 4) 962.590791 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 962.590810 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 962.840889 main [2148] mapped 334980KB at 0x801800000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 962.840963 main [2235] Wait 2 secs for phy reset 964.848016 main [2237] Ready... 964.848279 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 965.849263 main_thread [1720] 10.314 Mpps (10.325 Mpkts 4.956 Gbps in 1001020 usec) 47.93 avg_batch 0 min_space 966.855171 main_thread [1720] 10.322 Mpps (10.383 Mpkts 4.984 Gbps in 1005908 usec) 47.93 avg_batch 0 min_space 967.857352 main_thread [1720] 10.602 Mpps (10.625 Mpkts 5.100 Gbps in 1002182 usec) 46.42 avg_batch 0 min_space 968.858268 main_thread [1720] 10.343 Mpps (10.353 Mpkts 4.969 Gbps in 1000916 usec) 47.62 avg_batch 0 min_space ^C969.524538 sigint_h [404] received control-C on thread 0x801406800 969.895765 main_thread [1720] 6.588 Mpps (6.835 Mpkts 3.281 Gbps in 1037497 usec) 47.94 avg_batch 0 min_space Received 48520680 packets 2911240800 bytes 1020880 events 60 bytes each in 4.68 seconds. Speed: 10.376 Mpps Bandwidth: 4.981 Gbps (raw 6.973 Gbps). Average batch: 47.53 pkts chelsio# ./pkt-gen-b -b 32 -i ncxl0 -f rx 338.251691 main [1930] interface is ncxl0 338.251741 main [2050] running on 1 cpus (have 4) 338.251878 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 338.251897 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 338.494886 main [2148] mapped 334980KB at 0x801800000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 338.494967 main [2235] Wait 2 secs for phy reset 340.501849 main [2237] Ready... 340.502099 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 341.502529 main_thread [1720] 9.044 Mpps (9.048 Mpkts 4.343 Gbps in 1000462 usec) 31.99 avg_batch 0 min_space 342.503257 main_thread [1720] 9.784 Mpps (9.792 Mpkts 4.700 Gbps in 1000728 usec) 31.82 avg_batch 0 min_space 343.504752 main_thread [1720] 10.071 Mpps (10.086 Mpkts 4.841 Gbps in 1001495 usec) 31.76 avg_batch 0 min_space 344.533756 main_thread [1720] 9.046 Mpps (9.309 Mpkts 4.468 Gbps in 1029004 usec) 31.99 avg_batch 0 min_space 345.534754 main_thread [1720] 11.161 Mpps (11.172 Mpkts 5.363 Gbps in 1000998 usec) 31.58 avg_batch 0 min_space 346.535754 main_thread [1720] 9.262 Mpps (9.271 Mpkts 4.450 Gbps in 1001000 usec) 31.93 avg_batch 0 min_space 347.536755 main_thread [1720] 10.169 Mpps (10.179 Mpkts 4.886 Gbps in 1001001 usec) 31.74 avg_batch 0 min_space 348.537256 main_thread [1720] 9.896 Mpps (9.901 Mpkts 4.752 Gbps in 1000501 usec) 31.79 avg_batch 0 min_space 349.538757 main_thread [1720] 8.997 Mpps (9.011 Mpkts 4.325 Gbps in 1001501 usec) 31.99 avg_batch 0 min_space 350.548161 main_thread [1720] 9.709 Mpps (9.800 Mpkts 4.704 Gbps in 1009404 usec) 31.83 avg_batch 0 min_space 351.548888 main_thread [1720] 6.208 Mpps (6.212 Mpkts 2.982 Gbps in 1000727 usec) 31.98 avg_batch 0 min_space ^C354.108457 sigint_h [404] received control-C on thread 0x801406800 354.588907 main_thread [1720] 0.000 pps (0.000 pkts 0.000 bps in 1010653 usec) 0.00 avg_batch 0 min_space Received 103781019 packets 6226861140 bytes 3259138 events 60 bytes each in 13.61 seconds. Speed: 7.627 Mpps Bandwidth: 3.661 Gbps (raw 5.126 Gbps). Average batch: 31.84 pkts chelsio# ./pkt-gen-b -b 16 -i ncxl0 -f rx 369.154719 main [1930] interface is ncxl0 369.154770 main [2050] running on 1 cpus (have 4) 369.154931 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 369.154950 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 369.213861 main [2148] mapped 334980KB at 0x801800000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 369.213934 main [2235] Wait 2 secs for phy reset 371.287288 main [2237] Ready... 371.287548 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 391.613739 main_thread [1720] 1.754 Mpps (1.756 Mpkts 842.694 Mbps in 1001124 usec) 16.00 avg_batch 0 min_space 392.614736 main_thread [1720] 7.671 Mpps (7.678 Mpkts 3.686 Gbps in 1000998 usec) 16.00 avg_batch 0 min_space 393.615737 main_thread [1720] 7.890 Mpps (7.898 Mpkts 3.791 Gbps in 1001000 usec) 16.00 avg_batch 0 min_space 394.618238 main_thread [1720] 7.417 Mpps (7.435 Mpkts 3.569 Gbps in 1002501 usec) 16.00 avg_batch 0 min_space 395.622739 main_thread [1720] 7.812 Mpps (7.847 Mpkts 3.767 Gbps in 1004501 usec) 16.00 avg_batch 0 min_space 396.623737 main_thread [1720] 7.176 Mpps (7.184 Mpkts 3.448 Gbps in 1000998 usec) 16.00 avg_batch 0 min_space 397.624737 main_thread [1720] 8.188 Mpps (8.196 Mpkts 3.934 Gbps in 1001000 usec) 16.00 avg_batch 0 min_space 398.625238 main_thread [1720] 6.984 Mpps (6.988 Mpkts 3.354 Gbps in 1000501 usec) 16.00 avg_batch 0 min_space 399.626238 main_thread [1720] 8.535 Mpps (8.544 Mpkts 4.101 Gbps in 1001000 usec) 16.00 avg_batch 0 min_space 400.628241 main_thread [1720] 7.943 Mpps (7.959 Mpkts 3.820 Gbps in 1002003 usec) 16.00 avg_batch 0 min_space 401.639007 main_thread [1720] 6.890 Mpps (6.964 Mpkts 3.343 Gbps in 1010766 usec) 16.00 avg_batch 0 min_space 402.641242 main_thread [1720] 3.720 Mpps (3.728 Mpkts 1.790 Gbps in 1002235 usec) 16.00 avg_batch 0 min_space 403.674984 main_thread [1720] 0.000 pps (0.000 pkts 0.000 bps in 1033742 usec) 0.00 avg_batch 0 min_space ^C404.054679 sigint_h [404] received control-C on thread 0x801406800 404.713489 main_thread [1720] 0.000 pps (0.000 pkts 0.000 bps in 1038505 usec) 0.00 avg_batch 0 min_space Received 82176988 packets 4930619280 bytes 5136173 events 60 bytes each in 12.71 seconds. Speed: 6.464 Mpps Bandwidth: 3.103 Gbps (raw 4.344 Gbps). Average batch: 16.00 pkts chelsio# ./pkt-gen-b -b 8 -i ncxl0 -f rx 425.948206 main [1930] interface is ncxl0 425.948257 main [2050] running on 1 cpus (have 4) 425.948416 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 425.948435 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 426.007359 main [2148] mapped 334980KB at 0x801800000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 426.007441 main [2235] Wait 2 secs for phy reset 428.027495 main [2237] Ready... 456.499220 main_thread [1720] 4.701 Mpps (4.703 Mpkts 2.258 Gbps in 1000463 usec) 8.00 avg_batch 24 min_space 457.505129 main_thread [1720] 4.710 Mpps (4.738 Mpkts 2.274 Gbps in 1005909 usec) 8.00 avg_batch 24 min_space 458.505221 main_thread [1720] 4.705 Mpps (4.705 Mpkts 2.258 Gbps in 1000092 usec) 8.00 avg_batch 24 min_space 459.506715 main_thread [1720] 4.774 Mpps (4.782 Mpkts 2.295 Gbps in 1001495 usec) 8.00 avg_batch 21 min_space 460.509489 main_thread [1720] 4.961 Mpps (4.974 Mpkts 2.388 Gbps in 1002773 usec) 8.00 avg_batch 16 min_space 461.510218 main_thread [1720] 4.987 Mpps (4.990 Mpkts 2.395 Gbps in 1000729 usec) 8.00 avg_batch 16 min_space 462.511226 main_thread [1720] 4.931 Mpps (4.936 Mpkts 2.369 Gbps in 1001008 usec) 8.00 avg_batch 16 min_space ^C462.865617 sigint_h [404] received control-C on thread 0x801406800 463.519966 main_thread [1720] 1.837 Mpps (1.853 Mpkts 889.275 Mbps in 1008741 usec) 8.00 avg_batch 23 min_space Received 36200232 packets 2172013920 bytes 4525050 events 60 bytes each in 7.48 seconds. Speed: 4.840 Mpps Bandwidth: 2.323 Gbps (raw 3.253 Gbps). Average batch: 8.00 pkts so, the lower the batch the smaller performance. did you expect some other behaviour? thank you very much again From owner-freebsd-net@freebsd.org Sun Jan 24 04:30:52 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D7B8A8E1EF for ; Sun, 24 Jan 2016 04:30:52 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3301A19B6 for ; Sun, 24 Jan 2016 04:30:52 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 253CE2010C for ; Sun, 24 Jan 2016 04:30:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=bTIyn95XdeNtbt9fARNb7Jt4w/0ORE5kLHHeIzBpHh4=; b=d7MMs76q2aj+hxpaVEnobsCHTsyRS3diw5qA6Q0/meXsGE3zrDeYxaGmiYEbDmqdFsuDj6kThfEEve918bJxI6sPCNtI0+8vjWL/hMKFh8IdwgaYe7kap6HOX2QbTWTQj5pOJAcUvgzeTlS31ahBgon/m7hY8jUZSTTsY6VxR6wlBChIKy9fnZvi8/dSxZgui/YT9Dgspkp+/gZYMNaoFjKuwMiHmumMVGXEVQoarzPyn5iMVmbWmTM2m9J20PCION1YnLqjsm5gLx1fZU76UYT/wgz29RRTdWrwRXrANuS47wW6zSWKmbKwNaloARfsvaV35hO9SCbwjl1NnvPJig== Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP; Sun, 24 Jan 2016 04:30:50 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id A4936A0126; Sun, 24 Jan 2016 04:30:50 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 24 Jan 2016 02:30:50 -0200 To: "Adrian Chadd" Cc: "Luigi Rizzo" , "FreeBSD Net" , "Navdeep Parhar" Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: "Marcus Cenzatti" In-Reply-To: References: <20160124035300.3E533A0126@smtp.hushmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20160124043050.A4936A0126@smtp.hushmail.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 04:30:52 -0000 On 1/24/2016 at 2:10 AM, "Adrian Chadd" wrote: > >[snip] > >Right, but then can you bring down cxl0 whilst leaving ncxl0 up? > no :( different behaviour from T540? chelsio# ifconfig cxl0 cxl0: flags=8843 metric 0 mtu 1500 options=ec00bb ether 00:07:43:33:8d:c0 nd6 options=29 media: Ethernet 10Gbase-SR status: active chelsio# ifconfig ncxl0 ncxl0: flags=8843 metric 0 mtu 1500 ether 00:07:43:33:8d:c1 inet 10.1.1.2 netmask 0xffffff00 broadcast 10.1.1.255 nd6 options=29 media: Ethernet 10Gbase-SR status: active chelsio# ifconfig cxl0 down chelsio# ifconfig ncxl0 ncxl0: flags=8843 metric 0 mtu 1500 ether 00:07:43:33:8d:c1 inet 10.1.1.2 netmask 0xffffff00 broadcast 10.1.1.255 nd6 options=29 media: Ethernet 10Gbase-SR status: no carrier From owner-freebsd-net@freebsd.org Sun Jan 24 04:38:25 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51658A8E3F6 for ; Sun, 24 Jan 2016 04:38:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B7CB1C80 for ; Sun, 24 Jan 2016 04:38:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id q21so123975981iod.0 for ; Sat, 23 Jan 2016 20:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AhAo5JT5x0gh5+88xjz+2U9labF9GYvZRk7Qzs7NZ/4=; b=mVfCbrLk8jUJY0E7OIlpxbNJJw+ShlEbO9pR7mT/1GsvtLNlHuLmxFRtHl0YiTIdva QWK/99FsvCGCrXezDNOYZ7ii65KQuF29MVUf2DRVyZ9BgmDLtD4VVoNSIyRfZash4fYM vgtXchp+yagDNdSLkOiHLjmxLgrE53FLgOkHnIdZWO3cLj+5le7e5El+rjgkf8f5PUOc MPNSVkUGE7Tdke8AagJRLt/RcH9X1mKlgZ78vJJfTOj/wXHznSFBvA0MkVWYeAHMvKF5 8Uwc5OwVWbQOmb+Q3UwiJBPNVQE8lisw5dGfPb0WCpvES6A5PB/0oz9u534xjXpnRllI l+dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AhAo5JT5x0gh5+88xjz+2U9labF9GYvZRk7Qzs7NZ/4=; b=EUYWpooK22TZ2WRMbHxybWo3klPYgABB6UlEgk6N1JAZ5ZMAk0cC+teUVisyMCp59J sDN7/m271fpp2qJj3cAenH9P2JbYzCu2xyeDmGNvgdk/jr6CjW0AOs/T4kJ6PfNGOv1O ODaAZxK4Bk9Svv/vYE9cb1UdXJyOcKxMMtKGPmpO56NfWtwkvSPx1GNzc0hxfcXpIUUy AISxZfgQyb0vj0za1a7tJhmUK9EAUcqmcsRauyGq02OZ9MXOBZQrXPfd8D1o/7cY2LMn vdx1rg5Fpl4QwhUarXEWjN5TPyL1CWX9+BAeTTiSX1SKh833m9uyoEfmfHn1p4taHju7 Ng8w== X-Gm-Message-State: AG10YOQrV6sY4+zeS5bmr7eAnq/MLStNaMMmzXmnY8lMcQ44DUvMo8HHe0gveOt23aByt68p5xqHB8NUEsjZUg== MIME-Version: 1.0 X-Received: by 10.107.11.162 with SMTP id 34mr10666089iol.165.1453610304491; Sat, 23 Jan 2016 20:38:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.121.16 with HTTP; Sat, 23 Jan 2016 20:38:24 -0800 (PST) In-Reply-To: <20160124043050.A4936A0126@smtp.hushmail.com> References: <20160124035300.3E533A0126@smtp.hushmail.com> <20160124043050.A4936A0126@smtp.hushmail.com> Date: Sat, 23 Jan 2016 20:38:24 -0800 X-Google-Sender-Auth: OLWrIPT1oTWls-ZfXedp1Xd1doI Message-ID: Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: Adrian Chadd To: Marcus Cenzatti Cc: Luigi Rizzo , FreeBSD Net , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 04:38:25 -0000 ok, that's a discussion to have with navdeep. That /should/ work. Someone may have changed it lately. Things should behave very well and predictable once you can disable cxl0 but not ncxl0. :-P -a From owner-freebsd-net@freebsd.org Sun Jan 24 05:06:52 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81C80A8ED01 for ; Sun, 24 Jan 2016 05:06:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 65E7A1562 for ; Sun, 24 Jan 2016 05:06:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 60DDDA8ECFD; Sun, 24 Jan 2016 05:06:52 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46750A8ECFA; Sun, 24 Jan 2016 05:06:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFF4D1560; Sun, 24 Jan 2016 05:06:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0O56ZtF015586 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 24 Jan 2016 07:06:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0O56ZtF015586 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0O56Yr5015548; Sun, 24 Jan 2016 07:06:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Jan 2016 07:06:34 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Bruce Evans , threads@freebsd.org, Jilles Tjoelker , net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160124050634.GS3942@kib.kiev.ua> References: <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Yia77v5a8fyVHJSl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 05:06:52 -0000 --Yia77v5a8fyVHJSl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Overall, the patch starts taking the committable shape, I only have small notes about it. On Fri, Jan 22, 2016 at 11:15:18AM +0200, Boris Astardzhiev wrote: > be>None of the above. Plain recvmsg() returns ssize_t and its len arg has > be>type size_t. That is excessively typedefed and excessively large with > be>64-bit ssize_t, but it is silly for the multiple-message variant to use > be>smaller types. > be> > be>Otherwise, all the integer types should be int. >=20 > It seems logical. I'll convert the ret easily to ssize_t and the vector > length > to size_t. Now it differs from the Linux prototype but I guess it's okay. Lets try. I do think that the change is for good. >=20 > be>The errno method (and not checking ret at all) is best if for syscalls > that > be>return -1 for a non-error. It is not needed here. >=20 > Fixing it. >=20 > kb> I do not see any sense in making the functions with signature or > semantic > kb> different from Linux version. Right now, the goal of including the > patch > kb> is compatibility. >=20 > Regarding recvmmsg() - > I tried to implement MSG_WAITFORONE and the timeout stuff using > pselect(2) due to the timespec structure. I could have used ppoll and > I'm not sure which of these two is more appropriate or maybe there's > another approach? Now it has timeout just as in the Linux prototype. > Comments are welcomed. You defer to ppoll() and pselect() due to the struct timespec type of the argument, am I right ? > > See patch. > diff --git a/lib/libc/include/namespace.h b/lib/libc/include/namespace.h > index 739d7b1..c95829e 100644 > --- a/lib/libc/include/namespace.h > +++ b/lib/libc/include/namespace.h > @@ -208,6 +208,7 @@ > #define readv _readv > #define recvfrom _recvfrom > #define recvmsg _recvmsg > +#define recvmmsg _recvmmsg > #define select _select > #define sem_close _sem_close > #define sem_destroy _sem_destroy > @@ -220,6 +221,7 @@ > #define sem_unlink _sem_unlink > #define sem_wait _sem_wait > #define sendmsg _sendmsg > +#define sendmmsg _sendmmsg > #define sendto _sendto > #define setsockopt _setsockopt > /*#define sigaction _sigaction*/ > diff --git a/lib/libc/include/un-namespace.h b/lib/libc/include/un-namesp= ace.h > index f31fa7a..0233348 100644 > --- a/lib/libc/include/un-namespace.h > +++ b/lib/libc/include/un-namespace.h > @@ -189,6 +189,7 @@ > #undef readv > #undef recvfrom > #undef recvmsg > +#undef recvmmsg > #undef select > #undef sem_close > #undef sem_destroy > @@ -201,6 +202,7 @@ > #undef sem_unlink > #undef sem_wait > #undef sendmsg > +#undef sendmmsg > #undef sendto > #undef setsockopt > #undef sigaction > diff --git a/lib/libc/sys/Makefile.inc b/lib/libc/sys/Makefile.inc > index e4fe1b2..5f8b699 100644 > --- a/lib/libc/sys/Makefile.inc > +++ b/lib/libc/sys/Makefile.inc > @@ -28,6 +28,8 @@ SRCS+=3D futimens.c utimensat.c > NOASM+=3D futimens.o utimensat.o > PSEUDO+=3D _futimens.o _utimensat.o > =20 > +SRCS+=3D recvmmsg.c sendmmsg.c > + BTW, just noted, I think the functions should live in libc/gen. > INTERPOSED =3D \ > accept \ > accept4 \ > diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map > index 7b3257c..dc2ed0e 100644 > --- a/lib/libc/sys/Symbol.map > +++ b/lib/libc/sys/Symbol.map > @@ -399,6 +399,8 @@ FBSD_1.4 { > utimensat; > numa_setaffinity; > numa_getaffinity; > + sendmmsg; > + recvmmsg; > }; > =20 > FBSDprivate_1.0 { > diff --git a/lib/libc/sys/recv.2 b/lib/libc/sys/recv.2 > index 326e7ff..fd2b2a1 100644 > --- a/lib/libc/sys/recv.2 > +++ b/lib/libc/sys/recv.2 > @@ -34,8 +34,9 @@ > .Sh NAME > .Nm recv , > .Nm recvfrom , > -.Nm recvmsg > -.Nd receive a message from a socket > +.Nm recvmsg , > +.Nm recvmmsg > +.Nd receive message(s) from a socket > .Sh LIBRARY > .Lb libc > .Sh SYNOPSIS > @@ -47,11 +48,15 @@ > .Fn recvfrom "int s" "void *buf" "size_t len" "int flags" "struct sockad= dr * restrict from" "socklen_t * restrict fromlen" > .Ft ssize_t > .Fn recvmsg "int s" "struct msghdr *msg" "int flags" > +.Ft ssize_t > +.Fn recvmmsg "int s" "struct mmsghdr *msgvec" "size_t vlen" "int flags" = "const struct timespec *timeout" > .Sh DESCRIPTION > The > .Fn recvfrom > and > .Fn recvmsg > +and > +.Fn recvmmsg > system calls > are used to receive messages from a socket, > and may be used to receive data on a socket whether or not > @@ -84,8 +89,30 @@ null pointer passed as its > .Fa from > argument. > .Pp > -All three routines return the length of the message on successful > -completion. > +The > +.Fn recvmmsg > +function is used to receive multiple > +messages at a call. > +Their number > +is supplied by > +.Fa vlen . > +The messages are placed in the > +.Fa msgvec > +vector after reception. > +The size of each received message is placed in the > +.Fa msg_len > +field of each element of the vector. > +If > +.Fa timeout > +is NULL the call will normally block. Otherwise it will wait for data > +for the specified amount of time. If the timeout expires and there is > +no data received a value of 0 is returned. pselect(2) is used for the > +implementation of the timeout mechanism. Put each sentence on new line. > +.Pp > +The first three routines return the length of the message on successful > +completion whereas > +.Fn recvmmsg > +returns the number of received messages. > If a message is too long to fit in the supplied buffer, > excess bytes may be discarded depending on the type of socket > the message is received from (see > @@ -100,7 +127,9 @@ in which case the value > .Va errno > is set to > .Er EAGAIN . > -The receive calls normally return any data available, > +The receive calls except > +.Fn recvmmsg > +normally return any data available, > up to the requested amount, > rather than waiting for receipt of the full amount requested; > this behavior is affected by the socket-level options > @@ -127,6 +156,9 @@ one or more of the values: > .It Dv MSG_WAITALL Ta wait for full request or error > .It Dv MSG_DONTWAIT Ta do not block > .It Dv MSG_CMSG_CLOEXEC Ta set received fds close-on-exec > +.It Dv MSG_WAITFORONE Ta do not block after receiving the first message > +(relevant only for > +.Fn recvmmsg ) > .El > .Pp > The > @@ -158,6 +190,11 @@ is set to > This flag is not available in strict > .Tn ANSI > or C99 compilation mode. > +The > +.Dv MSG_WAITFORONE > +flag sets MSG_DONTWAIT after the first message has been received. This f= lag > +is only relevant for > +.Fn recvmmsg . > .Pp > The > .Fn recvmsg > @@ -290,9 +327,34 @@ control data were discarded due to lack of space in = the buffer > for ancillary data. > .Dv MSG_OOB > is returned to indicate that expedited or out-of-band data were received. > +.Pp > +The > +.Fn recvmmsg > +system call uses the > +.Fa mmsghdr > +structure. Its form is as follows, as defined in > +.In sys/socket.h : > +.Bd -literal > +struct mmsghdr { > + struct msghdr msg_hdr; /* message header */ > + unsigned int msg_len; /* message length */ > +}; > +.Ed > +.Pp > +For > +.Fa msg_hdr > +see above. On data reception the > +.Fa msg_len > +field is updated to the length of the received message. On > +data transmission it is updated to the number of > +characters sent. > .Sh RETURN VALUES > -These calls return the number of bytes received, or -1 > -if an error occurred. > +These calls except > +.Fn recvmmsg > +return the number of bytes received. > +.Fn recvmmsg > +returns the number of messages received. > +A value of -1 is returned if an error occurred. > .Sh ERRORS > The calls fail if: > .Bl -tag -width Er > diff --git a/lib/libc/sys/recvmmsg.c b/lib/libc/sys/recvmmsg.c > new file mode 100644 > index 0000000..19a937b > --- /dev/null > +++ b/lib/libc/sys/recvmmsg.c > @@ -0,0 +1,96 @@ > +/* > + * Copyright (c) 2016 Boris Astardzhiev, Smartcom-Bulgaria AD > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice(s), this list of conditions and the following disclaimer as > + * the first lines of this file unmodified other than the possible > + * addition of one or more copyright notices. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice(s), this list of conditions and the following disclaimer in > + * the documentation and/or other materials provided with the > + * distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS'' AND ANY > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR > + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, > + * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE > + * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, > + * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > +__FBSDID("$FreeBSD$"); > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include "libc_private.h" > + > +#define CMTR(s, timeout) \ > + do { \ > + fd_set fds; \ > + int res; \ > + \ > + FD_ZERO(&fds); \ > + FD_SET((s), &fds); \ > + res =3D __sys_pselect((s)+1, &fds, NULL, NULL, (timeout), NULL);\ Why do you need the syscall there ? Cancellation before any data was received is fine, since cancellation would not result in data loss. > + if (res =3D=3D -1 || res =3D=3D 0) \ > + return (res); \ > + if (!FD_ISSET((s), &fds)) \ > + return (-1); \ > + } while (0); > + > +ssize_t > +recvmmsg(int s, struct mmsghdr *msgvec, size_t vlen, int flags, > + const struct timespec *timeout) > +{ > + size_t i, rcvd; > + ssize_t ret; > + > + if (timeout !=3D NULL) > + CMTR(s, timeout); The CMTR define is only used once. I do not see why not inline it, and get rid of the staircase of backslashes. > + > + ret =3D __sys_recvmsg(s, &msgvec[0].msg_hdr, flags); > + if (ret =3D=3D -1) > + return (ret); > + > + /* Check initially for the presence of MSG_WAITFORONE. > + * Turn on MSG_DONTWAIT if set. */ > + if (flags & MSG_WAITFORONE) { > + flags |=3D MSG_DONTWAIT; > + /* The kernel doesn't need to know about this flag. */ > + flags &=3D ~MSG_WAITFORONE; > + } > + > + rcvd =3D 1; > + for (i =3D rcvd; i < vlen; i++) { i =3D rcvd =3D 1; ... i++, rcvd++ ? > + ret =3D __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > + if (ret =3D=3D -1) { > + if (rcvd !=3D 0) { > + /* We've received messages. Let caller know. */ > + return (rcvd); > + } > + return (ret); > + } > + > + /* Save received bytes */ > + msgvec[i].msg_len =3D ret; > + rcvd++; > + } > + > + return (rcvd); > +} > + > +#undef CMTR > diff --git a/lib/libc/sys/send.2 b/lib/libc/sys/send.2 > index 8fa2c64..33fa58d 100644 > --- a/lib/libc/sys/send.2 > +++ b/lib/libc/sys/send.2 > @@ -34,8 +34,9 @@ > .Sh NAME > .Nm send , > .Nm sendto , > -.Nm sendmsg > -.Nd send a message from a socket > +.Nm sendmsg , > +.Nm sendmmsg > +.Nd send message(s) from a socket > .Sh LIBRARY > .Lb libc > .Sh SYNOPSIS > @@ -47,6 +48,8 @@ > .Fn sendto "int s" "const void *msg" "size_t len" "int flags" "const str= uct sockaddr *to" "socklen_t tolen" > .Ft ssize_t > .Fn sendmsg "int s" "const struct msghdr *msg" "int flags" > +.Ft ssize_t > +.Fn sendmmsg "int s" "struct mmsghdr *msgvec" "size_t vlen" "int flags" > .Sh DESCRIPTION > The > .Fn send > @@ -55,8 +58,10 @@ and > .Fn sendto > and > .Fn sendmsg > +and > +.Fn sendmmsg > system calls > -are used to transmit a message to another socket. > +are used to transmit one or multiple messages (with the latter call) to = another socket. > The > .Fn send > function > @@ -66,6 +71,8 @@ state, while > .Fn sendto > and > .Fn sendmsg > +and > +.Fn sendmmsg > may be used at any time. > .Pp > The address of the target is given by > @@ -81,6 +88,18 @@ underlying protocol, the error > is returned, and > the message is not transmitted. > .Pp > +The > +.Fn sendmmsg > +function sends multiple messages at a call. > +They are given by the > +.Fa msgvec > +vector along with > +.Fa vlen > +specifying its size. The number of > +characters sent per each message is placed in the > +.Fa msg_len > +field of each element of the vector after transmission. > +.Pp > No indication of failure to deliver is implicit in a > .Fn send . > Locally detected errors are indicated by a return value of -1. > @@ -138,10 +157,16 @@ See > .Xr recv 2 > for a description of the > .Fa msghdr > +structure and the > +.Fa mmsghdr > structure. > .Sh RETURN VALUES > -The call returns the number of characters sent, or -1 > -if an error occurred. > +All calls except > +.Fn sendmmsg > +return the number of characters sent. The > +.Fn sendmmsg > +call returns the number of messages sent. > +If an error occurred a value of -1 is returned. > .Sh ERRORS > The > .Fn send > @@ -149,6 +174,8 @@ function and > .Fn sendto > and > .Fn sendmsg > +and > +.Fn sendmmsg > system calls > fail if: > .Bl -tag -width Er > diff --git a/lib/libc/sys/sendmmsg.c b/lib/libc/sys/sendmmsg.c > new file mode 100644 > index 0000000..cef35a3 > --- /dev/null > +++ b/lib/libc/sys/sendmmsg.c > @@ -0,0 +1,63 @@ > +/* > + * Copyright (c) 2016 Boris Astardzhiev, Smartcom-Bulgaria AD > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice(s), this list of conditions and the following disclaimer as > + * the first lines of this file unmodified other than the possible > + * addition of one or more copyright notices. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice(s), this list of conditions and the following disclaimer in > + * the documentation and/or other materials provided with the > + * distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS'' AND ANY > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR > + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, > + * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE > + * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, > + * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > +__FBSDID("$FreeBSD$"); > + > +#include > +#include > +#include > +#include > +#include > +#include "libc_private.h" > + > +ssize_t > +sendmmsg(int s, struct mmsghdr *msgvec, size_t vlen, int flags) > +{ > + size_t i, sent; > + ssize_t ret; > + > + sent =3D 0; > + for (i =3D 0; i < vlen; i++) { sent =3D i =3D 0; ... i++, sent++ > + ret =3D __sys_sendmsg(s, &msgvec[i].msg_hdr, flags); > + if (ret =3D=3D -1) { > + if (sent !=3D 0) { > + /* We have sent messages. Let caller know. */ > + return (sent); > + } > + return (ret); > + } > + > + /* Save sent bytes */ > + msgvec[i].msg_len =3D ret; > + sent++; > + } > + > + return (sent); > +} > diff --git a/sys/sys/socket.h b/sys/sys/socket.h > index 18e2de1..d95f29e 100644 > --- a/sys/sys/socket.h > +++ b/sys/sys/socket.h > @@ -435,6 +435,11 @@ struct msghdr { > #ifdef _KERNEL > #define MSG_SOCALLBCK 0x10000 /* for use by socket callbacks - sorece= ive (TCP) */ > #endif > +#ifndef _KERNEL > +#ifdef __BSD_VISIBLE > +#define MSG_WAITFORONE 0x100000 /* used in recvmmsg() */ Move the define to the previous __BSD_VISIBLE block, which ends with CMSG_CLOEXEC. Also, it seems that the next unused bit is 0x80000. Replace the comment by 'for recvmmsg()', the MSG_COMPAT is something private. > +#endif /* __BSD_VISIBLE */ > +#endif /* !_KERNEL */ > =20 > /* > * Header for ancillary data objects in msg_control buffer. > @@ -595,6 +600,18 @@ struct sf_hdtr { > #endif /* _KERNEL */ > #endif /* __BSD_VISIBLE */ > =20 > +#ifndef _KERNEL > +#ifdef __BSD_VISIBLE > +/* > + * Send/recvmmsg specific structure(s) > + */ > +struct mmsghdr { > + struct msghdr msg_hdr; /* message header */ > + unsigned int msg_len; /* message length */ Still int for msg_len ? > +}; > +#endif /* __BSD_VISIBLE */ > +#endif /* !_KERNEL */ > + > #ifndef _KERNEL > =20 > #include > @@ -615,11 +632,19 @@ int listen(int, int); > ssize_t recv(int, void *, size_t, int); > ssize_t recvfrom(int, void *, size_t, int, struct sockaddr * __restrict,= socklen_t * __restrict); > ssize_t recvmsg(int, struct msghdr *, int); > +#if __BSD_VISIBLE > +struct timespec; > +ssize_t recvmmsg(int, struct mmsghdr *, size_t, int, > + const struct timespec *); It probably makes sense to mark pointers with __restrict. > +#endif > ssize_t send(int, const void *, size_t, int); > ssize_t sendto(int, const void *, > size_t, int, const struct sockaddr *, socklen_t); > ssize_t sendmsg(int, const struct msghdr *, int); > #if __BSD_VISIBLE > +ssize_t sendmmsg(int, struct mmsghdr *, size_t, int); > +#endif > +#if __BSD_VISIBLE > int sendfile(int, int, off_t, size_t, struct sf_hdtr *, off_t *, int); > int setfib(int); > #endif --Yia77v5a8fyVHJSl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWpFvaAAoJEJDCuSvBvK1BKkUP/RC49EX9QKT2M+PdUeg2Z1de W0BEzTgE00z6AcksRzBNXVhdDW7D1/oJub23x3qdPXuMju3npf2FE41Hzm2+0BmC pKKURku90CZfRX6sIQZgU1jZbjSzMhRfYc9T6QeJQq0cQqOY3wM+V4hrE5LxVmJK 2TlKafvGubrImoEQx5doWOrgdBEG9vQ0Zbko/SNnmU4BWFQYniS3Hk0R5/OtuFbH VqvxOToMpzL54EOqNsV0Toi//7TiAlfPXFZfxoKFTLUHwpm1EGYEUFEdGU9NcLM3 5ER5MiFpYCuo/za+uqzJjuWsmZs6uIRj4EgUPHvR4BOR5Tc/HgYYGVbsKHn0cYVK 0mNfWsABrbb4G2bsCI2Air/QPGGWrol52LDljt/Qf3JtveAIN1PIVBTkAomEp0bH Xw+N4IzTPWufJUuzKRH5z9FJY39sLqRHU02B27kHQnFQ71C6d6r1EZvQQ0sgWBdc 2DJKH4Y4vwYAWRj12h8MPqfdAv0CGlb1tMLjF8iQnrHwV7VvOgC47NMjIZ8HhtiJ CIohLIH4D4qijcl/0JwQlUNSNl3YapmKH7UQtYcnGIbmlAgNK7Aedk5UDal9AL28 F1M4Fs4IboBakD7aiXIOb4IPZJ8luUmqF65KJHhwtvRizm9aX7jbAcixVHjlb+Qx HwQ7jX9Um2CqqHrW6MMs =QCkz -----END PGP SIGNATURE----- --Yia77v5a8fyVHJSl-- From owner-freebsd-net@freebsd.org Sun Jan 24 05:33:36 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14282A8F42E for ; Sun, 24 Jan 2016 05:33:36 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9B9D1F9C for ; Sun, 24 Jan 2016 05:33:35 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lb0-x234.google.com with SMTP id bc4so59327396lbc.2 for ; Sat, 23 Jan 2016 21:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OjeXt6PvoHZ0/PLo+OsuFvDD0ZtX8vNebRSLM1dEaTM=; b=dU8zsr/De0w7l2rnQT3pqkVwKsNZJ02MkuaBzrGMWUsd9R28UKXaRVcc61XnWctxaj kl+KkAqi9zu9o2gUB1bgxOb7eTGntOr1sG+4PrmojY3aC6cDD+EogSfWP+l3bplRbOPj 6BU65OL0hzcQyo4OZDi2GGHrTAtHLtXOujOSab9Iw6+Lb5lHrIpCHPwox+CXU8jTQite Gg5BNf1/Ms3jkDhSfmB6p155RRnWhPAST/sT/KWFlwnYThtQ9jHxfCb7gFxoUXUs+f4n VYlPJxDZ7nz4yHaQsvcyyyCI1EvtvNMC1ajdoGj41qygcWQiieeWwFWP2QMbu4SftCVe jx8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OjeXt6PvoHZ0/PLo+OsuFvDD0ZtX8vNebRSLM1dEaTM=; b=R84u/UR3Te8zLMyTsA8ln+QRT1Y2y1lId2mu9orYWOrM0s/20lRzXorIC3yOWNf6ii SuBxmlMFfxCNcT4eXWD8CARqMzu59EJ9FT6+1W3WRQAJ2d45JKyJLcN4g8w/ENtKv5P7 zF0B5ixdVp1jjTyefI9DkGnTj95W/VHXSxFSUHNoD8UXkcvmuETaYqzKziVFRriT+Z5Z TxCdt114FPeCzfcTKhc8W6eh7DtSnbe0S+3T3kB4nqsAsEiHJ/4BozAiBZvpjFvgampn 2XABtz13vKKIhp+FxYzYkSRAKnQeyRaez9dF3bC00DhAWCvGsyYy2uuHUZDFpVi3PYmp /Ywg== X-Gm-Message-State: AG10YOSohi65mcfKSuGB5G6PIXONGmcKNTRNGbo3NnNkiZ/gf+cffYofJRLOl8YO5+q9QyY0jhE7Oewkz9qG4A== MIME-Version: 1.0 X-Received: by 10.112.155.201 with SMTP id vy9mr4020722lbb.54.1453613612821; Sat, 23 Jan 2016 21:33:32 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Sat, 23 Jan 2016 21:33:32 -0800 (PST) In-Reply-To: <20160124042830.3D674A0128@smtp.hushmail.com> References: <20160124042830.3D674A0128@smtp.hushmail.com> Date: Sat, 23 Jan 2016 21:33:32 -0800 X-Google-Sender-Auth: 3Bxfofm9CkPIKpYUMamslxVRnl4 Message-ID: Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: Luigi Rizzo To: Marcus Cenzatti Cc: "freebsd-net@freebsd.org" , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 05:33:36 -0000 On Sat, Jan 23, 2016 at 8:28 PM, Marcus Cenzatti wrote: > > > On 1/24/2016 at 1:10 AM, "Luigi Rizzo" wrote: >> >>Thanks for re-running the experiments. >> >>I am changing the subject so that in the archives it is clear >>that the chelsio card works fine. >> >>Overall the tests confirm that whenever you hit the host stack you >>are bound >>to the poor performance of the latter. The problem does not appear >>using intel >>as a receiver because on the intel card netmap mode disables the >>host stack. >> >>More comments on the experiments: >> >>The only meaningful test is the one where you use the DMAC of the >>ncxl0 port: >> >> SENDER: ./pkt-gen -i ix0 -f tx -S 00:07:e9:44:d2:ba -D >>00:07:43:33:8d:c1 >> >>in the other experiment you transmit broadcast frames and hit the >>network stack. >>ARP etc do not matter since tx and rx are directly connected. >> >>On the receiver you do not need to specify addresses: >> >> RECEIVER: ./pkt-gen -i ncxl0 -f rx >> >>The numbers in netstat are clearly rounded, so 15M is probably >>14.88M >>(line rate), and 3.7M that you see correctly represents the >>difference >>between incoming and received packets. >> >>The fact that you see drops may be related to the NIC being unable >>to >>replenish the queue fast enough, which in turn may be a hardware >>or a >>software (netmap) issue. >>You may try experiment with shorter batches on the receive side >>(say, -b 64 or less) and see if you have better results. >> >>A short batch replenishes the rx queue more frequently, but it is >>not a conclusive experiment because there is an optimization in >>the netmap poll code which, as an unintended side effect, >>replenishes >>the queue less often than it should. >>For a conclusive experiment you should grab the netmap code from >>github.com/luigirizzo/netmap and use pkt-gen-b which >>uses busy wait and works around the poll "optimization" >> >>thanks again for investigating the issue. >> >>cheers >>luigi >> > > so as a summary, with IP test on intel card, netmap disables the host stack while on chelsio netmap does not disable the host stack and we ket things injected to host, so the only reliable test is mac based when using chelsio cards? > > yes I am already running github's netmap code, let's try with busy code: ... > chelsio# ./pkt-gen-b -i ncxl0 -f rx > 785.659290 main [1930] interface is ncxl0 > 785.659337 main [2050] running on 1 cpus (have 4) > 785.659477 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 > 785.659496 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 > 785.718707 main [2148] mapped 334980KB at 0x801800000 > Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. > 785.718784 main [2235] Wait 2 secs for phy reset > 787.729197 main [2237] Ready... > 787.729449 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 > 788.730089 main_thread [1720] 11.159 Mpps (11.166 Mpkts 5.360 Gbps in 1000673 usec) 205.89 avg_batch 0 min_space > 789.730588 main_thread [1720] 11.164 Mpps (11.169 Mpkts 5.361 Gbps in 1000500 usec) 183.54 avg_batch 0 min_space > 790.734224 main_thread [1720] 11.172 Mpps (11.213 Mpkts 5.382 Gbps in 1003636 usec) 198.84 avg_batch 0 min_space > ^C791.140853 sigint_h [404] received control-C on thread 0x801406800 > 791.742841 main_thread [1720] 4.504 Mpps (4.542 Mpkts 2.180 Gbps in 1008617 usec) 179.62 avg_batch 0 min_space > Received 38091031 packets 2285461860 bytes 196774 events 60 bytes each in 3.41 seconds. > Speed: 11.166 Mpps Bandwidth: 5.360 Gbps (raw 7.504 Gbps). Average batch: 193.58 pkts > > chelsio# ./pkt-gen-b -b 64 -i ncxl0 -f rx > 522.430459 main [1930] interface is ncxl0 > 522.430507 main [2050] running on 1 cpus (have 4) > 522.430644 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 > 522.430662 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 > 522.677743 main [2148] mapped 334980KB at 0x801800000 > Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. > 522.677822 main [2235] Wait 2 secs for phy reset > 524.698114 main [2237] Ready... > 524.698373 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 > 525.699118 main_thread [1720] 10.958 Mpps (10.966 Mpkts 5.264 Gbps in 1000765 usec) 61.84 avg_batch 0 min_space > 526.700108 main_thread [1720] 11.086 Mpps (11.097 Mpkts 5.327 Gbps in 1000991 usec) 61.06 avg_batch 0 min_space > 527.705650 main_thread [1720] 11.166 Mpps (11.227 Mpkts 5.389 Gbps in 1005542 usec) 61.91 avg_batch 0 min_space > 528.707113 main_thread [1720] 11.090 Mpps (11.107 Mpkts 5.331 Gbps in 1001463 usec) 61.34 avg_batch 0 min_space > 529.707617 main_thread [1720] 10.847 Mpps (10.853 Mpkts 5.209 Gbps in 1000504 usec) 62.51 avg_batch 0 min_space > ^C530.556309 sigint_h [404] received control-C on thread 0x801406800 > 530.709133 main_thread [1720] 9.166 Mpps (9.180 Mpkts 4.406 Gbps in 1001516 usec) 62.92 avg_batch 0 min_space > Received 64430028 packets 3865801680 bytes 1041000 events 60 bytes each in 5.86 seconds. > Speed: 10.999 Mpps Bandwidth: 5.279 Gbps (raw 7.391 Gbps). Average batch: 61.89 pkts ... > so, the lower the batch the smaller performance. > > did you expect some other behaviour? for very small batches, yes. For larger batch sizes I was hoping that refilling the ring more often could reduce losses. One last attempt: try use -l 64 on the sender, this will generate 64+4 byte packets, which may become just 64 on the receiver if the chelsio is configured to strip the CRC. This should result in well aligned PCIe transactions and reduced PCIe traffic, which may help (the ix driver has a similar problem, but since it does not strip the CRC can rx at line rate with 60 bytes but not with 64). If this does not help we should ask Navdeep if he knows what the NIC is capable of. cheers luigi > > thank you very much again > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Sun Jan 24 06:07:12 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9884AA8FBFD for ; Sun, 24 Jan 2016 06:07:12 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62D071B10; Sun, 24 Jan 2016 06:07:12 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pf0-x235.google.com with SMTP id e65so64788000pfe.0; Sat, 23 Jan 2016 22:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=u/9HJ4K2Q0KzYBBODGgSyyU36QrBiTgTYaD9XpyCV7U=; b=TSad/gUPVFyh6hPnnLTG+TxhnvdXCldDnVz3diQDiZBq992fFtQdE+qe15pWKblwZb uYbo/b/j3eu8KeXCg085k9432Plykw2cp4Duc4j+WsYlIILq7VxFjpiIaFauUhvDyTLl 9wBxtuIslCV1ClJpzolsBaiLRQYSL1z5MWidxqFp+hmZVzhOevT3IGNGhlT0eSti4Vag zJQOB3tV1HLDWl+4xhRnEqDFS/+bWi3upBJVS4YOKzZilOyIch0J9VIBJAVq/6nPy6n/ SFdV6jKar763F+3dik5KUvYVCUHZ6LoK5Q3CZyRznSi/1QMeVxwixlRcRStZsTwz5IuP gLKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=u/9HJ4K2Q0KzYBBODGgSyyU36QrBiTgTYaD9XpyCV7U=; b=JcOQ0rNW/yAlapajP48dWzm3ONW6Tykf9o4pA1sz3mYPMrv2bXa8KtwyyqHN/fWPbJ jQqhaDorpSnmhp0o5hoYpAfS9jW20SB6EZsKuLp2CUd6tgum3l/aXQIoLY7YgpV5TI7s Rhzr5uM0ptZl2h4WZugUob0ArV3rYo6UfMBB0XxphZ99QcBr3BLPdoUT/LQt2qB/yyOW B5rQK268URxr5ankfBZDk4IQGyHWCcOgJu/2OPigSwvwBSZ1hhee6S0AEZ9GusocyggP XJQ7LWujYT1Rg/P/S0U+HuKM8U+dW2fBcW13vzqbqFhteIH/nunhFdExXEg2dRxLsmzm v1fA== X-Gm-Message-State: AG10YOQ+aCkzQOuWuX24H8kZby2D35kSPQpL+1RRDuz4iq9rtg8epDfIEo8US/9zKzGn1Q== X-Received: by 10.98.42.213 with SMTP id q204mr16559013pfq.141.1453615632081; Sat, 23 Jan 2016 22:07:12 -0800 (PST) Received: from ox ([2601:641:c001:8a00:591d:d471:ff4a:b8bf]) by smtp.gmail.com with ESMTPSA id 75sm19828282pfj.20.2016.01.23.22.07.10 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sat, 23 Jan 2016 22:07:10 -0800 (PST) Date: Sat, 23 Jan 2016 22:07:06 -0800 From: Navdeep Parhar To: Adrian Chadd Cc: Marcus Cenzatti , Luigi Rizzo , FreeBSD Net Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX Message-ID: <20160124060706.GA7567@ox> Mail-Followup-To: Adrian Chadd , Marcus Cenzatti , Luigi Rizzo , FreeBSD Net References: <20160124035300.3E533A0126@smtp.hushmail.com> <20160124043050.A4936A0126@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 06:07:12 -0000 On Sat, Jan 23, 2016 at 08:38:24PM -0800, Adrian Chadd wrote: > ok, that's a discussion to have with navdeep. That /should/ work. > Someone may have changed it lately. Yes this used to work. > > Things should behave very well and predictable once you can disable > cxl0 but not ncxl0. :-P The plan is to clean all this up by moving the netmap specific parts to a driver module of its own. So when you load if_cxgbe you'll get only the cxl interfaces. If you want netmap access to the ports you'll be able to kldload cxgbe_netmap (or something like that) which will create the ncxl ports. These ncxl ports _will_ operate like normal ifnets hooked to the kernel stack if netmap isn't enabled on them. And the cxgbe_netmap driver will attach to PCIe PFs 0-3 so it won't take up resources (interrupt vectors, etc.) from PF4, which is what the main if_cxgbe attaches to. You'll certainly be able to up/down/whatever all the interfaces independent of each other. All this will get done in time for FreeBSD 11. Regards, Navdeep From owner-freebsd-net@freebsd.org Sun Jan 24 06:42:22 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AA16A8E78B for ; Sun, 24 Jan 2016 06:42:22 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 224EA1CB0 for ; Sun, 24 Jan 2016 06:42:21 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pa0-x230.google.com with SMTP id uo6so65083092pac.1 for ; Sat, 23 Jan 2016 22:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=IPpVXrpgTLCC3u1QkuKpQ7P4tE5mSP9yGggEidCoQ70=; b=x7bzNb5cKqU5ObyGZMQhS6YG2YwwyCIXloFwG7FBw9nFsz6Xa4B36Pq6Wh6UF1LYxd gWqSYRP0ObMAKNDU4lfnOlKYfi75AibaTf8igfdvH/6hskuiUNkvCac9g/7rZt9GDbJe 6DCuX2vUJCJz6eJt3+BVRH+cqf90kPdsuReW0jkgSb1cu72IAFlJH0AX7qAVbAB2bOkO +dPmRHSMV0nWj5zqgYn/XVWu3EduBEJAq+YP9xu3dDbfYTHcRYg8LN2oQjNjQkceb2ud 3t9JCrVKYl7KcI3A3fhiSx8xxhZ4RYKIPhnQnIgJcRZyQbr0TL3bXCmodIf3lwmiEkmQ XXMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=IPpVXrpgTLCC3u1QkuKpQ7P4tE5mSP9yGggEidCoQ70=; b=PJO9rb2K7OvBOqA8z0tJBcXCR4qxXaGQZqL3zjUnkB7Nu/ldd9qmr6Zna/4nn47jHb hC+jhopVPKRJ/xMaL4yyP9SZRijWLnuUmCulRwtVyhrzloyYBUm9RcBKPId41376yEHM ZCPV7JiiUYybYS9bojMHGG5dnvuVdYsDTmTWme69j7bM2ShfjmBZb6ADC/9jA8MAmQLX MihbUff0b13M1AKdgMB6ypqfEe5UowUtkRRdwD9T1wgqqLt44F46BQeA+wffD2Oj3lpP RCxctUfjhCESvtPGqk+O4nc12B2xsOmgCr9W2pE3qz55lPJ+Jj4NzNEbsP/Gt3v9XcOJ od4g== X-Gm-Message-State: AG10YOT6ZNkVWfZikN+aUlcH68BdaQA0hp+oCoBeQK9BIsbp8nUY/ZeJZNT8vgPmB6TgQQ== X-Received: by 10.66.237.66 with SMTP id va2mr16859920pac.87.1453617741642; Sat, 23 Jan 2016 22:42:21 -0800 (PST) Received: from ox ([2601:641:c001:8a00:591d:d471:ff4a:b8bf]) by smtp.gmail.com with ESMTPSA id u69sm19951512pfa.61.2016.01.23.22.42.19 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sat, 23 Jan 2016 22:42:20 -0800 (PST) Date: Sat, 23 Jan 2016 22:42:17 -0800 From: Navdeep Parhar To: Luigi Rizzo Cc: Marcus Cenzatti , "freebsd-net@freebsd.org" Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX Message-ID: <20160124064217.GB7567@ox> Mail-Followup-To: Luigi Rizzo , Marcus Cenzatti , "freebsd-net@freebsd.org" References: <20160124042830.3D674A0128@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 06:42:22 -0000 On Sat, Jan 23, 2016 at 09:33:32PM -0800, Luigi Rizzo wrote: > On Sat, Jan 23, 2016 at 8:28 PM, Marcus Cenzatti wrote: > > > > > > On 1/24/2016 at 1:10 AM, "Luigi Rizzo" wrote: > >> > >>Thanks for re-running the experiments. > >> > >>I am changing the subject so that in the archives it is clear > >>that the chelsio card works fine. > >> > >>Overall the tests confirm that whenever you hit the host stack you > >>are bound > >>to the poor performance of the latter. The problem does not appear > >>using intel > >>as a receiver because on the intel card netmap mode disables the > >>host stack. > >> > >>More comments on the experiments: > >> > >>The only meaningful test is the one where you use the DMAC of the > >>ncxl0 port: > >> > >> SENDER: ./pkt-gen -i ix0 -f tx -S 00:07:e9:44:d2:ba -D > >>00:07:43:33:8d:c1 > >> > >>in the other experiment you transmit broadcast frames and hit the > >>network stack. > >>ARP etc do not matter since tx and rx are directly connected. > >> > >>On the receiver you do not need to specify addresses: > >> > >> RECEIVER: ./pkt-gen -i ncxl0 -f rx > >> > >>The numbers in netstat are clearly rounded, so 15M is probably > >>14.88M > >>(line rate), and 3.7M that you see correctly represents the > >>difference > >>between incoming and received packets. > >> > >>The fact that you see drops may be related to the NIC being unable > >>to > >>replenish the queue fast enough, which in turn may be a hardware > >>or a > >>software (netmap) issue. > >>You may try experiment with shorter batches on the receive side > >>(say, -b 64 or less) and see if you have better results. > >> > >>A short batch replenishes the rx queue more frequently, but it is > >>not a conclusive experiment because there is an optimization in > >>the netmap poll code which, as an unintended side effect, > >>replenishes > >>the queue less often than it should. > >>For a conclusive experiment you should grab the netmap code from > >>github.com/luigirizzo/netmap and use pkt-gen-b which > >>uses busy wait and works around the poll "optimization" > >> > >>thanks again for investigating the issue. > >> > >>cheers > >>luigi > >> > > > > so as a summary, with IP test on intel card, netmap disables the host stack while on chelsio netmap does not disable the host stack and we ket things injected to host, so the only reliable test is mac based when using chelsio cards? > > > > yes I am already running github's netmap code, let's try with busy code: > ... > > chelsio# ./pkt-gen-b -i ncxl0 -f rx > > 785.659290 main [1930] interface is ncxl0 > > 785.659337 main [2050] running on 1 cpus (have 4) > > 785.659477 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 > > 785.659496 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 > > 785.718707 main [2148] mapped 334980KB at 0x801800000 > > Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. > > 785.718784 main [2235] Wait 2 secs for phy reset > > 787.729197 main [2237] Ready... > > 787.729449 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 > > 788.730089 main_thread [1720] 11.159 Mpps (11.166 Mpkts 5.360 Gbps in 1000673 usec) 205.89 avg_batch 0 min_space > > 789.730588 main_thread [1720] 11.164 Mpps (11.169 Mpkts 5.361 Gbps in 1000500 usec) 183.54 avg_batch 0 min_space > > 790.734224 main_thread [1720] 11.172 Mpps (11.213 Mpkts 5.382 Gbps in 1003636 usec) 198.84 avg_batch 0 min_space > > ^C791.140853 sigint_h [404] received control-C on thread 0x801406800 > > 791.742841 main_thread [1720] 4.504 Mpps (4.542 Mpkts 2.180 Gbps in 1008617 usec) 179.62 avg_batch 0 min_space > > Received 38091031 packets 2285461860 bytes 196774 events 60 bytes each in 3.41 seconds. > > Speed: 11.166 Mpps Bandwidth: 5.360 Gbps (raw 7.504 Gbps). Average batch: 193.58 pkts > > > > chelsio# ./pkt-gen-b -b 64 -i ncxl0 -f rx > > 522.430459 main [1930] interface is ncxl0 > > 522.430507 main [2050] running on 1 cpus (have 4) > > 522.430644 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 > > 522.430662 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 > > 522.677743 main [2148] mapped 334980KB at 0x801800000 > > Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. > > 522.677822 main [2235] Wait 2 secs for phy reset > > 524.698114 main [2237] Ready... > > 524.698373 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 > > 525.699118 main_thread [1720] 10.958 Mpps (10.966 Mpkts 5.264 Gbps in 1000765 usec) 61.84 avg_batch 0 min_space > > 526.700108 main_thread [1720] 11.086 Mpps (11.097 Mpkts 5.327 Gbps in 1000991 usec) 61.06 avg_batch 0 min_space > > 527.705650 main_thread [1720] 11.166 Mpps (11.227 Mpkts 5.389 Gbps in 1005542 usec) 61.91 avg_batch 0 min_space > > 528.707113 main_thread [1720] 11.090 Mpps (11.107 Mpkts 5.331 Gbps in 1001463 usec) 61.34 avg_batch 0 min_space > > 529.707617 main_thread [1720] 10.847 Mpps (10.853 Mpkts 5.209 Gbps in 1000504 usec) 62.51 avg_batch 0 min_space > > ^C530.556309 sigint_h [404] received control-C on thread 0x801406800 > > 530.709133 main_thread [1720] 9.166 Mpps (9.180 Mpkts 4.406 Gbps in 1001516 usec) 62.92 avg_batch 0 min_space > > Received 64430028 packets 3865801680 bytes 1041000 events 60 bytes each in 5.86 seconds. > > Speed: 10.999 Mpps Bandwidth: 5.279 Gbps (raw 7.391 Gbps). Average batch: 61.89 pkts > ... > > > so, the lower the batch the smaller performance. > > > > did you expect some other behaviour? > > > for very small batches, yes. > For larger batch sizes I was hoping that refilling the ring more often > could reduce losses. > > One last attempt: try use -l 64 on the sender, this will generate 64+4 byte > packets, which may become just 64 on the receiver if the chelsio is configured > to strip the CRC. This should result in well aligned PCIe transactions and > reduced PCIe traffic, which may help (the ix driver has a similar problem, > but since it does not strip the CRC can rx at line rate with 60 bytes but not > with 64). Keep hw.cxgbe.fl_pktshift in mind for these kind of tests. The default value is 2 so the chip DMAs payload at an offset of 2B from the start of the rx buffer. So you'll need to adjust your frame size by 2 (66B on the wire, 62B after CRC is removed, making it exactly 64B across PCIe if pktshift is 2) or just set hw.cxgbe.fl_pktshift=0 in /boot/loader.conf. Regards, Navdeep From owner-freebsd-net@freebsd.org Sun Jan 24 07:01:03 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1C94A8ECB7 for ; Sun, 24 Jan 2016 07:01:03 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85F9F112D for ; Sun, 24 Jan 2016 07:01:02 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) by smtp3.hushmail.com (Postfix) with SMTP id 869B5E01E5 for ; Sun, 24 Jan 2016 07:00:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=R6Wlcsq/YXds3J4onpw1703vc7bf0DtKXSgGQsVk3d4=; b=uBAzFKEAzto/xgK5myNmlDcBDMPWc2F3jl97L3JWAM0vnA1JI1DmxSlF4no3gOgRjVKE94j+jvXKx2aHYZ+iyoxF+7Hr3uOewFsOJUML9ffniAb202WQtq8BYTpRq4h4vDU2owJnLqeRmb7ZCe9MK/4BjzdFsjVkHW/kKOAFdXxkgqxHPzVFNwgTMEZBIDoB6tXjTE7RhdrrEJn1QYmlJwLg4USj879o7ytoc6bIdYFZryEBXvFKCPVRRq35oYLPJ+GqWqxTjuFQdnpJG4vi/IywaiTcAABt82ZThT/c3KWcepgOIQnzJyRigaBJhUgZaQQ1bM6qJRpuJsw9SQG7yw== Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp3.hushmail.com (Postfix) with ESMTP; Sun, 24 Jan 2016 07:00:56 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 4EC5CA0126; Sun, 24 Jan 2016 07:00:56 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 24 Jan 2016 05:00:55 -0200 To: "Luigi Rizzo" Cc: freebsd-net@freebsd.org, "Navdeep Parhar" Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: "Marcus Cenzatti" In-Reply-To: References: <20160124042830.3D674A0128@smtp.hushmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20160124070056.4EC5CA0126@smtp.hushmail.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 07:01:03 -0000 On 1/24/2016 at 3:33 AM, "Luigi Rizzo" wrote: > >On Sat, Jan 23, 2016 at 8:28 PM, Marcus Cenzatti > wrote: >> >> >> On 1/24/2016 at 1:10 AM, "Luigi Rizzo" >wrote: >>> >>>Thanks for re-running the experiments. >>> >>>I am changing the subject so that in the archives it is clear >>>that the chelsio card works fine. >>> >>>Overall the tests confirm that whenever you hit the host stack >you >>>are bound >>>to the poor performance of the latter. The problem does not >appear >>>using intel >>>as a receiver because on the intel card netmap mode disables the >>>host stack. >>> >>>More comments on the experiments: >>> >>>The only meaningful test is the one where you use the DMAC of the >>>ncxl0 port: >>> >>> SENDER: ./pkt-gen -i ix0 -f tx -S 00:07:e9:44:d2:ba -D >>>00:07:43:33:8d:c1 >>> >>>in the other experiment you transmit broadcast frames and hit the >>>network stack. >>>ARP etc do not matter since tx and rx are directly connected. >>> >>>On the receiver you do not need to specify addresses: >>> >>> RECEIVER: ./pkt-gen -i ncxl0 -f rx >>> >>>The numbers in netstat are clearly rounded, so 15M is probably >>>14.88M >>>(line rate), and 3.7M that you see correctly represents the >>>difference >>>between incoming and received packets. >>> >>>The fact that you see drops may be related to the NIC being >unable >>>to >>>replenish the queue fast enough, which in turn may be a hardware >>>or a >>>software (netmap) issue. >>>You may try experiment with shorter batches on the receive side >>>(say, -b 64 or less) and see if you have better results. >>> >>>A short batch replenishes the rx queue more frequently, but it is >>>not a conclusive experiment because there is an optimization in >>>the netmap poll code which, as an unintended side effect, >>>replenishes >>>the queue less often than it should. >>>For a conclusive experiment you should grab the netmap code from >>>github.com/luigirizzo/netmap and use pkt-gen-b which >>>uses busy wait and works around the poll "optimization" >>> >>>thanks again for investigating the issue. >>> >>>cheers >>>luigi >>> >> >> so as a summary, with IP test on intel card, netmap disables the >host stack while on chelsio netmap does not disable the host stack >and we ket things injected to host, so the only reliable test is >mac based when using chelsio cards? >> >> yes I am already running github's netmap code, let's try with >busy code: >... >> chelsio# ./pkt-gen-b -i ncxl0 -f rx >> 785.659290 main [1930] interface is ncxl0 >> 785.659337 main [2050] running on 1 cpus (have 4) >> 785.659477 extract_ip_range [367] range is 10.0.0.1:0 to >10.0.0.1:0 >> 785.659496 extract_ip_range [367] range is 10.1.0.1:0 to >10.1.0.1:0 >> 785.718707 main [2148] mapped 334980KB at 0x801800000 >> Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. >> 785.718784 main [2235] Wait 2 secs for phy reset >> 787.729197 main [2237] Ready... >> 787.729449 receiver_body [1412] reading from netmap:ncxl0 fd 3 >main_fd 3 >> 788.730089 main_thread [1720] 11.159 Mpps (11.166 Mpkts 5.360 >Gbps in 1000673 usec) 205.89 avg_batch 0 min_space >> 789.730588 main_thread [1720] 11.164 Mpps (11.169 Mpkts 5.361 >Gbps in 1000500 usec) 183.54 avg_batch 0 min_space >> 790.734224 main_thread [1720] 11.172 Mpps (11.213 Mpkts 5.382 >Gbps in 1003636 usec) 198.84 avg_batch 0 min_space >> ^C791.140853 sigint_h [404] received control-C on thread >0x801406800 >> 791.742841 main_thread [1720] 4.504 Mpps (4.542 Mpkts 2.180 Gbps >in 1008617 usec) 179.62 avg_batch 0 min_space >> Received 38091031 packets 2285461860 bytes 196774 events 60 >bytes each in 3.41 seconds. >> Speed: 11.166 Mpps Bandwidth: 5.360 Gbps (raw 7.504 Gbps). >Average batch: 193.58 pkts >> >> chelsio# ./pkt-gen-b -b 64 -i ncxl0 -f rx >> 522.430459 main [1930] interface is ncxl0 >> 522.430507 main [2050] running on 1 cpus (have 4) >> 522.430644 extract_ip_range [367] range is 10.0.0.1:0 to >10.0.0.1:0 >> 522.430662 extract_ip_range [367] range is 10.1.0.1:0 to >10.1.0.1:0 >> 522.677743 main [2148] mapped 334980KB at 0x801800000 >> Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. >> 522.677822 main [2235] Wait 2 secs for phy reset >> 524.698114 main [2237] Ready... >> 524.698373 receiver_body [1412] reading from netmap:ncxl0 fd 3 >main_fd 3 >> 525.699118 main_thread [1720] 10.958 Mpps (10.966 Mpkts 5.264 >Gbps in 1000765 usec) 61.84 avg_batch 0 min_space >> 526.700108 main_thread [1720] 11.086 Mpps (11.097 Mpkts 5.327 >Gbps in 1000991 usec) 61.06 avg_batch 0 min_space >> 527.705650 main_thread [1720] 11.166 Mpps (11.227 Mpkts 5.389 >Gbps in 1005542 usec) 61.91 avg_batch 0 min_space >> 528.707113 main_thread [1720] 11.090 Mpps (11.107 Mpkts 5.331 >Gbps in 1001463 usec) 61.34 avg_batch 0 min_space >> 529.707617 main_thread [1720] 10.847 Mpps (10.853 Mpkts 5.209 >Gbps in 1000504 usec) 62.51 avg_batch 0 min_space >> ^C530.556309 sigint_h [404] received control-C on thread >0x801406800 >> 530.709133 main_thread [1720] 9.166 Mpps (9.180 Mpkts 4.406 Gbps >in 1001516 usec) 62.92 avg_batch 0 min_space >> Received 64430028 packets 3865801680 bytes 1041000 events 60 >bytes each in 5.86 seconds. >> Speed: 10.999 Mpps Bandwidth: 5.279 Gbps (raw 7.391 Gbps). >Average batch: 61.89 pkts >... > >> so, the lower the batch the smaller performance. >> >> did you expect some other behaviour? > > >for very small batches, yes. >For larger batch sizes I was hoping that refilling the ring more >often >could reduce losses. > >One last attempt: try use -l 64 on the sender, this will generate >64+4 byte >packets, which may become just 64 on the receiver if the chelsio >is configured >to strip the CRC. This should result in well aligned PCIe >transactions and >reduced PCIe traffic, which may help (the ix driver has a similar >problem, >but since it does not strip the CRC can rx at line rate with 60 >bytes but not >with 64). > >If this does not help we should ask Navdeep if he knows what the >NIC >is capable of. > >cheers >luigi ok here it is this lowered pps rate to 9.4Mpps on chelsio (we had 11Mpps with defaul len) and lowered rates to 14Mpps on sender (we had 14.8Mpps before). intel# netmap-master/examples/pkt-gen-b -l 64 -i ix0 -f tx -S 00:07:e9:44:d2:ba -D 00:07:43:33:8d:c1 071.547164 main [1930] interface is ix0 071.547203 main [2050] running on 1 cpus (have 8) 071.547222 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 071.547232 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 071.652590 main [2148] mapped 334980KB at 0x801800000 Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:07:e9:44:d2:ba -> 00:07:43:33:8d:c1) 071.652665 main [2233] Sending 512 packets every 0.000000000 s 071.652670 main [2235] Wait 2 secs for phy reset 073.662663 main [2237] Ready... 073.662902 sender_body [1211] start, fd 3 main_fd 3 073.702057 sender_body [1293] drop copy 074.664337 main_thread [1720] 13.627 Mpps (13.646 Mpkts 6.987 Gbps in 1001450 usec) 423.69 avg_batch 0 min_space (...) 113.849333 main_thread [1720] 14.133 Mpps (14.147 Mpkts 7.243 Gbps in 1001001 usec) 412.94 avg_batch 99999 min_space ^C114.141717 sigint_h [404] received control-C on thread 0x801406800 114.141968 sender_body [1326] flush tail 360 head 1512 on thread 0x801406800 114.142212 sender_body [1334] pending tx tail 99 head 612 on ring 0 114.142267 sender_body [1334] pending tx tail 1000 head 1050 on ring 4 114.142299 sender_body [1334] pending tx tail 115 head 125 on ring 5 114.857560 main_thread [1720] 4.057 Mpps (4.090 Mpkts 2.094 Gbps in 1008227 usec) 421.75 avg_batch 99999 min_space Sent 570189473 packets 36492126272 bytes 1429432 events 64 bytes each in 40.48 seconds. Speed: 14.086 Mpps Bandwidth: 7.212 Gbps (raw 9.917 Gbps). Average batch: 398.89 pkts chelsio# ./pkt-gen-b -i ncxl0 -f rx 149.133685 main [1930] interface is ncxl0 149.133732 main [2050] running on 1 cpus (have 4) 149.133870 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 149.133889 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 149.192708 main [2148] mapped 334980KB at 0x801800000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 149.192783 main [2235] Wait 2 secs for phy reset 151.296102 main [2237] Ready... 151.296365 receiver_body [1412] reading from netmap:ncxl0 fd 3 main_fd 3 (..) 187.589094 main_thread [1720] 3.386 Mpps (3.396 Mpkts 1.739 Gbps in 1003011 usec) 174.46 avg_batch 0 min_space 188.590084 main_thread [1720] 9.470 Mpps (9.480 Mpkts 4.854 Gbps in 1000990 usec) 149.61 avg_batch 0 min_space 189.590591 main_thread [1720] 9.466 Mpps (9.471 Mpkts 4.849 Gbps in 1000507 usec) 164.13 avg_batch 0 min_space 190.608590 main_thread [1720] 9.470 Mpps (9.640 Mpkts 4.936 Gbps in 1017999 usec) 144.30 avg_batch 0 min_space 191.609584 main_thread [1720] 9.471 Mpps (9.481 Mpkts 4.854 Gbps in 1000994 usec) 158.99 avg_batch 0 min_space 192.610594 main_thread [1720] 9.470 Mpps (9.480 Mpkts 4.854 Gbps in 1001010 usec) 148.97 avg_batch 0 min_space 193.614357 main_thread [1720] 9.471 Mpps (9.507 Mpkts 4.867 Gbps in 1003763 usec) 168.09 avg_batch 0 min_space 194.614582 main_thread [1720] 9.469 Mpps (9.471 Mpkts 4.849 Gbps in 1000225 usec) 160.39 avg_batch 0 min_space 195.615590 main_thread [1720] 9.470 Mpps (9.480 Mpkts 4.854 Gbps in 1001008 usec) 151.97 avg_batch 0 min_space 196.617080 main_thread [1720] 9.471 Mpps (9.485 Mpkts 4.856 Gbps in 1001490 usec) 171.75 avg_batch 0 min_space 197.618083 main_thread [1720] 9.471 Mpps (9.480 Mpkts 4.854 Gbps in 1001003 usec) 164.99 avg_batch 0 min_space 198.619718 main_thread [1720] 9.471 Mpps (9.486 Mpkts 4.857 Gbps in 1001636 usec) 153.07 avg_batch 0 min_space 199.620607 main_thread [1720] 9.467 Mpps (9.476 Mpkts 4.852 Gbps in 1000888 usec) 153.94 avg_batch 0 min_space 200.622081 main_thread [1720] 9.471 Mpps (9.485 Mpkts 4.856 Gbps in 1001474 usec) 161.03 avg_batch 0 min_space 201.622582 main_thread [1720] 9.471 Mpps (9.476 Mpkts 4.852 Gbps in 1000501 usec) 168.47 avg_batch 0 min_space 202.632223 main_thread [1720] 9.470 Mpps (9.561 Mpkts 4.895 Gbps in 1009641 usec) 145.45 avg_batch 0 min_space 203.633077 main_thread [1720] 9.471 Mpps (9.479 Mpkts 4.853 Gbps in 1000854 usec) 170.21 avg_batch 0 min_space 204.633586 main_thread [1720] 9.467 Mpps (9.472 Mpkts 4.850 Gbps in 1000509 usec) 160.41 avg_batch 0 min_space 205.640364 main_thread [1720] 9.471 Mpps (9.535 Mpkts 4.882 Gbps in 1006778 usec) 171.47 avg_batch 0 min_space 206.641075 main_thread [1720] 9.471 Mpps (9.478 Mpkts 4.853 Gbps in 1000711 usec) 169.56 avg_batch 0 min_space 207.642079 main_thread [1720] 9.471 Mpps (9.480 Mpkts 4.854 Gbps in 1001004 usec) 158.71 avg_batch 0 min_space 208.642581 main_thread [1720] 9.471 Mpps (9.475 Mpkts 4.851 Gbps in 1000502 usec) 172.57 avg_batch 0 min_space ^C208.909765 sigint_h [404] received control-C on thread 0x801406800 209.650597 main_thread [1720] 2.510 Mpps (2.530 Mpkts 1.296 Gbps in 1008016 usec) 172.19 avg_batch 0 min_space Received 205307453 packets 13139666672 bytes 1283636 events 63 bytes each in 57.61 seconds. Speed: 9.364 Mpps Bandwidth: 8.825 Gbps (raw 9.509 Gbps). Average batch: 159.94 pkts this is repeatable, 11Mpps/RX <== 14.8Mpps/TX without -l 64 and 9.4Mpps <== 14Mpps with -l 64 for all testing sessions executed From owner-freebsd-net@freebsd.org Sun Jan 24 07:17:15 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73445A8F19D for ; Sun, 24 Jan 2016 07:17:15 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE74A19B3 for ; Sun, 24 Jan 2016 07:17:14 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id 17so68388539lfz.1 for ; Sat, 23 Jan 2016 23:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qTml7klnHnm/ZpszCpyeM2ay7E2P2TAuEAk2OoPpLjc=; b=Vvq+C8SNVtoZ2FfyWlt8xRYvx4EJ1GiwhD5bIfunjAbkqlqez1aYqmhs56lw+cZHzY 8BoC/Dhe7Jl1T5lzX0ZXsijW9N+2JhPdGugXr9I+jXYQvpNLXvioVxbdNRm9ODwYxsbb hGI9GWpzSkTkklHEogoP+Uyg3na7JuS/0tpRPc5UCzyfXCIkHZjQzAjwFAPfkYKbgcMk 9A4y9tydeIIElrYf575ElnQKyn6wiKKRJpHH0Uo5jdVdQfAq6geLHs0saA8nRBZG8D2G hG1ASc5iMeYEShMSSXtiyAeBI1+VsFdIoSVZhDmvtv5RVMKjCVJiABQ6kHE1N66jVN76 Xezg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qTml7klnHnm/ZpszCpyeM2ay7E2P2TAuEAk2OoPpLjc=; b=eNvNXunzEgsoWtQG4zkQxGZiYeu4c2u2+PAMFkawGSScWr3Jtz6EFK3xf9JPUvr5BS 6f9sTxMyAVObQHLJQ1JtViDgjO5q2wZ1lUMONar73pryvxXy05ldCoN+UxTqIIxiaOku +pOHDQftuJ6NsMIiBBVrIHYQTDKAAy1SjeOAaZjy+9zYDGt8B3YbVIw9l05+kJuguez4 6Vb5KxWfT4Ts+Rf38gzqupLSFo2xpFOWsHqSxpMvfGD7Ek5SO9FXHduPEs8D0YL9yVxe 3wIn30FCtILsNyZq+sncTet2uiP1ZBBQL1tlLWa2K/9rjPXzKKlH4pMysdoFfdtbnqm9 O5VQ== X-Gm-Message-State: AG10YOQ5nK8iS1cVlnDPK5VRrMZk5c3g1sb5qXKb2GMGtFtyvMey6AoiD3twfs95gOqAWaefPYSW+HGIlNI71g== MIME-Version: 1.0 X-Received: by 10.25.143.17 with SMTP id r17mr4204537lfd.37.1453619833110; Sat, 23 Jan 2016 23:17:13 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Sat, 23 Jan 2016 23:17:13 -0800 (PST) In-Reply-To: <20160124070056.4EC5CA0126@smtp.hushmail.com> References: <20160124042830.3D674A0128@smtp.hushmail.com> <20160124070056.4EC5CA0126@smtp.hushmail.com> Date: Sat, 23 Jan 2016 23:17:13 -0800 X-Google-Sender-Auth: eB1Eep0LMRq-jwDjdZ5FU7riI9M Message-ID: Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: Luigi Rizzo To: Marcus Cenzatti Cc: "freebsd-net@freebsd.org" , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 07:17:15 -0000 On Sat, Jan 23, 2016 at 11:00 PM, Marcus Cenzatti wrote: > > > On 1/24/2016 at 3:33 AM, "Luigi Rizzo" wrote: ... > ok here it is > > this lowered pps rate to 9.4Mpps on chelsio (we had 11Mpps with defaul len) and lowered rates to 14Mpps on sender (we had 14.8Mpps before). see the other email from navdeep, he suggests to try -l 62 because the chelsio saves the packet with a 2-byte offset into the buffer (it puzzles me a bit that it does so also in netmap mode though). cheers luigi From owner-freebsd-net@freebsd.org Sun Jan 24 07:23:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 211BAA8F40D for ; Sun, 24 Jan 2016 07:23:05 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BBCB1D71 for ; Sun, 24 Jan 2016 07:23:04 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id m198so68524531lfm.0 for ; Sat, 23 Jan 2016 23:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=qmQgtJ9h6EOwgB7X8+Lz0O4xFcymzN5bQKqYjt7WR30=; b=rZh5Qc/j1oK5RcZmO2g8u06LcMi35KvgEh4Qn0M29odZrmBK9rrK3n0Bkld+QAqAUs As7qBw7CMH7ojcy9HtU9463FhdgtL0qrXeAUhHwgaHhzeuOXcUae1Jy3qNrmMhS3cm8I nR3NRPs4i+FOdmV+bPrGj5XCPmBhax62dBLj5lavnvam8ytCk45zXzNgntU86v7t2R/E 4DnmP1Jk0kUxlxxATN8wzgvGl+XnKV5XJsQepKw3YhMF7cxs6k5L9HoCS0hv6Igif42I yh0lRk9UU9e217XjsHXwDwVIfkgRawtI+5IYPe4XlKAuGWCqUC05ftG4Lw3tq+r1lJ7p JJsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=qmQgtJ9h6EOwgB7X8+Lz0O4xFcymzN5bQKqYjt7WR30=; b=dUbzNGhmdIBD/ySUMUmoX/UEpp0LZGji28DbfxIlBG5eT6PJ/Z3LdMnMnFij4U76Ct G83tJNBpddwlNDCgLztLhruDLDVJ2ZyHS5UXD+R6myGKL2UT9ybtSBb60Ho/nq381rGQ ixqPdomrtgBFzYoRhJJzl5ZMj64V8x0wuaP45c41RFz9yhyyAVJYDmtAmeGc7ZtWL+v3 tHxe29JvcR6SWeVp05rYul6eYBxQCj/wDpct8nFm12UuXgyFyF5+dwqS8TwteqKRVmNb qdW/QWJvMf50svW9m3hlwYtecfwWEeuQf8R6MBbrEhVXOwQp1Tl8U+GFZ5hhqS655fsX 0FiQ== X-Gm-Message-State: AG10YOTpOCUx0tH077PalS0pn+mf7pXOCWvvWhcgqVu4j9PDbmi3W11uARJJfhi5/bHGMr6wt6t0WA8zitLjtg== MIME-Version: 1.0 X-Received: by 10.25.209.138 with SMTP id i132mr4181254lfg.4.1453620181539; Sat, 23 Jan 2016 23:23:01 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Sat, 23 Jan 2016 23:23:01 -0800 (PST) In-Reply-To: <20160124064217.GB7567@ox> References: <20160124042830.3D674A0128@smtp.hushmail.com> <20160124064217.GB7567@ox> Date: Sat, 23 Jan 2016 23:23:01 -0800 X-Google-Sender-Auth: 7WIfQixi2sMrNMogw4wHgYJF1HU Message-ID: Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: Luigi Rizzo To: Luigi Rizzo , Marcus Cenzatti , "freebsd-net@freebsd.org" , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 07:23:05 -0000 On Sat, Jan 23, 2016 at 10:42 PM, Navdeep Parhar wrote: > On Sat, Jan 23, 2016 at 09:33:32PM -0800, Luigi Rizzo wrote: >> On Sat, Jan 23, 2016 at 8:28 PM, Marcus Cenzatti wrote: >> > >> > >> > On 1/24/2016 at 1:10 AM, "Luigi Rizzo" wrote: ... >> One last attempt: try use -l 64 on the sender, this will generate 64+4 byte >> packets, which may become just 64 on the receiver if the chelsio is configured >> to strip the CRC. This should result in well aligned PCIe transactions and >> reduced PCIe traffic, which may help (the ix driver has a similar problem, >> but since it does not strip the CRC can rx at line rate with 60 bytes but not >> with 64). > > Keep hw.cxgbe.fl_pktshift in mind for these kind of tests. The default > value is 2 so the chip DMAs payload at an offset of 2B from the start of > the rx buffer. So you'll need to adjust your frame size by 2 (66B on > the wire, 62B after CRC is removed, making it exactly 64B across PCIe if > pktshift is 2) or just set hw.cxgbe.fl_pktshift=0 in /boot/loader.conf. This sounds like something to fix. In netmap packets are supposed to be aligned with the beginning of the buffer, so when operating in netmap mode at least the pktshift should be set to 0. If it is not possible to have it per- queue, I would suggest to set it to 0 unconditionally when you compile a netmap-enabled kernel. How much of a performance boost do you see with a shift of 2 with regular traffic ? Modern CPUs seem to be pretty good with unaligned memory accesses. cheers luigi > Regards, > Navdeep -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Sun Jan 24 07:31:31 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CE91A8F6EB for ; Sun, 24 Jan 2016 07:31:31 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E45F10FE for ; Sun, 24 Jan 2016 07:31:30 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id 4CF22C012E for ; Sun, 24 Jan 2016 07:31:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=TQ/tVenuIRBdv6SRnDOLKgSxTiqQK5FiCTkheyi/MBc=; b=xzhwWD2TLn0DaMNCstHwJVKSm1eG91R4Lwol8vhCUItxHj3gebiwaT41Hk+rn2+0bUNDP/QR0o4njw2Mb302Fa8dvAUBmRHTLkSbSQBraQm86EjVI9XDtFVu2A2BkmNugnPBaig0c/Mq1uuDR4EM4VSKRV+cydItcncMjoZTAgUN+l5hGZ16YNE9R2t47qWrxhXvPF0/fmZmoMZ2gZM5jYQfDompbOZBnOkBnPQIAtpgvPCuItLcf0u8EHxhguMc8Pv3LaeDliDEO4sro6pQEBfa7Jki0nxlga6jWAr4aKBweOk+S8TszOTfb8GiXmlilfhZoDFmuwFdUpcUYgLgKg== Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP; Sun, 24 Jan 2016 07:31:28 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id BE9DFA0126; Sun, 24 Jan 2016 07:31:28 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 24 Jan 2016 05:31:28 -0200 To: "Navdeep Parhar" , "Adrian Chadd" Cc: "Luigi Rizzo" , "FreeBSD Net" Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: "Marcus Cenzatti" In-Reply-To: <20160124060706.GA7567@ox> References: <20160124035300.3E533A0126@smtp.hushmail.com> <20160124043050.A4936A0126@smtp.hushmail.com> <20160124060706.GA7567@ox> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20160124073128.BE9DFA0126@smtp.hushmail.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 07:31:31 -0000 On 1/24/2016 at 4:07 AM, "Navdeep Parhar" wrote: > >On Sat, Jan 23, 2016 at 08:38:24PM -0800, Adrian Chadd wrote: >> ok, that's a discussion to have with navdeep. That /should/ work. >> Someone may have changed it lately. > >Yes this used to work. > >> >> Things should behave very well and predictable once you can >disable >> cxl0 but not ncxl0. :-P > >The plan is to clean all this up by moving the netmap specific >parts to >a driver module of its own. So when you load if_cxgbe you'll get >only >the cxl interfaces. If you want netmap access to the ports you'll >be >able to kldload cxgbe_netmap (or something like that) which will >create >the ncxl ports. These ncxl ports _will_ operate like normal ifnets >hooked to the kernel stack if netmap isn't enabled on them. And >the >cxgbe_netmap driver will attach to PCIe PFs 0-3 so it won't take up >resources (interrupt vectors, etc.) from PF4, which is what the >main >if_cxgbe attaches to. You'll certainly be able to >up/down/whatever all >the interfaces independent of each other. All this will get done >in >time for FreeBSD 11. > >Regards, >Navdeep very nice to read that, this will make tests easier too because when I have this simple test scenario: host1-bridge-host2 - bridge = netmap bridge i should ping host1 to host2 (kernel path) just to make sure bridge is up, and only after that start pkt-gen on both sides since we don't have a netmap-aware ping(1), I can not do simple connectivity tests with ncxl, instead i pkt-gen -R 100 just to check if I get something on the other side, works but is not as simple and "pedagogical" as getting icmp response back, and having cxl vs ncxl logical flow paths may also break kernel-path fallback in a running environment, I dont know just guessing, if_bridge cxl0-cxl1 vs netmap-bridge ncxl0-ncxl1, or if I write a daemon which listens on a given ip address, this IP address must be configured on ncxl or cxl so this application can not work transparently in netmap mode while a sister application runs on kernel-path mode.. since I probably can have the same IP address on both ncxl/cxl (I dont know how switches will behave due to different mac address) but freebsd's routing path will probably always rely on the first addressed interface chelsio# ifconfig cxl0 1.2.3.4/24 chelsio# ifconfig ncxl0 1.2.3.4/24 chelsio# route -n get 1.2.3.1 route to: 1.2.3.1 destination: 1.2.3.0 mask: 255.255.255.0 fib: 0 interface: ncxl0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 i think this would break many things and make usage scenarios more complex but is it important to have two interface names, mr navdeep, on chelsio hardware? i mean, very nice if I have ncxl0 working both netmap and kernel modes, or cxl0 if netmap support is not compiled or kernel module not loaded but why not simply have cxl as usual w/ intel cards? so we can always have the same interface name, chelsio netmap acceleration and internal working details could happen when the interface enters netmap mode or by a ifconfig (ifconfig cxl0 -netmap, ifconfig cxl0 netmap) or even cxgbetool if by some reason it can not be transparently detected when the application puts the port in netmap mode just wondering why ncxl vs cxl and curious about the internals thank you everyone again From owner-freebsd-net@freebsd.org Sun Jan 24 07:56:23 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D64A2A8FDEC for ; Sun, 24 Jan 2016 07:56:23 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B94781A71 for ; Sun, 24 Jan 2016 07:56:23 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id C254B401A5 for ; Sun, 24 Jan 2016 07:56:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=wxned9l7Nus3qESY3KsGCyUCi81B8n+LEMwOGxpF+mA=; b=gOLQ78gZlfjV/gQ2rYVLU2KZhaC6H9DjO95v88QDC56Gl8DSyxpP5YEx4FzgX+28AuvSkX543YvcUvYYjG6Ll4PedO8N2pz/NdqUfyJE/47dAPW0Bt1fGADj0pU7mUTaPPS9f/OwGz4XgehdJb0amMMjzvwWauNDvrul3k1y31ceN9uo05tnQCTwWD9PytAbfilr/XNdf0GhRQwu3eg6NuBoG8w27+bJdcAXw7ZIQIEd+ctJ1xTB9vzzlazpeYTSrlBNBUA9llUHtEc7+rJPysAME2wObELTy0Ga14fguGAV8EJmaIsE7I92dyrmWQvFp4P3mfUHUPZ6Zyge7TmEuQ== Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP; Sun, 24 Jan 2016 07:56:21 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 7F4FEA0126; Sun, 24 Jan 2016 07:56:21 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 24 Jan 2016 05:56:21 -0200 To: "Luigi Rizzo" Cc: freebsd-net@freebsd.org, "Navdeep Parhar" Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: "Marcus Cenzatti" In-Reply-To: References: <20160124042830.3D674A0128@smtp.hushmail.com> <20160124070056.4EC5CA0126@smtp.hushmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20160124075621.7F4FEA0126@smtp.hushmail.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 07:56:23 -0000 On 1/24/2016 at 5:17 AM, "Luigi Rizzo" wrote: > >On Sat, Jan 23, 2016 at 11:00 PM, Marcus Cenzatti > wrote: >> >> >> On 1/24/2016 at 3:33 AM, "Luigi Rizzo" >wrote: >... > >> ok here it is >> >> this lowered pps rate to 9.4Mpps on chelsio (we had 11Mpps with >defaul len) and lowered rates to 14Mpps on sender (we had 14.8Mpps >before). > >see the other email from navdeep, he suggests to try -l 62 >because the chelsio saves the packet with a 2-byte offset >into the buffer (it puzzles me a bit that it does so also >in netmap mode though). > >cheers >luigi yes, I saw, i've run both with 62 bytes and 64 bytes len very different results from the previous one and among both pkt sizes but could not go beyond 11Mpps results: -l 62 = TX 14.8Mpps RX 11Mpps -l 66 = TX 12.4Mpps RX 9.4Mpps here is the transcript: intel# intel# netmap-master/examples/pkt-gen-b -l 62 -i ix0 -f tx -S 00:07:e9:44:d2:ba -D 00:07:43:33:8d:c1 430.877073 main [1930] interface is ix0 430.877114 main [2050] running on 1 cpus (have 8) 430.877132 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 430.877141 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 430.982448 main [2148] mapped 334980KB at 0x801800000 Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:07:e9:44:d2:ba -> 00:07:43:33:8d:c1) 430.982522 main [2233] Sending 512 packets every 0.000000000 s 430.982527 main [2235] Wait 2 secs for phy reset 433.006279 main [2237] Ready... 433.006526 sender_body [1211] start, fd 3 main_fd 3 433.046003 sender_body [1293] drop copy 434.007048 main_thread [1720] 13.780 Mpps (13.787 Mpkts 6.839 Gbps in 1000544 usec) 433.79 avg_batch 0 min_space 435.007831 main_thread [1720] 14.289 Mpps (14.300 Mpkts 7.093 Gbps in 1000784 usec) 430.53 avg_batch 99999 min_space 436.008835 main_thread [1720] 14.318 Mpps (14.332 Mpkts 7.109 Gbps in 1001004 usec) 421.25 avg_batch 99999 min_space 437.009848 main_thread [1720] 14.303 Mpps (14.318 Mpkts 7.102 Gbps in 1001013 usec) 419.91 avg_batch 99999 min_space 438.011331 main_thread [1720] 14.291 Mpps (14.312 Mpkts 7.099 Gbps in 1001483 usec) 422.53 avg_batch 99999 min_space 439.012325 main_thread [1720] 14.309 Mpps (14.323 Mpkts 7.104 Gbps in 1000995 usec) 439.39 avg_batch 99999 min_space 440.013325 main_thread [1720] 14.300 Mpps (14.314 Mpkts 7.100 Gbps in 1000999 usec) 407.46 avg_batch 99999 min_space 441.014321 main_thread [1720] 14.267 Mpps (14.281 Mpkts 7.083 Gbps in 1000997 usec) 457.50 avg_batch 99999 min_space 442.014899 main_thread [1720] 14.316 Mpps (14.324 Mpkts 7.105 Gbps in 1000578 usec) 440.57 avg_batch 99999 min_space 443.016322 main_thread [1720] 14.274 Mpps (14.294 Mpkts 7.090 Gbps in 1001422 usec) 448.94 avg_batch 99999 min_space 444.022363 main_thread [1720] 14.329 Mpps (14.416 Mpkts 7.150 Gbps in 1006011 usec) 415.10 avg_batch 99999 min_space 445.023338 main_thread [1720] 14.315 Mpps (14.330 Mpkts 7.108 Gbps in 1001006 usec) 413.37 avg_batch 99999 min_space 446.024321 main_thread [1720] 14.286 Mpps (14.300 Mpkts 7.093 Gbps in 1000982 usec) 426.52 avg_batch 99999 min_space 447.025327 main_thread [1720] 14.343 Mpps (14.358 Mpkts 7.121 Gbps in 1001006 usec) 426.19 avg_batch 99999 min_space 448.026323 main_thread [1720] 14.282 Mpps (14.296 Mpkts 7.091 Gbps in 1000996 usec) 416.17 avg_batch 99999 min_space 449.027830 main_thread [1720] 14.278 Mpps (14.299 Mpkts 7.092 Gbps in 1001508 usec) 448.76 avg_batch 99999 min_space 450.029325 main_thread [1720] 14.274 Mpps (14.295 Mpkts 7.090 Gbps in 1001494 usec) 425.45 avg_batch 99999 min_space 451.029824 main_thread [1720] 14.248 Mpps (14.255 Mpkts 7.071 Gbps in 1000500 usec) 452.37 avg_batch 99999 min_space 452.040823 main_thread [1720] 14.267 Mpps (14.423 Mpkts 7.154 Gbps in 1010998 usec) 439.52 avg_batch 99999 min_space 453.042317 main_thread [1720] 14.256 Mpps (14.278 Mpkts 7.082 Gbps in 1001494 usec) 437.54 avg_batch 99999 min_space 454.043326 main_thread [1720] 14.329 Mpps (14.343 Mpkts 7.114 Gbps in 1001009 usec) 424.55 avg_batch 99999 min_space 455.043822 main_thread [1720] 14.319 Mpps (14.326 Mpkts 7.106 Gbps in 1000496 usec) 423.84 avg_batch 99999 min_space 456.045320 main_thread [1720] 14.311 Mpps (14.333 Mpkts 7.109 Gbps in 1001498 usec) 416.26 avg_batch 99999 min_space 457.046326 main_thread [1720] 14.319 Mpps (14.334 Mpkts 7.110 Gbps in 1001007 usec) 436.04 avg_batch 99999 min_space 458.047335 main_thread [1720] 14.372 Mpps (14.386 Mpkts 7.136 Gbps in 1001002 usec) 410.49 avg_batch 99999 min_space 459.048318 main_thread [1720] 14.244 Mpps (14.258 Mpkts 7.072 Gbps in 1000990 usec) 417.40 avg_batch 99999 min_space 460.049318 main_thread [1720] 14.329 Mpps (14.343 Mpkts 7.114 Gbps in 1000999 usec) 420.67 avg_batch 99999 min_space 461.050317 main_thread [1720] 14.304 Mpps (14.318 Mpkts 7.102 Gbps in 1000999 usec) 413.63 avg_batch 99999 min_space 462.051314 main_thread [1720] 14.232 Mpps (14.247 Mpkts 7.066 Gbps in 1000997 usec) 472.71 avg_batch 99999 min_space 463.052317 main_thread [1720] 14.269 Mpps (14.284 Mpkts 7.085 Gbps in 1001003 usec) 436.25 avg_batch 99999 min_space 464.052817 main_thread [1720] 14.364 Mpps (14.371 Mpkts 7.128 Gbps in 1000500 usec) 400.26 avg_batch 99999 min_space 465.054270 main_thread [1720] 14.261 Mpps (14.282 Mpkts 7.084 Gbps in 1001453 usec) 450.93 avg_batch 99999 min_space 466.077837 main_thread [1720] 14.313 Mpps (14.651 Mpkts 7.267 Gbps in 1023567 usec) 436.45 avg_batch 99999 min_space 467.078822 main_thread [1720] 14.281 Mpps (14.295 Mpkts 7.090 Gbps in 1000986 usec) 434.86 avg_batch 99999 min_space ^C467.836880 sigint_h [404] received control-C on thread 0x801406800 467.837095 sender_body [1326] flush tail 737 head 1762 on thread 0x801406800 467.837239 sender_body [1334] pending tx tail 1522 head 2035 on ring 0 467.837293 sender_body [1334] pending tx tail 1175 head 1225 on ring 1 467.837336 sender_body [1334] pending tx tail 1874 head 1915 on ring 2 467.837384 sender_body [1334] pending tx tail 1311 head 1325 on ring 4 468.101067 main_thread [1720] 10.636 Mpps (10.873 Mpkts 5.393 Gbps in 1022244 usec) 410.74 avg_batch 99999 min_space Sent 497478675 packets 30843677850 bytes 1159848 events 62 bytes each in 34.83 seconds. Speed: 14.283 Mpps Bandwidth: 7.084 Gbps (raw 9.827 Gbps). Average batch: 428.92 pkts intel# netmap-master/examples/pkt-gen-b -l 66 -i ix0 -f tx -S 00:07:e9:44:d2:ba -D 00:07:43:33:8d:c1 476.421587 main [1930] interface is ix0 476.421627 main [2050] running on 1 cpus (have 8) 476.421646 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 476.421655 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 476.527263 main [2148] mapped 334980KB at 0x801800000 Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:07:e9:44:d2:ba -> 00:07:43:33:8d:c1) 476.527339 main [2233] Sending 512 packets every 0.000000000 s 476.527344 main [2235] Wait 2 secs for phy reset 478.535360 main [2237] Ready... 478.535595 sender_body [1211] start, fd 3 main_fd 3 478.580779 sender_body [1293] drop copy 479.569816 main_thread [1720] 12.023 Mpps (12.435 Mpkts 6.566 Gbps in 1034249 usec) 142.97 avg_batch 0 min_space 480.571316 main_thread [1720] 12.431 Mpps (12.450 Mpkts 6.573 Gbps in 1001499 usec) 138.29 avg_batch 99999 min_space 481.572313 main_thread [1720] 12.483 Mpps (12.495 Mpkts 6.597 Gbps in 1000997 usec) 158.82 avg_batch 99999 min_space 482.573309 main_thread [1720] 12.478 Mpps (12.491 Mpkts 6.595 Gbps in 1000996 usec) 150.58 avg_batch 99999 min_space 483.573954 main_thread [1720] 12.478 Mpps (12.486 Mpkts 6.593 Gbps in 1000645 usec) 154.52 avg_batch 99999 min_space 484.575316 main_thread [1720] 12.383 Mpps (12.400 Mpkts 6.547 Gbps in 1001362 usec) 159.04 avg_batch 99999 min_space 485.576311 main_thread [1720] 12.479 Mpps (12.491 Mpkts 6.595 Gbps in 1000996 usec) 156.58 avg_batch 99999 min_space 486.577312 main_thread [1720] 12.473 Mpps (12.485 Mpkts 6.592 Gbps in 1001000 usec) 166.46 avg_batch 99999 min_space ^C486.932236 sigint_h [404] received control-C on thread 0x801406800 486.932301 sender_body [1326] flush tail 1400 head 1400 on thread 0x801406800 486.932371 sender_body [1334] pending tx tail 1989 head 1669 on ring 0 486.932445 sender_body [1334] pending tx tail 37 head 1669 on ring 0 486.932486 sender_body [1334] pending tx tail 141 head 1669 on ring 0 486.932517 sender_body [1334] pending tx tail 197 head 1669 on ring 0 486.932547 sender_body [1334] pending tx tail 246 head 1669 on ring 0 487.579383 main_thread [1720] 4.423 Mpps (4.432 Mpkts 2.340 Gbps in 1002071 usec) 163.45 avg_batch 99999 min_space Sent 104165529 packets 6874924914 bytes 679304 events 66 bytes each in 8.40 seconds. Speed: 12.404 Mpps Bandwidth: 6.549 Gbps (raw 8.931 Gbps). Average batch: 153.34 pkts chelsio# ./pkt-gen-b -i ncxl0 -f rx 506.318671 main [1930] interface is ncxl0 506.318722 main [2050] running on 1 cpus (have 4) 506.318859 extract_ip_range [367] range is 10.0.0.1:0 to 10.0.0.1:0 506.318878 extract_ip_range [367] range is 10.1.0.1:0 to 10.1.0.1:0 506.565853 main [2148] mapped 334980KB at 0x801800000 Receiving from netmap:ncxl0: 2 queues, 1 threads and 1 cpus. 506.565933 main [2235] Wait 2 secs for phy reset 508.567111 main [2237] Ready... 545.346710 receiver_body [1419] waiting for initial packets, poll returns 0 0 545.977706 main_thread [1720] 365.393 Kpps (365.756 Kpkts 181.415 Mbps in 1000994 usec) 199.76 avg_batch 0 min_space 546.978707 main_thread [1720] 11.172 Mpps (11.183 Mpkts 5.547 Gbps in 1001001 usec) 187.95 avg_batch 0 min_space 547.979208 main_thread [1720] 11.173 Mpps (11.179 Mpkts 5.545 Gbps in 1000501 usec) 188.79 avg_batch 0 min_space 548.980704 main_thread [1720] 11.163 Mpps (11.180 Mpkts 5.545 Gbps in 1001496 usec) 196.53 avg_batch 0 min_space 549.981703 main_thread [1720] 11.174 Mpps (11.185 Mpkts 5.548 Gbps in 1000999 usec) 189.79 avg_batch 0 min_space 550.990747 main_thread [1720] 11.173 Mpps (11.274 Mpkts 5.592 Gbps in 1009044 usec) 198.65 avg_batch 0 min_space 551.994476 main_thread [1720] 11.173 Mpps (11.214 Mpkts 5.562 Gbps in 1003728 usec) 201.30 avg_batch 0 min_space 552.996708 main_thread [1720] 11.171 Mpps (11.196 Mpkts 5.553 Gbps in 1002233 usec) 197.36 avg_batch 0 min_space 553.997566 main_thread [1720] 11.167 Mpps (11.176 Mpkts 5.543 Gbps in 1000858 usec) 187.29 avg_batch 0 min_space 555.000213 main_thread [1720] 11.172 Mpps (11.202 Mpkts 5.556 Gbps in 1002646 usec) 184.47 avg_batch 0 min_space 556.001209 main_thread [1720] 11.173 Mpps (11.184 Mpkts 5.547 Gbps in 1000997 usec) 188.14 avg_batch 0 min_space 557.002717 main_thread [1720] 11.170 Mpps (11.187 Mpkts 5.549 Gbps in 1001508 usec) 187.32 avg_batch 0 min_space 558.003201 main_thread [1720] 11.173 Mpps (11.178 Mpkts 5.544 Gbps in 1000484 usec) 186.84 avg_batch 0 min_space 559.004558 main_thread [1720] 11.167 Mpps (11.182 Mpkts 5.546 Gbps in 1001356 usec) 189.47 avg_batch 0 min_space 560.005218 main_thread [1720] 11.174 Mpps (11.181 Mpkts 5.546 Gbps in 1000661 usec) 199.56 avg_batch 0 min_space 561.006704 main_thread [1720] 11.173 Mpps (11.189 Mpkts 5.550 Gbps in 1001486 usec) 184.32 avg_batch 0 min_space 562.007715 main_thread [1720] 11.173 Mpps (11.184 Mpkts 5.547 Gbps in 1001010 usec) 192.40 avg_batch 0 min_space 563.008204 main_thread [1720] 11.171 Mpps (11.177 Mpkts 5.544 Gbps in 1000490 usec) 195.11 avg_batch 0 min_space 564.009485 main_thread [1720] 11.168 Mpps (11.182 Mpkts 5.546 Gbps in 1001281 usec) 186.32 avg_batch 0 min_space 565.010213 main_thread [1720] 11.171 Mpps (11.179 Mpkts 5.545 Gbps in 1000728 usec) 185.74 avg_batch 0 min_space 566.014238 main_thread [1720] 11.173 Mpps (11.218 Mpkts 5.564 Gbps in 1004025 usec) 197.98 avg_batch 0 min_space 567.016711 main_thread [1720] 11.173 Mpps (11.200 Mpkts 5.555 Gbps in 1002473 usec) 185.86 avg_batch 0 min_space 568.017213 main_thread [1720] 11.173 Mpps (11.179 Mpkts 5.545 Gbps in 1000502 usec) 189.72 avg_batch 0 min_space 569.027995 main_thread [1720] 11.170 Mpps (11.291 Mpkts 5.600 Gbps in 1010782 usec) 195.09 avg_batch 0 min_space 570.028205 main_thread [1720] 11.173 Mpps (11.175 Mpkts 5.543 Gbps in 1000210 usec) 185.56 avg_batch 0 min_space 571.029709 main_thread [1720] 11.173 Mpps (11.190 Mpkts 5.550 Gbps in 1001504 usec) 186.81 avg_batch 0 min_space 572.031206 main_thread [1720] 11.172 Mpps (11.189 Mpkts 5.550 Gbps in 1001497 usec) 185.98 avg_batch 0 min_space 573.038202 main_thread [1720] 11.172 Mpps (11.250 Mpkts 5.580 Gbps in 1006996 usec) 191.74 avg_batch 0 min_space 574.039199 main_thread [1720] 11.168 Mpps (11.180 Mpkts 5.545 Gbps in 1000997 usec) 196.01 avg_batch 0 min_space 575.042703 main_thread [1720] 11.173 Mpps (11.212 Mpkts 5.561 Gbps in 1003504 usec) 184.28 avg_batch 0 min_space 576.043200 main_thread [1720] 11.172 Mpps (11.177 Mpkts 5.544 Gbps in 1000497 usec) 189.59 avg_batch 0 min_space 577.044701 main_thread [1720] 11.172 Mpps (11.189 Mpkts 5.550 Gbps in 1001501 usec) 199.04 avg_batch 0 min_space 578.052358 main_thread [1720] 11.173 Mpps (11.258 Mpkts 5.584 Gbps in 1007657 usec) 184.56 avg_batch 0 min_space 579.053699 main_thread [1720] 11.170 Mpps (11.185 Mpkts 5.548 Gbps in 1001341 usec) 190.32 avg_batch 0 min_space 580.055701 main_thread [1720] 11.172 Mpps (11.195 Mpkts 5.552 Gbps in 1002002 usec) 201.08 avg_batch 0 min_space 581.060972 main_thread [1720] 7.664 Mpps (7.704 Mpkts 3.821 Gbps in 1005270 usec) 184.97 avg_batch 0 min_space 593.095693 main_thread [1720] 9.471 Mpps (9.478 Mpkts 5.004 Gbps in 1000720 usec) 158.37 avg_batch 0 min_space 594.104282 main_thread [1720] 9.469 Mpps (9.550 Mpkts 5.043 Gbps in 1008589 usec) 163.78 avg_batch 0 min_space 595.106902 main_thread [1720] 9.471 Mpps (9.496 Mpkts 5.014 Gbps in 1002620 usec) 157.00 avg_batch 0 min_space 596.107688 main_thread [1720] 9.471 Mpps (9.479 Mpkts 5.005 Gbps in 1000787 usec) 180.89 avg_batch 0 min_space 597.108692 main_thread [1720] 9.471 Mpps (9.481 Mpkts 5.006 Gbps in 1001002 usec) 179.28 avg_batch 0 min_space 598.109687 main_thread [1720] 9.471 Mpps (9.480 Mpkts 5.006 Gbps in 1000996 usec) 154.82 avg_batch 0 min_space 599.110692 main_thread [1720] 9.470 Mpps (9.479 Mpkts 5.005 Gbps in 1001005 usec) 178.17 avg_batch 0 min_space 600.118198 main_thread [1720] 9.468 Mpps (9.420 Mpkts 5.004 Gbps in 1007506 usec) 176.45 avg_batch 0 min_space ^C605.796897 sigint_h [404] received control-C on thread 0x801406800 606.128197 main_thread [1720] 0.000 pps (0.000 pkts 0.000 bps in 1004512 usec) 0.00 avg_batch 0 min_space Received 467977196 packets 29331410296 bytes 2508465 events 62 bytes each in 59.88 seconds. Speed: 7.816 Mpps Bandwidth: 3.919 Gbps (raw 5.420 Gbps). Average batch: 186.56 pkts kept the same RX session for both TX len sessions as you probably observed From owner-freebsd-net@freebsd.org Sun Jan 24 07:58:47 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E55F0A8FEC1 for ; Sun, 24 Jan 2016 07:58:47 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C96671CB9 for ; Sun, 24 Jan 2016 07:58:47 +0000 (UTC) (envelope-from cenzatti@hush.com) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id C1A4BC0150 for ; Sun, 24 Jan 2016 07:58:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=fp8e2fBcWfiO64tddorAXn47rFL7qLlrbv9GH86IerY=; b=oGS2zf+fJJBPeWfXETZ09KpnguBC3KbipLFg/wOTVed/E49q4el6jHMpDQiOrPSkAZBzQ5cBKjIDAdcKNXQQbVmLXw32+yN2pnyQSMk5IXmR+wtXl3EyRVKRPOcvwLXZsb1deowgZR7xQ/KhrFSs/69xZNWu8UcEMXFnpwFibGOsgiH1sWpUViCd87+7XR6OnJRxhzXJ/a0V3w/5No0VTv/ExNIrMNcxvHGod3avVrHb4zdUH0vR002Ad9Xc4mAUbFbKhJI/ppQEPRU5VpQyznpSDoNZx+TTxn+Bw0qC2v4mPGo1nv8UkDyqyD4Da2wOa7khShRTy2QLjx4FPRPfQg== Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP; Sun, 24 Jan 2016 07:58:46 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 89FF0A0126; Sun, 24 Jan 2016 07:58:46 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 24 Jan 2016 05:58:46 -0200 To: "Luigi Rizzo" Cc: freebsd-net@freebsd.org, "Navdeep Parhar" Subject: Re: solved: Re: Chelsio T520-SO-CR low performance (netmap tested) for RX From: "Marcus Cenzatti" In-Reply-To: <20160124075621.7F4FEA0126@smtp.hushmail.com> References: <20160124042830.3D674A0128@smtp.hushmail.com> <20160124070056.4EC5CA0126@smtp.hushmail.com> <20160124075621.7F4FEA0126@smtp.hushmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20160124075846.89FF0A0126@smtp.hushmail.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 07:58:48 -0000 On 1/24/2016 at 5:56 AM, "Marcus Cenzatti" wrote: > >On 1/24/2016 at 5:17 AM, "Luigi Rizzo" wrote: >> >>On Sat, Jan 23, 2016 at 11:00 PM, Marcus Cenzatti >> wrote: >>> >>> >>> On 1/24/2016 at 3:33 AM, "Luigi Rizzo" >>wrote: >>... >> >>> ok here it is >>> >>> this lowered pps rate to 9.4Mpps on chelsio (we had 11Mpps with >>defaul len) and lowered rates to 14Mpps on sender (we had >14.8Mpps >>before). >> >>see the other email from navdeep, he suggests to try -l 62 >>because the chelsio saves the packet with a 2-byte offset >>into the buffer (it puzzles me a bit that it does so also >>in netmap mode though). >> >>cheers >>luigi > >yes, I saw, i've run both with 62 bytes and 64 bytes len i mean 62 and 66 > >very different results from the previous one and among both pkt >sizes but could not go beyond 11Mpps > >results: > >-l 62 = TX 14.8Mpps RX 11Mpps >-l 66 = TX 12.4Mpps RX 9.4Mpps > From owner-freebsd-net@freebsd.org Sun Jan 24 08:42:02 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66AA1A8F18D; Sun, 24 Jan 2016 08:42:02 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B9D01387; Sun, 24 Jan 2016 08:42:02 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-lb0-x230.google.com with SMTP id cl12so60242114lbc.1; Sun, 24 Jan 2016 00:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=s9BKI5FAOBv2pvJHJC7pNx27WlQLNGm277nzvyo7bUY=; b=pCj9vLGlppH7lozoqrXLqePFlToG7EIaLuJKf2mtfmoOPF4UNKLAQW9bOqPChwzSaq S2Z9Rhtif0m1DBKAfVipa8BuaxMBku1cH6lPhzzvjJn83kR8Ye7haJXFg37n/MSgDTJ+ xlmk9o9yzwXG4ymELzWWYCkyt1XXRLXd/jL0gpC3LITXvZWoW+Jiwsw8DqZmvbHymCx1 4LMDmyManKpBg854CfQK2iN4+vB92ej6WhZKmd1MTmrwVzrfK2byaVFRtg1Npcfcd6qm KtjlzKoz8R/ydqd0J1PCTBA5hGJ7FmRpwhRq0o2l/fDYVc0PMuB4laTeQx16cdtpDfT1 JuNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=s9BKI5FAOBv2pvJHJC7pNx27WlQLNGm277nzvyo7bUY=; b=IuvfvAdErNK7cQci+1RCdTdnmg4L7mmWdWsIQU7+g3TOLSVRjJpCR5eJgOs0FL/w7F PNqc8yQLQpT1vpEPVXGpkahd+nO57fJjLSBfMfkQaYe6/KYmNtcrF+UZVx9AkwQHV5Mr VIN8zZ8Q3dDSj9qPzeoud3VzKw3hjR+TNO2JODXA7PRo8jhpl3pbJnLdfO4TYEyhQsWC fN4Ml3AtvpUex9OSjLlakXFVrp1p5B8VjQL+HY6b4Xc5aub6CnZ8wLUYVhZ7oozA1PWP 9VNx8hiTA/K6bGcEQDTiSmEvEpVbpOtKW9svFu+sEB8jVHM/qJFIbNqBzfAj4SAxWpKw za5A== X-Gm-Message-State: AG10YOTE/3A1AsNxqT4ODrCQlWCCy3Z19AJxyc52t7yn4p0P+mhrWpD7caHwdXLuk2WoggmFw9gOpKs+enlK7g== MIME-Version: 1.0 X-Received: by 10.112.143.163 with SMTP id sf3mr4068772lbb.117.1453624919001; Sun, 24 Jan 2016 00:41:59 -0800 (PST) Received: by 10.25.89.10 with HTTP; Sun, 24 Jan 2016 00:41:58 -0800 (PST) In-Reply-To: References: Date: Sun, 24 Jan 2016 09:41:58 +0100 Message-ID: Subject: Re: Multicast routing on FreeBSD 11 current From: Ben Woods To: "freebsd-net@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 08:42:02 -0000 On Saturday, 23 January 2016, Ben Woods wrote: > > I am running the GENERIC kernel, except with VIMAGE enabled and SCTP > disabled. > > When I try to load the kernel module, I am getting an error: > % sudo kldload -v ip_mroute > kldload: an error occurred while loading the module. Please check dmesg(8) > for more details. > % dmesg > linker_load_file: Unsupported file type > > Any ideas what could be causing this error? > > Thanks for your help. > > Regards, > Ben > > -- > From: Benjamin Woods > woodsb02@gmail.com > Hi everyone, Could someone running FreeBSD current on a test machine try loading the ip_mroute driver on their machine? This is to enable multicast routing, but I am wondering if it fails to load for everyone, or it is specific to my build some how. I am running r294463, please let me know which version you are running if it works or doesn't work. Regards, Ben -- -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@freebsd.org Sun Jan 24 09:07:52 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34252A8FD2D for ; Sun, 24 Jan 2016 09:07:52 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0FC651ED1 for ; Sun, 24 Jan 2016 09:07:52 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0D924A8FD2B; Sun, 24 Jan 2016 09:07:52 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E64E5A8FD2A; Sun, 24 Jan 2016 09:07:51 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 764581ED0; Sun, 24 Jan 2016 09:07:51 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id n5so38515813wmn.0; Sun, 24 Jan 2016 01:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=ftgCuFcYSMnB6fuySuMbNckj06Pk0AgBG2W8kZzZtk4=; b=s4ewxpHOPi6DxQxbR2j4sivSOc6LL9Mwck1jDtHcQs3Qs/9M43VegwjGe0deQ1O6IP dI2KLTLilkNLV8oxBDuI1spQhuMqKR6ZMsjy5uh7OPP+pFSusCCWpPBw5JacIykRn0i/ RkHmUgn1MqGeRBVzQ8PxuCFSBP0uFf7M9TguR8w4HrQFRIjR4gt65BJDS0HGqRYMGKPA yo+Qjs/lkTYg0B6BQtLz/h/DoCr7ay5iPj716U3yLPO5BIf3t0NLanfvSrqHcxPKcQpe FMRKhF/YNrRtOBjuVYbin0+AlR/8aF+Fjvj6uHGEZAGkYYbT7GitC3b2lyBoRGbb7xe7 wxAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-type :content-transfer-encoding; bh=ftgCuFcYSMnB6fuySuMbNckj06Pk0AgBG2W8kZzZtk4=; b=MQ0e4F4dumpKOvRACidgGt81X7BrwXjHBoW/4Mu/wCKxJssYAtRM+rdThlA0BKiGYO 2HMqDpdFFqcw6vYJuFHAIAOwBDttQHkUi1NHNuC5afs1nA078lJLHGb03QobKKtB7GFT PJ4/UgA5ocy//oV/SsqL+DxSekynlYcLzozXp5MWfCXjamwqQafQQD4AWhZ9eXo0/+pB CWBNcB1n5KXxzlvCri40GI1RAK0lJmpb6V+anHQLQ+mEuAeIIO4WKdDBDy+hlQNnppfv FE+hcM0D+immi62wviqoWIeJEgkbtmf/izls14/LZdpE2YL2lRCVKVQDrcOUpGGwaJAo /CxA== X-Gm-Message-State: AG10YORKQ9nr4JSO4oEWQ2U9nIuRnWO6iKuxLP5kEjCoYbQ+CHSt+u+9cphanKZUNQWgeA== X-Received: by 10.28.215.136 with SMTP id o130mr11996775wmg.33.1453626469665; Sun, 24 Jan 2016 01:07:49 -0800 (PST) Received: from ernst.home (p4FCA7FB6.dip0.t-ipconnect.de. [79.202.127.182]) by smtp.gmail.com with ESMTPSA id b127sm10631818wmh.9.2016.01.24.01.07.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jan 2016 01:07:49 -0800 (PST) Date: Sun, 24 Jan 2016 10:07:47 +0100 From: Gary Jennejohn To: Konstantin Belousov Cc: Boris Astardzhiev , threads@freebsd.org, Bruce Evans , net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160124100747.551f8e3f@ernst.home> In-Reply-To: <20160124050634.GS3942@kib.kiev.ua> References: <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 09:07:52 -0000 On Sun, 24 Jan 2016 07:06:34 +0200 Konstantin Belousov wrote: [delete irrelevant parts of the patch] > > + rcvd = 1; > > + for (i = rcvd; i < vlen; i++) { > i = rcvd = 1; ... i++, rcvd++ ? > > > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > > + if (ret == -1) { > > + if (rcvd != 0) { > > + /* We've received messages. Let caller know. */ > > + return (rcvd); > > + } > > + return (ret); > > + } > > + This seems wrong. rcvd is initialized to 1 so that the check for rcvd != 0 can never be false. We already successfully called __sys_recvmsg() just above the loop, so why not simplify the code by doing if (ret == -1) return (rcvd); -- Gary Jennejohn (gj@) From owner-freebsd-net@freebsd.org Sun Jan 24 10:19:18 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A10307EAE for ; Sun, 24 Jan 2016 10:19:18 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward18p.cmail.yandex.net (forward18p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::ab]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B2C2B58 for ; Sun, 24 Jan 2016 10:19:18 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [IPv6:2a02:6b8:0:1402::118]) by forward18p.cmail.yandex.net (Yandex) with ESMTP id 2B61A21457; Sun, 24 Jan 2016 13:19:06 +0300 (MSK) Received: from smtp17.mail.yandex.net (localhost [127.0.0.1]) by smtp17.mail.yandex.net (Yandex) with ESMTP id C19781901598; Sun, 24 Jan 2016 13:19:05 +0300 (MSK) Received: by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id KOh9diiLJT-J5TWGpM0; Sun, 24 Jan 2016 13:19:05 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1453630745; bh=+QVlWQamCm07hG5i5uVj7l5a9fgVUnBgPohrv5moPhw=; h=Subject:To:References:From:X-Enigmail-Draft-Status:Message-ID: Date:User-Agent:MIME-Version:In-Reply-To:Content-Type; b=pmPp7yYb3P1BhgcdNnRDM51eS1twQuVxk6LPEUwBnFH4x67eo74Q+P+12cUxiULlc SoTF1YECmqnBsrUfba2h9HVpS+SzhjN54gEaiDuXc5AbB255Ex+c7fIJUyOZOvqxrj 2r9sRfD3CyZQSp5c9EzDLE9zt8Q094h/38kW5zDA= Authentication-Results: smtp17.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-ForeignMX: US Subject: Re: Multicast routing on FreeBSD 11 current To: Ben Woods , freebsd-net@freebsd.org References: From: "Andrey V. Elsukov" X-Enigmail-Draft-Status: N1110 Message-ID: <56A4A4C9.6000807@yandex.ru> Date: Sun, 24 Jan 2016 13:17:45 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RlXCkNORsjCAl9Nlu3i6C7g602Kw0deMR" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 10:19:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RlXCkNORsjCAl9Nlu3i6C7g602Kw0deMR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 24.01.16 01:14, Ben Woods wrote: > % sudo kldload -v ip_mroute > kldload: an error occurred while loading the module. Please check dmesg= (8) > for more details. > % dmesg > linker_load_file: Unsupported file type >=20 > Any ideas what could be causing this error? Usually this means that your running kernel is out of sync with modules. You are running r294463, but __FreeBSD_version was bumped recently in r294505. You need rebuild and reinstall your kernel and all modules. --=20 WBR, Andrey V. Elsukov --RlXCkNORsjCAl9Nlu3i6C7g602Kw0deMR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWpKTJAAoJEAHF6gQQyKF6vtUH/0InWH0dtbg6cuPMtmfmQ2K+ 1p7N65Lp8Mk2Iam1b0kLxuCktw16H+leeJqWx7EbmsEb2o6krRvXqfxorv+6dRLM 8ULekTBmM4E6ZZ9Wa6h/I3XS6wycGSgzU/VqcX2vvmrnYDcRzP0ghTiyD73BqVaM wuPFZ+keISqjLS6WwM3SySWdwQUPdO45y9nG8xE70AsFI+/GLLfGIOY4yJ6AQVy8 huLYablFxook6NdvKXfFCDuWXBgYjCQ+O59GUXjxvtnxZek/n38d+q9m0KgpL0Ts VAErn7JQzu3R17AL0XLU7aUdaEtDp93vgs6GbLdsqqGU5QQhMiOFCszuWqFGf0c= =GpLu -----END PGP SIGNATURE----- --RlXCkNORsjCAl9Nlu3i6C7g602Kw0deMR-- From owner-freebsd-net@freebsd.org Sun Jan 24 10:25:18 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03A8670FB; Sun, 24 Jan 2016 10:25:18 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79257FD8; Sun, 24 Jan 2016 10:25:17 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id c192so69373844lfe.2; Sun, 24 Jan 2016 02:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ESHL5PSzRQmcSPcJfRLyLk6WhJrm77DWxaE/lW1cRoI=; b=EVrQQuET/6JdU6dCMVo15JA9tj6ilcN9JEEEfcKH52ssN7YqvCy+oEq9u9vPCyrV3N +0TeR62i584Pg95bBCtqhB+1oDvV5kEahl7IpzmjT1SMwvkSOCUAKNUaMov1pFh1UQND hZq6AOkWSn2KhtEW4iGDCwKiQzN5CMM+Ui4M4w8kVUgVSZkxr/NhtEyJ6+28BugNH4T4 mO7Q6k1N7kVBcK1+ltZO62EUL2jxykAVW0inaLdyFXF/QhODXtYv57b8RFqTYGtOxKcB lL9LBxwSmjWxwDfIlM5D/3I38/SNKcRNtkLSkFxg5TCXRmF7fyk9uiz4J39Q+ek72RzI tfkA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cochard-me.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ESHL5PSzRQmcSPcJfRLyLk6WhJrm77DWxaE/lW1cRoI=; b=elSCahn3ffBy+LqyoNy4trDieFF7Jo3HOUeYBLhp+0s926fE0BGsg4+SbJhCYIFttl G7009n4SyjfgOzu30iDSJWNoAfAamrW9BcFeJqu8yszQh0D2ogtPYJiPuII6rgUBmk2U ZAMdjXwk66LL4wAeLzhCOgnOS7MFqSk0+iu/niUd1Jed5nRNyWzV8A7urTpj1QuTRzfP R18k582vJjJNwbJM9qhYnvE81x0ZIggH1w47bZVMVZClcjO3ajdvfcFr63Lk+pzUMy1L wwDhf0tJaqL0NhZP13fhOGWRZXFm5tXCOJ1zgJ366L2q5ge4zGpCx+AhyhCVXC6A4nsl eZ4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=ESHL5PSzRQmcSPcJfRLyLk6WhJrm77DWxaE/lW1cRoI=; b=IZstXGuVJPI2n6CK14+0HMra90MrjSvJyeTJCL2Znva8WmqlAEOLZAu7okeWZV3QhS ucQRMsyys6W7E4AjcByWnHBd0Y6YIVGHZZtaxMpD290SjIc9X6xSkcIAArzZw0RTWKYS jHdhCTFYrwrsNiz+BNjwzGVanQFaDOm6+tKUH1EH4OElnuTuamX3ZFo/D8U4U0P8zl2S P3iEIsD6wHAIH6n8eX3XFNjgzBVbjKdF9hDG82lWq75DY5P2+WllvE44nIus+mEdE4zK Cdvo+Jh606JGMRXS8VmksHGrV/KHG5x4X0ioyJeE6cqqsKJXZnKYNGzf7pDNE6vhua4c gZuQ== X-Gm-Message-State: AG10YOREyU8O6nE96a9pRYfmNiNDyqvmsgjn4tIXEPjMPyT1MNHlDQKb7bgx+GUzHzrMVVINcrzN2F43tRnMPw== X-Received: by 10.25.33.198 with SMTP id h189mr4465883lfh.91.1453631115322; Sun, 24 Jan 2016 02:25:15 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.25.136.11 with HTTP; Sun, 24 Jan 2016 02:24:55 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Sun, 24 Jan 2016 11:24:55 +0100 X-Google-Sender-Auth: yMbqNz4oNLhDbsuPLrb_e0zf0N8 Message-ID: Subject: Re: Multicast routing on FreeBSD 11 current To: Ben Woods Cc: "freebsd-net@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 10:25:18 -0000 On Sun, Jan 24, 2016 at 9:41 AM, Ben Woods wrote: > > Hi everyone, > > Could someone running FreeBSD current on a test machine try loading the > ip_mroute driver on their machine? > =E2=80=8BHi, no problem here: root@lame5 # uname -a FreeBSD lame5.bsdrp.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294522: Thu Jan 21 20:07:04 CET 2016 root@lame5.bsdrp.net:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 root@lame5 # kldload ip_mroute root@lame5 =E2=80=8B # kldstat -m ip_mroute Id Refs Name 497 1 ip_mroute =E2=80=8BRegards, Olivier=E2=80=8B From owner-freebsd-net@freebsd.org Sun Jan 24 11:41:31 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D4117D78 for ; Sun, 24 Jan 2016 11:41:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2A29ECC for ; Sun, 24 Jan 2016 11:41:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0OBfUab069264 for ; Sun, 24 Jan 2016 11:41:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver Date: Sun, 24 Jan 2016 11:41:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: feature, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ohauer@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 11:41:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206528 Olli Hauer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ohauer@FreeBSD.org --- Comment #1 from Olli Hauer --- Hm, looking man(4) oce there is a hint to address such issues to emulex. I was myself looking the last days for an LPe12000 (FC) driver (no luck) but there is one for the LPe16000 on the emulex site http://www.emulex.com/downloads/emulex/drivers/freebsd/freebsd-10/drivers/ --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Jan 24 12:35:01 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E028A99989C for ; Sun, 24 Jan 2016 12:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D12505E0 for ; Sun, 24 Jan 2016 12:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0OCZ1re075303 for ; Sun, 24 Jan 2016 12:35:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver Date: Sun, 24 Jan 2016 12:35:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: feature, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ronald.valente@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 12:35:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206528 --- Comment #2 from Ron --- I looked there before opening the case, for me I just see this under downlo= ad: "Ethernet Driver - Use inbox driver" --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Jan 24 15:52:48 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B5489D9315 for ; Sun, 24 Jan 2016 15:52:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BA7413D0 for ; Sun, 24 Jan 2016 15:52:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0OFqlsG099249 for ; Sun, 24 Jan 2016 15:52:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver Date: Sun, 24 Jan 2016 15:52:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: feature, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ohauer@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 15:52:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206528 --- Comment #3 from Olli Hauer --- Hi Ron, you are right no download for 10.x, but there is a driver for 9.3 in the old pkg format. I'm not sure if it will work on 10.x and for FC but maybe give it a try. Perhaps Koobs or another Bugzilla admin can add the Emulex contact email address freebsd-drivers@emulex.com to the PR (does not exist until now so I cannot add the address to the CC list) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Jan 24 16:15:08 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BFE29D9E09 for ; Sun, 24 Jan 2016 16:15:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C5A06E6 for ; Sun, 24 Jan 2016 16:15:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0OGF7W3075920 for ; Sun, 24 Jan 2016 16:15:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver Date: Sun, 24 Jan 2016 16:15:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: feature, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ronald.valente@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 16:15:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206528 --- Comment #4 from Ron --- I will give it a shot shortly, last time I tried this I had failures due to= the change from gcc to clang. Will report back shortly. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Jan 24 16:26:58 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF0B67169 for ; Sun, 24 Jan 2016 16:26:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF49CDBC for ; Sun, 24 Jan 2016 16:26:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0OGQwBQ097740 for ; Sun, 24 Jan 2016 16:26:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver Date: Sun, 24 Jan 2016 16:26:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: feature, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ohauer@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 16:26:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206528 --- Comment #5 from Olli Hauer --- I forgot the change from gcc to clang already. oce.ko is a static module, and even it works I wouldn't trust in production without a vendor statement. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Jan 24 16:32:47 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 160F57462 for ; Sun, 24 Jan 2016 16:32:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 060961FA for ; Sun, 24 Jan 2016 16:32:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0OGWkFD011955 for ; Sun, 24 Jan 2016 16:32:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver Date: Sun, 24 Jan 2016 16:32:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: feature, needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 16:32:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206528 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #6 from Kubilay Kocak --- (In reply to Olli Hauer from comment #3) I don't think it's appropriate to create user accounts (to be CC'd on thing= s) without asking, but if you could send them an email to create an account th= at would be great :) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Jan 24 16:48:01 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59C597A17 for ; Sun, 24 Jan 2016 16:48:01 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7B4BB60 for ; Sun, 24 Jan 2016 16:48:00 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (31.147.117.175) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.266.1; Sun, 24 Jan 2016 17:46:42 +0100 Date: Sun, 24 Jan 2016 17:46:57 +0100 From: Marko Zec To: "Andrey V. Elsukov" CC: Ben Woods , Subject: Re: Multicast routing on FreeBSD 11 current Message-ID: <20160124174657.3d49b7c3@x23> In-Reply-To: <56A4A4C9.6000807@yandex.ru> References: <56A4A4C9.6000807@yandex.ru> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.147.117.175] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 16:48:01 -0000 On Sun, 24 Jan 2016 13:17:45 +0300 "Andrey V. Elsukov" wrote: > On 24.01.16 01:14, Ben Woods wrote: > > % sudo kldload -v ip_mroute > > kldload: an error occurred while loading the module. Please check > > dmesg(8) for more details. > > % dmesg > > linker_load_file: Unsupported file type > > > > Any ideas what could be causing this error? > > Usually this means that your running kernel is out of sync with > modules. You are running r294463, but __FreeBSD_version was bumped > recently in r294505. You need rebuild and reinstall your kernel and > all modules. In this particular case the problem is that ip_mroute demands more space for "virtualized global" variables than what kernel linker has put aside for each vnet. Bumping VNET_MODMIN to 24 should circumvent the issue that Ben is observing. A more vnet-friendly fix would require refactoring ip_mroute's arrays so that they get malloc()ed / free()d from SYSINIT handlers instead of being declared "virtualized global". Marko =================================================================== --- vnet.c (revision 294659) +++ vnet.c (working copy) @@ -170,7 +170,7 @@ * we want the virtualized global variable space to be page-sized, we may * have more space than that in practice. */ -#define VNET_MODMIN 8192 +#define VNET_MODMIN 3 * 8192 #define VNET_SIZE roundup2(VNET_BYTES, PAGE_SIZE) #define VNET_MODSIZE (VNET_SIZE - (VNET_BYTES - VNET_MODMIN)) From owner-freebsd-net@freebsd.org Sun Jan 24 16:53:44 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B24C57C44; Sun, 24 Jan 2016 16:53:44 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26315E38; Sun, 24 Jan 2016 16:53:44 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-lb0-x236.google.com with SMTP id cl12so63046539lbc.1; Sun, 24 Jan 2016 08:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FD00p7qA7PR7A0tBSfrMehHl1yLelya1wAnumvyMisA=; b=G7/4HOmUULNsqDhfCkJPgJQF+Za/0l8ATZczOnQuQPGIF7BJ7BtvSz2PCrVzWU8Ofg lr4pgDjhCwKL1BjDk/R6srWq9vMBXIe8R3E9mTN151r0n5eq60ro/AC1sLaGqrcb9PIJ 8EQMMTL6lD3Bpoy/Y7aemZv6g1nLv+6AJdokvKb3LPpxUBNR/32pL+cpzh9BwEmO8uJz MtKxj+6lRYAwQKIRDGSEmlZCjM80DF/98hDJm/YN2qKK6UkiCxS6la4EiC6T9Go+deHO XeXCo1YflwXYmx0KDW/QyXxzCimugrkjcoqmRh8KgTDGOedvCAqV6vSAFvVA9xVQOkjY tPjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FD00p7qA7PR7A0tBSfrMehHl1yLelya1wAnumvyMisA=; b=M3EaD25ZhlaANBT4CPhr21q1Yogr6d9P+Ny8kjCyXYo0LCwgYHjBAIEil6JJfouhPO TxX6Tlhr5zkQpTtx/GN/dovL3HDjMSNLbmu+ko5yGe9Mty6DfM3hpKZSYbxVcjuvmPrn QUa1d3mHidE604OFyzY00kvVNmvYx3vCn74L65mRE6ACxcgJr1dwek4oqpkyvEYpaG/m c27byv4Hkl69YDqq7qrqMmosbmCu6JEXmw0DnJbBReppbwem2EUf95Dx3W3ACZvWYJg+ V7WQ30CWhgOEgEhDu74eRp8ZfaufX1WIanCcC8X+Wg9UwQb2MmcvtFK6h3cfLkQeE4cr r3kQ== X-Gm-Message-State: AG10YOQFKpP0lffu0HTZPAn6u6lUBeKZrMUh8dnzfwDE0PL/eGWke7ki/zFkCi65t3RxFrvujazto6JJjxkk8A== MIME-Version: 1.0 X-Received: by 10.112.73.69 with SMTP id j5mr3778043lbv.124.1453654422324; Sun, 24 Jan 2016 08:53:42 -0800 (PST) Received: by 10.25.89.10 with HTTP; Sun, 24 Jan 2016 08:53:42 -0800 (PST) In-Reply-To: <56A4A91F.3020907@bsd.com.br> References: <56A4A91F.3020907@bsd.com.br> Date: Sun, 24 Jan 2016 17:53:42 +0100 Message-ID: Subject: Re: Multicast routing on FreeBSD 11 current From: Ben Woods To: =?UTF-8?B?T3RhY8OtbGlv?= Cc: FreeBSD Current , freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 16:53:44 -0000 On 24 January 2016 at 11:36, Otac=C3=ADlio wrote= : > Em 24/01/2016 07:24, Olivier Cochard-Labb=C3=A9 escreveu: > >> On Sun, Jan 24, 2016 at 9:41 AM, Ben Woods wrote: >> >> Hi everyone, >>> >>> Could someone running FreeBSD current on a test machine try loading the >>> ip_mroute driver on their machine? >>> >>> =E2=80=8BHi, >> >> no problem here: >> >> root@lame5 # uname -a >> FreeBSD lame5.bsdrp.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294522: Th= u >> Jan 21 20:07:04 CET 2016 >> root@lame5.bsdrp.net:/usr/obj/usr/src/sys/GENERIC-NODEBUG >> amd64 >> root@lame5 # kldload ip_mroute >> root@lame5 >> =E2=80=8B >> # kldstat -m ip_mroute >> Id Refs Name >> 497 1 ip_mroute >> >> >> =E2=80=8BRegards, >> >> Olivier=E2=80=8B >> >> > No problem here also. > > root@nostromo:~ # kldload ip_mroute > root@nostromo:~ # kldstat > Id Refs Address Size Name > 1 34 0xffffffff80200000 1e39ca8 kernel > 2 1 0xffffffff8203b000 e3b8 cuse.ko > 3 1 0xffffffff8204a000 3d90 pty.ko > 4 1 0xffffffff82221000 57b8 fdescfs.ko > 5 1 0xffffffff82227000 a3ac linprocfs.ko > 6 1 0xffffffff82232000 695a linux_common.ko > 7 1 0xffffffff82239000 26f8a vboxguest.ko > 8 1 0xffffffff82260000 7a9 vboxvideo.ko > 9 1 0xffffffff82261000 52092 drm2.ko > 10 1 0xffffffff822b4000 2679 iicbus.ko > 11 1 0xffffffff822b7000 1f6a imgact_binmisc.ko > 12 1 0xffffffff822b9000 657f nullfs.ko > 13 1 0xffffffff822c0000 abe8 tmpfs.ko > 14 1 0xffffffff822cb000 ceff ip_mroute.ko > root@nostromo:~ # uname -a > FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294319M: Tue Jan 1= 9 > 20:29:21 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/GENERIC amd64 > Thanks for your feedback everyone. Having spent some time now investigating, I have confirmed that this problem is related to VIMAGE. With VIMAGE enabled in the kernel, loading the ip_mroute kernel module will fail. With VIMAGE disabled on the same kernel source (no other changes), loading the ip_mroute kernel module works fine. I have submitted this bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206583 Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@freebsd.org Sun Jan 24 21:00:44 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB04F79E6 for ; Sun, 24 Jan 2016 21:00:44 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2F831CC2 for ; Sun, 24 Jan 2016 21:00:44 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0OL01eL036435 for ; Sun, 24 Jan 2016 21:00:44 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201601242100.u0OL01eL036435@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 24 Jan 2016 21:00:44 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 21:00:44 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 New | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc New | 203175 | Daily kernel crashes in tcp_twclose
Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89DE2A45BFB for ; Mon, 25 Jan 2016 00:41:20 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D5ACBD9 for ; Mon, 25 Jan 2016 00:41:20 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by quine.pinyon.org (Postfix, from userid 122) id 94D5416026A; Sun, 24 Jan 2016 17:41:19 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Received: from feyerabend.n1.pinyon.org (acipenser.esturion.net [65.101.5.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 9939C16015F for ; Sun, 24 Jan 2016 17:41:17 -0700 (MST) To: freebsd-net@freebsd.org From: "Russell L. Carter" Subject: ipfw NAT /etc/rc.firewall question Message-ID: <56A56F2D.2030200@pinyon.org> Date: Sun, 24 Jan 2016 17:41:17 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 00:41:20 -0000 Hi, I am making myself learn better how ipfw works. I am curious about the optimal location of the NAT rule definition code. My immediate application is a generic NATing gateway with an outside iface armored up and an inside iface permitting general anarchy. The usual services will be accessible to both sides. I plan to use kernel nat. Looking at /etc/rc.firewall: In the "open" | "client" section, natd/kernel nat are configured prior to other rules. In the "simple" section, natd only is configured after a bunch of rules, and before a bunch more. My question is, right after the natd configuration, are a bunch of rules that specify deny rules for problematic addresses. Here's the beginning and end of the section I'm curious about: ${fwcmd} add deny all from "table($BAD_ADDR_TBL)" to any via ${oif} if [ -n "$inet6" ]; then # Stop unique local unicast address on the outside interface ${fwcmd} add deny all from fc00::/7 to any via ${oif6} ${fwcmd} add deny all from any to fc00::/7 via ${oif6} ... ${fwcmd} add deny all from ff05::/16 to any via ${oif6} ${fwcmd} add deny all from any to ff05::/16 via ${oif6} fi Reading the comment before the nat configuration and also many comments provided by the goog, suggests it's better to define as many rules as possible before the nat config. But these rules are placed after. Can someone explain to me why this is better|required? I suspect I am missing something possibly important. This is stable/10. Thanks, Russell From owner-freebsd-net@freebsd.org Mon Jan 25 05:02:06 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DB10A31B2A for ; Mon, 25 Jan 2016 05:02:06 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id 58BEC1072 for ; Mon, 25 Jan 2016 05:02:06 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id 5341211F3A; Mon, 25 Jan 2016 05:02:06 +0000 (UTC) Date: Mon, 25 Jan 2016 05:02:06 +0000 To: freebsd-net@freebsd.org From: Phabricator Reply-to: D4972+325+2449bd8dbd7bc4eb@reviews.freebsd.org Subject: [Differential] [Closed] D4972: hyperv/hn: Partly rework transmission path Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D4972: hyperv/hn: Partly rework transmission path X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: MmY5Y2UyM2Y0YmJkYzM2NTIzMDc0Y2ViYzdkIFalrE4= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_d2ebb1e510a55e19fba0ba13c5d96832" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 05:02:06 -0000 --b1_d2ebb1e510a55e19fba0ba13c5d96832 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit This revision was automatically updated to reflect the committed changes. Closed by commit rS294700: hyperv/hn: Partly rework transmission path (authored by sephe). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D4972?vs=12444&id=12668#toc REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D4972?vs=12444&id=12668 REVISION DETAIL https://reviews.freebsd.org/D4972 AFFECTED FILES head/sys/dev/hyperv/netvsc/hv_net_vsc.c head/sys/dev/hyperv/netvsc/hv_net_vsc.h head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c head/sys/dev/hyperv/netvsc/hv_rndis.h head/sys/dev/hyperv/netvsc/hv_rndis_filter.c head/sys/dev/hyperv/netvsc/hv_rndis_filter.h EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, delphij, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, royger, network, adrian Cc: freebsd-net-list --b1_d2ebb1e510a55e19fba0ba13c5d96832 Content-Type: text/x-patch; charset=utf-8; name="D4972.12668.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D4972.12668.patch" ZGlmZiAtLWdpdCBhL2hlYWQvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X3JuZGlzX2ZpbHRlci5o IGIvaGVhZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfcm5kaXNfZmlsdGVyLmgKLS0tIGEvaGVh ZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfcm5kaXNfZmlsdGVyLmgKKysrIGIvaGVhZC9zeXMv ZGV2L2h5cGVydi9uZXR2c2MvaHZfcm5kaXNfZmlsdGVyLmgKQEAgLTk5LDYgKzk5LDcgQEAKIGlu dCBodl9yZl9vbl9yZWNlaXZlKG5ldHZzY19kZXYgKm5ldF9kZXYsCiAgICAgc3RydWN0IGh2X2Rl dmljZSAqZGV2aWNlLCBuZXR2c2NfcGFja2V0ICpwa3QpOwogdm9pZCBodl9yZl9yZWNlaXZlX3Jv bGx1cChuZXR2c2NfZGV2ICpuZXRfZGV2KTsKK3ZvaWQgaHZfcmZfY2hhbm5lbF9yb2xsdXAobmV0 dnNjX2RldiAqbmV0X2Rldik7CiBpbnQgaHZfcmZfb25fZGV2aWNlX2FkZChzdHJ1Y3QgaHZfZGV2 aWNlICpkZXZpY2UsIHZvaWQgKmFkZGl0bF9pbmZvKTsKIGludCBodl9yZl9vbl9kZXZpY2VfcmVt b3ZlKHN0cnVjdCBodl9kZXZpY2UgKmRldmljZSwgYm9vbGVhbl90IGRlc3Ryb3lfY2hhbm5lbCk7 CiBpbnQgaHZfcmZfb25fb3BlbihzdHJ1Y3QgaHZfZGV2aWNlICpkZXZpY2UpOwpkaWZmIC0tZ2l0 IGEvaGVhZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfcm5kaXNfZmlsdGVyLmMgYi9oZWFkL3N5 cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9ybmRpc19maWx0ZXIuYwotLS0gYS9oZWFkL3N5cy9kZXYv aHlwZXJ2L25ldHZzYy9odl9ybmRpc19maWx0ZXIuYworKysgYi9oZWFkL3N5cy9kZXYvaHlwZXJ2 L25ldHZzYy9odl9ybmRpc19maWx0ZXIuYwpAQCAtOTc0LDMgKzk3NCwyMSBAQAogCXJuZGlzX2Rl diA9IChybmRpc19kZXZpY2UgKiluZXRfZGV2LT5leHRlbnNpb247CiAJbmV0dnNjX3JlY3Zfcm9s bHVwKHJuZGlzX2Rldi0+bmV0X2Rldi0+ZGV2KTsKIH0KKwordm9pZAoraHZfcmZfY2hhbm5lbF9y b2xsdXAobmV0dnNjX2RldiAqbmV0X2RldikKK3sKKwlybmRpc19kZXZpY2UgKnJuZGlzX2RldjsK KworCXJuZGlzX2RldiA9IChybmRpc19kZXZpY2UgKiluZXRfZGV2LT5leHRlbnNpb247CisKKwkv KgorCSAqIFRoaXMgY291bGQgYmUgY2FsbGVkIHByZXR0eSBlYXJseSwgc28gd2UgbmVlZAorCSAq IHRvIG1ha2Ugc3VyZSBldmVyeXRoaW5nIGhhcyBiZWVuIHNldHVwLgorCSAqLworCWlmIChybmRp c19kZXYgPT0gTlVMTCB8fAorCSAgICBybmRpc19kZXYtPm5ldF9kZXYgPT0gTlVMTCB8fAorCSAg ICBybmRpc19kZXYtPm5ldF9kZXYtPmRldiA9PSBOVUxMKQorCQlyZXR1cm47CisJbmV0dnNjX2No YW5uZWxfcm9sbHVwKHJuZGlzX2Rldi0+bmV0X2Rldi0+ZGV2KTsKK30KZGlmZiAtLWdpdCBhL2hl YWQvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X3JuZGlzLmggYi9oZWFkL3N5cy9kZXYvaHlwZXJ2 L25ldHZzYy9odl9ybmRpcy5oCi0tLSBhL2hlYWQvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X3Ju ZGlzLmgKKysrIGIvaGVhZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfcm5kaXMuaApAQCAtMTA1 MCw2ICsxMDUwLDcgQEAKICAgICBuZXR2c2NfcGFja2V0ICpwYWNrZXQsIAogICAgIHJuZGlzX3Rj cF9pcF9jc3VtX2luZm8gKmNzdW1faW5mbyk7CiB2b2lkIG5ldHZzY19yZWN2X3JvbGx1cChzdHJ1 Y3QgaHZfZGV2aWNlICpkZXZpY2VfY3R4KTsKK3ZvaWQgbmV0dnNjX2NoYW5uZWxfcm9sbHVwKHN0 cnVjdCBodl9kZXZpY2UgKmRldmljZV9jdHgpOwogCiB2b2lkKiBodl9zZXRfcnBwaV9kYXRhKHJu ZGlzX21zZyAqcm5kaXNfbWVzZywKICAgICB1aW50MzJfdCBycHBpX3NpemUsCmRpZmYgLS1naXQg YS9oZWFkL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2QuYyBiL2hl YWQvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X25ldHZzY19kcnZfZnJlZWJzZC5jCi0tLSBhL2hl YWQvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X25ldHZzY19kcnZfZnJlZWJzZC5jCisrKyBiL2hl YWQvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X25ldHZzY19kcnZfZnJlZWJzZC5jCkBAIC0xMjks NiArMTI5LDQxIEBACiAjZGVmaW5lIEhWX05WX1NDX1BUUl9PRkZTRVRfSU5fQlVGICAgICAgICAg MAogI2RlZmluZSBIVl9OVl9QQUNLRVRfT0ZGU0VUX0lOX0JVRiAgICAgICAgIDE2CiAKKy8qIFlZ WSBzaG91bGQgZ2V0IGl0IGZyb20gdGhlIHVuZGVybHlpbmcgY2hhbm5lbCAqLworI2RlZmluZSBI Tl9UWF9ERVNDX0NOVAkJCTUxMgorCisjZGVmaW5lIEhOX1JORElTX01TR19MRU4JCVwKKyAgICAo c2l6ZW9mKHJuZGlzX21zZykgKwkJXAorICAgICBSTkRJU19WTEFOX1BQSV9TSVpFICsJCVwKKyAg ICAgUk5ESVNfVFNPX1BQSV9TSVpFICsJCVwKKyAgICAgUk5ESVNfQ1NVTV9QUElfU0laRSkKKyNk ZWZpbmUgSE5fUk5ESVNfTVNHX0JPVU5EQVJZCQlQQUdFX1NJWkUKKyNkZWZpbmUgSE5fUk5ESVNf TVNHX0FMSUdOCQlDQUNIRV9MSU5FX1NJWkUKKworI2RlZmluZSBITl9UWF9EQVRBX0JPVU5EQVJZ CQlQQUdFX1NJWkUKKyNkZWZpbmUgSE5fVFhfREFUQV9NQVhTSVpFCQlJUF9NQVhQQUNLRVQKKyNk ZWZpbmUgSE5fVFhfREFUQV9TRUdTSVpFCQlQQUdFX1NJWkUKKyNkZWZpbmUgSE5fVFhfREFUQV9T RUdDTlRfTUFYCQlcCisgICAgKE5FVFZTQ19QQUNLRVRfTUFYUEFHRSAtIEhWX1JGX05VTV9UWF9S RVNFUlZFRF9QQUdFX0JVRlMpCisKK3N0cnVjdCBobl90eGRlc2MgeworCVNMSVNUX0VOVFJZKGhu X3R4ZGVzYykgbGluazsKKwlzdHJ1Y3QgbWJ1ZgkqbTsKKwlzdHJ1Y3QgaG5fc29mdGMJKnNjOwor CWludAkJcmVmczsKKwl1aW50MzJfdAlmbGFnczsJCS8qIEhOX1RYRF9GTEFHXyAqLworCW5ldHZz Y19wYWNrZXQJbmV0dnNjX3BrdDsJLyogWFhYIHRvIGJlIHJlbW92ZWQgKi8KKworCWJ1c19kbWFt YXBfdAlkYXRhX2RtYXA7CisKKwlidXNfYWRkcl90CXJuZGlzX21zZ19wYWRkcjsKKwlybmRpc19t c2cJKnJuZGlzX21zZzsKKwlidXNfZG1hbWFwX3QJcm5kaXNfbXNnX2RtYXA7Cit9OworCisjZGVm aW5lIEhOX1RYRF9GTEFHX09OTElTVAkweDEKKyNkZWZpbmUgSE5fVFhEX0ZMQUdfRE1BTUFQCTB4 MgorCiAvKgogICogQSB1bmlmaWVkIGZsYWcgZm9yIGFsbCBvdXRib3VuZCBjaGVjayBzdW0gZmxh Z3MgaXMgdXNlZnVsLAogICogYW5kIGl0IGhlbHBzIGF2b2lkaW5nIHVubmVjZXNzYXJ5IGNoZWNr IHN1bSBjYWxjdWxhdGlvbiBpbgpAQCAtMTc0LDIxICsyMDksMzQgQEAKIHN0YXRpYyBpbnQgaG5f dHJ1c3RfaG9zdHRjcCA9IDA7CiBUVU5BQkxFX0lOVCgiZGV2LmhuLnRydXN0X2hvc3R0Y3AiLCAm aG5fdHJ1c3RfaG9zdHRjcCk7CiAKKyNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+PSAxMTAwMDQ1Cisv KiBMaW1pdCBUU08gYnVyc3Qgc2l6ZSAqLworc3RhdGljIGludCBobl90c29fbWF4bGVuID0gMDsK K1RVTkFCTEVfSU5UKCJkZXYuaG4udHNvX21heGxlbiIsICZobl90c29fbWF4bGVuKTsKKyNlbmRp ZgorCisvKiBMaW1pdCBjaGltbmV5IHNlbmQgc2l6ZSAqLworc3RhdGljIGludCBobl90eF9jaGlt bmV5X3NpemUgPSAwOworVFVOQUJMRV9JTlQoImRldi5obi50eF9jaGltbmV5X3NpemUiLCAmaG5f dHhfY2hpbW5leV9zaXplKTsKKwogLyoKICAqIEZvcndhcmQgZGVjbGFyYXRpb25zCiAgKi8KIHN0 YXRpYyB2b2lkIGhuX3N0b3AoaG5fc29mdGNfdCAqc2MpOwogc3RhdGljIHZvaWQgaG5faWZpbml0 X2xvY2tlZChobl9zb2Z0Y190ICpzYyk7CiBzdGF0aWMgdm9pZCBobl9pZmluaXQodm9pZCAqeHNj KTsKIHN0YXRpYyBpbnQgIGhuX2lvY3RsKHN0cnVjdCBpZm5ldCAqaWZwLCB1X2xvbmcgY21kLCBj YWRkcl90IGRhdGEpOwotc3RhdGljIGludCAgaG5fc3RhcnRfbG9ja2VkKHN0cnVjdCBpZm5ldCAq aWZwKTsKK3N0YXRpYyB2b2lkIGhuX3N0YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKmlmcCk7CiBz dGF0aWMgdm9pZCBobl9zdGFydChzdHJ1Y3QgaWZuZXQgKmlmcCk7CiBzdGF0aWMgaW50IGhuX2lm bWVkaWFfdXBkKHN0cnVjdCBpZm5ldCAqaWZwKTsKIHN0YXRpYyB2b2lkIGhuX2lmbWVkaWFfc3Rz KHN0cnVjdCBpZm5ldCAqaWZwLCBzdHJ1Y3QgaWZtZWRpYXJlcSAqaWZtcik7CiAjaWZkZWYgSE5f TFJPX0hJV0FUCiBzdGF0aWMgaW50IGhuX2xyb19oaXdhdF9zeXNjdGwoU1lTQ1RMX0hBTkRMRVJf QVJHUyk7CiAjZW5kaWYKK3N0YXRpYyBpbnQgaG5fdHhfY2hpbW5leV9zaXplX3N5c2N0bChTWVND VExfSEFORExFUl9BUkdTKTsKIHN0YXRpYyBpbnQgaG5fY2hlY2tfaXBsZW4oY29uc3Qgc3RydWN0 IG1idWYgKiwgaW50KTsKK3N0YXRpYyBpbnQgaG5fY3JlYXRlX3R4X3Jpbmcoc3RydWN0IGhuX3Nv ZnRjICpzYyk7CitzdGF0aWMgdm9pZCBobl9kZXN0cm95X3R4X3Jpbmcoc3RydWN0IGhuX3NvZnRj ICpzYyk7CiAKIHN0YXRpYyBfX2lubGluZSB2b2lkCiBobl9zZXRfbHJvX2hpd2F0KHN0cnVjdCBo bl9zb2Z0YyAqc2MsIGludCBoaXdhdCkKQEAgLTMxOCwxMCArMzY2LDEzIEBACiAJbmV0dnNjX2Rl dmljZV9pbmZvIGRldmljZV9pbmZvOwogCWhuX3NvZnRjX3QgKnNjOwogCWludCB1bml0ID0gZGV2 aWNlX2dldF91bml0KGRldik7Ci0Jc3RydWN0IGlmbmV0ICppZnA7CisJc3RydWN0IGlmbmV0ICpp ZnAgPSBOVUxMOwogCXN0cnVjdCBzeXNjdGxfb2lkX2xpc3QgKmNoaWxkOwogCXN0cnVjdCBzeXNj dGxfY3R4X2xpc3QgKmN0eDsKLQlpbnQgcmV0OworCWludCBlcnJvcjsKKyNpZiBfX0ZyZWVCU0Rf dmVyc2lvbiA+PSAxMTAwMDQ1CisJaW50IHRzb19tYXhsZW47CisjZW5kaWYKIAogCXNjID0gZGV2 aWNlX2dldF9zb2Z0YyhkZXYpOwogCWlmIChzYyA9PSBOVUxMKSB7CkBAIC0zMzQsNiArMzg1LDEw IEBACiAJc2MtPmhuX2xyb19oaXdhdCA9IEhOX0xST19ISVdBVF9ERUY7CiAJc2MtPmhuX3RydXN0 X2hvc3R0Y3AgPSBobl90cnVzdF9ob3N0dGNwOwogCisJZXJyb3IgPSBobl9jcmVhdGVfdHhfcmlu ZyhzYyk7CisJaWYgKGVycm9yKQorCQlnb3RvIGZhaWxlZDsKKwogCU5WX0xPQ0tfSU5JVChzYywg Ik5ldFZTQ0xvY2siKTsKIAogCXNjLT5obl9kZXZfb2JqID0gZGV2aWNlX2N0eDsKQEAgLTM4MSwx MiArNDM2LDEwIEBACiAJZWxzZQogCQlpZnAtPmlmX2h3YXNzaXN0ID0gQ1NVTV9UQ1AgfCBDU1VN X1RTTzsKIAotCXJldCA9IGh2X3JmX29uX2RldmljZV9hZGQoZGV2aWNlX2N0eCwgJmRldmljZV9p bmZvKTsKLQlpZiAocmV0ICE9IDApIHsKLQkJaWZfZnJlZShpZnApOworCWVycm9yID0gaHZfcmZf b25fZGV2aWNlX2FkZChkZXZpY2VfY3R4LCAmZGV2aWNlX2luZm8pOworCWlmIChlcnJvcikKKwkJ Z290byBmYWlsZWQ7CiAKLQkJcmV0dXJuIChyZXQpOwotCX0KIAlpZiAoZGV2aWNlX2luZm8ubGlu a19zdGF0ZSA9PSAwKSB7CiAJCXNjLT5obl9jYXJyaWVyID0gMTsKIAl9CkBAIC00MDAsOCArNDUz LDMwIEBACiAjZW5kaWYKICNlbmRpZgkvKiBJTkVUIHx8IElORVQ2ICovCiAKKyNpZiBfX0ZyZWVC U0RfdmVyc2lvbiA+PSAxMTAwMDQ1CisJdHNvX21heGxlbiA9IGhuX3Rzb19tYXhsZW47CisJaWYg KHRzb19tYXhsZW4gPD0gMCB8fCB0c29fbWF4bGVuID4gSVBfTUFYUEFDS0VUKQorCQl0c29fbWF4 bGVuID0gSVBfTUFYUEFDS0VUOworCisJaWZwLT5pZl9od190c29tYXhzZWdjb3VudCA9IEhOX1RY X0RBVEFfU0VHQ05UX01BWDsKKwlpZnAtPmlmX2h3X3Rzb21heHNlZ3NpemUgPSBQQUdFX1NJWkU7 CisJaWZwLT5pZl9od190c29tYXggPSB0c29fbWF4bGVuIC0KKwkgICAgKEVUSEVSX0hEUl9MRU4g KyBFVEhFUl9WTEFOX0VOQ0FQX0xFTik7CisjZW5kaWYKKwogCWV0aGVyX2lmYXR0YWNoKGlmcCwg ZGV2aWNlX2luZm8ubWFjX2FkZHIpOwogCisjaWYgX19GcmVlQlNEX3ZlcnNpb24gPj0gMTEwMDA0 NQorCWlmX3ByaW50ZihpZnAsICJUU086ICV1LyV1LyV1XG4iLCBpZnAtPmlmX2h3X3Rzb21heCwK KwkgICAgaWZwLT5pZl9od190c29tYXhzZWdjb3VudCwgaWZwLT5pZl9od190c29tYXhzZWdzaXpl KTsKKyNlbmRpZgorCisJc2MtPmhuX3R4X2NoaW1uZXlfbWF4ID0gc2MtPm5ldF9kZXYtPnNlbmRf c2VjdGlvbl9zaXplOworCXNjLT5obl90eF9jaGltbmV5X3NpemUgPSBzYy0+aG5fdHhfY2hpbW5l eV9tYXg7CisJaWYgKGhuX3R4X2NoaW1uZXlfc2l6ZSA+IDAgJiYKKwkgICAgaG5fdHhfY2hpbW5l eV9zaXplIDwgc2MtPmhuX3R4X2NoaW1uZXlfbWF4KQorCQlzYy0+aG5fdHhfY2hpbW5leV9zaXpl ID0gaG5fdHhfY2hpbW5leV9zaXplOworCiAJY3R4ID0gZGV2aWNlX2dldF9zeXNjdGxfY3R4KGRl dik7CiAJY2hpbGQgPSBTWVNDVExfQ0hJTERSRU4oZGV2aWNlX2dldF9zeXNjdGxfdHJlZShkZXYp KTsKIApAQCAtNDI5LDYgKzUwNCwyNiBAQAogCSAgICAiIyBvZiBUQ1Agc2VnZW1lbnRzIHRoYXQg d2UgdHJ1c3QgaG9zdCdzIGNzdW0gdmVyaWZpY2F0aW9uIik7CiAJU1lTQ1RMX0FERF9VTE9ORyhj dHgsIGNoaWxkLCBPSURfQVVUTywgInNtYWxsX3BrdHMiLAogCSAgICBDVExGTEFHX1JXLCAmc2Mt PmhuX3NtYWxsX3BrdHMsICIjIG9mIHNtYWxsIHBhY2tldHMgcmVjZWl2ZWQiKTsKKwlTWVNDVExf QUREX1VMT05HKGN0eCwgY2hpbGQsIE9JRF9BVVRPLCAibm9fdHhkZXNjcyIsCisJICAgIENUTEZM QUdfUlcsICZzYy0+aG5fbm9fdHhkZXNjcywgIiMgb2YgdGltZXMgc2hvcnQgb2YgVFggZGVzY3Mi KTsKKwlTWVNDVExfQUREX1VMT05HKGN0eCwgY2hpbGQsIE9JRF9BVVRPLCAic2VuZF9mYWlsZWQi LAorCSAgICBDVExGTEFHX1JXLCAmc2MtPmhuX3NlbmRfZmFpbGVkLCAiIyBvZiBoeXBlci12IHNl bmRpbmcgZmFpbHVyZSIpOworCVNZU0NUTF9BRERfVUxPTkcoY3R4LCBjaGlsZCwgT0lEX0FVVE8s ICJ0eGRtYV9mYWlsZWQiLAorCSAgICBDVExGTEFHX1JXLCAmc2MtPmhuX3R4ZG1hX2ZhaWxlZCwg IiMgb2YgVFggRE1BIGZhaWx1cmUiKTsKKwlTWVNDVExfQUREX1VMT05HKGN0eCwgY2hpbGQsIE9J RF9BVVRPLCAidHhfY29sbGFwc2VkIiwKKwkgICAgQ1RMRkxBR19SVywgJnNjLT5obl90eF9jb2xs YXBzZWQsICIjIG9mIFRYIG1idWYgY29sbGFwc2VkIik7CisJU1lTQ1RMX0FERF9VTE9ORyhjdHgs IGNoaWxkLCBPSURfQVVUTywgInR4X2NoaW1uZXkiLAorCSAgICBDVExGTEFHX1JXLCAmc2MtPmhu X3R4X2NoaW1uZXksICIjIG9mIGNoaW1uZXkgc2VuZCIpOworCVNZU0NUTF9BRERfSU5UKGN0eCwg Y2hpbGQsIE9JRF9BVVRPLCAidHhkZXNjX2NudCIsCisJICAgIENUTEZMQUdfUkQsICZzYy0+aG5f dHhkZXNjX2NudCwgMCwgIiMgb2YgdG90YWwgVFggZGVzY3MiKTsKKwlTWVNDVExfQUREX0lOVChj dHgsIGNoaWxkLCBPSURfQVVUTywgInR4ZGVzY19hdmFpbCIsCisJICAgIENUTEZMQUdfUkQsICZz Yy0+aG5fdHhkZXNjX2F2YWlsLCAwLCAiIyBvZiBhdmFpbGFibGUgVFggZGVzY3MiKTsKKwlTWVND VExfQUREX0lOVChjdHgsIGNoaWxkLCBPSURfQVVUTywgInR4X2NoaW1uZXlfbWF4IiwKKwkgICAg Q1RMRkxBR19SRCwgJnNjLT5obl90eF9jaGltbmV5X21heCwgMCwKKwkgICAgIkNoaW1uZXkgc2Vu ZCBwYWNrZXQgc2l6ZSB1cHBlciBib3VuZGFyeSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIGNo aWxkLCBPSURfQVVUTywgInR4X2NoaW1uZXlfc2l6ZSIsCisJICAgIENUTFRZUEVfSU5UIHwgQ1RM RkxBR19SVywgc2MsIDAsIGhuX3R4X2NoaW1uZXlfc2l6ZV9zeXNjdGwsCisJICAgICJJIiwgIkNo aW1uZXkgc2VuZCBwYWNrZXQgc2l6ZSBsaW1pdCIpOwogCiAJaWYgKHVuaXQgPT0gMCkgewogCQlz dHJ1Y3Qgc3lzY3RsX2N0eF9saXN0ICpkY19jdHg7CkBAIC00NDYsOSArNTQxLDIxIEBACiAJCSAg ICBDVExGTEFHX1JELCAmaG5fdHJ1c3RfaG9zdHRjcCwgMCwKIAkJICAgICJUcnVzdCB0Y3Agc2Vn ZW1lbnQgdmVyaWZpY2F0aW9uIG9uIGhvc3Qgc2lkZSwgIgogCQkgICAgIndoZW4gY3N1bSBpbmZv IGlzIG1pc3NpbmcgKGdsb2JhbCBzZXR0aW5nKSIpOworCQlTWVNDVExfQUREX0lOVChkY19jdHgs IGRjX2NoaWxkLCBPSURfQVVUTywgInR4X2NoaW1uZXlfc2l6ZSIsCisJCSAgICBDVExGTEFHX1JE LCAmaG5fdHhfY2hpbW5leV9zaXplLCAwLAorCQkgICAgIkNoaW1uZXkgc2VuZCBwYWNrZXQgc2l6 ZSBsaW1pdCIpOworI2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDExMDAwNDUKKwkJU1lTQ1RMX0FE RF9JTlQoZGNfY3R4LCBkY19jaGlsZCwgT0lEX0FVVE8sICJ0c29fbWF4bGVuIiwKKwkJICAgIENU TEZMQUdfUkQsICZobl90c29fbWF4bGVuLCAwLCAiVFNPIGJ1cnN0IGxpbWl0Iik7CisjZW5kaWYK IAl9CiAKIAlyZXR1cm4gKDApOworZmFpbGVkOgorCWhuX2Rlc3Ryb3lfdHhfcmluZyhzYyk7CisJ aWYgKGlmcCAhPSBOVUxMKQorCQlpZl9mcmVlKGlmcCk7CisJcmV0dXJuIChlcnJvcik7CiB9CiAK IC8qCkBAIC00ODAsNiArNTg3LDcgQEAKICNpZiBkZWZpbmVkKElORVQpIHx8IGRlZmluZWQoSU5F VDYpCiAJdGNwX2xyb19mcmVlKCZzYy0+aG5fbHJvKTsKICNlbmRpZgorCWhuX2Rlc3Ryb3lfdHhf cmluZyhzYyk7CiAKIAlyZXR1cm4gKDApOwogfQpAQCAtNDkzLDYgKzYwMSwxMTIgQEAKIAlyZXR1 cm4gKDApOwogfQogCitzdGF0aWMgX19pbmxpbmUgaW50Citobl90eGRlc2NfZG1hbWFwX2xvYWQo c3RydWN0IGhuX3NvZnRjICpzYywgc3RydWN0IGhuX3R4ZGVzYyAqdHhkLAorICAgIHN0cnVjdCBt YnVmICoqbV9oZWFkLCBidXNfZG1hX3NlZ21lbnRfdCAqc2VncywgaW50ICpuc2VncykKK3sKKwlz dHJ1Y3QgbWJ1ZiAqbSA9ICptX2hlYWQ7CisJaW50IGVycm9yOworCisJZXJyb3IgPSBidXNfZG1h bWFwX2xvYWRfbWJ1Zl9zZyhzYy0+aG5fdHhfZGF0YV9kdGFnLCB0eGQtPmRhdGFfZG1hcCwKKwkg ICAgbSwgc2VncywgbnNlZ3MsIEJVU19ETUFfTk9XQUlUKTsKKwlpZiAoZXJyb3IgPT0gRUZCSUcp IHsKKwkJc3RydWN0IG1idWYgKm1fbmV3OworCisJCW1fbmV3ID0gbV9jb2xsYXBzZShtLCBNX05P V0FJVCwgSE5fVFhfREFUQV9TRUdDTlRfTUFYKTsKKwkJaWYgKG1fbmV3ID09IE5VTEwpCisJCQly ZXR1cm4gRU5PQlVGUzsKKwkJZWxzZQorCQkJKm1faGVhZCA9IG0gPSBtX25ldzsKKwkJc2MtPmhu X3R4X2NvbGxhcHNlZCsrOworCisJCWVycm9yID0gYnVzX2RtYW1hcF9sb2FkX21idWZfc2coc2Mt PmhuX3R4X2RhdGFfZHRhZywKKwkJICAgIHR4ZC0+ZGF0YV9kbWFwLCBtLCBzZWdzLCBuc2Vncywg QlVTX0RNQV9OT1dBSVQpOworCX0KKwlpZiAoIWVycm9yKSB7CisJCWJ1c19kbWFtYXBfc3luYyhz Yy0+aG5fdHhfZGF0YV9kdGFnLCB0eGQtPmRhdGFfZG1hcCwKKwkJICAgIEJVU19ETUFTWU5DX1BS RVdSSVRFKTsKKwkJdHhkLT5mbGFncyB8PSBITl9UWERfRkxBR19ETUFNQVA7CisJfQorCXJldHVy biBlcnJvcjsKK30KKworc3RhdGljIF9faW5saW5lIHZvaWQKK2huX3R4ZGVzY19kbWFtYXBfdW5s b2FkKHN0cnVjdCBobl9zb2Z0YyAqc2MsIHN0cnVjdCBobl90eGRlc2MgKnR4ZCkKK3sKKworCWlm ICh0eGQtPmZsYWdzICYgSE5fVFhEX0ZMQUdfRE1BTUFQKSB7CisJCWJ1c19kbWFtYXBfc3luYyhz Yy0+aG5fdHhfZGF0YV9kdGFnLAorCQkgICAgdHhkLT5kYXRhX2RtYXAsIEJVU19ETUFTWU5DX1BP U1RXUklURSk7CisJCWJ1c19kbWFtYXBfdW5sb2FkKHNjLT5obl90eF9kYXRhX2R0YWcsCisJCSAg ICB0eGQtPmRhdGFfZG1hcCk7CisJCXR4ZC0+ZmxhZ3MgJj0gfkhOX1RYRF9GTEFHX0RNQU1BUDsK Kwl9Cit9CisKK3N0YXRpYyBfX2lubGluZSBpbnQKK2huX3R4ZGVzY19wdXQoc3RydWN0IGhuX3Nv ZnRjICpzYywgc3RydWN0IGhuX3R4ZGVzYyAqdHhkKQoreworCisJS0FTU0VSVCgodHhkLT5mbGFn cyAmIEhOX1RYRF9GTEFHX09OTElTVCkgPT0gMCwKKwkgICAgKCJwdXQgYW4gb25saXN0IHR4ZCAl I3giLCB0eGQtPmZsYWdzKSk7CisKKwlLQVNTRVJUKHR4ZC0+cmVmcyA+IDAsICgiaW52YWxpZCB0 eGQgcmVmcyAlZCIsIHR4ZC0+cmVmcykpOworCWlmIChhdG9taWNfZmV0Y2hhZGRfaW50KCZ0eGQt PnJlZnMsIC0xKSAhPSAxKQorCQlyZXR1cm4gMDsKKworCWhuX3R4ZGVzY19kbWFtYXBfdW5sb2Fk KHNjLCB0eGQpOworCWlmICh0eGQtPm0gIT0gTlVMTCkgeworCQltX2ZyZWVtKHR4ZC0+bSk7CisJ CXR4ZC0+bSA9IE5VTEw7CisJfQorCisJdHhkLT5mbGFncyB8PSBITl9UWERfRkxBR19PTkxJU1Q7 CisKKwltdHhfbG9ja19zcGluKCZzYy0+aG5fdHhsaXN0X3NwaW4pOworCUtBU1NFUlQoc2MtPmhu X3R4ZGVzY19hdmFpbCA+PSAwICYmCisJICAgIHNjLT5obl90eGRlc2NfYXZhaWwgPCBzYy0+aG5f dHhkZXNjX2NudCwKKwkgICAgKCJ0eGRlc2NfcHV0OiBpbnZhbGlkIHR4ZCBhdmFpbCAlZCIsIHNj LT5obl90eGRlc2NfYXZhaWwpKTsKKwlzYy0+aG5fdHhkZXNjX2F2YWlsKys7CisJU0xJU1RfSU5T RVJUX0hFQUQoJnNjLT5obl90eGxpc3QsIHR4ZCwgbGluayk7CisJbXR4X3VubG9ja19zcGluKCZz Yy0+aG5fdHhsaXN0X3NwaW4pOworCisJcmV0dXJuIDE7Cit9CisKK3N0YXRpYyBfX2lubGluZSBz dHJ1Y3QgaG5fdHhkZXNjICoKK2huX3R4ZGVzY19nZXQoc3RydWN0IGhuX3NvZnRjICpzYykKK3sK KwlzdHJ1Y3QgaG5fdHhkZXNjICp0eGQ7CisKKwltdHhfbG9ja19zcGluKCZzYy0+aG5fdHhsaXN0 X3NwaW4pOworCXR4ZCA9IFNMSVNUX0ZJUlNUKCZzYy0+aG5fdHhsaXN0KTsKKwlpZiAodHhkICE9 IE5VTEwpIHsKKwkJS0FTU0VSVChzYy0+aG5fdHhkZXNjX2F2YWlsID4gMCwKKwkJICAgICgidHhk ZXNjX2dldDogaW52YWxpZCB0eGQgYXZhaWwgJWQiLCBzYy0+aG5fdHhkZXNjX2F2YWlsKSk7CisJ CXNjLT5obl90eGRlc2NfYXZhaWwtLTsKKwkJU0xJU1RfUkVNT1ZFX0hFQUQoJnNjLT5obl90eGxp c3QsIGxpbmspOworCX0KKwltdHhfdW5sb2NrX3NwaW4oJnNjLT5obl90eGxpc3Rfc3Bpbik7CisK KwlpZiAodHhkICE9IE5VTEwpIHsKKwkJS0FTU0VSVCh0eGQtPm0gPT0gTlVMTCAmJiB0eGQtPnJl ZnMgPT0gMCAmJgorCQkgICAgKHR4ZC0+ZmxhZ3MgJiBITl9UWERfRkxBR19PTkxJU1QpLCAoImlu dmFsaWQgdHhkIikpOworCQl0eGQtPmZsYWdzICY9IH5ITl9UWERfRkxBR19PTkxJU1Q7CisJCXR4 ZC0+cmVmcyA9IDE7CisJfQorCXJldHVybiB0eGQ7Cit9CisKK3N0YXRpYyBfX2lubGluZSB2b2lk Citobl90eGRlc2NfaG9sZChzdHJ1Y3QgaG5fdHhkZXNjICp0eGQpCit7CisKKwkvKiAwLT4xIHRy YW5zaXRpb24gd2lsbCBuZXZlciB3b3JrICovCisJS0FTU0VSVCh0eGQtPnJlZnMgPiAwLCAoImlu dmFsaWQgcmVmcyAlZCIsIHR4ZC0+cmVmcykpOworCWF0b21pY19hZGRfaW50KCZ0eGQtPnJlZnMs IDEpOworfQorCiAvKgogICogU2VuZCBjb21wbGV0aW9uIHByb2Nlc3NpbmcKICAqCkBAIC01MDMs MTI5ICs3MTcsOTggQEAKIHZvaWQKIG5ldHZzY194bWl0X2NvbXBsZXRpb24odm9pZCAqY29udGV4 dCkKIHsKLQluZXR2c2NfcGFja2V0ICpwYWNrZXQgPSAobmV0dnNjX3BhY2tldCAqKWNvbnRleHQ7 Ci0Jc3RydWN0IG1idWYgKm1iOwotCXVpbnQ4X3QgKmJ1ZjsKKwluZXR2c2NfcGFja2V0ICpwYWNr ZXQgPSBjb250ZXh0OworCXN0cnVjdCBobl90eGRlc2MgKnR4ZDsKKwlzdHJ1Y3QgaG5fc29mdGMg KnNjOworCisJdHhkID0gKHN0cnVjdCBobl90eGRlc2MgKikodWludHB0cl90KQorCSAgICBwYWNr ZXQtPmNvbXBsLnNlbmQuc2VuZF9jb21wbGV0aW9uX3RpZDsKKworCXNjID0gdHhkLT5zYzsKKwlz Yy0+aG5fdHhlb2YgPSAxOworCWhuX3R4ZGVzY19wdXQoc2MsIHR4ZCk7Cit9CiAKLQltYiA9IChz dHJ1Y3QgbWJ1ZiAqKSh1aW50cHRyX3QpcGFja2V0LT5jb21wbC5zZW5kLnNlbmRfY29tcGxldGlv bl90aWQ7Ci0JYnVmID0gKCh1aW50OF90ICopcGFja2V0KSAtIEhWX05WX1BBQ0tFVF9PRkZTRVRf SU5fQlVGOwordm9pZAorbmV0dnNjX2NoYW5uZWxfcm9sbHVwKHN0cnVjdCBodl9kZXZpY2UgKmRl dmljZV9jdHgpCit7CisJc3RydWN0IGhuX3NvZnRjICpzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2 aWNlX2N0eC0+ZGV2aWNlKTsKKwlzdHJ1Y3QgaWZuZXQgKmlmcDsKIAotCWZyZWUoYnVmLCBNX05F VFZTQyk7CisJaWYgKCFzYy0+aG5fdHhlb2YpCisJCXJldHVybjsKIAotCWlmIChtYiAhPSBOVUxM KSB7Ci0JCW1fZnJlZW0obWIpOwotCX0KKwlzYy0+aG5fdHhlb2YgPSAwOworCWlmcCA9IHNjLT5o bl9pZnA7CisJTlZfTE9DSyhzYyk7CisJaWZwLT5pZl9kcnZfZmxhZ3MgJj0gfklGRl9EUlZfT0FD VElWRTsKKwlobl9zdGFydF9sb2NrZWQoaWZwKTsKKwlOVl9VTkxPQ0soc2MpOwogfQogCiAvKgog ICogU3RhcnQgYSB0cmFuc21pdCBvZiBvbmUgb3IgbW9yZSBwYWNrZXRzCiAgKi8KLXN0YXRpYyBp bnQKK3N0YXRpYyB2b2lkCiBobl9zdGFydF9sb2NrZWQoc3RydWN0IGlmbmV0ICppZnApCiB7CiAJ aG5fc29mdGNfdCAqc2MgPSBpZnAtPmlmX3NvZnRjOwogCXN0cnVjdCBodl9kZXZpY2UgKmRldmlj ZV9jdHggPSB2bWJ1c19nZXRfZGV2Y3R4KHNjLT5obl9kZXYpOwogCW5ldHZzY19kZXYgKm5ldF9k ZXYgPSBzYy0+bmV0X2RldjsKLQlkZXZpY2VfdCBkZXYgPSBkZXZpY2VfY3R4LT5kZXZpY2U7Ci0J dWludDhfdCAqYnVmOwogCW5ldHZzY19wYWNrZXQgKnBhY2tldDsKIAlzdHJ1Y3QgbWJ1ZiAqbV9o ZWFkLCAqbTsKLQlzdHJ1Y3QgbWJ1ZiAqbWNfaGVhZCA9IE5VTEw7CiAJc3RydWN0IGV0aGVyX3Zs YW5faGVhZGVyICplaDsKIAlybmRpc19tc2cgKnJuZGlzX21lc2c7CiAJcm5kaXNfcGFja2V0ICpy bmRpc19wa3Q7CiAJcm5kaXNfcGVyX3BhY2tldF9pbmZvICpycHBpOwogCW5kaXNfODAyMXFfaW5m byAqcnBwaV92bGFuX2luZm87CiAJcm5kaXNfdGNwX2lwX2NzdW1faW5mbyAqY3N1bV9pbmZvOwog CXJuZGlzX3RjcF90c29faW5mbyAqdHNvX2luZm87CQogCWludCBldGhlcl9sZW47Ci0JaW50IGk7 Ci0JaW50IG51bV9mcmFnczsKLQlpbnQgbGVuOwotCWludCByZXRyaWVzID0gMDsKLQlpbnQgcmV0 ID0gMDsJCiAJdWludDMyX3Qgcm5kaXNfbXNnX3NpemUgPSAwOwogCXVpbnQzMl90IHRyYW5zX3By b3RvX3R5cGU7CiAJdWludDMyX3Qgc2VuZF9idWZfc2VjdGlvbl9pZHggPQogCSAgICBOVlNQXzFf Q0hJTU5FWV9TRU5EX0lOVkFMSURfU0VDVElPTl9JTkRFWDsKIAotCXdoaWxlICghSUZRX0RSVl9J U19FTVBUWSgmc2MtPmhuX2lmcC0+aWZfc25kKSkgewotCQlJRlFfRFJWX0RFUVVFVUUoJnNjLT5o bl9pZnAtPmlmX3NuZCwgbV9oZWFkKTsKLQkJaWYgKG1faGVhZCA9PSBOVUxMKSB7Ci0JCQlicmVh azsKLQkJfQotCi0JCWxlbiA9IDA7Ci0JCW51bV9mcmFncyA9IDA7Ci0KLQkJLyogV2FsayB0aGUg bWJ1ZiBsaXN0IGNvbXB1dGluZyB0b3RhbCBsZW5ndGggYW5kIG51bSBmcmFncyAqLwotCQlmb3Ig KG0gPSBtX2hlYWQ7IG0gIT0gTlVMTDsgbSA9IG0tPm1fbmV4dCkgewotCQkJaWYgKG0tPm1fbGVu ICE9IDApIHsKLQkJCQludW1fZnJhZ3MrKzsKLQkJCQlsZW4gKz0gbS0+bV9sZW47Ci0JCQl9Ci0J CX0KKwlpZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgKElGRl9EUlZfUlVOTklORyB8IElGRl9EUlZf T0FDVElWRSkpICE9CisJICAgIElGRl9EUlZfUlVOTklORykKKwkJcmV0dXJuOwogCi0JCS8qCi0J CSAqIFJlc2VydmUgdGhlIG51bWJlciBvZiBwYWdlcyByZXF1ZXN0ZWQuICBDdXJyZW50bHksCi0J CSAqIG9uZSBwYWdlIGlzIHJlc2VydmVkIGZvciB0aGUgbWVzc2FnZSBpbiB0aGUgUk5ESVMKLQkJ ICogZmlsdGVyIHBhY2tldAotCQkgKi8KLQkJbnVtX2ZyYWdzICs9IEhWX1JGX05VTV9UWF9SRVNF UlZFRF9QQUdFX0JVRlM7CisJd2hpbGUgKCFJRlFfRFJWX0lTX0VNUFRZKCZpZnAtPmlmX3NuZCkp IHsKKwkJYnVzX2RtYV9zZWdtZW50X3Qgc2Vnc1tITl9UWF9EQVRBX1NFR0NOVF9NQVhdOworCQlp bnQgZXJyb3IsIG5zZWdzLCBpLCBzZW5kX2ZhaWxlZCA9IDA7CisJCXN0cnVjdCBobl90eGRlc2Mg KnR4ZDsKIAotCQkvKiBJZiBleGNlZWRzICMgcGFnZV9idWZmZXJzIGluIG5ldHZzY19wYWNrZXQg Ki8KLQkJaWYgKG51bV9mcmFncyA+IE5FVFZTQ19QQUNLRVRfTUFYUEFHRSkgewotCQkJZGV2aWNl X3ByaW50ZihkZXYsICJleGNlZWQgbWF4IHBhZ2UgYnVmZmVycywlZCwlZFxuIiwKLQkJCSAgICBu dW1fZnJhZ3MsIE5FVFZTQ19QQUNLRVRfTUFYUEFHRSk7Ci0JCQltX2ZyZWVtKG1faGVhZCk7Ci0J CQlpZl9pbmNfY291bnRlcihpZnAsIElGQ09VTlRFUl9PRVJST1JTLCAxKTsKLQkJCXJldHVybiAo RUlOVkFMKTsKLQkJfQorCQlJRlFfRFJWX0RFUVVFVUUoJmlmcC0+aWZfc25kLCBtX2hlYWQpOwor CQlpZiAobV9oZWFkID09IE5VTEwpCisJCQlicmVhazsKIAotCQkvKgotCQkgKiBBbGxvY2F0ZSBh IGJ1ZmZlciB3aXRoIHNwYWNlIGZvciBhIG5ldHZzYyBwYWNrZXQgcGx1cyBhCi0JCSAqIG51bWJl ciBvZiByZXNlcnZlZCBhcmVhcy4gIEZpcnN0IGNvbWVzIGEgKGN1cnJlbnRseSAxNgotCQkgKiBi eXRlcywgY3VycmVudGx5IHVudXNlZCkgcmVzZXJ2ZWQgZGF0YSBhcmVhLiAgU2Vjb25kIGlzCi0J CSAqIHRoZSBuZXR2c2NfcGFja2V0LiBUaGlyZCBpcyBhbiBhcmVhIHJlc2VydmVkIGZvciBhbiAK LQkJICogcm5kaXNfZmlsdGVyX3BhY2tldCBzdHJ1Y3QuIEZvdXJ0aCAob3B0aW9uYWwpIGlzIGEg Ci0JCSAqIHJuZGlzX3Blcl9wYWNrZXRfaW5mbyBzdHJ1Y3QuCi0JCSAqIENoYW5nZWQgbWFsbG9j IHRvIE1fTk9XQUlUIHRvIGF2b2lkIHNsZWVwIHVuZGVyIHNwaW4gbG9jay4KLQkJICogTm8gbG9u Z2VyIHJlc2VydmluZyBleHRyYSBzcGFjZSBmb3IgcGFnZSBidWZmZXJzLCBhcyB0aGV5Ci0JCSAq IGFyZSBhbHJlYWR5IHBhcnQgb2YgdGhlIG5ldHZzY19wYWNrZXQuCi0JCSAqLwotCQlidWYgPSBt YWxsb2MoSFZfTlZfUEFDS0VUX09GRlNFVF9JTl9CVUYgKwotCQkJc2l6ZW9mKG5ldHZzY19wYWNr ZXQpICsgCi0JCQlzaXplb2Yocm5kaXNfbXNnKSArCi0JCQlSTkRJU19WTEFOX1BQSV9TSVpFICsK LQkJCVJORElTX1RTT19QUElfU0laRSArCi0JCQlSTkRJU19DU1VNX1BQSV9TSVpFLAotCQkJTV9O RVRWU0MsIE1fWkVSTyB8IE1fTk9XQUlUKTsKLQkJaWYgKGJ1ZiA9PSBOVUxMKSB7Ci0JCQlkZXZp Y2VfcHJpbnRmKGRldiwgImhuOm1hbGxvYyBwYWNrZXQgZmFpbGVkXG4iKTsKLQkJCW1fZnJlZW0o bV9oZWFkKTsKLQkJCWlmX2luY19jb3VudGVyKGlmcCwgSUZDT1VOVEVSX09FUlJPUlMsIDEpOwot CQkJcmV0dXJuIChFTk9NRU0pOworCQl0eGQgPSBobl90eGRlc2NfZ2V0KHNjKTsKKwkJaWYgKHR4 ZCA9PSBOVUxMKSB7CisJCQlzYy0+aG5fbm9fdHhkZXNjcysrOworCQkJSUZfUFJFUEVORCgmaWZw LT5pZl9zbmQsIG1faGVhZCk7CisJCQlpZnAtPmlmX2Rydl9mbGFncyB8PSBJRkZfRFJWX09BQ1RJ VkU7CisJCQlicmVhazsKIAkJfQogCi0JCXBhY2tldCA9IChuZXR2c2NfcGFja2V0ICopKGJ1ZiAr IEhWX05WX1BBQ0tFVF9PRkZTRVRfSU5fQlVGKTsKLQkJKih2bV9vZmZzZXRfdCAqKWJ1ZiA9IEhW X05WX1NDX1BUUl9PRkZTRVRfSU5fQlVGOworCQlwYWNrZXQgPSAmdHhkLT5uZXR2c2NfcGt0Owor CQkvKiBYWFggbm90IG5lY2Vzc2FyeSAqLworCQltZW1zZXQocGFja2V0LCAwLCBzaXplb2YoKnBh Y2tldCkpOwogCiAJCXBhY2tldC0+aXNfZGF0YV9wa3QgPSBUUlVFOwogCi0JCS8qIFNldCB1cCB0 aGUgcm5kaXMgaGVhZGVyICovCi0JCXBhY2tldC0+cGFnZV9idWZfY291bnQgPSBudW1fZnJhZ3M7 Ci0KIAkJLyogSW5pdGlhbGl6ZSBpdCBmcm9tIHRoZSBtYnVmICovCi0JCXBhY2tldC0+dG90X2Rh dGFfYnVmX2xlbiA9IGxlbjsKKwkJcGFja2V0LT50b3RfZGF0YV9idWZfbGVuID0gbV9oZWFkLT5t X3BrdGhkci5sZW47CiAKIAkJLyoKIAkJICogZXh0ZW5zaW9uIHBvaW50cyB0byB0aGUgYXJlYSBy ZXNlcnZlZCBmb3IgdGhlCiAJCSAqIHJuZGlzX2ZpbHRlcl9wYWNrZXQsIHdoaWNoIGlzIHBsYWNl ZCBqdXN0IGFmdGVyCiAJCSAqIHRoZSBuZXR2c2NfcGFja2V0IChhbmQgcnBwaSBzdHJ1Y3QsIGlm IHByZXNlbnQ7CiAJCSAqIGxlbmd0aCBpcyB1cGRhdGVkIGxhdGVyKS4KIAkJICovCi0JCXBhY2tl dC0+cm5kaXNfbWVzZyA9IHBhY2tldCArIDE7Ci0JCXJuZGlzX21lc2cgPSAocm5kaXNfbXNnICop cGFja2V0LT5ybmRpc19tZXNnOworCQlybmRpc19tZXNnID0gdHhkLT5ybmRpc19tc2c7CisJCS8q IFhYWCBub3QgbmVjZXNzYXJ5ICovCisJCW1lbXNldChybmRpc19tZXNnLCAwLCBITl9STkRJU19N U0dfTEVOKTsKIAkJcm5kaXNfbWVzZy0+bmRpc19tc2dfdHlwZSA9IFJFTU9URV9ORElTX1BBQ0tF VF9NU0c7CiAKIAkJcm5kaXNfcGt0ID0gJnJuZGlzX21lc2ctPm1zZy5wYWNrZXQ7CkBAIC02NDQs OCArODI3LDYgQEAKIAkJCSAqIHNldCB1cCBzb21lIGFkZGl0aW9uYWwgZmllbGRzIHNvIHRoZSBI eXBlci1WIGluZnJhc3RydWN0dXJlIHdpbGwgc3R1ZmYgdGhlIFZMQU4gdGFnCiAJCQkgKiBpbnRv IHRoZSBmcmFtZS4KIAkJCSAqLwotCQkJcGFja2V0LT52bGFuX3RjaSA9IG1faGVhZC0+bV9wa3Ro ZHIuZXRoZXJfdnRhZzsKLQogCQkJcm5kaXNfbXNnX3NpemUgKz0gUk5ESVNfVkxBTl9QUElfU0la RTsKIAogCQkJcnBwaSA9IGh2X3NldF9ycHBpX2RhdGEocm5kaXNfbWVzZywgUk5ESVNfVkxBTl9Q UElfU0laRSwKQEAgLTY1Niw3ICs4MzcsNyBAQAogCQkJICAgIHJwcGktPnBlcl9wYWNrZXRfaW5m b19vZmZzZXQpOwogCQkJLyogRnJlZUJTRCBkb2VzIG5vdCBzdXBwb3J0IENGSSBvciBwcmlvcml0 eSAqLwogCQkJcnBwaV92bGFuX2luZm8tPnUxLnMxLnZsYW5faWQgPQotCQkJICAgIHBhY2tldC0+ dmxhbl90Y2kgJiAweGZmZjsKKwkJCSAgICBtX2hlYWQtPm1fcGt0aGRyLmV0aGVyX3Z0YWcgJiAw eGZmZjsKIAkJfQogCiAJCS8qIE9ubHkgY2hlY2sgdGhlIGZsYWdzIGZvciBvdXRib3VuZCBhbmQg aWdub3JlIHRoZSBvbmVzIGZvciBpbmJvdW5kICovCkBAIC03NTgsNyArOTM5LDcgQEAKIAkJcGFj a2V0LT50b3RfZGF0YV9idWZfbGVuID0gcm5kaXNfbWVzZy0+bXNnX2xlbjsKIAogCQkvKiBzZW5k IHBhY2tldCB3aXRoIHNlbmQgYnVmZmVyICovCi0JCWlmIChwYWNrZXQtPnRvdF9kYXRhX2J1Zl9s ZW4gPCBuZXRfZGV2LT5zZW5kX3NlY3Rpb25fc2l6ZSkgeworCQlpZiAocGFja2V0LT50b3RfZGF0 YV9idWZfbGVuIDwgc2MtPmhuX3R4X2NoaW1uZXlfc2l6ZSkgewogCQkJc2VuZF9idWZfc2VjdGlv bl9pZHggPQogCQkJICAgIGh2X252X2dldF9uZXh0X3NlbmRfc2VjdGlvbihuZXRfZGV2KTsKIAkJ CWlmIChzZW5kX2J1Zl9zZWN0aW9uX2lkeCAhPQpAQCAtNzgzLDk3ICs5NjQsMTE1IEBACiAJCQkJ cGFja2V0LT5zZW5kX2J1Zl9zZWN0aW9uX3NpemUgPQogCQkJCSAgICBwYWNrZXQtPnRvdF9kYXRh X2J1Zl9sZW47CiAJCQkJcGFja2V0LT5wYWdlX2J1Zl9jb3VudCA9IDA7CisJCQkJc2MtPmhuX3R4 X2NoaW1uZXkrKzsKIAkJCQlnb3RvIGRvX3NlbmQ7CiAJCQl9CiAJCX0KIAorCQllcnJvciA9IGhu X3R4ZGVzY19kbWFtYXBfbG9hZChzYywgdHhkLCAmbV9oZWFkLCBzZWdzLCAmbnNlZ3MpOworCQlp ZiAoZXJyb3IpIHsKKwkJCWludCBmcmVlZDsKKworCQkJLyoKKwkJCSAqIFRoaXMgbWJ1ZiBpcyBu b3QgbGlua2VkIHcvIHRoZSB0eGQgeWV0LCBzbyBmcmVlCisJCQkgKiBpdCBub3cuCisJCQkgKi8K KwkJCW1fZnJlZW0obV9oZWFkKTsKKwkJCWZyZWVkID0gaG5fdHhkZXNjX3B1dChzYywgdHhkKTsK KwkJCUtBU1NFUlQoZnJlZWQgIT0gMCwKKwkJCSAgICAoImZhaWwgdG8gZnJlZSB0eGQgdXBvbiB0 eGRtYSBlcnJvciIpKTsKKworCQkJc2MtPmhuX3R4ZG1hX2ZhaWxlZCsrOworCQkJaWZfaW5jX2Nv dW50ZXIoaWZwLCBJRkNPVU5URVJfT0VSUk9SUywgMSk7CisJCQljb250aW51ZTsKKwkJfQorCisJ CXBhY2tldC0+cGFnZV9idWZfY291bnQgPSBuc2VncyArCisJCSAgICBIVl9SRl9OVU1fVFhfUkVT RVJWRURfUEFHRV9CVUZTOworCiAJCS8qIHNlbmQgcGFja2V0IHdpdGggcGFnZSBidWZmZXIgKi8K LQkJcGFja2V0LT5wYWdlX2J1ZmZlcnNbMF0ucGZuID0KLQkJICAgIGF0b3AoaHZfZ2V0X3BoeXNf YWRkcihybmRpc19tZXNnKSk7CisJCXBhY2tldC0+cGFnZV9idWZmZXJzWzBdLnBmbiA9IGF0b3Ao dHhkLT5ybmRpc19tc2dfcGFkZHIpOwogCQlwYWNrZXQtPnBhZ2VfYnVmZmVyc1swXS5vZmZzZXQg PQotCQkgICAgKHVuc2lnbmVkIGxvbmcpcm5kaXNfbWVzZyAmIFBBR0VfTUFTSzsKKwkJICAgIHR4 ZC0+cm5kaXNfbXNnX3BhZGRyICYgUEFHRV9NQVNLOwogCQlwYWNrZXQtPnBhZ2VfYnVmZmVyc1sw XS5sZW5ndGggPSBybmRpc19tc2dfc2l6ZTsKIAogCQkvKgogCQkgKiBGaWxsIHRoZSBwYWdlIGJ1 ZmZlcnMgd2l0aCBtYnVmIGluZm8gc3RhcnRpbmcgYXQgaW5kZXgKIAkJICogSFZfUkZfTlVNX1RY X1JFU0VSVkVEX1BBR0VfQlVGUy4KIAkJICovCi0JCWkgPSBIVl9SRl9OVU1fVFhfUkVTRVJWRURf UEFHRV9CVUZTOwotCQlmb3IgKG0gPSBtX2hlYWQ7IG0gIT0gTlVMTDsgbSA9IG0tPm1fbmV4dCkg ewotCQkJaWYgKG0tPm1fbGVuKSB7Ci0JCQkJdm1fb2Zmc2V0X3QgcGFkZHIgPQotCQkJCSAgICB2 dG9waHlzKG10b2QobSwgdm1fb2Zmc2V0X3QpKTsKLQkJCQlwYWNrZXQtPnBhZ2VfYnVmZmVyc1tp XS5wZm4gPQotCQkJCSAgICBwYWRkciA+PiBQQUdFX1NISUZUOwotCQkJCXBhY2tldC0+cGFnZV9i dWZmZXJzW2ldLm9mZnNldCA9Ci0JCQkJICAgIHBhZGRyICYgKFBBR0VfU0laRSAtIDEpOwotCQkJ CXBhY2tldC0+cGFnZV9idWZmZXJzW2ldLmxlbmd0aCA9IG0tPm1fbGVuOwotCQkJCWkrKzsKLQkJ CX0KKwkJZm9yIChpID0gMDsgaSA8IG5zZWdzOyArK2kpIHsKKwkJCWh2X3ZtYnVzX3BhZ2VfYnVm ZmVyICpwYiA9ICZwYWNrZXQtPnBhZ2VfYnVmZmVyc1sKKwkJCSAgICBpICsgSFZfUkZfTlVNX1RY X1JFU0VSVkVEX1BBR0VfQlVGU107CisKKwkJCXBiLT5wZm4gPSBhdG9wKHNlZ3NbaV0uZHNfYWRk cik7CisJCQlwYi0+b2Zmc2V0ID0gc2Vnc1tpXS5kc19hZGRyICYgUEFHRV9NQVNLOworCQkJcGIt Pmxlbmd0aCA9IHNlZ3NbaV0uZHNfbGVuOwogCQl9CiAKIAkJcGFja2V0LT5zZW5kX2J1Zl9zZWN0 aW9uX2lkeCA9IAogCQkgICAgTlZTUF8xX0NISU1ORVlfU0VORF9JTlZBTElEX1NFQ1RJT05fSU5E RVg7CiAJCXBhY2tldC0+c2VuZF9idWZfc2VjdGlvbl9zaXplID0gMDsKIAogZG9fc2VuZDoKKwkJ dHhkLT5tID0gbV9oZWFkOwogCi0JCS8qCi0JCSAqIElmIGJwZiwgY29weSB0aGUgbWJ1ZiBjaGFp bi4gIFRoaXMgaXMgbGVzcyBleHBlbnNpdmUgdGhhbgotCQkgKiBpdCBhcHBlYXJzOyB0aGUgbWJ1 ZiBjbHVzdGVycyBhcmUgbm90IGNvcGllZCwgb25seSB0aGVpcgotCQkgKiByZWZlcmVuY2UgY291 bnRzIGFyZSBpbmNyZW1lbnRlZC4KLQkJICogTmVlZGVkIHRvIGF2b2lkIGEgcmFjZSBjb25kaXRp b24gd2hlcmUgdGhlIGNvbXBsZXRpb24KLQkJICogY2FsbGJhY2sgaXMgaW52b2tlZCwgZnJlZWlu ZyB0aGUgbWJ1ZiBjaGFpbiwgYmVmb3JlIHRoZQotCQkgKiBicGZfbXRhcCBjb2RlIGhhcyBhIGNo YW5jZSB0byBydW4uCi0JCSAqLwotCQlpZiAoaWZwLT5pZl9icGYpIHsKLQkJCW1jX2hlYWQgPSBt X2NvcHlwYWNrZXQobV9oZWFkLCBNX05PV0FJVCk7Ci0JCX0KLXJldHJ5X3NlbmQ6CiAJCS8qIFNl dCB0aGUgY29tcGxldGlvbiByb3V0aW5lICovCiAJCXBhY2tldC0+Y29tcGwuc2VuZC5vbl9zZW5k X2NvbXBsZXRpb24gPSBuZXR2c2NfeG1pdF9jb21wbGV0aW9uOwogCQlwYWNrZXQtPmNvbXBsLnNl bmQuc2VuZF9jb21wbGV0aW9uX2NvbnRleHQgPSBwYWNrZXQ7Ci0JCXBhY2tldC0+Y29tcGwuc2Vu ZC5zZW5kX2NvbXBsZXRpb25fdGlkID0gKHVpbnQ2NF90KSh1aW50cHRyX3QpbV9oZWFkOworCQlw YWNrZXQtPmNvbXBsLnNlbmQuc2VuZF9jb21wbGV0aW9uX3RpZCA9CisJCSAgICAodWludDY0X3Qp KHVpbnRwdHJfdCl0eGQ7CiAKLQkJLyogUmVtb3ZlZCBjcml0aWNhbF9lbnRlcigpLCBkb2VzIG5v dCBhcHBlYXIgbmVjZXNzYXJ5ICovCi0JCXJldCA9IGh2X252X29uX3NlbmQoZGV2aWNlX2N0eCwg cGFja2V0KTsKLQkJaWYgKHJldCA9PSAwKSB7CithZ2FpbjoKKwkJLyoKKwkJICogTWFrZSBzdXJl IHRoYXQgdHhkIGlzIG5vdCBmcmVlZCBiZWZvcmUgRVRIRVJfQlBGX01UQVAuCisJCSAqLworCQlo bl90eGRlc2NfaG9sZCh0eGQpOworCQllcnJvciA9IGh2X252X29uX3NlbmQoZGV2aWNlX2N0eCwg cGFja2V0KTsKKwkJaWYgKCFlcnJvcikgeworCQkJRVRIRVJfQlBGX01UQVAoaWZwLCBtX2hlYWQp OwogCQkJaWZfaW5jX2NvdW50ZXIoaWZwLCBJRkNPVU5URVJfT1BBQ0tFVFMsIDEpOwotCQkJLyog aWYgYnBmICYmIG1jX2hlYWQsIGNhbGwgYnBmX210YXAgY29kZSAqLwotCQkJaWYgKG1jX2hlYWQp IHsKLQkJCQlFVEhFUl9CUEZfTVRBUChpZnAsIG1jX2hlYWQpOwotCQkJfQotCQl9IGVsc2Ugewot CQkJcmV0cmllcysrOwotCQkJaWYgKHJldHJpZXMgPCA0KSB7Ci0JCQkJZ290byByZXRyeV9zZW5k OwotCQkJfQorCQl9CisJCWhuX3R4ZGVzY19wdXQoc2MsIHR4ZCk7CiAKLQkJCUlGX1BSRVBFTkQo JmlmcC0+aWZfc25kLCBtX2hlYWQpOwotCQkJaWZwLT5pZl9kcnZfZmxhZ3MgfD0gSUZGX0RSVl9P QUNUSVZFOworCQlpZiAoX19wcmVkaWN0X2ZhbHNlKGVycm9yKSkgeworCQkJaW50IGZyZWVkOwog CiAJCQkvKgotCQkJICogTnVsbCB0aGUgbWJ1ZiBwb2ludGVyIHNvIHRoZSBjb21wbGV0aW9uIGZ1 bmN0aW9uCi0JCQkgKiBkb2VzIG5vdCBmcmVlIHRoZSBtYnVmIGNoYWluLiAgV2UganVzdCBwdXNo ZWQgdGhlCi0JCQkgKiBtYnVmIGNoYWluIGJhY2sgb24gdGhlIGlmX3NuZCBxdWV1ZS4KKwkJCSAq IFRoaXMgc2hvdWxkICJyZWFsbHkgcmFyZWx5IiBoYXBwZW4uCisJCQkgKgorCQkJICogWFhYIFRv byBtYW55IFJYIHRvIGJlIGFja2VkIG9yIHRvbyBtYW55IHNpZGViYW5kCisJCQkgKiBjb21tYW5k cyB0byBydW4/ICBBc2sgbmV0dnNjX2NoYW5uZWxfcm9sbHVwKCkKKwkJCSAqIHRvIGtpY2sgc3Rh cnQgbGF0ZXIuCiAJCQkgKi8KLQkJCXBhY2tldC0+Y29tcGwuc2VuZC5zZW5kX2NvbXBsZXRpb25f dGlkID0gMDsKKwkJCXNjLT5obl90eGVvZiA9IDE7CisJCQlpZiAoIXNlbmRfZmFpbGVkKSB7CisJ CQkJc2MtPmhuX3NlbmRfZmFpbGVkKys7CisJCQkJc2VuZF9mYWlsZWQgPSAxOworCQkJCS8qCisJ CQkJICogVHJ5IHNlbmRpbmcgYWdhaW4gYWZ0ZXIgc2V0IGhuX3R4ZW9mOworCQkJCSAqIGluIGNh c2UgdGhhdCB3ZSBtaXNzZWQgdGhlIGxhc3QKKwkJCQkgKiBuZXR2c2NfY2hhbm5lbF9yb2xsdXAo KS4KKwkJCQkgKi8KKwkJCQlnb3RvIGFnYWluOworCQkJfQorCQkJaWZfcHJpbnRmKGlmcCwgInNl bmQgZmFpbGVkXG4iKTsKIAogCQkJLyoKLQkJCSAqIFJlbGVhc2UgdGhlIHJlc291cmNlcyBzaW5j ZSB3ZSB3aWxsIG5vdCBnZXQgYW55Ci0JCQkgKiBzZW5kIGNvbXBsZXRpb24KKwkJCSAqIFRoaXMg bWJ1ZiB3aWxsIGJlIHByZXBlbmRlZCwgZG9uJ3QgZnJlZSBpdAorCQkJICogaW4gaG5fdHhkZXNj X3B1dCgpOyBvbmx5IHVubG9hZCBpdCBmcm9tIHRoZQorCQkJICogRE1BIG1hcCBpbiBobl90eGRl c2NfcHV0KCksIGlmIGl0IHdhcyBsb2FkZWQuCiAJCQkgKi8KLQkJCW5ldHZzY194bWl0X2NvbXBs ZXRpb24ocGFja2V0KTsKLQkJCWlmX2luY19jb3VudGVyKGlmcCwgSUZDT1VOVEVSX09FUlJPUlMs IDEpOwotCQl9CisJCQl0eGQtPm0gPSBOVUxMOworCQkJZnJlZWQgPSBobl90eGRlc2NfcHV0KHNj LCB0eGQpOworCQkJS0FTU0VSVChmcmVlZCAhPSAwLAorCQkJICAgICgiZmFpbCB0byBmcmVlIHR4 ZCB1cG9uIHNlbmQgZXJyb3IiKSk7CiAKLQkJLyogaWYgYnBmICYmIG1jX2hlYWQsIGZyZWUgdGhl IG1idWYgY2hhaW4gY29weSAqLwotCQlpZiAobWNfaGVhZCkgewotCQkJbV9mcmVlbShtY19oZWFk KTsKKwkJCXNjLT5obl9zZW5kX2ZhaWxlZCsrOworCQkJSUZfUFJFUEVORCgmaWZwLT5pZl9zbmQs IG1faGVhZCk7CisJCQlpZnAtPmlmX2Rydl9mbGFncyB8PSBJRkZfRFJWX09BQ1RJVkU7CisJCQli cmVhazsKIAkJfQogCX0KLQotCXJldHVybiAocmV0KTsKIH0KIAogLyoKQEAgLTEyMjAsNiArMTQx OSw5IEBACiAJCQlicmVhazsKIAkJfQogCisJCXNjLT5obl90eF9jaGltbmV5X21heCA9IHNjLT5u ZXRfZGV2LT5zZW5kX3NlY3Rpb25fc2l6ZTsKKwkJaWYgKHNjLT5obl90eF9jaGltbmV5X3NpemUg PiBzYy0+aG5fdHhfY2hpbW5leV9tYXgpCisJCQlzYy0+aG5fdHhfY2hpbW5leV9zaXplID0gc2Mt PmhuX3R4X2NoaW1uZXlfbWF4OwogCQlobl9pZmluaXRfbG9ja2VkKHNjKTsKIAogCQlOVl9MT0NL KHNjKTsKQEAgLTE0NzcsNiArMTY3OSwyNSBAQAogI2VuZGlmCS8qIEhOX0xST19ISVdBVCAqLwog CiBzdGF0aWMgaW50Citobl90eF9jaGltbmV5X3NpemVfc3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FS R1MpCit7CisJc3RydWN0IGhuX3NvZnRjICpzYyA9IGFyZzE7CisJaW50IGNoaW1uZXlfc2l6ZSwg ZXJyb3I7CisKKwljaGltbmV5X3NpemUgPSBzYy0+aG5fdHhfY2hpbW5leV9zaXplOworCWVycm9y ID0gc3lzY3RsX2hhbmRsZV9pbnQob2lkcCwgJmNoaW1uZXlfc2l6ZSwgMCwgcmVxKTsKKwlpZiAo ZXJyb3IgfHwgcmVxLT5uZXdwdHIgPT0gTlVMTCkKKwkJcmV0dXJuIGVycm9yOworCisJaWYgKGNo aW1uZXlfc2l6ZSA+IHNjLT5obl90eF9jaGltbmV5X21heCB8fCBjaGltbmV5X3NpemUgPD0gMCkK KwkJcmV0dXJuIEVJTlZBTDsKKworCWlmIChzYy0+aG5fdHhfY2hpbW5leV9zaXplICE9IGNoaW1u ZXlfc2l6ZSkKKwkJc2MtPmhuX3R4X2NoaW1uZXlfc2l6ZSA9IGNoaW1uZXlfc2l6ZTsKKwlyZXR1 cm4gMDsKK30KKworc3RhdGljIGludAogaG5fY2hlY2tfaXBsZW4oY29uc3Qgc3RydWN0IG1idWYg Km0sIGludCBob2ZmKQogewogCWNvbnN0IHN0cnVjdCBpcCAqaXA7CkBAIC0xNTUxLDYgKzE3NzIs MTUwIEBACiAJcmV0dXJuIGlwLT5pcF9wOwogfQogCitzdGF0aWMgdm9pZAoraG5fZG1hX21hcF9w YWRkcih2b2lkICphcmcsIGJ1c19kbWFfc2VnbWVudF90ICpzZWdzLCBpbnQgbnNlZywgaW50IGVy cm9yKQoreworCWJ1c19hZGRyX3QgKnBhZGRyID0gYXJnOworCisJaWYgKGVycm9yKQorCQlyZXR1 cm47CisKKwlLQVNTRVJUKG5zZWcgPT0gMSwgKCJ0b28gbWFueSBzZWdtZW50cyAlZCEiLCBuc2Vn KSk7CisJKnBhZGRyID0gc2Vncy0+ZHNfYWRkcjsKK30KKworc3RhdGljIGludAoraG5fY3JlYXRl X3R4X3Jpbmcoc3RydWN0IGhuX3NvZnRjICpzYykKK3sKKwlidXNfZG1hX3RhZ190IHBhcmVudF9k dGFnOworCWludCBlcnJvciwgaTsKKworCXNjLT5obl90eGRlc2NfY250ID0gSE5fVFhfREVTQ19D TlQ7CisJc2MtPmhuX3R4ZGVzYyA9IG1hbGxvYyhzaXplb2Yoc3RydWN0IGhuX3R4ZGVzYykgKiBz Yy0+aG5fdHhkZXNjX2NudCwKKwkgICAgTV9ORVRWU0MsIE1fV0FJVE9LIHwgTV9aRVJPKTsKKwlT TElTVF9JTklUKCZzYy0+aG5fdHhsaXN0KTsKKwltdHhfaW5pdCgmc2MtPmhuX3R4bGlzdF9zcGlu LCAiaG4gdHhsaXN0IiwgTlVMTCwgTVRYX1NQSU4pOworCisJcGFyZW50X2R0YWcgPSBidXNfZ2V0 X2RtYV90YWcoc2MtPmhuX2Rldik7CisKKwkvKiBETUEgdGFnIGZvciBSTkRJUyBtZXNzYWdlcy4g Ki8KKwllcnJvciA9IGJ1c19kbWFfdGFnX2NyZWF0ZShwYXJlbnRfZHRhZywgLyogcGFyZW50ICov CisJICAgIEhOX1JORElTX01TR19BTElHTiwJCS8qIGFsaWdubWVudCAqLworCSAgICBITl9STkRJ U19NU0dfQk9VTkRBUlksCS8qIGJvdW5kYXJ5ICovCisJICAgIEJVU19TUEFDRV9NQVhBRERSLAkJ LyogbG93YWRkciAqLworCSAgICBCVVNfU1BBQ0VfTUFYQUREUiwJCS8qIGhpZ2hhZGRyICovCisJ ICAgIE5VTEwsIE5VTEwsCQkJLyogZmlsdGVyLCBmaWx0ZXJhcmcgKi8KKwkgICAgSE5fUk5ESVNf TVNHX0xFTiwJCS8qIG1heHNpemUgKi8KKwkgICAgMSwJCQkJLyogbnNlZ21lbnRzICovCisJICAg IEhOX1JORElTX01TR19MRU4sCQkvKiBtYXhzZWdzaXplICovCisJICAgIDAsCQkJCS8qIGZsYWdz ICovCisJICAgIE5VTEwsCQkJLyogbG9ja2Z1bmMgKi8KKwkgICAgTlVMTCwJCQkvKiBsb2NrZnVu Y2FyZyAqLworCSAgICAmc2MtPmhuX3R4X3JuZGlzX2R0YWcpOworCWlmIChlcnJvcikgeworCQlk ZXZpY2VfcHJpbnRmKHNjLT5obl9kZXYsICJmYWlsZWQgdG8gY3JlYXRlIHJuZGlzIGRtYXRhZ1xu Iik7CisJCXJldHVybiBlcnJvcjsKKwl9CisKKwkvKiBETUEgdGFnIGZvciBkYXRhLiAqLworCWVy cm9yID0gYnVzX2RtYV90YWdfY3JlYXRlKHBhcmVudF9kdGFnLCAvKiBwYXJlbnQgKi8KKwkgICAg MSwJCQkJLyogYWxpZ25tZW50ICovCisJICAgIEhOX1RYX0RBVEFfQk9VTkRBUlksCS8qIGJvdW5k YXJ5ICovCisJICAgIEJVU19TUEFDRV9NQVhBRERSLAkJLyogbG93YWRkciAqLworCSAgICBCVVNf U1BBQ0VfTUFYQUREUiwJCS8qIGhpZ2hhZGRyICovCisJICAgIE5VTEwsIE5VTEwsCQkJLyogZmls dGVyLCBmaWx0ZXJhcmcgKi8KKwkgICAgSE5fVFhfREFUQV9NQVhTSVpFLAkJLyogbWF4c2l6ZSAq LworCSAgICBITl9UWF9EQVRBX1NFR0NOVF9NQVgsCS8qIG5zZWdtZW50cyAqLworCSAgICBITl9U WF9EQVRBX1NFR1NJWkUsCQkvKiBtYXhzZWdzaXplICovCisJICAgIDAsCQkJCS8qIGZsYWdzICov CisJICAgIE5VTEwsCQkJLyogbG9ja2Z1bmMgKi8KKwkgICAgTlVMTCwJCQkvKiBsb2NrZnVuY2Fy ZyAqLworCSAgICAmc2MtPmhuX3R4X2RhdGFfZHRhZyk7CisJaWYgKGVycm9yKSB7CisJCWRldmlj ZV9wcmludGYoc2MtPmhuX2RldiwgImZhaWxlZCB0byBjcmVhdGUgZGF0YSBkbWF0YWdcbiIpOwor CQlyZXR1cm4gZXJyb3I7CisJfQorCisJZm9yIChpID0gMDsgaSA8IHNjLT5obl90eGRlc2NfY250 OyArK2kpIHsKKwkJc3RydWN0IGhuX3R4ZGVzYyAqdHhkID0gJnNjLT5obl90eGRlc2NbaV07CisK KwkJdHhkLT5zYyA9IHNjOworCisJCS8qCisJCSAqIEFsbG9jYXRlIGFuZCBsb2FkIFJORElTIG1l c3NhZ2VzLgorCQkgKi8KKyAgICAgICAgCWVycm9yID0gYnVzX2RtYW1lbV9hbGxvYyhzYy0+aG5f dHhfcm5kaXNfZHRhZywKKwkJICAgICh2b2lkICoqKSZ0eGQtPnJuZGlzX21zZywKKwkJICAgIEJV U19ETUFfV0FJVE9LIHwgQlVTX0RNQV9DT0hFUkVOVCwKKwkJICAgICZ0eGQtPnJuZGlzX21zZ19k bWFwKTsKKwkJaWYgKGVycm9yKSB7CisJCQlkZXZpY2VfcHJpbnRmKHNjLT5obl9kZXYsCisJCQkg ICAgImZhaWxlZCB0byBhbGxvY2F0ZSBybmRpc19tc2csICVkXG4iLCBpKTsKKwkJCXJldHVybiBl cnJvcjsKKwkJfQorCisJCWVycm9yID0gYnVzX2RtYW1hcF9sb2FkKHNjLT5obl90eF9ybmRpc19k dGFnLAorCQkgICAgdHhkLT5ybmRpc19tc2dfZG1hcCwKKwkJICAgIHR4ZC0+cm5kaXNfbXNnLCBI Tl9STkRJU19NU0dfTEVOLAorCQkgICAgaG5fZG1hX21hcF9wYWRkciwgJnR4ZC0+cm5kaXNfbXNn X3BhZGRyLAorCQkgICAgQlVTX0RNQV9OT1dBSVQpOworCQlpZiAoZXJyb3IpIHsKKwkJCWRldmlj ZV9wcmludGYoc2MtPmhuX2RldiwKKwkJCSAgICAiZmFpbGVkIHRvIGxvYWQgcm5kaXNfbXNnLCAl ZFxuIiwgaSk7CisJCQlidXNfZG1hbWVtX2ZyZWUoc2MtPmhuX3R4X3JuZGlzX2R0YWcsCisJCQkg ICAgdHhkLT5ybmRpc19tc2csIHR4ZC0+cm5kaXNfbXNnX2RtYXApOworCQkJcmV0dXJuIGVycm9y OworCQl9CisKKwkJLyogRE1BIG1hcCBmb3IgVFggZGF0YS4gKi8KKwkJZXJyb3IgPSBidXNfZG1h bWFwX2NyZWF0ZShzYy0+aG5fdHhfZGF0YV9kdGFnLCAwLAorCQkgICAgJnR4ZC0+ZGF0YV9kbWFw KTsKKwkJaWYgKGVycm9yKSB7CisJCQlkZXZpY2VfcHJpbnRmKHNjLT5obl9kZXYsCisJCQkgICAg ImZhaWxlZCB0byBhbGxvY2F0ZSB0eCBkYXRhIGRtYW1hcFxuIik7CisJCQlidXNfZG1hbWFwX3Vu bG9hZChzYy0+aG5fdHhfcm5kaXNfZHRhZywKKwkJCSAgICB0eGQtPnJuZGlzX21zZ19kbWFwKTsK KwkJCWJ1c19kbWFtZW1fZnJlZShzYy0+aG5fdHhfcm5kaXNfZHRhZywKKwkJCSAgICB0eGQtPnJu ZGlzX21zZywgdHhkLT5ybmRpc19tc2dfZG1hcCk7CisJCQlyZXR1cm4gZXJyb3I7CisJCX0KKwor CQkvKiBBbGwgc2V0LCBwdXQgaXQgdG8gbGlzdCAqLworCQl0eGQtPmZsYWdzIHw9IEhOX1RYRF9G TEFHX09OTElTVDsKKwkJU0xJU1RfSU5TRVJUX0hFQUQoJnNjLT5obl90eGxpc3QsIHR4ZCwgbGlu ayk7CisJfQorCXNjLT5obl90eGRlc2NfYXZhaWwgPSBzYy0+aG5fdHhkZXNjX2NudDsKKworCXJl dHVybiAwOworfQorCitzdGF0aWMgdm9pZAoraG5fZGVzdHJveV90eF9yaW5nKHN0cnVjdCBobl9z b2Z0YyAqc2MpCit7CisJc3RydWN0IGhuX3R4ZGVzYyAqdHhkOworCisJd2hpbGUgKCh0eGQgPSBT TElTVF9GSVJTVCgmc2MtPmhuX3R4bGlzdCkpICE9IE5VTEwpIHsKKwkJS0FTU0VSVCh0eGQtPm0g PT0gTlVMTCwgKCJzdGlsbCBoYXMgbWJ1ZiBpbnN0YWxsZWQiKSk7CisJCUtBU1NFUlQoKHR4ZC0+ ZmxhZ3MgJiBITl9UWERfRkxBR19ETUFNQVApID09IDAsCisJCSAgICAoInN0aWxsIGRtYSBtYXBw ZWQiKSk7CisJCVNMSVNUX1JFTU9WRV9IRUFEKCZzYy0+aG5fdHhsaXN0LCBsaW5rKTsKKworCQli dXNfZG1hbWFwX3VubG9hZChzYy0+aG5fdHhfcm5kaXNfZHRhZywKKwkJICAgIHR4ZC0+cm5kaXNf bXNnX2RtYXApOworCQlidXNfZG1hbWVtX2ZyZWUoc2MtPmhuX3R4X3JuZGlzX2R0YWcsCisJCSAg ICB0eGQtPnJuZGlzX21zZywgdHhkLT5ybmRpc19tc2dfZG1hcCk7CisKKwkJYnVzX2RtYW1hcF9k ZXN0cm95KHNjLT5obl90eF9kYXRhX2R0YWcsIHR4ZC0+ZGF0YV9kbWFwKTsKKwl9CisKKwlpZiAo c2MtPmhuX3R4X2RhdGFfZHRhZyAhPSBOVUxMKQorCQlidXNfZG1hX3RhZ19kZXN0cm95KHNjLT5o bl90eF9kYXRhX2R0YWcpOworCWlmIChzYy0+aG5fdHhfcm5kaXNfZHRhZyAhPSBOVUxMKQorCQli dXNfZG1hX3RhZ19kZXN0cm95KHNjLT5obl90eF9ybmRpc19kdGFnKTsKKwlmcmVlKHNjLT5obl90 eGRlc2MsIE1fTkVUVlNDKTsKKwltdHhfZGVzdHJveSgmc2MtPmhuX3R4bGlzdF9zcGluKTsKK30K Kwogc3RhdGljIGRldmljZV9tZXRob2RfdCBuZXR2c2NfbWV0aG9kc1tdID0gewogICAgICAgICAv KiBEZXZpY2UgaW50ZXJmYWNlICovCiAgICAgICAgIERFVk1FVEhPRChkZXZpY2VfcHJvYmUsICAg ICAgICAgbmV0dnNjX3Byb2JlKSwKZGlmZiAtLWdpdCBhL2hlYWQvc3lzL2Rldi9oeXBlcnYvbmV0 dnNjL2h2X25ldF92c2MuaCBiL2hlYWQvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X25ldF92c2Mu aAotLS0gYS9oZWFkL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXRfdnNjLmgKKysrIGIvaGVh ZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0X3ZzYy5oCkBAIC0zOCwxMiArMzgsMTYgQEAK ICNpZm5kZWYgX19IVl9ORVRfVlNDX0hfXwogI2RlZmluZSBfX0hWX05FVF9WU0NfSF9fCiAKLSNp bmNsdWRlIDxzeXMvdHlwZXMuaD4KICNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KICNpbmNsdWRlIDxz eXMvbG9jay5oPgogI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KKyNpbmNsdWRlIDxzeXMvcXVldWUu aD4KICNpbmNsdWRlIDxzeXMvc3guaD4KIAorI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CisjaW5j bHVkZSA8c3lzL2J1cy5oPgorI2luY2x1ZGUgPHN5cy9idXNfZG1hLmg+CisKICNpbmNsdWRlIDxu ZXRpbmV0L2luLmg+CiAjaW5jbHVkZSA8bmV0aW5ldC90Y3BfbHJvLmg+CiAKQEAgLTk4NCw2ICs5 ODgsOSBAQAogCWh2X2Jvb2xfdWludDhfdAlsaW5rX3N0YXRlOwogfSBuZXR2c2NfZGV2aWNlX2lu Zm87CiAKK3N0cnVjdCBobl90eGRlc2M7CitTTElTVF9IRUFEKGhuX3R4ZGVzY19saXN0LCBobl90 eGRlc2MpOworCiAvKgogICogRGV2aWNlLXNwZWNpZmljIHNvZnRjIHN0cnVjdHVyZQogICovCkBA IC0xMDAxLDYgKzEwMDgsMTggQEAKIAlzdHJ1Y3QgaHZfZGV2aWNlICAqaG5fZGV2X29iajsKIAlu ZXR2c2NfZGV2ICAJKm5ldF9kZXY7CiAKKwlpbnQJCWhuX3R4ZGVzY19jbnQ7CisJc3RydWN0IGhu X3R4ZGVzYyAqaG5fdHhkZXNjOworCWJ1c19kbWFfdGFnX3QJaG5fdHhfZGF0YV9kdGFnOworCWJ1 c19kbWFfdGFnX3QJaG5fdHhfcm5kaXNfZHRhZzsKKwlpbnQJCWhuX3R4X2NoaW1uZXlfc2l6ZTsK KwlpbnQJCWhuX3R4X2NoaW1uZXlfbWF4OworCisJc3RydWN0IG10eAlobl90eGxpc3Rfc3BpbjsK KwlzdHJ1Y3QgaG5fdHhkZXNjX2xpc3QgaG5fdHhsaXN0OworCWludAkJaG5fdHhkZXNjX2F2YWls OworCWludAkJaG5fdHhlb2Y7CisKIAlzdHJ1Y3QgbHJvX2N0cmwJaG5fbHJvOwogCWludAkJaG5f bHJvX2hpd2F0OwogCkBAIC0xMDEyLDYgKzEwMzEsMTEgQEAKIAl1X2xvbmcJCWhuX2NzdW1fdHJ1 c3RlZDsKIAl1X2xvbmcJCWhuX2xyb190cmllZDsKIAl1X2xvbmcJCWhuX3NtYWxsX3BrdHM7CisJ dV9sb25nCQlobl9ub190eGRlc2NzOworCXVfbG9uZwkJaG5fc2VuZF9mYWlsZWQ7CisJdV9sb25n CQlobl90eGRtYV9mYWlsZWQ7CisJdV9sb25nCQlobl90eF9jb2xsYXBzZWQ7CisJdV9sb25nCQlo bl90eF9jaGltbmV5OwogfSBobl9zb2Z0Y190OwogCiAKZGlmZiAtLWdpdCBhL2hlYWQvc3lzL2Rl di9oeXBlcnYvbmV0dnNjL2h2X25ldF92c2MuYyBiL2hlYWQvc3lzL2Rldi9oeXBlcnYvbmV0dnNj L2h2X25ldF92c2MuYwotLS0gYS9oZWFkL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXRfdnNj LmMKKysrIGIvaGVhZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0X3ZzYy5jCkBAIC0xMDI4 LDQgKzEwMjgsNiBAQAogCiAJaWYgKGJ1ZmZlcmxlbiA+IE5FVFZTQ19QQUNLRVRfU0laRSkKIAkJ ZnJlZShidWZmZXIsIE1fTkVUVlNDKTsKKworCWh2X3JmX2NoYW5uZWxfcm9sbHVwKG5ldF9kZXYp OwogfQoK --b1_d2ebb1e510a55e19fba0ba13c5d96832-- From owner-freebsd-net@freebsd.org Mon Jan 25 05:12:19 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F365A31FA2 for ; Mon, 25 Jan 2016 05:12:19 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id 3A56A1743 for ; Mon, 25 Jan 2016 05:12:19 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id 38C81116BB; Mon, 25 Jan 2016 05:12:19 +0000 (UTC) Date: Mon, 25 Jan 2016 05:12:19 +0000 To: freebsd-net@freebsd.org From: Phabricator Reply-to: D4977+325+02999679bd9ee421@reviews.freebsd.org Subject: [Differential] [Closed] D4977: hyperv/hn: Use m_copydata for chimney sending. Message-ID: <7eac4ee6ca5161c925637e8f180bca42@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D4977: hyperv/hn: Use m_copydata for chimney sending. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: OGYzNjQ1MzA3NTJkZTNiZDY5Y2E2NDE5N2EyIFalrrM= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_7eac4ee6ca5161c925637e8f180bca42" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 05:12:19 -0000 --b1_7eac4ee6ca5161c925637e8f180bca42 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit This revision was automatically updated to reflect the committed changes. Closed by commit rS294701: hyperv/hn: Use m_copydata for chimney sending. (authored by sephe). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D4977?vs=12412&id=12669#toc REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D4977?vs=12412&id=12669 REVISION DETAIL https://reviews.freebsd.org/D4977 AFFECTED FILES head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c CHANGE DETAILS diff --git a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c --- a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c +++ b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c @@ -756,7 +756,6 @@ struct hv_device *device_ctx = vmbus_get_devctx(sc->hn_dev); netvsc_dev *net_dev = sc->net_dev; netvsc_packet *packet; - struct mbuf *m_head, *m; struct ether_vlan_header *eh; rndis_msg *rndis_mesg; rndis_packet *rndis_pkt; @@ -767,8 +766,6 @@ int ether_len; uint32_t rndis_msg_size = 0; uint32_t trans_proto_type; - uint32_t send_buf_section_idx = - NVSP_1_CHIMNEY_SEND_INVALID_SECTION_INDEX; if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != IFF_DRV_RUNNING) @@ -778,6 +775,7 @@ bus_dma_segment_t segs[HN_TX_DATA_SEGCNT_MAX]; int error, nsegs, i, send_failed = 0; struct hn_txdesc *txd; + struct mbuf *m_head; IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); if (m_head == NULL) @@ -940,24 +938,21 @@ /* send packet with send buffer */ if (packet->tot_data_buf_len < sc->hn_tx_chimney_size) { + uint32_t send_buf_section_idx; + send_buf_section_idx = hv_nv_get_next_send_section(net_dev); if (send_buf_section_idx != NVSP_1_CHIMNEY_SEND_INVALID_SECTION_INDEX) { - char *dest = ((char *)net_dev->send_buf + - send_buf_section_idx * - net_dev->send_section_size); + uint8_t *dest = ((uint8_t *)net_dev->send_buf + + (send_buf_section_idx * + net_dev->send_section_size)); memcpy(dest, rndis_mesg, rndis_msg_size); dest += rndis_msg_size; - for (m = m_head; m != NULL; m = m->m_next) { - if (m->m_len) { - memcpy(dest, - (void *)mtod(m, vm_offset_t), - m->m_len); - dest += m->m_len; - } - } + + m_copydata(m_head, 0, m_head->m_pkthdr.len, + dest); packet->send_buf_section_idx = send_buf_section_idx; EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, delphij, adrian, network Cc: freebsd-net-list --b1_7eac4ee6ca5161c925637e8f180bca42 Content-Type: text/x-patch; charset=utf-8; name="D4977.12669.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D4977.12669.patch" ZGlmZiAtLWdpdCBhL2hlYWQvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X25ldHZzY19kcnZfZnJl ZWJzZC5jIGIvaGVhZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0dnNjX2Rydl9mcmVlYnNk LmMKLS0tIGEvaGVhZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0dnNjX2Rydl9mcmVlYnNk LmMKKysrIGIvaGVhZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0dnNjX2Rydl9mcmVlYnNk LmMKQEAgLTc1Niw3ICs3NTYsNiBAQAogCXN0cnVjdCBodl9kZXZpY2UgKmRldmljZV9jdHggPSB2 bWJ1c19nZXRfZGV2Y3R4KHNjLT5obl9kZXYpOwogCW5ldHZzY19kZXYgKm5ldF9kZXYgPSBzYy0+ bmV0X2RldjsKIAluZXR2c2NfcGFja2V0ICpwYWNrZXQ7Ci0Jc3RydWN0IG1idWYgKm1faGVhZCwg Km07CiAJc3RydWN0IGV0aGVyX3ZsYW5faGVhZGVyICplaDsKIAlybmRpc19tc2cgKnJuZGlzX21l c2c7CiAJcm5kaXNfcGFja2V0ICpybmRpc19wa3Q7CkBAIC03NjcsOCArNzY2LDYgQEAKIAlpbnQg ZXRoZXJfbGVuOwogCXVpbnQzMl90IHJuZGlzX21zZ19zaXplID0gMDsKIAl1aW50MzJfdCB0cmFu c19wcm90b190eXBlOwotCXVpbnQzMl90IHNlbmRfYnVmX3NlY3Rpb25faWR4ID0KLQkgICAgTlZT UF8xX0NISU1ORVlfU0VORF9JTlZBTElEX1NFQ1RJT05fSU5ERVg7CiAKIAlpZiAoKGlmcC0+aWZf ZHJ2X2ZsYWdzICYgKElGRl9EUlZfUlVOTklORyB8IElGRl9EUlZfT0FDVElWRSkpICE9CiAJICAg IElGRl9EUlZfUlVOTklORykKQEAgLTc3OCw2ICs3NzUsNyBAQAogCQlidXNfZG1hX3NlZ21lbnRf dCBzZWdzW0hOX1RYX0RBVEFfU0VHQ05UX01BWF07CiAJCWludCBlcnJvciwgbnNlZ3MsIGksIHNl bmRfZmFpbGVkID0gMDsKIAkJc3RydWN0IGhuX3R4ZGVzYyAqdHhkOworCQlzdHJ1Y3QgbWJ1ZiAq bV9oZWFkOwogCiAJCUlGUV9EUlZfREVRVUVVRSgmaWZwLT5pZl9zbmQsIG1faGVhZCk7CiAJCWlm IChtX2hlYWQgPT0gTlVMTCkKQEAgLTk0MCwyNCArOTM4LDIxIEBACiAKIAkJLyogc2VuZCBwYWNr ZXQgd2l0aCBzZW5kIGJ1ZmZlciAqLwogCQlpZiAocGFja2V0LT50b3RfZGF0YV9idWZfbGVuIDwg c2MtPmhuX3R4X2NoaW1uZXlfc2l6ZSkgeworCQkJdWludDMyX3Qgc2VuZF9idWZfc2VjdGlvbl9p ZHg7CisKIAkJCXNlbmRfYnVmX3NlY3Rpb25faWR4ID0KIAkJCSAgICBodl9udl9nZXRfbmV4dF9z ZW5kX3NlY3Rpb24obmV0X2Rldik7CiAJCQlpZiAoc2VuZF9idWZfc2VjdGlvbl9pZHggIT0KIAkJ CSAgICBOVlNQXzFfQ0hJTU5FWV9TRU5EX0lOVkFMSURfU0VDVElPTl9JTkRFWCkgewotCQkJCWNo YXIgKmRlc3QgPSAoKGNoYXIgKiluZXRfZGV2LT5zZW5kX2J1ZiArCi0JCQkJICAgIHNlbmRfYnVm X3NlY3Rpb25faWR4ICoKLQkJCQkgICAgbmV0X2Rldi0+c2VuZF9zZWN0aW9uX3NpemUpOworCQkJ CXVpbnQ4X3QgKmRlc3QgPSAoKHVpbnQ4X3QgKiluZXRfZGV2LT5zZW5kX2J1ZiArCisJCQkJICAg IChzZW5kX2J1Zl9zZWN0aW9uX2lkeCAqCisJCQkJICAgICBuZXRfZGV2LT5zZW5kX3NlY3Rpb25f c2l6ZSkpOwogCiAJCQkJbWVtY3B5KGRlc3QsIHJuZGlzX21lc2csIHJuZGlzX21zZ19zaXplKTsK IAkJCQlkZXN0ICs9IHJuZGlzX21zZ19zaXplOwotCQkJCWZvciAobSA9IG1faGVhZDsgbSAhPSBO VUxMOyBtID0gbS0+bV9uZXh0KSB7Ci0JCQkJCWlmIChtLT5tX2xlbikgewotCQkJCQkJbWVtY3B5 KGRlc3QsCi0JCQkJCQkgICAgKHZvaWQgKiltdG9kKG0sIHZtX29mZnNldF90KSwKLQkJCQkJCSAg ICBtLT5tX2xlbik7Ci0JCQkJCQlkZXN0ICs9IG0tPm1fbGVuOwotCQkJCQl9Ci0JCQkJfQorCisJ CQkJbV9jb3B5ZGF0YShtX2hlYWQsIDAsIG1faGVhZC0+bV9wa3RoZHIubGVuLAorCQkJCSAgICBk ZXN0KTsKIAogCQkJCXBhY2tldC0+c2VuZF9idWZfc2VjdGlvbl9pZHggPQogCQkJCSAgICBzZW5k X2J1Zl9zZWN0aW9uX2lkeDsKCg== --b1_7eac4ee6ca5161c925637e8f180bca42-- From owner-freebsd-net@freebsd.org Mon Jan 25 06:35:26 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2467C7A92 for ; Mon, 25 Jan 2016 06:35:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 720496C6 for ; Mon, 25 Jan 2016 06:35:24 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u0P6PM8x004563; Mon, 25 Jan 2016 17:25:22 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 25 Jan 2016 17:25:22 +1100 (EST) From: Ian Smith To: "Russell L. Carter" cc: freebsd-net@freebsd.org Subject: Re: ipfw NAT /etc/rc.firewall question In-Reply-To: <56A56F2D.2030200@pinyon.org> Message-ID: <20160125155850.U50714@sola.nimnet.asn.au> References: <56A56F2D.2030200@pinyon.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 06:35:26 -0000 On Sun, 24 Jan 2016 17:41:17 -0700, Russell L. Carter wrote: > Hi, > > I am making myself learn better how ipfw works. I am curious about > the optimal location of the NAT rule definition code. My immediate > application is a generic NATing gateway with an outside iface armored > up and an inside iface permitting general anarchy. The usual services > will be accessible to both sides. I plan to use kernel nat. > Looking at /etc/rc.firewall: > > In the "open" | "client" section, natd/kernel nat are configured prior > to other rules. > > In the "simple" section, natd only is configured after a bunch of > rules, and before a bunch more. Yes. The omission of kernel nat configuration (as well as just natd) in 'simple' is something I submitted patches for (to ipfw@) several times, several years ago, to no avail. If using 'simple', you need to manually add the kernel nat section, but omit the rulenumber (50). My patch just made this a function setup_nat(), called with or without a rulenmber. > My question is, right after the natd configuration, are a bunch of > rules that specify deny rules for problematic addresses. Here's the > beginning and end of the section I'm curious about: > > ${fwcmd} add deny all from "table($BAD_ADDR_TBL)" to any via ${oif} > if [ -n "$inet6" ]; then > # Stop unique local unicast address on the outside interface > ${fwcmd} add deny all from fc00::/7 to any via ${oif6} > ${fwcmd} add deny all from any to fc00::/7 via ${oif6} > ... > ${fwcmd} add deny all from ff05::/16 to any via ${oif6} > ${fwcmd} add deny all from any to ff05::/16 via ${oif6} > fi > > Reading the comment before the nat configuration and also many > comments provided by the goog, suggests it's better to define as many > rules as possible before the nat config. In general I'd say the opposite is what's more usually suggested and implemented, but as ever, 'it depends ..' > But these rules are placed after. Can someone explain to me why this > is better|required? I suspect I am missing something possibly > important. > > This is stable/10. With 'open' and 'client' the nat rules are placed right after those in setup_loopback and setup_ipv6_mandatory so NAT is performed very early. With 'simple' we are the gateway for our inside network, so we need to block a) traffic from the outside from (e.g.) 192.168.0.0/16 when we're internally using addresses in that range - or any of the others listed - as coming in from outside these are (far from uncommon) bogons; and b) block any traffic outbound to the internet that (still) has an internal address, or any other bogus address we or any of our client boxes might try sending from. So we need to check inbound traffic (still TO our external address) before performing NAT, and check outbound traffic after NAT (now FROM our external address), which is what the placement of those rules either side of NAT does. Seems to me that all those ipv6 addresses could go into that table too, simplifying that section to a couple of rules, but since I don't well enough (ie hardly at all) understand ipv6 addressing, I'll leave that. cheers, Ian From owner-freebsd-net@freebsd.org Mon Jan 25 08:22:31 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1BF4701C for ; Mon, 25 Jan 2016 08:22:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B31FAFD4 for ; Mon, 25 Jan 2016 08:22:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0P8MV5Z059615 for ; Mon, 25 Jan 2016 08:22:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206567] [msk] msk0: watchdog timeout - 88E8053 on i386 Date: Mon, 25 Jan 2016 08:22:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:22:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206567 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 25 08:24:52 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67F057280 for ; Mon, 25 Jan 2016 08:24:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58A84372 for ; Mon, 25 Jan 2016 08:24:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0P8OpPL063333 for ; Mon, 25 Jan 2016 08:24:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206533] Missing Intel I219-V support in 10-STABLE and 11-CURRENT Date: Mon, 25 Jan 2016 08:24:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable10? X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:24:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206533 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 25 08:26:59 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8B987443 for ; Mon, 25 Jan 2016 08:26:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9E3A7F2 for ; Mon, 25 Jan 2016 08:26:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0P8Qx5o067025 for ; Mon, 25 Jan 2016 08:26:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206494] lock order reversal (sleepable after non-sleepable) in in_mcast.c/bxe.c Date: Mon, 25 Jan 2016 08:26:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:26:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206494 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 25 09:22:16 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C047BA3145D for ; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9B76AB19 for ; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9A08EA3145C; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 810E2A31459; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 066F5B17; Mon, 25 Jan 2016 09:22:16 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id r129so55543748wmr.0; Mon, 25 Jan 2016 01:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CcFkVN47pIQ5OVbrQHvURyT9WAvjP32Z9OoYuQbifsc=; b=HFi4le++96JrxICuvWWBRZd1XkvrUlU8QvX/PbV5mE6yoA1+uw8u7UIm3gZ8MGhu+V 7HeUsfor3WJ14e7MgvByblCKywcXmKqg/92t0KF6N4yMd9EtUtcGw31tyUfFMSXIBuwz xEasjvjewA2w34JwR+ELpVdjeen5i9+EfOY3JcPKcHpxyx3qSMvpiircQZjjRwK7iyus dArtKEqqQMFPM7ixRPiWg8uO4onW28CGSFEzV6YEKfZA9zWfD8GD/CCkaYpyYaFJmHKp kFKRV9CGcuLan7bcxdpKGYXS+DQ200R1HVU6N3BHNRyIYA8g99GIqzv/Zz2ImDbIr+E3 yjTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CcFkVN47pIQ5OVbrQHvURyT9WAvjP32Z9OoYuQbifsc=; b=WH7K9hQFF1SZBkZ8OBb/P+aRkFo8yryEfNJQIWb5f0SszPbc57YwPqLk0P59GdFL2c KldN60pUcD/PLGvbuIVQcqeKaFGbj0a5Y+CaASbscDxWi27TVsuYW0gWdTeaZ351NwkE TEhCXg23ajBHlfPkEugiDvbGVUS2xU9f3qFEQcTH/XRZTGRWFw4j7RWVLIJvvdPawEfq TucVecKusLgL/JbHVIhmCQZ5mMtK4IN+UmLwiwXLz3pY1At2A+rA4XnHLZd0JkXv+0jD lgwk2OOvhPjod7Ol3hG656h7eIC/e8vtFjkDKbQ6oWpbQSfctfLnSEKzdibalG2t3SVm WTaQ== X-Gm-Message-State: AG10YORd7M5AZD14AYitsxJtZ7n1lXZQpgXmp6XlI7qSUtf2AsHTkvdHSUBlIvgXLVrFe/ayZUEGmuyKbAxhPQ== MIME-Version: 1.0 X-Received: by 10.194.78.175 with SMTP id c15mr16420727wjx.16.1453713733992; Mon, 25 Jan 2016 01:22:13 -0800 (PST) Received: by 10.28.136.148 with HTTP; Mon, 25 Jan 2016 01:22:13 -0800 (PST) In-Reply-To: <20160124100747.551f8e3f@ernst.home> References: <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> Date: Mon, 25 Jan 2016 11:22:13 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: gljennjohn@gmail.com Cc: Konstantin Belousov , threads@freebsd.org, Bruce Evans , net@freebsd.org Content-Type: multipart/mixed; boundary=047d7bfcf874b8bfce052a251a15 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 09:22:16 -0000 --047d7bfcf874b8bfce052a251a15 Content-Type: text/plain; charset=UTF-8 kb>You defer to ppoll() and pselect() due to the struct timespec type of kb>the argument, am I right ? Yes. kb>BTW, just noted, I think the functions should live in libc/gen. Okay. Moving them. kb>Put each sentence on new line Done. kb>The CMTR define is only used once. I do not see why not inline it, and kb>get rid of the staircase of backslashes. Initially I wrote two CMTRs - one using pselect and the other using ppoll. I left it this way to easily switch between these and that's why I have this macro. I'll inline the code as suggested. kb>Also, it seems that the next unused bit is 0x80000. I noticed that as well and fixed it. kb>Still int for msg_len ? I'll convert it to ssize_t. kb>It probably makes sense to mark pointers with __restrict. Done. gj>This seems wrong. rcvd is initialized to 1 so that the check for gj>rcvd != 0 can never be false. We already successfully called gj>__sys_recvmsg() just above the loop, so why not simplify the gj>code by doing gj> gj> if (ret == -1) gj> return (rcvd); Fixed. On Sun, Jan 24, 2016 at 11:07 AM, Gary Jennejohn wrote: > On Sun, 24 Jan 2016 07:06:34 +0200 > Konstantin Belousov wrote: > > [delete irrelevant parts of the patch] > > > > + rcvd = 1; > > > + for (i = rcvd; i < vlen; i++) { > > i = rcvd = 1; ... i++, rcvd++ ? > > > > > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > > > + if (ret == -1) { > > > + if (rcvd != 0) { > > > + /* We've received messages. Let caller > know. */ > > > > + return (rcvd); > > > + } > > > + return (ret); > > > + } > > > + > > This seems wrong. rcvd is initialized to 1 so that the check for > rcvd != 0 can never be false. We already successfully called > __sys_recvmsg() just above the loop, so why not simplify the > code by doing > > if (ret == -1) > return (rcvd); > > -- > Gary Jennejohn (gj@) > --047d7bfcf874b8bfce052a251a15 Content-Type: text/plain; charset=US-ASCII; name="sendrecvmmsg-libconly5.diff" Content-Disposition: attachment; filename="sendrecvmmsg-libconly5.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ijtrkzeo0 ZGlmZiAtLWdpdCBhL2xpYi9saWJjL2dlbi9NYWtlZmlsZS5pbmMgYi9saWIvbGliYy9nZW4vTWFr ZWZpbGUuaW5jCmluZGV4IGI0NDg0NjEuLmY5ZDJmOGEgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL2dl bi9NYWtlZmlsZS5pbmMKKysrIGIvbGliL2xpYmMvZ2VuL01ha2VmaWxlLmluYwpAQCAtOTksMTEg Kzk5LDEzIEBAIFNSQ1MrPQlfX2dldG9zcmVsZGF0ZS5jIFwKIAlyYWlzZS5jIFwKIAlyZWFkZGly LmMgXAogCXJlYWRwYXNzcGhyYXNlLmMgXAorCXJlY3ZtbXNnLmMgXAogCXJld2luZGRpci5jIFwK IAlzY2FuZGlyLmMgXAogCXNlZWQ0OC5jIFwKIAlzZWVrZGlyLmMgXAogCXNlbWN0bC5jIFwKKwlz ZW5kbW1zZy5jIFwKIAlzZXRkb21haW5uYW1lLmMgXAogCXNldGhvc3RuYW1lLmMgXAogCXNldGpt cGVyci5jIFwKZGlmZiAtLWdpdCBhL2xpYi9saWJjL2dlbi9yZWN2bW1zZy5jIGIvbGliL2xpYmMv Z2VuL3JlY3ZtbXNnLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uOTg4MzVi YQotLS0gL2Rldi9udWxsCisrKyBiL2xpYi9saWJjL2dlbi9yZWN2bW1zZy5jCkBAIC0wLDAgKzEs ODYgQEAKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMTYgQm9yaXMgQXN0YXJkemhpZXYsIFNtYXJ0 Y29tLUJ1bGdhcmlhIEFECisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJp YnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91 dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxv d2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNv dXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZShz KSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBh cworICogICAgdGhlIGZpcnN0IGxpbmVzIG9mIHRoaXMgZmlsZSB1bm1vZGlmaWVkIG90aGVyIHRo YW4gdGhlIHBvc3NpYmxlCisgKiAgICBhZGRpdGlvbiBvZiBvbmUgb3IgbW9yZSBjb3B5cmlnaHQg bm90aWNlcy4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJv ZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UocyksIHRoaXMgbGlzdCBvZiBj b25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4KKyAqICAgIHRoZSBkb2N1 bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUKKyAqICAg IGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBD T1BZUklHSFQgSE9MREVSKFMpIGBgQVMgSVMnJyBBTkQgQU5ZCisgKiBFWFBSRVNTIE9SIElNUExJ RUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1Q TElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSCisgKiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhF IENPUFlSSUdIVCBIT0xERVIoUykgQkUKKyAqIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJF Q1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IKKyAqIENPTlNFUVVFTlRJQUwg REFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GCisg KiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJP RklUUzsgT1IKKyAqIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9O IEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLAorICogV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNU IExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UKKyAqIE9SIE9USEVSV0lT RSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsCisg KiBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorICov CisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworI2lu Y2x1ZGUgPGVycm5vLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3N5 c2NhbGwuaD4KKyNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSA8c3lzL3NlbGVjdC5o PgorI2luY2x1ZGUgPHB0aHJlYWQuaD4KKyNpbmNsdWRlICJsaWJjX3ByaXZhdGUuaCIKKworc3Np emVfdAorcmVjdm1tc2coaW50IHMsIHN0cnVjdCBtbXNnaGRyICpfX3Jlc3RyaWN0IG1zZ3ZlYywg c2l6ZV90IHZsZW4sIGludCBmbGFncywKKyAgICBjb25zdCBzdHJ1Y3QgdGltZXNwZWMgKl9fcmVz dHJpY3QgdGltZW91dCkKK3sKKwlzaXplX3QgaSwgcmN2ZDsKKwlzc2l6ZV90IHJldDsKKworCWlm ICh0aW1lb3V0ICE9IE5VTEwpIHsKKwkJZmRfc2V0IGZkczsKKwkJaW50IHJlczsKKworCQlGRF9a RVJPKCZmZHMpOworCQlGRF9TRVQocywgJmZkcyk7CisJCXJlcyA9IF9fc3lzX3BzZWxlY3QocyAr IDEsICZmZHMsIE5VTEwsIE5VTEwsIHRpbWVvdXQsIE5VTEwpOworCQlpZiAocmVzID09IC0xIHx8 IHJlcyA9PSAwKQorCQkJcmV0dXJuIChyZXMpOworCQlpZiAoIUZEX0lTU0VUKHMsICZmZHMpKQor CQkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0ID0gX19zeXNfcmVjdm1zZyhzLCAmbXNndmVjWzBd Lm1zZ19oZHIsIGZsYWdzKTsKKwlpZiAocmV0ID09IC0xKQorCQlyZXR1cm4gKHJldCk7CisKKwkv KiBDaGVjayBpbml0aWFsbHkgZm9yIHRoZSBwcmVzZW5jZSBvZiBNU0dfV0FJVEZPUk9ORS4KKwkg KiBUdXJuIG9uIE1TR19ET05UV0FJVCBpZiBzZXQuICovCisJaWYgKGZsYWdzICYgTVNHX1dBSVRG T1JPTkUpIHsKKwkJZmxhZ3MgfD0gTVNHX0RPTlRXQUlUOworCQkvKiBUaGUga2VybmVsIGRvZXNu J3QgbmVlZCB0byBrbm93IGFib3V0IHRoaXMgZmxhZy4gKi8KKwkJZmxhZ3MgJj0gfk1TR19XQUlU Rk9ST05FOworCX0KKworCXJjdmQgPSAxOworCWZvciAoaSA9IHJjdmQ7IGkgPCB2bGVuOyBpKyss IHJjdmQrKykgeworCQlyZXQgPSBfX3N5c19yZWN2bXNnKHMsICZtc2d2ZWNbaV0ubXNnX2hkciwg ZmxhZ3MpOworCQlpZiAocmV0ID09IC0xKSB7CisJCQkvKiBXZSBoYXZlIHJlY2VpdmVkIG1lc3Nh Z2VzLiBMZXQgY2FsbGVyIGtub3cuICovCisJCQlyZXR1cm4gKHJjdmQpOworCQl9CisKKwkJLyog U2F2ZSByZWNlaXZlZCBieXRlcyAqLworCQltc2d2ZWNbaV0ubXNnX2xlbiA9IHJldDsKKwl9CisK KwlyZXR1cm4gKHJjdmQpOworfQpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvZ2VuL3NlbmRtbXNnLmMg Yi9saWIvbGliYy9nZW4vc2VuZG1tc2cuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAw MDAwLi5lNGU2MmE0Ci0tLSAvZGV2L251bGwKKysrIGIvbGliL2xpYmMvZ2VuL3NlbmRtbXNnLmMK QEAgLTAsMCArMSw2MiBAQAorLyoKKyAqIENvcHlyaWdodCAoYykgMjAxNiBCb3JpcyBBc3RhcmR6 aGlldiwgU21hcnRjb20tQnVsZ2FyaWEgQUQKKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgor ICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0 aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhh dCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1 dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICog ICAgbm90aWNlKHMpLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBk aXNjbGFpbWVyIGFzCisgKiAgICB0aGUgZmlyc3QgbGluZXMgb2YgdGhpcyBmaWxlIHVubW9kaWZp ZWQgb3RoZXIgdGhhbiB0aGUgcG9zc2libGUKKyAqICAgIGFkZGl0aW9uIG9mIG9uZSBvciBtb3Jl IGNvcHlyaWdodCBub3RpY2VzLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3Jt IG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZShzKSwgdGhp cyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbgorICog ICAgdGhlIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRo IHRoZQorICogICAgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklE RUQgQlkgVEhFIENPUFlSSUdIVCBIT0xERVIoUykgYGBBUyBJUycnIEFORCBBTlkKKyAqIEVYUFJF U1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywg VEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNT IEZPUiBBIFBBUlRJQ1VMQVIKKyAqIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVO VCBTSEFMTCBUSEUgQ09QWVJJR0hUIEhPTERFUihTKSBCRQorICogTElBQkxFIEZPUiBBTlkgRElS RUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUgorICogQ09O U0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VS RU1FTlQgT0YKKyAqIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBE QVRBLCBPUiBQUk9GSVRTOyBPUgorICogQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENB VVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksCisgKiBXSEVUSEVSIElOIENPTlRS QUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRQorICog T1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBT T0ZUV0FSRSwKKyAqIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBE QU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNE JCIpOworCisjaW5jbHVkZSA8ZXJybm8uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNs dWRlIDxzeXMvc3lzY2FsbC5oPgorI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRlIDxw dGhyZWFkLmg+CisjaW5jbHVkZSAibGliY19wcml2YXRlLmgiCisKK3NzaXplX3QKK3NlbmRtbXNn KGludCBzLCBzdHJ1Y3QgbW1zZ2hkciAqX19yZXN0cmljdCBtc2d2ZWMsIHNpemVfdCB2bGVuLCBp bnQgZmxhZ3MpCit7CisJc2l6ZV90IGksIHNlbnQ7CisJc3NpemVfdCByZXQ7CisKKwlzZW50ID0g MDsKKwlmb3IgKGkgPSAwOyBpIDwgdmxlbjsgaSsrLCBzZW50KyspIHsKKwkJcmV0ID0gX19zeXNf c2VuZG1zZyhzLCAmbXNndmVjW2ldLm1zZ19oZHIsIGZsYWdzKTsKKwkJaWYgKHJldCA9PSAtMSkg eworCQkJaWYgKHNlbnQgIT0gMCkgeworCQkJCS8qIFdlIGhhdmUgc2VudCBtZXNzYWdlcy4gTGV0 IGNhbGxlciBrbm93LiAqLworCQkJCXJldHVybiAoc2VudCk7CisJCQl9CisJCQlyZXR1cm4gKHJl dCk7CisJCX0KKworCQkvKiBTYXZlIHNlbnQgYnl0ZXMgKi8KKwkJbXNndmVjW2ldLm1zZ19sZW4g PSByZXQ7CisJfQorCisJcmV0dXJuIChzZW50KTsKK30KZGlmZiAtLWdpdCBhL2xpYi9saWJjL2lu Y2x1ZGUvbmFtZXNwYWNlLmggYi9saWIvbGliYy9pbmNsdWRlL25hbWVzcGFjZS5oCmluZGV4IDcz OWQ3YjEuLmM5NTgyOWUgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL2luY2x1ZGUvbmFtZXNwYWNlLmgK KysrIGIvbGliL2xpYmMvaW5jbHVkZS9uYW1lc3BhY2UuaApAQCAtMjA4LDYgKzIwOCw3IEBACiAj ZGVmaW5lCQlyZWFkdgkJCQlfcmVhZHYKICNkZWZpbmUJCXJlY3Zmcm9tCQkJX3JlY3Zmcm9tCiAj ZGVmaW5lCQlyZWN2bXNnCQkJCV9yZWN2bXNnCisjZGVmaW5lCQlyZWN2bW1zZwkJCV9yZWN2bW1z ZwogI2RlZmluZQkJc2VsZWN0CQkJCV9zZWxlY3QKICNkZWZpbmUJCXNlbV9jbG9zZQkJCV9zZW1f Y2xvc2UKICNkZWZpbmUJCXNlbV9kZXN0cm95CQkJX3NlbV9kZXN0cm95CkBAIC0yMjAsNiArMjIx LDcgQEAKICNkZWZpbmUJCXNlbV91bmxpbmsJCQlfc2VtX3VubGluawogI2RlZmluZQkJc2VtX3dh aXQJCQlfc2VtX3dhaXQKICNkZWZpbmUJCXNlbmRtc2cJCQkJX3NlbmRtc2cKKyNkZWZpbmUJCXNl bmRtbXNnCQkJX3NlbmRtbXNnCiAjZGVmaW5lCQlzZW5kdG8JCQkJX3NlbmR0bwogI2RlZmluZQkJ c2V0c29ja29wdAkJCV9zZXRzb2Nrb3B0CiAvKiNkZWZpbmUJCXNpZ2FjdGlvbgkJCV9zaWdhY3Rp b24qLwpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvaW5jbHVkZS91bi1uYW1lc3BhY2UuaCBiL2xpYi9s aWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmgKaW5kZXggZjMxZmE3YS4uMDIzMzM0OCAxMDA2NDQK LS0tIGEvbGliL2xpYmMvaW5jbHVkZS91bi1uYW1lc3BhY2UuaAorKysgYi9saWIvbGliYy9pbmNs dWRlL3VuLW5hbWVzcGFjZS5oCkBAIC0xODksNiArMTg5LDcgQEAKICN1bmRlZgkJcmVhZHYKICN1 bmRlZgkJcmVjdmZyb20KICN1bmRlZgkJcmVjdm1zZworI3VuZGVmCQlyZWN2bW1zZwogI3VuZGVm CQlzZWxlY3QKICN1bmRlZgkJc2VtX2Nsb3NlCiAjdW5kZWYJCXNlbV9kZXN0cm95CkBAIC0yMDEs NiArMjAyLDcgQEAKICN1bmRlZgkJc2VtX3VubGluawogI3VuZGVmCQlzZW1fd2FpdAogI3VuZGVm CQlzZW5kbXNnCisjdW5kZWYJCXNlbmRtbXNnCiAjdW5kZWYJCXNlbmR0bwogI3VuZGVmCQlzZXRz b2Nrb3B0CiAjdW5kZWYJCXNpZ2FjdGlvbgpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvc3lzL1N5bWJv bC5tYXAgYi9saWIvbGliYy9zeXMvU3ltYm9sLm1hcAppbmRleCA3YjMyNTdjLi5kYzJlZDBlIDEw MDY0NAotLS0gYS9saWIvbGliYy9zeXMvU3ltYm9sLm1hcAorKysgYi9saWIvbGliYy9zeXMvU3lt Ym9sLm1hcApAQCAtMzk5LDYgKzM5OSw4IEBAIEZCU0RfMS40IHsKIAl1dGltZW5zYXQ7CiAJbnVt YV9zZXRhZmZpbml0eTsKIAludW1hX2dldGFmZmluaXR5OworCXNlbmRtbXNnOworCXJlY3ZtbXNn OwogfTsKIAogRkJTRHByaXZhdGVfMS4wIHsKZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9yZWN2 LjIgYi9saWIvbGliYy9zeXMvcmVjdi4yCmluZGV4IDMyNmU3ZmYuLmU5NDAzNjQgMTAwNjQ0Ci0t LSBhL2xpYi9saWJjL3N5cy9yZWN2LjIKKysrIGIvbGliL2xpYmMvc3lzL3JlY3YuMgpAQCAtMzQs OCArMzQsOSBAQAogLlNoIE5BTUUKIC5ObSByZWN2ICwKIC5ObSByZWN2ZnJvbSAsCi0uTm0gcmVj dm1zZwotLk5kIHJlY2VpdmUgYSBtZXNzYWdlIGZyb20gYSBzb2NrZXQKKy5ObSByZWN2bXNnICwK Ky5ObSByZWN2bW1zZworLk5kIHJlY2VpdmUgbWVzc2FnZShzKSBmcm9tIGEgc29ja2V0CiAuU2gg TElCUkFSWQogLkxiIGxpYmMKIC5TaCBTWU5PUFNJUwpAQCAtNDcsMTEgKzQ4LDE1IEBACiAuRm4g cmVjdmZyb20gImludCBzIiAidm9pZCAqYnVmIiAic2l6ZV90IGxlbiIgImludCBmbGFncyIgInN0 cnVjdCBzb2NrYWRkciAqIHJlc3RyaWN0IGZyb20iICJzb2NrbGVuX3QgKiByZXN0cmljdCBmcm9t bGVuIgogLkZ0IHNzaXplX3QKIC5GbiByZWN2bXNnICJpbnQgcyIgInN0cnVjdCBtc2doZHIgKm1z ZyIgImludCBmbGFncyIKKy5GdCBzc2l6ZV90CisuRm4gcmVjdm1tc2cgImludCBzIiAic3RydWN0 IG1tc2doZHIgKiByZXN0cmljdCBtc2d2ZWMiICJzaXplX3QgdmxlbiIgImludCBmbGFncyIgImNv bnN0IHN0cnVjdCB0aW1lc3BlYyAqIHJlc3RyaWN0IHRpbWVvdXQiCiAuU2ggREVTQ1JJUFRJT04K IFRoZQogLkZuIHJlY3Zmcm9tCiBhbmQKIC5GbiByZWN2bXNnCithbmQKKy5GbiByZWN2bW1zZwog c3lzdGVtIGNhbGxzCiBhcmUgdXNlZCB0byByZWNlaXZlIG1lc3NhZ2VzIGZyb20gYSBzb2NrZXQs CiBhbmQgbWF5IGJlIHVzZWQgdG8gcmVjZWl2ZSBkYXRhIG9uIGEgc29ja2V0IHdoZXRoZXIgb3Ig bm90CkBAIC04NCw4ICs4OSwyOSBAQCBudWxsIHBvaW50ZXIgcGFzc2VkIGFzIGl0cwogLkZhIGZy b20KIGFyZ3VtZW50LgogLlBwCi1BbGwgdGhyZWUgcm91dGluZXMgcmV0dXJuIHRoZSBsZW5ndGgg b2YgdGhlIG1lc3NhZ2Ugb24gc3VjY2Vzc2Z1bAotY29tcGxldGlvbi4KK1RoZQorLkZuIHJlY3Zt bXNnCitmdW5jdGlvbiBpcyB1c2VkIHRvIHJlY2VpdmUgbXVsdGlwbGUKK21lc3NhZ2VzIGF0IGEg Y2FsbC4KK1RoZWlyIG51bWJlciBpcyBzdXBwbGllZCBieQorLkZhIHZsZW4gLgorVGhlIG1lc3Nh Z2VzIGFyZSBwbGFjZWQgaW4gdGhlCisuRmEgbXNndmVjCit2ZWN0b3IgYWZ0ZXIgcmVjZXB0aW9u LgorVGhlIHNpemUgb2YgZWFjaCByZWNlaXZlZCBtZXNzYWdlIGlzIHBsYWNlZCBpbiB0aGUKKy5G YSBtc2dfbGVuCitmaWVsZCBvZiBlYWNoIGVsZW1lbnQgb2YgdGhlIHZlY3Rvci4KK0lmCisuRmEg dGltZW91dAoraXMgTlVMTCB0aGUgY2FsbCB3aWxsIG5vcm1hbGx5IGJsb2NrLgorT3RoZXJ3aXNl IGl0IHdpbGwgd2FpdCBmb3IgZGF0YSBmb3IgdGhlIHNwZWNpZmllZCBhbW91bnQgb2YgdGltZS4K K0lmIHRoZSB0aW1lb3V0IGV4cGlyZXMgYW5kIHRoZXJlIGlzIG5vIGRhdGEgcmVjZWl2ZWQgYSB2 YWx1ZSBvZiAwIGlzIHJldHVybmVkLgorcHNlbGVjdCgyKSBpcyB1c2VkIGZvciB0aGUgaW1wbGVt ZW50YXRpb24gb2YgdGhlIHRpbWVvdXQgbWVjaGFuaXNtLgorLlBwCitUaGUgZmlyc3QgdGhyZWUg cm91dGluZXMgcmV0dXJuIHRoZSBsZW5ndGggb2YgdGhlIG1lc3NhZ2Ugb24gc3VjY2Vzc2Z1bAor Y29tcGxldGlvbiB3aGVyZWFzCisuRm4gcmVjdm1tc2cKK3JldHVybnMgdGhlIG51bWJlciBvZiBy ZWNlaXZlZCBtZXNzYWdlcy4KIElmIGEgbWVzc2FnZSBpcyB0b28gbG9uZyB0byBmaXQgaW4gdGhl IHN1cHBsaWVkIGJ1ZmZlciwKIGV4Y2VzcyBieXRlcyBtYXkgYmUgZGlzY2FyZGVkIGRlcGVuZGlu ZyBvbiB0aGUgdHlwZSBvZiBzb2NrZXQKIHRoZSBtZXNzYWdlIGlzIHJlY2VpdmVkIGZyb20gKHNl ZQpAQCAtMTAwLDcgKzEyNiw5IEBAIGluIHdoaWNoIGNhc2UgdGhlIHZhbHVlCiAuVmEgZXJybm8K IGlzIHNldCB0bwogLkVyIEVBR0FJTiAuCi1UaGUgcmVjZWl2ZSBjYWxscyBub3JtYWxseSByZXR1 cm4gYW55IGRhdGEgYXZhaWxhYmxlLAorVGhlIHJlY2VpdmUgY2FsbHMgZXhjZXB0CisuRm4gcmVj dm1tc2cKK25vcm1hbGx5IHJldHVybiBhbnkgZGF0YSBhdmFpbGFibGUsCiB1cCB0byB0aGUgcmVx dWVzdGVkIGFtb3VudCwKIHJhdGhlciB0aGFuIHdhaXRpbmcgZm9yIHJlY2VpcHQgb2YgdGhlIGZ1 bGwgYW1vdW50IHJlcXVlc3RlZDsKIHRoaXMgYmVoYXZpb3IgaXMgYWZmZWN0ZWQgYnkgdGhlIHNv Y2tldC1sZXZlbCBvcHRpb25zCkBAIC0xMjcsNiArMTU1LDkgQEAgb25lIG9yIG1vcmUgb2YgdGhl IHZhbHVlczoKIC5JdCBEdiBNU0dfV0FJVEFMTCBUYSB3YWl0IGZvciBmdWxsIHJlcXVlc3Qgb3Ig ZXJyb3IKIC5JdCBEdiBNU0dfRE9OVFdBSVQgVGEgZG8gbm90IGJsb2NrCiAuSXQgRHYgTVNHX0NN U0dfQ0xPRVhFQyBUYSBzZXQgcmVjZWl2ZWQgZmRzIGNsb3NlLW9uLWV4ZWMKKy5JdCBEdiBNU0df V0FJVEZPUk9ORSBUYSBkbyBub3QgYmxvY2sgYWZ0ZXIgcmVjZWl2aW5nIHRoZSBmaXJzdCBtZXNz YWdlCisocmVsZXZhbnQgb25seSBmb3IKKy5GbiByZWN2bW1zZyApCiAuRWwKIC5QcAogVGhlCkBA IC0xNTgsNiArMTg5LDExIEBAIGlzIHNldCB0bwogVGhpcyBmbGFnIGlzIG5vdCBhdmFpbGFibGUg aW4gc3RyaWN0CiAuVG4gQU5TSQogb3IgQzk5IGNvbXBpbGF0aW9uIG1vZGUuCitUaGUKKy5EdiBN U0dfV0FJVEZPUk9ORQorZmxhZyBzZXRzIE1TR19ET05UV0FJVCBhZnRlciB0aGUgZmlyc3QgbWVz c2FnZSBoYXMgYmVlbiByZWNlaXZlZC4KK1RoaXMgZmxhZyBpcyBvbmx5IHJlbGV2YW50IGZvcgor LkZuIHJlY3ZtbXNnIC4KIC5QcAogVGhlCiAuRm4gcmVjdm1zZwpAQCAtMjkwLDkgKzMyNiwzMyBA QCBjb250cm9sIGRhdGEgd2VyZSBkaXNjYXJkZWQgZHVlIHRvIGxhY2sgb2Ygc3BhY2UgaW4gdGhl IGJ1ZmZlcgogZm9yIGFuY2lsbGFyeSBkYXRhLgogLkR2IE1TR19PT0IKIGlzIHJldHVybmVkIHRv IGluZGljYXRlIHRoYXQgZXhwZWRpdGVkIG9yIG91dC1vZi1iYW5kIGRhdGEgd2VyZSByZWNlaXZl ZC4KKy5QcAorVGhlCisuRm4gcmVjdm1tc2cKK3N5c3RlbSBjYWxsIHVzZXMgdGhlCisuRmEgbW1z Z2hkcgorc3RydWN0dXJlLiBJdHMgZm9ybSBpcyBhcyBmb2xsb3dzLCBhcyBkZWZpbmVkIGluCisu SW4gc3lzL3NvY2tldC5oIDoKKy5CZCAtbGl0ZXJhbAorc3RydWN0IG1tc2doZHIgeworCXN0cnVj dCBtc2doZHIJIG1zZ19oZHI7CS8qIG1lc3NhZ2UgaGVhZGVyICovCisJc3NpemVfdAkJIG1zZ19s ZW47CS8qIG1lc3NhZ2UgbGVuZ3RoICovCit9OworLkVkCisuUHAKK0ZvcgorLkZhIG1zZ19oZHIK K3NlZSBhYm92ZS4gT24gZGF0YSByZWNlcHRpb24gdGhlCisuRmEgbXNnX2xlbgorZmllbGQgaXMg dXBkYXRlZCB0byB0aGUgbGVuZ3RoIG9mIHRoZSByZWNlaXZlZCBtZXNzYWdlLgorT24gZGF0YSB0 cmFuc21pc3Npb24gaXQgaXMgdXBkYXRlZCB0byB0aGUgbnVtYmVyIG9mIGNoYXJhY3RlcnMgc2Vu dC4KIC5TaCBSRVRVUk4gVkFMVUVTCi1UaGVzZSBjYWxscyByZXR1cm4gdGhlIG51bWJlciBvZiBi eXRlcyByZWNlaXZlZCwgb3IgLTEKLWlmIGFuIGVycm9yIG9jY3VycmVkLgorVGhlc2UgY2FsbHMg ZXhjZXB0CisuRm4gcmVjdm1tc2cKK3JldHVybiB0aGUgbnVtYmVyIG9mIGJ5dGVzIHJlY2VpdmVk LgorLkZuIHJlY3ZtbXNnCityZXR1cm5zIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgcmVjZWl2ZWQu CitBIHZhbHVlIG9mIC0xIGlzIHJldHVybmVkIGlmIGFuIGVycm9yIG9jY3VycmVkLgogLlNoIEVS Uk9SUwogVGhlIGNhbGxzIGZhaWwgaWY6CiAuQmwgLXRhZyAtd2lkdGggRXIKZGlmZiAtLWdpdCBh L2xpYi9saWJjL3N5cy9zZW5kLjIgYi9saWIvbGliYy9zeXMvc2VuZC4yCmluZGV4IDhmYTJjNjQu Ljk4MTBhY2UgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL3N5cy9zZW5kLjIKKysrIGIvbGliL2xpYmMv c3lzL3NlbmQuMgpAQCAtMzQsOCArMzQsOSBAQAogLlNoIE5BTUUKIC5ObSBzZW5kICwKIC5ObSBz ZW5kdG8gLAotLk5tIHNlbmRtc2cKLS5OZCBzZW5kIGEgbWVzc2FnZSBmcm9tIGEgc29ja2V0Cisu Tm0gc2VuZG1zZyAsCisuTm0gc2VuZG1tc2cKKy5OZCBzZW5kIG1lc3NhZ2UocykgZnJvbSBhIHNv Y2tldAogLlNoIExJQlJBUlkKIC5MYiBsaWJjCiAuU2ggU1lOT1BTSVMKQEAgLTQ3LDYgKzQ4LDgg QEAKIC5GbiBzZW5kdG8gImludCBzIiAiY29uc3Qgdm9pZCAqbXNnIiAic2l6ZV90IGxlbiIgImlu dCBmbGFncyIgImNvbnN0IHN0cnVjdCBzb2NrYWRkciAqdG8iICJzb2NrbGVuX3QgdG9sZW4iCiAu RnQgc3NpemVfdAogLkZuIHNlbmRtc2cgImludCBzIiAiY29uc3Qgc3RydWN0IG1zZ2hkciAqbXNn IiAiaW50IGZsYWdzIgorLkZ0IHNzaXplX3QKKy5GbiBzZW5kbW1zZyAiaW50IHMiICJzdHJ1Y3Qg bW1zZ2hkciAqIHJlc3RyaWN0IG1zZ3ZlYyIgInNpemVfdCB2bGVuIiAiaW50IGZsYWdzIgogLlNo IERFU0NSSVBUSU9OCiBUaGUKIC5GbiBzZW5kCkBAIC01NSw4ICs1OCwxMSBAQCBhbmQKIC5GbiBz ZW5kdG8KIGFuZAogLkZuIHNlbmRtc2cKK2FuZAorLkZuIHNlbmRtbXNnCiBzeXN0ZW0gY2FsbHMK LWFyZSB1c2VkIHRvIHRyYW5zbWl0IGEgbWVzc2FnZSB0byBhbm90aGVyIHNvY2tldC4KK2FyZSB1 c2VkIHRvIHRyYW5zbWl0IG9uZSBvciBtdWx0aXBsZSBtZXNzYWdlcyAod2l0aCB0aGUgbGF0dGVy IGNhbGwpIHRvCithbm90aGVyIHNvY2tldC4KIFRoZQogLkZuIHNlbmQKIGZ1bmN0aW9uCkBAIC02 Niw2ICs3Miw4IEBAIHN0YXRlLCB3aGlsZQogLkZuIHNlbmR0bwogYW5kCiAuRm4gc2VuZG1zZwor YW5kCisuRm4gc2VuZG1tc2cKIG1heSBiZSB1c2VkIGF0IGFueSB0aW1lLgogLlBwCiBUaGUgYWRk cmVzcyBvZiB0aGUgdGFyZ2V0IGlzIGdpdmVuIGJ5CkBAIC04MSw2ICs4OSwxOCBAQCB1bmRlcmx5 aW5nIHByb3RvY29sLCB0aGUgZXJyb3IKIGlzIHJldHVybmVkLCBhbmQKIHRoZSBtZXNzYWdlIGlz IG5vdCB0cmFuc21pdHRlZC4KIC5QcAorVGhlCisuRm4gc2VuZG1tc2cKK2Z1bmN0aW9uIHNlbmRz IG11bHRpcGxlIG1lc3NhZ2VzIGF0IGEgY2FsbC4KK1RoZXkgYXJlIGdpdmVuIGJ5IHRoZQorLkZh IG1zZ3ZlYwordmVjdG9yIGFsb25nIHdpdGgKKy5GYSB2bGVuCitzcGVjaWZ5aW5nIGl0cyBzaXpl LgorVGhlIG51bWJlciBvZiBjaGFyYWN0ZXJzIHNlbnQgcGVyIGVhY2ggbWVzc2FnZSBpcyBwbGFj ZWQgaW4gdGhlCisuRmEgbXNnX2xlbgorZmllbGQgb2YgZWFjaCBlbGVtZW50IG9mIHRoZSB2ZWN0 b3IgYWZ0ZXIgdHJhbnNtaXNzaW9uLgorLlBwCiBObyBpbmRpY2F0aW9uIG9mIGZhaWx1cmUgdG8g ZGVsaXZlciBpcyBpbXBsaWNpdCBpbiBhCiAuRm4gc2VuZCAuCiBMb2NhbGx5IGRldGVjdGVkIGVy cm9ycyBhcmUgaW5kaWNhdGVkIGJ5IGEgcmV0dXJuIHZhbHVlIG9mIC0xLgpAQCAtMTM4LDEwICsx NTgsMTYgQEAgU2VlCiAuWHIgcmVjdiAyCiBmb3IgYSBkZXNjcmlwdGlvbiBvZiB0aGUKIC5GYSBt c2doZHIKK3N0cnVjdHVyZSBhbmQgdGhlCisuRmEgbW1zZ2hkcgogc3RydWN0dXJlLgogLlNoIFJF VFVSTiBWQUxVRVMKLVRoZSBjYWxsIHJldHVybnMgdGhlIG51bWJlciBvZiBjaGFyYWN0ZXJzIHNl bnQsIG9yIC0xCi1pZiBhbiBlcnJvciBvY2N1cnJlZC4KK0FsbCBjYWxscyBleGNlcHQKKy5GbiBz ZW5kbW1zZworcmV0dXJuIHRoZSBudW1iZXIgb2YgY2hhcmFjdGVycyBzZW50LiBUaGUKKy5GbiBz ZW5kbW1zZworY2FsbCByZXR1cm5zIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgc2VudC4KK0lmIGFu IGVycm9yIG9jY3VycmVkIGEgdmFsdWUgb2YgLTEgaXMgcmV0dXJuZWQuCiAuU2ggRVJST1JTCiBU aGUKIC5GbiBzZW5kCkBAIC0xNDksNiArMTc1LDggQEAgZnVuY3Rpb24gYW5kCiAuRm4gc2VuZHRv CiBhbmQKIC5GbiBzZW5kbXNnCithbmQKKy5GbiBzZW5kbW1zZwogc3lzdGVtIGNhbGxzCiBmYWls IGlmOgogLkJsIC10YWcgLXdpZHRoIEVyCmRpZmYgLS1naXQgYS9zeXMvc3lzL3NvY2tldC5oIGIv c3lzL3N5cy9zb2NrZXQuaAppbmRleCAxOGUyZGUxLi5jN2EyMWNjIDEwMDY0NAotLS0gYS9zeXMv c3lzL3NvY2tldC5oCisrKyBiL3N5cy9zeXMvc29ja2V0LmgKQEAgLTQzMSw2ICs0MzEsOSBAQCBz dHJ1Y3QgbXNnaGRyIHsKICNkZWZpbmUJTVNHX05CSU8JMHg0MDAwCQkvKiBGSU9OQklPIG1vZGUs IHVzZWQgYnkgZmlmb2ZzICovCiAjZGVmaW5lCU1TR19DT01QQVQgICAgICAweDgwMDAJCS8qIHVz ZWQgaW4gc2VuZGl0KCkgKi8KICNkZWZpbmUJTVNHX0NNU0dfQ0xPRVhFQyAweDQwMDAwCS8qIG1h a2UgcmVjZWl2ZWQgZmRzIGNsb3NlLW9uLWV4ZWMgKi8KKyNpZm5kZWYgX0tFUk5FTAorI2RlZmlu ZSBNU0dfV0FJVEZPUk9ORQkweDgwMDAwCQkvKiBmb3IgcmVjdm1tc2coKSAqLworI2VuZGlmIC8q ICFfS0VSTkVMICovCiAjZW5kaWYKICNpZmRlZiBfS0VSTkVMCiAjZGVmaW5lCU1TR19TT0NBTExC Q0sgICAweDEwMDAwCQkvKiBmb3IgdXNlIGJ5IHNvY2tldCBjYWxsYmFja3MgLSBzb3JlY2VpdmUg KFRDUCkgKi8KQEAgLTU5NSw2ICs1OTgsMTggQEAgc3RydWN0IHNmX2hkdHIgewogI2VuZGlmIC8q IF9LRVJORUwgKi8KICNlbmRpZiAvKiBfX0JTRF9WSVNJQkxFICovCiAKKyNpZm5kZWYgX0tFUk5F TAorI2lmZGVmIF9fQlNEX1ZJU0lCTEUKKy8qCisgKiBTZW5kL3JlY3ZtbXNnIHNwZWNpZmljIHN0 cnVjdHVyZShzKQorICovCitzdHJ1Y3QgbW1zZ2hkciB7CisJc3RydWN0IG1zZ2hkcgltc2dfaGRy OwkJLyogbWVzc2FnZSBoZWFkZXIgKi8KKwlzc2l6ZV90CQltc2dfbGVuOwkJLyogbWVzc2FnZSBs ZW5ndGggKi8KK307CisjZW5kaWYgLyogX19CU0RfVklTSUJMRSAqLworI2VuZGlmIC8qICFfS0VS TkVMICovCisKICNpZm5kZWYJX0tFUk5FTAogCiAjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CkBAIC02 MTUsMTEgKzYzMCwxOSBAQCBpbnQJbGlzdGVuKGludCwgaW50KTsKIHNzaXplX3QJcmVjdihpbnQs IHZvaWQgKiwgc2l6ZV90LCBpbnQpOwogc3NpemVfdAlyZWN2ZnJvbShpbnQsIHZvaWQgKiwgc2l6 ZV90LCBpbnQsIHN0cnVjdCBzb2NrYWRkciAqIF9fcmVzdHJpY3QsIHNvY2tsZW5fdCAqIF9fcmVz dHJpY3QpOwogc3NpemVfdAlyZWN2bXNnKGludCwgc3RydWN0IG1zZ2hkciAqLCBpbnQpOworI2lm IF9fQlNEX1ZJU0lCTEUKK3N0cnVjdCB0aW1lc3BlYzsKK3NzaXplX3QJcmVjdm1tc2coaW50LCBz dHJ1Y3QgbW1zZ2hkciAqIF9fcmVzdHJpY3QsIHNpemVfdCwgaW50LAorICAgIGNvbnN0IHN0cnVj dCB0aW1lc3BlYyAqIF9fcmVzdHJpY3QpOworI2VuZGlmCiBzc2l6ZV90CXNlbmQoaW50LCBjb25z dCB2b2lkICosIHNpemVfdCwgaW50KTsKIHNzaXplX3QJc2VuZHRvKGludCwgY29uc3Qgdm9pZCAq LAogCSAgICBzaXplX3QsIGludCwgY29uc3Qgc3RydWN0IHNvY2thZGRyICosIHNvY2tsZW5fdCk7 CiBzc2l6ZV90CXNlbmRtc2coaW50LCBjb25zdCBzdHJ1Y3QgbXNnaGRyICosIGludCk7CiAjaWYg X19CU0RfVklTSUJMRQorc3NpemVfdAlzZW5kbW1zZyhpbnQsIHN0cnVjdCBtbXNnaGRyICogX19y ZXN0cmljdCwgc2l6ZV90LCBpbnQpOworI2VuZGlmCisjaWYgX19CU0RfVklTSUJMRQogaW50CXNl bmRmaWxlKGludCwgaW50LCBvZmZfdCwgc2l6ZV90LCBzdHJ1Y3Qgc2ZfaGR0ciAqLCBvZmZfdCAq LCBpbnQpOwogaW50CXNldGZpYihpbnQpOwogI2VuZGlmCg== --047d7bfcf874b8bfce052a251a15-- From owner-freebsd-net@freebsd.org Mon Jan 25 15:43:15 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AF3BA4647C for ; Mon, 25 Jan 2016 15:43:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B9341DD for ; Mon, 25 Jan 2016 15:43:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0PFhFM2001584 for ; Mon, 25 Jan 2016 15:43:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206533] Missing Intel I219-V support in 10-STABLE and 11-CURRENT Date: Mon, 25 Jan 2016 15:43:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable10? X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 15:43:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206533 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #1 from Sean Bruno --- Yep, all of this is true. However, when integrating Intel's upstream chang= es to enable this support, this causes many, many, MANY *other* chipsets to fa= il to attach to the driver (em). This is being discussed in phabricator reviews ... I think that makes this ticket irrelevant, but I'll leave it open if the submitter wishes. https://reviews.freebsd.org/D3162 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 25 15:46:59 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89F81A4660B for ; Mon, 25 Jan 2016 15:46:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A81A7E5 for ; Mon, 25 Jan 2016 15:46:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0PFkxBY007937 for ; Mon, 25 Jan 2016 15:46:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193452] Dell PowerEdge 210 II -- Kernel panic bce (broadcom) Date: Mon, 25 Jan 2016 15:46:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 15:46:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193452 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |sbruno@FreeBSD.org --- Comment #1 from Sean Bruno --- Does the submitter have the ability to test 10 release or stable? We have *one* of these machines in the FreeBSD cluster and I don't ever remember it doing this. However, we track current pretty aggressively. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 25 18:52:41 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4AE9A45709 for ; Mon, 25 Jan 2016 18:52:40 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A96251388 for ; Mon, 25 Jan 2016 18:52:40 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by quine.pinyon.org (Postfix, from userid 122) id 3391D16026A; Mon, 25 Jan 2016 11:52:39 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Received: from feyerabend.n1.pinyon.org (acipenser.esturion.net [65.101.5.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id DD9671601C7; Mon, 25 Jan 2016 11:52:36 -0700 (MST) Subject: Re: ipfw NAT /etc/rc.firewall question To: Ian Smith References: <56A56F2D.2030200@pinyon.org> <20160125155850.U50714@sola.nimnet.asn.au> From: "Russell L. Carter" Cc: freebsd-net@freebsd.org Message-ID: <56A66EF4.40806@pinyon.org> Date: Mon, 25 Jan 2016 11:52:36 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160125155850.U50714@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 18:52:41 -0000 On 01/24/16 23:25, Ian Smith wrote: > On Sun, 24 Jan 2016 17:41:17 -0700, Russell L. Carter wrote: > > Hi, > > > > I am making myself learn better how ipfw works. I am curious about > > the optimal location of the NAT rule definition code. My immediate > > application is a generic NATing gateway with an outside iface armored > > up and an inside iface permitting general anarchy. The usual services > > will be accessible to both sides. I plan to use kernel nat. > > Looking at /etc/rc.firewall: > > > > In the "open" | "client" section, natd/kernel nat are configured prior > > to other rules. > > > > In the "simple" section, natd only is configured after a bunch of > > rules, and before a bunch more. > > Yes. The omission of kernel nat configuration (as well as just natd) in > 'simple' is something I submitted patches for (to ipfw@) several times, > several years ago, to no avail. If using 'simple', you need to manually > add the kernel nat section, but omit the rulenumber (50). My patch just > made this a function setup_nat(), called with or without a rulenmber. Yeah I already planned on owning my rules file. I generally rip out everything not explicitly required by my specific setup on that particular system, so I'll just have a single kernel nat config. I really like how easy it is to hook into the rc system, and define my own variables for setting in rc.conf. More below... > > My question is, right after the natd configuration, are a bunch of > > rules that specify deny rules for problematic addresses. Here's the > > beginning and end of the section I'm curious about: > > > > ${fwcmd} add deny all from "table($BAD_ADDR_TBL)" to any via ${oif} > > if [ -n "$inet6" ]; then > > # Stop unique local unicast address on the outside interface > > ${fwcmd} add deny all from fc00::/7 to any via ${oif6} > > ${fwcmd} add deny all from any to fc00::/7 via ${oif6} > > ... > > ${fwcmd} add deny all from ff05::/16 to any via ${oif6} > > ${fwcmd} add deny all from any to ff05::/16 via ${oif6} > > fi > > > > Reading the comment before the nat configuration and also many > > comments provided by the goog, suggests it's better to define as many > > rules as possible before the nat config. > > In general I'd say the opposite is what's more usually suggested and > implemented, but as ever, 'it depends ..' > > > But these rules are placed after. Can someone explain to me why this > > is better|required? I suspect I am missing something possibly > > important. > > > > This is stable/10. > > With 'open' and 'client' the nat rules are placed right after those in > setup_loopback and setup_ipv6_mandatory so NAT is performed very early. > > With 'simple' we are the gateway for our inside network, so we need to > block a) traffic from the outside from (e.g.) 192.168.0.0/16 when we're > internally using addresses in that range - or any of the others listed - > as coming in from outside these are (far from uncommon) bogons; and b) > block any traffic outbound to the internet that (still) has an internal > address, or any other bogus address we or any of our client boxes might > try sending from. > > So we need to check inbound traffic (still TO our external address) > before performing NAT, and check outbound traffic after NAT (now FROM > our external address), which is what the placement of those rules either > side of NAT does. > > Seems to me that all those ipv6 addresses could go into that table too, > simplifying that section to a couple of rules, but since I don't well > enough (ie hardly at all) understand ipv6 addressing, I'll leave that. Ah, so taking this explanation back to the rules surrounding the 'simple' natd config it makes much more sense now. Thanks! Russell > cheers, Ian > From owner-freebsd-net@freebsd.org Mon Jan 25 23:22:14 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2103CA46835 for ; Mon, 25 Jan 2016 23:22:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 101BCEA2 for ; Mon, 25 Jan 2016 23:22:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0PNMC6K001482 for ; Mon, 25 Jan 2016 23:22:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203524] TCP checksum failed on igb network adapter Date: Mon, 25 Jan 2016 23:22:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 23:22:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203524 Gleb Smirnoff changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glebius@FreeBSD.org --- Comment #3 from Gleb Smirnoff --- Karim, what I see in the FreeBSD head is that m_megapullup() runs m_align()= on the mbuf, so the patch is no longer needed. P.S. I filed a bug for igb(4). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 25 23:55:21 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7C2DA4554A for ; Mon, 25 Jan 2016 23:55:21 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66894D14 for ; Mon, 25 Jan 2016 23:55:21 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id w75so98239371oie.0 for ; Mon, 25 Jan 2016 15:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=V7HfN4hscS7ZglDSy7yyJCoLEmVj3yHTDTWBo/jdXVk=; b=l9dFmuQh37GkmRzFIb3f4FHFICyz/2P3qAIB40IoQimy9uYrK0HXdjNg0MCkJt4pXk PM2RjgUCGuFvv98wgdqHlII24iYsi9MNKGTUW/y7PyIhqqQ0fJku3r8pipGmH3lTbXKR pafqs7mjdC4wmL2JNVpq0mv/a/0KANmHxiEIjZCJVnJDshMNOtxKb0vzwpDfZayvkld0 s91UFZ3s3F26lNTf9uoIMQhFMLnLvlxP6cjciyrDufKf0vi6kOdZSQsX3QvXhH7IcivU 0LAhLJ4DqEdw7mUN/0whK4hyYc5rH3q2wIvw/hTRU+Q8aKkPxB4waBlvM3E50O1Xwcei vSbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=V7HfN4hscS7ZglDSy7yyJCoLEmVj3yHTDTWBo/jdXVk=; b=DCzW4+1NbAbLTI/PvTcoJItEreeM8tv8amwbDfSFnLnHS+I7UNFv+d4NHh6tfkr4SK GhTLPazQ4a1csTqJg4yENhbc/Vx0ZryCwmF5WxLc+L34G6jugE9DWYvXjecixCK60Irc Pf15FwxHTZTMZCDfNIbQDGanzjLyX89Vieyb3x6PSiv/sz72dfksQElx7FgPvHegnhUn XG/oSeGIX5vBItFLOFlJPArD1/tN2eHuzpFyUNcMbNntPPHduaBZMqUTIV2L7NqCNDYa KJvudEGDznSIbjeLX4GrMf5ZgEr5hF64xjszUYZOtBg525ZJ2DOffat3iQXrysXIIJyB /qgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=V7HfN4hscS7ZglDSy7yyJCoLEmVj3yHTDTWBo/jdXVk=; b=JvGWvECzri0xbBDoDidph/Eoyr29apcKGYOz78fWWJKBxdWE0U8X8S/9eixfqYRMUu K1Qz3fJn4nEBLuSp1VQdoDoXOSq84dxYZ2gufJt/EVAOxPL9bTxBFYvdORaXJhR2SYrB 0eNoutV63iNHLVNSrkuNjwPpvQgIWm4EcW3FOK+sCycDQqs1OIovbUXe/Qmax8s+zcgr O6vwpvwbIDT70JgU3XQBBSWrnrfuGsh3NxHdt4j4oMezKgRUsVcHYWPrg2N+x/B+2MOm dvXhf6B9SJ6OR+Mq3zcieL2i63x/SY4PU6LtlI9wm3IvV54RFSFFd0PZWdvW9dtAm9cB HNvg== X-Gm-Message-State: AG10YOSXnl/XavSj4BAzWjPJW927BFTqiNtFNXym4QT57k0Wf7t3gXcJMa7mxVnmxkLdEk6+3WIfHdh042iMJA== MIME-Version: 1.0 X-Received: by 10.202.4.82 with SMTP id 79mr15231360oie.118.1453766120698; Mon, 25 Jan 2016 15:55:20 -0800 (PST) Sender: sunxiaoye07@gmail.com Received: by 10.202.223.5 with HTTP; Mon, 25 Jan 2016 15:55:20 -0800 (PST) Date: Mon, 25 Jan 2016 17:55:20 -0600 X-Google-Sender-Auth: t2Eh3CMV7kIVtE07rFXhp-ruok8 Message-ID: Subject: swaping ring slots between NIC ring and Host ring does not always success From: Xiaoye Sun To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 23:55:21 -0000 Hi all, I wrote a netmap application that is very similar to bridge.c in master/example directory of the netmap code. The major difference between my program and bridge.c is that my application also creates custom packets that are directly put into the tx ring of the NIC (like a packet generator with NIC-Host packet forwarding). Each generated packet has an unique sequence number so that the receiver can tell if a packet is lost. Like bridge.c, the packet forwarding between the nic and the host uses 'zerocopy', so that the program only swaps the buf_idx of the slots to virtually forward the packet to the other end. NS_BUF_CHANGED is set for the slots (both rx and tx) whose buf_idx has been changed due to zerocopy. I set the number of rings on nic to 1 using the ethtool command, i.e., one pair of netmap rings for the nic (one for host tx and one for host rx) and another pair of rings for the host (one for host tx and one for host rx). However, at the receiver side, I found that there is a chance (very little chance, less than 1% of the swaps) where swapping the buf_idx does not success. The receiver might get the packet in the buffer swapped out. For example, the netmap program wants to swap host slot *SH* with NIC slot *SN* in order to send the packet in *SH* from host to the receiver; the receiver might get the packet in *SN* instead. This usually happens to the very end of the available slots. Our experiment is done on *Linux* machine (Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux) with* intel NIC* (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection) using the *ixgbe* driver. To understand this problem, I look into the patch code to the ixgbe driver. I found that the flag NS_BUF_CHANGED is not used in the linux driver for ixgbe. please look the header file /LINUX/ixgbe_netmap_linux.h. In funtions ixgbe_netmap_txsync and ixgbe_netmap_rxsync, the function call netmap_reload_map is commented out. However, the ixgbe's driver patch for FreeBSD calls the reload function. So, I am wondering if this is a known problem when using netmap on LINUX. Has anybody found the same problem? Is netmap_reload_map required in Linux? why it is not called in the driver patch? What is the recommended solution for this problem? Thanks! Best, Xiaoye From owner-freebsd-net@freebsd.org Tue Jan 26 03:26:42 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50766A46338 for ; Tue, 26 Jan 2016 03:26:42 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id 3CAA49FC for ; Tue, 26 Jan 2016 03:26:42 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id 3BACD11621; Tue, 26 Jan 2016 03:26:42 +0000 (UTC) Date: Tue, 26 Jan 2016 03:26:42 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D5074+325+039f9366f641074c@reviews.freebsd.org Subject: [Differential] [Request, 136 lines] D5074: hyperv/hn: Improve sending performance Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D5074: hyperv/hn: Improve sending performance X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk Thread-Index: OTJkNGFhNzAyM2VjMmE0MjY4ZjllZTUzYmRk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_2f2d29c51593edd58ffa1ccd9e9d8153" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 03:26:42 -0000 --b1_2f2d29c51593edd58ffa1ccd9e9d8153 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit sepherosa_gmail.com created this revision. sepherosa_gmail.com added reviewers: network, adrian, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com. sepherosa_gmail.com added a subscriber: freebsd-net-list. REVISION SUMMARY - Avoid main lock contention by trylock for if_start, if that fails, schedule TX taskqueue for if_start - Don't do direct sending if the packet to be sent is large, e.g. TSO packet. This change gives me stable 9.1Gbps TCP sending performance w/ TSO over a 10Gbe directly connected network (the performance fluctuated between 4Gbps and 9Gbps before this commit). It also improves non-TSO TCP sending performance a lot. REVISION DETAIL https://reviews.freebsd.org/D5074 AFFECTED FILES sys/dev/hyperv/netvsc/hv_net_vsc.h sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com Cc: freebsd-net-list --b1_2f2d29c51593edd58ffa1ccd9e9d8153 Content-Type: text/x-patch; charset=utf-8; name="D5074.12702.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D5074.12702.patch" ZGlmZiAtLWdpdCBhL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2Qu YyBiL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2QuYwotLS0gYS9z eXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0dnNjX2Rydl9mcmVlYnNkLmMKKysrIGIvc3lzL2Rl di9oeXBlcnYvbmV0dnNjL2h2X25ldHZzY19kcnZfZnJlZWJzZC5jCkBAIC0xNDYsNiArMTQ2LDgg QEAKICNkZWZpbmUgSE5fVFhfREFUQV9TRUdDTlRfTUFYCQlcCiAgICAgKE5FVFZTQ19QQUNLRVRf TUFYUEFHRSAtIEhWX1JGX05VTV9UWF9SRVNFUlZFRF9QQUdFX0JVRlMpCiAKKyNkZWZpbmUgSE5f RElSRUNUX1RYX1NJWkVfREVGCQkxMjgKKwogc3RydWN0IGhuX3R4ZGVzYyB7CiAJU0xJU1RfRU5U UlkoaG5fdHhkZXNjKSBsaW5rOwogCXN0cnVjdCBtYnVmCSptOwpAQCAtMTk0LDYgKzE5Niw3IEBA CiAjZGVmaW5lIE5WX0xPQ0tfSU5JVChfc2MsIF9uYW1lKSBcCiAJICAgIG10eF9pbml0KCYoX3Nj KS0+aG5fbG9jaywgX25hbWUsIE1UWF9ORVRXT1JLX0xPQ0ssIE1UWF9ERUYpCiAjZGVmaW5lIE5W X0xPQ0soX3NjKQkJbXR4X2xvY2soJihfc2MpLT5obl9sb2NrKQorI2RlZmluZSBOVl9UUllMT0NL KF9zYykJCW10eF90cnlsb2NrKCYoX3NjKS0+aG5fbG9jaykKICNkZWZpbmUgTlZfTE9DS19BU1NF UlQoX3NjKQltdHhfYXNzZXJ0KCYoX3NjKS0+aG5fbG9jaywgTUFfT1dORUQpCiAjZGVmaW5lIE5W X1VOTE9DSyhfc2MpCQltdHhfdW5sb2NrKCYoX3NjKS0+aG5fbG9jaykKICNkZWZpbmUgTlZfTE9D S19ERVNUUk9ZKF9zYykJbXR4X2Rlc3Ryb3koJihfc2MpLT5obl9sb2NrKQpAQCAtMjE5LDE1ICsy MjIsMjAgQEAKIHN0YXRpYyBpbnQgaG5fdHhfY2hpbW5leV9zaXplID0gMDsKIFRVTkFCTEVfSU5U KCJkZXYuaG4udHhfY2hpbW5leV9zaXplIiwgJmhuX3R4X2NoaW1uZXlfc2l6ZSk7CiAKKy8qIExp bWl0IHRoZSBzaXplIG9mIHBhY2tldCBmb3IgZGlyZWN0IHRyYW5zbWlzc2lvbiAqLworc3RhdGlj IGludCBobl9kaXJlY3RfdHhfc2l6ZSA9IEhOX0RJUkVDVF9UWF9TSVpFX0RFRjsKK1RVTkFCTEVf SU5UKCJkZXYuaG4uZGlyZWN0X3R4X3NpemUiLCAmaG5fZGlyZWN0X3R4X3NpemUpOworCiAvKgog ICogRm9yd2FyZCBkZWNsYXJhdGlvbnMKICAqLwogc3RhdGljIHZvaWQgaG5fc3RvcChobl9zb2Z0 Y190ICpzYyk7CiBzdGF0aWMgdm9pZCBobl9pZmluaXRfbG9ja2VkKGhuX3NvZnRjX3QgKnNjKTsK IHN0YXRpYyB2b2lkIGhuX2lmaW5pdCh2b2lkICp4c2MpOwogc3RhdGljIGludCAgaG5faW9jdGwo c3RydWN0IGlmbmV0ICppZnAsIHVfbG9uZyBjbWQsIGNhZGRyX3QgZGF0YSk7Ci1zdGF0aWMgdm9p ZCBobl9zdGFydF9sb2NrZWQoc3RydWN0IGlmbmV0ICppZnApOworc3RhdGljIGludCBobl9zdGFy dF9sb2NrZWQoc3RydWN0IGlmbmV0ICppZnAsIGludCBsZW4pOwogc3RhdGljIHZvaWQgaG5fc3Rh cnQoc3RydWN0IGlmbmV0ICppZnApOworc3RhdGljIHZvaWQgaG5fc3RhcnRfdHhlb2Yoc3RydWN0 IGlmbmV0ICppZnApOwogc3RhdGljIGludCBobl9pZm1lZGlhX3VwZChzdHJ1Y3QgaWZuZXQgKmlm cCk7CiBzdGF0aWMgdm9pZCBobl9pZm1lZGlhX3N0cyhzdHJ1Y3QgaWZuZXQgKmlmcCwgc3RydWN0 IGlmbWVkaWFyZXEgKmlmbXIpOwogI2lmZGVmIEhOX0xST19ISVdBVApAQCAtMjM3LDYgKzI0NSw4 IEBACiBzdGF0aWMgaW50IGhuX2NoZWNrX2lwbGVuKGNvbnN0IHN0cnVjdCBtYnVmICosIGludCk7 CiBzdGF0aWMgaW50IGhuX2NyZWF0ZV90eF9yaW5nKHN0cnVjdCBobl9zb2Z0YyAqc2MpOwogc3Rh dGljIHZvaWQgaG5fZGVzdHJveV90eF9yaW5nKHN0cnVjdCBobl9zb2Z0YyAqc2MpOworc3RhdGlj IHZvaWQgaG5fc3RhcnRfdGFza2Z1bmModm9pZCAqeHNjLCBpbnQgcGVuZGluZyk7CitzdGF0aWMg dm9pZCBobl90eGVvZl90YXNrZnVuYyh2b2lkICp4c2MsIGludCBwZW5kaW5nKTsKIAogc3RhdGlj IF9faW5saW5lIHZvaWQKIGhuX3NldF9scm9faGl3YXQoc3RydWN0IGhuX3NvZnRjICpzYywgaW50 IGhpd2F0KQpAQCAtMzg0LDYgKzM5NCwxNCBAQAogCXNjLT5obl9kZXYgPSBkZXY7CiAJc2MtPmhu X2xyb19oaXdhdCA9IEhOX0xST19ISVdBVF9ERUY7CiAJc2MtPmhuX3RydXN0X2hvc3R0Y3AgPSBo bl90cnVzdF9ob3N0dGNwOworCXNjLT5obl9kaXJlY3RfdHhfc2l6ZSA9IGhuX2RpcmVjdF90eF9z aXplOworCisJc2MtPmhuX3R4X3Rhc2txID0gdGFza3F1ZXVlX2NyZWF0ZV9mYXN0KCJobl90eCIs IE1fV0FJVE9LLAorCSAgICB0YXNrcXVldWVfdGhyZWFkX2VucXVldWUsICZzYy0+aG5fdHhfdGFz a3EpOworCXRhc2txdWV1ZV9zdGFydF90aHJlYWRzKCZzYy0+aG5fdHhfdGFza3EsIDEsIFBJX05F VCwgIiVzIHR4IiwKKwkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChkZXYpKTsKKwlUQVNLX0lOSVQo JnNjLT5obl9zdGFydF90YXNrLCAwLCBobl9zdGFydF90YXNrZnVuYywgc2MpOworCVRBU0tfSU5J VCgmc2MtPmhuX3R4ZW9mX3Rhc2ssIDAsIGhuX3R4ZW9mX3Rhc2tmdW5jLCBzYyk7CiAKIAllcnJv ciA9IGhuX2NyZWF0ZV90eF9yaW5nKHNjKTsKIAlpZiAoZXJyb3IpCkBAIC01MjQsNiArNTQyLDkg QEAKIAlTWVNDVExfQUREX1BST0MoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJ0eF9jaGltbmV5X3Np emUiLAogCSAgICBDVExUWVBFX0lOVCB8IENUTEZMQUdfUlcsIHNjLCAwLCBobl90eF9jaGltbmV5 X3NpemVfc3lzY3RsLAogCSAgICAiSSIsICJDaGltbmV5IHNlbmQgcGFja2V0IHNpemUgbGltaXQi KTsKKwlTWVNDVExfQUREX0lOVChjdHgsIGNoaWxkLCBPSURfQVVUTywgImRpcmVjdF90eF9zaXpl IiwKKwkgICAgQ1RMRkxBR19SVywgJnNjLT5obl9kaXJlY3RfdHhfc2l6ZSwgMCwKKwkgICAgIlNp emUgb2YgdGhlIHBhY2tldCBmb3IgZGlyZWN0IHRyYW5zbWlzc2lvbiIpOwogCiAJaWYgKHVuaXQg PT0gMCkgewogCQlzdHJ1Y3Qgc3lzY3RsX2N0eF9saXN0ICpkY19jdHg7CkBAIC01NDgsNiArNTY5 LDkgQEAKIAkJU1lTQ1RMX0FERF9JTlQoZGNfY3R4LCBkY19jaGlsZCwgT0lEX0FVVE8sICJ0c29f bWF4bGVuIiwKIAkJICAgIENUTEZMQUdfUkQsICZobl90c29fbWF4bGVuLCAwLCAiVFNPIGJ1cnN0 IGxpbWl0Iik7CiAjZW5kaWYKKwkJU1lTQ1RMX0FERF9JTlQoZGNfY3R4LCBkY19jaGlsZCwgT0lE X0FVVE8sICJkaXJlY3RfdHhfc2l6ZSIsCisJCSAgICBDVExGTEFHX1JELCAmaG5fZGlyZWN0X3R4 X3NpemUsIDAsCisJCSAgICAiU2l6ZSBvZiB0aGUgcGFja2V0IGZvciBkaXJlY3QgdHJhbnNtaXNz aW9uIik7CiAJfQogCiAJcmV0dXJuICgwKTsKQEAgLTU4Myw2ICs2MDcsMTAgQEAKIAogCWh2X3Jm X29uX2RldmljZV9yZW1vdmUoaHZfZGV2aWNlLCBIVl9SRl9OVl9ERVNUUk9ZX0NIQU5ORUwpOwog CisJdGFza3F1ZXVlX2RyYWluKHNjLT5obl90eF90YXNrcSwgJnNjLT5obl9zdGFydF90YXNrKTsK Kwl0YXNrcXVldWVfZHJhaW4oc2MtPmhuX3R4X3Rhc2txLCAmc2MtPmhuX3R4ZW9mX3Rhc2spOwor CXRhc2txdWV1ZV9mcmVlKHNjLT5obl90eF90YXNrcSk7CisKIAlpZm1lZGlhX3JlbW92ZWFsbCgm c2MtPmhuX21lZGlhKTsKICNpZiBkZWZpbmVkKElORVQpIHx8IGRlZmluZWQoSU5FVDYpCiAJdGNw X2xyb19mcmVlKCZzYy0+aG5fbHJvKTsKQEAgLTczMywyNCArNzYxLDE5IEBACiBuZXR2c2NfY2hh bm5lbF9yb2xsdXAoc3RydWN0IGh2X2RldmljZSAqZGV2aWNlX2N0eCkKIHsKIAlzdHJ1Y3QgaG5f c29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfY3R4LT5kZXZpY2UpOwotCXN0cnVj dCBpZm5ldCAqaWZwOwogCiAJaWYgKCFzYy0+aG5fdHhlb2YpCiAJCXJldHVybjsKIAogCXNjLT5o bl90eGVvZiA9IDA7Ci0JaWZwID0gc2MtPmhuX2lmcDsKLQlOVl9MT0NLKHNjKTsKLQlpZnAtPmlm X2Rydl9mbGFncyAmPSB+SUZGX0RSVl9PQUNUSVZFOwotCWhuX3N0YXJ0X2xvY2tlZChpZnApOwot CU5WX1VOTE9DSyhzYyk7CisJaG5fc3RhcnRfdHhlb2Yoc2MtPmhuX2lmcCk7CiB9CiAKIC8qCiAg KiBTdGFydCBhIHRyYW5zbWl0IG9mIG9uZSBvciBtb3JlIHBhY2tldHMKICAqLwotc3RhdGljIHZv aWQKLWhuX3N0YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKmlmcCkKK3N0YXRpYyBpbnQKK2huX3N0 YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKmlmcCwgaW50IGxlbikKIHsKIAlobl9zb2Z0Y190ICpz YyA9IGlmcC0+aWZfc29mdGM7CiAJc3RydWN0IGh2X2RldmljZSAqZGV2aWNlX2N0eCA9IHZtYnVz X2dldF9kZXZjdHgoc2MtPmhuX2Rldik7CkBAIC03NjgsNyArNzkxLDcgQEAKIAogCWlmICgoaWZw LT5pZl9kcnZfZmxhZ3MgJiAoSUZGX0RSVl9SVU5OSU5HIHwgSUZGX0RSVl9PQUNUSVZFKSkgIT0K IAkgICAgSUZGX0RSVl9SVU5OSU5HKQotCQlyZXR1cm47CisJCXJldHVybiAwOwogCiAJd2hpbGUg KCFJRlFfRFJWX0lTX0VNUFRZKCZpZnAtPmlmX3NuZCkpIHsKIAkJYnVzX2RtYV9zZWdtZW50X3Qg c2Vnc1tITl9UWF9EQVRBX1NFR0NOVF9NQVhdOwpAQCAtNzgxLDExICs4MDQsMjEgQEAKIAkJaWYg KG1faGVhZCA9PSBOVUxMKQogCQkJYnJlYWs7CiAKKwkJaWYgKGxlbiA+IDAgJiYgbV9oZWFkLT5t X3BrdGhkci5sZW4gPiBsZW4pIHsKKwkJCS8qCisJCQkgKiBUaGlzIHNlbmRpbmcgY291bGQgYmUg dGltZSBjb25zdW1pbmc7IGxldCBjYWxsZXJzCisJCQkgKiBkaXNwYXRjaCB0aGlzIHBhY2tldCBz ZW5kaW5nIChhbmQgc2VuZGluZyBvZiBhbnkKKwkJCSAqIGZvbGxvd2luZyB1cCBwYWNrZXRzKSB0 byB0eCB0YXNrcXVldWUuCisJCQkgKi8KKwkJCUlGX1BSRVBFTkQoJmlmcC0+aWZfc25kLCBtX2hl YWQpOworCQkJcmV0dXJuIDE7CisJCX0KKwogCQl0eGQgPSBobl90eGRlc2NfZ2V0KHNjKTsKIAkJ aWYgKHR4ZCA9PSBOVUxMKSB7CiAJCQlzYy0+aG5fbm9fdHhkZXNjcysrOwogCQkJSUZfUFJFUEVO RCgmaWZwLT5pZl9zbmQsIG1faGVhZCk7Ci0JCQlpZnAtPmlmX2Rydl9mbGFncyB8PSBJRkZfRFJW X09BQ1RJVkU7CisJCQlhdG9taWNfc2V0X2ludCgmaWZwLT5pZl9kcnZfZmxhZ3MsIElGRl9EUlZf T0FDVElWRSk7CiAJCQlicmVhazsKIAkJfQogCkBAIC0xMDYwLDEwICsxMDkzLDExIEBACiAKIAkJ CXNjLT5obl9zZW5kX2ZhaWxlZCsrOwogCQkJSUZfUFJFUEVORCgmaWZwLT5pZl9zbmQsIG1faGVh ZCk7Ci0JCQlpZnAtPmlmX2Rydl9mbGFncyB8PSBJRkZfRFJWX09BQ1RJVkU7CisJCQlhdG9taWNf c2V0X2ludCgmaWZwLT5pZl9kcnZfZmxhZ3MsIElGRl9EUlZfT0FDVElWRSk7CiAJCQlicmVhazsK IAkJfQogCX0KKwlyZXR1cm4gMDsKIH0KIAogLyoKQEAgLTE1NTUsNyArMTU4OSw4IEBACiAJaWYg KGJvb3R2ZXJib3NlKQogCQlwcmludGYoIiBDbG9zaW5nIERldmljZSAuLi5cbiIpOwogCi0JaWZw LT5pZl9kcnZfZmxhZ3MgJj0gfihJRkZfRFJWX1JVTk5JTkcgfCBJRkZfRFJWX09BQ1RJVkUpOwor CWF0b21pY19jbGVhcl9pbnQoJmlmcC0+aWZfZHJ2X2ZsYWdzLAorCSAgICAoSUZGX0RSVl9SVU5O SU5HIHwgSUZGX0RSVl9PQUNUSVZFKSk7CiAJaWZfbGlua19zdGF0ZV9jaGFuZ2UoaWZwLCBMSU5L X1NUQVRFX0RPV04pOwogCXNjLT5obl9pbml0ZG9uZSA9IDA7CiAKQEAgLTE1NzEsMTMgKzE2MDYs NDMgQEAKIAlobl9zb2Z0Y190ICpzYzsKIAogCXNjID0gaWZwLT5pZl9zb2Z0YzsKLQlOVl9MT0NL KHNjKTsKLQlpZiAoc2MtPnRlbXBfdW51c2FibGUpIHsKKwlpZiAoTlZfVFJZTE9DSyhzYykpIHsK KwkJaW50IHNjaGVkOworCisJCXNjaGVkID0gaG5fc3RhcnRfbG9ja2VkKGlmcCwgc2MtPmhuX2Rp cmVjdF90eF9zaXplKTsKIAkJTlZfVU5MT0NLKHNjKTsKLQkJcmV0dXJuOworCQlpZiAoIXNjaGVk KQorCQkJcmV0dXJuOworCX0KKwl0YXNrcXVldWVfZW5xdWV1ZV9mYXN0KHNjLT5obl90eF90YXNr cSwgJnNjLT5obl9zdGFydF90YXNrKTsKK30KKworc3RhdGljIHZvaWQKK2huX3N0YXJ0X3R4ZW9m KHN0cnVjdCBpZm5ldCAqaWZwKQoreworCWhuX3NvZnRjX3QgKnNjOworCisJc2MgPSBpZnAtPmlm X3NvZnRjOworCWlmIChOVl9UUllMT0NLKHNjKSkgeworCQlpbnQgc2NoZWQ7CisKKwkJYXRvbWlj X2NsZWFyX2ludCgmaWZwLT5pZl9kcnZfZmxhZ3MsIElGRl9EUlZfT0FDVElWRSk7CisJCXNjaGVk ID0gaG5fc3RhcnRfbG9ja2VkKGlmcCwgc2MtPmhuX2RpcmVjdF90eF9zaXplKTsKKwkJTlZfVU5M T0NLKHNjKTsKKwkJaWYgKHNjaGVkKSB7CisJCQl0YXNrcXVldWVfZW5xdWV1ZV9mYXN0KHNjLT5o bl90eF90YXNrcSwKKwkJCSAgICAmc2MtPmhuX3N0YXJ0X3Rhc2spOworCQl9CisJfSBlbHNlIHsK KwkJLyoKKwkJICogUmVsZWFzZSB0aGUgT0FDVElWRSBlYXJsaWVyLCB3aXRoIHRoZSBob3BlLCB0 aGF0CisJCSAqIG90aGVycyBjb3VsZCBjYXRjaCB1cC4gIFRoZSB0YXNrIHdpbGwgY2xlYXIgdGhl CisJCSAqIGZsYWcgYWdhaW4gd2l0aCB0aGUgTlZfTE9DSyB0byBhdm9pZCBwb3NzaWJsZQorCQkg KiByYWNlcy4KKwkJICovCisJCWF0b21pY19jbGVhcl9pbnQoJmlmcC0+aWZfZHJ2X2ZsYWdzLCBJ RkZfRFJWX09BQ1RJVkUpOworCQl0YXNrcXVldWVfZW5xdWV1ZV9mYXN0KHNjLT5obl90eF90YXNr cSwgJnNjLT5obl90eGVvZl90YXNrKTsKIAl9Ci0JaG5fc3RhcnRfbG9ja2VkKGlmcCk7Ci0JTlZf VU5MT0NLKHNjKTsKIH0KIAogLyoKQEAgLTE2MDQsOCArMTY2OSw4IEBACiAJfSBlbHNlIHsKIAkJ c2MtPmhuX2luaXRkb25lID0gMTsKIAl9Ci0JaWZwLT5pZl9kcnZfZmxhZ3MgfD0gSUZGX0RSVl9S VU5OSU5HOwotCWlmcC0+aWZfZHJ2X2ZsYWdzICY9IH5JRkZfRFJWX09BQ1RJVkU7CisJYXRvbWlj X2NsZWFyX2ludCgmaWZwLT5pZl9kcnZfZmxhZ3MsIElGRl9EUlZfT0FDVElWRSk7CisJYXRvbWlj X3NldF9pbnQoJmlmcC0+aWZfZHJ2X2ZsYWdzLCBJRkZfRFJWX1JVTk5JTkcpOwogCWlmX2xpbmtf c3RhdGVfY2hhbmdlKGlmcCwgTElOS19TVEFURV9VUCk7CiB9CiAKQEAgLTE5MDcsNiArMTk3Miwy OCBAQAogCW10eF9kZXN0cm95KCZzYy0+aG5fdHhsaXN0X3NwaW4pOwogfQogCitzdGF0aWMgdm9p ZAoraG5fc3RhcnRfdGFza2Z1bmModm9pZCAqeHNjLCBpbnQgcGVuZGluZyBfX3VudXNlZCkKK3sK KwlzdHJ1Y3QgaG5fc29mdGMgKnNjID0geHNjOworCisJTlZfTE9DSyhzYyk7CisJaG5fc3RhcnRf bG9ja2VkKHNjLT5obl9pZnAsIDApOworCU5WX1VOTE9DSyhzYyk7Cit9CisKK3N0YXRpYyB2b2lk Citobl90eGVvZl90YXNrZnVuYyh2b2lkICp4c2MsIGludCBwZW5kaW5nIF9fdW51c2VkKQorewor CXN0cnVjdCBobl9zb2Z0YyAqc2MgPSB4c2M7CisJc3RydWN0IGlmbmV0ICppZnAgPSBzYy0+aG5f aWZwOworCisJTlZfTE9DSyhzYyk7CisJYXRvbWljX2NsZWFyX2ludCgmaWZwLT5pZl9kcnZfZmxh Z3MsIElGRl9EUlZfT0FDVElWRSk7CisJaG5fc3RhcnRfbG9ja2VkKGlmcCwgMCk7CisJTlZfVU5M T0NLKHNjKTsKK30KKwogc3RhdGljIGRldmljZV9tZXRob2RfdCBuZXR2c2NfbWV0aG9kc1tdID0g ewogICAgICAgICAvKiBEZXZpY2UgaW50ZXJmYWNlICovCiAgICAgICAgIERFVk1FVEhPRChkZXZp Y2VfcHJvYmUsICAgICAgICAgbmV0dnNjX3Byb2JlKSwKZGlmZiAtLWdpdCBhL3N5cy9kZXYvaHlw ZXJ2L25ldHZzYy9odl9uZXRfdnNjLmggYi9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0X3Zz Yy5oCi0tLSBhL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXRfdnNjLmgKKysrIGIvc3lzL2Rl di9oeXBlcnYvbmV0dnNjL2h2X25ldF92c2MuaApAQCAtMzksOSArMzksMTEgQEAKICNkZWZpbmUg X19IVl9ORVRfVlNDX0hfXwogCiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lz L2tlcm5lbC5oPgogI2luY2x1ZGUgPHN5cy9sb2NrLmg+CiAjaW5jbHVkZSA8c3lzL21hbGxvYy5o PgogI2luY2x1ZGUgPHN5cy9xdWV1ZS5oPgorI2luY2x1ZGUgPHN5cy90YXNrcXVldWUuaD4KICNp bmNsdWRlIDxzeXMvc3guaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CkBAIC0xMDA4LDE4 ICsxMDEwLDIzIEBACiAJc3RydWN0IGh2X2RldmljZSAgKmhuX2Rldl9vYmo7CiAJbmV0dnNjX2Rl diAgCSpuZXRfZGV2OwogCi0JaW50CQlobl90eGRlc2NfY250OwogCXN0cnVjdCBobl90eGRlc2Mg KmhuX3R4ZGVzYzsKIAlidXNfZG1hX3RhZ190CWhuX3R4X2RhdGFfZHRhZzsKIAlidXNfZG1hX3Rh Z190CWhuX3R4X3JuZGlzX2R0YWc7CiAJaW50CQlobl90eF9jaGltbmV5X3NpemU7CiAJaW50CQlo bl90eF9jaGltbmV5X21heDsKIAogCXN0cnVjdCBtdHgJaG5fdHhsaXN0X3NwaW47CiAJc3RydWN0 IGhuX3R4ZGVzY19saXN0IGhuX3R4bGlzdDsKKwlpbnQJCWhuX3R4ZGVzY19jbnQ7CiAJaW50CQlo bl90eGRlc2NfYXZhaWw7CiAJaW50CQlobl90eGVvZjsKIAorCWludAkJaG5fZGlyZWN0X3R4X3Np emU7CisJc3RydWN0IHRhc2txdWV1ZSAqaG5fdHhfdGFza3E7CisJc3RydWN0IHRhc2sJaG5fc3Rh cnRfdGFzazsKKwlzdHJ1Y3QgdGFzawlobl90eGVvZl90YXNrOworCiAJc3RydWN0IGxyb19jdHJs CWhuX2xybzsKIAlpbnQJCWhuX2xyb19oaXdhdDsKIAoK --b1_2f2d29c51593edd58ffa1ccd9e9d8153-- From owner-freebsd-net@freebsd.org Tue Jan 26 07:53:12 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4122EA6E62C for ; Tue, 26 Jan 2016 07:53:12 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E85CEF3 for ; Tue, 26 Jan 2016 07:53:12 +0000 (UTC) (envelope-from pavel.odintsov@gmail.com) Received: by mail-ig0-x229.google.com with SMTP id t15so53401676igr.0 for ; Mon, 25 Jan 2016 23:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QB1rYhq0tepcKbRIMRJBcSZ8aQtFq6r8HQj6C2sEJYA=; b=0OtmEDTHe0wa7X8sZO2i5SFi6Aoz7hjNg95CnNB4H3+7pvVVATz928oxO6jx8+d65n TqyLHqw0w1MWj32xh4td9pZ8lxhLsCp6+DHIFeulScGYX/fOqW7lzjo+tb6WMP+mTdLs bDaZUNlJWFb1AvX1wVfSR7Hpda6F+B7LuNhp07bWLrgFsPuwhaYfMAQJYkI0nZFhrtjw zmSvxcatK2ekxvAR1a1Zpq5bIR+uNcFVUWHOgmBk1hH839GD2agmexbiYHpcduH0/W3W sJC0euFOj7Gdh5LD/kIoFmvO8IHh18jEZVBWe+0O7U3EfYcgodQ+LxrmMEqINfjMsByI yAmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QB1rYhq0tepcKbRIMRJBcSZ8aQtFq6r8HQj6C2sEJYA=; b=TCqQcbw8I6Gvw/wqD7pb3f1mu6a7Ql5JP5UTqZq2ELtdWeaDvo25SziBEbX/TrTI/Z y4PSxal/Oc4ditCmM9qlmjwRQwsXnlJ9uSo9+h40RRYaoUE9AxxKy64Q1PRHeDi+BSKZ 5g9COCe9xlflvVujIofosU8F3POmUZV+IRQ+nxCHtmvDkrjGNxJJHzf5eJZAWzw4h2QH oxpq/TSOTdgHrP63kOpt50h50G0Q42L/ZKtNxQVhVczh0XPlj60wGBMR93FELVviWH5q lI6NiYWr5MmTuDctEetOtdGgMUn77fTTgEhrcABemV77wCQsmbnZaG4wggMakoLTrQOf 1rdA== X-Gm-Message-State: AG10YOTVhoUKff8ytEHuYDWLidndFeRJcABNpzdA13xPKX+sSYtIdPwBIYnjAGXiWYJnIDLKcwDi+c9APifF3g== MIME-Version: 1.0 X-Received: by 10.50.143.10 with SMTP id sa10mr22556453igb.91.1453794791419; Mon, 25 Jan 2016 23:53:11 -0800 (PST) Received: by 10.79.36.20 with HTTP; Mon, 25 Jan 2016 23:53:11 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Jan 2016 10:53:11 +0300 Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Pavel Odintsov To: Xiaoye Sun Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 07:53:12 -0000 Hello! Really useful and detailed research. Thanks a lot! Could you share your validation code? It could be useful for consistency tests for netmap. So I could not help with your original question. Let's wait answer from developers of awesome Netmap :) On Tue, Jan 26, 2016 at 2:55 AM, Xiaoye Sun wrote: > Hi all, > > I wrote a netmap application that is very similar to bridge.c in master/example > directory of the netmap code. The major difference between my program and > bridge.c is that my application also creates custom packets that are > directly put into the tx ring of the NIC (like a packet generator with > NIC-Host packet forwarding). Each generated packet has an unique sequence > number so that the receiver can tell if a packet is lost. > > Like bridge.c, the packet forwarding between the nic and the host uses > 'zerocopy', so that the program only swaps the buf_idx of the slots to > virtually forward the packet to the other end. NS_BUF_CHANGED is set for > the slots (both rx and tx) whose buf_idx has been changed due to zerocopy. > > I set the number of rings on nic to 1 using the ethtool command, i.e., one > pair of netmap rings for the nic (one for host tx and one for host rx) and > another pair of rings for the host (one for host tx and one for host rx). > > However, at the receiver side, I found that there is a chance (very little > chance, less than 1% of the swaps) where swapping the buf_idx does not > success. The receiver might get the packet in the buffer swapped out. For > example, the netmap program wants to swap host slot *SH* with NIC slot *SN* > in order to send the packet in *SH* from host to the receiver; the receiver > might get the packet in *SN* instead. This usually happens to the very end > of the available slots. > > Our experiment is done on *Linux* machine (Linux 3.16.0-4-amd64 #1 SMP > Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux) with* intel NIC* > (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection) using > the *ixgbe* driver. > > To understand this problem, I look into the patch code to the ixgbe driver. > I found that the flag NS_BUF_CHANGED is not used in the linux driver for > ixgbe. please look the header file /LINUX/ixgbe_netmap_linux.h. In funtions > ixgbe_netmap_txsync and ixgbe_netmap_rxsync, the function call > netmap_reload_map is commented out. However, the ixgbe's driver patch for > FreeBSD calls the reload function. > > So, I am wondering if this is a known problem when using netmap on LINUX. > Has anybody found the same problem? > Is netmap_reload_map required in Linux? why it is not called in the driver > patch? > What is the recommended solution for this problem? > > Thanks! > > Best, > Xiaoye > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Sincerely yours, Pavel Odintsov From owner-freebsd-net@freebsd.org Tue Jan 26 08:01:13 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC4C1A6EADE for ; Tue, 26 Jan 2016 08:01:13 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35BA93F4 for ; Tue, 26 Jan 2016 08:01:13 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lb0-x230.google.com with SMTP id x4so88052890lbm.0 for ; Tue, 26 Jan 2016 00:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VNP0KfEF+F6XWJS/jdQVSMllKGxOZFqAZ03M5IFpmoY=; b=Vp8V7p4f7BTTrknOsp3WptjTZbtzQbhqaZvr6uhQZ/CR60fwH5x1YHTdPVe9QgwXb5 py0IGWhjZcbsJCCgTz/5Tv6fJrSmtIaMYnhqutoFY8yYmknWfBu7LbV3WKc5Bf4Datx5 MUMST9E64YHbVy1BjLHdtxhlF/88KG3RKzCRXDtSbDoJ4oepHEFWmsHnaj2O7/TDxPk2 fq5jOXfVSfEr7H2LYelg47/oDyW6U1algOSl9HtXdgIu1kSxS+7o+FZy1VwFPhUR+9fh nkoF0wQn/1Ddd6PNvpthXfJvsMsHFnF1pgXNI7lws/FudUutlSYQpuGKUorX9on68W1r zezw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VNP0KfEF+F6XWJS/jdQVSMllKGxOZFqAZ03M5IFpmoY=; b=KaqTQU1TyTt/Y61C5OvBGXBjEUd+Ranr00dLZy1jORN4Nos51R+9NQyB5aBR1ED3M7 WZ6EfTanuCnVJyO2VJyrSWTD4ty0lXElBp7mkkmPuB9Ds7DaN9HhGQslQXHSwhKbsGrN 1c6qZAlel6liYcCwBo1Nqp7FaH2/LQP2gXtUgoWMxy+++GBTvxd9x9Y8T8pJj+JMWwLA vnaAobw/f9YjRrG3I6R81ORJdbQcCgEC20ZO7UGV1ojzMg5vrMS67adKZk2Ng/xCp5L9 NzzqBRGborp0AW7+seCOjt09gTObvdFbubxKU+5lebx0dEjuTAtjNwIf127t0tEdOOOV UXfA== X-Gm-Message-State: AG10YOQIr4JuTBOY6J9Xt5jTjAvQuHFWCligs9QG5ONx/BnXQbJfrVbWh3qh9KPmTWvQdZZ0cL6fXFEv8Btgyw== MIME-Version: 1.0 X-Received: by 10.112.170.101 with SMTP id al5mr7994605lbc.92.1453795271127; Tue, 26 Jan 2016 00:01:11 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Tue, 26 Jan 2016 00:01:11 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Jan 2016 00:01:11 -0800 X-Google-Sender-Auth: sxghxxZuvlXf3UTYJFdN9dgl6vM Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Luigi Rizzo To: Xiaoye Sun Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 08:01:13 -0000 Hi, in FreeBSD, netmap_reload_map() is basically a NOP unless the NIC uses bounce buffers (in which case it is pointless to use netmap, and I am not even sure the code works), or there is an iommu which may need to be reprogrammed (but in that case you don't want to do it dynamically on individual buffers, but once for all when the device is opened.) This said, can you check that the iommu is disabled in the bios and re-run the test ? This said I am not sure that the problem is the iommu -- a wrong entry should result in bogus content, certainly not the one before the swap. I suspect some kind of race, possibly missing memory barriers. cheers luigi On Mon, Jan 25, 2016 at 3:55 PM, Xiaoye Sun wrote: > Hi all, > > I wrote a netmap application that is very similar to bridge.c in master/example > directory of the netmap code. The major difference between my program and > bridge.c is that my application also creates custom packets that are > directly put into the tx ring of the NIC (like a packet generator with > NIC-Host packet forwarding). Each generated packet has an unique sequence > number so that the receiver can tell if a packet is lost. > > Like bridge.c, the packet forwarding between the nic and the host uses > 'zerocopy', so that the program only swaps the buf_idx of the slots to > virtually forward the packet to the other end. NS_BUF_CHANGED is set for > the slots (both rx and tx) whose buf_idx has been changed due to zerocopy. > > I set the number of rings on nic to 1 using the ethtool command, i.e., one > pair of netmap rings for the nic (one for host tx and one for host rx) and > another pair of rings for the host (one for host tx and one for host rx). > > However, at the receiver side, I found that there is a chance (very little > chance, less than 1% of the swaps) where swapping the buf_idx does not > success. The receiver might get the packet in the buffer swapped out. For > example, the netmap program wants to swap host slot *SH* with NIC slot *SN* > in order to send the packet in *SH* from host to the receiver; the receiver > might get the packet in *SN* instead. This usually happens to the very end > of the available slots. > > Our experiment is done on *Linux* machine (Linux 3.16.0-4-amd64 #1 SMP > Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux) with* intel NIC* > (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection) using > the *ixgbe* driver. > > To understand this problem, I look into the patch code to the ixgbe driver. > I found that the flag NS_BUF_CHANGED is not used in the linux driver for > ixgbe. please look the header file /LINUX/ixgbe_netmap_linux.h. In funtions > ixgbe_netmap_txsync and ixgbe_netmap_rxsync, the function call > netmap_reload_map is commented out. However, the ixgbe's driver patch for > FreeBSD calls the reload function. > > So, I am wondering if this is a known problem when using netmap on LINUX. > Has anybody found the same problem? > Is netmap_reload_map required in Linux? why it is not called in the driver > patch? > What is the recommended solution for this problem? > > Thanks! > > Best, > Xiaoye > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Tue Jan 26 13:40:12 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76201A46CC3 for ; Tue, 26 Jan 2016 13:40:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2EF116A for ; Tue, 26 Jan 2016 13:40:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5BF96A46CC1; Tue, 26 Jan 2016 13:40:12 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A80DA46CC0; Tue, 26 Jan 2016 13:40:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAB131169; Tue, 26 Jan 2016 13:40:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0QDe65E082213 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Jan 2016 15:40:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0QDe65E082213 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0QDe5Y8082210; Tue, 26 Jan 2016 15:40:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 26 Jan 2016 15:40:05 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: gljennjohn@gmail.com, threads@freebsd.org, Bruce Evans , net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160126134005.GD3942@kib.kiev.ua> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 13:40:12 -0000 On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: > +ssize_t > +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, > + const struct timespec *__restrict timeout) > +{ > + size_t i, rcvd; > + ssize_t ret; > + > + if (timeout != NULL) { > + fd_set fds; > + int res; Please move all local definitions to the beginning of the function. > + > + FD_ZERO(&fds); > + FD_SET(s, &fds); > + res = __sys_pselect(s + 1, &fds, NULL, NULL, timeout, NULL); So why is this __sys_pselect() and not pselect() ? Note that ppoll() is immune to the issue of s > FD_SETSIZE. > + if (res == -1 || res == 0) > + return (res); > + if (!FD_ISSET(s, &fds)) > + return (-1); > + } > + > + ret = __sys_recvmsg(s, &msgvec[0].msg_hdr, flags); > + if (ret == -1) > + return (ret); > + > + /* Check initially for the presence of MSG_WAITFORONE. > + * Turn on MSG_DONTWAIT if set. */ The style-conformant multi-line comment is /* * Text. * More text. */ > + if (flags & MSG_WAITFORONE) { > + flags |= MSG_DONTWAIT; > + /* The kernel doesn't need to know about this flag. */ > + flags &= ~MSG_WAITFORONE; You clear MSG_WAITFORONE flag in the calls to recvmsg(), but not at the first recvmsg() incantation. I think the flag should be just kept alone. > + } > + > + rcvd = 1; > + for (i = rcvd; i < vlen; i++, rcvd++) { > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > + if (ret == -1) { > + /* We have received messages. Let caller know. */ > + return (rcvd); > + } > + > + /* Save received bytes */ > + msgvec[i].msg_len = ret; > + } > + > + return (rcvd); > +} > diff --git a/sys/sys/socket.h b/sys/sys/socket.h > index 18e2de1..c7a21cc 100644 > --- a/sys/sys/socket.h > +++ b/sys/sys/socket.h > @@ -431,6 +431,9 @@ struct msghdr { > #define MSG_NBIO 0x4000 /* FIONBIO mode, used by fifofs */ > #define MSG_COMPAT 0x8000 /* used in sendit() */ > #define MSG_CMSG_CLOEXEC 0x40000 /* make received fds close-on-exec */ > +#ifndef _KERNEL Why is the !KERNEL protection for the definition needed ? > +#define MSG_WAITFORONE 0x80000 /* for recvmmsg() */ > +#endif /* !_KERNEL */ > #endif > #ifdef _KERNEL > #define MSG_SOCALLBCK 0x10000 /* for use by socket callbacks - soreceive (TCP) */ > @@ -595,6 +598,18 @@ struct sf_hdtr { > #endif /* _KERNEL */ > #endif /* __BSD_VISIBLE */ > > +#ifndef _KERNEL Why is the !KERNEL protection for the definition needed ? > +#ifdef __BSD_VISIBLE > +/* > + * Send/recvmmsg specific structure(s) > + */ > +struct mmsghdr { > + struct msghdr msg_hdr; /* message header */ > + ssize_t msg_len; /* message length */ > +}; > +#endif /* __BSD_VISIBLE */ > +#endif /* !_KERNEL */ > + > #ifndef _KERNEL > > #include > @@ -615,11 +630,19 @@ int listen(int, int); > ssize_t recv(int, void *, size_t, int); > ssize_t recvfrom(int, void *, size_t, int, struct sockaddr * __restrict, socklen_t * __restrict); > ssize_t recvmsg(int, struct msghdr *, int); > +#if __BSD_VISIBLE > +struct timespec; > +ssize_t recvmmsg(int, struct mmsghdr * __restrict, size_t, int, > + const struct timespec * __restrict); > +#endif > ssize_t send(int, const void *, size_t, int); > ssize_t sendto(int, const void *, > size_t, int, const struct sockaddr *, socklen_t); > ssize_t sendmsg(int, const struct msghdr *, int); > #if __BSD_VISIBLE > +ssize_t sendmmsg(int, struct mmsghdr * __restrict, size_t, int); > +#endif > +#if __BSD_VISIBLE Again, there is no use in closing __BSD_VISIBLE block only to open it again on the next line. > int sendfile(int, int, off_t, size_t, struct sf_hdtr *, off_t *, int); > int setfib(int); > #endif From owner-freebsd-net@freebsd.org Tue Jan 26 17:06:42 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4969CA46284 for ; Tue, 26 Jan 2016 17:06:42 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 286A2E4B for ; Tue, 26 Jan 2016 17:06:42 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2469FA46281; Tue, 26 Jan 2016 17:06:42 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09EEDA4627F; Tue, 26 Jan 2016 17:06:42 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 836B8E4A; Tue, 26 Jan 2016 17:06:41 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22e.google.com with SMTP id 17so109370043lfz.1; Tue, 26 Jan 2016 09:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=T7mn27yqF1atfSp+7ckzRpZa1zBwI1gOyutZKeWlmxM=; b=q2EMl8waQS58+2uOklBQUv/pPLsmiv/ND6egaeORCqxZpWDgI4FzI62D3SlNh3l/Jy JVNrfq2KloZ4McIOAG7JzD+SMsEjwO79rA8BtErUlrfvSjkOdpcxVuDLUZYpxzNwlvZ1 MfEvZadIiO1BKzPvJdqD0QKuZIcMm3ovPARY/0lxJvc1avhoxIpYqx6rKpm32eMHKfMb gB/2CHzp8dJlQ5ZwU+K+KPLx7koipm2pFFDBgvpLPHhYMfumE+n46WZTMP98cEF03Q5P GRVNLOF9/wCtWM/1QrDHccVA5BWZ1jvhOUx0tDQaIj6buUTrviY7k+L8EkJW4mO/dewc mPYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T7mn27yqF1atfSp+7ckzRpZa1zBwI1gOyutZKeWlmxM=; b=kUonTYDVpi5CYCSRd9osfXX7rXbCcPoYxykrTf1Fn6o/AvmU7IaMHltKtLr/q5cVjG 72MJ6AUt+z1N/+XXFsq0oblr3SfTydqNV4LaJ2J8WgQ8TvJaySovtwjNYmynL7HgTvoZ tIQqYvA8cnJkSW6RmGegbtT8cegi/b36vbRd76wpz3LxNhxSRq7mreNLEub002nliJi1 rX+2qsAp7+KWeSVGecE1J/ID/OOAZX3VfWvjI5BipoJh1kYLPIQSM1bxOSJC1zLixitq XlcjyvkR6uG+doPWUkSw+KT8uGKLtu+wZzw/jpMOij5j7lhavg0DYTn7hiAhsXnLiz/s 0DtA== X-Gm-Message-State: AG10YOQswa6q9quMRmrPqqWENeML38KIKViD2gR/0R+wYLFBwZgeYevcDGJ0l3vJbw3AI7sEvRYaZZMFqJ4ngQ== MIME-Version: 1.0 X-Received: by 10.25.209.138 with SMTP id i132mr9091992lfg.4.1453827999702; Tue, 26 Jan 2016 09:06:39 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Tue, 26 Jan 2016 09:06:39 -0800 (PST) In-Reply-To: <20160126134005.GD3942@kib.kiev.ua> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> Date: Tue, 26 Jan 2016 09:06:39 -0800 X-Google-Sender-Auth: Sd4U1kUTBPHiWaXKnzx4nXOeCtk Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: Konstantin Belousov Cc: Boris Astardzhiev , threads@freebsd.org, gljennjohn@gmail.com, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:06:42 -0000 On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov wrote: > On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >> +ssize_t >> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >> + const struct timespec *__restrict timeout) >> +{ >> + size_t i, rcvd; >> + ssize_t ret; >> + >> + if (timeout != NULL) { >> + fd_set fds; >> + int res; > Please move all local definitions to the beginning of the function. This style recommendation was from 30 years ago and is bad programming practice, as it tends to complicate analysis for the human and increase the chance of improper usage of variables. We should move away from this for new code. cheers luigi From owner-freebsd-net@freebsd.org Tue Jan 26 17:25:49 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49925A46DA5 for ; Tue, 26 Jan 2016 17:25:49 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 252671ACC for ; Tue, 26 Jan 2016 17:25:49 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 23E1AA46DA2; Tue, 26 Jan 2016 17:25:49 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 098C7A46DA1; Tue, 26 Jan 2016 17:25:49 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91D251AC6; Tue, 26 Jan 2016 17:25:48 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id b14so142511573wmb.1; Tue, 26 Jan 2016 09:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=8XIw2Nll9Ro6yeMO3HrnJVLdR/wuR5XxJEjlFlClc0I=; b=oi+IQZr3W9GlbszJVZ7+MX8Wsz5ZtU5FiMtZxDfhioTKqG8p3lWmwQz/ra5UFx7aT7 DucMBem1qSODsde0nZ8vjUEKJ6c/kLyLbjpL7AbOPTodWXFPR3JIFUKdaqwQHQt4Jdvw rdtwG6BrfgsPh7XzWGmZ0qt0LkXvxSFwggswbK1uKMjQgtIlSCLDLFmQruU0Zw8sYOOz K6LuLakCwL7o8tlNzclYZayYxO2c+XVr2KotUh5QYwKZZGWH2U36wcvLb3NL/4GqdJNt UBxbLmGvj2hixVQ4xKfeFtcTxNpPyAYKJ5uEMPA/N/96Jlj63UiRAXIVaIzxYqiAU6KG BAVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-type :content-transfer-encoding; bh=8XIw2Nll9Ro6yeMO3HrnJVLdR/wuR5XxJEjlFlClc0I=; b=P4JQNnYgPCBnBnoxdWcDP+UADVwspUkDCLiYwapdWxKKpxOERHtuwHwzIY1Jintpva CMKNMlyPhSCeWRL67c8dJdjsG3uyQO5+vXVxTQRXRBImXz7QvZDTW3xwU3Fg1zQGbmdC xj+Afrwn3IVUPdSaq7MzGC8O51yji69JdidzL2aD63H2io3bqq8E2i9aIVZQozTLLtsg xX8hUgJ9ogxiGYvHOR0zse8WRWwnS/Kt1z303irZoYkDZXHeFeZ7FClGAE1XDg4ZiaKf U7PdopkXPPPganVMvenG7Zd5Qw9rTPHRUkIfV4wSYElYQWKVq8KL3ZTjPpwfo1KlPSaJ oRKg== X-Gm-Message-State: AG10YOTDDKZQ57UzBXs+OvpBkLcQHUcgeehm2xqxkFn1JMxEvdkjTywpRrp/w72gBNaTZg== X-Received: by 10.194.95.34 with SMTP id dh2mr23779246wjb.63.1453829147025; Tue, 26 Jan 2016 09:25:47 -0800 (PST) Received: from ernst.home (p4FCA7371.dip0.t-ipconnect.de. [79.202.115.113]) by smtp.gmail.com with ESMTPSA id js8sm2351923wjc.37.2016.01.26.09.25.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jan 2016 09:25:45 -0800 (PST) Date: Tue, 26 Jan 2016 18:25:43 +0100 From: Gary Jennejohn To: Luigi Rizzo Cc: Konstantin Belousov , Boris Astardzhiev , threads@freebsd.org, "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160126182543.64050678@ernst.home> In-Reply-To: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:25:49 -0000 On Tue, 26 Jan 2016 09:06:39 -0800 Luigi Rizzo wrote: > On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov > wrote: > > On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: > >> +ssize_t > >> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, > >> + const struct timespec *__restrict timeout) > >> +{ > >> + size_t i, rcvd; > >> + ssize_t ret; > >> + > >> + if (timeout != NULL) { > >> + fd_set fds; > >> + int res; > > Please move all local definitions to the beginning of the function. > > This style recommendation was from 30 years ago and is > bad programming practice, as it tends to complicate analysis > for the human and increase the chance of improper usage of > variables. > > We should move away from this for new code. > Really? I personally find having all variables grouped together much easier to understand. Stumbling across declarations in the middle of the code in a for-loop, for example, takes me by surprise. I also greatly dislike initializing variables in their declarations. Maybe I'm just old fashioned since I have been writing C-code for more than 30 years. -- Gary Jennejohn From owner-freebsd-net@freebsd.org Tue Jan 26 18:14:26 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9805AA4608A for ; Tue, 26 Jan 2016 18:14:26 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 75DA215F5 for ; Tue, 26 Jan 2016 18:14:26 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 70F4BA46087; Tue, 26 Jan 2016 18:14:26 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70606A46083; Tue, 26 Jan 2016 18:14:26 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9D2E15F3; Tue, 26 Jan 2016 18:14:25 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id h129so111622398lfh.3; Tue, 26 Jan 2016 10:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hTvcC4x4nkGZQkTbFcNmtsBXR1OfB93MFgFMljHxXKU=; b=t3iYSgh47O+EvP8w7zQrJFwm9b1vHBgUA4BEBjezASflmuVSJI6gBd275zmwVThcoj KhZN7Z2xnnTtdTMG79cH4A6IDGfdpfCm9FxZpr3ZdYUIX0HTlSrEXp8+zFwugK32p545 hOylvtpuHa5aXw50JzGiDoDjATmbjWD/OVUjW0XukSAO+4kAuotFlvSOxEAhHD8eda2d JigciaZfEWTt+bAMB6oAGINUF7rUsfBlNT7/o/5QQ6fulH3YnOUd64SP2+q62SQVL/SJ 36Y3y8l1A8kCbOTQOwGXA1p0dfqnZs7Gkdt+zviQiD6ACrbihcWMy8AMc7JIsIBp5w5o ydaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hTvcC4x4nkGZQkTbFcNmtsBXR1OfB93MFgFMljHxXKU=; b=jkshdC8l7KjNAJpK0ZyaA7Z4UmjipdpcteE4/2KC7wOU5GgoV4ErhwJfEva5jq8buB psP1ZAdBdBVOlF8izSsQ43ry7O7X/XENTNqKkdss3WxSEXIAP4cYfOcnRaKwJ3lRwWZz Nbv+03AgET9eUxv+MPkwS8a8IcC7puj9dilylo9onUqznerMOFTNL9B/3FRjQyQrJjLR kXCcWDEtqD9SWCUnPibXFbCRcffSmC7zimKh1n4pzZp8bGldYYgapKlepjf8IjDpzy/a tp/KRhWYHmm8GUxcr9OWvQ0X9T1vaLH4CNXTK2FL/+XLs0xa8D3bdxciOhnASNm3X7HY NiOw== X-Gm-Message-State: AG10YORxKQagliDE4PVmiFK/07dZohlRJ2egC10+fTO7SKAZgknBlZ3qTHekpuLF+lbMVizBd26xAnvOu3MPrg== MIME-Version: 1.0 X-Received: by 10.25.158.136 with SMTP id h130mr9138909lfe.136.1453832063990; Tue, 26 Jan 2016 10:14:23 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Tue, 26 Jan 2016 10:14:23 -0800 (PST) In-Reply-To: <20160126182543.64050678@ernst.home> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> Date: Tue, 26 Jan 2016 10:14:23 -0800 X-Google-Sender-Auth: TjSAZi3JKdgjk9-9NQ8aEuFCRPk Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: gljennjohn@gmail.com Cc: Konstantin Belousov , Boris Astardzhiev , threads@freebsd.org, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 18:14:26 -0000 On Tue, Jan 26, 2016 at 9:25 AM, Gary Jennejohn wrote: > On Tue, 26 Jan 2016 09:06:39 -0800 > Luigi Rizzo wrote: > >> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >> wrote: >> > On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >> >> +ssize_t >> >> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >> >> + const struct timespec *__restrict timeout) >> >> +{ >> >> + size_t i, rcvd; >> >> + ssize_t ret; >> >> + >> >> + if (timeout != NULL) { >> >> + fd_set fds; >> >> + int res; >> > Please move all local definitions to the beginning of the function. >> >> This style recommendation was from 30 years ago and is >> bad programming practice, as it tends to complicate analysis >> for the human and increase the chance of improper usage of >> variables. >> >> We should move away from this for new code. >> > > Really? I personally find having all variables grouped together > much easier to understand. Stumbling across declarations in the > middle of the code in a for-loop, for example, takes me by surprise. > > I also greatly dislike initializing variables in their declarations. > > Maybe I'm just old fashioned since I have been writing C-code for > more than 30 years. (sorry for the digression) I am in the same ballpark in terms of coding age, but systems have become a lot more complex in that time window, code size generally exploded, and compilers are smarter so they do not need hints from the programmer on when to do initializations, or stack reuse or register allocations. I find that reducing the scope of variables helps a lot understanding third party code (e.g. where information belongs to) and reduces the chance of misuse (such as, leaking information from the body of a loop). About initializers in declarations, I think the rule should be "use good judgement and privilege readability". E.g., do postpone initialization if the first use is 20 lines down, so that it is clear what the value is by the time you use the variable; or when there is some complex condition to check, as writing it as a conditional expression may be ugly and cause code duplication and lead to poor error handling. But when the first use is close to the declaration, splitting the initialization is just unnecessary source bloat. cheers luigi > > -- > Gary Jennejohn -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Tue Jan 26 22:47:00 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 250EFA6E6B7 for ; Tue, 26 Jan 2016 22:47:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0DDEE19FD for ; Tue, 26 Jan 2016 22:47:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0A782A6E6B3; Tue, 26 Jan 2016 22:47:00 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09033A6E6B2; Tue, 26 Jan 2016 22:47:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4E6219FC; Tue, 26 Jan 2016 22:46:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u0QMkqI1036585; Tue, 26 Jan 2016 17:46:52 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 26 Jan 2016 17:46:52 -0500 (EST) Date: Tue, 26 Jan 2016 17:46:52 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Gary Jennejohn cc: Luigi Rizzo , threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <20160126182543.64050678@ernst.home> Message-ID: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 22:47:00 -0000 On Tue, 26 Jan 2016, Gary Jennejohn wrote: > On Tue, 26 Jan 2016 09:06:39 -0800 > Luigi Rizzo wrote: > >> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >> wrote: >>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>> +ssize_t >>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >>>> + const struct timespec *__restrict timeout) >>>> +{ >>>> + size_t i, rcvd; >>>> + ssize_t ret; >>>> + >>>> + if (timeout != NULL) { >>>> + fd_set fds; >>>> + int res; >>> Please move all local definitions to the beginning of the function. >> >> This style recommendation was from 30 years ago and is >> bad programming practice, as it tends to complicate analysis >> for the human and increase the chance of improper usage of >> variables. >> >> We should move away from this for new code. >> > > Really? I personally find having all variables grouped together > much easier to understand. Stumbling across declarations in the > middle of the code in a for-loop, for example, takes me by surprise. > > I also greatly dislike initializing variables in their declarations. > > Maybe I'm just old fashioned since I have been writing C-code for > more than 30 years. +1 Probably should be discouraged, but allowed on a case-by-case basis. One could argue that if you need to declaration blocks in the middle of code, then that code is too complex and should be broken out into a separate function. -- DE From owner-freebsd-net@freebsd.org Wed Jan 27 00:31:50 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E030A46E5D for ; Wed, 27 Jan 2016 00:31:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 69E9F8C5 for ; Wed, 27 Jan 2016 00:31:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 67B3EA46E59; Wed, 27 Jan 2016 00:31:50 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67249A46E58; Wed, 27 Jan 2016 00:31:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFA138C0; Wed, 27 Jan 2016 00:31:49 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id 123so128782531wmz.0; Tue, 26 Jan 2016 16:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=ZzH014obF/8i1r5IKZEJSesGYA6PlJd3h/jxXXAQRiE=; b=VgTQT4mGpKcuOX57pIdt8lTRUM0oqfjAUztGFqTuFtGi80I3S08Gn2VjeBeprn6ZLG SMNeVMaQRb3+kmV1I4tx/Csm7WiOW0l4yWz3ZXAU0oRMh2JjC61sxuCsref/SooY9Oed qsZkiM/IP6gXdHO1KXo/JtjRUgjL/aolkFO9lZEIWu23puhW+WxVyEgUQdRnQ8ey7HNL vSn2mqnEIvzpS1nG5hgpTY7r/tSbABdHyVPZOrVTB9uhawa9h1I7P4l/YSumVAJY34IX yqFD71jHtOsfn1qY9O68dWuuCN6h+fg5EySgIgmdE6GSw1vzEkkEjcc2QPV7Of3DJ06V aWPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-type :content-transfer-encoding; bh=ZzH014obF/8i1r5IKZEJSesGYA6PlJd3h/jxXXAQRiE=; b=SMDL9iWAH5fe4lVjzRYxdctdSU+6bwHEYXAQlp8XJtlhskiApuuNpkeNtxrwgomB65 OKpeNITA16+FthKn919sfPdUYnDfgH6TeJb59C9GtCG45bmCRsPChxegj1YvTgYz9OcI IjbO9yw/IC8uZwBTXLKcLc5rdGs7Mp1bt82sfsRPZIeJwQ5ZtrweDn8F794dtlTL/B+R kX171V0qXcCV4wFNGTEpOdjew9I6NyLrsvg+XUL8hchiSILSGBZIWuPRxtCmjHjGNzNd oIZVTbrcgm/tzzRiFS7lO2EkD+LpX2wQwOkcl8pZbjYey7bNYDKO9eCVXVtjKaHulOL/ Qrhw== X-Gm-Message-State: AG10YOQTPiuXvZqBwx88dLE6GzGCttmExaEjTbKrqjxoegzyE8vauDzFu+azEyovnjDnmw== X-Received: by 10.28.212.9 with SMTP id l9mr28452579wmg.75.1453854708534; Tue, 26 Jan 2016 16:31:48 -0800 (PST) Received: from ernst.home (p4FCA7371.dip0.t-ipconnect.de. [79.202.115.113]) by smtp.gmail.com with ESMTPSA id e198sm5129102wmd.0.2016.01.26.16.31.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jan 2016 16:31:47 -0800 (PST) Date: Wed, 27 Jan 2016 01:31:45 +0100 From: Gary Jennejohn To: Daniel Eischen Cc: Luigi Rizzo , threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160127013145.36f2aaef@ernst.home> In-Reply-To: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 00:31:50 -0000 On Tue, 26 Jan 2016 17:46:52 -0500 (EST) Daniel Eischen wrote: > On Tue, 26 Jan 2016, Gary Jennejohn wrote: > > > On Tue, 26 Jan 2016 09:06:39 -0800 > > Luigi Rizzo wrote: > > > >> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov > >> wrote: > >>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: > >>>> +ssize_t > >>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, > >>>> + const struct timespec *__restrict timeout) > >>>> +{ > >>>> + size_t i, rcvd; > >>>> + ssize_t ret; > >>>> + > >>>> + if (timeout != NULL) { > >>>> + fd_set fds; > >>>> + int res; > >>> Please move all local definitions to the beginning of the function. > >> > >> This style recommendation was from 30 years ago and is > >> bad programming practice, as it tends to complicate analysis > >> for the human and increase the chance of improper usage of > >> variables. > >> > >> We should move away from this for new code. > >> > > > > Really? I personally find having all variables grouped together > > much easier to understand. Stumbling across declarations in the > > middle of the code in a for-loop, for example, takes me by surprise. > > > > I also greatly dislike initializing variables in their declarations. > > > > Maybe I'm just old fashioned since I have been writing C-code for > > more than 30 years. > > +1 > > Probably should be discouraged, but allowed on a case-by-case > basis. One could argue that if you need to declaration blocks > in the middle of code, then that code is too complex and should > be broken out into a separate function. > Right. And code like this int func(void) { int baz, zot; [some more code] if (zot < 5) { int baz = 3; [more code] } [some more code] } is even worse. The compiler (clang) seems to consider this to merely be a reinitialization of baz, but a human might be confused. Something like for (int i = 0; i < 2; i++) is IMHO OK. -- Gary Jennejohn From owner-freebsd-net@freebsd.org Wed Jan 27 00:39:04 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D14FA6E457 for ; Wed, 27 Jan 2016 00:39:04 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6B558C51 for ; Wed, 27 Jan 2016 00:39:04 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 67421A6E455; Wed, 27 Jan 2016 00:39:04 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66B94A6E453; Wed, 27 Jan 2016 00:39:04 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF80FC4E; Wed, 27 Jan 2016 00:39:03 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id c192so116460603lfe.2; Tue, 26 Jan 2016 16:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=unqjzdiAU3Lsv07QAgQ5QKIqrqRb1aw8ueSz/wDpd84=; b=ondHbLGcP9dPXaJymV9/irHTjUER4wXCO4PKmemxXpWVqQavwS8TA23QY5ynOKliKf U4wy5VXO21h29dAREHqIzbzIj6GuU9DwM3ioLlzB+womDG7OOk8bKIR4mVdTdTtV41dW Mi5Pd/MnWH2OyQ/iGQw/HIGqvZDiuO0V63E/CQo1fO1oPF+M8jTCISxhTEMXyZZD0mmY XdHXErZoTBFTaPvzCiHmz0DsbP73n8gHRjGTxys6HBGyEJgTfi7avlebZI/PpUH6hSR1 cedSP1qu2sTD1T8v0jv0KL3iAM2XH7C7PQ8JicyaxAlC4EF2S1il54TV9hzXPOOc7DQa sd7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=unqjzdiAU3Lsv07QAgQ5QKIqrqRb1aw8ueSz/wDpd84=; b=kzAbwNsfTUB1l+SaHz/qVQebP1oyhYoWzlA80EUFpLuO8qKnRyuedNe1JXN4dFIFws TunWn6Q+LRNAOY/C25VRs6TA1tuc8ojeYqd6/iYV/MMpLQs0xR54iNqzq7qRwYDaPyp+ cm/vs/BJYFUGRr34i+nioXDFrGlSgmtLWJFZoBZlaDLpzA9aiTsC81SS45G9FNknFyMz V8M3SuKwS/vU4w4PkwUoCxI+ttiX5Fqz4i+xBHJ1q+lQTmTwSxj0iiOfsOGZ/5CAWPJQ BEy8UQ000s/k7eAPSJkhU5Z16RT+gHV+lO7vZaVdKMr2bZTc2aXfnJae2Wao14O6bUJ8 +CaQ== X-Gm-Message-State: AG10YOTuYBVZKRfYZzatbxIM+RP2K9kJjX7OkkcihNK3N8ZnrmhAB9+yZIIYrdOzvIkkHr24AUrMAw3ikJXTZQ== MIME-Version: 1.0 X-Received: by 10.25.21.208 with SMTP id 77mr9813445lfv.96.1453855140698; Tue, 26 Jan 2016 16:39:00 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Tue, 26 Jan 2016 16:39:00 -0800 (PST) In-Reply-To: <20160127013145.36f2aaef@ernst.home> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> Date: Tue, 26 Jan 2016 16:39:00 -0800 X-Google-Sender-Auth: k4LwQVdu9Ah7Qo0jNU6CBodhdSw Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: gljennjohn@gmail.com Cc: Daniel Eischen , threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 00:39:04 -0000 On Tue, Jan 26, 2016 at 4:31 PM, Gary Jennejohn wrote: > On Tue, 26 Jan 2016 17:46:52 -0500 (EST) > Daniel Eischen wrote: > >> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >> >> > On Tue, 26 Jan 2016 09:06:39 -0800 >> > Luigi Rizzo wrote: >> > >> >> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >> >> wrote: >> >>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >> >>>> +ssize_t >> >>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >> >>>> + const struct timespec *__restrict timeout) >> >>>> +{ >> >>>> + size_t i, rcvd; >> >>>> + ssize_t ret; >> >>>> + >> >>>> + if (timeout != NULL) { >> >>>> + fd_set fds; >> >>>> + int res; >> >>> Please move all local definitions to the beginning of the function. >> >> >> >> This style recommendation was from 30 years ago and is >> >> bad programming practice, as it tends to complicate analysis >> >> for the human and increase the chance of improper usage of >> >> variables. >> >> >> >> We should move away from this for new code. >> >> >> > >> > Really? I personally find having all variables grouped together >> > much easier to understand. Stumbling across declarations in the >> > middle of the code in a for-loop, for example, takes me by surprise. >> > >> > I also greatly dislike initializing variables in their declarations. >> > >> > Maybe I'm just old fashioned since I have been writing C-code for >> > more than 30 years. >> >> +1 >> >> Probably should be discouraged, but allowed on a case-by-case >> basis. One could argue that if you need to declaration blocks >> in the middle of code, then that code is too complex and should >> be broken out into a separate function. >> > > Right. > > And code like this > > int func(void) > { > int baz, zot; > [some more code] > if (zot < 5) > { > int baz = 3; > [more code] > } > [some more code] > } > > is even worse. The compiler (clang) seems to consider this to > merely be a reinitialization of baz, but a human might be confused. oh please... :) This is simply an inner variable shadowing the outer one (which is another poor practice, flagged with -Wshadow ). When you exit the scope you get the external variable with its value, as you can see from the following code. #include int main(int ac, char *av[]) { int baz = 5; printf("1 baz %d\n", baz); { int baz = 3; printf("2 baz %d\n", baz); } printf("3 baz %d\n", baz); return 0; } cheers luigi From owner-freebsd-net@freebsd.org Wed Jan 27 03:04:39 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B46F8A6F809 for ; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBB2C0E for ; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 9953CA6F807; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98C62A6F806; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 44004C0C; Wed, 27 Jan 2016 03:04:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 1C54342C5BF; Wed, 27 Jan 2016 14:04:30 +1100 (AEDT) Date: Wed, 27 Jan 2016 14:04:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Gary Jennejohn cc: Daniel Eischen , Boris Astardzhiev , threads@freebsd.org, Luigi Rizzo , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <20160127013145.36f2aaef@ernst.home> Message-ID: <20160127132558.W985@besplex.bde.org> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=PfoC/XVd c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=0JCmQBZd7s8qsGVShdUA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 03:04:39 -0000 On Wed, 27 Jan 2016, Gary Jennejohn wrote: > On Tue, 26 Jan 2016 17:46:52 -0500 (EST) > Daniel Eischen wrote: > >> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >> >>> On Tue, 26 Jan 2016 09:06:39 -0800 >>> Luigi Rizzo wrote: >>> >>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>> wrote: >>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>> +ssize_t >>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >>>>>> + const struct timespec *__restrict timeout) >>>>>> +{ >>>>>> + size_t i, rcvd; >>>>>> + ssize_t ret; >>>>>> + >>>>>> + if (timeout != NULL) { >>>>>> + fd_set fds; >>>>>> + int res; >>>>> Please move all local definitions to the beginning of the function. >>>> >>>> This style recommendation was from 30 years ago and is >>>> bad programming practice, as it tends to complicate analysis >>>> for the human and increase the chance of improper usage of >>>> variables. >>>> >>>> We should move away from this for new code. >>> >>> Really? I personally find having all variables grouped together >>> much easier to understand. Stumbling across declarations in the >>> middle of the code in a for-loop, for example, takes me by surprise. +1 I used to program in a strict version of the "new" style 25-30 years ago, but learned better. In the strict version, every variable must have minimal scope, so squillions of inner blocks are needed to limit the scopes. Some deeply nested of course. This is a good obfuscation. It even breaks -Wshadow by letting you have unrelated variables named 'i' that don't shadow each other because their scope is limited. Such variables are good in separate functions but not in the same function. Understanding the code to see that the variables are actually unrelated requires counting more braces than usual. If you don't do this strictly then you get a random style with some variables declared at the top and some in inner blocks for mostly historical reasons. A strict style with all of the variables at the top is much easier to write and read. >>> I also greatly dislike initializing variables in their declarations. >>> >>> Maybe I'm just old fashioned since I have been writing C-code for >>> more than 30 years. >> >> +1 >> >> Probably should be discouraged, but allowed on a case-by-case >> basis. One could argue that if you need to declaration blocks >> in the middle of code, then that code is too complex and should >> be broken out into a separate function. > > Right. Lots of inner blocks are good for both making simple code look complex and making it easier to write the complex code in the same function, at least if you use a tiny indentation so that you can have 40 levels of indentation without needing a 500-column terminal. > And code like this > > int func(void) > { > int baz, zot; > [some more code] > if (zot < 5) > { > int baz = 3; > [more code] > } > [some more code] > } > > is even worse. The compiler (clang) seems to consider this to > merely be a reinitialization of baz, but a human might be confused. No, that is a different baz, and is warned about by Wshadow. > Something like for (int i = 0; i < 2; i++) is IMHO OK. Except it is C++ style which is so forbidden that style(9) doesn't know that it needs a rule to forbid it. The worst is C++ style that doesn't limit the scope -- a bunch of variables at the top and then somewhere in the middle of the function another variable is needed and it is declared at top level of the function scope. I sometimes do this when in a hurry. The strict K&R-C90 style requires opening an inner block to do little more than hold the declaration and then (re)indenting and (re)formatting all the code in the inner block. The C++ style reduces writability and readability in a different way. It doesn't cause excessive indentation but it doesn't limit the scope much differently than putting all the declarations at the top. At least the reader can find the declarations easily when they are at the top. Bruce From owner-freebsd-net@freebsd.org Wed Jan 27 04:07:46 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95634A6EE3B for ; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6CF83117F for ; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6C338A6EE39; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B8C2A6EE38; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28A12117E; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ob0-x233.google.com with SMTP id is5so158664792obc.0; Tue, 26 Jan 2016 20:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8c8cFMzpu1Eo5kd5Vi84Y1/ndIb2zqmERWEkC0iSDPo=; b=I703BzXsF4pQPHe1Ko8m/B2TJpxs3/dXcHbiRIKhC3rbXIe7sMaew6PHGaFL1f77d0 1AeCRVs0NStlQKqJ+Fz+nphp1Lh1e6EmoEeMpUdwce0YYJ0C3EfqF65haYlsequDAVKL mT7VEcqluhHK1p52WSMVEic8UIULeDCw/L2D7fONWoRzTv9p9GgXEfJi7S5fyG87Xibi lKpWxbSNmVPPPdC0AuKMbvPqGEr6L0IRnIl3wOO60Tn5D2lmMbuMZjrV4PUQi0AMS96o 6iE1PSPP/soewfXWcWCu8V4PFi4BKI9AOcIEC9iCxTOP5YL/pPiUbFQzSpH6Ge5ml4BP gn7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8c8cFMzpu1Eo5kd5Vi84Y1/ndIb2zqmERWEkC0iSDPo=; b=C0raulsV0wlAt6FMYXxitYMBC7Lfy86eX1Ajtc/5aTnqLg3F9hVcvEOARRjhU5Oz9D RyfXxL8soQUnOFtmWQtJ4AGxbnSjD9jnRDwbu7Uk0HhjMTvfdK4KJk0G1tehBwcU9fKv 2NxG9fKLfYbGm/wP9HREMC4pT8NNjNnKP1LMOwOqk6VRMZyQ+IFqs1k6/p5ZIflDOVLu sGL+zB+0WMdBOvH6coSPh+1WfKBAALBQPtG4pLsu3NOdDRVxbb1lD6T10ENzxMzi0hpE ZnC4fdj54eXkOkOcf4TmeePwxX/Wa5XbAx+3d6thlQ5FX58vvuYxR/TvAQYP7aPcEKpi 42ww== X-Gm-Message-State: AG10YOQCe7wMUIifo18SJbDGjGhA1kTrb6l3VYnOKYEU8jVMqaUO1tgZ3qXGzJVCcXdzTv6Px1j7oDWeXWbAIA== MIME-Version: 1.0 X-Received: by 10.182.116.200 with SMTP id jy8mr21254020obb.35.1453867665444; Tue, 26 Jan 2016 20:07:45 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.202.89.130 with HTTP; Tue, 26 Jan 2016 20:07:45 -0800 (PST) In-Reply-To: <20160127132558.W985@besplex.bde.org> References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> Date: Tue, 26 Jan 2016 20:07:45 -0800 X-Google-Sender-Auth: bF99goyZzGwjIdS4teqKAUU-7Kg Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Kevin Oberman To: Bruce Evans Cc: Gary Jennejohn , Daniel Eischen , threads@freebsd.org, Boris Astardzhiev , Luigi Rizzo , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 04:07:46 -0000 Since this has become a debate on programming style, it seem appropriate to mention that Edward Yourdan passed away last Tuesday. For those too young to recognize the name, he was the developer of modern structured programming. He did recognize the style rules are important, but not iron-clad. Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans wrote: > On Wed, 27 Jan 2016, Gary Jennejohn wrote: > > On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >> Daniel Eischen wrote: >> >> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>> >>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>> Luigi Rizzo wrote: >>>> >>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>> wrote: >>>>> >>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>> >>>>>>> +ssize_t >>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int >>>>>>> flags, >>>>>>> + const struct timespec *__restrict timeout) >>>>>>> +{ >>>>>>> + size_t i, rcvd; >>>>>>> + ssize_t ret; >>>>>>> + >>>>>>> + if (timeout != NULL) { >>>>>>> + fd_set fds; >>>>>>> + int res; >>>>>>> >>>>>> Please move all local definitions to the beginning of the function. >>>>>> >>>>> >>>>> This style recommendation was from 30 years ago and is >>>>> bad programming practice, as it tends to complicate analysis >>>>> for the human and increase the chance of improper usage of >>>>> variables. >>>>> >>>>> We should move away from this for new code. >>>>> >>>> >>>> Really? I personally find having all variables grouped together >>>> much easier to understand. Stumbling across declarations in the >>>> middle of the code in a for-loop, for example, takes me by surprise. >>>> >>> > +1 > > I used to program in a strict version of the "new" style 25-30 years > ago, but learned better. In the strict version, every variable must > have minimal scope, so squillions of inner blocks are needed to limit > the scopes. Some deeply nested of course. This is a good obfuscation. > It even breaks -Wshadow by letting you have unrelated variables named > 'i' that don't shadow each other because their scope is limited. Such > variables are good in separate functions but not in the same function. > Understanding the code to see that the variables are actually unrelated > requires counting more braces than usual. If you don't do this > strictly then you get a random style with some variables declared at > the top and some in inner blocks for mostly historical reasons. A > strict style with all of the variables at the top is much easier to > write and read. > > I also greatly dislike initializing variables in their declarations. >>>> >>>> Maybe I'm just old fashioned since I have been writing C-code for >>>> more than 30 years. >>>> >>> >>> +1 >>> >>> Probably should be discouraged, but allowed on a case-by-case >>> basis. One could argue that if you need to declaration blocks >>> in the middle of code, then that code is too complex and should >>> be broken out into a separate function. >>> >> >> Right. >> > > Lots of inner blocks are good for both making simple code look complex > and making it easier to write the complex code in the same function, > at least if you use a tiny indentation so that you can have 40 levels > of indentation without needing a 500-column terminal. > > And code like this >> >> int func(void) >> { >> int baz, zot; >> [some more code] >> if (zot < 5) >> { >> int baz = 3; >> [more code] >> } >> [some more code] >> } >> >> is even worse. The compiler (clang) seems to consider this to >> merely be a reinitialization of baz, but a human might be confused. >> > > No, that is a different baz, and is warned about by Wshadow. > > Something like for (int i = 0; i < 2; i++) is IMHO OK. >> > > Except it is C++ style which is so forbidden that style(9) doesn't > know that it needs a rule to forbid it. > > The worst is C++ style that doesn't limit the scope -- a bunch of > variables at the top and then somewhere in the middle of the function > another variable is needed and it is declared at top level of the > function scope. I sometimes do this when in a hurry. The strict > K&R-C90 style requires opening an inner block to do little more than > hold the declaration and then (re)indenting and (re)formatting all > the code in the inner block. The C++ style reduces writability and > readability in a different way. It doesn't cause excessive indentation > but it doesn't limit the scope much differently than putting all the > declarations at the top. At least the reader can find the declarations > easily when they are at the top. > > Bruce > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Wed Jan 27 10:14:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D729A6F203 for ; Wed, 27 Jan 2016 10:14:05 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 661491D96 for ; Wed, 27 Jan 2016 10:14:05 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 61666A6F201; Wed, 27 Jan 2016 10:14:05 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60C3DA6F200; Wed, 27 Jan 2016 10:14:05 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6A581D93; Wed, 27 Jan 2016 10:14:04 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id 123so144666581wmz.0; Wed, 27 Jan 2016 02:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=me8kynz4UqlTFaowtYMjeDL/5ucMxemlJz9/vVLp0WQ=; b=WUyqrsAoPXdE8NGnT3mwyKDjUdx33iY+1rfYVHaff6LdMYndvNWU2Ojrjd/Et5tQrd 7Zn5ojkzGt4ZsKFvHUtuHM/iAqrJ7fqDoEFOwS53af2YlfEoIqMsj6GDxk2QdQpa/T0W jH2ASCaw48m8h/jK1KhwvORg+RhSlqmYPIywgw/FscLyVvKbPhgMPjmUGOYNqezdnFdl wlU2RSLBUgrYzuSbQTkDLe3A+TQbfrPNWlihKRqcmDqChjIS/7PxyCUf1SGb+2/lDFVH xdVUhKs6w/PZHf5R5LPbfHZMX/6yEQe1d1yNCyedutL0qppJmeVlAv5sHsG41piOj76q E/KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=me8kynz4UqlTFaowtYMjeDL/5ucMxemlJz9/vVLp0WQ=; b=XAdmcLO89byVOKqXtNuSyUGhRizK+fCo9HoinzU0n2HGuRXnn1FLcUPPoqFlpWTKPH hCFyfOL0z7eCXm/M4aWcEwRrH2hpLbRG0nPUONYyC1jhlV9b1PzSUsa689BGYQQU416W 33yWuumdfUI1WnV1axZ9rvq1GbBazowX6tbSXo/hTbqV5iXCTe/JIFmqp0+ZuHzmo7aN aZvLe7BxplDvUtBnLyTKKKvpSHflesq/UIrhEcgtRi5bT5lWM7IT+H/Oo7Xbiej2jNVw 5efI9QeEj69JOjv/Lgo7nS7+SpwhISQ1c0Jmxa4O5jRF7+tYsn/xVA2RCugKTKfgCnNT khgw== X-Gm-Message-State: AG10YOSC7pmaDmqxlvbGo3Vr6AGr50vMEYDqbQjgfErOKUhdF+ATWIiunfYQcFedIc7fE+fDVzgPuwz2rbRebQ== MIME-Version: 1.0 X-Received: by 10.194.243.103 with SMTP id wx7mr31668722wjc.136.1453889643178; Wed, 27 Jan 2016 02:14:03 -0800 (PST) Received: by 10.28.136.148 with HTTP; Wed, 27 Jan 2016 02:14:02 -0800 (PST) In-Reply-To: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> Date: Wed, 27 Jan 2016 12:14:02 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Kevin Oberman Cc: Bruce Evans , Gary Jennejohn , Daniel Eischen , threads@freebsd.org, Luigi Rizzo , "freebsd-net@freebsd.org" Content-Type: multipart/mixed; boundary=089e01493c12b9cea1052a4e0f84 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 10:14:05 -0000 --089e01493c12b9cea1052a4e0f84 Content-Type: text/plain; charset=UTF-8 Hello, I've made a few changes in the patch as recommended here starting with the switch to ppoll(). I have a question since it's not quite clear to me as written in the manpage. Is it possible that ppoll() doesn't return an error and yet revents have set either POLLERR or POLLHUP or POLLNVAL? See patch and comments are again welcomed. On Wed, Jan 27, 2016 at 6:07 AM, Kevin Oberman wrote: > Since this has become a debate on programming style, it seem appropriate > to mention that Edward Yourdan passed away last Tuesday. For those too > young to recognize the name, he was the developer of modern structured > programming. He did recognize the style rules are important, but not > iron-clad. > > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans wrote: > >> On Wed, 27 Jan 2016, Gary Jennejohn wrote: >> >> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >>> Daniel Eischen wrote: >>> >>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>>> >>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>>> Luigi Rizzo wrote: >>>>> >>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>>> wrote: >>>>>> >>>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>> >>>>>>>> +ssize_t >>>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, >>>>>>>> int flags, >>>>>>>> + const struct timespec *__restrict timeout) >>>>>>>> +{ >>>>>>>> + size_t i, rcvd; >>>>>>>> + ssize_t ret; >>>>>>>> + >>>>>>>> + if (timeout != NULL) { >>>>>>>> + fd_set fds; >>>>>>>> + int res; >>>>>>>> >>>>>>> Please move all local definitions to the beginning of the function. >>>>>>> >>>>>> >>>>>> This style recommendation was from 30 years ago and is >>>>>> bad programming practice, as it tends to complicate analysis >>>>>> for the human and increase the chance of improper usage of >>>>>> variables. >>>>>> >>>>>> We should move away from this for new code. >>>>>> >>>>> >>>>> Really? I personally find having all variables grouped together >>>>> much easier to understand. Stumbling across declarations in the >>>>> middle of the code in a for-loop, for example, takes me by surprise. >>>>> >>>> >> +1 >> >> I used to program in a strict version of the "new" style 25-30 years >> ago, but learned better. In the strict version, every variable must >> have minimal scope, so squillions of inner blocks are needed to limit >> the scopes. Some deeply nested of course. This is a good obfuscation. >> It even breaks -Wshadow by letting you have unrelated variables named >> 'i' that don't shadow each other because their scope is limited. Such >> variables are good in separate functions but not in the same function. >> Understanding the code to see that the variables are actually unrelated >> requires counting more braces than usual. If you don't do this >> strictly then you get a random style with some variables declared at >> the top and some in inner blocks for mostly historical reasons. A >> strict style with all of the variables at the top is much easier to >> write and read. >> >> I also greatly dislike initializing variables in their declarations. >>>>> >>>>> Maybe I'm just old fashioned since I have been writing C-code for >>>>> more than 30 years. >>>>> >>>> >>>> +1 >>>> >>>> Probably should be discouraged, but allowed on a case-by-case >>>> basis. One could argue that if you need to declaration blocks >>>> in the middle of code, then that code is too complex and should >>>> be broken out into a separate function. >>>> >>> >>> Right. >>> >> >> Lots of inner blocks are good for both making simple code look complex >> and making it easier to write the complex code in the same function, >> at least if you use a tiny indentation so that you can have 40 levels >> of indentation without needing a 500-column terminal. >> >> And code like this >>> >>> int func(void) >>> { >>> int baz, zot; >>> [some more code] >>> if (zot < 5) >>> { >>> int baz = 3; >>> [more code] >>> } >>> [some more code] >>> } >>> >>> is even worse. The compiler (clang) seems to consider this to >>> merely be a reinitialization of baz, but a human might be confused. >>> >> >> No, that is a different baz, and is warned about by Wshadow. >> >> Something like for (int i = 0; i < 2; i++) is IMHO OK. >>> >> >> Except it is C++ style which is so forbidden that style(9) doesn't >> know that it needs a rule to forbid it. >> >> The worst is C++ style that doesn't limit the scope -- a bunch of >> variables at the top and then somewhere in the middle of the function >> another variable is needed and it is declared at top level of the >> function scope. I sometimes do this when in a hurry. The strict >> K&R-C90 style requires opening an inner block to do little more than >> hold the declaration and then (re)indenting and (re)formatting all >> the code in the inner block. The C++ style reduces writability and >> readability in a different way. It doesn't cause excessive indentation >> but it doesn't limit the scope much differently than putting all the >> declarations at the top. At least the reader can find the declarations >> easily when they are at the top. >> >> Bruce >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > --089e01493c12b9cea1052a4e0f84 Content-Type: text/plain; charset=US-ASCII; name="sendrecvmmsg-libconly6.diff" Content-Disposition: attachment; filename="sendrecvmmsg-libconly6.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ijwo52uv0 ZGlmZiAtLWdpdCBhL2xpYi9saWJjL2dlbi9NYWtlZmlsZS5pbmMgYi9saWIvbGliYy9nZW4vTWFr ZWZpbGUuaW5jCmluZGV4IGI0NDg0NjEuLjdkZThjZTMgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL2dl bi9NYWtlZmlsZS5pbmMKKysrIGIvbGliL2xpYmMvZ2VuL01ha2VmaWxlLmluYwpAQCAtOTksMTEg Kzk5LDEzIEBAIFNSQ1MrPQlfX2dldG9zcmVsZGF0ZS5jIFwKIAlyYWlzZS5jIFwKIAlyZWFkZGly LmMgXAogCXJlYWRwYXNzcGhyYXNlLmMgXAorCXJlY3ZtbXNnLmMgXAogCXJld2luZGRpci5jIFwK IAlzY2FuZGlyLmMgXAogCXNlZWQ0OC5jIFwKIAlzZWVrZGlyLmMgXAogCXNlbWN0bC5jIFwKKwlz ZW5kbW1zZy5jIFwKIAlzZXRkb21haW5uYW1lLmMgXAogCXNldGhvc3RuYW1lLmMgXAogCXNldGpt cGVyci5jIFwKQEAgLTQ1MSwxMCArNDUzLDEyIEBAIE1MSU5LUys9cmFuZDQ4LjMgX3JhbmQ0OC4z IFwKIAlyYW5kNDguMyBucmFuZDQ4LjMgXAogCXJhbmQ0OC4zIHNlZWQ0OC4zIFwKIAlyYW5kNDgu MyBzcmFuZDQ4LjMKK01MSU5LUys9cmVjdi4yIHJlY3ZtbXNnLjIKIE1MSU5LUys9c2NhbmRpci4z IGFscGhhc29ydC4zCiBNTElOS1MrPXNlbV9vcGVuLjMgc2VtX2Nsb3NlLjMgXAogCXNlbV9vcGVu LjMgc2VtX3VubGluay4zCiBNTElOS1MrPXNlbV93YWl0LjMgc2VtX3RyeXdhaXQuMworTUxJTktT Kz1zZW5kLjIgc2VuZG1tc2cuMgogTUxJTktTKz1zZXRqbXAuMyBfbG9uZ2ptcC4zIFwKIAlzZXRq bXAuMyBfc2V0am1wLjMgXAogCXNldGptcC4zIGxvbmdqbXAuMyBcCmRpZmYgLS1naXQgYS9saWIv bGliYy9nZW4vcmVjdm1tc2cuYyBiL2xpYi9saWJjL2dlbi9yZWN2bW1zZy5jCm5ldyBmaWxlIG1v ZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjQzMjAwOGYKLS0tIC9kZXYvbnVsbAorKysgYi9saWIv bGliYy9nZW4vcmVjdm1tc2cuYwpAQCAtMCwwICsxLDg3IEBACisvKgorICogQ29weXJpZ2h0IChj KSAyMDE2IEJvcmlzIEFzdGFyZHpoaWV2LCBTbWFydGNvbS1CdWxnYXJpYSBBRAorICogQWxsIHJp Z2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBh bmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBl cm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1l dDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUg YWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UocyksIHRoaXMgbGlzdCBvZiBjb25kaXRpb25z IGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgYXMKKyAqICAgIHRoZSBmaXJzdCBsaW5lcyBv ZiB0aGlzIGZpbGUgdW5tb2RpZmllZCBvdGhlciB0aGFuIHRoZSBwb3NzaWJsZQorICogICAgYWRk aXRpb24gb2Ygb25lIG9yIG1vcmUgY29weXJpZ2h0IG5vdGljZXMuCisgKiAyLiBSZWRpc3RyaWJ1 dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAor ICogICAgbm90aWNlKHMpLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2lu ZyBkaXNjbGFpbWVyIGluCisgKiAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0 ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCisgKiAgICBkaXN0cmlidXRpb24uCisgKgorICogVEhJ UyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJR0hUIEhPTERFUihTKSBgYEFTIElT JycgQU5EIEFOWQorICogRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywg QlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFO VEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUgorICogUFVSUE9TRSBBUkUgRElT Q0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBDT1BZUklHSFQgSE9MREVSKFMpIEJFCisg KiBMSUFCTEUgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBF WEVNUExBUlksIE9SCisgKiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5P VCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRgorICogU1VCU1RJVFVURSBHT09EUyBPUiBTRVJW SUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SCisgKiBCVVNJTkVTUyBJTlRF UlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwK KyAqIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xV RElORyBORUdMSUdFTkNFCisgKiBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQg T0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLAorICogRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQ T1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+ CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNs dWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSA8c3lzL3BvbGwuaD4KKyNpbmNsdWRlIDxzeXMv c3RkZGVmLmg+CisjaW5jbHVkZSAibGliY19wcml2YXRlLmgiCisKKyNkZWZpbmUgUE9MTE1BU0sg KFBPTExJTiB8IFBPTExSRE5PUk0gfCBQT0xMUkRCQU5EIHwgUE9MTFBSSSkKKyNkZWZpbmUgRVBP TExNQVNLIChQT0xMRVJSIHwgUE9MTEhVUCB8IFBPTExOVkFMKQorCitzc2l6ZV90CityZWN2bW1z ZyhpbnQgcywgc3RydWN0IG1tc2doZHIgKl9fcmVzdHJpY3QgbXNndmVjLCBzaXplX3Qgdmxlbiwg aW50IGZsYWdzLAorICAgIGNvbnN0IHN0cnVjdCB0aW1lc3BlYyAqX19yZXN0cmljdCB0aW1lb3V0 KQoreworCXN0cnVjdCBwb2xsZmQgcGZkWzFdOworCXNpemVfdCBpLCByY3ZkOworCXNzaXplX3Qg cmV0OworCWludCByZXM7CisKKwlpZiAodGltZW91dCAhPSBOVUxMKSB7CisJCXBmZFswXS5mZCA9 IHM7CisJCXBmZFswXS5ldmVudHMgPSBQT0xMTUFTSzsKKwkJcGZkWzBdLnJldmVudHMgPSAwOwor CQlyZXMgPSBwcG9sbCgmcGZkWzBdLCAxLCB0aW1lb3V0LCBOVUxMKTsKKwkJaWYgKHJlcyA9PSAt MSB8fCByZXMgPT0gMCkKKwkJCXJldHVybiAocmVzKTsKKwkJaWYgKHBmZFswXS5yZXZlbnRzICYg RVBPTExNQVNLIHx8CisJCSAgICAocGZkWzBdLnJldmVudHMgJiBQT0xMTUFTSykgPT0gMCkKKwkJ CXJldHVybiAoLTEpOworCX0KKworCXJldCA9IF9fc3lzX3JlY3Ztc2cocywgJm1zZ3ZlY1swXS5t c2dfaGRyLCBmbGFncyk7CisJaWYgKHJldCA9PSAtMSkKKwkJcmV0dXJuIChyZXQpOworCisJLyog VHVybiBvbiBET05UV0FJVCBpZiBXQUlURk9ST05FIGlzIHNldC4gKi8KKwlpZiAoZmxhZ3MgJiBN U0dfV0FJVEZPUk9ORSkKKwkJZmxhZ3MgfD0gTVNHX0RPTlRXQUlUOworCisJcmN2ZCA9IDE7CisJ Zm9yIChpID0gcmN2ZDsgaSA8IHZsZW47IGkrKywgcmN2ZCsrKSB7CisJCXJldCA9IF9fc3lzX3Jl Y3Ztc2cocywgJm1zZ3ZlY1tpXS5tc2dfaGRyLCBmbGFncyk7CisJCWlmIChyZXQgPT0gLTEpIHsK KwkJCS8qIFdlIGhhdmUgcmVjZWl2ZWQgbWVzc2FnZXMuIExldCBjYWxsZXIga25vdy4gKi8KKwkJ CXJldHVybiAocmN2ZCk7CisJCX0KKworCQkvKiBTYXZlIHJlY2VpdmVkIGJ5dGVzICovCisJCW1z Z3ZlY1tpXS5tc2dfbGVuID0gcmV0OworCX0KKworCXJldHVybiAocmN2ZCk7Cit9CisKKyN1bmRl ZiBQT0xMTUFTSworI3VuZGVmIEVQT0xMTUFTSwpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvZ2VuL3Nl bmRtbXNnLmMgYi9saWIvbGliYy9nZW4vc2VuZG1tc2cuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NApp bmRleCAwMDAwMDAwLi4zZDkxZWUyCi0tLSAvZGV2L251bGwKKysrIGIvbGliL2xpYmMvZ2VuL3Nl bmRtbXNnLmMKQEAgLTAsMCArMSw1OSBAQAorLyoKKyAqIENvcHlyaWdodCAoYykgMjAxNiBCb3Jp cyBBc3RhcmR6aGlldiwgU21hcnRjb20tQnVsZ2FyaWEgQUQKKyAqIEFsbCByaWdodHMgcmVzZXJ2 ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBm b3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJv dmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBS ZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHly aWdodAorICogICAgbm90aWNlKHMpLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZv bGxvd2luZyBkaXNjbGFpbWVyIGFzCisgKiAgICB0aGUgZmlyc3QgbGluZXMgb2YgdGhpcyBmaWxl IHVubW9kaWZpZWQgb3RoZXIgdGhhbiB0aGUgcG9zc2libGUKKyAqICAgIGFkZGl0aW9uIG9mIG9u ZSBvciBtb3JlIGNvcHlyaWdodCBub3RpY2VzLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJp bmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGlj ZShzKSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ciBpbgorICogICAgdGhlIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92 aWRlZCB3aXRoIHRoZQorICogICAgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUg SVMgUFJPVklERUQgQlkgVEhFIENPUFlSSUdIVCBIT0xERVIoUykgYGBBUyBJUycnIEFORCBBTlkK KyAqIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFO RCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIKKyAqIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuICBJ TiBOTyBFVkVOVCBTSEFMTCBUSEUgQ09QWVJJR0hUIEhPTERFUihTKSBCRQorICogTElBQkxFIEZP UiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBP UgorICogQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBU TywgUFJPQ1VSRU1FTlQgT0YKKyAqIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1Mg T0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUgorICogQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBI T1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksCisgKiBXSEVUSEVS IElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElH RU5DRQorICogT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0Ug T0YgVEhJUyBTT0ZUV0FSRSwKKyAqIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkg T0YgU1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQo IiRGcmVlQlNEJCIpOworCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3Nv Y2tldC5oPgorI2luY2x1ZGUgImxpYmNfcHJpdmF0ZS5oIgorCitzc2l6ZV90CitzZW5kbW1zZyhp bnQgcywgc3RydWN0IG1tc2doZHIgKl9fcmVzdHJpY3QgbXNndmVjLCBzaXplX3QgdmxlbiwgaW50 IGZsYWdzKQoreworCXNpemVfdCBpLCBzZW50OworCXNzaXplX3QgcmV0OworCisJc2VudCA9IDA7 CisJZm9yIChpID0gMDsgaSA8IHZsZW47IGkrKywgc2VudCsrKSB7CisJCXJldCA9IF9fc3lzX3Nl bmRtc2cocywgJm1zZ3ZlY1tpXS5tc2dfaGRyLCBmbGFncyk7CisJCWlmIChyZXQgPT0gLTEpIHsK KwkJCWlmIChzZW50ICE9IDApIHsKKwkJCQkvKiBXZSBoYXZlIHNlbnQgbWVzc2FnZXMuIExldCBj YWxsZXIga25vdy4gKi8KKwkJCQlyZXR1cm4gKHNlbnQpOworCQkJfQorCQkJcmV0dXJuIChyZXQp OworCQl9CisKKwkJLyogU2F2ZSBzZW50IGJ5dGVzICovCisJCW1zZ3ZlY1tpXS5tc2dfbGVuID0g cmV0OworCX0KKworCXJldHVybiAoc2VudCk7Cit9CmRpZmYgLS1naXQgYS9saWIvbGliYy9pbmNs dWRlL25hbWVzcGFjZS5oIGIvbGliL2xpYmMvaW5jbHVkZS9uYW1lc3BhY2UuaAppbmRleCA3Mzlk N2IxLi5jOTU4MjllIDEwMDY0NAotLS0gYS9saWIvbGliYy9pbmNsdWRlL25hbWVzcGFjZS5oCisr KyBiL2xpYi9saWJjL2luY2x1ZGUvbmFtZXNwYWNlLmgKQEAgLTIwOCw2ICsyMDgsNyBAQAogI2Rl ZmluZQkJcmVhZHYJCQkJX3JlYWR2CiAjZGVmaW5lCQlyZWN2ZnJvbQkJCV9yZWN2ZnJvbQogI2Rl ZmluZQkJcmVjdm1zZwkJCQlfcmVjdm1zZworI2RlZmluZQkJcmVjdm1tc2cJCQlfcmVjdm1tc2cK ICNkZWZpbmUJCXNlbGVjdAkJCQlfc2VsZWN0CiAjZGVmaW5lCQlzZW1fY2xvc2UJCQlfc2VtX2Ns b3NlCiAjZGVmaW5lCQlzZW1fZGVzdHJveQkJCV9zZW1fZGVzdHJveQpAQCAtMjIwLDYgKzIyMSw3 IEBACiAjZGVmaW5lCQlzZW1fdW5saW5rCQkJX3NlbV91bmxpbmsKICNkZWZpbmUJCXNlbV93YWl0 CQkJX3NlbV93YWl0CiAjZGVmaW5lCQlzZW5kbXNnCQkJCV9zZW5kbXNnCisjZGVmaW5lCQlzZW5k bW1zZwkJCV9zZW5kbW1zZwogI2RlZmluZQkJc2VuZHRvCQkJCV9zZW5kdG8KICNkZWZpbmUJCXNl dHNvY2tvcHQJCQlfc2V0c29ja29wdAogLyojZGVmaW5lCQlzaWdhY3Rpb24JCQlfc2lnYWN0aW9u Ki8KZGlmZiAtLWdpdCBhL2xpYi9saWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmggYi9saWIvbGli Yy9pbmNsdWRlL3VuLW5hbWVzcGFjZS5oCmluZGV4IGYzMWZhN2EuLjAyMzMzNDggMTAwNjQ0Ci0t LSBhL2xpYi9saWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmgKKysrIGIvbGliL2xpYmMvaW5jbHVk ZS91bi1uYW1lc3BhY2UuaApAQCAtMTg5LDYgKzE4OSw3IEBACiAjdW5kZWYJCXJlYWR2CiAjdW5k ZWYJCXJlY3Zmcm9tCiAjdW5kZWYJCXJlY3Ztc2cKKyN1bmRlZgkJcmVjdm1tc2cKICN1bmRlZgkJ c2VsZWN0CiAjdW5kZWYJCXNlbV9jbG9zZQogI3VuZGVmCQlzZW1fZGVzdHJveQpAQCAtMjAxLDYg KzIwMiw3IEBACiAjdW5kZWYJCXNlbV91bmxpbmsKICN1bmRlZgkJc2VtX3dhaXQKICN1bmRlZgkJ c2VuZG1zZworI3VuZGVmCQlzZW5kbW1zZwogI3VuZGVmCQlzZW5kdG8KICN1bmRlZgkJc2V0c29j a29wdAogI3VuZGVmCQlzaWdhY3Rpb24KZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9TeW1ib2wu bWFwIGIvbGliL2xpYmMvc3lzL1N5bWJvbC5tYXAKaW5kZXggN2IzMjU3Yy4uZGMyZWQwZSAxMDA2 NDQKLS0tIGEvbGliL2xpYmMvc3lzL1N5bWJvbC5tYXAKKysrIGIvbGliL2xpYmMvc3lzL1N5bWJv bC5tYXAKQEAgLTM5OSw2ICszOTksOCBAQCBGQlNEXzEuNCB7CiAJdXRpbWVuc2F0OwogCW51bWFf c2V0YWZmaW5pdHk7CiAJbnVtYV9nZXRhZmZpbml0eTsKKwlzZW5kbW1zZzsKKwlyZWN2bW1zZzsK IH07CiAKIEZCU0Rwcml2YXRlXzEuMCB7CmRpZmYgLS1naXQgYS9saWIvbGliYy9zeXMvcmVjdi4y IGIvbGliL2xpYmMvc3lzL3JlY3YuMgppbmRleCAzMjZlN2ZmLi5jYjU0NjIyIDEwMDY0NAotLS0g YS9saWIvbGliYy9zeXMvcmVjdi4yCisrKyBiL2xpYi9saWJjL3N5cy9yZWN2LjIKQEAgLTM0LDgg KzM0LDkgQEAKIC5TaCBOQU1FCiAuTm0gcmVjdiAsCiAuTm0gcmVjdmZyb20gLAotLk5tIHJlY3Zt c2cKLS5OZCByZWNlaXZlIGEgbWVzc2FnZSBmcm9tIGEgc29ja2V0CisuTm0gcmVjdm1zZyAsCisu Tm0gcmVjdm1tc2cKKy5OZCByZWNlaXZlIG1lc3NhZ2UocykgZnJvbSBhIHNvY2tldAogLlNoIExJ QlJBUlkKIC5MYiBsaWJjCiAuU2ggU1lOT1BTSVMKQEAgLTQ3LDExICs0OCwxNSBAQAogLkZuIHJl Y3Zmcm9tICJpbnQgcyIgInZvaWQgKmJ1ZiIgInNpemVfdCBsZW4iICJpbnQgZmxhZ3MiICJzdHJ1 Y3Qgc29ja2FkZHIgKiByZXN0cmljdCBmcm9tIiAic29ja2xlbl90ICogcmVzdHJpY3QgZnJvbWxl biIKIC5GdCBzc2l6ZV90CiAuRm4gcmVjdm1zZyAiaW50IHMiICJzdHJ1Y3QgbXNnaGRyICptc2ci ICJpbnQgZmxhZ3MiCisuRnQgc3NpemVfdAorLkZuIHJlY3ZtbXNnICJpbnQgcyIgInN0cnVjdCBt bXNnaGRyICogcmVzdHJpY3QgbXNndmVjIiAic2l6ZV90IHZsZW4iICJpbnQgZmxhZ3MiICJjb25z dCBzdHJ1Y3QgdGltZXNwZWMgKiByZXN0cmljdCB0aW1lb3V0IgogLlNoIERFU0NSSVBUSU9OCiBU aGUKIC5GbiByZWN2ZnJvbQogYW5kCiAuRm4gcmVjdm1zZworYW5kCisuRm4gcmVjdm1tc2cKIHN5 c3RlbSBjYWxscwogYXJlIHVzZWQgdG8gcmVjZWl2ZSBtZXNzYWdlcyBmcm9tIGEgc29ja2V0LAog YW5kIG1heSBiZSB1c2VkIHRvIHJlY2VpdmUgZGF0YSBvbiBhIHNvY2tldCB3aGV0aGVyIG9yIG5v dApAQCAtODQsOCArODksMjkgQEAgbnVsbCBwb2ludGVyIHBhc3NlZCBhcyBpdHMKIC5GYSBmcm9t CiBhcmd1bWVudC4KIC5QcAotQWxsIHRocmVlIHJvdXRpbmVzIHJldHVybiB0aGUgbGVuZ3RoIG9m IHRoZSBtZXNzYWdlIG9uIHN1Y2Nlc3NmdWwKLWNvbXBsZXRpb24uCitUaGUKKy5GbiByZWN2bW1z ZworZnVuY3Rpb24gaXMgdXNlZCB0byByZWNlaXZlIG11bHRpcGxlCittZXNzYWdlcyBhdCBhIGNh bGwuCitUaGVpciBudW1iZXIgaXMgc3VwcGxpZWQgYnkKKy5GYSB2bGVuIC4KK1RoZSBtZXNzYWdl cyBhcmUgcGxhY2VkIGluIHRoZQorLkZhIG1zZ3ZlYwordmVjdG9yIGFmdGVyIHJlY2VwdGlvbi4K K1RoZSBzaXplIG9mIGVhY2ggcmVjZWl2ZWQgbWVzc2FnZSBpcyBwbGFjZWQgaW4gdGhlCisuRmEg bXNnX2xlbgorZmllbGQgb2YgZWFjaCBlbGVtZW50IG9mIHRoZSB2ZWN0b3IuCitJZgorLkZhIHRp bWVvdXQKK2lzIE5VTEwgdGhlIGNhbGwgd2lsbCBub3JtYWxseSBibG9jay4KK090aGVyd2lzZSBp dCB3aWxsIHdhaXQgZm9yIGRhdGEgZm9yIHRoZSBzcGVjaWZpZWQgYW1vdW50IG9mIHRpbWUuCitJ ZiB0aGUgdGltZW91dCBleHBpcmVzIGFuZCB0aGVyZSBpcyBubyBkYXRhIHJlY2VpdmVkIGEgdmFs dWUgb2YgMCBpcyByZXR1cm5lZC4KK3Bwb2xsKDIpIGlzIHVzZWQgZm9yIHRoZSBpbXBsZW1lbnRh dGlvbiBvZiB0aGUgdGltZW91dCBtZWNoYW5pc20uCisuUHAKK1RoZSBmaXJzdCB0aHJlZSByb3V0 aW5lcyByZXR1cm4gdGhlIGxlbmd0aCBvZiB0aGUgbWVzc2FnZSBvbiBzdWNjZXNzZnVsCitjb21w bGV0aW9uIHdoZXJlYXMKKy5GbiByZWN2bW1zZworcmV0dXJucyB0aGUgbnVtYmVyIG9mIHJlY2Vp dmVkIG1lc3NhZ2VzLgogSWYgYSBtZXNzYWdlIGlzIHRvbyBsb25nIHRvIGZpdCBpbiB0aGUgc3Vw cGxpZWQgYnVmZmVyLAogZXhjZXNzIGJ5dGVzIG1heSBiZSBkaXNjYXJkZWQgZGVwZW5kaW5nIG9u IHRoZSB0eXBlIG9mIHNvY2tldAogdGhlIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgZnJvbSAoc2VlCkBA IC0xMDAsNyArMTI2LDkgQEAgaW4gd2hpY2ggY2FzZSB0aGUgdmFsdWUKIC5WYSBlcnJubwogaXMg c2V0IHRvCiAuRXIgRUFHQUlOIC4KLVRoZSByZWNlaXZlIGNhbGxzIG5vcm1hbGx5IHJldHVybiBh bnkgZGF0YSBhdmFpbGFibGUsCitUaGUgcmVjZWl2ZSBjYWxscyBleGNlcHQKKy5GbiByZWN2bW1z Zworbm9ybWFsbHkgcmV0dXJuIGFueSBkYXRhIGF2YWlsYWJsZSwKIHVwIHRvIHRoZSByZXF1ZXN0 ZWQgYW1vdW50LAogcmF0aGVyIHRoYW4gd2FpdGluZyBmb3IgcmVjZWlwdCBvZiB0aGUgZnVsbCBh bW91bnQgcmVxdWVzdGVkOwogdGhpcyBiZWhhdmlvciBpcyBhZmZlY3RlZCBieSB0aGUgc29ja2V0 LWxldmVsIG9wdGlvbnMKQEAgLTEyNyw2ICsxNTUsOSBAQCBvbmUgb3IgbW9yZSBvZiB0aGUgdmFs dWVzOgogLkl0IER2IE1TR19XQUlUQUxMIFRhIHdhaXQgZm9yIGZ1bGwgcmVxdWVzdCBvciBlcnJv cgogLkl0IER2IE1TR19ET05UV0FJVCBUYSBkbyBub3QgYmxvY2sKIC5JdCBEdiBNU0dfQ01TR19D TE9FWEVDIFRhIHNldCByZWNlaXZlZCBmZHMgY2xvc2Utb24tZXhlYworLkl0IER2IE1TR19XQUlU Rk9ST05FIFRhIGRvIG5vdCBibG9jayBhZnRlciByZWNlaXZpbmcgdGhlIGZpcnN0IG1lc3NhZ2UK KyhyZWxldmFudCBvbmx5IGZvcgorLkZuIHJlY3ZtbXNnICkKIC5FbAogLlBwCiBUaGUKQEAgLTE1 OCw2ICsxODksMTEgQEAgaXMgc2V0IHRvCiBUaGlzIGZsYWcgaXMgbm90IGF2YWlsYWJsZSBpbiBz dHJpY3QKIC5UbiBBTlNJCiBvciBDOTkgY29tcGlsYXRpb24gbW9kZS4KK1RoZQorLkR2IE1TR19X QUlURk9ST05FCitmbGFnIHNldHMgTVNHX0RPTlRXQUlUIGFmdGVyIHRoZSBmaXJzdCBtZXNzYWdl IGhhcyBiZWVuIHJlY2VpdmVkLgorVGhpcyBmbGFnIGlzIG9ubHkgcmVsZXZhbnQgZm9yCisuRm4g cmVjdm1tc2cgLgogLlBwCiBUaGUKIC5GbiByZWN2bXNnCkBAIC0yOTAsOSArMzI2LDMzIEBAIGNv bnRyb2wgZGF0YSB3ZXJlIGRpc2NhcmRlZCBkdWUgdG8gbGFjayBvZiBzcGFjZSBpbiB0aGUgYnVm ZmVyCiBmb3IgYW5jaWxsYXJ5IGRhdGEuCiAuRHYgTVNHX09PQgogaXMgcmV0dXJuZWQgdG8gaW5k aWNhdGUgdGhhdCBleHBlZGl0ZWQgb3Igb3V0LW9mLWJhbmQgZGF0YSB3ZXJlIHJlY2VpdmVkLgor LlBwCitUaGUKKy5GbiByZWN2bW1zZworc3lzdGVtIGNhbGwgdXNlcyB0aGUKKy5GYSBtbXNnaGRy CitzdHJ1Y3R1cmUuIEl0cyBmb3JtIGlzIGFzIGZvbGxvd3MsIGFzIGRlZmluZWQgaW4KKy5JbiBz eXMvc29ja2V0LmggOgorLkJkIC1saXRlcmFsCitzdHJ1Y3QgbW1zZ2hkciB7CisJc3RydWN0IG1z Z2hkcgkgbXNnX2hkcjsJLyogbWVzc2FnZSBoZWFkZXIgKi8KKwlzc2l6ZV90CQkgbXNnX2xlbjsJ LyogbWVzc2FnZSBsZW5ndGggKi8KK307CisuRWQKKy5QcAorRm9yCisuRmEgbXNnX2hkcgorc2Vl IGFib3ZlLiBPbiBkYXRhIHJlY2VwdGlvbiB0aGUKKy5GYSBtc2dfbGVuCitmaWVsZCBpcyB1cGRh dGVkIHRvIHRoZSBsZW5ndGggb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UuCitPbiBkYXRhIHRyYW5z bWlzc2lvbiBpdCBpcyB1cGRhdGVkIHRvIHRoZSBudW1iZXIgb2YgY2hhcmFjdGVycyBzZW50Lgog LlNoIFJFVFVSTiBWQUxVRVMKLVRoZXNlIGNhbGxzIHJldHVybiB0aGUgbnVtYmVyIG9mIGJ5dGVz IHJlY2VpdmVkLCBvciAtMQotaWYgYW4gZXJyb3Igb2NjdXJyZWQuCitUaGVzZSBjYWxscyBleGNl cHQKKy5GbiByZWN2bW1zZworcmV0dXJuIHRoZSBudW1iZXIgb2YgYnl0ZXMgcmVjZWl2ZWQuCisu Rm4gcmVjdm1tc2cKK3JldHVybnMgdGhlIG51bWJlciBvZiBtZXNzYWdlcyByZWNlaXZlZC4KK0Eg dmFsdWUgb2YgLTEgaXMgcmV0dXJuZWQgaWYgYW4gZXJyb3Igb2NjdXJyZWQuCiAuU2ggRVJST1JT CiBUaGUgY2FsbHMgZmFpbCBpZjoKIC5CbCAtdGFnIC13aWR0aCBFcgpkaWZmIC0tZ2l0IGEvbGli L2xpYmMvc3lzL3NlbmQuMiBiL2xpYi9saWJjL3N5cy9zZW5kLjIKaW5kZXggOGZhMmM2NC4uOTgx MGFjZSAxMDA2NDQKLS0tIGEvbGliL2xpYmMvc3lzL3NlbmQuMgorKysgYi9saWIvbGliYy9zeXMv c2VuZC4yCkBAIC0zNCw4ICszNCw5IEBACiAuU2ggTkFNRQogLk5tIHNlbmQgLAogLk5tIHNlbmR0 byAsCi0uTm0gc2VuZG1zZwotLk5kIHNlbmQgYSBtZXNzYWdlIGZyb20gYSBzb2NrZXQKKy5ObSBz ZW5kbXNnICwKKy5ObSBzZW5kbW1zZworLk5kIHNlbmQgbWVzc2FnZShzKSBmcm9tIGEgc29ja2V0 CiAuU2ggTElCUkFSWQogLkxiIGxpYmMKIC5TaCBTWU5PUFNJUwpAQCAtNDcsNiArNDgsOCBAQAog LkZuIHNlbmR0byAiaW50IHMiICJjb25zdCB2b2lkICptc2ciICJzaXplX3QgbGVuIiAiaW50IGZs YWdzIiAiY29uc3Qgc3RydWN0IHNvY2thZGRyICp0byIgInNvY2tsZW5fdCB0b2xlbiIKIC5GdCBz c2l6ZV90CiAuRm4gc2VuZG1zZyAiaW50IHMiICJjb25zdCBzdHJ1Y3QgbXNnaGRyICptc2ciICJp bnQgZmxhZ3MiCisuRnQgc3NpemVfdAorLkZuIHNlbmRtbXNnICJpbnQgcyIgInN0cnVjdCBtbXNn aGRyICogcmVzdHJpY3QgbXNndmVjIiAic2l6ZV90IHZsZW4iICJpbnQgZmxhZ3MiCiAuU2ggREVT Q1JJUFRJT04KIFRoZQogLkZuIHNlbmQKQEAgLTU1LDggKzU4LDExIEBAIGFuZAogLkZuIHNlbmR0 bwogYW5kCiAuRm4gc2VuZG1zZworYW5kCisuRm4gc2VuZG1tc2cKIHN5c3RlbSBjYWxscwotYXJl IHVzZWQgdG8gdHJhbnNtaXQgYSBtZXNzYWdlIHRvIGFub3RoZXIgc29ja2V0LgorYXJlIHVzZWQg dG8gdHJhbnNtaXQgb25lIG9yIG11bHRpcGxlIG1lc3NhZ2VzICh3aXRoIHRoZSBsYXR0ZXIgY2Fs bCkgdG8KK2Fub3RoZXIgc29ja2V0LgogVGhlCiAuRm4gc2VuZAogZnVuY3Rpb24KQEAgLTY2LDYg KzcyLDggQEAgc3RhdGUsIHdoaWxlCiAuRm4gc2VuZHRvCiBhbmQKIC5GbiBzZW5kbXNnCithbmQK Ky5GbiBzZW5kbW1zZwogbWF5IGJlIHVzZWQgYXQgYW55IHRpbWUuCiAuUHAKIFRoZSBhZGRyZXNz IG9mIHRoZSB0YXJnZXQgaXMgZ2l2ZW4gYnkKQEAgLTgxLDYgKzg5LDE4IEBAIHVuZGVybHlpbmcg cHJvdG9jb2wsIHRoZSBlcnJvcgogaXMgcmV0dXJuZWQsIGFuZAogdGhlIG1lc3NhZ2UgaXMgbm90 IHRyYW5zbWl0dGVkLgogLlBwCitUaGUKKy5GbiBzZW5kbW1zZworZnVuY3Rpb24gc2VuZHMgbXVs dGlwbGUgbWVzc2FnZXMgYXQgYSBjYWxsLgorVGhleSBhcmUgZ2l2ZW4gYnkgdGhlCisuRmEgbXNn dmVjCit2ZWN0b3IgYWxvbmcgd2l0aAorLkZhIHZsZW4KK3NwZWNpZnlpbmcgaXRzIHNpemUuCitU aGUgbnVtYmVyIG9mIGNoYXJhY3RlcnMgc2VudCBwZXIgZWFjaCBtZXNzYWdlIGlzIHBsYWNlZCBp biB0aGUKKy5GYSBtc2dfbGVuCitmaWVsZCBvZiBlYWNoIGVsZW1lbnQgb2YgdGhlIHZlY3RvciBh ZnRlciB0cmFuc21pc3Npb24uCisuUHAKIE5vIGluZGljYXRpb24gb2YgZmFpbHVyZSB0byBkZWxp dmVyIGlzIGltcGxpY2l0IGluIGEKIC5GbiBzZW5kIC4KIExvY2FsbHkgZGV0ZWN0ZWQgZXJyb3Jz IGFyZSBpbmRpY2F0ZWQgYnkgYSByZXR1cm4gdmFsdWUgb2YgLTEuCkBAIC0xMzgsMTAgKzE1OCwx NiBAQCBTZWUKIC5YciByZWN2IDIKIGZvciBhIGRlc2NyaXB0aW9uIG9mIHRoZQogLkZhIG1zZ2hk cgorc3RydWN0dXJlIGFuZCB0aGUKKy5GYSBtbXNnaGRyCiBzdHJ1Y3R1cmUuCiAuU2ggUkVUVVJO IFZBTFVFUwotVGhlIGNhbGwgcmV0dXJucyB0aGUgbnVtYmVyIG9mIGNoYXJhY3RlcnMgc2VudCwg b3IgLTEKLWlmIGFuIGVycm9yIG9jY3VycmVkLgorQWxsIGNhbGxzIGV4Y2VwdAorLkZuIHNlbmRt bXNnCityZXR1cm4gdGhlIG51bWJlciBvZiBjaGFyYWN0ZXJzIHNlbnQuIFRoZQorLkZuIHNlbmRt bXNnCitjYWxsIHJldHVybnMgdGhlIG51bWJlciBvZiBtZXNzYWdlcyBzZW50LgorSWYgYW4gZXJy b3Igb2NjdXJyZWQgYSB2YWx1ZSBvZiAtMSBpcyByZXR1cm5lZC4KIC5TaCBFUlJPUlMKIFRoZQog LkZuIHNlbmQKQEAgLTE0OSw2ICsxNzUsOCBAQCBmdW5jdGlvbiBhbmQKIC5GbiBzZW5kdG8KIGFu ZAogLkZuIHNlbmRtc2cKK2FuZAorLkZuIHNlbmRtbXNnCiBzeXN0ZW0gY2FsbHMKIGZhaWwgaWY6 CiAuQmwgLXRhZyAtd2lkdGggRXIKZGlmZiAtLWdpdCBhL3N5cy9zeXMvc29ja2V0LmggYi9zeXMv c3lzL3NvY2tldC5oCmluZGV4IDE4ZTJkZTEuLjVkYTI4NmUgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMv c29ja2V0LmgKKysrIGIvc3lzL3N5cy9zb2NrZXQuaApAQCAtNDMxLDYgKzQzMSw3IEBAIHN0cnVj dCBtc2doZHIgewogI2RlZmluZQlNU0dfTkJJTwkweDQwMDAJCS8qIEZJT05CSU8gbW9kZSwgdXNl ZCBieSBmaWZvZnMgKi8KICNkZWZpbmUJTVNHX0NPTVBBVCAgICAgIDB4ODAwMAkJLyogdXNlZCBp biBzZW5kaXQoKSAqLwogI2RlZmluZQlNU0dfQ01TR19DTE9FWEVDIDB4NDAwMDAJLyogbWFrZSBy ZWNlaXZlZCBmZHMgY2xvc2Utb24tZXhlYyAqLworI2RlZmluZSBNU0dfV0FJVEZPUk9ORQkweDgw MDAwCQkvKiBmb3IgcmVjdm1tc2coKSAqLwogI2VuZGlmCiAjaWZkZWYgX0tFUk5FTAogI2RlZmlu ZQlNU0dfU09DQUxMQkNLICAgMHgxMDAwMAkJLyogZm9yIHVzZSBieSBzb2NrZXQgY2FsbGJhY2tz IC0gc29yZWNlaXZlIChUQ1ApICovCkBAIC01OTUsNiArNTk2LDE2IEBAIHN0cnVjdCBzZl9oZHRy IHsKICNlbmRpZiAvKiBfS0VSTkVMICovCiAjZW5kaWYgLyogX19CU0RfVklTSUJMRSAqLwogCisj aWZkZWYgX19CU0RfVklTSUJMRQorLyoKKyAqIFNlbmQvcmVjdm1tc2cgc3BlY2lmaWMgc3RydWN0 dXJlKHMpCisgKi8KK3N0cnVjdCBtbXNnaGRyIHsKKwlzdHJ1Y3QgbXNnaGRyCW1zZ19oZHI7CQkv KiBtZXNzYWdlIGhlYWRlciAqLworCXNzaXplX3QJCW1zZ19sZW47CQkvKiBtZXNzYWdlIGxlbmd0 aCAqLworfTsKKyNlbmRpZiAvKiBfX0JTRF9WSVNJQkxFICovCisKICNpZm5kZWYJX0tFUk5FTAog CiAjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CkBAIC02MTUsMTIgKzYyNiwxOCBAQCBpbnQJbGlzdGVu KGludCwgaW50KTsKIHNzaXplX3QJcmVjdihpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQpOwogc3Np emVfdAlyZWN2ZnJvbShpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQsIHN0cnVjdCBzb2NrYWRkciAq IF9fcmVzdHJpY3QsIHNvY2tsZW5fdCAqIF9fcmVzdHJpY3QpOwogc3NpemVfdAlyZWN2bXNnKGlu dCwgc3RydWN0IG1zZ2hkciAqLCBpbnQpOworI2lmIF9fQlNEX1ZJU0lCTEUKK3N0cnVjdCB0aW1l c3BlYzsKK3NzaXplX3QJcmVjdm1tc2coaW50LCBzdHJ1Y3QgbW1zZ2hkciAqIF9fcmVzdHJpY3Qs IHNpemVfdCwgaW50LAorICAgIGNvbnN0IHN0cnVjdCB0aW1lc3BlYyAqIF9fcmVzdHJpY3QpOwor I2VuZGlmCiBzc2l6ZV90CXNlbmQoaW50LCBjb25zdCB2b2lkICosIHNpemVfdCwgaW50KTsKIHNz aXplX3QJc2VuZHRvKGludCwgY29uc3Qgdm9pZCAqLAogCSAgICBzaXplX3QsIGludCwgY29uc3Qg c3RydWN0IHNvY2thZGRyICosIHNvY2tsZW5fdCk7CiBzc2l6ZV90CXNlbmRtc2coaW50LCBjb25z dCBzdHJ1Y3QgbXNnaGRyICosIGludCk7CiAjaWYgX19CU0RfVklTSUJMRQogaW50CXNlbmRmaWxl KGludCwgaW50LCBvZmZfdCwgc2l6ZV90LCBzdHJ1Y3Qgc2ZfaGR0ciAqLCBvZmZfdCAqLCBpbnQp Oworc3NpemVfdAlzZW5kbW1zZyhpbnQsIHN0cnVjdCBtbXNnaGRyICogX19yZXN0cmljdCwgc2l6 ZV90LCBpbnQpOwogaW50CXNldGZpYihpbnQpOwogI2VuZGlmCiBpbnQJc2V0c29ja29wdChpbnQs IGludCwgaW50LCBjb25zdCB2b2lkICosIHNvY2tsZW5fdCk7Cg== --089e01493c12b9cea1052a4e0f84-- From owner-freebsd-net@freebsd.org Wed Jan 27 10:19:12 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19641A6F36C for ; Wed, 27 Jan 2016 10:19:12 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E60871EDE for ; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E11C8A6F368; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFB7BA6F366; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6647C1EDB; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id 123so144879869wmz.0; Wed, 27 Jan 2016 02:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WC9W5H6mMXiCFJRU9WXALfCSEx5zg39f+zZ4DnRmd48=; b=gPNpyxGaRN6sgZz2ZQHZQfWAq6nyXy8EHAPAeQaTj4wVLscLtvqyICvuGXjpZxWoYk t5X1g0Npzur++LOBv9Ho216+p9uensJHjZddvxoOnf4x7dkI+dC6Vy7zj41L4Njsw5za pAQjuYGaFBS7ncttLcyJcgwccd/Lkn1HBQCP+M6blhO88z28TSYdcsrvll+Pz6igiEzx 7VMK0phhOn8loA7DjB/Xbcyz5Uyajvit0BB3ZPx+EPaTn2mVoSGqutpbir0z4/EmV9Oa Rh6OBSmOjiogNoXowJ3adb/Bj3hUonAIe1W4oJpwnR5235UPSj2kyhnf224AP93UyeWP NsVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WC9W5H6mMXiCFJRU9WXALfCSEx5zg39f+zZ4DnRmd48=; b=G9EgklghR/skg88bGHFGKVCn/BFpSQ7O1POiTzJXbymWpHqc6lFgIAEx30yDij9ZM6 JCDwbHM1L3Mh5RHVADzn85Hsu4I83gAs5daUfqqv0+X/I2WH6ct1LqqaHubaYa7t+C0g g6/Kfj1Y2tlk30fvNSZgmIXetDi2bTH2mbQJco+hszWOYE0/urtDDBGiwhO/qzLGjIM3 ZlUQNi04OIQEtWSZvosF7UuSBTBJ1/g0LL64CuzfYTlMPiTiekanqWpbmmEbjiVucO6e tx03tRuw9GTlrnLyBL8dDIcBHp6sn7g3jmZXT9OgU23O0FjFK3M/hpXyJQJlpEUWFR+A MFIw== X-Gm-Message-State: AG10YOSRhmBJMECUkWGSI6qL0iBMpBbtdtCxikWV6qvv1kGcU9377JC4vs/fU8cokX9MSzFU1sRutFL+jFLuag== MIME-Version: 1.0 X-Received: by 10.194.119.161 with SMTP id kv1mr23282212wjb.135.1453889949887; Wed, 27 Jan 2016 02:19:09 -0800 (PST) Received: by 10.28.136.148 with HTTP; Wed, 27 Jan 2016 02:19:09 -0800 (PST) In-Reply-To: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> Date: Wed, 27 Jan 2016 12:19:09 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Kevin Oberman Cc: Bruce Evans , Gary Jennejohn , Daniel Eischen , threads@freebsd.org, Luigi Rizzo , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 10:19:12 -0000 ba>Is it possible that ppoll() doesn't return an error and yet revents ba>have set either POLLERR or POLLHUP or POLLNVAL? Apart from timeout. On Wed, Jan 27, 2016 at 12:14 PM, Boris Astardzhiev < boris.astardzhiev@gmail.com> wrote: > Hello, > > I've made a few changes in the patch as recommended here starting with > the switch to ppoll(). I have a question since it's not quite clear to me > as written > in the manpage. Is it possible that ppoll() doesn't return an error and > yet revents > have set either POLLERR or POLLHUP or POLLNVAL? > > See patch and comments are again welcomed. > > > On Wed, Jan 27, 2016 at 6:07 AM, Kevin Oberman > wrote: > >> Since this has become a debate on programming style, it seem appropriate >> to mention that Edward Yourdan passed away last Tuesday. For those too >> young to recognize the name, he was the developer of modern structured >> programming. He did recognize the style rules are important, but not >> iron-clad. >> >> Kevin Oberman, Part time kid herder and retired Network Engineer >> E-mail: rkoberman@gmail.com >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >> >> On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans >> wrote: >> >>> On Wed, 27 Jan 2016, Gary Jennejohn wrote: >>> >>> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >>>> Daniel Eischen wrote: >>>> >>>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>>>> >>>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>>>> Luigi Rizzo wrote: >>>>>> >>>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>>>> wrote: >>>>>>> >>>>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>>> >>>>>>>>> +ssize_t >>>>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, >>>>>>>>> int flags, >>>>>>>>> + const struct timespec *__restrict timeout) >>>>>>>>> +{ >>>>>>>>> + size_t i, rcvd; >>>>>>>>> + ssize_t ret; >>>>>>>>> + >>>>>>>>> + if (timeout != NULL) { >>>>>>>>> + fd_set fds; >>>>>>>>> + int res; >>>>>>>>> >>>>>>>> Please move all local definitions to the beginning of the function. >>>>>>>> >>>>>>> >>>>>>> This style recommendation was from 30 years ago and is >>>>>>> bad programming practice, as it tends to complicate analysis >>>>>>> for the human and increase the chance of improper usage of >>>>>>> variables. >>>>>>> >>>>>>> We should move away from this for new code. >>>>>>> >>>>>> >>>>>> Really? I personally find having all variables grouped together >>>>>> much easier to understand. Stumbling across declarations in the >>>>>> middle of the code in a for-loop, for example, takes me by surprise. >>>>>> >>>>> >>> +1 >>> >>> I used to program in a strict version of the "new" style 25-30 years >>> ago, but learned better. In the strict version, every variable must >>> have minimal scope, so squillions of inner blocks are needed to limit >>> the scopes. Some deeply nested of course. This is a good obfuscation. >>> It even breaks -Wshadow by letting you have unrelated variables named >>> 'i' that don't shadow each other because their scope is limited. Such >>> variables are good in separate functions but not in the same function. >>> Understanding the code to see that the variables are actually unrelated >>> requires counting more braces than usual. If you don't do this >>> strictly then you get a random style with some variables declared at >>> the top and some in inner blocks for mostly historical reasons. A >>> strict style with all of the variables at the top is much easier to >>> write and read. >>> >>> I also greatly dislike initializing variables in their declarations. >>>>>> >>>>>> Maybe I'm just old fashioned since I have been writing C-code for >>>>>> more than 30 years. >>>>>> >>>>> >>>>> +1 >>>>> >>>>> Probably should be discouraged, but allowed on a case-by-case >>>>> basis. One could argue that if you need to declaration blocks >>>>> in the middle of code, then that code is too complex and should >>>>> be broken out into a separate function. >>>>> >>>> >>>> Right. >>>> >>> >>> Lots of inner blocks are good for both making simple code look complex >>> and making it easier to write the complex code in the same function, >>> at least if you use a tiny indentation so that you can have 40 levels >>> of indentation without needing a 500-column terminal. >>> >>> And code like this >>>> >>>> int func(void) >>>> { >>>> int baz, zot; >>>> [some more code] >>>> if (zot < 5) >>>> { >>>> int baz = 3; >>>> [more code] >>>> } >>>> [some more code] >>>> } >>>> >>>> is even worse. The compiler (clang) seems to consider this to >>>> merely be a reinitialization of baz, but a human might be confused. >>>> >>> >>> No, that is a different baz, and is warned about by Wshadow. >>> >>> Something like for (int i = 0; i < 2; i++) is IMHO OK. >>>> >>> >>> Except it is C++ style which is so forbidden that style(9) doesn't >>> know that it needs a rule to forbid it. >>> >>> The worst is C++ style that doesn't limit the scope -- a bunch of >>> variables at the top and then somewhere in the middle of the function >>> another variable is needed and it is declared at top level of the >>> function scope. I sometimes do this when in a hurry. The strict >>> K&R-C90 style requires opening an inner block to do little more than >>> hold the declaration and then (re)indenting and (re)formatting all >>> the code in the inner block. The C++ style reduces writability and >>> readability in a different way. It doesn't cause excessive indentation >>> but it doesn't limit the scope much differently than putting all the >>> declarations at the top. At least the reader can find the declarations >>> easily when they are at the top. >>> >>> Bruce >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > From owner-freebsd-net@freebsd.org Wed Jan 27 12:04:46 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A508A6F68F for ; Wed, 27 Jan 2016 12:04:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A7031C53 for ; Wed, 27 Jan 2016 12:04:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0RC4jRp044663 for ; Wed, 27 Jan 2016 12:04:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203922] The kern.ipc.acceptqueue limit is too low Date: Wed, 27 Jan 2016 12:04:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: needs-qa, patch, performance X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: white_knight@2ch.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 12:04:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203922 White Knight changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #162281|0 |1 is obsolete| | --- Comment #7 from White Knight --- Created attachment 166184 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166184&action= =3Dedit A patch which keeps the ABI of xsctp_inpc intact. This patch addresses comment #6 and keeps the xsctp_inpc ABI intact. It has also been updated to base r294778. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 27 12:34:20 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC805A46450 for ; Wed, 27 Jan 2016 12:34:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC97A1D17 for ; Wed, 27 Jan 2016 12:34:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0RCYKUf002381 for ; Wed, 27 Jan 2016 12:34:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206533] Missing Intel I219-V support in 10-STABLE and 11-CURRENT Date: Wed, 27 Jan 2016 12:34:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: royger@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable10? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 12:34:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206533 Roger Pau Monn=C3=83=C2=A9 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |royger@freebsd.org --- Comment #2 from Roger Pau Monn=C3=83=C2=A9 --- I'm not really sure if it's related to this or not, but I have an Intel I21= 8-V, to which the em driver attaches to and seems to work fine, but it only dete= cts the media as 100baseTX. I've tried to manually force it to 1000baseTX but t= hen it's unable to find a carrier. According to the specifications [0], I218-V should support 1Gbps. Is this know, or should I open a new bug? http://www.intel.com/content/www/us/en/embedded/products/networking/etherne= t-connection-i218-family.html --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 27 12:44:20 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 693E3A46767 for ; Wed, 27 Jan 2016 12:44:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FD551243 for ; Wed, 27 Jan 2016 12:44:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0RCiJXI006055 for ; Wed, 27 Jan 2016 12:44:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206533] Missing Intel I219-V support in 10-STABLE and 11-CURRENT Date: Wed, 27 Jan 2016 12:44:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: IntelNetworking, feature, needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable10? X-Bugzilla-Changed-Fields: bug_file_loc keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 12:44:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206533 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://reviews.freebsd.org | |/D3162 Keywords| |feature, needs-qa --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 27 12:45:39 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8090EA46842 for ; Wed, 27 Jan 2016 12:45:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70BC1130F for ; Wed, 27 Jan 2016 12:45:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0RCjcFO008273 for ; Wed, 27 Jan 2016 12:45:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206533] Intel I219-V in 11-CURRENT and 10-STABLE Date: Wed, 27 Jan 2016 12:45:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: IntelNetworking, feature, needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable10? X-Bugzilla-Changed-Fields: short_desc bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 12:45:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206533 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Missing Intel I219-V |Intel I219-V in 11-CURRENT |support in 10-STABLE and |and 10-STABLE |11-CURRENT | Status|In Progress |Open --- Comment #3 from Kubilay Kocak --- Can't be in In Progress without an Assignee, but we pull assignees, not pus= h. If the author of the review mentioned here would like to 'take' this issue = to track its progress, please do so --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 27 15:31:12 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7ADC7A70B0D for ; Wed, 27 Jan 2016 15:31:12 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64EC610B4 for ; Wed, 27 Jan 2016 15:31:11 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.200.208] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 15D00192ADC for ; Wed, 27 Jan 2016 15:31:04 +0000 (UTC) To: "freebsd-net@freebsd.org" From: Sean Bruno Subject: em/igb CFT Message-ID: <56A8E2B7.9010006@freebsd.org> Date: Wed, 27 Jan 2016 07:31:03 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 15:31:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Intel has posted a new review for an update to em/lem/igb here: https://reviews.freebsd.org/D3162 If you have time and hardware (em/lem/igb), please give this patch a spin on your hardware and post results to the phabricator review. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWqOK0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kl+YIAIDMyV2pLxkAgmMzHG8rVXN9 zwTZx6UyT2BNiOBWe9S1uF+VhLrHFrpxUn0v7wA7qMufHwcETpUE98THAb7JoeHa 7jn0HZTihP1MhZRUSq+pRemYO3PfR/K84w2tRLbRmbdB1s2JpNx3L3I4o8GH2l6O j0ovylAN+r0YgGqxqcDwMTDTMFwHb8tSiIy0yMfxgJgE2f/yepKU52O8dIjZ/xkk XBmutfc4Q/QEPJyBayjaCxukJPB9tp9EZ9WxPbA6jijGGjgxNqi02J5I/pPWHNmU 7ATikpBq13GurLN8r2SAXI7L2DwDQiSrE1sN/KkzcgzzjV/K2mweTH0HD9vfeE4= =+YOy -----END PGP SIGNATURE----- From owner-freebsd-net@freebsd.org Wed Jan 27 18:49:28 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2635CA6E58F for ; Wed, 27 Jan 2016 18:49:28 +0000 (UTC) (envelope-from mmcco@mykolab.com) Received: from mx-out01.mykolab.com (mx01.mykolab.com [95.128.36.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E958D157D for ; Wed, 27 Jan 2016 18:49:26 +0000 (UTC) (envelope-from mmcco@mykolab.com) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out01.mykolab.com (Postfix) with ESMTPS id 49A4161DDC for ; Wed, 27 Jan 2016 19:43:56 +0100 (CET) Date: Wed, 27 Jan 2016 13:43:52 -0500 From: Michael McConville To: freebsd-net@freebsd.org Subject: Undefined shift overflow in dhclient(8) Message-ID: <20160127184352.GA3148@thinkpad.swarthmore.edu> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 18:49:28 -0000 I fixed this in OpenBSD yesterday. Details: https://marc.info/?l=openbsd-tech&m=145377854103866&w=2 Index: sbin/dhclient/dhclient.c =================================================================== --- sbin/dhclient/dhclient.c (revision 294200) +++ sbin/dhclient/dhclient.c (working copy) @@ -138,7 +138,7 @@ findproto(char *cp, int n) { struct sockaddr *sa; - int i; + unsigned int i; if (n == 0) return -1; From owner-freebsd-net@freebsd.org Wed Jan 27 20:02:39 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2ED99A7055C for ; Wed, 27 Jan 2016 20:02:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 13F661B27 for ; Wed, 27 Jan 2016 20:02:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 107F8A7055A; Wed, 27 Jan 2016 20:02:39 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBD0AA70558; Wed, 27 Jan 2016 20:02:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95B9A1B24; Wed, 27 Jan 2016 20:02:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0RK2VUL030962 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Jan 2016 22:02:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0RK2VUL030962 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0RK2U3D030960; Wed, 27 Jan 2016 22:02:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Jan 2016 22:02:30 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Kevin Oberman , Daniel Eischen , Gary Jennejohn , "freebsd-net@freebsd.org" , threads@freebsd.org, Luigi Rizzo Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160127200230.GG74231@kib.kiev.ua> References: <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 20:02:39 -0000 On Wed, Jan 27, 2016 at 12:14:02PM +0200, Boris Astardzhiev wrote: > Hello, > > I've made a few changes in the patch as recommended here starting with > the switch to ppoll(). I have a question since it's not quite clear to me > as written > in the manpage. Is it possible that ppoll() doesn't return an error and yet > revents > have set either POLLERR or POLLHUP or POLLNVAL? Ppoll() returned error means that the error is global for the syscall, i.e. the whole syscall execution was either impossible due to invalid parameters, or external event like signal delivery interrupted the execution. Individual file descriptors events like POLLHUP (EOF detected) or POLLNVAL (fd closed meantime) or POLLERR (whatever meaning the file type is provided for exceptional and not error situation) are not global errors. > +#include > +__FBSDID("$FreeBSD$"); > + > +#include > +#include > +#include > +#include Order sys/*.h alphabetically, except sys/types.h which comes first. Note that poll.h and stddef.h are not sys/, at least not for userspace consumers. > +#include "libc_private.h" > + > +#define POLLMASK (POLLIN | POLLRDNORM | POLLRDBAND | POLLPRI) > +#define EPOLLMASK (POLLERR | POLLHUP | POLLNVAL) I do not like these definitions which are used once. They only make reading the code harder. I do not think that it is needed to check for EPOLLMASK. POLLHUP or POLLERR would result in the corresponding action on recvmsg(2), while you cannot realistically replicate the kernel logic to report the state, so it is better to delegate the handling to kernel. POLLNVAL means that the file descriptor was either invalid outright or closed during the call, i.e. a bug in the caller. > + > +ssize_t > +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, > + const struct timespec *__restrict timeout) > +{ > + struct pollfd pfd[1]; > + size_t i, rcvd; > + ssize_t ret; > + int res; > + > + if (timeout != NULL) { > + pfd[0].fd = s; > + pfd[0].events = POLLMASK; > + pfd[0].revents = 0; > + res = ppoll(&pfd[0], 1, timeout, NULL); > + if (res == -1 || res == 0) > + return (res); > + if (pfd[0].revents & EPOLLMASK || > + (pfd[0].revents & POLLMASK) == 0) > + return (-1); > + } Fix the poll use and hopefully the patch is finished. Do you have any tests written ? Please provide me the tests. From owner-freebsd-net@freebsd.org Wed Jan 27 22:29:28 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 397DBA6F6B9 for ; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2346E1243 for ; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 20134A6F6B7; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04D42A6F6B6; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id E1B5C1241; Wed, 27 Jan 2016 22:29:27 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8001:cee1:c548:2788:e3cb:8a45]) by elvis.mu.org (Postfix) with ESMTPSA id 779D4345A921; Wed, 27 Jan 2016 14:29:27 -0800 (PST) Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? To: Luigi Rizzo , gljennjohn@gmail.com References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> Cc: Daniel Eischen , threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" From: Alfred Perlstein Organization: FreeBSD Message-ID: <56A944C6.1040603@freebsd.org> Date: Wed, 27 Jan 2016 14:29:26 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:29:28 -0000 On 1/26/16 4:39 PM, Luigi Rizzo wrote: > On Tue, Jan 26, 2016 at 4:31 PM, Gary Jennejohn wrote: >> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >> Daniel Eischen wrote: >> >>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>> >>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>> Luigi Rizzo wrote: >>>> >>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>> wrote: >>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>> +ssize_t >>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >>>>>>> + const struct timespec *__restrict timeout) >>>>>>> +{ >>>>>>> + size_t i, rcvd; >>>>>>> + ssize_t ret; >>>>>>> + >>>>>>> + if (timeout != NULL) { >>>>>>> + fd_set fds; >>>>>>> + int res; >>>>>> Please move all local definitions to the beginning of the function. >>>>> This style recommendation was from 30 years ago and is >>>>> bad programming practice, as it tends to complicate analysis >>>>> for the human and increase the chance of improper usage of >>>>> variables. >>>>> >>>>> We should move away from this for new code. >>>>> >>>> Really? I personally find having all variables grouped together >>>> much easier to understand. Stumbling across declarations in the >>>> middle of the code in a for-loop, for example, takes me by surprise. >>>> >>>> I also greatly dislike initializing variables in their declarations. >>>> >>>> Maybe I'm just old fashioned since I have been writing C-code for >>>> more than 30 years. >>> +1 >>> >>> Probably should be discouraged, but allowed on a case-by-case >>> basis. One could argue that if you need to declaration blocks >>> in the middle of code, then that code is too complex and should >>> be broken out into a separate function. >>> >> Right. >> >> And code like this >> >> int func(void) >> { >> int baz, zot; >> [some more code] >> if (zot < 5) >> { >> int baz = 3; >> [more code] >> } >> [some more code] >> } >> >> is even worse. The compiler (clang) seems to consider this to >> merely be a reinitialization of baz, but a human might be confused. > oh please... :) > > This is simply an inner variable shadowing the outer one > (which is another poor practice, flagged with -Wshadow ). > When you exit the scope you get the external variable > with its value, as you can see from the following code. > > #include > int main(int ac, char *av[]) > { > int baz = 5; > printf("1 baz %d\n", baz); > { > int baz = 3; > printf("2 baz %d\n", baz); > } > printf("3 baz %d\n", baz); > return 0; > } > I agree wholeheartedly with Luigi. I am also surprised that shadowed variable warnings was not more widely understood. It's time to move forward and make the code more readable and maintainable. Having scoped variables just makes sense. It's true that if you see very many of them, then it's likely time to introduce separate functions, but only in extreme cases, not on a case-by-case basis. -Alfred From owner-freebsd-net@freebsd.org Wed Jan 27 22:32:07 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86687A6F8FC for ; Wed, 27 Jan 2016 22:32:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C6F4176C for ; Wed, 27 Jan 2016 22:32:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0RMW7pd013905 for ; Wed, 27 Jan 2016 22:32:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 161277] [em] [patch] BMC cannot receive IPMI traffic after loading or enabling the if_em driver Date: Wed, 27 Jan 2016 22:32:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:32:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D161277 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: marius Date: Wed Jan 27 22:31:09 UTC 2016 New revision: 294958 URL: https://svnweb.freebsd.org/changeset/base/294958 Log: Sync the e1000 drivers with what's in head as of r294327, modulo parts that don't apply to stable/10 (driver API, if_inc_counter(), RSS changes etc.) and modulo r287465 (which reportedly breaks igb(4)), i. e. assorted fixes and improvements only: o MFC r267385 (partial): - Don't compare bus_dma map pointers for static DMA allocations against NULL to determine if bus_dmamap_unload() or bus_dmamem_free() should = be called. Instead, check the associated bus and virtual addresses. - Don't clear static DMA maps to NULL. o MFC r284933: Delete the refernce to VLAN handling being disabled by default. This is no longer the case. [1] o MFC r285639: Add an adapter CORE lock in the DDB hook em_dump_queue to avoid WITNESS panic in em_init_locked() while debugging. o MFC r285879: - Remove unused txd_saved. - Intialize txd_upper, txd_lower and txd_used at declaration. o MFC r286162: Free mbufs when busdma loading fails. o MFC r286829: Add capability to disable CRC stripping as it breaks IPMI/BMC capabilit= ies on certain adatpers. [2] o MFC r286831: [3] - Increase EM_MAX_SCATTER to 64 such that the size of em_xmit():: segs[EM_MAX_SCATTER] doesn't get overrun by things like NFS that can and do shove more than 32 segs when being used with em(4) and TSO4. - Update tso handling code in em_xmit() with update from jhb@ - Set if_hw_tsomax, if_hw_tsomaxsegcount and if_hw_tsomaxsegsize to appropriate values. - Define a TSO workaround "magic" number of 4 that is used to avoid an alignment issue in hardware. - Change a couple of integer values that were used as booleans to actual bool types. - Ensure that em_enable_intr() enables the appropriate mask of interrup= ts and not just a hardcoded define of values. o MFC r286832: e1000/if_lem.c bump to 1.1.0 o MFC r286833: Bump all copywrite dates to 2015. o MFC r287112: Style/whitespace cleanup in shared/common code. o MFC r293331: - Switch em(4) to the extended RX descriptor format. - Split rxbuffer and txbuffer apart to support the new RX descriptor format structures. Move rxbuffer manipulation to em_setup_rxdesc() to unify the new behavior changes. - Add a RSSKEYLEN macro for help in generating the RSSKEY data structur= es in the card. - Change em_receive_checksum() to process the new rxdescriptor format status bit. o MFC r293332: Disable the reuse of checksum offload context descriptors in the case of multiple queues in em(4). Document errata in the code. o MFC r293854: Given that em(4), lem(4) and igb(4) hardware doesn't require the alignment guarantees provided by m_defrag(9), use m_collapse(9) instead for performance reasons. While at it, sanitize the statistics softc members, i. e. retire unused ones and add SYSCTL nodes missing for actually used ones. PR: 118693 [1], 161277 [2], 195078 [3], 199174 [3], 200221 [3] Changes: _U stable/10/ stable/10/share/man/man4/em.4 stable/10/sys/dev/e1000/e1000_80003es2lan.c stable/10/sys/dev/e1000/e1000_80003es2lan.h stable/10/sys/dev/e1000/e1000_82540.c stable/10/sys/dev/e1000/e1000_82541.c stable/10/sys/dev/e1000/e1000_82541.h stable/10/sys/dev/e1000/e1000_82542.c stable/10/sys/dev/e1000/e1000_82543.c stable/10/sys/dev/e1000/e1000_82543.h stable/10/sys/dev/e1000/e1000_82571.c stable/10/sys/dev/e1000/e1000_82571.h stable/10/sys/dev/e1000/e1000_82575.c stable/10/sys/dev/e1000/e1000_82575.h stable/10/sys/dev/e1000/e1000_api.c stable/10/sys/dev/e1000/e1000_api.h stable/10/sys/dev/e1000/e1000_defines.h stable/10/sys/dev/e1000/e1000_hw.h stable/10/sys/dev/e1000/e1000_i210.c stable/10/sys/dev/e1000/e1000_i210.h stable/10/sys/dev/e1000/e1000_ich8lan.c stable/10/sys/dev/e1000/e1000_ich8lan.h stable/10/sys/dev/e1000/e1000_mac.c stable/10/sys/dev/e1000/e1000_mac.h stable/10/sys/dev/e1000/e1000_manage.c stable/10/sys/dev/e1000/e1000_manage.h stable/10/sys/dev/e1000/e1000_mbx.c stable/10/sys/dev/e1000/e1000_mbx.h stable/10/sys/dev/e1000/e1000_nvm.c stable/10/sys/dev/e1000/e1000_nvm.h stable/10/sys/dev/e1000/e1000_osdep.c stable/10/sys/dev/e1000/e1000_osdep.h stable/10/sys/dev/e1000/e1000_phy.c stable/10/sys/dev/e1000/e1000_phy.h stable/10/sys/dev/e1000/e1000_regs.h stable/10/sys/dev/e1000/e1000_vf.c stable/10/sys/dev/e1000/e1000_vf.h stable/10/sys/dev/e1000/if_em.c stable/10/sys/dev/e1000/if_em.h stable/10/sys/dev/e1000/if_igb.c stable/10/sys/dev/e1000/if_igb.h stable/10/sys/dev/e1000/if_lem.c stable/10/sys/dev/e1000/if_lem.h stable/10/sys/dev/ixgb/if_ixgb.c stable/10/sys/dev/netmap/if_em_netmap.h --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 27 22:32:11 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 842B3A6F921 for ; Wed, 27 Jan 2016 22:32:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6AB261791 for ; Wed, 27 Jan 2016 22:32:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0RMWA1j014007 for ; Wed, 27 Jan 2016 22:32:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199174] em tx and rx hang Date: Wed, 27 Jan 2016 22:32:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: sbruno@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:32:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D199174 --- Comment #34 from commit-hook@freebsd.org --- A commit references this bug: Author: marius Date: Wed Jan 27 22:31:10 UTC 2016 New revision: 294958 URL: https://svnweb.freebsd.org/changeset/base/294958 Log: Sync the e1000 drivers with what's in head as of r294327, modulo parts that don't apply to stable/10 (driver API, if_inc_counter(), RSS changes etc.) and modulo r287465 (which reportedly breaks igb(4)), i. e. assorted fixes and improvements only: o MFC r267385 (partial): - Don't compare bus_dma map pointers for static DMA allocations against NULL to determine if bus_dmamap_unload() or bus_dmamem_free() should = be called. Instead, check the associated bus and virtual addresses. - Don't clear static DMA maps to NULL. o MFC r284933: Delete the refernce to VLAN handling being disabled by default. This is no longer the case. [1] o MFC r285639: Add an adapter CORE lock in the DDB hook em_dump_queue to avoid WITNESS panic in em_init_locked() while debugging. o MFC r285879: - Remove unused txd_saved. - Intialize txd_upper, txd_lower and txd_used at declaration. o MFC r286162: Free mbufs when busdma loading fails. o MFC r286829: Add capability to disable CRC stripping as it breaks IPMI/BMC capabilit= ies on certain adatpers. [2] o MFC r286831: [3] - Increase EM_MAX_SCATTER to 64 such that the size of em_xmit():: segs[EM_MAX_SCATTER] doesn't get overrun by things like NFS that can and do shove more than 32 segs when being used with em(4) and TSO4. - Update tso handling code in em_xmit() with update from jhb@ - Set if_hw_tsomax, if_hw_tsomaxsegcount and if_hw_tsomaxsegsize to appropriate values. - Define a TSO workaround "magic" number of 4 that is used to avoid an alignment issue in hardware. - Change a couple of integer values that were used as booleans to actual bool types. - Ensure that em_enable_intr() enables the appropriate mask of interrup= ts and not just a hardcoded define of values. o MFC r286832: e1000/if_lem.c bump to 1.1.0 o MFC r286833: Bump all copywrite dates to 2015. o MFC r287112: Style/whitespace cleanup in shared/common code. o MFC r293331: - Switch em(4) to the extended RX descriptor format. - Split rxbuffer and txbuffer apart to support the new RX descriptor format structures. Move rxbuffer manipulation to em_setup_rxdesc() to unify the new behavior changes. - Add a RSSKEYLEN macro for help in generating the RSSKEY data structur= es in the card. - Change em_receive_checksum() to process the new rxdescriptor format status bit. o MFC r293332: Disable the reuse of checksum offload context descriptors in the case of multiple queues in em(4). Document errata in the code. o MFC r293854: Given that em(4), lem(4) and igb(4) hardware doesn't require the alignment guarantees provided by m_defrag(9), use m_collapse(9) instead for performance reasons. While at it, sanitize the statistics softc members, i. e. retire unused ones and add SYSCTL nodes missing for actually used ones. PR: 118693 [1], 161277 [2], 195078 [3], 199174 [3], 200221 [3] Changes: _U stable/10/ stable/10/share/man/man4/em.4 stable/10/sys/dev/e1000/e1000_80003es2lan.c stable/10/sys/dev/e1000/e1000_80003es2lan.h stable/10/sys/dev/e1000/e1000_82540.c stable/10/sys/dev/e1000/e1000_82541.c stable/10/sys/dev/e1000/e1000_82541.h stable/10/sys/dev/e1000/e1000_82542.c stable/10/sys/dev/e1000/e1000_82543.c stable/10/sys/dev/e1000/e1000_82543.h stable/10/sys/dev/e1000/e1000_82571.c stable/10/sys/dev/e1000/e1000_82571.h stable/10/sys/dev/e1000/e1000_82575.c stable/10/sys/dev/e1000/e1000_82575.h stable/10/sys/dev/e1000/e1000_api.c stable/10/sys/dev/e1000/e1000_api.h stable/10/sys/dev/e1000/e1000_defines.h stable/10/sys/dev/e1000/e1000_hw.h stable/10/sys/dev/e1000/e1000_i210.c stable/10/sys/dev/e1000/e1000_i210.h stable/10/sys/dev/e1000/e1000_ich8lan.c stable/10/sys/dev/e1000/e1000_ich8lan.h stable/10/sys/dev/e1000/e1000_mac.c stable/10/sys/dev/e1000/e1000_mac.h stable/10/sys/dev/e1000/e1000_manage.c stable/10/sys/dev/e1000/e1000_manage.h stable/10/sys/dev/e1000/e1000_mbx.c stable/10/sys/dev/e1000/e1000_mbx.h stable/10/sys/dev/e1000/e1000_nvm.c stable/10/sys/dev/e1000/e1000_nvm.h stable/10/sys/dev/e1000/e1000_osdep.c stable/10/sys/dev/e1000/e1000_osdep.h stable/10/sys/dev/e1000/e1000_phy.c stable/10/sys/dev/e1000/e1000_phy.h stable/10/sys/dev/e1000/e1000_regs.h stable/10/sys/dev/e1000/e1000_vf.c stable/10/sys/dev/e1000/e1000_vf.h stable/10/sys/dev/e1000/if_em.c stable/10/sys/dev/e1000/if_em.h stable/10/sys/dev/e1000/if_igb.c stable/10/sys/dev/e1000/if_igb.h stable/10/sys/dev/e1000/if_lem.c stable/10/sys/dev/e1000/if_lem.h stable/10/sys/dev/ixgb/if_ixgb.c stable/10/sys/dev/netmap/if_em_netmap.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 27 22:32:09 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8385EA6F906 for ; Wed, 27 Jan 2016 22:32:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 692E5177E for ; Wed, 27 Jan 2016 22:32:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0RMW99Z013993 for ; Wed, 27 Jan 2016 22:32:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195078] em tx_dma_fails and dropped packets Date: Wed, 27 Jan 2016 22:32:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: IntelNetworking, easy, regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:32:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195078 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: marius Date: Wed Jan 27 22:31:09 UTC 2016 New revision: 294958 URL: https://svnweb.freebsd.org/changeset/base/294958 Log: Sync the e1000 drivers with what's in head as of r294327, modulo parts that don't apply to stable/10 (driver API, if_inc_counter(), RSS changes etc.) and modulo r287465 (which reportedly breaks igb(4)), i. e. assorted fixes and improvements only: o MFC r267385 (partial): - Don't compare bus_dma map pointers for static DMA allocations against NULL to determine if bus_dmamap_unload() or bus_dmamem_free() should = be called. Instead, check the associated bus and virtual addresses. - Don't clear static DMA maps to NULL. o MFC r284933: Delete the refernce to VLAN handling being disabled by default. This is no longer the case. [1] o MFC r285639: Add an adapter CORE lock in the DDB hook em_dump_queue to avoid WITNESS panic in em_init_locked() while debugging. o MFC r285879: - Remove unused txd_saved. - Intialize txd_upper, txd_lower and txd_used at declaration. o MFC r286162: Free mbufs when busdma loading fails. o MFC r286829: Add capability to disable CRC stripping as it breaks IPMI/BMC capabilit= ies on certain adatpers. [2] o MFC r286831: [3] - Increase EM_MAX_SCATTER to 64 such that the size of em_xmit():: segs[EM_MAX_SCATTER] doesn't get overrun by things like NFS that can and do shove more than 32 segs when being used with em(4) and TSO4. - Update tso handling code in em_xmit() with update from jhb@ - Set if_hw_tsomax, if_hw_tsomaxsegcount and if_hw_tsomaxsegsize to appropriate values. - Define a TSO workaround "magic" number of 4 that is used to avoid an alignment issue in hardware. - Change a couple of integer values that were used as booleans to actual bool types. - Ensure that em_enable_intr() enables the appropriate mask of interrup= ts and not just a hardcoded define of values. o MFC r286832: e1000/if_lem.c bump to 1.1.0 o MFC r286833: Bump all copywrite dates to 2015. o MFC r287112: Style/whitespace cleanup in shared/common code. o MFC r293331: - Switch em(4) to the extended RX descriptor format. - Split rxbuffer and txbuffer apart to support the new RX descriptor format structures. Move rxbuffer manipulation to em_setup_rxdesc() to unify the new behavior changes. - Add a RSSKEYLEN macro for help in generating the RSSKEY data structur= es in the card. - Change em_receive_checksum() to process the new rxdescriptor format status bit. o MFC r293332: Disable the reuse of checksum offload context descriptors in the case of multiple queues in em(4). Document errata in the code. o MFC r293854: Given that em(4), lem(4) and igb(4) hardware doesn't require the alignment guarantees provided by m_defrag(9), use m_collapse(9) instead for performance reasons. While at it, sanitize the statistics softc members, i. e. retire unused ones and add SYSCTL nodes missing for actually used ones. PR: 118693 [1], 161277 [2], 195078 [3], 199174 [3], 200221 [3] Changes: _U stable/10/ stable/10/share/man/man4/em.4 stable/10/sys/dev/e1000/e1000_80003es2lan.c stable/10/sys/dev/e1000/e1000_80003es2lan.h stable/10/sys/dev/e1000/e1000_82540.c stable/10/sys/dev/e1000/e1000_82541.c stable/10/sys/dev/e1000/e1000_82541.h stable/10/sys/dev/e1000/e1000_82542.c stable/10/sys/dev/e1000/e1000_82543.c stable/10/sys/dev/e1000/e1000_82543.h stable/10/sys/dev/e1000/e1000_82571.c stable/10/sys/dev/e1000/e1000_82571.h stable/10/sys/dev/e1000/e1000_82575.c stable/10/sys/dev/e1000/e1000_82575.h stable/10/sys/dev/e1000/e1000_api.c stable/10/sys/dev/e1000/e1000_api.h stable/10/sys/dev/e1000/e1000_defines.h stable/10/sys/dev/e1000/e1000_hw.h stable/10/sys/dev/e1000/e1000_i210.c stable/10/sys/dev/e1000/e1000_i210.h stable/10/sys/dev/e1000/e1000_ich8lan.c stable/10/sys/dev/e1000/e1000_ich8lan.h stable/10/sys/dev/e1000/e1000_mac.c stable/10/sys/dev/e1000/e1000_mac.h stable/10/sys/dev/e1000/e1000_manage.c stable/10/sys/dev/e1000/e1000_manage.h stable/10/sys/dev/e1000/e1000_mbx.c stable/10/sys/dev/e1000/e1000_mbx.h stable/10/sys/dev/e1000/e1000_nvm.c stable/10/sys/dev/e1000/e1000_nvm.h stable/10/sys/dev/e1000/e1000_osdep.c stable/10/sys/dev/e1000/e1000_osdep.h stable/10/sys/dev/e1000/e1000_phy.c stable/10/sys/dev/e1000/e1000_phy.h stable/10/sys/dev/e1000/e1000_regs.h stable/10/sys/dev/e1000/e1000_vf.c stable/10/sys/dev/e1000/e1000_vf.h stable/10/sys/dev/e1000/if_em.c stable/10/sys/dev/e1000/if_em.h stable/10/sys/dev/e1000/if_igb.c stable/10/sys/dev/e1000/if_igb.h stable/10/sys/dev/e1000/if_lem.c stable/10/sys/dev/e1000/if_lem.h stable/10/sys/dev/ixgb/if_ixgb.c stable/10/sys/dev/netmap/if_em_netmap.h --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 27 22:32:16 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45170A6F93C for ; Wed, 27 Jan 2016 22:32:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 033E81847 for ; Wed, 27 Jan 2016 22:32:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0RMWDWT014110 for ; Wed, 27 Jan 2016 22:32:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200221] em0 watchdog timeout under load Date: Wed, 27 Jan 2016 22:32:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: IntelNetworking, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: sbruno@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:32:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200221 --- Comment #24 from commit-hook@freebsd.org --- A commit references this bug: Author: marius Date: Wed Jan 27 22:31:10 UTC 2016 New revision: 294958 URL: https://svnweb.freebsd.org/changeset/base/294958 Log: Sync the e1000 drivers with what's in head as of r294327, modulo parts that don't apply to stable/10 (driver API, if_inc_counter(), RSS changes etc.) and modulo r287465 (which reportedly breaks igb(4)), i. e. assorted fixes and improvements only: o MFC r267385 (partial): - Don't compare bus_dma map pointers for static DMA allocations against NULL to determine if bus_dmamap_unload() or bus_dmamem_free() should = be called. Instead, check the associated bus and virtual addresses. - Don't clear static DMA maps to NULL. o MFC r284933: Delete the refernce to VLAN handling being disabled by default. This is no longer the case. [1] o MFC r285639: Add an adapter CORE lock in the DDB hook em_dump_queue to avoid WITNESS panic in em_init_locked() while debugging. o MFC r285879: - Remove unused txd_saved. - Intialize txd_upper, txd_lower and txd_used at declaration. o MFC r286162: Free mbufs when busdma loading fails. o MFC r286829: Add capability to disable CRC stripping as it breaks IPMI/BMC capabilit= ies on certain adatpers. [2] o MFC r286831: [3] - Increase EM_MAX_SCATTER to 64 such that the size of em_xmit():: segs[EM_MAX_SCATTER] doesn't get overrun by things like NFS that can and do shove more than 32 segs when being used with em(4) and TSO4. - Update tso handling code in em_xmit() with update from jhb@ - Set if_hw_tsomax, if_hw_tsomaxsegcount and if_hw_tsomaxsegsize to appropriate values. - Define a TSO workaround "magic" number of 4 that is used to avoid an alignment issue in hardware. - Change a couple of integer values that were used as booleans to actual bool types. - Ensure that em_enable_intr() enables the appropriate mask of interrup= ts and not just a hardcoded define of values. o MFC r286832: e1000/if_lem.c bump to 1.1.0 o MFC r286833: Bump all copywrite dates to 2015. o MFC r287112: Style/whitespace cleanup in shared/common code. o MFC r293331: - Switch em(4) to the extended RX descriptor format. - Split rxbuffer and txbuffer apart to support the new RX descriptor format structures. Move rxbuffer manipulation to em_setup_rxdesc() to unify the new behavior changes. - Add a RSSKEYLEN macro for help in generating the RSSKEY data structur= es in the card. - Change em_receive_checksum() to process the new rxdescriptor format status bit. o MFC r293332: Disable the reuse of checksum offload context descriptors in the case of multiple queues in em(4). Document errata in the code. o MFC r293854: Given that em(4), lem(4) and igb(4) hardware doesn't require the alignment guarantees provided by m_defrag(9), use m_collapse(9) instead for performance reasons. While at it, sanitize the statistics softc members, i. e. retire unused ones and add SYSCTL nodes missing for actually used ones. PR: 118693 [1], 161277 [2], 195078 [3], 199174 [3], 200221 [3] Changes: _U stable/10/ stable/10/share/man/man4/em.4 stable/10/sys/dev/e1000/e1000_80003es2lan.c stable/10/sys/dev/e1000/e1000_80003es2lan.h stable/10/sys/dev/e1000/e1000_82540.c stable/10/sys/dev/e1000/e1000_82541.c stable/10/sys/dev/e1000/e1000_82541.h stable/10/sys/dev/e1000/e1000_82542.c stable/10/sys/dev/e1000/e1000_82543.c stable/10/sys/dev/e1000/e1000_82543.h stable/10/sys/dev/e1000/e1000_82571.c stable/10/sys/dev/e1000/e1000_82571.h stable/10/sys/dev/e1000/e1000_82575.c stable/10/sys/dev/e1000/e1000_82575.h stable/10/sys/dev/e1000/e1000_api.c stable/10/sys/dev/e1000/e1000_api.h stable/10/sys/dev/e1000/e1000_defines.h stable/10/sys/dev/e1000/e1000_hw.h stable/10/sys/dev/e1000/e1000_i210.c stable/10/sys/dev/e1000/e1000_i210.h stable/10/sys/dev/e1000/e1000_ich8lan.c stable/10/sys/dev/e1000/e1000_ich8lan.h stable/10/sys/dev/e1000/e1000_mac.c stable/10/sys/dev/e1000/e1000_mac.h stable/10/sys/dev/e1000/e1000_manage.c stable/10/sys/dev/e1000/e1000_manage.h stable/10/sys/dev/e1000/e1000_mbx.c stable/10/sys/dev/e1000/e1000_mbx.h stable/10/sys/dev/e1000/e1000_nvm.c stable/10/sys/dev/e1000/e1000_nvm.h stable/10/sys/dev/e1000/e1000_osdep.c stable/10/sys/dev/e1000/e1000_osdep.h stable/10/sys/dev/e1000/e1000_phy.c stable/10/sys/dev/e1000/e1000_phy.h stable/10/sys/dev/e1000/e1000_regs.h stable/10/sys/dev/e1000/e1000_vf.c stable/10/sys/dev/e1000/e1000_vf.h stable/10/sys/dev/e1000/if_em.c stable/10/sys/dev/e1000/if_em.h stable/10/sys/dev/e1000/if_igb.c stable/10/sys/dev/e1000/if_igb.h stable/10/sys/dev/e1000/if_lem.c stable/10/sys/dev/e1000/if_lem.h stable/10/sys/dev/ixgb/if_ixgb.c stable/10/sys/dev/netmap/if_em_netmap.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Jan 28 00:43:26 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3E41A6F61A for ; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CAD3B19EC for ; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C9573A6F617; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8CC8A6F616; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0E4419EA; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u0S0hIuW028478; Wed, 27 Jan 2016 19:43:18 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 27 Jan 2016 19:43:18 -0500 (EST) Date: Wed, 27 Jan 2016 19:43:18 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Alfred Perlstein cc: Luigi Rizzo , gljennjohn@gmail.com, threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <56A944C6.1040603@freebsd.org> Message-ID: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <56A944C6.1040603@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 00:43:27 -0000 On Wed, 27 Jan 2016, Alfred Perlstein wrote: > > > On 1/26/16 4:39 PM, Luigi Rizzo wrote: >> On Tue, Jan 26, 2016 at 4:31 PM, Gary Jennejohn >> wrote: >>> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >>> Daniel Eischen wrote: >>> >>>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>>> >>>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>>> Luigi Rizzo wrote: >>>>> >>>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>>> wrote: >>>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>>> +ssize_t >>>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int >>>>>>>> flags, >>>>>>>> + const struct timespec *__restrict timeout) >>>>>>>> +{ >>>>>>>> + size_t i, rcvd; >>>>>>>> + ssize_t ret; >>>>>>>> + >>>>>>>> + if (timeout != NULL) { >>>>>>>> + fd_set fds; >>>>>>>> + int res; >>>>>>> Please move all local definitions to the beginning of the function. >>>>>> This style recommendation was from 30 years ago and is >>>>>> bad programming practice, as it tends to complicate analysis >>>>>> for the human and increase the chance of improper usage of >>>>>> variables. >>>>>> >>>>>> We should move away from this for new code. >>>>>> >>>>> Really? I personally find having all variables grouped together >>>>> much easier to understand. Stumbling across declarations in the >>>>> middle of the code in a for-loop, for example, takes me by surprise. >>>>> >>>>> I also greatly dislike initializing variables in their declarations. >>>>> >>>>> Maybe I'm just old fashioned since I have been writing C-code for >>>>> more than 30 years. >>>> +1 >>>> >>>> Probably should be discouraged, but allowed on a case-by-case >>>> basis. One could argue that if you need to declaration blocks >>>> in the middle of code, then that code is too complex and should >>>> be broken out into a separate function. >>>> >>> Right. >>> >>> And code like this >>> >>> int func(void) >>> { >>> int baz, zot; >>> [some more code] >>> if (zot < 5) >>> { >>> int baz = 3; >>> [more code] >>> } >>> [some more code] >>> } >>> >>> is even worse. The compiler (clang) seems to consider this to >>> merely be a reinitialization of baz, but a human might be confused. >> oh please... :) >> >> This is simply an inner variable shadowing the outer one >> (which is another poor practice, flagged with -Wshadow ). >> When you exit the scope you get the external variable >> with its value, as you can see from the following code. >> >> #include >> int main(int ac, char *av[]) >> { >> int baz = 5; >> printf("1 baz %d\n", baz); >> { >> int baz = 3; >> printf("2 baz %d\n", baz); >> } >> printf("3 baz %d\n", baz); >> return 0; >> } >> > I agree wholeheartedly with Luigi. I am also surprised that shadowed > variable warnings was not more widely understood. > > It's time to move forward and make the code more readable and maintainable. > Having scoped variables just makes sense. It's true that if you see very > many of them, then it's likely time to introduce separate functions, but only > in extreme cases, not on a case-by-case basis. -1 It certainly doesn't make it more readable for me. It seems like it is done out of sheer laziness as opposed to structuring the code better. -- DE From owner-freebsd-net@freebsd.org Thu Jan 28 05:14:08 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 216BAA70110 for ; Thu, 28 Jan 2016 05:14:08 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id 0003412EB for ; Thu, 28 Jan 2016 05:14:07 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id F2DD71060EC; Thu, 28 Jan 2016 05:14:07 +0000 (UTC) Date: Thu, 28 Jan 2016 05:14:07 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D5098+325+4e694d74d281089c@reviews.freebsd.org Subject: [Differential] [Request, 217 lines] D5098: hyperv/hn: Reorganize TX csum offloading Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D5098: hyperv/hn: Reorganize TX csum offloading X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk Thread-Index: MWY5NTZkMGRiYzcxOTg0MWVmNWQ1NWNiZWRh MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_2090b449f5d8745f07ed904ab1fd66c1" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 05:14:08 -0000 --b1_2090b449f5d8745f07ed904ab1fd66c1 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit sepherosa_gmail.com created this revision. sepherosa_gmail.com added reviewers: network, adrian, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com. sepherosa_gmail.com added a subscriber: freebsd-net-list. REVISION SUMMARY So that we don't need to access mbuf content for non-TSO offloading. REVISION DETAIL https://reviews.freebsd.org/D5098 AFFECTED FILES sys/dev/hyperv/netvsc/hv_net_vsc.h sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com Cc: freebsd-net-list --b1_2090b449f5d8745f07ed904ab1fd66c1 Content-Type: text/x-patch; charset=utf-8; name="D5098.12774.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D5098.12774.patch" ZGlmZiAtLWdpdCBhL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2Qu YyBiL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2QuYwotLS0gYS9z eXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0dnNjX2Rydl9mcmVlYnNkLmMKKysrIGIvc3lzL2Rl di9oeXBlcnYvbmV0dnNjL2h2X25ldHZzY19kcnZfZnJlZWJzZC5jCkBAIC0xNjcsMTYgKzE2Nyw2 IEBACiAjZGVmaW5lIEhOX1RYRF9GTEFHX0RNQU1BUAkweDIKIAogLyoKLSAqIEEgdW5pZmllZCBm bGFnIGZvciBhbGwgb3V0Ym91bmQgY2hlY2sgc3VtIGZsYWdzIGlzIHVzZWZ1bCwKLSAqIGFuZCBp dCBoZWxwcyBhdm9pZGluZyB1bm5lY2Vzc2FyeSBjaGVjayBzdW0gY2FsY3VsYXRpb24gaW4KLSAq IG5ldHdvcmsgZm9yd2FyZGluZyBzY2VuYXJpby4KLSAqLwotI2RlZmluZSBIVl9DU1VNX0ZPUl9P VVRCT1VORAkJCQkJCVwKLSAgICAoQ1NVTV9JUHxDU1VNX0lQX1VEUHxDU1VNX0lQX1RDUHxDU1VN X0lQX1NDVFB8Q1NVTV9JUF9UU098CQlcCi0gICAgQ1NVTV9JUF9JU0NTSXxDU1VNX0lQNl9VRFB8 Q1NVTV9JUDZfVENQfENTVU1fSVA2X1NDVFB8CQlcCi0gICAgQ1NVTV9JUDZfVFNPfENTVU1fSVA2 X0lTQ1NJKQotCi0vKgogICogT25seSBlbmFibGUgVURQIGNoZWNrc3VtIG9mZmxvYWRpbmcgd2hl biBpdCBpcyBvbiAyMDEyUjIgb3IKICAqIGxhdGVyLiAgVURQIGNoZWNrc3VtIG9mZmxvYWRpbmcg ZG9lc24ndCB3b3JrIG9uIGVhcmxpZXIKICAqIFdpbmRvd3MgcmVsZWFzZXMuCkBAIC0yNjUsNjIg KzI1NSw2IEBACiAjZW5kaWYKIH0KIAotLyoKLSAqIE5ldFZzYyBnZXQgbWVzc2FnZSB0cmFuc3Bv cnQgcHJvdG9jb2wgdHlwZSAKLSAqLwotc3RhdGljIHVpbnQzMl90IGdldF90cmFuc3BvcnRfcHJv dG9fdHlwZShzdHJ1Y3QgbWJ1ZiAqbV9oZWFkKQotewotCXVpbnQzMl90IHJldF92YWwgPSBUUkFO U1BPUlRfVFlQRV9OT1RfSVA7Ci0JdWludDE2X3QgZXRoZXJfdHlwZSA9IDA7Ci0JaW50IGV0aGVy X2xlbiA9IDA7Ci0Jc3RydWN0IGV0aGVyX3ZsYW5faGVhZGVyICplaDsKLSNpZmRlZiBJTkVUCi0J c3RydWN0IGlwICppcGg7Ci0jZW5kaWYKLSNpZmRlZiBJTkVUNgotCXN0cnVjdCBpcDZfaGRyICpp cDY7Ci0jZW5kaWYKLQotCWVoID0gbXRvZChtX2hlYWQsIHN0cnVjdCBldGhlcl92bGFuX2hlYWRl ciopOwotCWlmIChlaC0+ZXZsX2VuY2FwX3Byb3RvID09IGh0b25zKEVUSEVSVFlQRV9WTEFOKSkg ewotCQlldGhlcl9sZW4gPSBFVEhFUl9IRFJfTEVOICsgRVRIRVJfVkxBTl9FTkNBUF9MRU47Ci0J CWV0aGVyX3R5cGUgPSBlaC0+ZXZsX3Byb3RvOwotCX0gZWxzZSB7Ci0JCWV0aGVyX2xlbiA9IEVU SEVSX0hEUl9MRU47Ci0JCWV0aGVyX3R5cGUgPSBlaC0+ZXZsX2VuY2FwX3Byb3RvOwotCX0KLQot CXN3aXRjaCAobnRvaHMoZXRoZXJfdHlwZSkpIHsKLSNpZmRlZiBJTkVUNgotCWNhc2UgRVRIRVJU WVBFX0lQVjY6Ci0JCWlwNiA9IChzdHJ1Y3QgaXA2X2hkciAqKShtX2hlYWQtPm1fZGF0YSArIGV0 aGVyX2xlbik7Ci0KLQkJaWYgKElQUFJPVE9fVENQID09IGlwNi0+aXA2X254dCkgewotCQkJcmV0 X3ZhbCA9IFRSQU5TUE9SVF9UWVBFX0lQVjZfVENQOwotCQl9IGVsc2UgaWYgKElQUFJPVE9fVURQ ID09IGlwNi0+aXA2X254dCkgewotCQkJcmV0X3ZhbCA9IFRSQU5TUE9SVF9UWVBFX0lQVjZfVURQ OwotCQl9Ci0JCWJyZWFrOwotI2VuZGlmCi0jaWZkZWYgSU5FVAotCWNhc2UgRVRIRVJUWVBFX0lQ OgotCQlpcGggPSAoc3RydWN0IGlwICopKG1faGVhZC0+bV9kYXRhICsgZXRoZXJfbGVuKTsKLQot CQlpZiAoSVBQUk9UT19UQ1AgPT0gaXBoLT5pcF9wKSB7Ci0JCQlyZXRfdmFsID0gVFJBTlNQT1JU X1RZUEVfSVBWNF9UQ1A7Ci0JCX0gZWxzZSBpZiAoSVBQUk9UT19VRFAgPT0gaXBoLT5pcF9wKSB7 Ci0JCQlyZXRfdmFsID0gVFJBTlNQT1JUX1RZUEVfSVBWNF9VRFA7Ci0JCX0KLQkJYnJlYWs7Ci0j ZW5kaWYKLQlkZWZhdWx0OgotCQlyZXRfdmFsID0gVFJBTlNQT1JUX1RZUEVfTk9UX0lQOwotCQli cmVhazsKLQl9Ci0KLQlyZXR1cm4gKHJldF92YWwpOwotfQotCiBzdGF0aWMgaW50CiBobl9pZm1l ZGlhX3VwZChzdHJ1Y3QgaWZuZXQgKmlmcCBfX3VudXNlZCkKIHsKQEAgLTc4MywxNiArNzE3LDEz IEBACiAJaG5fc29mdGNfdCAqc2MgPSBpZnAtPmlmX3NvZnRjOwogCXN0cnVjdCBodl9kZXZpY2Ug KmRldmljZV9jdHggPSB2bWJ1c19nZXRfZGV2Y3R4KHNjLT5obl9kZXYpOwogCW5ldHZzY19kZXYg Km5ldF9kZXYgPSBzYy0+bmV0X2RldjsKLQlzdHJ1Y3QgZXRoZXJfdmxhbl9oZWFkZXIgKmVoOwog CXJuZGlzX21zZyAqcm5kaXNfbWVzZzsKIAlybmRpc19wYWNrZXQgKnJuZGlzX3BrdDsKIAlybmRp c19wZXJfcGFja2V0X2luZm8gKnJwcGk7CiAJbmRpc184MDIxcV9pbmZvICpycHBpX3ZsYW5faW5m bzsKIAlybmRpc190Y3BfaXBfY3N1bV9pbmZvICpjc3VtX2luZm87CiAJcm5kaXNfdGNwX3Rzb19p bmZvICp0c29faW5mbzsJCi0JaW50IGV0aGVyX2xlbjsKIAl1aW50MzJfdCBybmRpc19tc2dfc2l6 ZSA9IDA7Ci0JdWludDMyX3QgdHJhbnNfcHJvdG9fdHlwZTsKIAogCWlmICgoaWZwLT5pZl9kcnZf ZmxhZ3MgJiAoSUZGX0RSVl9SVU5OSU5HIHwgSUZGX0RSVl9PQUNUSVZFKSkgIT0KIAkgICAgSUZG X0RSVl9SVU5OSU5HKQpAQCAtODcyLDEwMSArODAzLDc4IEBACiAJCQkgICAgbV9oZWFkLT5tX3Br dGhkci5ldGhlcl92dGFnICYgMHhmZmY7CiAJCX0KIAotCQkvKiBPbmx5IGNoZWNrIHRoZSBmbGFn cyBmb3Igb3V0Ym91bmQgYW5kIGlnbm9yZSB0aGUgb25lcyBmb3IgaW5ib3VuZCAqLwotCQlpZiAo MCA9PSAobV9oZWFkLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgSFZfQ1NVTV9GT1JfT1VUQk9VTkQp KSB7Ci0JCQlnb3RvIHByZV9zZW5kOwotCQl9Ci0KLQkJZWggPSBtdG9kKG1faGVhZCwgc3RydWN0 IGV0aGVyX3ZsYW5faGVhZGVyKik7Ci0JCWlmIChlaC0+ZXZsX2VuY2FwX3Byb3RvID09IGh0b25z KEVUSEVSVFlQRV9WTEFOKSkgewotCQkJZXRoZXJfbGVuID0gRVRIRVJfSERSX0xFTiArIEVUSEVS X1ZMQU5fRU5DQVBfTEVOOwotCQl9IGVsc2UgewotCQkJZXRoZXJfbGVuID0gRVRIRVJfSERSX0xF TjsKLQkJfQotCi0JCXRyYW5zX3Byb3RvX3R5cGUgPSBnZXRfdHJhbnNwb3J0X3Byb3RvX3R5cGUo bV9oZWFkKTsKLQkJaWYgKFRSQU5TUE9SVF9UWVBFX05PVF9JUCA9PSB0cmFuc19wcm90b190eXBl KSB7Ci0JCQlnb3RvIHByZV9zZW5kOwotCQl9Ci0KLQkJLyoKLQkJICogVFNPIHBhY2tldCBuZWVk bGVzcyB0byBzZXR1cCB0aGUgc2VuZCBzaWRlIGNoZWNrc3VtCi0JCSAqIG9mZmxvYWQuCi0JCSAq LwogCQlpZiAobV9oZWFkLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NVTV9UU08pIHsKLQkJCWdv dG8gZG9fdHNvOwotCQl9Ci0KLQkJLyogc2V0dXAgY2hlY2tzdW0gb2ZmbG9hZCAqLwotCQlybmRp c19tc2dfc2l6ZSArPSBSTkRJU19DU1VNX1BQSV9TSVpFOwotCQlycHBpID0gaHZfc2V0X3JwcGlf ZGF0YShybmRpc19tZXNnLCBSTkRJU19DU1VNX1BQSV9TSVpFLAotCQkgICAgdGNwaXBfY2hrc3Vt X2luZm8pOwotCQljc3VtX2luZm8gPSAocm5kaXNfdGNwX2lwX2NzdW1faW5mbyAqKSgoY2hhciop cnBwaSArCi0JCSAgICBycHBpLT5wZXJfcGFja2V0X2luZm9fb2Zmc2V0KTsKLQotCQlpZiAodHJh bnNfcHJvdG9fdHlwZSAmIChUWVBFX0lQVjQgPDwgMTYpKSB7Ci0JCQljc3VtX2luZm8tPnhtaXQu aXNfaXB2NCA9IDE7Ci0JCX0gZWxzZSB7Ci0JCQljc3VtX2luZm8tPnhtaXQuaXNfaXB2NiA9IDE7 Ci0JCX0KKwkJCXN0cnVjdCBldGhlcl92bGFuX2hlYWRlciAqZWg7CisJCQlpbnQgZXRoZXJfbGVu OworCisJCQllaCA9IG10b2QobV9oZWFkLCBzdHJ1Y3QgZXRoZXJfdmxhbl9oZWFkZXIqKTsKKwkJ CWlmIChlaC0+ZXZsX2VuY2FwX3Byb3RvID09IGh0b25zKEVUSEVSVFlQRV9WTEFOKSkgeworCQkJ CWV0aGVyX2xlbiA9IEVUSEVSX0hEUl9MRU4gKworCQkJCSAgICBFVEhFUl9WTEFOX0VOQ0FQX0xF TjsKKwkJCX0gZWxzZSB7CisJCQkJZXRoZXJfbGVuID0gRVRIRVJfSERSX0xFTjsKKwkJCX0KIAot CQlpZiAodHJhbnNfcHJvdG9fdHlwZSAmIFRZUEVfVENQKSB7Ci0JCQljc3VtX2luZm8tPnhtaXQu dGNwX2NzdW0gPSAxOwotCQkJY3N1bV9pbmZvLT54bWl0LnRjcF9oZWFkZXJfb2Zmc2V0ID0gMDsK LQkJfSBlbHNlIGlmICh0cmFuc19wcm90b190eXBlICYgVFlQRV9VRFApIHsKLQkJCWNzdW1faW5m by0+eG1pdC51ZHBfY3N1bSA9IDE7Ci0JCX0KKwkJCXJuZGlzX21zZ19zaXplICs9IFJORElTX1RT T19QUElfU0laRTsKKwkJCXJwcGkgPSBodl9zZXRfcnBwaV9kYXRhKHJuZGlzX21lc2csIFJORElT X1RTT19QUElfU0laRSwKKwkJCSAgICB0Y3BfbGFyZ2Vfc2VuZF9pbmZvKTsKIAotCQlnb3RvIHBy ZV9zZW5kOworCQkJdHNvX2luZm8gPSAocm5kaXNfdGNwX3Rzb19pbmZvICopKChjaGFyICopcnBw aSArCisJCQkgICAgcnBwaS0+cGVyX3BhY2tldF9pbmZvX29mZnNldCk7CisJCQl0c29faW5mby0+ bHNvX3YyX3htaXQudHlwZSA9CisJCQkgICAgUk5ESVNfVENQX0xBUkdFX1NFTkRfT0ZGTE9BRF9W Ml9UWVBFOwogCi1kb190c286Ci0JCS8qIHNldHVwIFRDUCBzZWdtZW50YXRpb24gb2ZmbG9hZCAq LwotCQlybmRpc19tc2dfc2l6ZSArPSBSTkRJU19UU09fUFBJX1NJWkU7Ci0JCXJwcGkgPSBodl9z ZXRfcnBwaV9kYXRhKHJuZGlzX21lc2csIFJORElTX1RTT19QUElfU0laRSwKLQkJICAgIHRjcF9s YXJnZV9zZW5kX2luZm8pOwotCQkKLQkJdHNvX2luZm8gPSAocm5kaXNfdGNwX3Rzb19pbmZvICop KChjaGFyICopcnBwaSArCi0JCSAgICBycHBpLT5wZXJfcGFja2V0X2luZm9fb2Zmc2V0KTsKLQkJ dHNvX2luZm8tPmxzb192Ml94bWl0LnR5cGUgPQotCQkgICAgUk5ESVNfVENQX0xBUkdFX1NFTkRf T0ZGTE9BRF9WMl9UWVBFOwotCQkKICNpZmRlZiBJTkVUCi0JCWlmICh0cmFuc19wcm90b190eXBl ICYgKFRZUEVfSVBWNCA8PCAxNikpIHsKLQkJCXN0cnVjdCBpcCAqaXAgPQotCQkJICAgIChzdHJ1 Y3QgaXAgKikobV9oZWFkLT5tX2RhdGEgKyBldGhlcl9sZW4pOwotCQkJdW5zaWduZWQgbG9uZyBp cGhfbGVuID0gaXAtPmlwX2hsIDw8IDI7Ci0JCQlzdHJ1Y3QgdGNwaGRyICp0aCA9Ci0JCQkgICAg KHN0cnVjdCB0Y3BoZHIgKikoKGNhZGRyX3QpaXAgKyBpcGhfbGVuKTsKLQkJCi0JCQl0c29faW5m by0+bHNvX3YyX3htaXQuaXBfdmVyc2lvbiA9Ci0JCQkgICAgUk5ESVNfVENQX0xBUkdFX1NFTkRf T0ZGTE9BRF9JUFY0OwotCQkJaXAtPmlwX2xlbiA9IDA7Ci0JCQlpcC0+aXBfc3VtID0gMDsKLQkJ Ci0JCQl0aC0+dGhfc3VtID0gaW5fcHNldWRvKGlwLT5pcF9zcmMuc19hZGRyLAotCQkJICAgIGlw LT5pcF9kc3Quc19hZGRyLAotCQkJICAgIGh0b25zKElQUFJPVE9fVENQKSk7Ci0JCX0KKwkJCWlm IChtX2hlYWQtPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJiBDU1VNX0lQX1RTTykgeworCQkJCXN0cnVj dCBpcCAqaXAgPQorCQkJCSAgICAoc3RydWN0IGlwICopKG1faGVhZC0+bV9kYXRhICsgZXRoZXJf bGVuKTsKKwkJCQl1bnNpZ25lZCBsb25nIGlwaF9sZW4gPSBpcC0+aXBfaGwgPDwgMjsKKwkJCQlz dHJ1Y3QgdGNwaGRyICp0aCA9CisJCQkJICAgIChzdHJ1Y3QgdGNwaGRyICopKChjYWRkcl90KWlw ICsgaXBoX2xlbik7CisJCQkKKwkJCQl0c29faW5mby0+bHNvX3YyX3htaXQuaXBfdmVyc2lvbiA9 CisJCQkJICAgIFJORElTX1RDUF9MQVJHRV9TRU5EX09GRkxPQURfSVBWNDsKKwkJCQlpcC0+aXBf bGVuID0gMDsKKwkJCQlpcC0+aXBfc3VtID0gMDsKKwkJCQorCQkJCXRoLT50aF9zdW0gPSBpbl9w c2V1ZG8oaXAtPmlwX3NyYy5zX2FkZHIsCisJCQkJICAgIGlwLT5pcF9kc3Quc19hZGRyLCBodG9u cyhJUFBST1RPX1RDUCkpOworCQkJfQogI2VuZGlmCiAjaWYgZGVmaW5lZChJTkVUNikgJiYgZGVm aW5lZChJTkVUKQotCQllbHNlCisJCQllbHNlCiAjZW5kaWYKICNpZmRlZiBJTkVUNgotCQl7Ci0J CQlzdHJ1Y3QgaXA2X2hkciAqaXA2ID0KLQkJCSAgICAoc3RydWN0IGlwNl9oZHIgKikobV9oZWFk LT5tX2RhdGEgKyBldGhlcl9sZW4pOwotCQkJc3RydWN0IHRjcGhkciAqdGggPSAoc3RydWN0IHRj cGhkciAqKShpcDYgKyAxKTsKLQotCQkJdHNvX2luZm8tPmxzb192Ml94bWl0LmlwX3ZlcnNpb24g PQotCQkJICAgIFJORElTX1RDUF9MQVJHRV9TRU5EX09GRkxPQURfSVBWNjsKLQkJCWlwNi0+aXA2 X3BsZW4gPSAwOwotCQkJdGgtPnRoX3N1bSA9IGluNl9ja3N1bV9wc2V1ZG8oaXA2LCAwLCBJUFBS T1RPX1RDUCwgMCk7Ci0JCX0KKwkJCXsKKwkJCQlzdHJ1Y3QgaXA2X2hkciAqaXA2ID0gKHN0cnVj dCBpcDZfaGRyICopCisJCQkJICAgIChtX2hlYWQtPm1fZGF0YSArIGV0aGVyX2xlbik7CisJCQkJ c3RydWN0IHRjcGhkciAqdGggPSAoc3RydWN0IHRjcGhkciAqKShpcDYgKyAxKTsKKworCQkJCXRz b19pbmZvLT5sc29fdjJfeG1pdC5pcF92ZXJzaW9uID0KKwkJCQkgICAgUk5ESVNfVENQX0xBUkdF X1NFTkRfT0ZGTE9BRF9JUFY2OworCQkJCWlwNi0+aXA2X3BsZW4gPSAwOworCQkJCXRoLT50aF9z dW0gPQorCQkJCSAgICBpbjZfY2tzdW1fcHNldWRvKGlwNiwgMCwgSVBQUk9UT19UQ1AsIDApOwor CQkJfQogI2VuZGlmCi0JCXRzb19pbmZvLT5sc29fdjJfeG1pdC50Y3BfaGVhZGVyX29mZnNldCA9 IDA7Ci0JCXRzb19pbmZvLT5sc29fdjJfeG1pdC5tc3MgPSBtX2hlYWQtPm1fcGt0aGRyLnRzb19z ZWdzejsKKwkJCXRzb19pbmZvLT5sc29fdjJfeG1pdC50Y3BfaGVhZGVyX29mZnNldCA9IDA7CisJ CQl0c29faW5mby0+bHNvX3YyX3htaXQubXNzID0gbV9oZWFkLT5tX3BrdGhkci50c29fc2Vnc3o7 CisJCX0gZWxzZSBpZiAobV9oZWFkLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgc2MtPmhuX2NzdW1f YXNzaXN0KSB7CisJCQlybmRpc19tc2dfc2l6ZSArPSBSTkRJU19DU1VNX1BQSV9TSVpFOworCQkJ cnBwaSA9IGh2X3NldF9ycHBpX2RhdGEocm5kaXNfbWVzZywgUk5ESVNfQ1NVTV9QUElfU0laRSwK KwkJCSAgICB0Y3BpcF9jaGtzdW1faW5mbyk7CisJCQljc3VtX2luZm8gPSAocm5kaXNfdGNwX2lw X2NzdW1faW5mbyAqKSgoY2hhciopcnBwaSArCisJCQkgICAgcnBwaS0+cGVyX3BhY2tldF9pbmZv X29mZnNldCk7CisKKwkJCWNzdW1faW5mby0+eG1pdC5pc19pcHY0ID0gMTsKKwkJCWlmIChtX2hl YWQtPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJiBDU1VNX1RDUCkgeworCQkJCWNzdW1faW5mby0+eG1p dC50Y3BfY3N1bSA9IDE7CisJCQkJY3N1bV9pbmZvLT54bWl0LnRjcF9oZWFkZXJfb2Zmc2V0ID0g MDsKKwkJCX0gZWxzZSBpZiAobV9oZWFkLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NVTV9VRFAp IHsKKwkJCQljc3VtX2luZm8tPnhtaXQudWRwX2NzdW0gPSAxOworCQkJfQorCQl9CiAKLXByZV9z ZW5kOgogCQlybmRpc19tZXNnLT5tc2dfbGVuID0gcGFja2V0LT50b3RfZGF0YV9idWZfbGVuICsg cm5kaXNfbXNnX3NpemU7CiAJCXBhY2tldC0+dG90X2RhdGFfYnVmX2xlbiA9IHJuZGlzX21lc2ct Pm1zZ19sZW47CiAKZGlmZiAtLWdpdCBhL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXRfdnNj LmggYi9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0X3ZzYy5oCi0tLSBhL3N5cy9kZXYvaHlw ZXJ2L25ldHZzYy9odl9uZXRfdnNjLmgKKysrIGIvc3lzL2Rldi9oeXBlcnYvbmV0dnNjL2h2X25l dF92c2MuaApAQCAtMTAxNSw2ICsxMDE1LDcgQEAKIAlidXNfZG1hX3RhZ190CWhuX3R4X3JuZGlz X2R0YWc7CiAJaW50CQlobl90eF9jaGltbmV5X3NpemU7CiAJaW50CQlobl90eF9jaGltbmV5X21h eDsKKwl1aW50NjRfdAlobl9jc3VtX2Fzc2lzdDsKIAogCXN0cnVjdCBtdHgJaG5fdHhsaXN0X3Nw aW47CiAJc3RydWN0IGhuX3R4ZGVzY19saXN0IGhuX3R4bGlzdDsKQEAgLTEwNDMsOCArMTA0NCw2 IEBACiAJdV9sb25nCQlobl90eGRtYV9mYWlsZWQ7CiAJdV9sb25nCQlobl90eF9jb2xsYXBzZWQ7 CiAJdV9sb25nCQlobl90eF9jaGltbmV5OwotCi0JdWludDY0X3QJaG5fY3N1bV9hc3Npc3Q7CiB9 IGhuX3NvZnRjX3Q7CiAKIAoK --b1_2090b449f5d8745f07ed904ab1fd66c1-- From owner-freebsd-net@freebsd.org Thu Jan 28 05:18:55 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B8CFA7032C for ; Thu, 28 Jan 2016 05:18:55 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from phabric-backend.rbsd.freebsd.org (unknown [IPv6:2607:fc50:2000:101::1bb:73]) by mx1.freebsd.org (Postfix) with ESMTP id E1E1E1499 for ; Thu, 28 Jan 2016 05:18:54 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by phabric-backend.rbsd.freebsd.org (Postfix, from userid 1346) id E0AA6106339; Thu, 28 Jan 2016 05:18:54 +0000 (UTC) Date: Thu, 28 Jan 2016 05:18:54 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D5099+325+848a83c1598839c9@reviews.freebsd.org Subject: [Differential] [Request, 5 lines] D5099: hyperv/hn: Enable IP header checksum offloading Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D5099: hyperv/hn: Enable IP header checksum offloading X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk Thread-Index: YmJjZTQyNjA4YTZjZjY2YWRlYTUwZDRiZThk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_8433498bc71f02aa1a01066b952a0fad" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 05:18:55 -0000 --b1_8433498bc71f02aa1a01066b952a0fad Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit sepherosa_gmail.com created this revision. sepherosa_gmail.com added reviewers: network, adrian, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com. sepherosa_gmail.com added a subscriber: freebsd-net-list. REVISION SUMMARY - TCP/IP stack will not do unnecessary IP header checksum for TSO packets - Reduce guest load for non-TSO IP packets. REVISION DETAIL https://reviews.freebsd.org/D5099 AFFECTED FILES sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c CHANGE DETAILS diff --git a/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c b/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c --- a/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c +++ b/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c @@ -172,7 +172,7 @@ * Windows releases. */ #define HN_CSUM_ASSIST_WIN8 (CSUM_TCP) -#define HN_CSUM_ASSIST (CSUM_UDP | CSUM_TCP) +#define HN_CSUM_ASSIST (CSUM_IP | CSUM_UDP | CSUM_TCP) /* XXX move to netinet/tcp_lro.h */ #define HN_LRO_HIWAT_MAX 65535 @@ -867,6 +867,9 @@ rppi->per_packet_info_offset); csum_info->xmit.is_ipv4 = 1; + if (m_head->m_pkthdr.csum_flags & CSUM_IP) + csum_info->xmit.ip_header_csum = 1; + if (m_head->m_pkthdr.csum_flags & CSUM_TCP) { csum_info->xmit.tcp_csum = 1; csum_info->xmit.tcp_header_offset = 0; EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com Cc: freebsd-net-list --b1_8433498bc71f02aa1a01066b952a0fad Content-Type: text/x-patch; charset=utf-8; name="D5099.12775.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D5099.12775.patch" ZGlmZiAtLWdpdCBhL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2Qu YyBiL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2QuYwotLS0gYS9z eXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0dnNjX2Rydl9mcmVlYnNkLmMKKysrIGIvc3lzL2Rl di9oeXBlcnYvbmV0dnNjL2h2X25ldHZzY19kcnZfZnJlZWJzZC5jCkBAIC0xNzIsNyArMTcyLDcg QEAKICAqIFdpbmRvd3MgcmVsZWFzZXMuCiAgKi8KICNkZWZpbmUgSE5fQ1NVTV9BU1NJU1RfV0lO OAkoQ1NVTV9UQ1ApCi0jZGVmaW5lIEhOX0NTVU1fQVNTSVNUCQkoQ1NVTV9VRFAgfCBDU1VNX1RD UCkKKyNkZWZpbmUgSE5fQ1NVTV9BU1NJU1QJCShDU1VNX0lQIHwgQ1NVTV9VRFAgfCBDU1VNX1RD UCkKIAogLyogWFhYIG1vdmUgdG8gbmV0aW5ldC90Y3BfbHJvLmggKi8KICNkZWZpbmUgSE5fTFJP X0hJV0FUX01BWAkJCQk2NTUzNQpAQCAtODY3LDYgKzg2Nyw5IEBACiAJCQkgICAgcnBwaS0+cGVy X3BhY2tldF9pbmZvX29mZnNldCk7CiAKIAkJCWNzdW1faW5mby0+eG1pdC5pc19pcHY0ID0gMTsK KwkJCWlmIChtX2hlYWQtPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJiBDU1VNX0lQKQorCQkJCWNzdW1f aW5mby0+eG1pdC5pcF9oZWFkZXJfY3N1bSA9IDE7CisKIAkJCWlmIChtX2hlYWQtPm1fcGt0aGRy LmNzdW1fZmxhZ3MgJiBDU1VNX1RDUCkgewogCQkJCWNzdW1faW5mby0+eG1pdC50Y3BfY3N1bSA9 IDE7CiAJCQkJY3N1bV9pbmZvLT54bWl0LnRjcF9oZWFkZXJfb2Zmc2V0ID0gMDsKCg== --b1_8433498bc71f02aa1a01066b952a0fad-- From owner-freebsd-net@freebsd.org Thu Jan 28 19:48:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5299EA71EF9 for ; Thu, 28 Jan 2016 19:48:05 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 3AAE267E; Thu, 28 Jan 2016 19:48:04 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id B7C775648E; Thu, 28 Jan 2016 13:48:03 -0600 (CST) To: "freebsd-net@freebsd.org" , Sean Bruno , Eric Joyner From: Eric van Gyzen Subject: Intel I219-V Support? Message-ID: <56AA7072.2040105@FreeBSD.org> Date: Thu, 28 Jan 2016 13:48:02 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 19:48:05 -0000 I just bought a Dell XPS 8900 desktop. I was delighted to see that the onboard Ethernet is an Intel chip, although it doesn't seem to be supported in head yet. Is support for this chip planned or in progress? none4@pci0:0:31:6: class=0x020000 card=0x06b81028 chip=0x15b88086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection (2) I219-V' class = network subclass = ethernet Thanks, Eric From owner-freebsd-net@freebsd.org Thu Jan 28 19:54:39 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3938A3C1A7 for ; Thu, 28 Jan 2016 19:54:39 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mx1.freebsd.org (Postfix) with ESMTP id CA906A02; Thu, 28 Jan 2016 19:54:39 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 28 Jan 2016 11:54:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,360,1449561600"; d="scan'208";a="643093580" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by FMSMGA003.fm.intel.com with ESMTP; 28 Jan 2016 11:54:33 -0800 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.220]) by ORSMSX105.amr.corp.intel.com ([169.254.2.138]) with mapi id 14.03.0248.002; Thu, 28 Jan 2016 11:54:32 -0800 From: "Pieper, Jeffrey E" To: Eric van Gyzen , "freebsd-net@freebsd.org" , Sean Bruno , Eric Joyner Subject: RE: Intel I219-V Support? Thread-Topic: Intel I219-V Support? Thread-Index: AQHRWgTbdB71zCiUFkWpWMeXi5DjiJ8RVxfR Date: Thu, 28 Jan 2016 19:54:31 +0000 Message-ID: <2A35EA60C3C77D438915767F458D65688092D7AF@ORSMSX111.amr.corp.intel.com> References: <56AA7072.2040105@FreeBSD.org> In-Reply-To: <56AA7072.2040105@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.86.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 19:54:40 -0000 Please see https://reviews.freebsd.org/D3162.=0A= =0A= Thanks,=0A= Jeff=0A= ________________________________________=0A= From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on beha= lf of Eric van Gyzen [vangyzen@FreeBSD.org]=0A= Sent: Thursday, January 28, 2016 11:48 AM=0A= To: freebsd-net@freebsd.org; Sean Bruno; Eric Joyner=0A= Subject: Intel I219-V Support?=0A= =0A= I just bought a Dell XPS 8900 desktop. I was delighted to see that the=0A= onboard Ethernet is an Intel chip, although it doesn't seem to be=0A= supported in head yet.=0A= =0A= Is support for this chip planned or in progress?=0A= =0A= none4@pci0:0:31:6: class=3D0x020000 card=3D0x06b81028 chip=3D0x15b8808= 6=0A= rev=3D0x31 hdr=3D0x00=0A= vendor =3D 'Intel Corporation'=0A= device =3D 'Ethernet Connection (2) I219-V'=0A= class =3D network=0A= subclass =3D ethernet=0A= =0A= Thanks,=0A= =0A= Eric=0A= _______________________________________________=0A= freebsd-net@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= From owner-freebsd-net@freebsd.org Fri Jan 29 11:34:06 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68CB0A71E8E for ; Fri, 29 Jan 2016 11:34:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59967181E for ; Fri, 29 Jan 2016 11:34:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0TBY5eB083363 for ; Fri, 29 Jan 2016 11:34:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203922] The kern.ipc.acceptqueue limit is too low Date: Fri, 29 Jan 2016 11:34:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: needs-qa, patch, performance X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 11:34:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203922 --- Comment #8 from Konstantin Belousov --- (In reply to White Knight from comment #7) The patch is mostly fine. I do not see a need in the casts to uint32_t in sctp_sysctl_handle_assoclist(), the normal promotion rules would do the rig= ht thing. Also, I believe that somebody else at some other place already noted that s= uch change does not deserve addition of the copyright lines to the affected fil= es.=20 I do not see the patch with these claims acceptable, and we cannot strip yo= ur copyright notice. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 29 12:19:57 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22148A70001 for ; Fri, 29 Jan 2016 12:19:57 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D33011DA8; Fri, 29 Jan 2016 12:19:56 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pa0-x229.google.com with SMTP id ho8so40811250pac.2; Fri, 29 Jan 2016 04:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=YkYvgwOnyvtCMjuHwyflsRaC1tBrHcEoqoFEItQ4LlQ=; b=KFpRZ0SxGYQHmH2AjOf0x63/diB68W3GQjx/1OeXWjjtgy5RPW0qQaA37A6sm8oL3t g31HNCz1RbnXtw4TV7BL88QSphkfzial1+EldJZh5rrWaNiK3qmBWYXnlweQDK1cs4PW a0Coo2Cs5tT2Y9HCjD5eGtCIzB1CeJaqA5wDgaNJNGlXYkDIs2ZSuQqGvOQQj0BcHXpE TooamuLug7Vhf/LW65dTv3bxFaxB7MDE9QU/TKdk1O4bdKwhW/hZO9vMrcaBH3IL2mSH 8uczt4pA6jriX0OCvJWACBW8O0xVmsCbR2CFSWBks27BHd0ZFHZyq4yLn+pMf0PH/TPC YRQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=YkYvgwOnyvtCMjuHwyflsRaC1tBrHcEoqoFEItQ4LlQ=; b=M2WT23DbU7RgmHxtNJVUJUU/R4+CpOWdEbF3eTeKdyBc+lNVBsEmju//e3sB4UDkbY gjWo74MntrkceDW1S8XNEdixyuzzg9iEKb4y2TKW8B3DU7mJaqjqJ+wgickaiyh5PE9F So9w7KYsJss6Md8+8EpVA1sfgVHh0RdZzw4zjUCurgG1lqkhIaFsHayI0tYy8+j9rWbU OvC8voPC+Aejxf02SsBIwsm40Mr6C6SOaKBed7j8J2QebfDpHG94kjlghBcFPdiNkK8A QVKLqiYneKRkswWB8baJOS9eGx20Sx9OhnMuGBZMBSNHt6xC5L1mxgWYvFE7VqFolQUW cdjA== X-Gm-Message-State: AG10YOSKRyNTcoNluEQKgvLOjvmSPvuUQo1WtDXH+w5FQk2oNvCQ8mQd0KSs9kLetH/JXg== X-Received: by 10.66.141.165 with SMTP id rp5mr12957429pab.56.1454069995750; Fri, 29 Jan 2016 04:19:55 -0800 (PST) Received: from ?IPv6:2001:44b8:31ae:7b01:d8d8:7a9e:193f:1cfe? (2001-44b8-31ae-7b01-d8d8-7a9e-193f-1cfe.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:d8d8:7a9e:193f:1cfe]) by smtp.gmail.com with ESMTPSA id 24sm7868936pfn.50.2016.01.29.04.19.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 04:19:55 -0800 (PST) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: Intel I219-V Support? References: <56AA7072.2040105@FreeBSD.org> <2A35EA60C3C77D438915767F458D65688092D7AF@ORSMSX111.amr.corp.intel.com> To: Eric van Gyzen , "freebsd-net@freebsd.org" Cc: "Pieper, Jeffrey E" From: Kubilay Kocak Message-ID: <56AB58DF.1010405@FreeBSD.org> Date: Fri, 29 Jan 2016 23:19:43 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <2A35EA60C3C77D438915767F458D65688092D7AF@ORSMSX111.amr.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 12:19:57 -0000 On 29/01/2016 6:54 AM, Pieper, Jeffrey E wrote: > Please see https://reviews.freebsd.org/D3162. > > Thanks, > Jeff > ________________________________________ > From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on behalf of Eric van Gyzen [vangyzen@FreeBSD.org] > Sent: Thursday, January 28, 2016 11:48 AM > To: freebsd-net@freebsd.org; Sean Bruno; Eric Joyner > Subject: Intel I219-V Support? > > I just bought a Dell XPS 8900 desktop. I was delighted to see that the > onboard Ethernet is an Intel chip, although it doesn't seem to be > supported in head yet. > > Is support for this chip planned or in progress? > > none4@pci0:0:31:6: class=0x020000 card=0x06b81028 chip=0x15b88086 > rev=0x31 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Ethernet Connection (2) I219-V' > class = network > subclass = ethernet > > Thanks, > > Eric And https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206533 which links to it From owner-freebsd-net@freebsd.org Fri Jan 29 15:13:40 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8025A72E05 for ; Fri, 29 Jan 2016 15:13:40 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0021BE8; Fri, 29 Jan 2016 15:13:40 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 29 Jan 2016 07:13:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,364,1449561600"; d="scan'208";a="871768868" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga001.jf.intel.com with ESMTP; 29 Jan 2016 07:13:34 -0800 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.220]) by ORSMSX101.amr.corp.intel.com ([169.254.8.21]) with mapi id 14.03.0248.002; Fri, 29 Jan 2016 07:13:34 -0800 From: "Pieper, Jeffrey E" To: "koobs@FreeBSD.org" , Eric van Gyzen , "freebsd-net@freebsd.org" Subject: RE: Intel I219-V Support? Thread-Topic: Intel I219-V Support? Thread-Index: AQHRWgTbdB71zCiUFkWpWMeXi5DjiJ8RVxfRgAGZpoD//6mcsA== Date: Fri, 29 Jan 2016 15:13:33 +0000 Message-ID: <2A35EA60C3C77D438915767F458D65688092FD5B@ORSMSX111.amr.corp.intel.com> References: <56AA7072.2040105@FreeBSD.org> <2A35EA60C3C77D438915767F458D65688092D7AF@ORSMSX111.amr.corp.intel.com> <56AB58DF.1010405@FreeBSD.org> In-Reply-To: <56AB58DF.1010405@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDUwN2Q5M2MtMmNiNi00YjFlLWExZjYtYzBkMGZhMWI3YzI0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS40LjEwLjE5IiwiVHJ1c3RlZExhYmVsSGFzaCI6InIxNHh4bzhRYWNTcHVyWFdRTkZRWDlHUVIwaVZqNnFwbk84QXJ2MW05Y2M9In0= x-ctpclassification: CTP_PUBLIC x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:13:40 -0000 VGhlIEJ1Z3ppbGxhIGlzIGlycmVsZXZhbnQgdG8gdGhlIHF1ZXN0aW9uLiBUaGUgUGhhYnJpY2F0 b3IgcmV2aWV3IGhhcyBiZWVuIG9uZ29pbmcgZm9yIG1vbnRocy4NCg0KSmVmZg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS3ViaWxheSBLb2NhayBbbWFpbHRvOmtvb2JzLmZy ZWVic2RAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgS3ViaWxheSBLb2Nhaw0KU2VudDogRnJpZGF5 LCBKYW51YXJ5IDI5LCAyMDE2IDQ6MjAgQU0NClRvOiBFcmljIHZhbiBHeXplbiA8dmFuZ3l6ZW5A RnJlZUJTRC5vcmc+OyBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZw0KQ2M6IFBpZXBlciwgSmVmZnJl eSBFIDxqZWZmcmV5LmUucGllcGVyQGludGVsLmNvbT4NClN1YmplY3Q6IFJlOiBJbnRlbCBJMjE5 LVYgU3VwcG9ydD8NCg0KT24gMjkvMDEvMjAxNiA2OjU0IEFNLCBQaWVwZXIsIEplZmZyZXkgRSB3 cm90ZToNCj4gUGxlYXNlIHNlZSBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDMxNjIuDQo+ IA0KPiBUaGFua3MsDQo+IEplZmYNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBGcm9tOiBvd25lci1mcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyBbb3duZXItZnJl ZWJzZC1uZXRAZnJlZWJzZC5vcmddIG9uIGJlaGFsZiBvZiBFcmljIHZhbiBHeXplbiBbdmFuZ3l6 ZW5ARnJlZUJTRC5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI4LCAyMDE2IDExOjQ4 IEFNDQo+IFRvOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZzsgU2VhbiBCcnVubzsgRXJpYyBKb3lu ZXINCj4gU3ViamVjdDogSW50ZWwgSTIxOS1WIFN1cHBvcnQ/DQo+IA0KPiBJIGp1c3QgYm91Z2h0 IGEgRGVsbCBYUFMgODkwMCBkZXNrdG9wLiAgSSB3YXMgZGVsaWdodGVkIHRvIHNlZSB0aGF0IHRo ZQ0KPiBvbmJvYXJkIEV0aGVybmV0IGlzIGFuIEludGVsIGNoaXAsIGFsdGhvdWdoIGl0IGRvZXNu J3Qgc2VlbSB0byBiZQ0KPiBzdXBwb3J0ZWQgaW4gaGVhZCB5ZXQuDQo+IA0KPiBJcyBzdXBwb3J0 IGZvciB0aGlzIGNoaXAgcGxhbm5lZCBvciBpbiBwcm9ncmVzcz8NCj4gDQo+IG5vbmU0QHBjaTA6 MDozMTo2OiAgICAgIGNsYXNzPTB4MDIwMDAwIGNhcmQ9MHgwNmI4MTAyOCBjaGlwPTB4MTViODgw ODYNCj4gcmV2PTB4MzEgaGRyPTB4MDANCj4gICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nDQo+ICAgICBkZXZpY2UgICAgID0gJ0V0aGVybmV0IENvbm5lY3Rpb24gKDIpIEkyMTkt VicNCj4gICAgIGNsYXNzICAgICAgPSBuZXR3b3JrDQo+ICAgICBzdWJjbGFzcyAgID0gZXRoZXJu ZXQNCj4gDQo+IFRoYW5rcywNCj4gDQo+IEVyaWMNCg0KQW5kIGh0dHBzOi8vYnVncy5mcmVlYnNk Lm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MjA2NTMzIHdoaWNoIGxpbmtzDQp0byBpdA0K DQo= From owner-freebsd-net@freebsd.org Fri Jan 29 21:39:23 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BF68A7360B for ; Fri, 29 Jan 2016 21:39:23 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FBCF1595 for ; Fri, 29 Jan 2016 21:39:23 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-oi0-x22d.google.com with SMTP id r14so55721918oie.0 for ; Fri, 29 Jan 2016 13:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=B2q0vwnGEVV1yLjc+KFKi8TsUtPW0ShupsnDyoUQB70=; b=cDtUcBwLWRpwHiRTqxMkB4iZtLbsyshAuqnqRQK13sTFB2kvLSOd+QmG/0n20ZOlZy N5hbtFv6Ho7KuZzHGEP0PjCpn1tn60z6KdTCTPUj/1WAdw+/PjNkHZasWwnsXzuRCKeG CQKCI8xuIJodWuq26CcofNNLG11/TKnLdO0KPAqAutI5FOagrd6ioWMP1W3i+rg1Eygg d5R9ts4E/SlheLyz7GNeMlF+/bky3EU9eR/Ua/rZ9l6LW+Z5rWhD7aef+wKse9XdGBtR 1J/CMWg8K3yBy3WOIUxku7qLRHeMkekbPeMlg+DrrR0/NClLnttqVjmld4aMPVT2e6gy CZXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=B2q0vwnGEVV1yLjc+KFKi8TsUtPW0ShupsnDyoUQB70=; b=aNnIpTsl+cgmWFrnUAi9oGFaKWTJT/hK0kCs4p58dRTJQvT84JBQFJB1x6G0XQLq6O c6tEA24aUYMDFMDzqRUCCENkInAjiPkjB93/tMtOcWTnva0o+Z2583TApIXjWlzSViIw a3FTFNogUUOUl2sbNUBwOWknKF23TOTvlaePAymI3DcyEXCYvy2wGTQK7uE1OOx8l/VG Agsld5s4CF2dqSe8Yk7rGCqwacpzRQNCoknRgl1yyI4hEG2XS6AqeEDs882SpkQhx6me Pvk9fDr1n2eQ/Synn49At3DzG936iC5zo2bspcSYUCoq5c/gFo/XsQeF/r6XpwTJXDOO KkBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B2q0vwnGEVV1yLjc+KFKi8TsUtPW0ShupsnDyoUQB70=; b=QL20UObhepxQ/Wx3dmIjbV3aVvdJwWFW6BXFy8JlvAbonu1gHMryn6r/wPkj9c0weE wYfNNKcSlHkim8M5tZISXJNoptNbXfa2VywFpYQa5DqOgMhBlrwY7HxPTedqbfcMIz8w mYww0/fm39CUdS6I//uA/ur+PFTWz7YS6kKQ3zR2sp8NeZmX8ennrL5udyRtCdh29Q8T 23whvqDPfX0YCxlfEC17BxP74i0Jqc3pOcXDfc/yHL729UFdVe8oj2f5dHouRGcBNgiN qT7snn6/gXIMuSSoDzPm0ZVjKAp+MWTI8QBKpncj9IgNw1PhMIeuiH4pM99QTJHO2K9g S8yw== X-Gm-Message-State: AG10YOSb2bLujEv/eyqxhqxl+VjYvZJQwGTeN95wh8lF4mc3ZyDFj6HSZUbxvT5qeeJVJSzviEqQX8UHFIaizg== MIME-Version: 1.0 X-Received: by 10.202.108.69 with SMTP id h66mr7271178oic.67.1454103562609; Fri, 29 Jan 2016 13:39:22 -0800 (PST) Sender: sunxiaoye07@gmail.com Received: by 10.202.223.5 with HTTP; Fri, 29 Jan 2016 13:39:22 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Jan 2016 15:39:22 -0600 X-Google-Sender-Auth: OcC115aT0Nfxlebwvbv7RWMaaYA Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Xiaoye Sun To: Pavel Odintsov Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:39:23 -0000 Hi Pavel, Our code is somewhat complicate. So I did a very simple experiment having the same problem so that you could regenerate the problem. In the new experiment, I used a very simple udp sender and udp receiver that sends and receives udp packet with seq num. I put the code here. http://www.owlnet.rice.edu/~xs6/receiver.c http://www.owlnet.rice.edu/~xs6/sender.c To repeat the experiment, on machine A, I run the sender program (command: sender 10.10.10.1 (your receiver IP)). On machien B, I run a netmap bridge that swap the slot printer between the host ring and the nic ring (the bridge example in netmap package /examples/bridge.c using the command ./bridge netmap:eth1 netmap:eth1) and also run the receiver program. I am able to see that the receiver print message saying that the new seq number is less than the seq number received in the previous round. Please let me know if you successfully generates the same problem. Thank! Xiaoye On Tue, Jan 26, 2016 at 1:53 AM, Pavel Odintsov wrote: > Hello! > > Really useful and detailed research. Thanks a lot! Could you share > your validation code? It could be useful for consistency tests for > netmap. > > So I could not help with your original question. Let's wait answer > from developers of awesome Netmap :) > > On Tue, Jan 26, 2016 at 2:55 AM, Xiaoye Sun wrote: > > Hi all, > > > > I wrote a netmap application that is very similar to bridge.c in > master/example > > directory of the netmap code. The major difference between my program and > > bridge.c is that my application also creates custom packets that are > > directly put into the tx ring of the NIC (like a packet generator with > > NIC-Host packet forwarding). Each generated packet has an unique sequence > > number so that the receiver can tell if a packet is lost. > > > > Like bridge.c, the packet forwarding between the nic and the host uses > > 'zerocopy', so that the program only swaps the buf_idx of the slots to > > virtually forward the packet to the other end. NS_BUF_CHANGED is set for > > the slots (both rx and tx) whose buf_idx has been changed due to > zerocopy. > > > > I set the number of rings on nic to 1 using the ethtool command, i.e., > one > > pair of netmap rings for the nic (one for host tx and one for host rx) > and > > another pair of rings for the host (one for host tx and one for host rx). > > > > However, at the receiver side, I found that there is a chance (very > little > > chance, less than 1% of the swaps) where swapping the buf_idx does not > > success. The receiver might get the packet in the buffer swapped out. For > > example, the netmap program wants to swap host slot *SH* with NIC slot > *SN* > > in order to send the packet in *SH* from host to the receiver; the > receiver > > might get the packet in *SN* instead. This usually happens to the very > end > > of the available slots. > > > > Our experiment is done on *Linux* machine (Linux 3.16.0-4-amd64 #1 SMP > > Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux) with* intel NIC* > > (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection) using > > the *ixgbe* driver. > > > > To understand this problem, I look into the patch code to the ixgbe > driver. > > I found that the flag NS_BUF_CHANGED is not used in the linux driver for > > ixgbe. please look the header file /LINUX/ixgbe_netmap_linux.h. In > funtions > > ixgbe_netmap_txsync and ixgbe_netmap_rxsync, the function call > > netmap_reload_map is commented out. However, the ixgbe's driver patch for > > FreeBSD calls the reload function. > > > > So, I am wondering if this is a known problem when using netmap on LINUX. > > Has anybody found the same problem? > > Is netmap_reload_map required in Linux? why it is not called in the > driver > > patch? > > What is the recommended solution for this problem? > > > > Thanks! > > > > Best, > > Xiaoye > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- > Sincerely yours, Pavel Odintsov > > From owner-freebsd-net@freebsd.org Fri Jan 29 21:46:00 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49A71A7385E for ; Fri, 29 Jan 2016 21:46:00 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACA021C38 for ; Fri, 29 Jan 2016 21:45:59 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lb0-x229.google.com with SMTP id cl12so48033243lbc.1 for ; Fri, 29 Jan 2016 13:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0+Q28BPLoaHj+wHpDP0VfaQEGkx4RkRGDFHWfbetyXc=; b=n6a5TCJlcfLeaWBgKkQeIw6Jc2SNWFd3dJv321jBuA3jt1vTwigj7BGfqgT2KmSApB pGhW6GdkSdwOI6cGdTxaZw2Kj0mGP6qHm2hPJx13y882Y7O1RqbJ7njDcm/2aV6ivyQm sSrGX/sbOhsRlMmnilj0aZUPZY+V59s7bSIdE5vkksUQCV9G3NrEWqjG+t7IlbNilf2s OITwyAJ34aLnLfZLXZwlYGn1feD369fC4Vn+Mno4ke7WiDBMor3xaMHpp/pkIwSO3aLx JUU1j5VEVzTNG41KGoVPBfxMFUOmg4i8eYk2vBucNIDfqy7CjU9mcJp07i//4SW07pF7 W6+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0+Q28BPLoaHj+wHpDP0VfaQEGkx4RkRGDFHWfbetyXc=; b=O79iaZf4ntChmzmE8RoYDbgnBAzIZu/3lDdRF7A04DK3VmD/RAgDu0eT8W5Bf2tBW6 ogoFrOmUYzdYUt4uAO6O5BM8O422ZpRA2QSttGujeMB3UiLGmv1F6snw+MfqFGgp0vxR N3arlkRs2BJnD/omPxfVi3Z7O4bMi0thudLuI7eMq1SoPpHhTiEYMaT+aUKTh1Di8TPi K9RTEYc1s6umjMrir231YXR+RW81MvrxBp9zmqmZa9ShuAeRD6E42IxlKaOEUYJu8XRa ss/03XSzriSgIkRkR6+DakH7/izR5jyEUOPX/RDxoaxLLbfp+pkUoHwNWqiQbXIXHKxZ 0osQ== X-Gm-Message-State: AG10YOTMtKUMJg9MLCDz3lptv8BGL50inZAqtSDx94PIvgxGBZ3qJRsG758q6mRpDfX9THgOzFyVUaPa8qylAw== MIME-Version: 1.0 X-Received: by 10.112.155.201 with SMTP id vy9mr4117420lbb.54.1454103957655; Fri, 29 Jan 2016 13:45:57 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Fri, 29 Jan 2016 13:45:57 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Jan 2016 13:45:57 -0800 X-Google-Sender-Auth: aPcyLJtz4M2PuP1Z1KRj726xcVs Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Luigi Rizzo To: Xiaoye Sun Cc: Pavel Odintsov , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:46:00 -0000 On Fri, Jan 29, 2016 at 1:39 PM, Xiaoye Sun wrote: > Hi Pavel, > > Our code is somewhat complicate. > So I did a very simple experiment having the same problem so that you could > regenerate the problem. Xiaoye, before doing more experiments can you please clarify the operating conditions, specifically make sure that you are only using a single receive and transmit queue on the NICs in the bridge machine ? I suspect the problem lies here (it was not clear from your previous description). netmap cannot make any guarantee on the transmit order if you are using multiple transmit queues (same problem on receive, though it is not relevant here because almost surely all input traffic goes to the same queue). cheers luigi > In the new experiment, I used a very simple udp sender and udp receiver > that sends and receives udp packet with seq num. > > I put the code here. > http://www.owlnet.rice.edu/~xs6/receiver.c > http://www.owlnet.rice.edu/~xs6/sender.c > > To repeat the experiment, on machine A, I run the sender program > (command: sender > 10.10.10.1 (your receiver IP)). > On machien B, I run a netmap bridge that swap the slot printer between the > host ring and the nic ring (the bridge example in netmap package > /examples/bridge.c using the command ./bridge netmap:eth1 netmap:eth1) and > also run the receiver program. > > I am able to see that the receiver print message saying that the new seq > number is less than the seq number received in the previous round. > > Please let me know if you successfully generates the same problem. > > Thank! > Xiaoye > > > > On Tue, Jan 26, 2016 at 1:53 AM, Pavel Odintsov > wrote: > >> Hello! >> >> Really useful and detailed research. Thanks a lot! Could you share >> your validation code? It could be useful for consistency tests for >> netmap. >> >> So I could not help with your original question. Let's wait answer >> from developers of awesome Netmap :) >> >> On Tue, Jan 26, 2016 at 2:55 AM, Xiaoye Sun wrote: >> > Hi all, >> > >> > I wrote a netmap application that is very similar to bridge.c in >> master/example >> > directory of the netmap code. The major difference between my program and >> > bridge.c is that my application also creates custom packets that are >> > directly put into the tx ring of the NIC (like a packet generator with >> > NIC-Host packet forwarding). Each generated packet has an unique sequence >> > number so that the receiver can tell if a packet is lost. >> > >> > Like bridge.c, the packet forwarding between the nic and the host uses >> > 'zerocopy', so that the program only swaps the buf_idx of the slots to >> > virtually forward the packet to the other end. NS_BUF_CHANGED is set for >> > the slots (both rx and tx) whose buf_idx has been changed due to >> zerocopy. >> > >> > I set the number of rings on nic to 1 using the ethtool command, i.e., >> one >> > pair of netmap rings for the nic (one for host tx and one for host rx) >> and >> > another pair of rings for the host (one for host tx and one for host rx). >> > >> > However, at the receiver side, I found that there is a chance (very >> little >> > chance, less than 1% of the swaps) where swapping the buf_idx does not >> > success. The receiver might get the packet in the buffer swapped out. For >> > example, the netmap program wants to swap host slot *SH* with NIC slot >> *SN* >> > in order to send the packet in *SH* from host to the receiver; the >> receiver >> > might get the packet in *SN* instead. This usually happens to the very >> end >> > of the available slots. >> > >> > Our experiment is done on *Linux* machine (Linux 3.16.0-4-amd64 #1 SMP >> > Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux) with* intel NIC* >> > (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection) using >> > the *ixgbe* driver. >> > >> > To understand this problem, I look into the patch code to the ixgbe >> driver. >> > I found that the flag NS_BUF_CHANGED is not used in the linux driver for >> > ixgbe. please look the header file /LINUX/ixgbe_netmap_linux.h. In >> funtions >> > ixgbe_netmap_txsync and ixgbe_netmap_rxsync, the function call >> > netmap_reload_map is commented out. However, the ixgbe's driver patch for >> > FreeBSD calls the reload function. >> > >> > So, I am wondering if this is a known problem when using netmap on LINUX. >> > Has anybody found the same problem? >> > Is netmap_reload_map required in Linux? why it is not called in the >> driver >> > patch? >> > What is the recommended solution for this problem? >> > >> > Thanks! >> > >> > Best, >> > Xiaoye >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> -- >> Sincerely yours, Pavel Odintsov >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Fri Jan 29 21:46:03 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29187A73861 for ; Fri, 29 Jan 2016 21:46:03 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD4721C39 for ; Fri, 29 Jan 2016 21:46:02 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-oi0-x22b.google.com with SMTP id p187so55928786oia.2 for ; Fri, 29 Jan 2016 13:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7Zu7ZVIkaB/Bcq+06WPBh3zhipkHUdDyGLIh1ADvGSU=; b=EWYosyvn75SsA30IoVVaSMFW8gVzSmevFpozjZNNlsfJr7C3p3uAaFjc0ltdPk/Pk3 g0MO30cJzNx4KvMDrTeLvRFZ+4t4OEvqgj/H3y8LCYHyu5bhG+n19S1nYFSpLp0JIqFM XioXV0AY8Q1GouCNgZ01Yydiz5igPT6K7doRXAC3En1hnHQEwZ9fTHLwGKaS/1EsebrQ anabmr8WbSlxxnbux8iK/aHZDbrJ0TKuPHN2fGsocQRkXUTJ+3Zmzop9EyrEoSHdQOJO 4RoYMWK6dlp6lygvRomCdMT5PZ+14YU1yqiK+ysBwfOVa/Nr2sN0Ih5WgSIDsYmOf95p ncPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7Zu7ZVIkaB/Bcq+06WPBh3zhipkHUdDyGLIh1ADvGSU=; b=paHqMA5WPw3rODLfaJWP1vGNcxTO1niaEYFkEGa9t3ZGzr4xXqyt7u9757RkWJILnX fVDZlymRHBKTQ6n07mH/6YRPOusUjy5QWxzC6y+95j1vluebI5IYaZd5lHMtJC1PkS2i D2rEvCaX7dKYD4J0wDuddccQgc8FQRQt+3qZvyUppDvT7yGB2JTBLyyNBY5Vo0rXIleH Cbj3NHJSjocP96FLtZ39CejQKIjWH4zZafkoWpY/1UUEH+Pgj+4/7iaQSjoMIquJev4s X2rRgIpuijKCT/ITwiZmKvoyeCTLCQ6b4hEZhJLhsUFKEez1L2R+Nf9jzuUDdOLPmKyU 8wHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7Zu7ZVIkaB/Bcq+06WPBh3zhipkHUdDyGLIh1ADvGSU=; b=FkUyfpdVr1UNSVIVNxcMC+fOCPBCdEtv8z7s3AipxJjcgL3y1Li8aoVxKj4CC94fpz 4m3aEmnXVorkXMTdCDTEM3ZFDmLXqWBt/Xl0y/8sBRK+0VlZWerdjZGVt02KT9tre/HX LKuy+3WskLVIyWqERyr77eN0IcukZEtx6JmkxSgcJIycp7XjXRZblyHbIMMDFecXdofR MNzZtfj6ZHTmnMxK4aS55fyK5HeYGNRt6fO2BTacNrliSkUbAU2Qqxi6YerjM/kMkuND EZylIDBeIE4uu27ZProMChBGogAcmfQV3h//+Z49TxFg3X1pefR/uwIREiL6Xej48L88 7ldg== X-Gm-Message-State: AG10YOT0NGJe+JMl8KawHU3VEUNsnIPZNZiYRdCZpB8qUYZTSNtjvyFmxZZnhEqubktzfLuqB6efEd7OnN9sOQ== MIME-Version: 1.0 X-Received: by 10.202.108.69 with SMTP id h66mr7289378oic.67.1454103962222; Fri, 29 Jan 2016 13:46:02 -0800 (PST) Sender: sunxiaoye07@gmail.com Received: by 10.202.223.5 with HTTP; Fri, 29 Jan 2016 13:46:02 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Jan 2016 15:46:02 -0600 X-Google-Sender-Auth: BN-tHkhRZR2x4HEb5yexkbwEQkA Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Xiaoye Sun To: Luigi Rizzo Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:46:03 -0000 Hi Luigi, Thanks for your reply. I try to disable iommu (add a line of "GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off intel_iommu=off"" in /etc/default/grub and also add memory barrier (__asm__ volatile("mfence" : : : "memory");) before it updates the slot pointer cur and head. However, the problem still there. In my reply to Pavel, I post how to generate the problem using very simple code and exmperiment. Could you please also try it on Linux and see if you could generate the same problem? Thanks! Best, Xiaoye On Tue, Jan 26, 2016 at 2:01 AM, Luigi Rizzo wrote: > Hi, > in FreeBSD, netmap_reload_map() is basically a NOP unless the NIC uses > bounce buffers (in which case it is pointless to use netmap, and I am > not even sure the code works), or there is an iommu which may need to > be reprogrammed (but in that case you don't want to do it dynamically > on individual buffers, but once for all when the device is opened.) > > This said, can you check that the iommu is disabled in the bios and > re-run the test ? > > This said I am not sure that the problem is the iommu -- a wrong entry > should result in bogus content, certainly not the one before the swap. > I suspect some kind of race, possibly missing memory barriers. > > cheers > luigi > > > On Mon, Jan 25, 2016 at 3:55 PM, Xiaoye Sun wrote: > > Hi all, > > > > I wrote a netmap application that is very similar to bridge.c in > master/example > > directory of the netmap code. The major difference between my program and > > bridge.c is that my application also creates custom packets that are > > directly put into the tx ring of the NIC (like a packet generator with > > NIC-Host packet forwarding). Each generated packet has an unique sequence > > number so that the receiver can tell if a packet is lost. > > > > Like bridge.c, the packet forwarding between the nic and the host uses > > 'zerocopy', so that the program only swaps the buf_idx of the slots to > > virtually forward the packet to the other end. NS_BUF_CHANGED is set for > > the slots (both rx and tx) whose buf_idx has been changed due to > zerocopy. > > > > I set the number of rings on nic to 1 using the ethtool command, i.e., > one > > pair of netmap rings for the nic (one for host tx and one for host rx) > and > > another pair of rings for the host (one for host tx and one for host rx). > > > > However, at the receiver side, I found that there is a chance (very > little > > chance, less than 1% of the swaps) where swapping the buf_idx does not > > success. The receiver might get the packet in the buffer swapped out. For > > example, the netmap program wants to swap host slot *SH* with NIC slot > *SN* > > in order to send the packet in *SH* from host to the receiver; the > receiver > > might get the packet in *SN* instead. This usually happens to the very > end > > of the available slots. > > > > Our experiment is done on *Linux* machine (Linux 3.16.0-4-amd64 #1 SMP > > Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux) with* intel NIC* > > (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection) using > > the *ixgbe* driver. > > > > To understand this problem, I look into the patch code to the ixgbe > driver. > > I found that the flag NS_BUF_CHANGED is not used in the linux driver for > > ixgbe. please look the header file /LINUX/ixgbe_netmap_linux.h. In > funtions > > ixgbe_netmap_txsync and ixgbe_netmap_rxsync, the function call > > netmap_reload_map is commented out. However, the ixgbe's driver patch for > > FreeBSD calls the reload function. > > > > So, I am wondering if this is a known problem when using netmap on LINUX. > > Has anybody found the same problem? > > Is netmap_reload_map required in Linux? why it is not called in the > driver > > patch? > > What is the recommended solution for this problem? > > > > Thanks! > > > > Best, > > Xiaoye > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2217533 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > > From owner-freebsd-net@freebsd.org Fri Jan 29 22:12:56 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 321A6A72263 for ; Fri, 29 Jan 2016 22:12:56 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0FB41AEE for ; Fri, 29 Jan 2016 22:12:55 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-ob0-x236.google.com with SMTP id is5so74944295obc.0 for ; Fri, 29 Jan 2016 14:12:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=A1DLkYfr9PsO4TsrwSddp+eUHG2NqzDwhmREI4Kijok=; b=ofn0AVoeTjNA4DFR8xc2gt1YcISVUOJwC6WMaWaAJ5vQCdbhdjYIqzYLDlcoIY/09c qbY1Tfl20BzmyvlNR1GUw3Vv9B+vWKcWzD+SRvff7mZE/Izg0R+oebcctgoKCXd8gT+H pHz3Y4tDD6+i+VyfcFom+aohgVN+hKuKp+ZmoSjybfQa3cNDP5BIM8zjh9P44U3d2KSS LB7ZgqFTpNNC2EvhnCGgpgR98ZfdkhzBvB6Jto0gyVAoLBheJtPd7WPODn1+IYsWQWz2 2po0XFtVEjPD75BKuRGeSaUKd/WwBbXmcJCj3dZDE5wx1rH6qYjgldOZEZj+tcKve8GD Dswg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=A1DLkYfr9PsO4TsrwSddp+eUHG2NqzDwhmREI4Kijok=; b=wauoMS0lIyYd7aydA6TxPtZ5MO2G4BcqHIkPvlKOZhGGgenEubcYArg/0G+Uxayz5q PGtoqdeAQDfQZM34Q6rUld6MyRQFyBnepYDkamgKBr4cnjcxLDWiQZy3ERnn9OvljRVx HMxa5/o7BWqrwAICkZI0UpGLwrynsy05J+jOnNCRGGiHjS1O6MLAKMZ6cSuxdI11cuOg PNl9iG//ir2YlD0BL+bEFW1LuU3fIqu96gTjnK/7C+youjgjh9/PanD2wjyrwdHVh9Fi Hvf8ZD0Fd78a2cBhSC7fSeJibaeVnu3Abk1CEDgcSuJeratu5/k/CRLpU73KrujUWZAr 411A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=A1DLkYfr9PsO4TsrwSddp+eUHG2NqzDwhmREI4Kijok=; b=BJLTY8p41JALIUw81KowheZC14VGn9M9RINMK4BQv2TQGs7qEfQiFIW6odfYdCpTwP Qi+SYLFbtk8TEe8EMr2hBwj6wOfBm4EUH8gX+YvLE4jVf2mBiokaxWr5AJj0RtRbL70E caWyZPBCVU4uapFM2Y61u+LPIW8z4EHLZ1gobr21ybyvk9kHeqBrHkC4Gman3gj7ADGH XWuPiHuUQSWKVQxCv+S9Vvy+UF6mwZe4yJKkYIMZ/LqBYpwBjwI/lUVIE2B6tfDovDS4 9xNBPrDrfpkUddti5sFCgX/7rNmsEpbJ2akD0JXftbHUO3YHtsR9utpVNEBWch5g7YMh wkpA== X-Gm-Message-State: AG10YOQXyWL/CPQcBQwzuNLCSECQxgomjwmmAfk1CaRjIZv5tSDX1KI5No0bCfW5snZ+wBjbxYM+nNKFKm/qvg== MIME-Version: 1.0 X-Received: by 10.60.178.180 with SMTP id cz20mr8471271oec.15.1454105575106; Fri, 29 Jan 2016 14:12:55 -0800 (PST) Sender: sunxiaoye07@gmail.com Received: by 10.202.223.5 with HTTP; Fri, 29 Jan 2016 14:12:55 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Jan 2016 16:12:55 -0600 X-Google-Sender-Auth: DfAS3uCa70BRA5MnD37j17ZdJEY Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Xiaoye Sun To: Luigi Rizzo Cc: Pavel Odintsov , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 22:12:56 -0000 Hi Luigi, Thanks for your advice. I forgot to mention that I use the command "ethtool -L eth1 combined 1" to set the number of rings of the nic to 1. The host also only has one ring. I understand the situation where the first tx ring is full so the bridge will swap the packets to the second tx ring and then the host/nic might drain either rings. But this is not the case in the experiment. Thanks a lot! Xiaoye On Fri, Jan 29, 2016 at 3:45 PM, Luigi Rizzo wrote: > On Fri, Jan 29, 2016 at 1:39 PM, Xiaoye Sun wrote: > > Hi Pavel, > > > > Our code is somewhat complicate. > > So I did a very simple experiment having the same problem so that you > could > > regenerate the problem. > > Xiaoye, > > before doing more experiments can you please clarify > the operating conditions, specifically make sure that > you are only using a single receive and transmit queue > on the NICs in the bridge machine ? > I suspect the problem lies here (it was not clear > from your previous description). > netmap cannot make any guarantee on the transmit > order if you are using multiple transmit queues > (same problem on receive, though it is not relevant > here because almost surely all input traffic goes to > the same queue). > > cheers > luigi > > > In the new experiment, I used a very simple udp sender and udp receiver > > that sends and receives udp packet with seq num. > > > > I put the code here. > > http://www.owlnet.rice.edu/~xs6/receiver.c > > http://www.owlnet.rice.edu/~xs6/sender.c > > > > To repeat the experiment, on machine A, I run the sender program > > (command: sender > > 10.10.10.1 (your receiver IP)). > > On machien B, I run a netmap bridge that swap the slot printer between > the > > host ring and the nic ring (the bridge example in netmap package > > /examples/bridge.c using the command ./bridge netmap:eth1 netmap:eth1) > and > > also run the receiver program. > > > > I am able to see that the receiver print message saying that the new seq > > number is less than the seq number received in the previous round. > > > > Please let me know if you successfully generates the same problem. > > > > Thank! > > Xiaoye > > > > > > > > On Tue, Jan 26, 2016 at 1:53 AM, Pavel Odintsov < > pavel.odintsov@gmail.com> > > wrote: > > > >> Hello! > >> > >> Really useful and detailed research. Thanks a lot! Could you share > >> your validation code? It could be useful for consistency tests for > >> netmap. > >> > >> So I could not help with your original question. Let's wait answer > >> from developers of awesome Netmap :) > >> > >> On Tue, Jan 26, 2016 at 2:55 AM, Xiaoye Sun > wrote: > >> > Hi all, > >> > > >> > I wrote a netmap application that is very similar to bridge.c in > >> master/example > >> > directory of the netmap code. The major difference between my program > and > >> > bridge.c is that my application also creates custom packets that are > >> > directly put into the tx ring of the NIC (like a packet generator with > >> > NIC-Host packet forwarding). Each generated packet has an unique > sequence > >> > number so that the receiver can tell if a packet is lost. > >> > > >> > Like bridge.c, the packet forwarding between the nic and the host uses > >> > 'zerocopy', so that the program only swaps the buf_idx of the slots to > >> > virtually forward the packet to the other end. NS_BUF_CHANGED is set > for > >> > the slots (both rx and tx) whose buf_idx has been changed due to > >> zerocopy. > >> > > >> > I set the number of rings on nic to 1 using the ethtool command, i.e., > >> one > >> > pair of netmap rings for the nic (one for host tx and one for host rx) > >> and > >> > another pair of rings for the host (one for host tx and one for host > rx). > >> > > >> > However, at the receiver side, I found that there is a chance (very > >> little > >> > chance, less than 1% of the swaps) where swapping the buf_idx does not > >> > success. The receiver might get the packet in the buffer swapped out. > For > >> > example, the netmap program wants to swap host slot *SH* with NIC slot > >> *SN* > >> > in order to send the packet in *SH* from host to the receiver; the > >> receiver > >> > might get the packet in *SN* instead. This usually happens to the very > >> end > >> > of the available slots. > >> > > >> > Our experiment is done on *Linux* machine (Linux 3.16.0-4-amd64 #1 SMP > >> > Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux) with* intel NIC* > >> > (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection) > using > >> > the *ixgbe* driver. > >> > > >> > To understand this problem, I look into the patch code to the ixgbe > >> driver. > >> > I found that the flag NS_BUF_CHANGED is not used in the linux driver > for > >> > ixgbe. please look the header file /LINUX/ixgbe_netmap_linux.h. In > >> funtions > >> > ixgbe_netmap_txsync and ixgbe_netmap_rxsync, the function call > >> > netmap_reload_map is commented out. However, the ixgbe's driver patch > for > >> > FreeBSD calls the reload function. > >> > > >> > So, I am wondering if this is a known problem when using netmap on > LINUX. > >> > Has anybody found the same problem? > >> > Is netmap_reload_map required in Linux? why it is not called in the > >> driver > >> > patch? > >> > What is the recommended solution for this problem? > >> > > >> > Thanks! > >> > > >> > Best, > >> > Xiaoye > >> > _______________________________________________ > >> > freebsd-net@freebsd.org mailing list > >> > https://lists.freebsd.org/mailman/listinfo/freebsd-net > >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org > " > >> > >> > >> > >> -- > >> Sincerely yours, Pavel Odintsov > >> > >> > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2217533 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > > From owner-freebsd-net@freebsd.org Fri Jan 29 22:27:05 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30208A7269B for ; Fri, 29 Jan 2016 22:27:05 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A526910A7 for ; Fri, 29 Jan 2016 22:27:04 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id c192so55674572lfe.2 for ; Fri, 29 Jan 2016 14:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wKUZL3wnQNMJpU7HBSDSOEiKP1xGIakCc0akYWjQEaw=; b=rrIea+EY9yd4+Vm5cMJcrmtCKg+GGqLOc7WyZixeSDABWYhSn9Fg74gAVJci8kaDD5 tOkIMKePHAU3oYKm4EtmvDX23akrZUI6XcANHDC318FfONgMZEHYAmgar0ieT9sFyXvD 7FAFKbfI4Bh/MFajegw3kq9coiWshmeC7ZV0C3JyrMGy1qTcKE7NOXMgIRcNLCf+Z0b4 VER7oOmvhbOED6BdNYdQX0sE6bgO2EwND8cTfvY8V3yGRWcnLju4wPr/JNDLJnNZdo9i /qn6P1kaREsuBIFR/gUSqMkZol7/HYVLE0vR7PkktYzAqFZNGc+DgY7+NAgbXmsqmH/m zr2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wKUZL3wnQNMJpU7HBSDSOEiKP1xGIakCc0akYWjQEaw=; b=MUKcMhBi3F0uGOtuLrrRDebuiLnXc04T/KiFzcG3+UFSyDYp1UdVrNwzh61QPcB3l4 YB4rmLO73tZS1dTlpiCEVfC7/LEX3/tiHDuuzTy9ANT1mhOQJVD+wot5RhwBVozvyxos voLqAypUTGb26tLfNx5Nc7CCQVt51qaKJzLAWBcTvQZSFD2cqS753JqCy3TqgMncXyhY PXKBYnZ8gZURlIoukNE0zBAWNg1ldPAGgGCuA19hCLUecOY/qHOu6ArJ01BPYs4/l4bv npUHWtiClDmkbqXtofTIHFQTw8tUq6I8sk4ncY9IgTuzjbg8zhwhDwwwY2kTcIUApooQ R1RQ== X-Gm-Message-State: AG10YOSsadOg7Q2ylQgR4s8lrKwIS6Gw98YYV09LbtFDV5lDyiH18k5Rt5TRyE86vpvpYakiPbr7uL3XNxZffw== MIME-Version: 1.0 X-Received: by 10.25.25.142 with SMTP id 136mr4364134lfz.42.1454106422853; Fri, 29 Jan 2016 14:27:02 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.4.232 with HTTP; Fri, 29 Jan 2016 14:27:02 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Jan 2016 14:27:02 -0800 X-Google-Sender-Auth: Mbbv4oFOgF8Ft65L0xfWzDLwGTY Message-ID: Subject: Re: swaping ring slots between NIC ring and Host ring does not always success From: Luigi Rizzo To: Xiaoye Sun Cc: Pavel Odintsov , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 22:27:05 -0000 On Fri, Jan 29, 2016 at 2:12 PM, Xiaoye Sun wrote: > Hi Luigi, > > Thanks for your advice. > I forgot to mention that I use the command "ethtool -L eth1 combined 1" to > set the number of rings of the nic to 1. The host also only has one ring. > I understand the situation where the first tx ring is full so the bridge > will swap the packets to the second tx ring and then the host/nic might > drain either rings. But this is not the case in the experiment. ok good to know that. So if we have ruled out multiqueue and iommu, let's look at the internal allocator and at bridge.c 1. are you running the most recent version of netmap ? Some older version (probably 1-2 years ago) had a bug in the buffer allocator and some buffers were allocated twice. 2. can you tweak your receiver.c to report some more info on how often you get out of sequence packets, how much out of sequence they are ? Also it would be useful to report gaps on the increasing side (i.e. new_seq != old_seq +1 ) 3. can you tweak bridge.c so that it writes into the packet the netmap buffer indexes and slots on the rx and tx side, so when you detect a sequence error we can figure out where it is happening. Ideally you could also add the sequence number detection code in bridge.c so we can check whether the errors appear on the input or output sides. cheers luigi From owner-freebsd-net@freebsd.org Sat Jan 30 00:16:54 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33247A71F90 for ; Sat, 30 Jan 2016 00:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 237471F7F for ; Sat, 30 Jan 2016 00:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0U0Gs5o075929 for ; Sat, 30 Jan 2016 00:16:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 203922] The kern.ipc.acceptqueue limit is too low Date: Sat, 30 Jan 2016 00:16:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: needs-qa, patch, performance X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: alfred@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: alfred@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 00:16:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203922 Alfred Perlstein changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |alfred@FreeBSD.org --- Comment #9 from Alfred Perlstein --- At a glance the patch looks good. Thank you for doing this work. I will commit shortly. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Jan 30 07:39:30 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8ABC3A72B42 for ; Sat, 30 Jan 2016 07:39:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76B0ADED for ; Sat, 30 Jan 2016 07:39:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0U7dUGs026953 for ; Sat, 30 Jan 2016 07:39:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194485] Userland cannot add IPv6 prefix routes Date: Sat, 30 Jan 2016 07:39:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: easy, feature, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: flagtypes.name bug_status cc keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 07:39:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194485 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |mfc-stable9?, mfc-stable10? Status|New |Open CC| |koobs@FreeBSD.org Keywords| |easy, feature, needs-qa --=20 You are receiving this mail because: You are the assignee for the bug.=