Subject: Re: [forces] IPv4prefix packing

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 2 Feb 2012 09:01:31 -0500

Hi Weiming,

There are some implementation ties to what i described - but having fields being
alignment accessible when it doesnt cost you anything is pragmatic. Reserved
fields are a common occurrence in protocol and data definitions (we have one in
the forces header for example for this very same reason).

Sometimes it is hard to achieve that goal. For example when you have MAC
addresses that straddle across 32 bit fields. In the Linux kernel,
some equipment
ends up adding 2B padding after the ethernet header after receiving the packet
to align the IPv4/6 header so that when it is accessed, there are no alignment
penalties. So _how you send things on the wire_ makes a difference.

In the same spirit of thought, but this one is not as a big deal,
for EncapTableEntry, aligning on 32 bits:

DstMac(32  bits)
DstMac(16 bits): SrcMac (16 bits)
SrcMac(32 bits)
VlanID (16 bits): L2PortID(16 bits)
L2PortID(16 bits)

It would be nice maybe to have it as:
DstMac(32  bits)
DstMac(16 bits): SrcMac (16 bits)
SrcMac(32 bits)
VlanID (16 bits): Reserved (16bits)
L2PortID(32 bits)

Actually VlanID is 12 bits so the reserved could be reserved1(4 bits)
and reserved2 (16bits)

cheers,
jamal

On Tue, Jan 31, 2012 at 10:45 PM, Wang,Weiming <[email-masked]> wrote:
> 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]>
>
> 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:
>> 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: =======
>>>
>>>> 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
>>>>
>>>> On Sun, Jan 15, 2012 at 7:44 AM, Jamal Hadi Salim<[email-masked]>
>>>> wrote:
>>>>>
>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Chuanhuang Li <[email-masked]>
Date: Fri, 3 Feb 2012 00:05:37 +0800

Hi, Jamal and all
     If we consider the alignment issue, besides the type of IPv4Prefix, IPv6Prefix and 
EncapTable, VlanInputTable in EtherClassifier also need to be modified. The way to solve 
alignment with adding Reserved field, please see the attachment. 
 
I agree to Jamal's modification suggestion.  But, i still think this is just an FE's implementation issue. 
The main goal of LFB definition is that CE can control and configure FEs implemented by different users, not 
guiding user to implement an FE.  
The alignment said in ForCES protocol and the aligment in FE's implementation are two different issues. 
If user sends ForCES message with TLV length not multiple of 32 bits, Padding is required.
Whatever the LFB is defined, this requirement can be reached. But the LFB can be implemented in different ways.  
For example, the "SupportedLFBType" defined in FEObject LFB,
                <dataTypeDef>
                <name>SupportedLFBType</name>
                <synopsis>table entry for supported LFB</synopsis>
                <struct>
                  <component componentID="1">
                    <name>LFBName</name>
                    <synopsis>
                      The name of a supported LFB class
                    </synopsis>
                    <typeRef>string</typeRef>
                  </component>
                  <component componentID="2">
                    <name>LFBClassID</name>
                    <synopsis>the id of a supported LFB class</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                  ......
LFBName is string type, LFBClassID, uint32 type, respectively. 
User can implement this type in the following way: 
typedef struct SupportedLFBType{
        UINT8    LFBName[FEOBJECTLFB_MAX_STRING_LENGTH]; 
        UINT32   LFBClassID;
        ......
The macro "FEOBJECTLFB_MAX_STRING_LENGTH" used by LFBName can be any value that user wants to use
(for alignment, Usually be multiple of 32 bits).
But if user encapsulates the information into TLV, the string length is the actual length 
of the value. It is not multiple of 32 bits in most cases.

Yours,
Chuanhuang

> From: [email-masked]
> Date: Thu, 2 Feb 2012 09:01:31 -0500
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [forces] IPv4prefix packing
> 
> Hi Weiming,
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 2 Feb 2012 12:00:15 -0500

> alignment with adding Reserved field, please see the attachment.

I think this is fine - Note: I dont feel as strongly about this as i
did about the
ipv4 prefixing.

> of the value. It is not multiple of 32 bits in most cases.

Strings are easy.
You have no choice but to pack variable sized entities(like strings) in TLV
or ILV. In the case the string size is not 32-bit aligned, xLV must be
padded to be
32-bit aligned. So accessing the on-the-wire format is alignment friendly.
Imagine instead of a string you have a uint8 in the place of LFBName;
then the issue is clear.

cheers,
jamal