In principle:
A parallel query against a partitioned table will use one slave per partition if the query is thought to span multiple partitions, and it can use all slaves on a single partition if the query is thought to target just one partition. Unfortunately, this is NOT strictly true. It is possible for the optimizer to decide to use parallelism at degree M when accessing N partitions. Sometimes this can lead to very inefficient, brute-force, processing when a more efficient path is available. This can be a particular problem with multi-table joins that should be partition-wise joins. You may be better off leaving the tables defined as non-parallel and adding explicit parallel hints to the code for critical queries.

'PX Deq: Execute Reply' is considered as 'Idle' by Oracle wait interface, but for session it is not idle - it is waiting.

1) Session is executing a SQL, for which plan is build to parallelize work

2) Session becomes a QC (Query coordinator), which is given certain number of parallel slaves

3) QC instructs PX slaves what kind of work they should perform.
When QC has instructed PX slaves about work, it waits for the reply from slaves - since it has no work to do,but it have do something This something is "sleep and wake up sometimes (when wait timeout is passed)".This kind of wait is called 'PX Deq: Execute Reply'.It is idle for session (since it is not performing significant work), but for query response time it is not idle, since you will receive your results only when the query will be finished.That will happen when all the necessary work will be done.

Also forgive me for my earlier post the Degree of PARALLELISM
is 10 for indexes not for table.

I did some search myself and found this.