or in other words... The Difference between "walking to work" and "carrying a bag lunch". Hmmm... you say?
The first event is something that happens... The second event is something that takes advantage of the other event... think of efficiencies of scale... You would prefer to deliver multiple lunches to work if you could, but that's not always the requirement. But walking to work is still a good thing, even if you don't have a single bag lunch to bring or deliver. I try...
You can trunk across multiple ISL's (inter-switch links) if they are configured properly. As stated earlier, trunking allows "in order delivery" of packets from an initiator connected to one switch to a target connected to a different switch. There is a difference between trunking on a CISCO switch, and a BROCADE switch because of the VLAN concept on the CISCO, but the general result are the same, speed. As an example, if you configure 8 ISL's (I think the limit is 16 ISL's per switch) between two switches, you can trunk across any 2 or more ISL's.
You may chose to dedicate multiple trunked ISL's to a particular array, cluster or even an particular application... One application that comes to mind is FCIP links to a remote site for replication. Lets say you have an array somewhere downstream in your infrastructure in Miami, that needs to replicate to Peru. You will probably do whatever you can to "stream" data as quickly as possible to the switch that has the FCIP links to Peru. Using multiple ISL's, you trunk across as many ISL's as you need for performance. I know, it's a stretch, I would much rather move that storage to the switch with the FCIP connection, even if I had to leave the servers
But the heart of your question is whether by having 2ea. 8Gb FC cables, do you get 16Gb of bandwidth by trunking? The answer of course is no. Your bandwidth is limited by the overall network contention on all the ISL's at any given time. Trunking by itself does not increase bandwidth. You may have additional request queues for each fiber cable you add, yes, but the net performance result does not improve by trunking multiple ISL's by itself. MPIO settings, queue depth, number of ISL's, production/development mix, service queues on the storage, separate backup SAN/TAN availability, replication requirements, etc. all affect the configuration items (CI) of the infrastructure. In most cases, by trunking existing ISL's, you will see NO improvement of speed (bandwidth), in most environments.
So unless you are a hedge fund or a telco, or have some heavy replication requirements, the recommendation is to allow those ISL's to do what they need to do to move traffic themselves. If you can see a small percentage of the ISL's being hit harder than others, there are other configuration items to be tweaked first before trunking. Trunking can cause more problems if not done properly. Example, P9500 configured with multiple cache partitions for Prod, Dev, Replication, external storage, etc. can leave you cache poor for any or all those environments at different times. It's always recommended to eschew over-configuring for cache performance before implementing partitioning. The same holds true for trunking. Especially if your wondering if just by trunking, you could double bandwidth. NOT!
Friends, don't let friends implement trunking...
