netnice-kernels Mailing List for netnice
Status: Alpha
Brought to you by:
taost6
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(4) |
Sep
(10) |
Oct
(34) |
Nov
(25) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(15) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(1) |
2006 |
Jan
(1) |
Feb
(11) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: abcd e. <kar...@ho...> - 2011-03-20 17:34:00
|
http://super-trotteurs.fr/asl3.html |
From: kartikey b. <kar...@ho...> - 2011-03-11 11:27:50
|
http://holidayvillasrental.com/asf6.html |
From: kartikey b. <kar...@ho...> - 2011-03-10 06:56:57
|
http://manuel-linares.com/asf3.html |
From: kartikey b. <kar...@ho...> - 2011-03-04 04:40:15
|
http://rioual.com/sol5.html |
From: kartikey b. <kar...@ho...> - 2011-03-03 16:41:52
|
http://ecfcomunicacion.com/sol5.html |
From: kartikey b. <kar...@ho...> - 2011-03-03 07:11:46
|
http://bergerhollandais.fr/sol3.html |
From: kartikey b. <kar...@ho...> - 2011-03-02 15:59:06
|
http://trancosohf.com.br/sol2.html |
From: kartikey b. <kar...@ho...> - 2011-02-26 08:08:25
|
http://hr-rohlfing.de/bmi3.html |
From: kartikey b. <kar...@ho...> - 2011-02-25 23:57:24
|
http://grupsofos.com/bmi2.html |
From: Takashi O. <ta...@wi...> - 2006-05-05 06:24:24
|
Dear netnice users/hackers, As I have announced, I have been planning to host a hacking camp in Pittsburgh this summer. However, because of several difficulties, I have decided to postpone the camp until next March. Accordingly, the release of Netnice-2.2 will be delayed as much... Although we cannot have direct contact, however, interested developers may independently work on the tasks undone. Such tasks are summarized in our project website, and I would really appreciate if you share the burden to make the system better. Even if you are not a kernel hacker, there are a lot of tasks :-) Specifically, I would appreciate if some of you take a look at nndiag script. It does not generate stable output between runs. Any other offers are welcome. Just write to the related liets, since personal messages may cause task conflict. http://www.netnice.org/pukiwiki.php?Netnice2.2 thanks!!! -- taka Takashi Okumura wrote: > > Dear netnice users/hackers, > > In early may, I'm planning to host a hacking camp in Pittsburgh, to > intensively collaborate with netnice users/developers toward the > release of netnice-2.2. > > You will need to pay just for your roundtrip flights, and I will > arrange a bed and working environment for you. I am planning to > work on Knoppix remastering for Knoppix/Netnice integration and > libnetnice implementation. But, you may pick up any subproject > of your choice. Several suggestions are listed in our website, > such as mod_netnice (traffic management/access control module for > Apache). I will arrange things to help you finish the task you > choose. > > I believe that this will be a good opportunity for students who > want to be (kernel) hackers. Even if you do not have time to join > the camp, you may join a dinner (on May 6, maybe?). > > If interested, please let me know, so that we can coordinate. > Questions and/or suggestions are also highly appreciated to make > the plan better. > > thanks! > > -- ta...@ne... > >>> btw, i'm planning to come back to pittsburgh for a while to work on my >>> dissertation in this early summer. and, during the stay, i may host a >>> netnice workshop (R&D camp) to finish several tasks, such as libnetnice, >>> Knoppix/Netnice, mod_netnice for Apache. >>> >>> although i cannot pay you, i'll sponsor good accommodation and working >>> environment (bed, desk, WiFi connection, printer, etc). i guess that >>> will be a good opportunity for students who want to be kernel hackers. >>> the term will be just after Spring finals of most U.S. students (early >>> may?) >>> >>> i'll suggest you about more concrete plan later, when i fix my travel >>> schedule. but, if you're interested at this point, please let me know, >>> so that i can have better plan. or, if any of you have a good place >>> (house, maybe?) and can host the workshop inside the U.S., please let >>> me know. >>> >>> >>> thanks! > > |
From: Takashi O. <ta...@cs...> - 2006-04-27 05:21:53
|
Dear netnice kernel developers, As you might have realized by the commit log, I found several bugs in FreeBSD4/5 Netnice. Fortunately, they are minor ones, and do not make big difference to most users... And, I will write to the related lists, regarding Netnice-2.2 release and the hacking camp, shortly. thanks, -- taka@pittsburgh - nnfs_netnice.c:nnfs_donetnice() use of nnfs_getuserstr at "case Pvif_filter" of nnfs_donetnice() is inapropriate, because it is for string data. It requires larger buffer size (+1) for string termination, and also modifies the data content. Accordingly, we need to use another function nnfs_getuserdt(), which is added in nnfs_subr.c. - nnfs_vnops.c:nnfs_getattr() in the calculation of vap->va_nlink at "case Pvif_dir", a nvif_target, which is not actually used, is also counted. we need to properly subtract the number of entries not used. - nnfs_vnops.c:nnfs_readdir.c() same as above. the number of entries is not appropriate. similarly to the vap->va_nlink calculation above, we need to appropriately count the number of the entries, and need to skip the extra entries. otherwise, it would use another entry at the end of the list multiple times. - vif_input.c:vif_enqueue() of FreeBSD 4.11 a closing bracket is missing... (L.723) EoF |
From: Takashi O. <ta...@wi...> - 2006-04-03 13:05:00
|
Hi Matt, okay. never mind :-) it is just a voluntary project anyway, and please contribute things that you can contribute. (or, you may join just the dinner, if your schedule and budget permit...) thanks!! -- taka On 4/3/06, Matt Davis <mat...@gm...> wrote: > Taka I am very interested. But I have been doing some independent study > work at school and I need to begin wrapping that up. I would like to > devote more to netnice, which I know I haven't done much recently, but > Iv had some local side project stuff that I have been committing some > time to. While I see this as a fantastic opportunity, I cannot make any > commitments right now. I do appreciate the offer, and I am sure you have > intrigued many of the other devs. I still would like to perform more > kernel contributions, which I have yet to truly do for this project. > > Thanks > > -Matt > > Takashi Okumura wrote: > > Dear netnice users/hackers, > > > > In early may, I'm planning to host a hacking camp in Pittsburgh, to > > intensively collaborate with netnice users/developers toward the > > release of netnice-2.2. > > > > You will need to pay just for your roundtrip flights, and I will > > arrange a bed and working environment for you. I am planning to > > work on Knoppix remastering for Knoppix/Netnice integration and > > libnetnice implementation. But, you may pick up any subproject > > of your choice. Several suggestions are listed in our website, > > such as mod_netnice (traffic management/access control module for > > Apache). I will arrange things to help you finish the task you > > choose. > > > > I believe that this will be a good opportunity for students who > > want to be (kernel) hackers. Even if you do not have time to join > > the camp, you may join a dinner (on May 6, maybe?). > > > > If interested, please let me know, so that we can coordinate. > > Questions and/or suggestions are also highly appreciated to make > > the plan better. > > > > thanks! > > > > -- ta...@ne... > > > >>> btw, i'm planning to come back to pittsburgh for a while to work on m= y > >>> dissertation in this early summer. and, during the stay, i may host a > >>> netnice workshop (R&D camp) to finish several tasks, such as libnetni= ce, > >>> Knoppix/Netnice, mod_netnice for Apache. > >>> > >>> although i cannot pay you, i'll sponsor good accommodation and workin= g > >>> environment (bed, desk, WiFi connection, printer, etc). i guess that > >>> will be a good opportunity for students who want to be kernel hackers= . > >>> the term will be just after Spring finals of most U.S. students (earl= y > >>> may?) > >>> > >>> i'll suggest you about more concrete plan later, when i fix my travel > >>> schedule. but, if you're interested at this point, please let me know= , > >>> so that i can have better plan. or, if any of you have a good place > >>> (house, maybe?) and can host the workshop inside the U.S., please let > >>> me know. > >>> > >>> > >>> thanks! > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > > that extends applications into web and mobile media. Attend the live we= bcast > > and join the prime developer group breaking into this new coding territ= ory! > > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 > > _______________________________________________ > > Netnice-kernels mailing list > > Net...@li... > > https://lists.sourceforge.net/lists/listinfo/netnice-kernels > > > > |
From: Matt D. <mat...@gm...> - 2006-04-02 16:34:11
|
Taka I am very interested. But I have been doing some independent study work at school and I need to begin wrapping that up. I would like to devote more to netnice, which I know I haven't done much recently, but Iv had some local side project stuff that I have been committing some time to. While I see this as a fantastic opportunity, I cannot make any commitments right now. I do appreciate the offer, and I am sure you have intrigued many of the other devs. I still would like to perform more kernel contributions, which I have yet to truly do for this project. Thanks -Matt Takashi Okumura wrote: > Dear netnice users/hackers, > > In early may, I'm planning to host a hacking camp in Pittsburgh, to > intensively collaborate with netnice users/developers toward the > release of netnice-2.2. > > You will need to pay just for your roundtrip flights, and I will > arrange a bed and working environment for you. I am planning to > work on Knoppix remastering for Knoppix/Netnice integration and > libnetnice implementation. But, you may pick up any subproject > of your choice. Several suggestions are listed in our website, > such as mod_netnice (traffic management/access control module for > Apache). I will arrange things to help you finish the task you > choose. > > I believe that this will be a good opportunity for students who > want to be (kernel) hackers. Even if you do not have time to join > the camp, you may join a dinner (on May 6, maybe?). > > If interested, please let me know, so that we can coordinate. > Questions and/or suggestions are also highly appreciated to make > the plan better. > > thanks! > > -- ta...@ne... > >>> btw, i'm planning to come back to pittsburgh for a while to work on my >>> dissertation in this early summer. and, during the stay, i may host a >>> netnice workshop (R&D camp) to finish several tasks, such as libnetnice, >>> Knoppix/Netnice, mod_netnice for Apache. >>> >>> although i cannot pay you, i'll sponsor good accommodation and working >>> environment (bed, desk, WiFi connection, printer, etc). i guess that >>> will be a good opportunity for students who want to be kernel hackers. >>> the term will be just after Spring finals of most U.S. students (early >>> may?) >>> >>> i'll suggest you about more concrete plan later, when i fix my travel >>> schedule. but, if you're interested at this point, please let me know, >>> so that i can have better plan. or, if any of you have a good place >>> (house, maybe?) and can host the workshop inside the U.S., please let >>> me know. >>> >>> >>> thanks! > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 > _______________________________________________ > Netnice-kernels mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netnice-kernels > |
From: Takashi O. <ta...@wi...> - 2006-04-02 01:59:31
|
Dear netnice users/hackers, In early may, I'm planning to host a hacking camp in Pittsburgh, to intensively collaborate with netnice users/developers toward the release of netnice-2.2. You will need to pay just for your roundtrip flights, and I will arrange a bed and working environment for you. I am planning to work on Knoppix remastering for Knoppix/Netnice integration and libnetnice implementation. But, you may pick up any subproject of your choice. Several suggestions are listed in our website, such as mod_netnice (traffic management/access control module for Apache). I will arrange things to help you finish the task you choose. I believe that this will be a good opportunity for students who want to be (kernel) hackers. Even if you do not have time to join the camp, you may join a dinner (on May 6, maybe?). If interested, please let me know, so that we can coordinate. Questions and/or suggestions are also highly appreciated to make the plan better. thanks! -- ta...@ne... >> btw, i'm planning to come back to pittsburgh for a while to work on my >> dissertation in this early summer. and, during the stay, i may host a >> netnice workshop (R&D camp) to finish several tasks, such as libnetnice, >> Knoppix/Netnice, mod_netnice for Apache. >> >> although i cannot pay you, i'll sponsor good accommodation and working >> environment (bed, desk, WiFi connection, printer, etc). i guess that >> will be a good opportunity for students who want to be kernel hackers. >> the term will be just after Spring finals of most U.S. students (early >> may?) >> >> i'll suggest you about more concrete plan later, when i fix my travel >> schedule. but, if you're interested at this point, please let me know, >> so that i can have better plan. or, if any of you have a good place >> (house, maybe?) and can host the workshop inside the U.S., please let >> me know. >> >> >> thanks! |
From: Takashi O. <ta...@wi...> - 2006-02-28 15:28:55
|
sorry for the slow reply. kartikey bhatt wrote: > >> i don't think i understand everything about your suggestion. but, this >> sounds like adding a "stack-like" structure in the association >> management, >> where we can easily recover former associations in an organized manner at >> any given time. > >> several questoins: >> >> - are you linking this idea with the one-process one-vif policy, you >> suggested? if so, it confuses me, and i need more explanation. > > its not one-process one-vif policy but one-process and only one > association to the vif that connects the process to the real interface. > i mean a process cannot have association to two different vifs that has > the same reall interface. i'm confused. first, i would suggest you to start from examples, where the original design is not appropriate, and where the suggested design works better. second, you are now discussing a policy issue, although what you submitted us is description of suggested change in the implementation, when i asked you to give us a figure of the overview. anyway. stretching my imagination, i guess you are protesting against VIF configuration like this (see attached figure). is that true? >> - although the stack-like management of VIF-process/socket association >> looks interesting, i don't understand why you came up with the idea. >> can you suggest several situations where this approach is useful? >> when we delete a VIF-process association, we did because we want to >> delete the association, prohibiting the process from using the >> interface (right?). even on your scheme, we can delete the association >> when we delete the first one. but, this obviously violates semantics >> of "rm" (remove, or unlink) operation on NNFS (any justification?). >> also, we can revert to the default (original) association, just by >> copying the association of the parent process. any comment on the >> issue? > > i think when we delete the VIF-process association, we do it because we > want to prohibit the process from using the VIF not the "interface". i feel there is a misinterpretation, here. for the process we control, an attached VIF behaves like the interface to which the process inject packets. (though i may change the interpretation, if you can convince me) > we can't revert to the default association just by copying the > association of the parent process, because in the mean time parent > process might have created new associations. sounds interesting. there are two possible cases; - process A (parent) forks, creates a VIF, and attaches itself to the VIF. in this case, when the child tries to revert to the default VIF by copying its parent configuration, the association would point to a descendant VIF of the original VIF for the child . - process B (parent) creates a VIF, attaches itself to the VIF, forks, and reconnect it back to the original VIF in this case, the association would point to an ancestor. i feel that both cases would do no harm. rather, your "memory" feature would be a bit harmful, because the memory would keep a pointer to a deleted VIF. to prohibit this, we'll need to traverse all the links, introduced for the feature, and need to implement the parental-copy strategy. but, i may agree with you to keep one pointer (not a list for pointers) to the original VIF, so that we can prohibit a process from connecting itself to ancestors (of course, the pointer should be deleted, when we rmdir() the original VIF). we can also keep one int, keeping the original bandwidth specification. > the most annoying part of the netnice is shared vifs among the parent > and the child process. i mean when a child process modifies the vif > attributes like bandwidth and type of the vif, it gets reflected in the > parent process. which really shouldn't be allowed. i understand the point. but, i think this is the copy-on-write strategy you first suggested. because every child is allowed to create its own VIF, they should create its own VIF when they need a dedicated control. for the parent process, if they do not want to be affected by its child processes, it can simply create a "sandbox" VIF. thanks! -- taka |
From: kartikey b. <kar...@ho...> - 2006-02-26 09:15:14
|
hi, taka wrote: >this statement is understandable. yes, we may adopt the copy-on-write >strategy, and if you prefer the approach, you may change the algorithm, >as long as it is compatible with *BSD. however, the memory waste and the >copy overhead you mentioned are negligible on most machines nowadays, and >very few applications create and delete sockets intensively. so, it sounds >like adding extra complexity in the code for very small gain. i agree. >i don't think i understand everything about your suggestion. but, this >sounds like adding a "stack-like" structure in the association management, >where we can easily recover former associations in an organized manner at >any given time. >several questoins: > > - are you linking this idea with the one-process one-vif policy, you > suggested? if so, it confuses me, and i need more explanation. its not one-process one-vif policy but one-process and only one association to the vif that connects the process to the real interface. i mean a process cannot have association to two different vifs that has the same reall interface. > - pvifnet is a link of VIFs associated with a terminating entity, such > as a process, and a socket. i believe the structure is needed to > properly handle multiple network interfaces, but, in the above > description of the algorithm, it shows only one pvifnet. is it > just for explanation purpose? or, are you proposing "one-process > one-pvifnet one-vif" model? (i hope not!) exactly not. pvifnet is a list of all the vifs association of the process. > - although the stack-like management of VIF-process/socket association > looks interesting, i don't understand why you came up with the idea. > can you suggest several situations where this approach is useful? > when we delete a VIF-process association, we did because we want to > delete the association, prohibiting the process from using the > interface (right?). even on your scheme, we can delete the association > when we delete the first one. but, this obviously violates semantics > of "rm" (remove, or unlink) operation on NNFS (any justification?). > also, we can revert to the default (original) association, just by > copying the association of the parent process. any comment on the > issue? i think when we delete the VIF-process association, we do it because we want to prohibit the process from using the VIF not the "interface". we can't revert to the default association just by copying the association of the parent process, because in the mean time parent process might have created new ass ociations. >anyway. i really appreciate your suggestions, and i do not want to >interrupt your attempts simply because they are against my original >design. thanks a lot on positve feedback! the most annoying part of the netnice is shared vifs among the parent and the child process. i mean when a child process modifies the vif attributes like bandwidth and type of the vif, it gets reflected in the parent process. which really shouldn't be allowed. any suggestions for the same? thanks kartikey |
From: Takashi O. <ta...@wi...> - 2006-02-25 13:02:16
|
hi, kartikey bhatt wrote: > >> how can we control sockets, in the scheme? we may want to control >> independent connections, or, may want to prioritize some sockets >> (interactive ones) among others (bulk data transfer), in a process. >> >> one of our advantage is flexible control granularity with hierarchical >> resource management scheme, realized by the VIF structure. i cannot >> see any merit in your suggestion. what do you mean by the word, >> "consistent"? > > i'd like to make a few points. > > netnice command doesn't provide this support. it only allows you to > create vif and associated with the process. it doesn't allow fine gain > control over sockets. it's simply because the command is designed to control network I/O on per-process basis (from outside the programs being controlled). > how do you differentiate interactive sockets from bulk data transfer > sockets? application programmers should know which socket is used for what purpose. so, the applications can easily differentiate them (inside the programs being controlled). > for a process like apache creating several connections (sockets) , > creating a pvifnet data structure for each of them is a waste of kernel > memory. it also introduces overhead of creating and deleting pvifnet as > each connection is made and terminated. > > we can take an approach where each socket initially shares pvifnet data > structure associated with the process and create a new pvifnet data > structure only when it is required to control independent connection. this statement is understandable. yes, we may adopt the copy-on-write strategy, and if you prefer the approach, you may change the algorithm, as long as it is compatible with *BSD. however, the memory waste and the copy overhead you mentioned are negligible on most machines nowadays, and very few applications create and delete sockets intensively. so, it sounds like adding extra complexity in the code for very small gain. > >> > 2. I am enforcing that each process should have at least (and at most) >> > one vif associated with the real net_device (ifnet in FreeBSD >> > terminology). So a process cannot have more than "1" or less than "1" >> > vif associated with eth0 at any given time. Whenever a process creates a >> > vif, I am not allocating a new p_vifnet rather I am modifying the >> > p_vifnet that is already associated with the vif that connects process >> > to the real net_device (interface). When a process deletes the vif it >> > simply reverts the p_vifnet to the vif that was associated with it >> > before the creation of new vif. >> >> can you give us a simple figure, describing each scheme? > > i am not good at figure though i implement my scheme as follows. > > initially each process has one vif attached to real interface. > which is accessible through pvifnet->pipe and real interface is accessible through > pvif->pipe->dev. > i introduce a new variable prev_pipe in pvifnet data structure. when a process creates a new vif we find out the pvifnet data structure that connects process to the interface and simply update: > > pvifnet->prev_pipe = pvifnet->pipe; > pvifnet->pipe = new_vif: > > when a process wants to delete an association to the vif the operation becomes: > > pvifnet->pipe = pvifnet->prev_pipe; > > this way at any given time each process has at least one vif that associates it with thee real interface i don't think i understand everything about your suggestion. but, this sounds like adding a "stack-like" structure in the association management, where we can easily recover former associations in an organized manner at any given time. several questoins: - are you linking this idea with the one-process one-vif policy, you suggested? if so, it confuses me, and i need more explanation. - pvifnet is a link of VIFs associated with a terminating entity, such as a process, and a socket. i believe the structure is needed to properly handle multiple network interfaces, but, in the above description of the algorithm, it shows only one pvifnet. is it just for explanation purpose? or, are you proposing "one-process one-pvifnet one-vif" model? (i hope not!) - although the stack-like management of VIF-process/socket association looks interesting, i don't understand why you came up with the idea. can you suggest several situations where this approach is useful? when we delete a VIF-process association, we did because we want to delete the association, prohibiting the process from using the interface (right?). even on your scheme, we can delete the association when we delete the first one. but, this obviously violates semantics of "rm" (remove, or unlink) operation on NNFS (any justification?). also, we can revert to the default (original) association, just by copying the association of the parent process. any comment on the issue? anyway. i really appreciate your suggestions, and i do not want to interrupt your attempts simply because they are against my original design. thanks, -- taka |
From: kartikey b. <kar...@ho...> - 2006-02-24 09:17:50
|
hi, taka wrote: >how can we control sockets, in the scheme? we may want to control >independent connections, or, may want to prioritize some sockets >(interactive ones) among others (bulk data transfer), in a process. > >one of our advantage is flexible control granularity with hierarchical >resource management scheme, realized by the VIF structure. i cannot >see any merit in your suggestion. what do you mean by the word, >"consistent"? netnice command doesn't provide support for controlling individual sockets, it just allows control over the process. how do you differentiate interactive sockets from bulk data transfer sockets in a process. a process like apache or inetd which creates and terminates several connections , allocating and deallocating pvifnet data structure introduces overhead. rather my approach is that a socket shares the pvifnet data structure with the process and only when it is required to control individual socket we allocate the necessary resources. > > 2. I am enforcing that each process should have at least (and at most) > > one vif associated with the real net_device (ifnet in FreeBSD > > terminology). So a process cannot have more than "1" or less than "1" > > vif associated with eth0 at any given time. Whenever a process creates a > > vif, I am not allocating a new p_vifnet rather I am modifying the > > p_vifnet that is already associated with the vif that connects process > > to the real net_device (interface). When a process deletes the vif it > > simply reverts the p_vifnet to the vif that was associated with it > > before the creation of new vif. > >can you give us a simple figure, describing each scheme? i am not good at figure though i implement my scheme as follows. initially each process has one vif attached to real interface. which is accessible through pvifnet->pipe and real interface is accessible through pvif->pipe->dev. i introduce a new variable prev_pipe in pvifnet data structure. when a process creates a new vif we find out the pvifnet data structure that connects process to the interface and simply update: pvifnet->prev_pipe = pvifnet->pipe; pvifnet->pipe = new_vif: when a process wants to delete an association to the vif the operation becomes: pvifnet->pipe = pvifnet->prev_pipe; this way at any given time each process has at least one vif that associates it with thee real interface thanks --kartikey |
From: Takashi O. <ta...@wi...> - 2006-02-23 11:47:45
|
kartikey bhatt wrote: > > Before I commit my further patches I'd like to ask you a few questions > regarding netnice in particular and on linux. > > 1. Is it really necessary that we allow fine grain control over sockets > too? I mean whether each individual socket should have its own > association to vifs? What I am doing is rather than associating vifs to > each socket , i am associating the vif to process only and the so_vifnet > in socket is a pointer to the list of associated vifs of the process. > And this way the system is more consistent. how can we control sockets, in the scheme? we may want to control independent connections, or, may want to prioritize some sockets (interactive ones) among others (bulk data transfer), in a process. one of our advantage is flexible control granularity with hierarchical resource management scheme, realized by the VIF structure. i cannot see any merit in your suggestion. what do you mean by the word, "consistent"? > 2. I am enforcing that each process should have at least (and at most) > one vif associated with the real net_device (ifnet in FreeBSD > terminology). So a process cannot have more than "1" or less than "1" > vif associated with eth0 at any given time. Whenever a process creates a > vif, I am not allocating a new p_vifnet rather I am modifying the > p_vifnet that is already associated with the vif that connects process > to the real net_device (interface). When a process deletes the vif it > simply reverts the p_vifnet to the vif that was associated with it > before the creation of new vif. can you give us a simple figure, describing each scheme? you may use (modify) the following page, and upload a GIF file there, to save mail traffic. http://www.netnice.org/pukiwiki-e.php?kartikey%27s%20note thanks, -- taka |
From: kartikey b. <kar...@ho...> - 2006-02-23 10:46:59
|
hi taka, Before I commit my further patches I'd like to ask you a few questions regarding netnice in particular and on linux. 1. Is it really necessary that we allow fine grain control over sockets too? I mean whether each individual socket should have its own association to vifs? What I am doing is rather than associating vifs to each socket , i am associating the vif to process only and the so_vifnet in socket is a pointer to the list of associated vifs of the process. And this way the system is more consistent. 2. I am enforcing that each process should have at least (and at most) one vif associated with the real net_device (ifnet in FreeBSD terminology). So a process cannot have more than "1" or less than "1" vif associated with eth0 at any given time. Whenever a process creates a vif, I am not allocating a new p_vifnet rather I am modifying the p_vifnet that is already associated with the vif that connects process to the real net_device (interface). When a process deletes the vif it simply reverts the p_vifnet to the vif that was associated with it before the creation of new vif. I know that these two approaches are not consistent with the way netnice is implemented on FreeBSD. However, they give a consistent view of the vif system. Any feedback? thanks --kartikey |
From: Takashi O. <ta...@wi...> - 2006-02-20 14:29:37
|
hi, i clarified the Linux/NPF porting task, a bit more, for future reference. if you may help the porting, please take a look. http://www.netnice.org/pukiwiki-e.php?NPF-port btw, i'm planning to come back to pittsburgh for a while to work on my dissertation in this early summer. and, during the stay, i may host a netnice workshop (R&D camp) to finish several tasks, such as libnetnice, Knoppix/Netnice, mod_netnice for Apache. although i cannot pay you, i'll sponsor good accommodation and working environment (bed, desk, WiFi connection, printer, etc). i guess that will be a good opportunity for students who want to be kernel hackers. the term will be just after Spring finals of most U.S. students (early may?) i'll suggest you about more concrete plan later, when i fix my travel schedule. but, if you're interested at this point, please let me know, so that i can have better plan. or, if any of you have a good place (house, maybe?) and can host the workshop inside the U.S., please let me know. thanks! -- taka |
From: Takashi O. <ta...@wi...> - 2006-02-16 16:50:16
|
thanks kartikey, and welcome back. so, the new commit is to make netnice work with the latest linux kernel. right? i also want to make sure that > vif deletion and proper attachments of vif to processes and reference > counting for the vif this part refers to the bug i've been reporting. right? that will be really helpful. when you finish the debugging part (that won't be too hard), please notify us so that Matt can apply the changes you make to 2.6.12. please note that we need to keep the 2.6.12 branch updated, since Knoppix is currently 2.6.12-debian based. (and, when they migrate to the latest kernel, we'll follow them, relinquishing the branch. we may also merge your "linux-netnice" and "Linux" modules that time.) thanks! -- taka kartikey bhatt wrote: > hi all! > > i updated the patch to 2.6.15 kerenel tree. > the patch works fine and infact while commiting the code and writing this > mail i am using the 2.6.15-NETNICE kerenel with bandwidth limit for > cvs set to 64K and it works perfactly fine. the next thing i am planning to > do is nnfs cleanup and vif deletion and proper attachments of vif to > processes and reference counting for the vif. > > the patch should be in CVS by the time you are reading this mail. > > to get the 2.6.15 with netnice: > cvs co -r netnice2615a Linux > > check it out! > > > thanks all > --kartikey > > >> From: Takashi Okumura <ta...@wi...> >> To: Matt Davis <mat...@gm...> >> CC: >> net...@li...,net...@li... >> >> Subject: [Netnice-kernels] Re: [Netnice-developer] Linux 2.6.12 and >> Netnice >> Date: Tue, 14 Feb 2006 22:08:44 +0900 >> >> >> Thanks Matt, >> >> sounds like a good restart. we've got to first check the functionality, >> and i believe netnice-2.2/contrib/nndiag will help you. please feel free >> to fix any bug in the testing script :-) >> >> thanks! >> >> >> -- taka >> >> Matt Davis wrote: >> >>> Much thanks goes out to Scott, I applied his patch to 2.6.12 and the >>> kernel boots fine. Mounting the nnfs fs works seemingly error free >>> too. I have yet to do much testing with this but it looks smooth. >>> The kernel with the applied patch is now in CVS and you can give it a >>> shot: >>> "cvs co -r netnice2612b Linux" >>> >>> -Matt >>> >> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log >> files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >> _______________________________________________ >> Netnice-kernels mailing list >> Net...@li... >> https://lists.sourceforge.net/lists/listinfo/netnice-kernels > > > > |
From: kartikey b. <kar...@ho...> - 2006-02-16 13:31:50
|
hi all, sorry about mess up. i tried to update the repository with my patch but i din't succeed. finally i had to create a new environment for linux and uploaded my patch. "linux netnice" developers please make a note of the following. i imported linux kernel version 2.6.15 with vendor tag LINUX and release tag LINUX_2_6_15 as the main branch. the directory (or module) is linux-netnice. and then i create a development branch with the first patch as patch1. to checkout use cvs co linux-netnice (for HEAD) cvs co linux-netnice -r patch1 (for patch). please do not commit to the HEAD directly. so do cvs co linux-netnice -r patch1 and give it a shot. thanks --kartikey |
From: kartikey b. <kar...@ho...> - 2006-02-16 00:13:09
|
hi all! i updated the patch to 2.6.15 kerenel tree. the patch works fine and infact while commiting the code and writing this mail i am using the 2.6.15-NETNICE kerenel with bandwidth limit for cvs set to 64K and it works perfactly fine. the next thing i am planning to do is nnfs cleanup and vif deletion and proper attachments of vif to processes and reference counting for the vif. the patch should be in CVS by the time you are reading this mail. to get the 2.6.15 with netnice: cvs co -r netnice2615a Linux check it out! thanks all --kartikey >From: Takashi Okumura <ta...@wi...> >To: Matt Davis <mat...@gm...> >CC: >net...@li...,net...@li... >Subject: [Netnice-kernels] Re: [Netnice-developer] Linux 2.6.12 and Netnice >Date: Tue, 14 Feb 2006 22:08:44 +0900 > > >Thanks Matt, > >sounds like a good restart. we've got to first check the functionality, >and i believe netnice-2.2/contrib/nndiag will help you. please feel free >to fix any bug in the testing script :-) > >thanks! > > >-- taka > >Matt Davis wrote: >>Much thanks goes out to Scott, I applied his patch to 2.6.12 and the >>kernel boots fine. Mounting the nnfs fs works seemingly error free too. >> I have yet to do much testing with this but it looks smooth. The kernel >>with the applied patch is now in CVS and you can give it a shot: >>"cvs co -r netnice2612b Linux" >> >>-Matt >> > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log >files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >_______________________________________________ >Netnice-kernels mailing list >Net...@li... >https://lists.sourceforge.net/lists/listinfo/netnice-kernels |
From: Takashi O. <ta...@wi...> - 2006-02-14 13:09:24
|
Thanks Matt, sounds like a good restart. we've got to first check the functionality, and i believe netnice-2.2/contrib/nndiag will help you. please feel free to fix any bug in the testing script :-) thanks! -- taka Matt Davis wrote: > Much thanks goes out to Scott, I applied his patch to 2.6.12 and the > kernel boots fine. Mounting the nnfs fs works seemingly error free too. > I have yet to do much testing with this but it looks smooth. The > kernel with the applied patch is now in CVS and you can give it a shot: > "cvs co -r netnice2612b Linux" > > -Matt > |