Supporting Multicast in Network driver
Hi,
I would like to support MULTICAST in my network driver. I have define a
function set_multi which will extract the Ethernet multicast address and update
the corresponding hardware register. This function is called in the
SIOCADDMULTI and SIOCDELMULTI ioctl case.
I used following user level program to test the multicast functionality of
the driver. When I run the user level program, I could see that the control
comes to SIOCADDMULTI ioctl and the correct Ethernet Multicast Mac address is
added. After that when I try to ping the Multicast IP address from remote
machine, the ping is not responding. Do I need to do any thing extra apart from
update the Ethernet Multicast address?
User level program:
#include stdio.h
#include stdlib.h
#include string.h
#include arpa/inet.h
#include unistd.h
//#include net/if.h
#include netinet/in.h
//#include sys/types.h
#include sys/socket.h
int
main(int argc, char *argv[])
{
struct ip_mreq mreqn;
int s;
struct in_addr ip;
if (argc != 3) {
fprintf(stderr, usage: %s dev group\n, argv[0]);
exit(1);
}
if((s = socket(PF_INET, SOCK_DGRAM, 0)) 0) {
perror(socket);
exit(1);
}
memset(mreqn, 0, sizeof(mreqn));
inet_aton(argv[1], (mreqn.imr_interface));
/* mreqn.imr_interface = ip; */
if (inet_pton(AF_INET, argv[2], mreqn.imr_multiaddr) = 0) {
fprintf(stderr, %s: \%s\ invalid group address\n, argv[0],argv[2]);
exit(1);
}
if (setsockopt(s, 0, IP_ADD_MEMBERSHIP,mreqn,sizeof mreqn) 0) {
perror(IP_ADD_MEMBERSHIP);
exit(1);
}
printf(joined group %s on %s (pausing...)\n, argv[2], argv[1]);
fflush(stdout);
pause();
}
Thanks
-
Find out what India is talking about on Yahoo! Answers India.
Send FREE SMS from New Yahoo! Messenger to Mobile: Download NOW!
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCTP
Yann Berthier wrote: Hello, On Mon, 17 Jul 2006, at 07:54, Randall Stewart wrote: All: Just a friendly reminder/prod... if you have started testing SCTP.. thats great (any feedback?).. As said last time, i've been using sctp with netflow records between a router and a freebsd box - perhaps not the most useful test, but it's the only 'real life' test i found. if you have other ideas ... anyway, the only way to have more exposure is to have more sctp ready applications, and a good way to have it happen is to commit your patch, right :) Of course.. You can also find a patch for apache to use SCTP and a firebird version that can take advantage of it at: http://pel.cis.udel.edu/ R -- http://flowog.6f2.net/ - A NetFlow collecting house -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 or 815-342-5222 (cell) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCTP
Pawel: I see at least one thing wrong with the sctp_sendmsg() code... I just recently added the iov and the order of where bad:/ bad2:/ bad1: goes is wrong.. Now, the MAC stuff I have never enabled (at least I don't think so).. and I see that in this trace it seems the MAC stuff is calling to deallocate the socket directly... I am not sure if the crash is related to the wrong bad calls.. which would do a free() when it should not on the iov.. that can't be good.. but also not sure of the deallocate() stuff... The bad stuff is easy to fix.. and I will get a new patch prepared.. (I also will see if I can't update to current again.. and thus eliminate your syscall conflict).. But I want to look a bit into this mac_destroy_socket() path... R Pawel Worach wrote: On 7/17/06, Randall Stewart [EMAIL PROTECTED] wrote: All: Just a friendly reminder/prod... if you have started testing SCTP.. thats great (any feedback?).. and if you have not .. please do so :-D Hi, I played around a bit with NetPIPE, FreeBSD-CURRENT in one end and Linux 2.6.17 in the other over a gigabit crossover cable network, 1500 MTU. FreeBSD crashes after a while. I do have MAC enabled (no policy modules loaded at the time), it looks like it is involved. I think I can reproduce this, made it happen on both attempts. For the record, I modified the patch a bit to make it compile, the syscalls numbers collide with new threading syscalls added recently, so I moved the thr syscalls up a notch. And I removed this #ifdef MAC part of the patch due to duplicate sctp_bad labels. +#ifdef MAC +sctp_bad: +#endif + sctp_bad: + free(iov, M_IOV); Any more info I can provide ? ~/sctp/np ./NPsctp -h 192.168.10.1 ... 68: 16384 bytes 71 times --179.87 Mbps in 694.94 usec 69: 16387 bytes 71 times --178.78 Mbps in 699.33 usec 70: 24573 bytes 71 times --198.43 Mbps in 944.80 usec 71: 24576 bytes 70 times --199.18 Mbps in 941.35 usec 72: 24579 bytes 70 times --198.82 Mbps in 943.19 usec 73: 32765 bytes 35 times --210.05 Mbps in1190.07 usec 74: 32768 bytes 42 times --208.48 Mbps in1199.15 usec 75: 32771 bytes 41 times --208.00 Mbps in1202.03 usec 76: 49149 bytes 41 times --234.43 Mbps in1599.55 usec 77: 49152 bytes 41 times --300.20 Mbps in1249.17 usec 78: 49155 bytes 53 times --299.66 Mbps in1251.51 usec 79: 65533 bytes 26 times -- 4.77 Mbps in 104844.52 usec 80: 65536 bytes 3 times -- 3.70 Mbps in 135258.48 usec 81: 65539 bytes 3 times -- 3.70 Mbps in 135257.16 usec 82: 98301 bytes 3 times -- 7.36 Mbps in 101946.00 usec 83: 98304 bytes 3 times -- 7.36 Mbps in 101923.51 usec 84: 98307 bytes 3 times -- 7.36 Mbps in 101945.48 usec 85: 131069 bytes 3 times -- [stalls here] then a couple of seconds later... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc06a7e16 stack pointer = 0x28:0xd35e5174 frame pointer = 0x28:0xd35e5174 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: net) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(c078488a,c07e2500,c07790c0,d35e5028,100,...) at kdb_backtrace+0x2e panic(c07790c0,c079de93,c2466a70,1,1,...) at panic+0xb7 trap_fatal(d35e5134,0,2,8,e5df6f6e,...) at trap_fatal+0x342 trap_pfault(d35e5134,0,0,0,0,...) at trap_pfault+0x245 trap(8,0028,7fff0028,c104db80,0,...) at trap+0x3e3 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc06a7e16, esp = 0xd35e5174, ebp = 0xd35e5174 --- mac_labelzone_dtor(0,14,0,0,0,...) at mac_labelzone_dtor+0x6 uma_zfree_arg(c104db80,0,0,d35e51d0,c06acfc4,...) at uma_zfree_arg+0x2f mac_labelzone_free(0) at mac_labelzone_free+0x22 mac_socket_label_free(0,c2ad4000,d35e5200,c0587da8,c2ad4000,...) at mac_socket_label_free+0x94 mac_destroy_socket(c2ad4000,40,0,c2ad4000,4,...) at mac_destroy_socket+0x18 sodealloc(c2ad4000,c2ad4000,0,0,4,...) at sodealloc+0x168 sofree(c2ad4000,0,0,0,c10372c8,...) at sofree+0x311 sctp_inpcb_free(c2c98000,0,0,d35e52b4,c060c90d,...) at sctp_inpcb_free+0x10d6 sctp_free_assoc(c2c98000,c2cad958,0,c2cafcd0,d35e534c,...) at sctp_free_assoc+0x1a5b sctp_handle_shutdown_complete(c2cf3830,c2cad958,c2cafcd0,d35e534c,c0754bbe,...) at sctp_handle_shutdown_complete+0x228 sctp_process_control(c2cea500,14,d35e5bb8,24,c2cf3824,...) at sctp_process_control+0x1388 sctp_common_input_processing(d35e5c30,14,20,24,c2cf3824,...) at sctp_common_input_processing+0x87 sctp_input(c2cea500,14,c255c800,1,0,...) at sctp_input+0x383 ip_input(c2cea500,d35e5c88,c0553c65,8,0,...) at ip_input+0x70c
Testing of Multicast support on fxp and bge driver.
Hi all,
I was trying to test the Multicast support of bge and fxp driver using the
following user level program.
#include stdio.h
#include stdlib.h
#include string.h
#include arpa/inet.h
#include unistd.h
//#include net/if.h
#include netinet/in.h
//#include sys/types.h
#include sys/socket.h
int
main(int argc, char *argv[])
{
struct ip_mreq mreqn;
int s;
struct in_addr ip;
if (argc != 3) {
fprintf(stderr, usage: %s dev group\n, argv[0]);
exit(1);
}
if((s = socket(PF_INET, SOCK_DGRAM, 0)) 0) {
perror(socket);
exit(1);
}
memset(mreqn, 0, sizeof(mreqn));
inet_aton(argv[1], (mreqn.imr_interface));
/* mreqn.imr_interface = ip; */
if (inet_pton(AF_INET, argv[2], mreqn.imr_multiaddr) = 0) {
fprintf(stderr, %s: \%s\ invalid group address\n, argv[0],argv[2]);
exit(1);
}
if (setsockopt(s, 0, IP_ADD_MEMBERSHIP,mreqn,sizeof mreqn) 0) {
perror(IP_ADD_MEMBERSHIP);
exit(1);
}
printf(joined group %s on %s (pausing...)\n, argv[2], argv[1]);
fflush(stdout);
pause();
}
On test machine:
[EMAIL PROTECTED] ./a.out bge0 224.1.1.37
joined group 224.1.1.37 on bge0 (pausing...)
On remote machine:
-bash-3.00# ping -i xge2 224.1.1.37
no answer from 224.1.1.37
The ping is failing. I tried the same test on fxp (intel interface) also. The
ping to the multicast IP is not working. am I doing the correct steps? Do I
need to check any firewall setting that prevent the multicast packets??
Please advice, if I miss something in the testing.
Thanks,
-
Find out what India is talking about on Yahoo! Answers India.
Send FREE SMS from New Yahoo! Messenger to Mobile: Download NOW!
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Testing of Multicast support on fxp and bge driver.
try sysctl net.inet.icmp.bmcastecho=1
Baldur
On Wed, Jul 19, 2006 at 02:39:36PM +0100, freebsd nettest wrote:
Hi all,
I was trying to test the Multicast support of bge and fxp driver using the
following user level program.
#include stdio.h
#include stdlib.h
#include string.h
#include arpa/inet.h
#include unistd.h
//#include net/if.h
#include netinet/in.h
//#include sys/types.h
#include sys/socket.h
int
main(int argc, char *argv[])
{
struct ip_mreq mreqn;
int s;
struct in_addr ip;
if (argc != 3) {
fprintf(stderr, usage: %s dev group\n, argv[0]);
exit(1);
}
if((s = socket(PF_INET, SOCK_DGRAM, 0)) 0) {
perror(socket);
exit(1);
}
memset(mreqn, 0, sizeof(mreqn));
inet_aton(argv[1], (mreqn.imr_interface));
/* mreqn.imr_interface = ip; */
if (inet_pton(AF_INET, argv[2], mreqn.imr_multiaddr) = 0) {
fprintf(stderr, %s: \%s\ invalid group address\n, argv[0],argv[2]);
exit(1);
}
if (setsockopt(s, 0, IP_ADD_MEMBERSHIP,mreqn,sizeof mreqn) 0) {
perror(IP_ADD_MEMBERSHIP);
exit(1);
}
printf(joined group %s on %s (pausing...)\n, argv[2], argv[1]);
fflush(stdout);
pause();
}
On test machine:
[EMAIL PROTECTED] ./a.out bge0 224.1.1.37
joined group 224.1.1.37 on bge0 (pausing...)
On remote machine:
-bash-3.00# ping -i xge2 224.1.1.37
no answer from 224.1.1.37
The ping is failing. I tried the same test on fxp (intel interface) also.
The ping to the multicast IP is not working. am I doing the correct steps? Do
I need to check any firewall setting that prevent the multicast packets??
Please advice, if I miss something in the testing.
Thanks,
-
Find out what India is talking about on Yahoo! Answers India.
Send FREE SMS from New Yahoo! Messenger to Mobile: Download NOW!
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCTP
Pawel:
Ok, I have verified that even with my patch I can
recreate this one.. have not tried the mac one yet
(I will fix this first :-D)
I do think its an SCTP problem.. it looks to me
like an accounting issue... sb_cc or sb_mbcnt is
left with a value (at a guess) when we never use
the sb_mb pointers... so it panics..
In theory sb_cc and sb_mbcnt should be zero at
cleanup.. so some where a bug crept in from
the last time I played with netpipe :-0
Should have a patch later today hopefully.. of course
I am now trying to get kgdb to build.. I have not
done a buildworld in a while and of course there
have been changes and the old kgdb will not read
the core.. some nice error... sigh... I hate
to go down the build-world rat-hole.. at least
after the last time I did this it took me a long
time to recover... but I will jump in with both
feet :-D
R
Pawel Worach wrote:
On 7/18/06, Pawel Worach [EMAIL PROTECTED] wrote:
On 7/17/06, Randall Stewart [EMAIL PROTECTED] wrote:
All:
Just a friendly reminder/prod... if you have started
testing SCTP.. thats great (any feedback?)..
and if you have not .. please do so :-D
Hi,
I played around a bit with NetPIPE, FreeBSD-CURRENT in one end and
Linux 2.6.17 in the other over a gigabit crossover cable network, 1500
MTU. FreeBSD crashes after a while. I do have MAC enabled (no policy
modules loaded at the time), it looks like it is involved. I think I
can reproduce this, made it happen on both attempts.
And I removed MAC and I get another panic. No idea if directly related
to SCTP.
panic: sbdrop
KDB: stack backtrace:
kdb_backtrace(c0761224,c07bd400,c07649ee,d5b14a10,100,...) at
kdb_backtrace+0x2e
panic(c07649ee,c2b42d24,0,0,0,...) at panic+0xb7
sbdrop_locked(c2aaf9d0,10c19,0,c05250f9,c2aaf9d0,...) at sbdrop_locked+0x46
sbflush_locked(c2aaf9d0,c2b42b70,0,0,3041,...) at sbflush_locked+0x54
sbrelease_locked(c2aaf9d0,c2aaf914,d5b14a88,c05eb388,c2b42b70,...) at
sbrelease_locked+0x12
sofree(c2aaf914,d5b14ae4,4,d5b14ab4,c073ce8c,...) at sofree+0x2a3
soclose(c2aaf914,d5b14b24,0,d5b14ae0,c059d652,...) at soclose+0x3ff
soo_close(c27305a0,c275bbd0,d5b14af8,c05a9798,c27305a0,...) at
soo_close+0x7d
fdrop_locked(c27305a0,c275bbd0,c0722f76,d5b14be0,4) at fdrop_locked+0xf0
fdrop(c27305a0,c275bbd0,c2720924,0,c275bbd0,d5b14be0,0,0,0,c06d1e2b,c2720924,c2b41374,c175b040,d5b14b68,c06e2c12,4,c29b7514,28111000,d5b14c5c,c06d39f2,d5b14be0,80,c2b41374,5,0)
at fdrop+0x5f
closef(c27305a0,c275bbd0,c25c4a00,d5b14c64,0,...) at closef+0x542
fdfree(c275bbd0,c078e240,2,c053e2e6,c275bbd0,...) at fdfree+0x756
exit1(c275bbd0,19100,d5b14d30,c0727af3,c275bbd0,...) at exit1+0x660
sys_exit(c275bbd0,d5b14d04,4,c275bbd0,d5b14d30,...) at sys_exit+0x1d
syscall(bfbf003b,82b003b,bfbc003b,bfbfe910,82c4000,...) at syscall+0x3d3
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280e87ef, esp =
0xbfbc002c, ebp = 0xbfbc0038 ---
Uptime: 10m15s
Physical memory: 502 MB
Dumping 84 MB: 69 53 37 21 5
#0 doadump () at pcpu.h:166
166 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:166
#1 0xc0535b44 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc0535ebd in panic (fmt=0xc07649ee sbdrop)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc05876b6 in sbdrop_locked (sb=0xc2aaf9d0, len=68633)
at /usr/src/sys/kern/uipc_socket2.c:1002
#4 0xc0587574 in sbflush_locked (sb=0xc2aaf9d0)
at /usr/src/sys/kern/uipc_socket2.c:969
#5 0xc0586952 in sbrelease_locked (sb=0xc2aaf9d0, so=0x0)
at /usr/src/sys/kern/uipc_socket2.c:469
#6 0xc0581603 in sofree (so=0xc2aaf914) at
/usr/src/sys/kern/uipc_socket.c:587
#7 0xc0581a8f in soclose (so=0xc2aaf914)
at /usr/src/sys/kern/uipc_socket.c:662
#8 0xc056b9bd in soo_close (fp=0xc27305a0, td=0xc275bbd0)
at /usr/src/sys/kern/sys_socket.c:317
#9 0xc050be00 in fdrop_locked (fp=0xc27305a0, td=0x0) at file.h:296
#10 0xc050bcff in fdrop (fp=0xc27305a0, td=0x0)
at /usr/src/sys/kern/kern_descrip.c:2156
#11 0xc0509b42 in closef (fp=0xc27305a0, td=0xc275bbd0)
at /usr/src/sys/kern/kern_descrip.c:1971
#12 0xc0508396 in fdfree (td=0xc275bbd0)
at /usr/src/sys/kern/kern_descrip.c:1653
#13 0xc0514620 in exit1 (td=0xc275bbd0, rv=102656)
---Type return to continue, or q return to quit---
at /usr/src/sys/kern/kern_exit.c:280
#14 0xc0513fbd in sys_exit (td=0x0, uap=0x0)
at /usr/src/sys/kern/kern_exit.c:101
#15 0xc0727af3 in syscall (frame=
{tf_fs = -1078001605, tf_es = 137035835, tf_ds = -1078198213,
tf_edi = -1077942000, tf_esi = 137117696, tf_ebp = -1078198216, tf_isp
= -709800604, tf_ebx = 672598776, tf_edx = 0, tf_ecx = 3, tf_eax = 1,
tf_trapno = 12, tf_err = 2, tf_eip = 672040943, tf_cs = 51, tf_eflags
= 646, tf_esp = -1078198228, tf_ss = 59}) at
/usr/src/sys/i386/i386/trap.c:1015
#16 0xc071613f in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:191
#17 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) f 3
#3
RE: Broadcom 5780
Pavol, The 5780 is functionally equivalent to the 5714. Support for the 5780 was added to -CURRENT on June 29, 2006 in version 1.135 of if_bge.c. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pavol Cierny Sent: Wednesday, July 19, 2006 7:17 AM To: freebsd-net@freebsd.org Subject: Broadcom 5780 Hello, has anyone information about implementing Broadcom 5780 to the bge driver? Just bought a Fujitsu-Siemens RX220 server, and the NICs don't work :( --- Best regards Pavol Čierny ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broadcom 5780
Thanks for the info. Any chances it get's into STABLE in a near term? Could I use the driver code and compile it in STABLE? :) --- S pozdravom Pavol Čierny Pavol, The 5780 is functionally equivalent to the 5714. Support for the 5780 was added to -CURRENT on June 29, 2006 in version 1.135 of if_bge.c. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pavol Cierny Sent: Wednesday, July 19, 2006 7:17 AM To: freebsd-net@freebsd.org Subject: Broadcom 5780 Hello, has anyone information about implementing Broadcom 5780 to the bge driver? Just bought a Fujitsu-Siemens RX220 server, and the NICs don't work :( --- Best regards Pavol Čierny ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Broadcom 5780
I don't maintain that driver so I don't know the answer to that. Dave -Original Message- From: Pavol Čierny [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 19, 2006 11:43 AM To: David (Controller AE) Christensen Cc: freebsd-net@freebsd.org Subject: Re: Broadcom 5780 Thanks for the info. Any chances it get's into STABLE in a near term? Could I use the driver code and compile it in STABLE? :) --- S pozdravom Pavol Čierny Pavol, The 5780 is functionally equivalent to the 5714. Support for the 5780 was added to -CURRENT on June 29, 2006 in version 1.135 of if_bge.c. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pavol Cierny Sent: Wednesday, July 19, 2006 7:17 AM To: freebsd-net@freebsd.org Subject: Broadcom 5780 Hello, has anyone information about implementing Broadcom 5780 to the bge driver? Just bought a Fujitsu-Siemens RX220 server, and the NICs don't work :( --- Best regards Pavol Čierny ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCTP
Pawel/All: You will now find a new patch available either by clicking: http://www.sctp.org/cvs_diff.July19.bz2 Or you can find it at http://www.sctp.org/ Hanging off the download page has patch-2. This is current to this evening's CVS and fixes the issues Pawel saw.. I still don't like the performance on my SMP machine and think there may be some locking contentions going on.. I will try to look into this tommorrow :-0 R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 or 815-342-5222 (cell) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
complement to sendfile()?
Hello! My program receives data from the socket and writes it to a file -- with the usual read()/write() tedium. Is there anything zero-copying like sendfile() for the socket-file direction? In fact, sendfile's API may allow to use it in any direction, but the manual is quite explicit, that the second (destination) argument must be socket. recvfile()? Thanks! -mi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: complement to sendfile()?
Hello! My program receives data from the socket and writes it to a file -- with the usual read()/write() tedium. Is there anything zero-copying like sendfile() for the socket-file direction? In fact, sendfile's API may allow to use it in any direction, but the manual is quite explicit, that the second (destination) argument must be socket. recvfile()? Thanks! sendfile() could be extended to allow arbitrary file descriptor types as the source and destination, but the zero-copy nature of it can only work in the file to socket direction. This is because network buffers can be made out of filesystem buffers (file-network direction), but for the network to file direction network packets arrive non-deterministically. With the right network hardware it would in theory be possible to have the TCP code run on the network card and it could DMA the TCP stream directly into file buffers. If pigs had wings, they could fly. :-) -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: complement to sendfile()?
середа 19 липень 2006 22:50, David G. Lawrence написав: sendfile() could be extended to allow arbitrary file descriptor types as the source and destination, but the zero-copy nature of it can only work in the file to socket direction. This is because network buffers can be made out of filesystem buffers (file-network direction), but for the network to file direction network packets arrive non-deterministically. With the right network hardware it would in theory be possible to have the TCP code run on the network card and it could DMA the TCP stream directly into file buffers. If pigs had wings, they could fly. :-) Ok, so zero-copy may not work, but one-copy would still be better, than the usual two-copy. Am I right? With the usual read/write method, data is read from the network card to kernel's buffers, from there to the application buffer, and from there to the filesystem. That's two copies, no? Having mmap-ed the output file, I could read from the socket directly into the mmap-returned buffer, but writing via. mmap appears to be implemented pessimally in FreeBSD and breaks horrendously if the output file happens to be accessed via NFS. Thanks! -mi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: complement to sendfile()?
?? 19 ?? 2006 22:50, David G. Lawrence ???: ? ?sendfile() could be extended to allow arbitrary file descriptor types as the source and destination, but the zero-copy nature of it can only work in the file to socket direction. This is because network buffers can be made out of filesystem buffers (file-network direction), but for the network to file direction network packets arrive non-deterministically. With the right network hardware it would in theory be possible to have the TCP code run on the network card and it could DMA the TCP stream directly into file buffers. If pigs had wings, they could fly. :-) Ok, so zero-copy may not work, but one-copy would still be better, than the usual two-copy. Am I right? With the usual read/write method, data is read from the network card to kernel's buffers, from there to the application buffer, and from there to the filesystem. That's two copies, no? Yes, you are right. A few other cool things that could be done with sendfile include: o Full duplex zero-copy socket to socket sends. This could be used on (e.g Squid) proxy servers, for example, to connect two (inside/outside) TCP streams. Plus an ASYNC flag to make it all happen in the background inside the kernel (returning immediately to the proxy application). o An APPEND flag that allows sendfile to block at the end of file, waiting for more data to be written to it (as long as someone has the file open for append). This would be very useful in some real-time audio/video streaming applications (like the one I'm working on right now :-)). -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
