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

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

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