[Nfd-dev] Vehicular face design: preliminary questions

[Davide Pesavento]

Hi Junxiao,

Thanks for replying.

On Fri, Aug 22, 2014 at 12:43 AM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
>
> 2/ submitting supporting components early
> [...]
> I suggest you to provide a design document that explains how many components
> are there, their functionality and relationship.
> Without this document, the necessity of components would be challenged, and
> you'll have a hard time getting them approved.
>

Sure, we already intended to provide a design document before starting
the implementation.

> 3/ platform limitation
> Platform policy requires all projects to build on both Ubuntu and OSX.
> As I understand, if the addition of V2V face and supporting components
> doesn't cause a build failure, you're fine.
> One prior example is that EthernetFace does not support OSX with Boost 1.56.
>
> If you intend to support Ubuntu and Boost 1.54 only, I suggest adding a
> configuration option, so that V2V face and supporting components are
> compiled only if "./waf configure" is executed with "--with-v2v" option.
>

Ok, that is not a problem then.

> 4/ threading
> The decision of not to use threading comes from Van's opinion at 20140115
> meeting: context switching is expensive - a context switch costs around 100
> instructions.
> Threading can be used if you can prove it's more efficient than a design
> without threading.
>
> I personally agree that it’s worth seconds of programmer time to save hours
> of CPU time.
> If you can illustrate that a design without threading is much more difficult
> to develop than a design with threading, and an implementation with
> threading won't become a bottleneck on V2V's typical operation environment
> (vehicle onboard computer), I'll agree with using threading.
>

The main reason why we chose multi-threading was that our Link
Adaptation Layer (a.k.a. layer-2.5, inside the V2V face) performs
several tasks that are completely independent from the main forwarder
thread (such as distance calculation and handling of digital road
maps) and needs to process all received (broadcast) frames in order to
properly adjust retransmission timers, to handle implicit ACKs,
directional ACKs, geo-tagging, and other things specific of the
vehicular environment (only a fraction of all these packets are then
passed to the forwarder). We didn't want all these tasks to interfere
with the main forwarder loop and slow down packet processing on the
other (non-vehicular) faces.

Anyway, we don't know yet if it still makes sense for us to use a
separate thread, given the new daemon design. We are still
investigating the best approach and will present our proposal soon. So
what we actually wanted to know with question 4/ was: is threading
completely forbidden or will it be accepted if properly justified?
>From your answer it seems that the latter is true.

Thanks,
Davide