Re: [Netnice-kernels] Re: netnice on linux

[Takashi O. <ta...@wi...>]

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