Tx Flow - No of npkts in the linked list, the tot_iov in eac

QNX Newsgroups (Archives) qdn.public.ddk.network
1

Hello,
Could anyone please clarify:
When my drivers’ TxFxn, gets invoked, npkt contains a list of npkts.
I want to know on what basis the following fields in the npkt are decided:

  1. number of npkts in the list.
  2. tot_iov in each npkt. (Number of Fragements)
  3. iov_len (Fragment Length)

In the example code, if the free Tx descriptors < tot_iov, we go for
defragementing, which results in creating only one npkt. In that if the sum
of iov_len > 1520, we reject the packet. Wat is the idea behind it.?

Thanks
Jalaja

2

Jalaja <jganapat@storage.com> wrote:

Hello,
Could anyone please clarify:
When my drivers’ TxFxn, gets invoked, npkt contains a list of npkts.
I want to know on what basis the following fields in the npkt are decided:

  1. number of npkts in the list.
  2. tot_iov in each npkt. (Number of Fragements)
  3. iov_len (Fragment Length)

Actually, the npkt contains a list of IOV’s that make up a single packet.
It is also possible that the npkt->next field is not null and points to
an additonal npkt which also has IOV’s. The tot_iov is the number of
IOV’s in the packet that makes up the complete packet data. The iov_len
is the lenth of a sinle IOV.

In the example code, if the free Tx descriptors < tot_iov, we go for
defragementing, which results in creating only one npkt. In that if the sum
of iov_len > 1520, we reject the packet. Wat is the idea behind it.?

Well, since the descriptors hold a single IOV we need to make sure that
that there are enough descriptors to hold a complete packet. If there
isn’t then we “defrag” the packet so it only needs a single IOV. If
the packet is bettering the 1520 we toss it since that is too large to
be an ethernet packet.

chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

3

“Chris McKillop” <cdm@qnx.com> wrote in message
news:99itgt$ibo$1@nntp.qnx.com…

Jalaja <> jganapat@storage.com> > wrote:

Hello,
Could anyone please clarify:
When my drivers’ TxFxn, gets invoked, npkt contains a list of npkts.
I want to know on what basis the following fields in the npkt are
decided:

  1. number of npkts in the list.
  2. tot_iov in each npkt. (Number of Fragements)
  3. iov_len (Fragment Length)


    Actually, the npkt contains a list of IOV’s that make up a single packet.
    It is also possible that the npkt->next field is not null and points to
    an additonal npkt which also has IOV’s. The tot_iov is the number of
    IOV’s in the packet that makes up the complete packet data. The iov_len
    is the lenth of a sinle IOV.

I understand this completely. But my question is, what is the limitation
of number of IOVs in each npkt? what is the limitation of iov_len of each
IOV? For ex. Can I have 100s of IOVs each consisting of some 10 bytes? On
what basis the the number of IOVs and the iov_len is decided. Also,
npkt->next may contain a non-null pointer. How many npkts I can have in the
list? When I want to give the packet up to io_net, I want to decide on these
factors.

In the example code, if the free Tx descriptors < tot_iov, we go for
defragementing, which results in creating only one npkt. In that if the
sum
of iov_len > 1520, we reject the packet. Wat is the idea behind it.?

Well, since the descriptors hold a single IOV we need to make sure that
that there are enough descriptors to hold a complete packet. If there
isn’t then we “defrag” the packet so it only needs a single IOV. If
the packet is bettering the 1520 we toss it since that is too large to
be an ethernet packet.

I just need an suggestion here. I have two different set of Transfer
decriptors for my project, say Tx1Type, Tx2Type. If the packet length is
lesser than some LIMIT, they go for Tx1Type, else Tx2Type. So here I am
unable to check out the received IOVs is less than my than my Tranfer
descriptors (cuz I have two different sets here).
So what i did was, I go for defrag everytime when i receive a packet and
then depending on the length go for choosing Tx1Type tranfer descriptor or
the other one.

I do like this:

epic_send_packets (npkt_t *npkt, void *hdl)
{
dpkt = defrag (npkt);
if (dpkt->buffers->net_iov_iov_len < LIMIT)
Get Tx1Type descriptor and send the packet down
else
Get Tx2Type descriptor and send the packet down;
}

Here I am not checking (if tot_iov > TX_DESCRIPTORS). I defrag everytime.
Does this make sense? Or shd i need to go for any other mechanism?


chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

4

Jalaja <jganapat@storage.com> wrote:

I understand this completely. But my question is, what is the limitation
of number of IOVs in each npkt? what is the limitation of iov_len of each
IOV? For ex. Can I have 100s of IOVs each consisting of some 10 bytes? On
what basis the the number of IOVs and the iov_len is decided. Also,
npkt->next may contain a non-null pointer. How many npkts I can have in the
list? When I want to give the packet up to io_net, I want to decide on these
factors.

