Nack received in Nullify TLP

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

Nack received in Nullify TLP

Postby Guest » Tue Jun 18, 2013 6:30 pm

Hi,
Let's consider below case:
Application/Software indicate that current TLP has to be marked as nullify tlp, so TL will send complete TLP to DL and will indicate about the same. DL will send it to PL and it will inform PL about nullify packet so that PL will add EDB indicating Bad End. DL will not store same TLP in retry buffer.

Now at receiver side there was error in LCRC(i.e. calculated LCRC did not match with inverted LCRC) so receiver will send NACK. Now in Tx retry buffer this TLP was not stored as it was marked as nullify then how re-transmission will occur?

Please help me in understanding this.
--
regards,
Snehal
Guest
 

Re: Nack received in Nullify TLP

Postby support » Tue Jun 18, 2013 7:06 pm

Wow. That was a rather tangled scenario. Does anyone really nullify packets? It looks like a theoretic feature to me.

Anyhow, the PCIe 1.0 spec 3.5.2.1 says that when a packet is nullified, it doesn't increment NEXT_TRANSMIT_SEQ, so from its perspective, it's as if the packet was never sent. And therefore, it's not expected to be in the retry buffer.

The same section also says, that when a replay is initiated, either due to reception of a Nak or due to REPLAY_TIMER expiration, the all unacknowledged packets should be transmitted. Since the packet isn't in the retry buffer, it's not even in the game. No retransmission is expected. Which makes sense. Why would one want to retransmit a packet that the receiver should ignore.

I'm not even sure that an Nak should be sent on a bad nullified packet. Not that it matter so much.

I can understand the concern that AckNak_Seq_Num will contain a sequence number to a packet that the sender doesn't remember. But the spec says "If the Sequence Number specified by the AckNak_Seq_Num does not correspond to an
unacknowledged TLP, or to the value in ACKD_SEQ, the DLLP is discarded". So this Nak will do nothing. At worst, it will Nak a packet that was just sent, accidentally had the same sequence number, and wasn't Ack'ed.

So this tangled case seems to work out pretty well anyhow.

Hope this helped,
Eli
support
 
Posts: 733
Joined: Tue Apr 24, 2012 3:46 pm

Re: Nack received in Nullify TLP

Postby Guest » Wed Jun 19, 2013 3:06 am

Hi Eli,
Thanks for the replay.

You are correct in " that when a packet is nullified, it doesn't increment NEXT_TRANSMIT_SEQ, so from its perspective, it's as if the packet was never sent. And therefore, it's not expected to be in the retry buffer."

In similar manner in receiver also NXT_RCVD_SEQ will not increment as it is generating NACK. So the sequence number received at Transmitter side will be last acknowledge sequence number(@receiver end).

So "AckNak_Seq_Num" is not a problem here. Real problem is that we do not have any such TLP in retry buffer with such sequence number. I do not how we handle such case.

--
Regards,
Snehal
Guest
 

Re: Nack received in Nullify TLP

Postby support » Wed Jun 19, 2013 9:24 am

Since you don't have the nullified TLP in your retry buffer, that matches "If the Sequence Number specified by the AckNak_Seq_Num does not correspond to an unacknowledged TLP, or to the value in ACKD_SEQ, the DLLP is discarded". So just trash that Nak. Which makes sense. What doesn't make sense is to Nak a nullified packet, and I'm not sure if it's allowed. But anyhow, the correct way is to ignore that packet.

I suggest having a look at figure 3-17 in the PCIe 1.0 spec (Ack/Nak DLLP Processing Flowchart): If the DLLP is an Nak, AckNak_Seq_Num isn't even considered (except for two sanity checks). It triggers off a replay of all unacknowledged packets in the retry buffer.
support
 
Posts: 733
Joined: Tue Apr 24, 2012 3:46 pm


Return to General PCIe

cron