[ewg] Fireworks CS3
Adobe CS3 Master Collection for PC or MAC includes: - InDesign CS3 - Photoshop CS3 - Illustrator CS3 - Acrobat 8 Professional - Flash CS3 Professional - Dreamweaver CS3 - Fireworks CS3 - Contribute CS3 - After Effects CS3 Professional - Premiere Pro CS3 - Encore DVD CS3 - Soundbooth CS3 - oemcheapnew. com in Internet Exp|orer System Requirements For PC: - Intel Pentium 4 (1.4GHz processor for DV; 3.4GHz processor for HDV), Intel Centrino, Intel Xeon, (dual 2.8GHz processors for HD), or Intel Core - Duo (or compatible) processor; SSE2-enabled processor required for AMD systems - Microsoft Windows XP with Service Pack 2 or Microsoft Windows Vista Home Premium, Business, Ultimate, or Enterprise (certified for 32-bit editions) - 1GB of RAM for DV; 2GB of RAM for HDV and HD; more RAM recommended when running multiple components - 38GB of available hard-disk space (additional free space required during installation) - Dedicated 7,200 RPM hard drive for DV and HDV editing; striped disk array storage (RAID 0) for HD; SCSI disk subsystem preferred - Microsoft DirectX compatible sound card (multichannel ASIO-compatible sound card recommended) - 1,280x1,024 monitor resolution with 32-bit color adapter - DVD-ROM drive For MAC: - PowerPC G4 or G5 or multicore Intel processor (Adobe Premiere Pro, Encore, and Soundbooth require a multicore Intel processor; Adobe OnLocation CS3 is a Windows application and may be used with Boot Camp) - Mac OS X v.10.4.9; Java Runtime Environment 1.5 required for Adobe Version Cue CS3 Server - 1GB of RAM for DV; 2GB of RAM for HDV and HD; more RAM recommended when running multiple components - 36GB of available hard-disk space (additional free space required during installation) - Dedicated 7,200 RPM hard drive for DV and HDV editing; striped disk array storage (RAID 0) for HD; SCSI disk subsystem preferred - Core Audio compatible sound card - 1,280x1,024 monitor resolution with 32-bit color adapter - DVD-ROM drive- DVD+-R burner required for DVD creation Food-Bank Organizers Face Shortages Lebanese Politics: Fascinating, Frustrating ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] good luck
Hello! I am bored tonight. I am nice girl that would like to chat with you. Email me at [EMAIL PROTECTED] only, because I am using my friend's email to write this. Don't miss some of my naughty pictures. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Agenda for the OFED meeting today
Steve Wise wrote: Sorry I missed today's call. If possible, I'd like a few weeks to get the cxgb3 fixes tested and ready to go. That puts me around mid may. I'll try and pull that in to make a RC1 of May 6, but I'm thinking I might need another week or so. Please try to make most of the code ready for May 6. You can add more modifications for RC2 which is May 20. Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED April 21 meeting summary
OFED April 21 meeting summary about 1.3.1 plans and OFED 1.4 development: 1. OFED 1.3.1: 1.1 Planned changes: ULPs changes: IB-bonding - done SRP failover - on work SDP crashes - on work RDS fixes for RDMA API - done librdmacm 1.0.7 - done Open MPI 1.2.6 - done uDAPL - on work Low level drivers: - each HW vendor should reply when the changes will be ready nes - will be ready on first week of May mlx4 - fixes are ready; changes to support Eth are under review of the submission to kernel so not clear if they will make it on time. cxgb3 - will be ready by middle of may. Majority of changes should be submitted for RC1. ipath - wait for update from Betsy ehca - wait for update from Christoph 1.2 Schedule: we agreed that 2 release candidate should be sufficient GA is planned for May-29 - RC1 - May 6 - RC2 - May 20 Note: daily builds of 1.3.1 are already available at: http://www.openfabrics.org/builds/ofed-1.3.1 2. OFED 1.4: Release features were presented at Sonoma (presentation available at http://www.openfabrics.org/archives/april2008sonoma.htm) IPv6: Woody is looking for resources to add IPv6 support to the CMA. Hal noted that it will require a change in opensm too. Xsigo Vnic Vhba - Not clear if they will make it Kernel tree is under work at: git://git.openfabrics.org/ofed_1_4/linux-2.6.git branch ofed_kernel We should try to get the kernel code to compile as soon as possible so everybody will be able to contribute code. Schedule reminder: == Release: Oct 06, 2008 Features freeze: Jun 25, 08 (kernel 2.6.26 based) Alpha: Jul 9, 08 Beta: Jul 30, 08 kernel 2.6.27-rcX (assuming it will be available) RC1:Aug 13, 08 RC2:Aug 27, 08 RC3-RC5/6 - every 5-10 days Latest RC to be used in OFA interop event GA: Oct 06 08 Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] IPoIB 4K MTU support
Hello Roland,
On Tue, 2008-04-22 at 13:46 -0700, Roland Dreier wrote:
Thanks, applied with some cleanups as below.
Thanks!
As an aside, in the case where we need to use a fragment in the receive
skb, does it make sense to make the initial linear part bigger so the
TCP and IP headers fit there (and the kernel doesn't have to look into
the fragment list to handle the packet)?
We can improve this later.
Also, is there any clean way where a kernel with PAGE_SIZE 4096 can
have ud_need_sg evaluate to 0 at compile time, so that all the unneeded
code can be thrown out by the compiler?
+ return (IPOIB_UD_BUF_SIZE(ib_mtu) PAGE_SIZE) ? 1 : 0;
I've never understood this style: it makes no sense to do
return bool ? 1 : 0;
instead of just
return bool;
You are right.
+static inline void ipoib_ud_dma_unmap_rx(struct ipoib_dev_priv *priv,
+ u64 mapping[IPOIB_UD_RX_SG])
+{
+ if (ipoib_ud_need_sg(priv-max_ib_mtu)) {
+ ib_dma_unmap_single(priv-ca, mapping[0], IPOIB_UD_HEAD_SIZE,
DMA_FROM_DEVICE);
+ ib_dma_unmap_page(priv-ca, mapping[1], PAGE_SIZE,
DMA_FROM_DEVICE);
+ } else
+ ib_dma_unmap_single(priv-ca, mapping[0],
IPOIB_UD_BUF_SIZE(priv-max_ib_mtu), DMA_FROM_DEVICE);
+}
+
+static inline void ipoib_ud_skb_put_frags(struct ipoib_dev_priv *priv,
+struct sk_buff *skb,
+unsigned int length)
+{
+ if (ipoib_ud_need_sg(priv-max_ib_mtu)) {
+ skb_frag_t *frag = skb_shinfo(skb)-frags[0];
+ /*
+ * There is only two buffers needed for max_payload = 4K,
+ * first buf size is IPOIB_UD_HEAD_SIZE
+ */
+ skb-tail += IPOIB_UD_HEAD_SIZE;
+ frag-size = length - IPOIB_UD_HEAD_SIZE;
+ skb-data_len += frag-size;
+ skb-truesize += frag-size;
+ skb-len += length;
+ } else
+ skb_put(skb, length);
+
+}
These are pretty big to put in a header file as inlines... I moved them
to the only .c file where they're used.
- R.
Right. I should have moved it into .c file from Or's comment. I forgot.
Thanks.
Shirley
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Where have you been?
Hello! I am tired this afternoon. I am nice girl that would like to chat with you. Email me at [EMAIL PROTECTED] only, because I am using my friend's email to write this. Will send some of my pictures ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Notes from Improve the OFED Development Process at Sonoma
Here are the notes from the Improve the OFED Development Process session at Sonoma, including issues, proposals, questions and comments, collected from the session. I wanted to get the notes out in front of everyone before we forget what we actually talked about. Once people have had a chance to review them, we can follow up and determine how to execute. (Note, I'm out of town and away from email till next Monday, so hopefully other panelists will respond to questions and comments - no, I didn't plan it that way!) - Betsy Issues 1) How do we ensure we achieve enterprise quality? PROPOSALS: a) Evaluate features early in the process, so everyone is aware of potential impact - eg, API changes, performance impact on other components, (NOTE: we need a checklist) b) Make it clear to all participants that OFED is not intended to be an experimental release. Components can be marked as tech preview, but it is not OK to put experimental changes in already released protocols. c) Authors of changes to ULPs, or SW that may affect many HW vendors should submit a list of potential affected HW, along with a list of which HW they have tested on. 2) What do we do to minimize slippage of release date? PROPOSALS: a) Clear definition of feature vs bugfix b) Clear statement and communication of feature freeze date c) Review proposed features, including what impact they might have on other components, such as drivers or ULPs d) Especially for late bug fixes, the implementor has to be responsible for making sure the change doesn't impact other SW components, or other vendors hw. PROPOSAL: Make OFED a date driven release. Implies that for last period (4 weeks?) of release, only specific bug fixes are allowed. 3) Process for fast turnaround, single vendor bugfix. DOCUMENT on Open Fabrics webpage: - submit patch - get nightly build - vendor tests - all recognize that sub-minor (4 release numbers) means that this is for one vendor - or, can we actually use something like: 1.3.1.1.q, to indicate a bugfix release from QLogic (NOTE: need decision) - fix needs to be rolled into next point release - Download page from openfabrics.org has only fully qualified, tested releases 4) QUESTION: Does kernel code always need to come through kernel.org? PROPOSALS: a) SDP is an exception, as existing non-conforming - it will not be submitted to kernel.org b) IB kernel developers will try to get changes into kernel first, to be pulled down into OFED. If they miss the kernel train, changes should be submitted to next available kernel. Developers should try to make sure their changes are in Roland's queue, even if they are not actually in the kernel. c) Components (other than SDP) which are not currently in the kernel should be submitted there. (eg, RDS - what else?) QUESTION: What happens if a component is not accepted to kernel? - if it is because of code style/quality - fix it - if not considered appropriate feature for kernel - discuss it, but how do we resolve it? Note that we really don't want a component which is not in the kernel, and which has no long term owner - other possible reason for rejection is that it is legally inappropriate, that is, either wrong license/copyright, or disputed patent, or something similar. This should not be taken into OFED. QUESTION: How do we make sure fix-up patches get submitted to the upstream kernel? COMMENT: All can benefit from the kernel review process. COMMENT: We don't want to end up in a situation where the same functionality is handled one way in OFED, and another way in the kernel 5) Improve Housekeeping PROPOSAL: Review licenses/copyrights for correctness 6) Enabling Distros QUESTION: Is it true that RHEL doesn't take all of OFED 1.3, but instead pulls directly from the maintainers? (NOTE: Need followup) QUESTION: Is it true that RHEL and SUSE write their own backports, rather than using the OFED ones? (concern for us because of testing) QUESTION: How, exactly, are RHEL and SUSE distros put together? eg, does the distro just pull IB kernel support from the relevant kernel, rather than taking OFED kernel components? QUESTION: How do we coordinate OFED and distro releases, to maximize opportunityfor most recent OFED release to go in newest distro release? PROPOSAL for packaging change: a) Aggregate kernel patches and modules into one package b) User code - use tar-balls and sample RPM spec files for releases and RCs - use git (for daily builds) and pull script - distributors roll their own 7) Planning for interoperability events PROPOSAL: Do interoperability initial testing on final RC (only expected changes are interop changes), and do formal testing on GA. COMMENTS: - the best way to reach enterprise quality is to submit everything through the kernel, because of their rigorous review process - note that submitting to Roland's queue does not automatically mean the change goes into OFED - you have to specifically request that it go in.
