Ingress/Egress port TC/VC mapping

Comments and questions related to the "Down to the TLP" pages

Ingress/Egress port TC/VC mapping

Postby Guest » Fri May 16, 2014 1:32 pm

Hi Eli,

I am studying the PCIe specs, and I am having trouble with some issues that do not seem to be stated in the specs. Here goes 3 of them

1 -The specs state that transaction ordering is applied on packets of the same traffic (TC) class according to some rules. It also states the packets in the same virtual channels (VC) should be reordered. VC can contain different TCs. Do they have to be re-ordered?

2 - Does reordering have to applied in the egress port and the ingress port wherever a virtual channel exists?

3 - Do ingress ports and egress ports have the same TC/VC mapping? The VC resource control register contains the mapping information, but it does not specifically mention whether it is for an ingress/egress port.

Can you please shed some light on these?

Thanks,
Dawood
Guest
 

Re: Ingress/Egress port TC/VC mapping

Postby support » Fri May 16, 2014 1:54 pm

Hi,

I'm curious to know why the issue of virtual channels interests you at all. I still haven't seen a concrete project that actually uses them. So it's quite clear that I don't have much experience with virtual channels. But from the top of my head:

(1) Certain reordering rules always apply, even in the typical setting where all packets go through VC0.
(2) The reordering rules depend on whether the packet is marked to allow non-strict reordering or not (I don't recall the exact term).
(3) Two packets having different values in their TC fields may be reordered freely.
(4) Data layer credits are maintained separately on each link partner for packets with a each allowed TC field value, for every leg on the bus.

Items (3) and (4) are in fact the essence of virtual channels: A receiver may signal with its credits that it can't receive more packets with TC=0, but it's fine with more packets having TC=1. So if the sender on the same link happens to have packets with TC=1 for transmission, they may bypass packets with TC=0 in its transmission queue because of (3) and transmit them.

In reality, it seems like this "can't take anymore" scenario isn't really relevant in real applications, which is probably why there's not much attention to this whole issue. Except in datasheets and manuals.

The answers to your specific question lies in how your hardware is set up to mark and interpret those TC fields.

I hope this gave an idea.

Regards,
Eli
support
 
Posts: 760
Joined: Tue Apr 24, 2012 3:46 pm

Re: Ingress/Egress port TC/VC mapping

Postby Guest » Fri May 16, 2014 2:18 pm

Thanks Eli for the prompt reply. Yes, it did give me some idea.

To tell you the truth, I am new to all of this. We are in the initial stages of identifying our product (that we still don't know). In the mean time, we are studying the PCIe specs, and we want to implement something that involves it. We are not specially interested in virtual channels, but we are interested in knowing the whole spec, and what we "must" and "can" implement when it comes to the PCIe layers.

I am a bit confused though. Common practice does not use virtual channels? where are packets stored, in general buffers? Or did you mean that common practice does not use multiple virtual channels (VC0-7)?

How about packet reordering, where does that happen, in the egress or the ingress part of the port, or in both? Can you comment on that?

Thanks Eli,
Dawood
Guest
 

Re: Ingress/Egress port TC/VC mapping

Postby support » Fri May 16, 2014 4:19 pm

Hi,

Virtual channels have nothing to do with the buffers. It's really just marking the TC field with different values in order to allow a sort-of "VIP treatment" of some packets. But as it turns out, all packets are "VIP" enough for common applications, so all packets are transmitted with TC=0, or with Virtual channel zero, VC0.

Packet ordering takes place anywhere packets are buffered: In the outgoing endpoint's PCIe interface, in switches in the middle, and also possibly in the interface of the endpoint at which the packet arrives. The reordering rules makes sense, though, so if strict ordering is imposed (it almost always is) the overall behavior is what one would naturally expect.

And now some shameless self-promotion: Since you're looking for a PCIe solution -- have you taken a look at the Xillybus IP core? ;)

Regards,
Eli
support
 
Posts: 760
Joined: Tue Apr 24, 2012 3:46 pm

Re: Ingress/Egress port TC/VC mapping

Postby Guest » Mon May 19, 2014 1:11 pm

Thanks Eli. We have not taken a look yet at Xillybus IP core, but we will :D
Guest
 


Return to General PCIe

cron