In theory there is no upper limit to either the IOV’s or the number of
packets. In practical terms there is normally a single packet and
somewhere between 2 and 20 IOV’s. However, your driver shouldn’t care. :wink:


Here I am not checking (if tot_iov > TX_DESCRIPTORS). I defrag everytime.
Does this make sense? Or shd i need to go for any other mechanism?

It does, but it will hurt your performance to defrag on every packet. If
that is okay then you are fine. You could also just loop over the
IOV’s and check npkt->framelen to get the packet size and then “do the
right thing” with respect to which type of descriptor you need to use.

chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

5

“Chris McKillop” <cdm@qnx.com> wrote in message
news:99nqk9$e28$1@nntp.qnx.com…

Jalaja <> jganapat@storage.com> > wrote:


In theory there is no upper limit to either the IOV’s or the number of
packets. In practical terms there is normally a single packet and
somewhere between 2 and 20 IOV’s. However, your driver shouldn’t care. > :wink:

While I send the packet up to the io_net, whatz the logic i need to follow,
any number of IOVs with any iov_len??

Also, Could you please tell me what are the debugging tools available to
debug my driver other than printf ??

6

Jalaja <jganapat@storage.com> wrote:

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:99nqk9$e28$> 1@nntp.qnx.com> …
Jalaja <> jganapat@storage.com> > wrote:


In theory there is no upper limit to either the IOV’s or the number of
packets. In practical terms there is normally a single packet and
somewhere between 2 and 20 IOV’s. However, your driver shouldn’t care. > :wink:

While I send the packet up to the io_net, whatz the logic i need to follow,
any number of IOVs with any iov_len??

“In theory” again, yes. any number of IOVs and any iov_len.
set the correct tot_iov please.

Most upper protocol layer have a “fast path” in hope that
tot_iov == 1, so if you can, use one IOV (with framelen == iov_len)
is encourged.

Also, Could you please tell me what are the debugging tools available to
debug my driver other than printf ??

What’s wrong with gdb? :slight_smile:

-xtang

7

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:99r205$bup$1@nntp.qnx.com…

Jalaja <> jganapat@storage.com> > wrote:

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:99nqk9$e28$> 1@nntp.qnx.com> …
Jalaja <> jganapat@storage.com> > wrote:

Thanks!!

What’s wrong with gdb? > :slight_smile:
I am doing mount-t devn-mydriver.so. I am not sure whether we can use gdb.

If so, could you plz tell me how to use gdb on my shared so? I could not
find off-hand doc for this.


-xtang

8

Jalaja <jganapat@storage.com> wrote:

Thanks!!
What’s wrong with gdb? > :slight_smile:
I am doing mount-t devn-mydriver.so. I am not sure whether we can use gdb.
If so, could you plz tell me how to use gdb on my shared so? I could not
find off-hand doc for this.

Look into using gdb to attach to a running process (io-net in this case).
You can also start more then one io-net at a time so you can keep your
main io-net running while you start another one for debugging your driver
using gdb.

chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

9

Look into using gdb to attach to a running process (io-net in this case).
You can also start more then one io-net at a time so you can keep your
main io-net running while you start another one for debugging your driver
using gdb.

I looked into the doc. It says to attach process_id, to attach a running
process for debugging.
I do the following in the command line:

  1. io-net &
  2. mount -Tio-net mydriver-devn.so

So, initially i start io-net. To get the process id , i do pidin, but it
lists many io-nets running ex.
sbin/io-net 10r RECEIVE 1
sbin/io-net 10r RECEIVE 1

  1. I am not sure how to find my io-net
  2. And How to attach my driver which is done above using mount
    (mount -Tio-net mydriver-devn.so) to debug my driver code. I am sorry i
    just could not find the doc for this.



chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

10

Jalaja <jganapat@storage.com> wrote:

I looked into the doc. It says to attach process_id, to attach a running
process for debugging.
I do the following in the command line:

  1. io-net &
  2. mount -Tio-net mydriver-devn.so

So, initially i start io-net. To get the process id , i do pidin, but it
lists many io-nets running ex.
sbin/io-net 10r RECEIVE 1
sbin/io-net 10r RECEIVE 1

  1. I am not sure how to find my io-net

If you have an io-net started at boot time and one your run at a later
time, the one run at a later time will have a bigger PID then the
other one. Here is a better output from pidin…

cdm@katana → pidin | grep io-net
671763 1 o-net/x86/o/io-net 10r SIGWAITINFO
671763 2 o-net/x86/o/io-net 10r RECEIVE 1
671763 3 o-net/x86/o/io-net 18r RECEIVE 1
671763 4 o-net/x86/o/io-net 21r RECEIVE 3
671763 5 o-net/x86/o/io-net 20r RECEIVE 6
671763 6 o-net/x86/o/io-net 10r RECEIVE 1

