Subject: Re: [forces] IPv4prefix packing

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 15 Jan 2012 07:44:01 -0500

Hi Chuanhuang,

There are several reasons. One is: RAM is abused a lot more.
Ive attached a small C program with four possible layouts of the fields.
In the suggested case we save 3Bytes compared to current definition.
Try running it to see what I mean. Then try to imagine you have 500K such
fields and how much RAM you can save.
Not only for RAM, but if you were to send this structure on the wire -
the most efficient
way to do it is as i described. There is network equipment which will
do more than one
fetch to retrieve a field that goes across 32bit or 64bit alignment
boundaries; these
compute cycles could also be saved if you laid it out this way.
Third, to interop properly you cant send that struct with plain TLVs,
you need to
use ILVs (restricting its usefulness).

cheers,
jamal

On Sun, Jan 15, 2012 at 1:37 AM, Chuanhuang Li
<[email-masked]> wrote:
> Hi,Jamal
>    I think it's no problem that we add this reserved field, if it is needed sometime. But can you
> detailed the possible occasion to use this field? Thanks!
>
> Yours,
> Chuanhuang
> ======= 2012-01-14 21:59:17 Jamal Hadi Salim, wrote: =======
>
>>The current IPV4 prefix is not efficient to send on the wire.
>>Can we re-arrange and add an 8 bit reserved field to make it more
>>efficient.
>>XML suggestions attached.
>>
>>cheers,
>>jamal
>>
>
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 15 Jan 2012 07:51:17 -0500

Sorry, I didnt answer the core part of your question:
We dont need this reserved field, but we want to annotate it
so nobody tries to add a new field in the future; it is also
common practise (look at evolution of many headers at IETF,
IPv4, TCP etc).

BTW: In the xml i sent you, I made a mistake in the IDs; i think ID=3
is repeated twice.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 15 Jan 2012 23:33:15 -0500

I started out thinking exactly the way you describe Chuanhuang.
Then Jamal pointed out to me that when one uses the full-data TLV we 
pack all of the data together.  In order as defined by the LFB.  At 
which point the alignment comes into play.

Yours,
Joel

On 1/15/2012 9:10 PM, Chuanhuang Li wrote:
> Hi,Jamal
>      I have some different opinions.
> I think the LFB definition is not a  specific implementation. It just a logical and
> abstract definition. User can implement the LFB in different ways. But the important
> is that CE could use ForCES protocol to control these LFBs implemented by different users.
> Byte alignment is an implementation problem. If the reason for adding the definition field is
> just this one, from my point, i think we needn't change.
>
> Exactly, there may be other byte alignment cases, not just this one. For example, if a "string" type
> component is a member of "struct" type, such as the definition of "LFBLinkType" in FEObject LFB.
>
> Yours,
> Chuanhuang
> ======= 2012-01-15 20:51:42 Jamal Hadi Salim, wrote: =======
>
>> On Sun, Jan 15, 2012 at 7:44 AM, Jamal Hadi Salim<[email-masked]>  wrote:
>>> Hi Chuanhuang,
>>>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 16 Jan 2012 07:28:49 -0500

Aside from the packing issue, lets say your implementation was how i described
the most optimal layout out to be and you merely translated on where
to put things
as they come in from the wire with this format; on a lot of hardware,
the processing is going to consume  more cycles. For example, two fetches
will be required to retrieve HopSelector from the wire format.
So it is pragmatic to make this change.

cheers,
jamal

On Sun, Jan 15, 2012 at 11:33 PM, Joel M. Halpern <[email-masked]> wrote:
> Then Jamal pointed out to me that when one uses the full-data TLV we pack
> all of the data together.  In order as defined by the LFB.  At which point
> the alignment comes into play.
>
> Yours,
> Joel
>
>

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 1 Feb 2012 11:45:39 +0800

Hi Jamal and Chuanhuang,

I agree it seems like an implementation issue, whereas it also seems a good way of optimization to the lib xml file, i.e., users may be rewarded  by the change at no extra cost.

As a result, I suggest to make the component ID order as much as possible to consider the alignment for all LFBs. 

On the reserved field, I'm not sure if we now need this, or if we do so for all LFBs, the xml may look a little usual, with too many reserved fields?

thanks,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>

cheers,
jamal

>>>>>> XML suggestions attached.
_______________________________________________
forces mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/forces