Hi,
I’m doing a little research on multiple iov’s occurrence.
My watch position is below ip.
The objectives were NT and Linux machines. In both the qnx machine behaved
the same.
I’ve put a watch on the number of iov’s per buffer and got to the following
conclusions:
- doing simple ping cause 1 packet in/out with 1 buffer, which contains 1
net_iov.
- doing ftp/telnet cause (at the login time only) few incoming/outgoing
packets. In one of the outgoing packet a packet with 2 iov’s, which has
total size of 46 bytes.
Assuming that multiple iov’s represents fragments:
a) Why is there more then one iov in the buffer? it is only in logging time,
there are no big packet that are been transferred here.
b) When should I expect more then one iov per buffer? except big packets,
which are bigger then 1520.
Benzy Gabay
Benzy Gabay <bgabay@everbee.com> wrote:
Hi,
I’m doing a little research on multiple iov’s occurrence.
My watch position is below ip.
The objectives were NT and Linux machines. In both the qnx machine behaved
the same.
I’ve put a watch on the number of iov’s per buffer and got to the following
conclusions:
- doing simple ping cause 1 packet in/out with 1 buffer, which contains 1
net_iov.
- doing ftp/telnet cause (at the login time only) few incoming/outgoing
packets. In one of the outgoing packet a packet with 2 iov’s, which has
total size of 46 bytes.
Assuming that multiple iov’s represents fragments:
a) Why is there more then one iov in the buffer? it is only in logging time,
there are no big packet that are been transferred here.
b) When should I expect more then one iov per buffer? except big packets,
which are bigger then 1520.
You should ALWAYS assume you will receive a multi iov npkt from your
upper layer, nothing you can do to stop that.
Multi iov or not, DO NOT depends on how much bytes your are transfering.
The big stack (npm-tcpip.so) decided how much “iov” by optimize
the buffer using. That is, it might decided to use “2 small buffer”
(128 bytes per buffer) to transfer 200 bytes, instead of use
“1 large buffer (2048 bytes)” to transfer 200 bytes.
-xtang
Benzy Gabay <bgabay@everbee.com> wrote:
: Hi,
: I’m doing a little research on multiple iov’s occurrence.
: My watch position is below ip.
: The objectives were NT and Linux machines. In both the qnx machine behaved
: the same.
: I’ve put a watch on the number of iov’s per buffer and got to the following
: conclusions:
: 1) doing simple ping cause 1 packet in/out with 1 buffer, which contains 1
: net_iov.
: 2) doing ftp/telnet cause (at the login time only) few incoming/outgoing
: packets. In one of the outgoing packet a packet with 2 iov’s, which has
: total size of 46 bytes.
: Assuming that multiple iov’s represents fragments:
‘Fragment’ in the ip world has a special meaning. One npkt from the
ip stack is a complete ip packet. That ip packet may be multiple iov’s and
may or may not be an ip fragment.
: a) Why is there more then one iov in the buffer? it is only in logging time,
: there are no big packet that are been transferred here.
Both stacks go through a lot of pain to balance scatter gather vs
number of iov’s sent to the drivers. It’s faster this way.
: b) When should I expect more then one iov per buffer? except big packets,
: which are bigger then 1520.
You should never count on a single iov.
-seanb
is there a top limit for the number of iov’s that be in one buffer / packet
? if yes what is it?
–
Benzy Gabay
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:9m5m81$8cg$3@nntp.qnx.com…
Benzy Gabay <> bgabay@everbee.com> > wrote:
Hi,
I’m doing a little research on multiple iov’s occurrence.
My watch position is below ip.
The objectives were NT and Linux machines. In both the qnx machine
behaved
the same.
I’ve put a watch on the number of iov’s per buffer and got to the
following
conclusions:
- doing simple ping cause 1 packet in/out with 1 buffer, which contains
1
net_iov.
- doing ftp/telnet cause (at the login time only) few incoming/outgoing
packets. In one of the outgoing packet a packet with 2 iov’s, which has
total size of 46 bytes.
Assuming that multiple iov’s represents fragments:
a) Why is there more then one iov in the buffer? it is only in logging
time,
there are no big packet that are been transferred here.
b) When should I expect more then one iov per buffer? except big
packets,
which are bigger then 1520.
You should ALWAYS assume you will receive a multi iov npkt from your
upper layer, nothing you can do to stop that.
Multi iov or not, DO NOT depends on how much bytes your are transfering.
The big stack (npm-tcpip.so) decided how much “iov” by optimize
the buffer using. That is, it might decided to use “2 small buffer”
(128 bytes per buffer) to transfer 200 bytes, instead of use
“1 large buffer (2048 bytes)” to transfer 200 bytes.
-xtang
Benzy Gabay <bgabay@everbee.com> wrote:
is there a top limit for the number of iov’s that be in one buffer / packet
? if yes what is it?
No. (well it’s a int, so I guess logic limit is MAX_INT).
-xtang
–
Benzy Gabay
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:9m5m81$8cg$> 3@nntp.qnx.com> …
Benzy Gabay <> bgabay@everbee.com> > wrote:
Hi,
I’m doing a little research on multiple iov’s occurrence.
My watch position is below ip.
The objectives were NT and Linux machines. In both the qnx machine
behaved
the same.
I’ve put a watch on the number of iov’s per buffer and got to the
following
conclusions:
- doing simple ping cause 1 packet in/out with 1 buffer, which contains
1
net_iov.
- doing ftp/telnet cause (at the login time only) few incoming/outgoing
packets. In one of the outgoing packet a packet with 2 iov’s, which has
total size of 46 bytes.
Assuming that multiple iov’s represents fragments:
a) Why is there more then one iov in the buffer? it is only in logging
time,
there are no big packet that are been transferred here.
b) When should I expect more then one iov per buffer? except big
packets,
which are bigger then 1520.
You should ALWAYS assume you will receive a multi iov npkt from your
upper layer, nothing you can do to stop that.
Multi iov or not, DO NOT depends on how much bytes your are transfering.
The big stack (npm-tcpip.so) decided how much “iov” by optimize
the buffer using. That is, it might decided to use “2 small buffer”
(128 bytes per buffer) to transfer 200 bytes, instead of use
“1 large buffer (2048 bytes)” to transfer 200 bytes.
-xtang
In article <9mc6g7$7iu$1@nntp.qnx.com>, xtang@qnx.com says…
Benzy Gabay <> bgabay@everbee.com> > wrote:
is there a top limit for the number of iov’s that be in one buffer / packet
? if yes what is it?
No. (well it’s a int, so I guess logic limit is MAX_INT).
-xtang
Actually, I would guess that it is highly unlikely (or maybe even
impossible) to get more iov’s than there are bytes in the packet… 
Since Ethernet MTU is 1500 or so, I would guess that an upper limit of
2000 would never be reached in the current environment.
–
Benzy Gabay
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:9m5m81$8cg$> 3@nntp.qnx.com> …
Benzy Gabay <> bgabay@everbee.com> > wrote:
Hi,
I’m doing a little research on multiple iov’s occurrence.
My watch position is below ip.
The objectives were NT and Linux machines. In both the qnx machine
behaved
the same.
I’ve put a watch on the number of iov’s per buffer and got to the
following
conclusions:
- doing simple ping cause 1 packet in/out with 1 buffer, which contains
1
net_iov.
- doing ftp/telnet cause (at the login time only) few incoming/outgoing
packets. In one of the outgoing packet a packet with 2 iov’s, which has
total size of 46 bytes.
Assuming that multiple iov’s represents fragments:
a) Why is there more then one iov in the buffer? it is only in logging
time,
there are no big packet that are been transferred here.
b) When should I expect more then one iov per buffer? except big
packets,
which are bigger then 1520.
You should ALWAYS assume you will receive a multi iov npkt from your
upper layer, nothing you can do to stop that.
Multi iov or not, DO NOT depends on how much bytes your are transfering.
The big stack (npm-tcpip.so) decided how much “iov” by optimize
the buffer using. That is, it might decided to use “2 small buffer”
(128 bytes per buffer) to transfer 200 bytes, instead of use
“1 large buffer (2048 bytes)” to transfer 200 bytes.
-xtang
\
–
Stephen Munnings
Software Developer
Corman Technologies Inc.
Stephen Munnings <steve@cormantech.com> wrote:
: In article <9mc6g7$7iu$1@nntp.qnx.com>, xtang@qnx.com says…
:> Benzy Gabay <bgabay@everbee.com> wrote:
:> > is there a top limit for the number of iov’s that be in one buffer / packet
:> > ? if yes what is it?
:>
:> No. (well it’s a int, so I guess logic limit is MAX_INT).
:>
:> -xtang
: Actually, I would guess that it is highly unlikely (or maybe even
: impossible) to get more iov’s than there are bytes in the packet…
: Since Ethernet MTU is 1500 or so, I would guess that an upper limit of
: 2000 would never be reached in the current environment.
Unless the stack sent down 0 length iov’s 
. The practical limit
for the small stack is 4; the large stack, 45 (almost never near this).
-seanb