[Ndn-interest] [EXT] content store

[Junxiao Shi]

Hi Marwa

In NDN-DPDK (notice the correct spelling):
Allocation function is rte_pktmbuf_alloc. It's invoked by the Ethernet
adapter driver, such as dpdk/drivers/net/mlx5/mlx5_rxq.c
<https://github.com/DPDK/dpdk/blob/51fe32138c860992f228dbf19416ffd3b8e8baf4/drivers/net/mlx5/mlx5_rxq.c#L147>
.
Deallocation function is rte_pktmbuf_free. For cached Data it's invoked by
the CS eviction procedure, in ndn-dpdk/csrc/pcct/cs-entry.h
<https://github.com/usnistgov/ndn-dpdk/blob/0cc54f843f952ca568768545201a7b99e45ff9c1/csrc/pcct/cs-entry.h#L99>
.

I don't know about others.

Yours, Junxiao

On Tue, Feb 23, 2021 at 6:27 AM marwa kareem <
m.kareem1305 at coeng.uobaghdad.edu.iq> wrote:

> *External Email*
> Hi Junxiao,
> Thank you for the explanation, now things become more clear to me.
>
> Can you please refer to where buffers are handled in the  nfd and nfd-
> dpdk source code?
>
> thanks,
> Marwa
>
> On Tue, Feb 23, 2021 at 6:33 AM Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>> Hi Marwa
>>
>>
>>
>>> 1- In the content store you are using skip lists and hash tables in
>>> older versions 0.7.x, is the skip lists and hash tables have the ability to
>>> store the data packets?
>>> because in the repository the btrees have been used, why? I,m confused
>>> about this point.
>>>
>>
>> Typically the Content Store has an *index* pointing to packet buffers.
>> When someone says the CS is a hash table, tree, trie, skip list, etc, it
>> refers to the structure of the index.
>>
>> The packets themselves are stored in buffers elsewhere.
>> In NFD, buffers are allocated via malloc; in NDN-DPDK, buffers are
>> fetched from a pre-allocated mempool; I don't know how ccnd handles buffers.
>>
>> 2- why the number of contents have been used to measure the capacity of
>>> the content store and not something like (200MB, 300MB, ...)?
>>>
>>
>> As I described above, a forwarder stores packets in buffers.
>> In both NFD and NDN-DPDK, a buffer is allocated before receiving the
>> packet from a socket or Ethernet adapter, and the packet stays in the same
>> buffer until it's evicted / deleted.
>> Since the packet length is unknown before receiving, every buffer must be
>> able to accommodate the maximum packet length (around 9KB).
>>
>> As such, the CS capacity in bytes equals the CS capacity in packets
>> multiplied by the maximum packet length.
>> It has nothing to do with the actual packet length.
>> In this case, it's easier to measure CS capacity in packets.
>>
>> Yours, Junxiao
>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20210223/0ae38929/attachment.html>