Re: problem in Network device driver.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Its handled by tcp stack within linux kernel. If you want to take a look at the code, then see
open linux/net/ipv4/tcp.c and look at tcp_sendmsg().

Vishal

Devesh Sharma wrote:
One more query I have in my mind, let's say user wants to transfer 1MB
data (callling send() only once), and socket buffer size is set to
4096 for example, how and who handles packaging of data?

On Wed, Apr 22, 2009 at 10:56 AM, Devesh Sharma <devesh28@xxxxxxxxx> wrote:
On Tue, Apr 21, 2009 at 9:48 PM, Michael Blizek
<michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi!

On 18:37 Tue 21 Apr     , Devesh Sharma wrote:
Hello michi, Sorry for late reply. comments are inline:
...

Is there any packet loss on the link? What does "ping -f" and
packet loss is very less......after data transfer in TBits I observer
on  5 tx packet drops
"ping -f -s 4096" say? How much does the latency increase if you send
bigger packets? Is there a "magic value" which causes a "sudden increase"
(e.g. 4051 is much slower than 4050)?
Yes there is a magic number for packet size of 4040 bytes in ping -s
4040 gives proper results
but of ping -s 4041 every alternate packet get delayed upto 1000 ms.
This is interesting:
Ethernet header is 14 byte + 4 byte crc32 (you said, you are using something
else, do you know the header/trailer size?)
There is no additional header or trailer to the packet. Its posted to
my device as given to hard_start_xmit
this is actually an InfiniBand over our proprietary network so its an
IPoIB interface.

IP header is 20 byte
UDP header is 8 byte (what prococol are you using?)
I am using TCP not UDP

---
54 bytes

4040+54 = 4094

I have also checked with my device debugging tool, it posting exactly
2 descriptors each of 2048 size for every 4040 byte ping packet, so
for (4096-4040) = 56 additional bytes.

This is very close to the 4096 page size most machines have. But 1000 ms for
a 8KB continuous memory allocation on a machine with 64GB RAM sounds pretty
extreme. Maybe oprofile has has clues or there was a regression and older
kernels run faster?
How to use oprofile with this? Interrupt handling of my device may
also be a bottle neck?
I am also not able to receive jeffrey's posts!!
       -Michi
--
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com



--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ




--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux