Question on Partial Checksum in TCP/IP

2001-06-04 Thread Bharath Madhavan

Hello all,
I am trying to understand a little bit about the TCP path in the
Linux kernel.
I saw that while we were even copying the user data into kernel space, we
were doing
the partial checksum of the data portion alone (as the TCP header is not yet
filled up) and storing 
it in skb->csum. 
Later on when we fill the header portion, we do the checksum of the header
and "add" it to the
already calculated checksum of the data. Here we check if the HW performs
the checksum 
or not (skb->ip_summed == CHECKSUM_HW). I am looking into kernel ver 2.4
My question is, why is this check not performed when the data is copied
initially. Instead of
calling csum_and_copy_from_user, if we did a memcpy in the case when HW does
the checksum,
would'nt that be more efficient? Or have I overlooked something...

Thanks a lot

PS. Please CC responses to me also as I am not subscribed to the mailing
list. Thanks

Bharath


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Question on Partial Checksum in TCP/IP

2001-06-04 Thread Bharath Madhavan

Hello all,
I am trying to understand a little bit about the TCP path in the
Linux kernel.
I saw that while we were even copying the user data into kernel space, we
were doing
the partial checksum of the data portion alone (as the TCP header is not yet
filled up) and storing 
it in skb-csum. 
Later on when we fill the header portion, we do the checksum of the header
and add it to the
already calculated checksum of the data. Here we check if the HW performs
the checksum 
or not (skb-ip_summed == CHECKSUM_HW). I am looking into kernel ver 2.4
My question is, why is this check not performed when the data is copied
initially. Instead of
calling csum_and_copy_from_user, if we did a memcpy in the case when HW does
the checksum,
would'nt that be more efficient? Or have I overlooked something...

Thanks a lot

PS. Please CC responses to me also as I am not subscribed to the mailing
list. Thanks

Bharath


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



RE: Accelerated TCP/IP support from kernel

2001-05-25 Thread Bharath Madhavan

Hello all,
We will most probably be looking into supporting Gig MACs and that
is
the reason why I was wondering if HW assist will help.
We are talking of Gigs of network data (dont ask me the application!)
I dont know about IPv6 support, we havent thought of that.
But the point is, We can visualize a scenario where the processor
is overworked and we want to relieve it off some of its load.
To summarize the info I got from the mailing list, there are two
conflicting views about this topic.
1. Protocol processing does not take much time compared to data processing 
and so the ZERO_COPY/HW_CHECKSUM feature in Linux currently is good enough.
2. The application maybe unique and heavy load that it may save the
processor
some bandwidth especially when several TCP connections needs to be
maintained.

I am mainly looking into case 2, and just trying to see the amount of work
that needs to go into this area. I am asking your expert opinions and find
out if this is an easy job, if so can it be done to maintain compatability 
with older NICs too and able to move along easily with standard linux
distributions. If the kernel can provide some hooks to "branch off" to
a different set of drivers at the socket level, that will do the trick I
think.
Is this easy?
Thanks a lot
Bharath






