* /proc/net/tcp6 inconsistent line length @ 2012-01-17 15:29 abirvalg 2012-01-17 13:33 ` David Laight 2012-01-17 14:29 ` David Miller 0 siblings, 2 replies; 6+ messages in thread From: abirvalg @ 2012-01-17 15:29 UTC (permalink / raw) To: netdev My application relies heavily on the constant number of chars in a line of /proc/net/tcp* files /proc/net/tcp does pad have such constancy 0: 000000:006F ....... 1: 000000:DD36 ....... 2: 000000:B23A ....... We know that 1 is exactly 150 chars after 0 and 2 is exactly 150 chars after 1 and so forth. There is no such consistency with /proc/net/tcp6, i.e. sl local_address remote_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode 0: 00000000000000000000000000000000:DD36 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 162811 1 ea464b00 300 0 0 2 -1 1: 0000000000000000FFFF00000100007F:225B 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 109176 1 ea464000 300 0 0 2 -1 2: 0000000000000000FFFF00007201A8C0:A4F4 0000000000000000FFFF000009A6D38C:0050 08 00000000:00000001 00:00000000 00000000 1000 0 3128779 1 c210f700 66 4 0 3 2 3: 0000000000000000FFFF00007201A8C0:AD90 0000000000000000FFFF00001AC64F42:0050 08 00000000:00000001 00:00000000 00000000 1000 0 3128796 1 ea465600 4800 4 0 3 2 4: 0000000000000000FFFF00007201A8C0:DD24 0000000000000000FFFF00002CD8D2CF:0050 01 00000000:00000000 00:00000000 00000000 1000 0 3128263 1 c210ec00 295 0 0 3 2 5: 0000000000000000FFFF00007201A8C0:BBC6 0000000000000000FFFF000063E8B244:0050 01 00000000:00000000 00:00000000 00000000 1000 0 3128375 1 c210c580 4800 0 0 4 2 (word wrap need to turned off when viewing this to better understand my point. Here the amount of chars fluctuate: between 0 and 1 = 170 chars between 1 and 2 = 170 chars between 2 and 3 = 169 chars between 3 and 4 = 171 chars between 4 and 5 = 170 chars Is it possible to implement a constant amount of chars in one line just like in /proc/net/tcp. This is very helpful for parsing when you extract i.e. the source port, then seek 150 chars and extract the next line's source port and so on. My application parses /proc/net/tcp6 at least 4 times per second, so the overhead of figuring out the length of each line and subtracting the offset is quite expensive. P.S. Please CC me when replying to this thread ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: /proc/net/tcp6 inconsistent line length 2012-01-17 15:29 /proc/net/tcp6 inconsistent line length abirvalg @ 2012-01-17 13:33 ` David Laight 2012-01-17 16:14 ` abirvalg 2012-01-17 14:29 ` David Miller 1 sibling, 1 reply; 6+ messages in thread From: David Laight @ 2012-01-17 13:33 UTC (permalink / raw) To: abirvalg, netdev > My application parses /proc/net/tcp6 at least 4 times per > second, so the overhead of figuring out the length of each > line and subtracting the offset is quite expensive. I'd be surprised if you can detect the cost of calling strchr(buf, '\n') on each line at the frequency. It is probably far less than the other processing you do on the line. David ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: /proc/net/tcp6 inconsistent line length 2012-01-17 13:33 ` David Laight @ 2012-01-17 16:14 ` abirvalg 2012-01-17 15:13 ` Eric Dumazet 0 siblings, 1 reply; 6+ messages in thread From: abirvalg @ 2012-01-17 16:14 UTC (permalink / raw) To: netdev On Tue, 17 Jan 2012 13:33:01 -0000 "David Laight" <David.Laight@ACULAB.COM> wrote: > > > My application parses /proc/net/tcp6 at least 4 times per > > second, so the overhead of figuring out the length of each > > line and subtracting the offset is quite expensive. > > I'd be surprised if you can detect the cost of calling > strchr(buf, '\n') on each line at the frequency. > > It is probably far less than the other processing you > do on the line. > > David > > Thank you, David. I first fread() the whole file to membuf and then process it thusly trying to find a line that matches my source port (porthex) : while(1){ memcpy(buffer,&tcp6_membuf[184+170*i],4); if ( !memcmp ( porthex, buffer, 4 ) ){ //match! goto endloop; } i++; continue; N.B. 184 is the offset of source port on line 2 from the beginning of file (line 1 is used for column headings) my /proc/net/tcp6 file contains 300 - 500 lines and I parse it at least from 4 to 10 times per sec. So the maximum is 5000 iterations per sec. It would be very costly CPU wise to do strchr(buf, '\n') I'm not skillful enough to understand the code in kernel sources. My concern boils down to this: Was /proc/net/tcp* meant to have an equal length of each line? If yes, then I discovered a bug. If no, then would it be possible to patch the kernel to enable an equal length on each line? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: /proc/net/tcp6 inconsistent line length 2012-01-17 16:14 ` abirvalg @ 2012-01-17 15:13 ` Eric Dumazet 2012-01-17 15:15 ` David Miller 0 siblings, 1 reply; 6+ messages in thread From: Eric Dumazet @ 2012-01-17 15:13 UTC (permalink / raw) To: abirvalg; +Cc: netdev Le mardi 17 janvier 2012 à 16:14 +0000, abirvalg@lavabit.com a écrit : > Thank you, David. I first fread() the whole file to membuf and then process it thusly trying to find a line that matches my source port (porthex) : > > while(1){ > memcpy(buffer,&tcp6_membuf[184+170*i],4); > if ( !memcmp ( porthex, buffer, 4 ) ){ //match! > goto endloop; > } > i++; > continue; Wow... no comment on this code. > > N.B. 184 is the offset of source port on line 2 from the beginning of file (line 1 is used for column headings) > > my /proc/net/tcp6 file contains 300 - 500 lines and I parse it at least from 4 to 10 times per sec. So the maximum is 5000 iterations per sec. It would be very costly CPU wise to do strchr(buf, '\n') > > I'm not skillful enough to understand the code in kernel sources. > My concern boils down to this: > > Was /proc/net/tcp* meant to have an equal length of each line? > If yes, then I discovered a bug. > If no, then would it be possible to patch the kernel to enable an equal length on each line? > netlink can give you the needed information much faster. Take a look at what is done by : "ss -emoi src :22" State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 0 192.168.20.108:22 10.37.168.20:39444 timer:(keepalive,115min,0) ino:6852 sk:ffff88011ca81900 mem:(r0,w0,f8192,t0) ts sack cubic wscale:4,4 rto:208 rtt:8/11 ato:51 cwnd:10 ssthresh:24 send 14.5Mbps rcv_rtt:15 rcv_space:14480 sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(3)=[{"`\0\0\0\22\0\1\3@\342\1\0\0\0\0\0\2\0\0\17\0\0\0\0\0\0\0\0 \0\0\0\0"..., 76}, {"\24\0\1\0", 4}, {"\7\20\24\0\0\0\0\0\26\0\0\0\0\0\0 \0", 16}], msg_controllen=0, msg_flags=0}, 0) = 96 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\344\0\0\0\22\0\2\0@\342\1\0l\f\0\0\2\1\1\0\0\26\232\24 \300\250\24l320 "..., 8192}], msg_controllen=0, msg_flags=0}, 0) = 228 One sendmsg() for the request, one recvmsg() for the answer (with _all_ details included), even if your /proc/net/tcp*** has 1.000.000 lines. Really say no to /proc files. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: /proc/net/tcp6 inconsistent line length 2012-01-17 15:13 ` Eric Dumazet @ 2012-01-17 15:15 ` David Miller 0 siblings, 0 replies; 6+ messages in thread From: David Miller @ 2012-01-17 15:15 UTC (permalink / raw) To: eric.dumazet; +Cc: abirvalg, netdev From: Eric Dumazet <eric.dumazet@gmail.com> Date: Tue, 17 Jan 2012 16:13:17 +0100 > One sendmsg() for the request, one recvmsg() for the answer (with _all_ > details included), even if your /proc/net/tcp*** has 1.000.000 lines. > > Really say no to /proc files. Indeed. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: /proc/net/tcp6 inconsistent line length 2012-01-17 15:29 /proc/net/tcp6 inconsistent line length abirvalg 2012-01-17 13:33 ` David Laight @ 2012-01-17 14:29 ` David Miller 1 sibling, 0 replies; 6+ messages in thread From: David Miller @ 2012-01-17 14:29 UTC (permalink / raw) To: abirvalg; +Cc: netdev From: <abirvalg@lavabit.com> Date: Tue, 17 Jan 2012 15:29:19 +0000 > My application relies heavily on the constant number of chars in a line of /proc/net/tcp* files Too bad, parse the fields properly. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-17 15:15 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-01-17 15:29 /proc/net/tcp6 inconsistent line length abirvalg 2012-01-17 13:33 ` David Laight 2012-01-17 16:14 ` abirvalg 2012-01-17 15:13 ` Eric Dumazet 2012-01-17 15:15 ` David Miller 2012-01-17 14:29 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).