• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 102 subscribers
  • Views 515 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C6748: Use of VLAN tags

Michael Greenspan
Intellectual 565 points
Part Number: TMS320C6748

In your description of the EMAC/MDIO you say it has "Eight receive channels with VLAN tag discrimination for receive quality-of-service (QOS) support."

If it is a correct statement, is there any documentation as to how to use it?  One would expect a register to enter the VLAN ID for discriminating the VLAN tags desired and those not desired?

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the sw team. They will post their feedback directly here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 565 points
    SW team? Are you there? Any hints?
  • 0 in reply to Michael Greenspan
    TI__Mastermind 27355 points

    Hi Michael,

    Sorry for the delayed response. From the developer:

    It looks like hardware ignores the VLAN ID portion of the VLAN tag, and just uses the priority bits (TCI = Traffic Class ID = priority bits), therefore we think that VLAN ID cannot be used in packet classification.  Priority bits can be used to implement quality of service on receive where lower priority packets (TCI = 0 - 3 we think) will be dropped if there isn’t enough buffering available.  Priority bits aren’t used to pick RX channel as far as we can tell.

    TRM Section 17.2.10.4 Hardware Receive QOS Support

    Hardware receive quality of service (QOS) is supported, when enabled, by the Tag Protocol Identifier format and the associated Tag Control Information (TCI) format priority field. When the incoming frame length/type value is equal to 81.00h, the EMAC recognizes the frame as an Ethernet Encoded Tag Protocol Type. The two octets immediately following the protocol type contain the 16-bit TCI field. Bits 15-13 of the TCI field contain the received frames priority (0 to 7). The received frame is a low-priority frame, if the priority value is 0 to 3; the received frame is a high-priority frame, if the priority value is 4 to 7. All frames that have a length/type field value not equal to 81.00h are low-priority frames. Received frames that contain priority information are determined by the EMAC as:

    • A 48-bit (6 bytes) destination address equal to:

    – The destination station's individual unicast address.

    – The destination station's multicast address (MACHASH1 and MACHASH2).

    – The broadcast address of all ones.

    • A 48-byte (6 bytes) source address.

    • The 16-bit (2 bytes) length/type field containing the value 81.00h.

    • The 16-bit (2 bytes) TCI field with the priority field in the upper 3 bits.

    • Data bytes

    • The 4 bytes CRC.

    The receive filter low priority frame threshold register (RXFILTERLOWTHRESH) and the receive channel n free buffer count registers (RXnFREEBUFFER) are used in conjunction with the priority information to implement receive hardware QOS. Low-priority frames are filtered if the number of free buffers (RXnFREEBUFFER) for the frame channel is less than or equal to the filter low threshold (RXFILTERLOWTHRESH) value. Hardware QOS is enabled by the RXQOSEN bit in the receive

  • 0 in reply to Sahin Okur
    Intellectual 565 points

    Thanks Sahin.

    I had already read section 17.2.10.4 and 5, and it was a bit disappointing, relative to what seemed to be promised in section 17.1.2 "Features".

    So I was kind of hoping that maybe there was something more, something that I had not found yet.

    But if the people at TI say explicitly that there is no hardware discrimination of the VLAN ID, then I guess that resolves the issue, and we will just have to manage with what is there.

    Again, thanks.

    Michael