The first number is the pid which you pass to gdb. You can get a list
of threads once gdb is attached and figure out which one your driver
is using and setup breakpoints, etc, etc.

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

11

Jalaja <jganapat@storage.com> wrote:

Look into using gdb to attach to a running process (io-net in this case).
You can also start more then one io-net at a time so you can keep your
main io-net running while you start another one for debugging your driver
using gdb.

I looked into the doc. It says to attach process_id, to attach a running
process for debugging.
I do the following in the command line:

  1. io-net &
  2. mount -Tio-net mydriver-devn.so

gdb /sbin/io-net

(gdb) run
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c

In another shell:

mount -Tio-net mydriver-devn.so

ctrl-c the gdb:
(gdb) l mydriver_tx_up

-xtang

12

This really helps me!! Thanks you sooo much!!!


“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:99svab$ftr$1@nntp.qnx.com…

Jalaja <> jganapat@storage.com> > wrote:

Look into using gdb to attach to a running process (io-net in this
case).
You can also start more then one io-net at a time so you can keep your
main io-net running while you start another one for debugging your
driver
using gdb.

I looked into the doc. It says to attach process_id, to attach a running
process for debugging.
I do the following in the command line:

  1. io-net &
  2. mount -Tio-net mydriver-devn.so

gdb /sbin/io-net

(gdb) run
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c

In another shell:

mount -Tio-net mydriver-devn.so

ctrl-c the gdb:
(gdb) l mydriver_tx_up

-xtang

13

I just want to know how can i do step by step debugging. I tried with “s”
instead of “c”. Even then, gdb continues, printing all the printf messages
of my code.
I guess I need to add -g option (but in which level, which file ???) and
load the symbols. (how???)

And and one more query. When i do the below said steps, when i say
(gdb) c
Conitunuing
libc.so No such file or directory
(gdb)

When I do again, it just waits there.
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c
(gdb)Continuing.

Thanks,
Jalaja

gdb /sbin/io-net

(gdb) run
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c

In another shell:

mount -Tio-net mydriver-devn.so

ctrl-c the gdb:
(gdb) l mydriver_tx_up

14

It does not ‘wait there’. It is ‘continuing’ which means it passed
control to your code and your code runs. It will run until it either
exits or hits a breakpoint. You are supposed to set a breakpoint before
doing ‘c’ (which stands for ‘continue’).

Jalaja wrote:

I just want to know how can i do step by step debugging. I tried with “s”
instead of “c”. Even then, gdb continues, printing all the printf messages
of my code.
I guess I need to add -g option (but in which level, which file ???) and
load the symbols. (how???)

And and one more query. When i do the below said steps, when i say
(gdb) c
Conitunuing
libc.so No such file or directory
(gdb)

When I do again, it just waits there.
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c
(gdb)Continuing.

Thanks,
Jalaja

gdb /sbin/io-net

(gdb) run
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c

In another shell:

mount -Tio-net mydriver-devn.so

ctrl-c the gdb:
(gdb) l mydriver_tx_up

15

I tried that saying
(gdb) b my_fxn
Function my_fxn not defined.

I am not sure whether we need to load the symbols or to set any debug flags.


I just want to know how can i do step by step debugging. I tried with
“s”
instead of “c”. Even then, gdb continues, printing all the printf
messages
of my code.
I guess I need to add -g option (but in which level, which file ???) and
load the symbols. (how???)

And and one more query. When i do the below said steps, when i say
(gdb) c
Conitunuing
libc.so No such file or directory
(gdb)

When I do again, it just waits there.
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c
(gdb)Continuing.

Thanks,
Jalaja

gdb /sbin/io-net

(gdb) run
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c

In another shell:

mount -Tio-net mydriver-devn.so

ctrl-c the gdb:
(gdb) l mydriver_tx_up

16

It probably means your function is in library/DLL which has not been
loaded yet.
You should spend some time reading GDB docs, FAQs, etc. There are
workarounds for that problem.

  • igor

Jalaja wrote:

I tried that saying
(gdb) b my_fxn
Function my_fxn not defined.

I am not sure whether we need to load the symbols or to set any debug flags.

I just want to know how can i do step by step debugging. I tried with
“s”
instead of “c”. Even then, gdb continues, printing all the printf
messages
of my code.
I guess I need to add -g option (but in which level, which file ???) and
load the symbols. (how???)

And and one more query. When i do the below said steps, when i say
(gdb) c
Conitunuing
libc.so No such file or directory
(gdb)

When I do again, it just waits there.
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c
(gdb)Continuing.

Thanks,
Jalaja

gdb /sbin/io-net

(gdb) run
(gdb) set solib-search-path /directory/of/mydriver.so/
(gdb) set auto-solib-add 1
(gdb) c

In another shell:

mount -Tio-net mydriver-devn.so

ctrl-c the gdb:
(gdb) l mydriver_tx_up