-Original Message-
From: David S. Miller [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 24, 2001 7:08 PM
To: Bharath Madhavan
Cc: '[EMAIL PROTECTED]'
Subject: RE: Accelerated TCP/IP support from kernel



Bharath Madhavan writes:
 > I guess 3c905c NIC supports HW checksumming. Is this true?

Yes.

 > In this case, do we have any benchmarking for this card 
 > with and without ZERO_COPY (and HW checksumming). I am eager to
 > know by how many times did the system throughput increase?

It doesn't matter with 100baseT cards, they are slow enough that even
with the cpu doing the data copies the link may be easily saturated.
What you will get is decreased CPU utilization.

You need to go to gigabit or faster link speeds to see any real
throughput improvement.

Later,
David S. Miller
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



RE: Accelerated TCP/IP support from kernel

2001-05-25 Thread Bharath Madhavan

Hello all,
We will most probably be looking into supporting Gig MACs and that
is
the reason why I was wondering if HW assist will help.
We are talking of Gigs of network data (dont ask me the application!)
I dont know about IPv6 support, we havent thought of that.
But the point is, We can visualize a scenario where the processor
is overworked and we want to relieve it off some of its load.
To summarize the info I got from the mailing list, there are two
conflicting views about this topic.
1. Protocol processing does not take much time compared to data processing 
and so the ZERO_COPY/HW_CHECKSUM feature in Linux currently is good enough.
2. The application maybe unique and heavy load that it may save the
processor
some bandwidth especially when several TCP connections needs to be
maintained.

I am mainly looking into case 2, and just trying to see the amount of work
that needs to go into this area. I am asking your expert opinions and find
out if this is an easy job, if so can it be done to maintain compatability 
with older NICs too and able to move along easily with standard linux
distributions. If the kernel can provide some hooks to branch off to
a different set of drivers at the socket level, that will do the trick I
think.
Is this easy?
Thanks a lot
Bharath






-Original Message-
From: David S. Miller [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 24, 2001 7:08 PM
To: Bharath Madhavan
Cc: '[EMAIL PROTECTED]'
Subject: RE: Accelerated TCP/IP support from kernel



Bharath Madhavan writes:
  I guess 3c905c NIC supports HW checksumming. Is this true?

Yes.

  In this case, do we have any benchmarking for this card 
  with and without ZERO_COPY (and HW checksumming). I am eager to
  know by how many times did the system throughput increase?

It doesn't matter with 100baseT cards, they are slow enough that even
with the cpu doing the data copies the link may be easily saturated.
What you will get is decreased CPU utilization.

You need to go to gigabit or faster link speeds to see any real
throughput improvement.

Later,
David S. Miller
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Accelerated TCP/IP support from kernel

2001-05-24 Thread Bharath Madhavan

Hello all,
I am looking into a scenario where we have a NIC which performs 
all the TCP/IP processing and basically the core CPU offloads all data from
the socket level interface onwards to this NIC. 
Can Linux do this as of now. I saw some limited support like TCP/IP
checksumming
being done in HW (ex: 3c905c) and linux supports it. I also saw the
ZERO_COPY
feature in linux code. 
My question is can there be support for entire (almost) TCP/IP to be
offloaded 
to a NIC card. I noticed some NIC cards by Alacritec and Applicom who have 
such NICs but it looks like the support from Linux would be quite a bit of
work.
Basically Linux needs to support all socket calls as it will usually but
the socket interface must be intelligent enough to call different drivers(!)
for those NIC cards and thus bypassing the whole of TCP/IP stack of Linux.
Is this possible at all and if so, is anyone doing this???
I talked to a vendor who does this NIC and he said that they provide a
library
for linux which means that they have proprietery functions for using their
NIC
and thus this cannot be used in the standard socket interface way. That is a
big
limitation and not of much use. Basically, I am looking into a case where 
the kernel code needs to be changed to handle this
Looking eagerly for some help/advice from you folks
Thanks a lot
Bharath
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Accelerated TCP/IP support from kernel

2001-05-24 Thread Bharath Madhavan

Hello all,
I am looking into a scenario where we have a NIC which performs 
all the TCP/IP processing and basically the core CPU offloads all data from
the socket level interface onwards to this NIC. 
Can Linux do this as of now. I saw some limited support like TCP/IP
checksumming
being done in HW (ex: 3c905c) and linux supports it. I also saw the
ZERO_COPY
feature in linux code. 
My question is can there be support for entire (almost) TCP/IP to be
offloaded 
to a NIC card. I noticed some NIC cards by Alacritec and Applicom who have 
such NICs but it looks like the support from Linux would be quite a bit of
work.
Basically Linux needs to support all socket calls as it will usually but
the socket interface must be intelligent enough to call different drivers(!)
for those NIC cards and thus bypassing the whole of TCP/IP stack of Linux.
Is this possible at all and if so, is anyone doing this???
I talked to a vendor who does this NIC and he said that they provide a
library
for linux which means that they have proprietery functions for using their
NIC
and thus this cannot be used in the standard socket interface way. That is a
big
limitation and not of much use. Basically, I am looking into a case where 
the kernel code needs to be changed to handle this
Looking eagerly for some help/advice from you folks
Thanks a lot
Bharath
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Speeding up VFS using HW assist

2001-05-22 Thread Bharath Madhavan

Hello All,
I will be using Linux as the OS for an embedded system.
I was looking into 2.4.4 kernel code and saw the dcache implementation
in VFS which is pretty neat and fast by itself.

My question is, will I gain any considerable efficiency in file system
access
if I can move this "pathname -> inode" lookup into some proprietery 
HW assist mechanism and take out the dcache hashing and "cached_lookup"
function.

How good(bad) was it before the dcache implementation and in which release
was dcache feature added (was it only after 2.2.x release). 
Did we get 2-3 times better performance with dcache? (if not, how much?)

Can anyone suggest any other place in the file system (VFS and EXT2) where
we
can use any HW assist (let us say FPGA implementing search, lookup, etc.)
to speed up file-system access (both for opening and read/write)

Would tweaking the buffer cache and page cache sizes make a considerable 
effect on efficiency?

Any other suggestions?

Thanks a lot,

Bharath
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/