Hi, I think I made a mistake while configuring Mask in the above example. My Bad :)
This is the exact configuration which should be given as input to PMR creation for the example defined above. PMR1 -- Term value = 0x0000 and mask 0xFF00 PMR2 -- Term value = 0x0100 and mask 0xFF00 PMR3 -- Term value = 0x0200 and mask 0xFF00 Val_sz is 16 bits. 'Val_sz' denotes the size of 'value' and 'Mask' in the specific term. The 'Value' is the value to be matched against the packet header in native byte order the 'Mask' is used to indicate which bits in the header is matched (1's) and which should be ignored (0's). The logic is based on ternary CAM where memory has the ability to query three different inputs: 0, 1, and X. where input 'x' point to don't care or ignore. So for a given value and mask combination the effective set is calculated as: Input set to be matched = value & mask. So if the term length is 16 bits and the following are inputs: Value = 0x0000 Mask = 0xFF00 , then the effective set which is mapped is (value & mask). In the above case ( 0x0000 & 0xFF00) which is 0x00XX. For the input set of 0x00XX to a TCAM then it matches all the values from 0x0000 to 0x00FF. Based on the defined logic if Value = 0x0200 and Mask = 0xFF00 input set = 0x02XX and will match all the values from 0x0200 to 0x02FF. Hence a packet of length 0x1200 will go to the default CoS. Regards, Bala On 4 March 2016 at 06:59, huanggaoyang <[email protected]> wrote: > I don't think the PMR1~3 in your example will work like you said. > If the incoming packet len is 0x1200: > 0x1200 & 0x00FF(PMR1's mask)==0x0000, so the packet matchs PMR1... > 0x1200 & 0x02FF(PMR3's mask)==0x0200, also matchs PMR3... > > But actually I want this 0x1200 packet match the Default Cos's PMR > > > 在 2016/3/3 21:35, Bala Manoharan 写道: > > The concept of range for Packet matching terms was initially proposed in > classification and was removed since most HW implement packet classifier > using TCAM and TCAMs only support matching and mask. > > The range can be configured using the existing PMR by intelligently > configuring the system by using bit mask parameters in PMR. > > Let us take a simple example: > PMR1 -- Term value = 0x0000 and mask 0x00FF > PMR2 -- Term value = 0x0100 and mask 0x01FF > PMR3 -- Term value = 0x0200 and mask 0x02FF > > PMR1 will match all packet with the length range 0 to 255 bytes > PMR2 will match all packets with the length range 256 to 511 bytes > PMR3 will match all packets with the length range 512 to 767 bytes > > And the default CoS will receive all the remaining packets with higher > lengths. > > Regards, > Bala > > On 3 March 2016 at 09:11, huanggaoyang <[email protected]> wrote: > >> Hi, >> Thank you for your explaining. But I can't totally agree with you. >> I don't know how does the ODP_PMR_LEN support range match. >> I mean if I want the packets with different lenth alloced from Pool No1~4 >> like this: >> lenth alloc from >> (0, 200) Pool-No.1 >> [200, 800) Pool-No.2 >> [800, 1600) Pool-No.3 >> other Pool-No.4 >> How can I create <PMR CoS> pair to implement this? >> >> >> 在 2016/3/1 23:27, Bala Manoharan 写道: >> >> Hi, >> >> The above described use-case is implementable with the existing ODP >> classification framework. >> >> Few points to take note for implementing this use-case >> * Each CoS has an associated pool from which packets arriving at this CoS >> is allocated. >> * There is an existing PMR rule ODP_PMR_LEN which selects packets based >> on the total length of received packets. >> >> example: >> An application can create different PMR rules with term ODP_PMR_LEN each >> associated with different CoSs. When packets of different length arrive at >> the pktio interface they will be associated to their respective CoS based >> on the PMR rules (in this case ODP_PMR_LEN). Since each CoS has an >> associated pool then these packets which have been differentiated based on >> their length will be allocated on the pool associated with the CoS. >> >> Hope this Helps, >> Bala >> >> On 29 February 2016 at 15:58, huanggaoyang < <[email protected]> >> [email protected]> wrote: >> >>> Make the packet IO interface support multi packet pools with different >>> buffer size. >>> When receiving packets, the pktio will alloc packets from the most >>> suitable pool via packet len. >>> >>> It aims to save the memory in case that the Memory Resource is limited, >>> and the pktio >>> should deal with packets in different length. >>> >>> huanggaoyang (1): >>> linux-generic:pktio:add an interface to support multi pool >>> >>> include/odp/api/packet_io.h | 15 +++++ >>> .../linux-generic/include/odp_packet_io_internal.h | 1 + >>> platform/linux-generic/include/odp_packet_tap.h | 5 +- >>> platform/linux-generic/odp_packet_io.c | 16 +++++ >>> platform/linux-generic/pktio/tap.c | 70 >>> ++++++++++++++++++++-- >>> test/validation/pktio/pktio.c | 63 >>> ++++++++++++++++++- >>> test/validation/pktio/pktio.h | 1 + >>> 7 files changed, 163 insertions(+), 8 deletions(-) >>> >>> -- >>> 1.9.1 >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> [email protected] >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >> >> >> >> _______________________________________________ >> lng-odp mailing >> [email protected]https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> > > > _______________________________________________ > lng-odp mailing > [email protected]https://lists.linaro.org/mailman/listinfo/lng-odp > > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
