> -----Original Message-----
> From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com]
> Sent: Wednesday, September 15, 2010 11:53 AM
> To: Anderson, Trevor; Andrew Morton
> Cc: linux-ker...@vger.kernel.org; Thomas Moll; linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 switches
>
> Anderson, Trevor <tander...@curtisswright.com> wrote:
> >
> > Keep it in please. We lurkers in the embedded community do use the
> per-port routing tables.
> > One of the problems with SRIO switch tables is that access to routes
> is not atomic; we can use
> > restricted access to per-port routing tables to reduce the risk of
> interference. And we still use
> > the Global table during enumeration.
> >
> Will it help if I add sysfs attribute(s) to handle per-port routes?

I don't think so - not from my perspective, at least. All of our routes
are programmed using the broadcast table; but we use the private tables
as a safer method of reading the routes that have been programmed, when we
need to know that.



_______________________________________________________________________
This e-mail and any files transmitted with it are proprietary and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have reason to believe that you have received this e-mail in error, please 
notify the sender and destroy this email and any attached files. Please note 
that any views or opinions presented in this e-mail are solely those of the 
author and do not necessarily represent those of the Curtiss-Wright Corporation 
or any of its subsidiaries.  Documents attached hereto may contain technology 
subject to government export regulations. Recipient is solely responsible for 
ensuring that any re-export, transfer or disclosure of this information is in 
accordance with applicable government export regulations.  The recipient should 
check this e-mail and any attachments for the presence of viruses. 
Curtiss-Wright Corporation and its subsidiaries accept no liability for any 
damage caused by any virus transmitted by this e-mail.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to